net.digest April 1998

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.

HP looks into new disk technology

Sometimes while you’re asking for one thing on the Internet, you get another that can help you even more. Or not, but at least it’s useful information you never might have found otherwise. That’s what happened when Rick Tomlinson of Wake Forest University asked for experiences with EMC’s 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 IBM’s 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 HP’s 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. I’m sure that David’s 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, David’s 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 HP’s Fiber Channel (FC) disks were being positioned against SSA technology, then included his prediction of HP’s 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, HP’s 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 don’t 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. It’s way too early in the process to guess what the outcome will be. Let’s wait a little, giving David and CSY time to investigate before jumping on either one.”

So Boyd’s 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 technology. Results of that investigation might be on the minds of customers such as Tomlinson, looking to avoid the extraordinary costs of EMC’s Symmetrix.

Moving bits across platforms

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 we’re 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 I’m 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...

BUILD MYMSGF;DISC=___;REC=___ FILE MYTAPE;DEV=___;REC=___ FCOPY FROM=*MYMSGF;TO=*MYTAPE;SUBSET=0,numrecs

“Might have a number of gotchas. For example you’d 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 he’d run across but hadn’t 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. Don’t 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 I’m 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.

More XL power with a patch

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? “

HP’s 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 under “misc”.

Going recursive in COBOL II

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 doesn’t permit recursion. COBOL II/iX will let you get away with it to some extent, but tries to warn you about it. It isn’t 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 don’t go too deep. How deep is too deep? I’d 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.




		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. HP looks into new disk technology Sometimes while you’re asking for one thing on the Internet, you get another that can help you even more. Or not, but at least it’s useful information you never might have found otherwise. That’s what happened when Rick Tomlinson of Wake Forest University asked for experiences with EMC’s 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 IBM’s 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 HP’s 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. I’m sure that David’s 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, David’s 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 HP’s Fiber Channel (FC) disks were being positioned against SSA technology, then included his prediction of HP’s 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, HP’s 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 don’t 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. It’s way too early in the process to guess what the outcome will be. Let’s wait a little, giving David and CSY time to investigate before jumping on either one.” So Boyd’s 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 technology. Results of that investigation might be on the minds of customers such as Tomlinson, looking to avoid the extraordinary costs of EMC’s Symmetrix. Moving bits across platforms 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 we’re 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 I’m 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... `BUILD MYMSGF;DISC=___;REC=___ FILE MYTAPE;DEV=___;REC=___ FCOPY FROM=MYMSGF;TO=MYTAPE;SUBSET=0,numrecs` “Might have a number of gotchas. For example you’d 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 he’d run across but hadn’t 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. Don’t 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 I’m 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. More XL power with a patch 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? “ HP’s 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 under “misc”. Going recursive in COBOL II 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 doesn’t permit recursion. COBOL II/iX will let you get away with it to some extent, but tries to warn you about it. It isn’t 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 don’t go too deep. How deep is too deep? I’d 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.