net.digest June 1998

Click here for Lund Performance Solutions 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.

A peek at 64-bit promise on 3000s

The HP 3000 is definitely getting a 64-bit overhaul, as engineers in the 3000 division (CSY) renovate the operating system for new chips from the PA-RISC line and other sources. Sometimes a forthright question from Internet readers can draw out one of the CSY engineers to explore more of this kind of future vision. It happened when an admittedly non-technical operations manager Kathy McCarthy asked, “Assuming HP will eventually provide this (64-bit) technology in the HP 3000, will the benefits be the same, greater, or less than on the 9000?” It was a good enough question to elicit this reply from CSY’s Jeff Vance

“The initial releases of 64 bitness in MPE will differ from HP-UX in some external ways:

• There will not be a 64-bit developers environment (compilers, debuggers). This means that you do not need modify your application to run on MPE with 64 bitness. The 64 bit features will be internal and allow us to support files up to 1 TB and larger physical memory and larger objects.

• There will not be mirrored 64 bit APIs (MPE intrinsics). Again this means that you do not need to re-engineer the applications and tools that you are using on MPE. It also means you do not have direct access to MPE’s 64 bitness. It is currently a fairly large effort to get apps to HP-UX 11.0 in wide mode, i.e. using the 64 bit environment.

• The SOM (executable) format is still used vs. converting to ELF-64 as in HP-UX. Again no impact to you or third parties.”

McCarthy also asked about the impact of 64-bits on third party software providers for the 3000, and what the benefits might be from a 64-bit MPE – would large shops be the only ones to see an improvement? Vance replied:

“There should be no effort to most third parties. The exceptions would be tools vendors that have intimate knowledge of the OS and some of its lower level data structures. We will be (and are) working with these third parties to ensure that their products run well on the initial release of MPE that supports 64 bits.”

The benefits were widespread: “The main benefits of MPE 64 bit computing are:

a. faster memory to memory moves, which are common in the OS; b. support of large internal objects (data structures); c. due to b. we can support more physical memory, so if your applications run faster with more memory, then this will improve their performance.

“A drawback of 64 bitness in wide mode (that is, 64 bit address offsets, or a flat 64 bit address space) is that performance generally gets worse. The reason is that most applications don’t need 64 bit addresses, but they will be using them and the associated extra space. These wider addresses consume more cache space, which means there are less unique addresses we can have in the cache. This causes us to have more cache misses, which results in more OS overhead to translate virtual address to real addresses. As far as I know, HP-UX 64-bit benchmarks will be done in “narrow” 32 bit mode. Narrow mode is only mode initially supported by MPE.”

Stan Sieler, a legendary developer whose company has been contracted by CSY for some time to do MPE/iX enhancements, added his own view of 64-bit benefits:

“To some extent, many applications will benefit automatically. We’ve been able to do applications that manipulate files of up to 4Gb years before most platforms could. We’ll have the ability to manipulate terabyte files soon, on current hardware – and in a cleaner, more thorough implementation than provided in Unix. That means that application vendors will soon be able to take advantage of such files prior to any new hardware being shipped.

“So, we benefit automatically where improvements in the underlying operating system happen to speed up file access, for example.

“On the other hand, yes – I’d hope that some applications would be changed to do a better job of taking of new hardware, particularly the amount of memory that can be put on a machine.”

Sieler noted that HP has already announced it will be directly supporting the new 64-bit hardware in the future. The only question remaining to be answered is which 64 bit hardware will be included, other than PA-RISC. It was up to John Clogg to address the indirect question of what these 64-bit plans mean to the 3000’s future. “The best news is that you don’t have to be afraid to stay with the HP 3000 from the standpoint of scalability and continued commitment from HP.”

Losing CPU? Quiet those heartbeats

Apparently the recent version of MPE/iX is more sensitive to heartbeat signals generated by network transceivers in LANs. The result can be a drain of up to 15 percent of CPU, according to tests run by Shawn Gordon. Several Internet readers posted some solutions to keep 3000s from losing CPU while running MPE/iX 5.5 Express 3 or later.

John Zoltak reported, “I noticed this same thing when I updated to [Express 3]. It seemed to be the SQE switch on transceivers to DTCs was not on. Something about the new DTC code. After flipping the SQE switch to on, the excessive activity stopped.”

Ken Sletten found another leak to plug. “Not only CPU activity: If the SQE heartbeat on the 10BaseT transceiver is not on, believe you will also get a high level of disc I/O, because the system wants to log each of these “events.” When we first switched from 10Base2 to 10BaseT and hooked up a DTC, we immediately started seeing a continuous 70-80 I/Os per second. Eventually got around to doing a LINKCONTROL @; STATUS = ALL and noticed we had millions of heartbeat losses recorded since last reset. Turned on transceiver SQE heartbeat and all was well.” Bill Lancaster noted that “you can also change a parameter in NMMGR to essentially not allow the SQE heartbeat losses to be recorded on the 3000.”

Advice on restoring datasets: don’t

Operational choices sometimes take the risk of ignoring longstanding advice, especially if you’re not as longstanding in the 3000 environment. To put it another way, just because you can do something doesn’t mean you should. During an application upgrade, one company had to set up new tables included in a single IMAGE dataset. In trying to avoid re-doing all the table entries again, the manager wanted to know best way of storing/restoring that dataset.

The advice was direct from Jeff Kell. “Thou shalt not store/restore individual datasets. You might check around for DB2DISK/DISK2DB or some equivalent programs that have circulated around in the Contributed Software Library for ages. Or if you don’t have the CSL, you might find it on one of the 3000-friendly Web sites or FTP directories. With these programs you can export IMAGE datasets to flat files and vice versa, although the usual IMAGE restrictions exist (load masters before details, etc). These programs use straightforward IMAGE intrinsics to do their work, so you have to play by the rules.”

Ken Sletten added, “If you happen to have HP’s DICT/3000, it comes with a couple nice utilities: DICTDBU and DICTDBL, for unload-to-flatfile-on-disc and reload to dataset. They keep all those zillions of IMAGE pointers and etc. relationships straight, and can be used at the individual dataset level.”

Phil Anthony suggested another way. “Well, if you have Suprtool, you could extract them to a flat file and then use Suprtool to put the entries to the new dataset. Barring that, you could extract them with QUERY and write a COBOL program to put the entries back. You definitely don’t want to store and restore the individual set.”

Copyright 1998, The 3000 NewsWire. All rights reserved.




		Click here for Lund Performance Solutions 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. A peek at 64-bit promise on 3000s The HP 3000 is definitely getting a 64-bit overhaul, as engineers in the 3000 division (CSY) renovate the operating system for new chips from the PA-RISC line and other sources. Sometimes a forthright question from Internet readers can draw out one of the CSY engineers to explore more of this kind of future vision. It happened when an admittedly non-technical operations manager Kathy McCarthy asked, “Assuming HP will eventually provide this (64-bit) technology in the HP 3000, will the benefits be the same, greater, or less than on the 9000?” It was a good enough question to elicit this reply from CSY’s Jeff Vance “The initial releases of 64 bitness in MPE will differ from HP-UX in some external ways: • There will not be a 64-bit developers environment (compilers, debuggers). This means that you do not need modify your application to run on MPE with 64 bitness. The 64 bit features will be internal and allow us to support files up to 1 TB and larger physical memory and larger objects. • There will not be mirrored 64 bit APIs (MPE intrinsics). Again this means that you do not need to re-engineer the applications and tools that you are using on MPE. It also means you do not have direct access to MPE’s 64 bitness. It is currently a fairly large effort to get apps to HP-UX 11.0 in wide mode, i.e. using the 64 bit environment. • The SOM (executable) format is still used vs. converting to ELF-64 as in HP-UX. Again no impact to you or third parties.” McCarthy also asked about the impact of 64-bits on third party software providers for the 3000, and what the benefits might be from a 64-bit MPE – would large shops be the only ones to see an improvement? Vance replied: “There should be no effort to most third parties. The exceptions would be tools vendors that have intimate knowledge of the OS and some of its lower level data structures. We will be (and are) working with these third parties to ensure that their products run well on the initial release of MPE that supports 64 bits.” The benefits were widespread: “The main benefits of MPE 64 bit computing are: a. faster memory to memory moves, which are common in the OS; b. support of large internal objects (data structures); c. due to b. we can support more physical memory, so if your applications run faster with more memory, then this will improve their performance. “A drawback of 64 bitness in wide mode (that is, 64 bit address offsets, or a flat 64 bit address space) is that performance generally gets worse. The reason is that most applications don’t need 64 bit addresses, but they will be using them and the associated extra space. These wider addresses consume more cache space, which means there are less unique addresses we can have in the cache. This causes us to have more cache misses, which results in more OS overhead to translate virtual address to real addresses. As far as I know, HP-UX 64-bit benchmarks will be done in “narrow” 32 bit mode. Narrow mode is only mode initially supported by MPE.” Stan Sieler, a legendary developer whose company has been contracted by CSY for some time to do MPE/iX enhancements, added his own view of 64-bit benefits: “To some extent, many applications will benefit automatically. We’ve been able to do applications that manipulate files of up to 4Gb years before most platforms could. We’ll have the ability to manipulate terabyte files soon, on current hardware – and in a cleaner, more thorough implementation than provided in Unix. That means that application vendors will soon be able to take advantage of such files prior to any new hardware being shipped. “So, we benefit automatically where improvements in the underlying operating system happen to speed up file access, for example. “On the other hand, yes – I’d hope that some applications would be changed to do a better job of taking of new hardware, particularly the amount of memory that can be put on a machine.” Sieler noted that HP has already announced it will be directly supporting the new 64-bit hardware in the future. The only question remaining to be answered is which 64 bit hardware will be included, other than PA-RISC. It was up to John Clogg to address the indirect question of what these 64-bit plans mean to the 3000’s future. “The best news is that you don’t have to be afraid to stay with the HP 3000 from the standpoint of scalability and continued commitment from HP.” Losing CPU? Quiet those heartbeats Apparently the recent version of MPE/iX is more sensitive to heartbeat signals generated by network transceivers in LANs. The result can be a drain of up to 15 percent of CPU, according to tests run by Shawn Gordon. Several Internet readers posted some solutions to keep 3000s from losing CPU while running MPE/iX 5.5 Express 3 or later. John Zoltak reported, “I noticed this same thing when I updated to [Express 3]. It seemed to be the SQE switch on transceivers to DTCs was not on. Something about the new DTC code. After flipping the SQE switch to on, the excessive activity stopped.” Ken Sletten found another leak to plug. “Not only CPU activity: If the SQE heartbeat on the 10BaseT transceiver is not on, believe you will also get a high level of disc I/O, because the system wants to log each of these “events.” When we first switched from 10Base2 to 10BaseT and hooked up a DTC, we immediately started seeing a continuous 70-80 I/Os per second. Eventually got around to doing a LINKCONTROL @; STATUS = ALL and noticed we had millions of heartbeat losses recorded since last reset. Turned on transceiver SQE heartbeat and all was well.” Bill Lancaster noted that “you can also change a parameter in NMMGR to essentially not allow the SQE heartbeat losses to be recorded on the 3000.” Advice on restoring datasets: don’t Operational choices sometimes take the risk of ignoring longstanding advice, especially if you’re not as longstanding in the 3000 environment. To put it another way, just because you can do something doesn’t mean you should. During an application upgrade, one company had to set up new tables included in a single IMAGE dataset. In trying to avoid re-doing all the table entries again, the manager wanted to know best way of storing/restoring that dataset. The advice was direct from Jeff Kell. “Thou shalt not store/restore individual datasets. You might check around for DB2DISK/DISK2DB or some equivalent programs that have circulated around in the Contributed Software Library for ages. Or if you don’t have the CSL, you might find it on one of the 3000-friendly Web sites or FTP directories. With these programs you can export IMAGE datasets to flat files and vice versa, although the usual IMAGE restrictions exist (load masters before details, etc). These programs use straightforward IMAGE intrinsics to do their work, so you have to play by the rules.” Ken Sletten added, “If you happen to have HP’s DICT/3000, it comes with a couple nice utilities: DICTDBU and DICTDBL, for unload-to-flatfile-on-disc and reload to dataset. They keep all those zillions of IMAGE pointers and etc. relationships straight, and can be used at the individual dataset level.” Phil Anthony suggested another way. “Well, if you have Suprtool, you could extract them to a flat file and then use Suprtool to put the entries to the new dataset. Barring that, you could extract them with QUERY and write a COBOL program to put the entries back. You definitely don’t want to store and restore the individual set.”
		Copyright 1998, The 3000 NewsWire. All rights reserved.