|Click here for RAC sponsor message|
Net.digest summarizes helpful technical
discussions on the HP
3000 Internet newsgroup. Advice here is
offered on a best-effort,
Good Samaritan basis. Test these concepts
for yourself before
applying them to your production or
development HP 3000s.
Sometimes while youre asking for one thing on the Internet, you get another that can help you even more. Or not, but at least its useful information you never might have found otherwise. Thats what happened when Rick Tomlinson of Wake Forest University asked for experiences with EMCs Symmetrix disk arrays. It was all the opening needed to tout new disk technology called SSA, and debate over whether HP would support it soon followed. David Lethe of Compass Corporate Systems, a firm offering SSA devices for HP 3000s, said:
Look at IBMs SSA for the HP 3000. It is typically several hundred percent faster, at about half the price. Hardware mirroring is in beta now. All the usual features you would expect, including: hotswap, multiple initator support (with limitations), RAID capability, works with HPs predictive and other diagnostics, priced around 50 cents/Mb, very high density .. almost a terabyte in a HP 19-inch rack, no single point of failure (redundant paths, cables, power), add, delete, reconfigure, mount them to different systems without a reboot.
The posting prompted a sobering reply from Bill Lancaster, who recently began heading up a new High Availability Special Interest Group at Interex:
A little caution is in order before making the jump to SSA for production. Im sure that Davids company did a great job in bringing the technology to the 3000. My concern is that it is not officially supported by HP. Until HP gets on the bandwagon of SSA on the 3000, I will find it very difficult to recommend it in the 3000 environment. At the very least, Davids company should get HP to say SSA does no harm and is at least as robust as JBOD (Just a Bunch Of Disk).
Charles Finley of 3000 integrator Open Ended Systems Corp. chimed in by reporting that HPs Fiber Channel (FC) disks were being positioned against SSA technology, then included his prediction of HPs 3000 support for SSA:
Much of the competitive positioning IBM is using against FC is several years old based on prototype products and is not relevant to products shipping today. For customers requiring multi-platform and multi-vendor support, a quick look at SSA should result in either a Parallel SCSI, UltraSCSI, or Fiber Channel decision. Customers who plan to implement an exclusive IBM shop may find IBM SSA attractive. However, beware of IBM shifting from SSA to FC-EL. Whether IBM abandons SSA or not, HP made it really clear that they have no plans to support SSA. Bottom line, expect no HP support and probably no investment protection with SSA.
But after a few more exchanges, HPs Larry Boyd of the New Opportunities Solution Team at CSY said the division has begun to investigate the new technology:
In defense of David, let me say that while CSY has not officially blessed these new drives, we are in discussions with David. CSY is focusing on projects that continue the life of the 3k beyond the year 2000, and for many years after that. It is very likely that the SSA drivers will help in this, and this is another reason we are interested in discussing the possibilities. On the other hand, as every company operates with few slack resources, it is likely that we are looking at an investigation for the first step and then a decision on the amount of work for the second (just like with EMC). These dont take one or two days.
The bottom line is that CSY is interested, and has begun discussing, the SSA solution. We cannot, at this time, indicate whether the solution will be viable for 3k customers, or at what time in the future you can expect an answer from HP. Its way too early in the process to guess what the outcome will be. Lets wait a little, giving David and CSY time to investigate before jumping on either one.
So Boyds reply showed HP will be
doing a technical investigation
of SSA on HP 3000s, at first to determine
how much work might
be needed from CSY engineers to support the
of that investigation might be on the minds
of customers such
as Tomlinson, looking to avoid the
extraordinary costs of EMCs
As HP continues to identify customers desire to make 3000s work in heterogenous environments, field experience illustrates how the fundamental skills to accomplish this need updating. Something as basic as moving datasets from one kind of HP system to another was the goal when James Trudeau asked:
We have a TurboIMAGE database which needs one of its datasets on the 9000. The output file created by the extract program on the 3000 is 23Gb. The program normally outputs a disk file, but were just a tad shy of that kind of free disk space, so I redirected it to a 120m DDS-2 tape. Well that, of course, worked fine until it hit EOT, thereby notifying MPE that the disk file is full and promptly crashes.
Trudeau supposed that he could change the disc-to-tape file equation and call it a labeled tape, but but I have no idea of how to tell the 9000 program that the input is labeled. Is there a simple way to move these files that Im not aware of? FTP and modems are out. Gotta be tape.
Lars Appel of HP replied that a combination of FCOPY and message files might work: If your data extraction tools is able to write to a MSG file then you might be able to use FCOPY to pick up chunks and direct them to tape. Something like...
Might have a number of gotchas. For example youd probably need to start the writing job/session before the first FCOPY open the MYMSGF successfully. It might also need a second reader to dummy-open then MYMSGF so that there is always at least one potential reader (otherwise the first FCOPY closing the file might make the writer complain instead of just block).
Stan Sieler delivered a pointer to a useful tool in the problem hed run across but hadnt used yet:
A year or two ago I stumbled across a company that has a program to read labeled tapes on HP-UX. REELexchange is produced by Sceptre Corporation, 3626 W. Liberty Road, Ann Arbor, MI 48103; 313.665.8778, fax 313.665.5707.
Tracy Johnson of the MK Group pointed out that good ol Quiz or QTP should make you a good ANSI labeled tape. Worked fine with reel-to-reel EOT. Dont know if behavior will be the same on a DDS.
Finally, Trudeau posted back with his solution, for the moment:
The problem was that the extract program was writing a 134 byte record to a 1024 byte record. After determining that there was no processing of the data just read-write-read-write I used Suprtool to copy the records from the dataset to a disk file. Then the disk file was FTP-flown to the 9000. Once there, I used SQLLOAD to plant it to the Oracle database. Okay for now, but Im quite sure this big file issue will rise again.
We might add it certainly will, so long
as HP continues to rely
on the 9000 line to provide applications
that must use data residing
on HP 3000 databases.
Eric Kundl posted a problem related to large programs that unearthed a way to extend an MPE/iX limit, and track programs with a large number of modules:
We embed in all our Cobol object modules a string that is reported by the version.pub.sys program, showing the user,release and date compiled. Then we can use version.pub.sys at any of our remote sites to see what the version is of each module in a run unit or XL. However, version.pub.sys seems to stop after reporting 100 modules, and we have one XL that has way over 100 modules in it. Is there a way to cause version.pub.sys to report past the 100th module in an XL?
HPs Jeff Vance and Scott McClellan
reported on the solution:
There is a freeware VERSION on Jazz that
bumps up the 100 limit
imposed by the program. Scott McClellan
gets the credit. See http://jazz. external.hp.com/src/src.html
Jim Phillips of Therm-O-Link wanted to know if COBOL II would perform an operation not recommended but sometimes necessary: Does anyone know if COBOL II/iX supports recursion? I have need to perform a paragraph recursively, but I can code around it if need be.
Walter Murray of the HP 3000 COBOL lab replied in short order: There are presently no known defects in COBOL II/iX regarding recursion. The ANSI COBOL standard doesnt permit recursion. COBOL II/iX will let you get away with it to some extent, but tries to warn you about it. It isnt recommended.
The use of recursive PERFORMs is not recommended and would likely impede migration to future systems. However, because of the way COBOL II/iX implements the PERFORM mechanism with a stack, you may be able to get away with it if you dont go too deep. How deep is too deep? Id certainly be worried if recursive PERFORMs approached a depth of 50.
If you do use recursive PERFORMs, or if you do other unorthodox things with PERFORM statements, compile with $CONTROL BOUNDS. It will detect a paragraph stack overflow and give you a meaningful error message. Otherwise, strange things may happen when the stack overflows.
Copyright 1998, The 3000 NewsWire. All rights reserved.