How to: Logical multi-database transactions

As HP 3000s move into the larger world of HMOs and direct mail firms, it’s 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

DBXBEGIN( base1, ... )
DBXBEGIN( base2, ... )

DBXEND ( base2, ... )
DBXEND ( base1, ... )


But like the manual said, you risk a logical inconsistency in the data if there’s 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 doesn’t 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:

[DBUNLOCK]
[DBXUNDO]

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 3000’s heritage got a couple of great pointers at first hand reports of the system’s 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). HP’s 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 day’s the last?

At times the 3000 newsgroup is a programmer’s 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 Newton’s 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 Vesoft’s 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:

%setvar tomorrow (today+1)

%IF STR(“!tomorrow”,7,2) = “01” THEN
Echo Today is the last day of the month!!
%ENDIF

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, IF HPDATE=![WORD(“31 28 31 30 31 30 31 31 30 31 30 31”,,HPMONTH)] will do it, and for catching leap day, IF !HPDATE = 29 AND !HPMONTH = 2 AND !HPYEAR MOD 4 = 0 will fail on the first element except for 28 days of the year, so either test, date or month, can go first. Of course, if the first two elements are true, there’s not much point in testing the third. There is more than one way to put these two together to efficiently test both, depending on what you want to do if it is the last day of the month.”

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 that’s over 100 years from now - I’ll certainly be retired by then!’ To which I reply, ‘True, but we’re talking HP 3000s here. More than likely they’ll still be running!’ ”

Phillips expressed gratitude for the solutions, then asked a question that will likely show up as an MPE/iX enhancement. “Why can’t HP supply me with a system variable (like HPEOMDAY) that would be automagically set to the last day of the current month?”

How to check your patches

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 I’m half-blind. Has something changed?” HP’s 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 HP’s information. “Two rules to remember:
1) Although Patch/iX will update both PMSWINFO and HPSWINFO, Autopat and Autoinst will only update HPSWINFO.

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 3000’s DTCs came up on the newsgroup. In converting DTC 48s to unshielded twisted pair (UTP) wiring, Steve Barrett said of the DTC manual, “I’m just a little concerned that they refer to the AUI port as a ThickLAN port. I’m 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, that’s exactly what I did with several DTC 48’s a couple years ago to convert them from 10-Base-2 to 10-Base-T.” A deeper explanation of the manual’s 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.”