net.digest December 1997

Click here for RAC sponsor message

Net.digest summarizes helpful technical discussions on the HP 3000-L Internet mailing list. 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.

Analysis by John Burke

To array or not to array, that is the question

Whether ’tis nobler to use a RAID stack or to, perchance, use mirrored disk… Anyway, you get the idea. This thread was started by the following question:

“We have a 3000 that is having some disk bottleneck problems. Most of our disk drives are older single-ended drives. We want to replace them with newer Fast/Wide disks (FWD) and IO cards, and get some redundancy at the same time. I have heard conflicting stories on using disk arrays versus regular FWD drives that are mirrored. Does anyone have any experience in which solution is better for disk performance?”

Two well-known members of the HP 3000 community responded, demonstrating once again that there can be more than one right answer:

Bill Lancaster (BL): “There is really no conflict. Mirrored disks perform much better than disk arrays.”

Guy Smith (GS): “Arrays, and for two reasons:

“1) Mirroring requires CPU cycles to manage and synchronize disks (this is on top of normal disk delays, including disk speed, SCSI I/O functions and contention, etc). If you are ever short on CPU, then mirroring overhead may become a problem.

“2) Many arrays come with significant RAM caches and can reduce I/O time by avoiding disk reads/writes. Large caches can be found on single drives, but it is fairly rare.

“3) Also, the last time I checked, mirroring was not supported for the system volume set. Since transient I/O can be significant, and since redundancy for the system volume set is highly desirable, you’ll likely end up with one set of arrays anyway.”

BL: “Mirroring requires generally very little CPU. Maybe 2 to 3 percent at most, on very active systems. Additionally, there is actually a performance ‘boost’ when using mirrored disk, because MPE is smart enough to be able to choose the mirror to read from if the master is busy, and vice versa.

“Array cache is generally ineffective on MPE/iX. This is mainly because MPE/iX does such a great job of prefetching. This is particularly true of EMC cache. It is usually much, much better to drop cache from disk subsystems and increase memory on the 3000.

“The best I/O environment, in my opinion, utilizes disk arrays for the system volume set and mirrored disk for other user volume sets.”

GS (responding about cache): “True enough, though for systems with high volume, but extremely random I/O, disk caching can boost performance. Also, cache on arrays comes into play for write operations, especially operations which cause locks until the write is completed. Of course, this is so application-specific that how much disk based write cache helps any given system is difficult to predict.”

But is it just the difference of one letter?

This is one of those topics that sounds deceptively simple, that most of us have a “feeling” about, and that is not covered in the standard MPE documentation. The question that prompted this thread: “Is there a meaningful difference between doing a ctrl-a and a ctrl-b when you’re doing a normal, i.e. not panic-mode shutdown on a HP 3000?” Pete Crosby of Hewlett-Packard gave the following explanation:

Let’s take a look at both Classic and MPE/XL systems.

First of all, skipping the system termination aspects, a CTL-B is used to communicate with the CPU hardware (generally a maintenance processor or equivalent). CTL-A communicates with a low-level functionality of the operating system; it can be used to issue console-level commands (REPLY, LOGON, LOGOFF, ABORTIO, etc) and to shut the system down. When you issue a SHUTDOWN command, the net effect is that a message is sent to the system’s parent process (pin #1, PROGEN) to bring the operating system down. This is an orderly shutdown where all processes are told to terminate and all files get closed and posted to disk.

On a Classic, pre-MPE/XL, system a SHUTDOWN works as just explained. No more, no less. A CTL-B HALT (or START or LOAD, either of which will result in a halt occurring first) results in files being left open and changes not getting posted to disk, including file label and directory changes. Under the wrong circumstances this can be quite catastrophic, but the OS does its best to limit that vulnerability. However, upon reboot there is likely to be a fair amount of cleanup that needs to be performed by the user, especially with regard to databases, KSAM files, and message files.

On an MPE/XL system, a SHUTDOWN also works as explained above but this includes bringing down Transaction Management (XM). XM termination will assure that transactions are completed or backed out and all I/Os get posted to disk. A CTL-B ‘TC’ or ‘RS’ is, as on a CLASSIC machine, equivalent to a system failure or system halt; it is an immediate cessation of OS activity. Files are not closed, data in memory never gets posted to disk, etc. However, XM will protect some user file types, some system structures, and the directory and label tables. During system reboot, when the last volume in each volume set is mounted, XM SYSTEMLOG and XM USERLOG recovery will take place and transactions will either get posted or backed out leaving files and system structures in a logically consistent state. This greatly reduces the amount of user recovery that may need to be performed.

Therefore, unless you have to halt the system due to a system hang or to capture a hung process in a memory dump, on both types of systems you should ALWAYS perform a CTL-A SHUTDOWN if possible. If this is not possible, then have as many users log off as you can to assure that their open files get closed, and then use CTL-B to halt/restart the system.

Need to be up-to-date on CIUPDATE?

Even though it was introduced around 1992, TurboIMAGE’s Critical Item Update (CIUPDATE, or CIU) is not well understood in all quarters, as evidenced by this thread.

The stage: I think I need to use CIUPDATE in a project and have several questions. The questions and answers (supplied by Jerry Fochtman and Steve Dirickson):

Q: What are the preconditions for CIU to work?

A: You should understand whether the application relies on failure of calls to DBUPDATE when attempting to update a search or sort field. If indeed this is an expected behavior, then you should set CIUPDATE to ‘ALLOWED,’ which means by default CIUPDATE is not allowed, but can be enabled for the specific task by calling DBCONTROL, mode 5. And conversely disabled using DBCONTROL mode 6.

Q: What do I do to get it started in DBUTIL?

A: In DBUTIL:

SET basename/maintword CIUPDATE={OFF ALLOWED ON}

Q: Does it work from Query?

A: Yes, like a champ, but only if the setting for the database is CIUPDATE=ON. Unfortunately, QUERY does not provide the ability to issue DBCONTROL options to an opened base. The DBUTIL CIUPDATE setting also has another value, “ALLOWED.” This does not turn on the critical-item update capability for the database, but allows an application program to turn it on as needed using DBCONTROL. I don’t think that QUERY was modified to support on-the-fly enabling of CIUPDATE, so the database has to be in the “ON” state instead of “ALLOWED” for QUERY to update search or sort items.

Q: If so, is there a special command, or does Query’s UPDATE REPLACE command take care of it by itself?

A: No special command; it just makes REP searchitem=”newvalue”;end work instead of blow up.

Original material copyright 1997, The 3000 NewsWire. All rights reserved.




		Click here for RAC sponsor message
		Net.digest summarizes helpful technical discussions on the HP 3000-L Internet mailing list. 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. Analysis by John Burke To array or not to array, that is the question Whether ’tis nobler to use a RAID stack or to, perchance, use mirrored disk… Anyway, you get the idea. This thread was started by the following question: “We have a 3000 that is having some disk bottleneck problems. Most of our disk drives are older single-ended drives. We want to replace them with newer Fast/Wide disks (FWD) and IO cards, and get some redundancy at the same time. I have heard conflicting stories on using disk arrays versus regular FWD drives that are mirrored. Does anyone have any experience in which solution is better for disk performance?” Two well-known members of the HP 3000 community responded, demonstrating once again that there can be more than one right answer: Bill Lancaster (BL): “There is really no conflict. Mirrored disks perform much better than disk arrays.” Guy Smith (GS): “Arrays, and for two reasons: “1) Mirroring requires CPU cycles to manage and synchronize disks (this is on top of normal disk delays, including disk speed, SCSI I/O functions and contention, etc). If you are ever short on CPU, then mirroring overhead may become a problem. “2) Many arrays come with significant RAM caches and can reduce I/O time by avoiding disk reads/writes. Large caches can be found on single drives, but it is fairly rare. “3) Also, the last time I checked, mirroring was not supported for the system volume set. Since transient I/O can be significant, and since redundancy for the system volume set is highly desirable, you’ll likely end up with one set of arrays anyway.” BL: “Mirroring requires generally very little CPU. Maybe 2 to 3 percent at most, on very active systems. Additionally, there is actually a performance ‘boost’ when using mirrored disk, because MPE is smart enough to be able to choose the mirror to read from if the master is busy, and vice versa. “Array cache is generally ineffective on MPE/iX. This is mainly because MPE/iX does such a great job of prefetching. This is particularly true of EMC cache. It is usually much, much better to drop cache from disk subsystems and increase memory on the 3000. “The best I/O environment, in my opinion, utilizes disk arrays for the system volume set and mirrored disk for other user volume sets.” GS (responding about cache): “True enough, though for systems with high volume, but extremely random I/O, disk caching can boost performance. Also, cache on arrays comes into play for write operations, especially operations which cause locks until the write is completed. Of course, this is so application-specific that how much disk based write cache helps any given system is difficult to predict.” But is it just the difference of one letter? This is one of those topics that sounds deceptively simple, that most of us have a “feeling” about, and that is not covered in the standard MPE documentation. The question that prompted this thread: “Is there a meaningful difference between doing a ctrl-a and a ctrl-b when you’re doing a normal, i.e. not panic-mode shutdown on a HP 3000?” Pete Crosby of Hewlett-Packard gave the following explanation: Let’s take a look at both Classic and MPE/XL systems. First of all, skipping the system termination aspects, a CTL-B is used to communicate with the CPU hardware (generally a maintenance processor or equivalent). CTL-A communicates with a low-level functionality of the operating system; it can be used to issue console-level commands (REPLY, LOGON, LOGOFF, ABORTIO, etc) and to shut the system down. When you issue a SHUTDOWN command, the net effect is that a message is sent to the system’s parent process (pin #1, PROGEN) to bring the operating system down. This is an orderly shutdown where all processes are told to terminate and all files get closed and posted to disk. On a Classic, pre-MPE/XL, system a SHUTDOWN works as just explained. No more, no less. A CTL-B HALT (or START or LOAD, either of which will result in a halt occurring first) results in files being left open and changes not getting posted to disk, including file label and directory changes. Under the wrong circumstances this can be quite catastrophic, but the OS does its best to limit that vulnerability. However, upon reboot there is likely to be a fair amount of cleanup that needs to be performed by the user, especially with regard to databases, KSAM files, and message files. On an MPE/XL system, a SHUTDOWN also works as explained above but this includes bringing down Transaction Management (XM). XM termination will assure that transactions are completed or backed out and all I/Os get posted to disk. A CTL-B ‘TC’ or ‘RS’ is, as on a CLASSIC machine, equivalent to a system failure or system halt; it is an immediate cessation of OS activity. Files are not closed, data in memory never gets posted to disk, etc. However, XM will protect some user file types, some system structures, and the directory and label tables. During system reboot, when the last volume in each volume set is mounted, XM SYSTEMLOG and XM USERLOG recovery will take place and transactions will either get posted or backed out leaving files and system structures in a logically consistent state. This greatly reduces the amount of user recovery that may need to be performed. Therefore, unless you have to halt the system due to a system hang or to capture a hung process in a memory dump, on both types of systems you should ALWAYS perform a CTL-A SHUTDOWN if possible. If this is not possible, then have as many users log off as you can to assure that their open files get closed, and then use CTL-B to halt/restart the system. Need to be up-to-date on CIUPDATE? Even though it was introduced around 1992, TurboIMAGE’s Critical Item Update (CIUPDATE, or CIU) is not well understood in all quarters, as evidenced by this thread. The stage: I think I need to use CIUPDATE in a project and have several questions. The questions and answers (supplied by Jerry Fochtman and Steve Dirickson): Q: What are the preconditions for CIU to work? A: You should understand whether the application relies on failure of calls to DBUPDATE when attempting to update a search or sort field. If indeed this is an expected behavior, then you should set CIUPDATE to ‘ALLOWED,’ which means by default CIUPDATE is not allowed, but can be enabled for the specific task by calling DBCONTROL, mode 5. And conversely disabled using DBCONTROL mode 6. Q: What do I do to get it started in DBUTIL? A: In DBUTIL: `SET basename/maintword CIUPDATE={OFF ALLOWED ON}` Q: Does it work from Query? A: Yes, like a champ, but only if the setting for the database is CIUPDATE=ON. Unfortunately, QUERY does not provide the ability to issue DBCONTROL options to an opened base. The DBUTIL CIUPDATE setting also has another value, “ALLOWED.” This does not turn on the critical-item update capability for the database, but allows an application program to turn it on as needed using DBCONTROL. I don’t think that QUERY was modified to support on-the-fly enabling of CIUPDATE, so the database has to be in the “ON” state instead of “ALLOWED” for QUERY to update search or sort items. Q: If so, is there a special command, or does Query’s `UPDATE REPLACE` command take care of it by itself? A: No special command; it just makes `REP searchitem=”newvalue”;end` work instead of blow up. Original material copyright 1997, The 3000 NewsWire. All rights reserved.