 |
 |
 |
Net.digest summarizes
helpful technical discussions on the comp.sys.hp.mpe Internet
newsgroup and 3000-L mailing list. Advice here is offered on a
best-effort, Good Samaritan basis. Test these concepts for yourself
before applying them to your HP 3000s.
Edited by John Burke
After a
month’s hiatus, the off-topic and wildly off-topic posts
returned in force, to the tune of 667 messages. In the merely
off-topic category were discussions about the proposed HP Compaq
merger/acquisition (overwhelmingly against), thus leading to the
demise of MPE (again), and discussions about whether HP World should
have a permanent home in San Jose (lots of sentiment in favor).
My favorite wildly off-topic thread (and I had a lot to choose from) morphed out of a merely off-topic thread. In “Cosmic Ruminations,” we were treated to, among other things, Roy Brown’s observation that if the universe is represented by eleven dimensions, only four of which we can experience, then the universe cannot be represented in HP 3000 COBOL since COBOL arrays are limited to only seven dimensions.
There were still more on-topic threads than off-topic threads, including two important ones that I’ve summarized below. As always, I would like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you think I’m full of it or goofed, or a horse’s behind, let me know. If something from these columns helped you, let me know. If you’ve got an idea for something you think I missed, let me know. If you spot something on 3000-L and would like someone to elaborate on what was discussed, let me know. Are you seeing a pattern here? You can reach me at john@burke-consulting.com.
Help, I’ve created a monster
Such was the plaintive cry that showed up on 3000-L one day. Here is the tale of woe:
“We’ve created on online report archiving system, which compresses a file into a GROUP and writes a record of it into a DB. It’s been running great now for about six months. However, as of late, performance of the machine has gone to hell and the system has been crashing from time to time. HP reviewed our memory dump and informed us that we’ve reached a maximum of 70,000 files within a single group.
“We’ve identified 40,000 files to purge. However, the system crashes whenever we attempt to purge the files. Unfortunately, this is a 24 x 7-production machine, with peak usage around 300 users.
“Things that we have tried: STORE with purge option (crashed); PURGE in a command file (crashed); PURGE in a JOB (crashed). Any ideas?”
Several people (mostly from HP) noted that if you want to purge only a subset of the files in the group, you have to purge the files in reverse alphabetical order to avoid the System Abort (probably SA2200). PURGEGROUP and PURGEACCT will be successful, but at the expense of having to recreate the accounting structure and restoring the files you want to keep. Note that if you log onto the group and then do PURGEGROUP you will not have to recreate the group.
Craig Fairchild, MPE/iX File System Architect explained what is going on.
“You must purge files in reverse alphabetical order. You can do this by creating a command file of purge commands with the file names in reverse alphabetical order, or by using the PURGEGROUP command and copying or restoring the files back.
“Your system abort stems from the fact that the system is trying desperately to make sure that all the changes to your directory are permanently recorded. To do this, MPE uses its Transaction Management (XM) facility on all directory operations. To make sure that the directories are not corrupted, XM takes a beginning image of the area of the directory being changed, and after the directory operation is complete, it takes an after-image. In this way, should the system ever crash in the middle of a directory operation, XM can always recover the directory to a consistent state — either before or after the operation, but not in a corrupted in-between state.
“On MPE, directories are actually just special files with records for each other file or directory that is contained in them. They are stored in sorted alphabetical order, with the disk address of the file label for that file. Because we must keep this list of files in alphabetical order, if you add or delete a file, the remaining contents of the file need to be “shifted” to make room, or to compact the directory. So, if you purge file the first file alphabetically, XM must record the entire contents of the directory file as the before image, and the entire remaining file as the after image.
“So purging from the top of the directory causes us to log data equal to twice the size of the directory. Purging from the bottom of directory causes XM to log much less data, since most of the records stay in the same place and their contents don’t change.
“The system abort comes from the fact that more data is being logged to XM than it can reliably record. When its logs fill completely and it can no longer provide protection for the transactions that have been initiated, XM will crash the system to ensure data integrity. In general, you should try to keep your directory sizes below 1.5Mb. This will mean a different number of files for root, account, group, and HFS directories since they all have different record sizes and structures. You can find a directory’s size by using the LISTFILE command:
:listfile /CRAIGF/PUB,2 or my personal favorite (available on release 6.5 and beyond), listfile /CRAIGF/PUB,11
HP’s Goetz Neumann added, “PURGEGROUP (and PURGEACCT) are not causing a SA2200 risk, since they actually traverse the directory in reverse alphabetical order internally. This is useful to know for performance reasons. Since these commands cause much smaller XM transactions, it is faster to empty a group by logging into it and then PURGEGROUP it, instead of using PURGE @.
“A little known fact is that there is a tool to help prevent you from running into these situations in the first place: DIRLIMIT.MPEXL.TELESUP. It should be documented in the MPE/iX 5.0 Communicator. A suggested (soft) limit for directory files would be 2Mb. This would limit MPE to not have more than 50,000 files in one group, and (very much depending on the filenames) much less than 50,000 files per HFS directory. (These are XM protected just as well, and 10,000s of files in an HFS directory are not a good idea from a performance standpoint either.)
“Another way to reduce the risk of SA2200 in these situations would be to increase the size of the XM system log file (on the volume set that holds the group with the large number of files), which is available per a VOLUTIL command since MPE/iX 6.0.”
Everything you ever wanted to know about gateways and the HP e3000
Questions about gateways frequently arise on 3000-L. I recently had my hands full with learned gateways issues, so it was serendipitous that James Hofmeister posted the tutorial which follows on how the HP e3000 deals with gateways (edited somewhat for space):
[3K] [ux] [3K] [ux] [nt]
| | | | |
+-----+----+ 12 +-+------------+-----+ 13
[R4] [R5] [R6]
\ / \
{wan} {wan} {wan}
/ / /
[R3] [R2] [R1]
+----+-------------+------------+----+ 11
| | |
[3K] [ux] [nt]
Figure 1
Path: NETXPORT.NI.LAN1.INTERNET.ROUTER
[A 011 001.001.001] Neighbor Gateway IP Internet Address
Configured Reachable Networks
IP Network Address IP Mask (Optional) Hops
[@ ] [ ] [ ]
Figure 2
Let’s start with a picture. Consider Figure 1. To simplify this example, assume the network addresses are 11.x.x.x, 12.x.x.x, and 13.x.x.x respectively, with a subnet mask of 255.0.0.0. From the 3000 on network 11 there is a single path R3-R4 to the 3000 on network 12. From the 3000 on network 11 there are 2 possible paths R2-R5 and R1-R6 to the 3000 on network 13. In the network of Figure 1, it is common for the gateway configuration on the 3000 on network 11 to look like Figure 2, where 11.1.1.1 is the IP address of [R1]. [R1] is the default gateway for the 3000 on network 11.
In this network R1, R2, R3, R4, R5, R6 all talk to each other communicating link status (up/down), best performing route, and route/path configuration. The 3000’s only listen to ICMP request for updates to the routing tables. The 3000’s do not support the protocols that listen to messages passed between routers. For details on the ICMP message “Route Change Request” see Douglas E. Comer — Internetworking with TCP/IP, Vol. 1 (3rd Edition) pages 131-132.
:nettool.net.sys;info="nameaddr;routing;gatelist;quit"
[5]NAMEADDR.ROUTING>>>gatelist
Network address filter: @
Gateway address filter: @
Gateway IP Hops Flags Active Default Gateway
______________________________________________________________
11.1.1.1 0 0 y y
______________________________________________________________
Total number of gateways = 1
[6]NAMEADDR.ROUTING>>>quit
:nettool.net.sys;info="nameaddr;routing;routing;quit"
>>>routing
Network address filter: @
Gateway address filter: @
Network number Subnet mask Gateway Hops Flags
______________________________________________________________
Total number of routings = 0
Figure 3
Example 1: The 3000 on network 11 reaches the 3000 on network 13 by the default gateway [R1]. The gateway table will look like Figure 3.
Example 2: The 3000 on network 11 attempts to reach the 3000 on network 12 by the default gateway [R1], but a path does not exist and [R1] knows this, thus [R1] sends a ICMP redirect specifying that the 3000 on network 12 can be reached by going to [R3]. The 3000 on network 11 now reaches the 3000 on network 12 via the learned gateway [R3]. The gateway table will look like Figure 4 below:
:nettool.net.sys;info="nameaddr;routing;gatelist;quit"
[5]NAMEADDR.ROUTING>>>gatelist
Network address filter: @
Gateway address filter: @
Gateway IP Hops Flags Active Default Gateway
______________________________________________________________
11.1.1.1 0 0 y y
11.1.1.3 0 0 y n
______________________________________________________________
Total number of gateways = 2
[6]NAMEADDR.ROUTING>>>quit
:nettool.net.sys;info="nameaddr;routing;routing;quit"
>>>routing
Network address filter: @
Gateway address filter: @
Network number Subnet mask Gateway Hops Flags
______________________________________________________________
12.0.0.0 255.0.0.0 11.1.1.3 0 0
______________________________________________________________
Total number of routings = 1
Figure 4
Example 3: The {wan} between [R1] and [R6] is down. The 3000 on network 11 attempts to reach the 3000 on network 13 by the default gateway [R1], but the link is now down and [R1] knows this, thus [R1] sends a ICMP redirect specifying that the 3000 on network 13 can be reached by going to [R2]. The 3000 on network 11 now reaches the 3000 on network 13 via the learned gateway [R2]. The gateway table will look like Figure 5 below:
:nettool.net.sys;info="nameaddr;routing;gatelist;quit"
[5]NAMEADDR.ROUTING>>>gatelist
Network address filter: @
Gateway address filter: @
Gateway IP Hops Flags Active Default Gateway
______________________________________________________________
11.1.1.1 0 0 y y
11.1.1.3 0 0 y n
11.1.1.2 0 0 y n
______________________________________________________________
Total number of gateways = 3
[6]NAMEADDR.ROUTING>>>quit
:nettool.net.sys;info="nameaddr;routing;routing;quit"
>>>routing
Network address filter: @
Gateway address filter: @
Network number Subnet mask Gateway Hops Flags
______________________________________________________________
12.0.0.0 255.0.0.0 11.1.1.3 0 0
13.0.0.0 255.0.0.0 11.1.1.2 0 0
______________________________________________________________
Total number of routings = 2
Figure 5
Example 4: The {wan} between [R1] and [R6] is now back up. The 3000 on network 11 attempts to reach the 3000 on network 13 by the learned gateway [R2]. But, the [R2] knows the {wan} between [R1] and [R6] is now back up and that [R1] is the preferred route, thus [R2] sends a ICMP redirect specifying that the 3000 on network 13 can be reached by going to [R1]. The 3000 on network 11 now reaches the 3000 on network 13 via the learned gateway [R1]. The gateway table will look like Figure 6 below:
:nettool.net.sys;info="nameaddr;routing;gatelist;quit"
[5]NAMEADDR.ROUTING>>>gatelist
Network address filter: @
Gateway address filter: @
Gateway IP Hops Flags Active Default Gateway
______________________________________________________________
11.1.1.1 0 0 y y
11.1.1.3 0 0 y n
11.1.1.2 0 0 y n
______________________________________________________________
Total number of gateways = 3
[6]NAMEADDR.ROUTING>>>quit
:nettool.net.sys;info="nameaddr;routing;routing;quit"
>>>routing
Network address filter: @
Gateway address filter: @
Network number Subnet mask Gateway Hops Flags
______________________________________________________________
12.0.0.0 255.0.0.0 11.1.1.3 0 0
13.0.0.0 255.0.0.0 11.1.1.1 0 0
______________________________________________________________
Total number of routings = 2
Figure 6
Some further notes: It is not necessary to delete learned gateways if routers respond to connection request with the appropriate ICMP Redirect.
If an entry is new, a learned route will be added to the 3000 routing table.
If an entry is changed, the existing learned route will be updated in the 3000 routing table.
Receiving an ICMP redirect and learning a new route does not guarantee that existing connections will not be disconnected.
It is possible to down learned gateways in nettool. The possibility of disconnecting existing connections exists if an active gateway is downed. It is possible to delete learned gateways with “netcontrol update=”. The possibility of disconnecting existing connections exists if an active gateway is deleted.
The learned gateways will exist (unless deleted) until the network is stopped (:netcontrol stop) and restarted or until the system is restarted.
John Burke is the editor of the NewsWire’s HiddenValue and net.digest columns and has more than 20 years’ experience managing HP 3000s.
Copyright The 3000 NewsWire. All rights reserved.