Hidden Value December 2000

SolutionSoft Sponsor Message

Hidden Value details commands and procedures in MPE that can improve your productivity with HP 3000 systems. Get a free NewsWire HP 3000 cap — submit your tip directly to us here at the NewsWire. Send your tips to editor@3000newswire.com, or fax them to 512.331.3807.

Edited by John Burke

Does adding an additional processor to a box result in a new HPSUSAN and/or HPCPUNAME?

Chris Gauthier replies:
First off, CPUNAME and HPSUSAN live in EPROMs called “Stable-Storage.” Those EPROMs live in different spots in the machine depending on your model. Never allow anyone other than a HP CE to change your Stable Storage. This is for legal reasons as well as your own protection. If your HP CE forgets something, then it’s on their nickel to come back out and fix it.

The HPSUSAN number is an algorithm using the system’s SERIAL NUMBER and the ORIGINAL base-model number at the time of manufacture. Therefore, when you upgrade within the same family (959 to 979 as an example) the HPSUSAN number should not change.

However, HPCPUNAME should ALWAYS change whenever you upgrade your processors (i.e. 928RX to 968RX or 979-100 to 979-200 as examples).

FYI: If your CE changes any parts, for whatever reason, that have Stable-Storage chips on them, the CE should use SS_CONFIG to bring Stable-Storage back into the above specs. There are no exceptions.

If your HPSUSAN number did change, then a step was missed and you need to call the HP Response Center.

[Editor’s note: this is very important because many software packages use HPSUSAN and some also use HPCPUNAME in their validation algorithms. Well-behaved packages will revert to demo mode, giving you time to contact the vendor and straighten things out. Ill-behaved packages will just stop working. The prudent rule to follow: Always contact your vendors prior to any upgrade that will effect HPSUSAN or HPCPUNAME to avoid unplanned downtime. Note also that a change to HPSUSAN or HPCPUNAME may result in upgrade fees for your software and should be considered in any upgrade plan.]

We have an old application that’s written in COBOL and has been re-written. Is there a way we can make the old database application read-only without re-compiling the old source to change the database Open mode from Read/Write to read-only?

Mark Wonsil suggests:
Have you considered using a tool like Adager or DBGeneral to change the password that the application uses to only have read access? For example, if the password is associated with class 5, make your dataset access (5/). Your application may of course bomb out if any DBPUTs or DBUPDATEs are attempted.

Not a question, but an FTP tip from Paul Christidis:
It seems that the new version of FTP.ARPA.SYS uses the default file designators of ‘input’ and ‘output’. Therefore, if in your current stream files you set ‘input’ or ‘output’ you may want to strategically insert the proper ‘reset’ commands or risk overwriting files, creating unwanted reports, etc.

How can I change my default printer? I removed the DTC LP was on and I want the default printer to now be LP23, instead of LP. How can I do it and also redirect STDLIST to LP23?

Doug Werth replies:
The default output for batch jobs can be changed but it won’t necessarily solve your problem. It is probable that batch jobs on your system have a “;dev=LP,4” directive on them which will override the default device class.

A better option is to add device class LP to the LDEV you have configured for LP23. This way reports that currently print to this device will continue to do so, and $STDLISTs and other reports for LP will use it as well.

Assuming you are using LDEV 23 for device class LP23 you could change it this way:
:ioconfig ioconfig:MC LP;ALDEV=23
Just remember the next time you restart your system that you must use a “start NOrecovery” or any dynamic configuration changes you made will be lost until you “start NOrecovery” or re-add them with IOCONFIG.

How can we tell, using COBOL or CI functions, what mode an already open database was opened in? And if more than one process has the database open, what mode each process used?

Jerry Fochtman replies:
DBUTIL shows you this:

>>show simp.tjtest users
For database SIMP.TJTEST

PIN  PATH   EXECUTING PROGRAM        JOBNUM  MODE


69      1      QUERYNM.PUB.SYS             #S4          5

You could route the output from DBUTIL to a file then parse the file looking for the information. Another possible option is to use the AIFFILEGGET, retrieve the file access options and use these to determine the open mode of the rootfile. This may require PM, as the file is a PRIV file.

As I recall, BULDACCT likes to deposit BULDJOB1 and BULDJOB2 in PUB.SYS which is not quite where I’d like things like that to be. Does BULDACCT still do that?

Doug Werth and Larry Barnes reply:
BULDACCT creates BULDJOB1 and BULDJOB2 in your current group. Furthermore, there is no reason that the files cannot be renamed/moved into a secured group.

Lars Appel also notes as a slightly tongue-in-cheek aside:
Which brings up the point that it’s typically a good idea to use ALTUSER to give MANAGER.SYS a home group other than PUB.SYS. It helps keep the PUB group clean (by not cluttering it with MANAGER’s work files, auxiliary files, K-files, etc.) and keeps MANAGER’s workspace less PUB-lic.

What is the current rule of thumb for configuring memory? And, please, I don’t mean a rule devised by a purveyor of memory. I know that HP is recommending no less than 128 Mb for 6.5, but how can I hone that a little?

Stan Sieler replies:
I used to say 64 Mb + 2 Mb per user. Now, I think I’d say 128 Mb + 4 Mb per user.

Are background jobs such as SOSMONJ, NBSPOOL, JINETD, and other background jobs not even a factor in the equation for addressing memory sizing? Or are JOBS and SESSIONS considered USERS?

Stan Sieler replies again:
Good question. Remember the above was a rule of thumb. My other rule of thumb is, how much memory will fit in the box?

Is there a way I can get a listing of all my DBEnvironments?

Michael Berkowitz replies:
Use the command :LISTFILE @.@.@,6;SELEQ=[CODE=-491]. -491 is the filecode for DBE files.

If I look at a listjobq it shows 11 executing; however, if I look at a listing of showjob job=@j;jobq there are only 10 executing. Where is the other job? How do I get these counts back the same? How did they get off by one?

Jon Dierks replies:
I got bit by this a few months ago, too. If HPSYSJQ is out of sync, a reboot is required to fix it. If it’s a user-defined jobq you can delete and re-create the jobq as an alternative to rebooting.

Goetz Neumann adds:
As of today (12/14/00) we have a beta patch available from your Response Center for this problem for release 6.0: MPELXC2-C. The 6.5 version is currently in development.

What is the maximum length of a file name in the Posix name space? I can only seem to get 16 character names.

Mark Bixby replies:
The limit for HFS filenames contained within MPE groups (/ACCOUNT/GROUP/hfsfilename) or MPE accounts (/ACCOUNT/hfsfilename) is 16 characters.

But for HFS files stored in HFS directories, the filenames can be up to 255 characters. So you can do things like /ACCOUNT/GROUP/hfsdirectory/superduperreallylonghfsfilename below MPE groups as long as you use an HFS directory to store the long-named files.

Barry Lake adds a word of caution:
The overall HFS path can be as long as 1,023 characters. Beware, however: the CI has a maximum command buffer of 511 bytes, so you can’t specify a HFS pathname greater than 511-(length of CI command). You can get around this by doing a CHDIR to a deeply nested directory and then use a relative HFS path rather than an absolute path. Depending upon what you’re doing, you might also be able to get around it by dropping into the shell, in which case you get a much larger command buffer to work with.

There is a problem with VSTORE on MPE/iX 6.0 involving /usr files (there is an S/R: 8606252865). The temporary fix is to exclude the /usr files from the VSTORE. The RC noted that the /usr files have been successfully restored from the tape even though they don’t validate. So, since I don’t work with the HFS file set, how do I exclude the /usr file set from my VSTORE of everything job?

Gilles Schipper recommends:
Use the command!VSTORE ;/ - /usr/;ONERR=QUIT;SHOW=LONG,DATES

We have a limited user license of 100 users and want to log off users who have been inactive for a period of time. I set up in sysgen -> misc -> session a value of 15 minutes for citimeout. But this means my console user is also automatically logged off after 15 minutes. Is there any way to be more selective?

In addition to various free and third-party tools, Mario Tremblay, H Lassite, Jeff Vance and Tracy Johnson suggest:
Try setting the HPTIMEOUT CI variable in a logon UDC based on logon, ldev, whether the user is the console HPLDEVIN=HPCONSOLE), etc.

[Editor’s note: HPTIMEOUT is “a variable used by the CI that lets a user set timed CI reads on $STDIN. A positive value indicates the number of minutes the CI waits for input. If a timed CI read expires, the session is logged off. The initial value is zero, which means no timed reads. The maximum value is 546 minutes.” HPTIMEOUT may be restricted if Security Monitor sets the HPSYSTIMEOUT variable.]