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

A: Chris Gauthier replied:

• First off, CPUNAME and HPSUSAN live in EPROM (s) called "Stable-Storage". Those EPROM's 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 systems 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.]

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

A: Mark Wonsil suggested:

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 a tip from Paul Christidis:

It seems that the new version of FTP.ARPA.SYS uses the default file designators of 'input' and 'output'. If, therefore, in your current stream files you are setting 'input' or 'output' you may want to strategically insert the proper 'reset' commands or else you may end up overwriting files, creating unwanted reports, etc.

Q: 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?

A: Doug Werth replied:

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.

Q: 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?

A: Jerry Fochtman replied:

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.

Q: 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 anybody know if BULDACCT still does that?

A: Doug Werth and Larry Barnes replied:

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 noted 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 keeping 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.

Q: I am trying to write a quick little QUERY report. I want to search on date, todays date in fact. I want to use the contents of the MPE/iX variable HPYYYYMMDD. I tried: f entry-date = !hpyyyymmdd in QUERY, but this does not work. What can I do?

A: Leonard Berkowitz, Kevin Miller and Barry Lake all replied with command !/O redirection solutions, for example:

PURGE QUERYIN,TEMP
PURGE QUERYIN
[disregard warnings for files that do not exist]

ECHO BASE=dbname.group.account > QUERYIN
ECHO readpass >>QUERYIN
ECHO 5 >>QUERYIN
ECHO SET=dataset >>QUERYIN
ECHO FIND field = !HPYYYYMMDD >>QUERYIN
ECHO some additional Query commands >>QUERYIN
ECHO EXIT >>QUERYIN

RUN QUERY.PUB.SYS<QUERYIN

Kevin Miller noted:

I usually do this inside QUERY,

>:PURGE QUERYIN,TEMP
>:ECHO SET=dataset >QUERYIN
>:ECHO FIND field = !HPYYYYMMDD >>QUERYIN
>XEQ QUERYIN

This can be really useful if you need to update (REPLACE) fields with other values or calculated values from the database. Output a query report to the temp file that contains REPLACE commands.

Q: Is there a way I could get a listing of all my DBEnvironments?

A: Michael Berkowitz replied:

:LISTFILE @.@.@,6;SELEQ=[CODE=-491]

-491 is the filecode for DBE files.

Q: 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?

A: Jon Dierks replied:

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 added:

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.

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

A: Mark Bixby replied:

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 added a word of caution:

The overall HFS path can be as long as 1023 characters. Beware, however, that 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.

Q: 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. My question is, since I don't work with the HFS file set, how do I exclude the /usr file set from my VSTORE of everything job?

A: Gilles Schipper recommended:

!VSTORE ;/ - /usr/;ONERR=QUIT;SHOW=LONG,DATES

Q: Does anyone have a 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 128MB for 6.5, but does anyone have a suggestion on honing that a little?

A: Stan Sieler replied:

I used to say 64 MB + 2 MB per user. Now, I think I'd say 128 MB + 4 MB per user.

To which someone asked:

Is this to say that background jobs such as SOSMONJ, NBSPOOL, JINETD, and other background jobs are not even a factor in the equation for addressing memory sizing? Or do you consider JOBS and SESSIONS as USERS?

Stan then elaborated:

Good question. Remember that it was a rule of thumb. My other rule of thumb is, how much memory will fit in the box?

Q: 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?

A: In additon to various free and third-party tools,Mario Tremblay, H Lassite, Jeff Vance and Tracy Johnson suggested:

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.]

Q: Recently I modified inetdsec, adding additional values for "telnet allow". I used 2 "telnet allow' lines in the file becuase there were too many IP's to fit on 1 line. I used the '/' character at the end of the first line as described in the Confguration and Managing MPE/iX Internet Services manual. For some unknown reason telnet quit working. Does anyone know what is wrong?

A: Greg Skvorak and Mark Bixby replied:

To make continuation lines work,

• create /SYS/NET/INETDSEC as a bytestream file.
• use a backslash "\" as the continuation character at the end of the line.

Using a backslash is counter to the MPE/iX documentation which suggests a forward slash "/", however it does adhere to the HP-UX documentation. see man 4 inetd.sec (HP-UX 11.0)

Q: Is there a way to display, for example, the first 7 bytes of a file using just the CI or shell?

A: Barry Lake, Ken Hirsch and Eric Vistica contributed the following solutions:

In the shell,

$head -c 7 MYFILE

Or,

/bin/head "-c 7 MYFILE"

from the CI without even going into the shell.

Strictly using the CI,

:INPUT MYVAR;READCNT=7 < MYFILE

:SHOWVAR MYVAR

or

INPUT A < MYFILE

ECHO ![lft(A,7)]

Q: We are on a 918 with MPE/iX 6.0. The system appears to hang when we attempt to change the tiime during system startup right after the "ISL> START NORECOVERY" prompt and response. Is there a patch or newer release that fixes this?

A: Wirt Atmar and Andreas Schmidt replied:

The patch is: "Don't do that!"

It is not clear what machines are effected, but has been reported on 918s and 969s. The machine isn't hung, per se. Rather what it's doing is gradually adjusting its clock to match your new specification. If you leave it for a few hours (or days), it will come back to you and you can then complete the boot-up.

So, the fix is: don't set the time there. Ignore the wrong time during boot-up and fix it later, using SETCLOCK, once you've got MPE up and operational.

Q: I want to change a udc file, but I cannot modify the file because as long as someone is signed on, the file is in use. Is there any workaround to this?

A: John Burke and Gary Paveza replied:

Even if someone is logged on in one of the accounts that has the UDC file set, you can still make the change easily for all subsequent accessors:

• edit the file (say udc.pub.sys), making your changes and keeping it as, for example, udcnew.pub.sys.
• use the posix move command to replace udc with udcnew:

:mv.hpbin.sys "/SYS/PUB/UDCNEW /SYS/PUB/UDC"

Respond "yes" to the question about replacing udc. All subsequent logons will get the new version of the udc. I use this trick all the time to replace files in use.

Mark Bixby added:

Start your mv parameters with -f and it won't bother to prompt you, it will just do the rename.

Duane Percox and Thomas Burger noted another way:

:purgelink oldudc

:rename newudc,oldudc

Q: From what I understand, MPE/iX does not use blocking when writing files. Or rather it handles it all, and specifying it on the file equation doesn't matter. For that reason I usually omit the blocksize and leave that option blank. However, a programmer has asked what the result would actually be when the file is written to tape with FCOPY. In this case, it's an IBM labeled tape. What blocksize would the IBM see? The file equation is as follows:

!FILE T;DEV=TAPE;REC=-350,,F,ASCII;DEN=6250;LABEL=BONUS,IBM

A: Dennis Handly replied:

This will create a tape with a very poor blocking factor: 1.

Q: Is there a way to move IMAGE database files to an HFS file system on a non-MPE box (such as UNIX or NT) and yet access them from the HPe3000 with all normal IMAGE library routines, QUERY, etc?

A: Gavin Scott replied:

No. Image needs to be able to directly interact with the disk storage managers and the memory management system, plus of course the transaction manager, in order to manage I/O to the database. None of the interception products (NetBase, NFS client, etc.) developed for the 3000 has ever intercepted at these levels. I can guarantee you that there's no way to do exactly what you're asking.

Q: I'm accessing the DBE as the creator of the database and the DBE environment. I've done a GRANT ALL to myself. The message(s) I'm getting are these:

isql=> connect to 'flibdbe';
isql=> delete from flib.flib_xml where xml_id = 'rick';
IMAGE/SQL error 164; TurboIMAGE error -242; TurboIMAGE intrinsic 420, &
Auxiliary error 6554488. (DBERR 13552)
INSERT/UPDATE/DELETE statement had no effect due to execution errors.
(DBERR 2292)

Number of rows processed is 0

What does this mean?

A: Ken Vickers replied:

This is the old TURBOGTX problem. The TI transaction log has gotten out of step with your Image root. The solution is:

Ensuring that no one has the file TURBOGTX.PUB.SYS open, purge it using either STORE - PURGE or FSCHECK as it is a PRIV mode file. The system will re-build it as soon as it needs it. The cause is usually that a TIDB has been restored to another group or account.

Q: I created a new DBEnvironment and went into IMAGESQL and performed my SET commands. When I attempted to ATTACH a database to the DBEnvironment, I received the following:

>>ATTACH

Split 7 compound source field(s) (ATCWARN 32063).
Mapped 324 source table/source field name(s) (ATCWARN 32062).
Mapped 30 incompatible/imprecise source type(s) (ATCWARN 32061).
ALLBASE/SQL CREATE TABLE command failed (ATCERR 32353).
Log full. (DBERR 14046)

What do I need to do to fix this ?

A: Denys Beauchmin replied:

The action of attaching a TurboImage database to a DBE is an SQL transaction, which can be quite large. In your case, you have a total of 304 items and tables that have created rows in various tables of the DBE. You also had 7 compound items that generated multiple columns in corresponding tables. Furthermore, there were 30 items that are mapped imprecisely. These may need to be touched up when you finally succeed in attaching the TIDB.

Finally, the attach command failed, because the overall SQL transaction creating all this "junk" along with corresponding views, overflowed the log file size.

You will need to increase the logfile size, and you do this using "sqlutil.pub.sys". Start the program and then enter "showdbe". Give it the DBE name and hit return until you get the "->" prompt. At that point, enter "all". This will show you all the parameters of the DBE. Look at the number of log buffers. You will need to increase this value. Using "altdbe", answer with the DBE name and then hit return until you get to the log buffer question. Put in your new value. Hit return until the last question, which asks you if you want to Alter the DBE parameters. Enter yes.

You can verify your handiwork with showdbe. BTW, each log page is 1000 bytes.