net.digest

Help, I just updated my OS and can't get my utilities up!
You've just updated your OS and a utility you depend upon stops working. What do you do? One system manager queried HP3000-L recently when ALLOWME stopped working:

"ALLOWME now complains with the error message :
Operating system revision level incompatibility
This program not checked out for new revlevel"

This is one of those difficult to plan for "gotchas" that can make your life miserable after an OS update. Someone helpfully pointed out that given what ALLOWME does, it should probably work on 5.0:

"ALLOWME functions by changing the ALLOW mask in the JIT (Job Information Table). The JIT has not changed from 4.0 to 5.0 and neither has the pointer to the JIT DST. This pointer is in the PCBX portion of the CM stack. It sounds like you have a very good, though not particularly convenient, version of a PM program which recognizes that it should not run on a version of the OS which did not exist when it was written."

The version of ALLOWME the poster was trying to use came from the TECHXL account of the Interex Contributed Software Library (CSL) and the answer to the poster's dilemma came the same day:

"You need to run the program REFEREE (from the TECHXL account) to change the rev level of ALLOWME with the CHANGE command, as follows:

:referee.pub.techxl CH ALLOWME;VUF=C.50"

The Case of the Missing Manuals
Someone who asked a question on creating TERMTYPE files was pointed to the utility TTUTIL with the comment:

"TTUTIL is documented in: Customizing Terminal and Printer Type Files With the Workstation Configurator (5959-2870). This manual, unfortunately, is not included on LaserRom."

To which someone added:

"Another significant 'missing' [and useful] manual is the MPE/iX Shell and Utilities User's Guide. I don't have a complete list, but I have had to order several paper manuals...".

"I used to think the 'missing' manuals were for add-on products, but the manuals I mention here are for products that come with every system!"

Then, probably echoing the thoughts of many:

"um.... I thought all the manuals were on the LaserROM? Anybody want to comment on this?"

An interesting comment came from one of the listers who has done much work with the Posix shell:

"There are several exceptions. Besides the above, I know of the Serial Device and Printer Configuration manual (not exact title), the newer Image/SQL and ODBC manuals (that might have changed), and most all of the Posix manuals are absent. Arguably the Posix reference manuals are simply the man pages, but that gets into the Unix mindset where 'RTFM' which we all know as 'Read The Fine Manual' (Okay, the third word isn't quite right) becomes RTFMP (Read The Fine Man Page). If there's anything more annoying than a RFTM answer, it's a RFTMP answer :-)

"For the Unix virgins reading the above, Unix 'man' equates to MPE ':help', but even worse. You have to know what you're looking for ahead of time, there's no index, or table of contents, or subtopics, or otherwise. (Okay, yeah, there is the whatis file...)

"There is one 'good' manual on Posix -- the Posix Shell and Utilities User's Guide -- but it's not on the CD either."

This has been one of my pet peeves since I acquired documentation on LaserROM several years ago. I understand why, for example, the AIF manuals are not included, but the ones pointed out above? Makes no sense. Maybe we can get a response from HP-- I'll look into it for next month.

Best of the best
Larry Boyd, formerly of Bradmark and now of HP wrote:

"I am looking to create a list of 'Best Practices for the 3000'. Many of you actually have some. I would like to put this list together and provide it to anyone who asks. It would be freely distributed, with no copyright.

"If you have a 'best practice,' please send me a private e-mail (lboyd@cup.hp.com) and let me know if I can include your name and/or company name on the list.

"You don't have to be a large site, nor do you need 10,000 years of experience in IT. Some ideas for subject areas are:

OS Installation/Updates/Patches, Backup/Recovery/Disasters, Application development, design or coding (including source code change management), Spool file management, Hardware/Software support management, Operations management, Systems management, General Database management and IMAGE management.

"I believe that just about everyone on this list would like to see the results, because just about every customer I support now (or have in the past) is interested in this list. I can't do it alone and I need your help. I would prefer to have a short paragraph, instead of just a one line suggestion. What is the 'practice' and what's your justification for doing this?"

Several days later, Larry commented:

"BTW, I think I have received more requests for the list than best practices. I was afraid this would happen. Everyone wants to know what the other guy is doing, and we forget to share our own ideas."

Okay, Larry, I guess I'm guilty too. I think what Larry is trying to do is a great idea, and I plan to contribute some 'practices.' I will, I will. It just may take me a while to get things on 'paper.' I encourage everyone to contribute.

Aaargh, the console message scrolled out of screen memory!

"We currently print all console messages from our HP 3000 to Epson printers through the 'Log Bottom' soft key. We need these console messages when researching problems or answering questions, or for monitoring other problems. We keep them for several weeks.

"I am looking for other solutions (hardware and/or software) to be able to save console messages to a file. Our system consoles are the HP 700/9x types, which do not have disk drives.

"Are there other technologies/products available out there that can save console messages to a file?"

The first response was

"And the solution is: VESOFT's MPEX and VEAUDIT. CONSOLE messages are already stored in your system log files, if turned on. The combination of MPEX and VEAUDIT gives you a new command: VEAUDIT LISTLOG CONSOLE which lists the content of all CONSOLE logs. "

The same person continued:

"...HP provides utilities that let you look at log files, but the format is barely usable for this type of analysis. For CONSOLE messages specifically, however, it is relatively trivial to write a program to read the log files and extract/format/print just these log events. (Relatively trivial to, say, brain surgery... :)"

Another suggestion:

"Run your log bottom output into the serial port of a PC and capture it to a file on the PC." Also, use a PC with a terminal emulator as the console and LOG BOTTOM to a file.

Another variation:

"You might continue using LOG BOTTOM but plug the console printer port wire into a (yet) unused DTC port and write a small program to read that LDEV to collect the console message copies."

: "...review the console logs with LOGTOOL inside SYSDIAG and 'export' them to a text file...

"In LOGTOOL use STATUS DETAIL to get a list of the available logfiles and the date and time of their first records. Pick the interesting logfiles. Use LIST LOG=mm/nn TYPE=115 OUTFILE=myfile DATE TIME to extract the 115 type events (console messages) from logfiles mm through nn and redirect the output to MYFILE.DIAG.SYS instead of terminal. DATE and TIME give you a prompt to narrow down the interesting range. (See HELP LIST for details)

"The contents of MYFILE will contain quite a lot of information. I usually extract the most interesting part (the messages like they once appeared on the console) with :FCOPY FROM=myfile.DIAG.SYS;TO;SUBSET='(OUTPUT)'."

"Several good ideas have been presented on this thread. But so far I haven't seen any reference to the numerous good programs in the Contributed Library for doing exactly this. We make continuous use of ALFRED for exactly this purpose."

Ah, but then a word or two of warning:

"The system logfiles don't provide all messages. Even CONMSG doesn't provide every boot message. The best examples are the transaction manager recovery messages. The recovery can fail, (the volume set is read only), and the only indication is a console message that rolls off and is not logged.

"I highly suggest having a printer slaved to the console for boot up processing. Many system hangs and aborts result from disc related problems. The worst indication usually comes at boot time when a volume is unavailable for mounting. In the old days the "mount correct volumes or reload" message usually meant a disc had crashed. Today you could lose a disc and not be aware of it until much later."

Finally, in response to the suggestion about plugging the console printer port into an unused DTC port and writing a small program to read the LDEV and write a copy of the messages to disk, it was suggested that a program was not needed, that FCOPY would do the job just fine.

Hmmmm. Seems like a lot of material here for Larry Boyd's Best Practices.

SCSI as LDEV1? SCSI want to.
The following started an interesting thread that may not be completed:

"I had an interesting discussion today with a customer who is starting to worry about LDEV1 disk space requirements exceeding 670Mb. His contention is that some of his systems (he manages multiple ones) cannot use SCSI disks as LDEV1 so he is limited to 670Mb (without HP-FL). Once MPE/iX exceeds that limit, he can't upgrade to the latest OS version.

"If this is a true, what systems would be affected? I can guess systems like: 920, 922, 925, 935, 948, 958. Are there others, and is this list correct?"

Part of the question seemed to be answered by this post:

"We have a 958 and it is true that these boxes (and probably the others you listed as well) cannot use a SCSI device as LDEV1, but we have also gotten assurance from HP that both 5.0 and 5.5 versions of MPE/iX will consume less then 670Mb of LDEV1 space. I haven't heard anything about releases beyond 5.5 yet."

So, we seem to be okay for the time being with the largest HP-IB drives (670Mb) as LDEV1. But what about SCSI as LDEV1? The following post provides at least a partial answer:

"A 935 and 925 can supposedly boot from SCSI, but only if:

"1. You have a SCSI controller (of course). These are available for relatively low prices remarketd (and, possibly, from HP?)

"2. Your computer's IODC firmware is at least revision 6 or later.

"Number 2 is the show stopper...if you have old firmware (like we do), you CAN'T order a new firmware chip and install it yourself. And I have serious doubts whether or not HP can/will actually do it for you for a fee.

"If you are interested in updating your 925/935 (or 825/835) firmware, here's the info I have, which came from HPSL Document Id A1802251 (HPSL Date Loaded: 08-01-91): "A1756A IODC Firmware Upgrade Kit (Must order w/processor opt.)

Opt. 420 825 w/CIO Expander option

Opt. 421 835S/SE, 635SV, Base 825S Processor option

Opt. 423 850/55/60/65/70 Processor option

"We have a 3000/935, not on support, which we wanted to upgrade. Earlier this year, it took me about three months of sporadic phone calls to/from HP people across the U.S. to get to the point were HP said: 'We don't know if we even have the chip in stock, but if you want it, you'll have to pay about $650 in travel time and labor and an unknown amount for the chip itself'; or, we could send in our 935 CPU board, and $850, for a board-swap replacement ... but HP couldn't affirm that the new board would really have the modern firmware. So, we gave up."

In response to the firmware post came: "This rings a bell, as we had to go through a similar song and dance. The firmware goes into the channel adapter (on a 9x0 machine) and is only needed for the CA in the boot path. When you upgrade this firmware, you also have to update firmware in the HP-IB cards on that CA as well. The former we did purchase as a 'firmware upgrade kit' (actually a board swap) and the latter was covered under hardware support. Delivery time on the CA firmware upgrade was quoted as 90 days and was actually much longer."

In referring to an earlier post,

"Those boxes can't do SCSI? I thought this thread was going to refer to the 950/955/960/980 original CIO machines. We are running SCSI on a 950 and 960 (the 960 has two channels). We still have HP-IB discs but only two Coyotes are really being used for 'important stuff'."

Then out of left field came this claim:

"We have a 932 that currently has a SCSI drive as LDEV 1. It's not a fast/wide SCSI though...we are running 5.0."

Finally, several days later came:

"We have a 958 and it is true that these boxes (and probably the others you listed as well) cannot use a SCSI device as LDEV 1 ... Those boxes can't do SCSI?

"Sure they can, just not as LDEV 1. All of the disks on our 958 are SCSI except for LDEV1 and 2 which are HP-IB (2203's)."

So, the second part of the question appears to still be up for grabs. To wit: Are there any 9xx systems that cannot have a SCSI disk as LDEV 1?

Watch this space.

Corrections & Clarifications (& Stuff)
Regarding our section covering "How Do You FTP PRIV Files?" in the June net.digest, Fred White (who, for those who do not already know, was one of the original developers of IMAGE before joining Adager Corp. many years ago) took mild exception to my comment that assigning negative file codes to IMAGE database files has caused problems for many years. Fred wanted to point out (correctly, I might add) that using negative file codes has also prevented many problems from occurring in the first place. Imagine, for instance, if you could PURGE an IMAGE file the same way you can PURGE any standard MPE file?

Fred also pointed out the need for some clarification on comments in the "Where, Oh Where, Has My Free Space Gone" section. Adager (Adager Corp.) and DBGeneral (Bradmark) will only move IMAGE dataset files to specific LDEVs, MPEX (VeSoft) will move filesets and DeFrag/X (Lund) and Disc Space Manager (Bradmark) are more general managers of disk storage.

Exercise for the reader (the answer is not known yet, but Adager is investigating): what impact, positive or otherwise, does the Symbolic Link feature of the Posix interface have on IMAGE and Allbase databases? Bonus question: is there any way to determine if a particular file is the subject of a symbolic link?

Copyright 1996, The 3000 NewsWire. All rights reserved.