|
Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup and 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 This month seemed to have more off-topic threads than usual. Perhaps this was because the month included the Solutions Symposium, SIG3000 and the FLORUG Performance Conference, not to mention the official announcement of the A-class and N-class HP e3000s and MPE/iX 7.0. Anyway, readers were treated to a lengthy argument about what constitutes a Julian date and a very lengthy thread that started out as a discussion about the power problems in California and rolling blackouts. It then morphed into an argument about whether Silicon Valley could or would relocate itself to, for example, the Midwest and then morphed again into a rather passionate argument about schools and schooling. There was also a lengthy thread on whether it is disk or disc and a very, very lengthy thread on what is meant by separation of church and state. You could easily get the impression no one was doing any useful work this month, but maybe it was just the effects of a long winter. And lets not forget about Alfredo Rego at Alpine Ski WM 2001 in St. Anton, Austria. He may have come in last, but he was the oldest competitor, and he finished both runs which more than half the starting field did not. One lengthy semi-on-topic thread started with the discussion of a Gartner Group report on the cost in both time and dollars in migrating a COBOL programmer to Java, and then retaining him. It then wound through a discussion of object oriented programming and techniques and ended with a posting by Wirt Atmar on the word pleiotropy and how it applies to all complex systems whether biological, social or engineering. Loosely translated, the word means change a single item in a complex system and other subsystems may be affected in wholly unexpected manners. Look it up in the archives. As usual, there was still a lot of very much on-topic information, some of which is summarized below and in Hidden Value. I would like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you think Im full of it or goofed, or a horses behind, let me know. If something from these columns helped you, let me know. If youve 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@paccoast.com. A word or two about the new, improved SIB As you read this, voting will have already started or will be about to start on the 2001 System Improvement Ballot (SIB). [Note that voting is expected to end about April 1.] The SIB is different this year from previous years in several important ways. One thing that has not changed though is that you will likely find that many of the items on the SIB have been discussed, and possibly discussed extensively, on 3000-L. One thing that has changed significantly from the past is that this year CSY has committed funds and engineering time to working on some of the top requested items. The importance of this cannot be over-emphasized. This is the first time CSY has ever made such a commitment. However, this comes with a price, albeit not that expensive a price once you consider it. Interex, the MPE Forum, the SIG leaders and CSY have agreed on a very shortened SIB cycle from initial SIG ballot preparation through SIG balloting to the final SIB results. More importantly, all have agreed on a vetting process that ensures that the items on the final SIB are do-able. Finally, the results of the vote are not binding, but only serve as guidelines for CSY. Dont get too concerned about this though, because CSY is just being cautious since this is the first time for this process. Considering the up-front vetting of ballot items, if an item is an overwhelming favorite in the SIB balloting, I fully expect CSY will work on it. Here is what this means for the SIB that you will vote on. Items for which there is a third-party solution or an acceptable work-around will probably not be included in the SIB. Items that HP has indicated in the past it will not work on, for whatever reason, will almost certainly not be on the final SIB regardless of the popularity. Furthermore, items that can properly be considered bugs will also not be included. So, if one of your long-time favorites doesnt make the SIB, please understand the reasons. Even after all this preliminary ballot preparation, please also consider SIG-IMAGE/SQL Chairman Ken Slettens advice when you vote on the SIB: I urge all voters to THINK STRATEGIC. Take all of this into consideration when you are voting in the next week or two. Make sure your votes count. I opened the database read only, yet the root file shows modified why? For system managers, there is little more important than the integrity of backups, so when I saw this thread on 3000-L, I flagged it as something I wanted to come back to and resolve if possible. The thread started with this posting: We have noticed that even if we open a TurboIMAGE database in mode 5 and use a read-only password, and not even open a single dataset, the modification date of the root file is changed. Is this supposed to happen? And if so, why? I have always understood, and, in fact, relied on changing the modification date by opening a database in mode 1, but why would mode 5 have the same effect? And, will this effect backups using the DATE>= modified date parameter? In other words, if I do incremental STORE backups, will the entire database be backed up because the root file got stamped as modified even though the database was in fact not modified? First off, Patrick Mullen of Adager Corp. provided an explanation for the change in modify date of the root file: There are run-time fields in the root file that get modified during a DBOPEN regardless of mode. They revert back to initial values (in the cases I examined) upon DBCLOSE. So, in effect, no lasting modification transpired although a run-time modification took place. I must say that I, too, was surprised but now understand how it happened. The corresponding/underlying datasets do not, however, get an updated mod date during DBFIND/DBGET on a database opened in mode 5. Now, what about the backup question? There was some controversy about what would happen with a backup controlled by the DATE>= modified date parameter, with a well-known expert claiming that STORE (with the implied FULLDB option) would store the entire database. Tom Burger reported that on MPE/iX 6.5, only the root file gets stored and, in fact, STORE displays the following message (from an example): /AMISYS/DATA/ACCTNG STORED BECAUSE ONLY ROOT FILE QUALIFIED FOR DATE OPTION The thread died at that point, but the question about how pre-6.5 systems would behave continued to concern me. I recently tested the situation on a 6.0 PowerPatch 1 system (and, by the way, PowerPatch 1 does not contain any patches that appear to address this situation). I obtained the same results as Tom Burger. So, I think I can safely say that as long as you are on one of the two currently supported versions of the OS (MPE/iX 6.0 and MPE/iX 6.5), your incremental STOREs will behave as expected. This, even though the behavior of TurboIMAGE mode 5 on the root file is somewhat counter-intuitive. Tracert: Here one day, gone the next. And here again? Adding tracert to the MPE/iX network toolbox has been something of a long-running soap opera. Many people have been requesting it for years, and we even had it for awhile, but it was withdrawn because of problems in FDDI and token ring networks. The good news is tracert is back in the form of beta patches for MPE/iX 6.0 (NSTFDX4A) and MPE/iX 6.5 (NSTFDX5A). The SR reference is 5003-442715. So, what is tracert? From James Hofmeister, of the Hewlett-Packard Worldwide Technology Network Expert Center: Tracert is a tool which traces the route of IP traffic through intermediate routers and system network interfaces (IP level devices), identifying the full IP path traveled from the source to the destination system. The way this is done with this version of the tracert tool is a packet is sent to the destination system with a Time-To-Live (TTL) of 1 and then the tracert waits for the next IP level system in-line to reply with a ICMP message specifying TTL exceeded. Tracert then increases the TTL by 1 and resends the same packet, tracking the new IP address reached at each step until the destination system or the max number of hops is reached. Here is a sample run of tracert on a right-coast HP e3000 to a left-coast HPUX system. :tracert.prvxl.telesup
Enter Host Name or IP
addr[Press Return to exit]:wtec.cup.hp.com In this example you can see that seven IP gateways/routers exist between my local MPE system and the destination system wtec.cup.hp.com. Note: The 172.17.192.49 address does not include a node name since this IP address is not configured in a Domain Name Server. I verified this by using nslookup:
:nslookup 172.17.192.49 *** l3107ns1.ssr.hp.com cant find 172.17.192.49: Non-existent host/domain Note: If you are going to run tracert between two MPE machines it is necessary to install the appropriate tracert patch on both the local and remote MPE machines. If you tracert to a remote MPE system which does not include the tracert patch you will get a good tracert of all of the intermediate IP gateways/routers, but you will get a * * when you reach the destination MPE system and you will need to CNTRL-Y to terminate tracert. Donna Garverick gave some not entirely tongue-in-cheek practical advice on the use of tracert: Picture this. For some reason system <x> cant reach system <y> and one of these systems is your MPE/iX box. Your network engineer looks down his/her nose at you and sneers one of two things: What, you cant tracert? or Obviously its the MPE system. tracert has the potential of shortening maddening arguments such as this (See. Its not even reaching the router!). And it may even make life easier for you. Jeff Kell cautioned: I should point out that failure to ping/tracert does not necessarily imply a failure. Many sites these days are blocking ICMP messages for security purposes (which kills ping for obvious reasons, and tracert because the ICMP unreachable replies are blocked). So, failure of ping/tracert does not equal a network problem. Success of ping/tracert does equal a healthy network. Put betas to work, if you can One final note this month. The two tracert patches above are both beta patches, and have been for a while. HP has a very careful and cautious approach about qualifying patches for General Release (GR). And well they should have. But this means that we all have to help by testing as many of these patches as possible, especially those that add functionality. For example, as I write this, the MPE/iX store-to-disk patch for FOS on MPE/iX 6.5 has not yet gone GR, because not enough people have tried it. I am not suggesting you should run out and get every beta patch around and apply each to your production system. I believe in applying beta patches to a production system only if it is to correct a problem youve seen or could see. But, if you have a development system, or, even better, a crash-and-burn system, then why not help out the community as a whole by testing these beta patches? Certainly in the past, many of us resisted this because a beta patch must usually be backed out and the GR version applied. With tape as the only option, this was a long and sometimes painful process. However, these days, most patches are stageable and staging a patch makes applying it and, especially, backing it out, as simple as a SHUTDOWN START NORECOVERY. John Burke is the editor of the NewsWires HiddenValue and net.digest columns and has more than 20 years experience managing HP 3000s. Copyright The 3000 NewsWire. All rights reserved. |