Click here for RAC Consulting Sponsor Message

net.digest

Analysis by John Burke

It's No Great Leap of Faith
The year 2000 IS a leap year. But not for the same reason that 1996 is a leap year. Pope Gregory's leap year rule: all years that are even multiples of 4 have an extra day (February 29) except for years evenly divisible by 100 but not evenly divisible by 400. Thus 2000 is a leap year because it is evenly divisible by 400, but 1900 was not a leap year even though it is evenly divisible by 4.

Several people contributed interesting historical information on various calendar schemes. As I was compiling this, I received my November issue of Scientific American and found that the Mathematical Recreations section contained a discussion of this very topic titled "A Guide to Computer Dating". (As of this writing, Scientific American's web site does not include this section; however, if you do not have easy access to the magazine itself, you can give their web site a try at http://www.sciam.com/) The article is based upon the book Calendrical Calculations (Cambridge University Press, 1996; paperback version ISBN 0-521-56474-3) by Nachum Dershowitz and Edward Reingold who developed the calendar and diary features for the GNU Emacs editor. In the book they discuss their method for converting dates between any of 14 calendar systems. The Scientific American article presents, among other things, their algorithm for determining the day of the week for any date in the Gregorian calendar [See Hidde nValue for a HP 3000 command file that does the same thing].

Early Returns on MPE/iX 5.5
Someone commented that he was interested in the new features of MPE/iX 5.5 but was leery of updating until at least the first PowerPatch was available. So, the question was: When will there be a PowerPatch tape for MPE/iX 5.5. The reply from the response center:

"Well, there will be a Powerpatch (C.55.01) made available early next month [ed. note: November], but this Powerpatch mostly contains support for new hardware devices and does not include any bug fixes. Quite frankly, there hasn't been a significant accumulation of bug fixes for 5.5, simply because there hasn't been a significant accumulation of bug reports against 5.5. Because of this, I don't think there will be a bug fix laden Powerpatch until early next calendar year. Perhaps you'd be better served by asking the early 5.5 adopters what they think of the release's reliability & quality?"

"When I go into NMMGR and validate DTS, everything is fine until the end when, in a new prompt, I am asked if I want to make the changes effective immediately or later. Whether I reply 'Y', 'y', 'N', 'n', 'H', or 'h' it just locks up on me. If I break and abort, it still just sits there. My only option is to abort my session from another terminal. Any clues?"

"This is definitely a 5.5 bug. There's already a S/R for it. It will only happen if you are connecting via a networked PC (ns/vt). A workaround is to use a serial terminal or PC for you nmmgr configs until a patch comes out."

"A few caveats (well, bugs and features, depending on what you want) when you use IOCONFIG:

• " If your last START wasn't a NORECOVERY, your configuration changes will not be saved (it can't write to the BOOTUP group) and you'll get an ominous-looking tombstone when you try to exit.
• " Whether it succeeds in saving the configs or not, you still have your changes for the duration of the current IPL
• " If you definitely intend to save all your changes, be sure your last start was a start norecovery."

"The whole process went fairly well. The one-inch thick installation manual seemed overall better than the past documentation, but there are several typo's that I ran into. All were benign, but the bit on setting up the TAR utility on page 6-15 took me a couple minutes to figure out. In true MPE fashion, they intermix upper and lowercase at will. In step 2, the instructions say:

:MKNOD "/DEV/TAPE c 0 n"

and then go on to explain the parameters. They have following that: ' /dev/tape - The device link filename '

"Overall, I'm pleased. I setup the Network Printing for my Laserjet IIIP using a JetDirect EX Plus print server without a hitch. So far, I'll give it an 'A'. Cleaner documentation would have pushed it up to 'A+'. Now over the next couple weeks/months, I'll push things and see what pops."

An annoying problem, at least for me, the spooler starts generating the following message at the console every time you print something:

"The last name component of the pathname does not exist in the directory. HP Directory message 1"

MPE/iX's "VUF". Version UnFathomable?
This is one of those issues that keeps coming up like bad seafood. In this case, someone questioned what was meant by the change in the version ID of the VUF from "B" to "C". From HP's Software Service and Support Organization came this explanation:

"OK, there seems to have been some confusion about the numbering conventions used for MPE/iX releases. I will try to sort things out. Maybe CSY folks on the list have more ideas, but let's get down with a starter.

"First, the RELEASE v.u.f has been different from the MPE/iX v.u.f for some years, now. You can view MPE/iX as being only a component of the whole release .

"Second, there's been a numbering convention, also for some years, that mandates a x.0 number for PUSH (Platform) releases, and something different for PULL releases. That's why we had 4.0 and 5.0 as PUSH releases and 4.5 and 5.5 as PULL releases. If we get deeper in the past, we will begin to find different conventions .

"Third, the first letter of the RELEASE v.u.f (not the MPE/iX v.u.f!) has been used to designate major rewrites of the OS. A was for the 'first-generation' OS, B was used for multiprocessor- capable releases and now we have C for POSIX-compliant releases. Conventional wisdom would mandate that this convention be used for both the RELEASE and the MPE/iX v.u.fs, but, for POSIX, MPE/iX has taken some time to catch up with the release v.u.f. That's why 5.0 has a release v.u.f of C.50.00 but an MPE/iX v.u.f of B.79.06 .

"Fourth, the 'commercial' denomination for a given release is carried by the release v.u.f, not by the MPE/iX v.u.f. The MPE/iX v.u.f is simply the number used by the lab to build the OS. It has no meaningful value outside the lab. More to the point, we use the 'u' part of the release v.u.f to carry the release name. As an example, let's remember that 4.0 was release B.40.00. The 'u' part of the v.u.f is 40, you just insert a period, and there you go ... 4.0! You have the same with B.30.00 for 3.0, B.31.00 for 3.1, C.45.00 for 4.5, C.50.00 for 5.0 and now C.55.00 for 5.5. If no major rewrite occurs, 6.0 should be C.60.00 when it comes out.

"The following table should make things clearer ... well, hopefully:

"OK, that was my two cents worth about release naming and numbering conventions currently used for MPE/iX. Maybe CSY people on the list can add other ideas."

"... a very good thesis about our release and OS V.UU.FF numbering conventions.

"Speaking personally,

• " The Release V.UU.FF should be of interest to customers. Basically, releases should sort appropriately. An earlier release would be sorted before a later release. And, you should be able to get an indication from the V.UU.FF about which release is which. For example, C.55.03 would be 5.5 Express 3 (or 5.5 Powerpatch 3).

• " OS V.UU.FFs are internal names. Other than the fact that the V.UU.FFs would sort, these V.UU.FFs should have no meaning to customers. We basically use the OS V.UU.FFs to isolate the presence of a bug and/or its fix.

"And (again speaking personally), I don't understand why customers are interested in the 'meanings' of the V.UU.FFs. There really aren't any hidden 'meanings.' We just use the V.UU.FFs to track the different versions of our software, so that we can support you better. Can someone enlighten me?"

"By the way: WHICH VUFs are you wondering about, the 'Release VUF' or the "MPE/iX VUF" of :SHOWME?) We need to know for a variety of reasons!

"A user says 'I'm having a problem with the XXX program', and we ask him what release he/she is on...to help determine if the problem is a known MPE bug/feature/whatever. How does the user determine this?

"Here's one of those VUFs that was quoted for an older release:

Commercial release name: 4.0, Release v.u.f: B.40.00, MPE/iX v.u.f :B.30.45.

"So, the user does a ':SHOWME'...WHICH VUF does he/she use? The one that implies 4.0 (B.40.00), 3.0 (B.30.45), 4.5 (B.30.45)? Yes...*WE* know that *now* the "Release VUF" is the one to look at, in the middle.

"Back to that user... what else can he/she look at to determine the system release number? If they're like me, they can't find their FOS tape, but they pickup their SUBSYS tape. It has a number of 'versions' on it: MPEix (spelled without the '/') 5.0, X.50.15, Date code 3404.

"Or, WORSE YET, how about my 4.0 SUBSYS tape... it says:

MPE XL 4.0 vuf B.40.02 <---- "02"?

"I can only assume there was a quiet rev of 4.0 between Christian's B.40.00 and the tape we received of B.40.02. What's different? Does it affect the user's problem?

"A number of vendors, and other software authors, need to know what version of MPE their software is running on. And, since the release of MPE XL there's really been only one reliable indicator: which corresponds to the 'MPE/iX' VUF in a :SHOWME command. (By the way, that's also the number/phrase you need to do dump analysis of your own machine.)

"So, the 'meaning' of a VUF includes: What release of MPE am I on and what patch level of MPE am I on (if this even shows up!)

"Some of the bug reports that I've found on HPSL say that something is fixed in a particular VUF ... which doesn't provide much information if I don't know if that's a 'release VUF' or an 'MPE/iX VUF'.

"This isn't a terribly difficult problem to solve. I've proposed naming solutions before, and other people probably have too."

Back in September we quoted Ken Paul's excellent explanation of IMAGE prefetch thinking it would be the final word on the subject. Silly me. There is no such thing as a final word on any subject where 3000-L is concerned. (Ed. note: Indeed, we already have run other comments on the subject in our Online Extra edition covering that issue.)

Robelle, in their newsletter, noted:

"... it was recommended that all IMAGE/SQL databases should have prefetch enabled by using Dbutil. This option can increase performance by up to 35 percent. One older version of IMAGE/SQL on MPE/iX 4.0 has a bug in this feature, but unfortunately we don't have any notes on the specifics. We can, however, recommend it to all MPE/iX 5.0 users."

"Our own Adager investigations have not yielded more than 5 percent to 10 percent improvement. And we could not get more concrete details from Robelle regarding the 35 percent. Nevertheless, assuming that a 5 percent to 10 percent is better than nothing...., I have added the necessary logic to Adager to automatically enable prefetch for all Adager- transformed databases IF you are on MPE/iX 5.0 or later."

"This morning I turned on the PREFETCH attribute to see what positive effects we might experience since the sentiment seems to be no negative effects. The issue would seem to need further examination it seems to me. Environment: 3000/957 c 384MB memory and ~100 users. While there have been no noticeable negative database effects, the users have noted a 'jerky' screen painting that seems new as of today. Five to eight screen lines will post from the database, a pause, then the balance of five to eight will post. I'll run this way today and turn off the feature tomorrow for a bit more 'empirical' testing. While the overall effect may be positive, the appearance to the user (due to that mid-screen pause) is that there has been a deterioration of response time."

"It has been a while since I have done any benchmarking, but as I recall from my earlier tests and from discussions with IMAGE lab folks, this [automatically enabling prefetch] would not be a good idea. I believe that the benefits accrue for fast machines with a lot of concurrent PUTs, DELETEs, and UPDATEs to specific data sets and little or no memory pressure. The internal lock is held for a shorter time, permitting the additional concurrency. For slower machines without this type of demand, no benefit will be seen, or possibly even a degradation, since some data will have to be fetched twice, if it gets swapped out before it is needed."

"After recommending that you enable IMAGE prefetch in our last newsletter, we discovered that some versions of MPE/iX had some problems. One of our customers was getting "CORRUPT DBG DISABLED; POTENTIAL DAMAGE; ONLY DBCLOSE ALLOWED" messages. Pretty scary! HP said the messages were bogus and advised the customer to disable IMAGE prefetch. When this was done, the problem went away.

"The message 'DBG DISABLED; POTENTIAL DAMAGE; ONLY DBCLOSE ALLOWED' should never be treated as a bogus message. However, in the cases we've seen, where a DBPUT fails AND the database is enabled for PREFETCH, if the following is displayed we have not seen any corruption in the database.:

ABORT:  DBPUT    ON DATABASE dbname.group.acct;
TURBOIMAGE/XL ABORTS ON DBB CONTROL BLOCK
ESCAPE FROM TURBOIMAGE/XL; PC:    CODE: $ffdb006b.
STACK MARKER TRACE:
       PC=5fc.0062eb48
XL.PUB.SYS/dump'process'environment_278+$64
NM* 0) SP=41847f60 RP=5fc.0062f388 ti'dbdumpxds+$294
       DP=41668000 PSP=41847eb8 PCPRIV=0
NM  1) SP=41847eb8 RP=5fc.00604c60 dbput+$1d0
       DP=41668000 PSP=41847cb0 PCPRIV=0
NM  2) SP=41847cb0 RP=5fc.00604a6c ?dbput+$8
       DP=41668000 PSP=41847bb0 PCPRIV=0
         export stub: 213c.000de6a4

"However, something went wrong that resulted in the DBG (or DBB) being disabled. This is serious, as the only way to resolve a DBG/DBB disabling, is to get everyone out of the database. After which the control blocks are purged with the last DBCLOSE.

"At the risk of opening a can of worms, the above abort and stack trace can be seen on TurboIMAGE versions C.05.xx and C.06.xx, when PREFETCH is enabled. The resolution, in all cases, is to disable PREFETCH. Does PREFETCH have a bug in it? We don't know for sure. But we have found that one site had a corrupted buffer address, which was used by PREFETCH. We are very actively pursuing this problem.

"I have personally only heard of one site, that when they disabled PREFETCH, saw their application's performance severely impacted. Most people don't seem to notice a difference whether it's enabled or disabled. :-(

"I would like to suggest, that if you are going to use PREFETCH, that you also enable your database for Dumping. This can be done via DBUTIL and by issuing the following command: ENABLE dbname FOR DUMPING. There is no incurred overhead when running with this option enabled. In fact, it probably would be a good idea to always have it enabled. When an IMAGE update intrinsic (DBPUT, DBUPDATE, DBDELETE) aborts, an I and J file will be created. We can then look at these two privileged files and see what happened, hopefully."

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