|Click here for SW Consulting Sponsor site|
|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.
How to: Logical multi-database transactions
As HP 3000s move into the larger world of HMOs and direct mail firms, its logical for transactions to need to reach into several databases on a single pass. You could find tips on the Internet for making such dynamic transactions (DBXBegin/DBXEnd/DBXUndo) work over multiple databases. Glenn Cole replied, Several years ago, the DBX@ calls were greatly hampered by DBUPDATE. I would try an update and check the return status. If it indicated a search or sort item changed, I would delete and add. Unfortunately, if this occurred in a dynamic transaction, all subsequent operations FAILED saying that only DBXUNDO was allowed. I understand that this behavior has since changed.
Bottom line: Sure, you can use
But like the manual said, you risk a logical inconsistency in the data if theres a system failure between the DBXENDs.
There was also advice on the relative sequence of [DBXBEGIN]/[DBLOCK]. Steve Dirickson noted that the lock/unlock must be done outside the dynamic transaction. Check the DBUNLOCK error code table in the manual for status -230. Or the section Locking and Dynamic Transactions in Chapter 7. Or the section Strong Locking and Dynamic Transactions in Chapter 4.
Conditional locking is great when the sequence of locks supports it. Since IMAGE doesnt support incremental DBUNLOCK, you have to be able to re-start the entire lock-setup sequence anywhere in the sequence.
And rolling back one of these mega transactions with a simple sequence of:
is enough, according to Dirickson. Do not be clever; the whole point of dynamic transactions is that the DBM/XM magically fix everything if something goes awry, or if you simply change your mind part way through the modification sequence.
Finally, John Zoltak reported that I use unconditional locks most of the time. Either way the user is going to have to wait. You may as well get into the queue now instead of polling.
The DBXBEGIN can occur before or after the DBLOCK, but the DBUNLOCK must occur after the DBXEND/DBXUNDO (IMAGE manual page 7-11). When I started using dynamic transactions I found that the DBUNLOCK had to be after the transaction so I just figured that the DBLOCK had to be before the start of the transaction.
As a note, I use this scheme to do shop order part issues which involves many transactions. When I find later that some part cannot be issued, I can undo the whole transaction. It works very nice.
A great link to history
History buffs of the 3000s heritage got a couple of great pointers at first hand reports of the systems early years. Glenn J. Koster reported that you could browse to Web pages hosted at Robelle (www.robelle.com/libr ary/smugbook/classic.html) and 3k Associates, which hosts a paper written by an HP employee about the earliest years of software and hardware development (www.3kassociates.com/papers/hp3000_his tory.html). HPs own history of the transition from CISC to RISC computing though not exclusive to the HP 3000 is in a slide show at www.ses.hp.com/dtf/bk gnd/mpfnotes/sld001.htm
What days the last?
At times the 3000 newsgroup is a programmers club, especially when someone asks how to perform a function common to many businesses running HP 3000s. Such was the case when Jim Phillips asked Is there an easy way to determine if today is the last day of the current month? Answers were in abundance.
Ernie Newtons was most direct: If you can check the day number, then with one IF statement you could check to see if tomorrow < today. If it is, then today is the last day. John Zoltak offered, If you can add one day to the target date, you can see if the month changes. Then you know that you have the last day of the month. John Hornberger suggested pressing Vesofts MPEX into the quest. Try checking to see if tomorrow is the first of some month, he said. Then today has to be the last day of the current month. For example, using MPEX, do the following:
Stepping further into
programming examples, Greg Stigers turned to the HP date intrinsics.
I had a lot of help with this from Lars Appel, Jeff Vance, and Tim
Ericson, so they deserve the credit for me being able to put this together.
But except for leap months,
MPE architect Craig Fairchild put a note on the solution from Stigers that showed how 3000 programmers have to think ahead. He said, Note, however, that this algorithm will fail on February 28, 2100 (not a leap year), assuming that the two conditions above are constructed together to remove February 28 of each leap year from consideration as the last day of the month.
Of course, I hear the snickers now. Yeah, but thats over 100 years from now - Ill certainly be retired by then! To which I reply, True, but were talking HP 3000s here. More than likely theyll still be running!
Phillips expressed gratitude for
the solutions, then asked a question that will likely show up as an MPE/iX
enhancement. Why cant HP supply me with a system variable (like
HPEOMDAY) that would be automagically set to the last day of the current
In all the discussion of PowerPatches during the last month and finding out which ones you might have installed that contain trouble a short thread outlined how to check patches. There used to be a file out in pub.sys which AUTOPAT appended to every time I added a patch. Either the file is gone, or Im half-blind. Has something changed? HPs Scott McClellan, keeper of the Patch/iX utility, rode to the rescue with this summary:
Two files inventory patches. The first one, and the one you probably remember, is HPSWINFO.PUB.SYS. This is just a plain old ASCII file and it can be printed using the PRINT command.
Unfortunately (or maybe fortunately) it can also be edited with a standard editor, and deleted or overwritten quite easily (e.g. by sloppy back up/recovery procedures)
For this reason (in part) a new SW inventory file was created and is updated/trusted by Patch/iX. The other file is called PMSWINFO.INSTALL.SYS and it should be accurate provided you use Patch/iX exclusively to apply patches. Given this is not always the case (no comments from the peanut gallery) the two files are probably most accurate when viewed as an aggregate. Patch/iX will update both HPSWINFO and PMSWINFO.
PMSWINFO can only be viewed easily by using Patch/iX (under View Patches) and by using Stage/iX in cases where Patch/iX patches were staged (using the STAGEMAN list xxx;patches command).
Michael Hurdle summarized to
polish up HPs information. Two rules to remember:
2) Patch/iX does not recognize the HPSWINFO file when attempting to determine if patch dependencies have been met.
So you really have three choices: a) Use Patch/iX all the time and rely solely on PMSWINFO, b) never use Patch/iX and rely solely on HPSWINFO or c) use both tools interchangeably, rely both on HPSWINFO and PMSWINFO and expect to have a lot of patches that should qualify under Patch/iX not qualify.
DTCs: from ThinLAN to UTP
Networks are getting upgraded on HP 3000 all the time, and the nuances of wiring the 3000s DTCs came up on the newsgroup. In converting DTC 48s to unshielded twisted pair (UTP) wiring, Steve Barrett said of the DTC manual, Im just a little concerned that they refer to the AUI port as a ThickLAN port. Im probably wrong, but I always thought ThickLAN was just another type of coax (RG59 or some such). Can I move the jumper on the processor board to the ThickLAN position and attach a UTP Transceiver?
John Schick said Yes, thats exactly what I did with several DTC 48s a couple years ago to convert them from 10-Base-2 to 10-Base-T. A deeper explanation of the manuals naming came from Mike Hornsby, who explained The ThickLAN MAU required an AUI port. It had an AUI to AUI cable that jumpered to it. For a while, every new MPE/IX box shipped with both the thin and thick MAU. The thick MAU is a long thin black box that attached with a viper tap to the LAN cable. The AUI port works fine with those little AUI to UTP transceivers.
Copyright 1998, The 3000 NewsWire. All rights reserved.