What with the holidays, the true beginning of the new millenium and the usual year-end vacations, I expected the volume of traffic to be down for this month's collection period 12/21 - 01/20. And, it was down for a few days. I guess a lot of people have an HP3000-L jones though, because things certainly picked up and, in a few off-topic threads, heated up, in January. There were still over 1500 postings to wade through.

It was a month of change with HP co-founder William Hewlett passing away and Fred White "retiring". William Hewlett had not been actively involved in HP management for many years. But his and David Packard's legacy of founding what became a mighty company (HP) and helping to create a region that became synonymous with high tech (Silicon Valley) as well as fostering humane (yet successful) management practices (the HP Way) should endure well into this century. Fred White is one of the developers of IMAGE and for many years has worked at Adager helping people get the maximum out of their investment in IMAGE and the HP e3000. Fred is one of the more fascinating people you could ever hope to meet, sometimes a bit curmudgeonly, but never uninteresting. Many of us hope IMAGE endures well into this century. Good luck, Fred.

A user writes on HP3000-L: While running smbclient I inadvertently broke out of it. When I tried to run it again later this is what I got:

shell/iX> smbclient
**** EXEC FUNCTION FAILED; subsys =517; info = 48
ABORT: /SAMBA/PUB/bin/smbclient

I did a listfile,2 and much to my surprise I saw this:

CODE ------------LOGICAL RECORD----------- ----SPACE---- FILENAME
SIZE TYP EOF LIMIT R/B SECTORS #X MX

NMPRG 128W FB 0 1939 1 256 1 * smbclient

Does any one have any idea how this could happen, that a program file was apparently emptied?

Lars Appel somehow figured out what was happening and passed on a word or two of advice for all shell novices: I could not duplicate this by doing Break :ABORT in smbclient (and in fact, I would be very surprised to see a program file emptied just because it is aborted). However, I could duplicate the emptying of the program file by pressing Enter instead of Return when trying to execute the smbclient command inside the Shell.

shell/iX> pwd
/SAMBA/PUB

shell/iX> bin/smbclient
bin/smbclientshell/iX: not found

shell/iX> ls -l bin/smbclient

-rwxr-xr-x 1 MGR.SAMBA SAMBA 0 Dec 23 12:24 smbclient

This is not a Samba specific issue. It is just a side effect of the unfortunate default prompt in the Shell that contains a greater than sign, which acts as output redirection when pressing Enter (and thus causing the terminal to "retype the screen line").

See http://www.allegro.com/papers/posix/pnpposix.html (Plug and Play Posix) for good advice on customizing /etc/profile regarding the PS1 default prompt (and many other tips regarding Posix Shell setup or customization).

I am trying to learn how to use the POSIX shell. I am in possession of the MPE/iX Shell and Utilities Reference Manual (2 volumes). This has a great list of commands and other help. What it does not tell me is how to even invoke the shell. Is there another manual that has even more basic information, something like, "Getting Started with POSIX?"

Several people pointed out that the udc file HPPXUDC.PUB.SYS has a command "sh" that will invoke the shell. Or, the shell can be invoked directly:

run sh.hpbin.sys;info="-L" or

xeq sh.hpbin.sys –L or, simply

sh.hpbin.sys –L

In addition to Michael Hensley’s "Plug and Play Posix" mentioned above Mark Bixby suggested "The HPUX Shells: User’s Guide" at http://docs.hp.com/hpux/onlinedocs/B2355-90046/B2355-90046.html.

A number of people also noted that a computer-based training (CBT) module comes with MPE/iX. Just execute POSIXCBT.LSN.SYS from any terminal or PC with termulator.

Robelle has several useful materials at their web site. www.robelle.com/smugbook/mpe2unix.html provides a comparison of MPE and shell commands and www.robelle.com/ftp/tutorials/1997/hpuxmpe.exe is a self-extracting PowerPoint presentation entitled "HP-UX for MPE Users" that gives a good overview of Posix and shell commands.

The "MPE/iX Shell and Utilities User's Guide" (36431-90002) is absolutely invaluable as a learning tool as it presents various features of Posix and the shell through a series of tutorials and guides. Unfortunately, it appears to be available only in paper format. Why this is so when even the AIF:OS manual is now available electronically is a mystery to me. If you do not have the guide and want to learn to use the shell and various Posix utilities, buy it. It will be a wise investment in your career.

Imagine buying a car with four-wheel drive but never learning how to engage and use it. Sure, for average usage, you do not need four-wheel drive. But if you never use it, you are missing out on much of the vehicle's potential. So it is with MPE/iX and Posix. If you never use Posix and the shell, you are missing out on much of your system's potential. Additionally, CSY is reluctant to invest in enhancements to MPE/iX if the functionality is already available through the shell, third-party software or freeware. So it behooves you to learn as much as you can about what is available.

That's right, you read it correctly, there is a Y2001 bug in MPE. Fortunately, it is not terribly serious, but it certainly comes as a surprise. It occurs when printing a directory listing if the modify date of NSDIR is greater than 12/31/2000. NMMGR aborts with "**** Bounds violation or range error (TRAPS 12)". From HP:

The problem exists on all releases of the operating system and occurs when the modify-date of NSDIR is greater than 31 December 2000 (i.e. the year portion of the date is 2001 or greater). The problem occurs in NMMGR when printing the directory listing in block or character mode, and also in NETTOOL CONFIG NETDIR (which uses NMMGR maintenance mode). It is, however, possible to view the directory entries when in UPDATE mode and perform any directory management required.

The SR for this is 8606175312 and beta patches exist for both MPE/iX 6.0 (NMCGD03A) and MPE/Ix 6.5 (NMCGD04A) at press time.

Thus began a question and thread. The consensus answer is something like "It is probably not necessary, but is it worth the potential pain if you remove it? Better to spend your effort securing the user."

From Mike Hornsby: You can remove this user if you have no batch jobs that sign on as OPERATOR.SYS. However,

• You may want to add a start up user to SYSSTART.PUB.SYS since otherwise the system will attempt to logon as OPERATOR.SYS and generate an error.
• Down the road, if you ever do a restore you will have to use the CREATE option, and it will be deja user all over again.
• The next software update or patch may reincarnate this user.

Mike continued that it used to be you could count on an option logon, nobreak UDC with a bye command to disable a user. (The parm=-1 exception could be handled by removing SM from the user.) However, with FTP not processing UDCs, the best alternative now, absent a separate security package, is to frequently change passwords.

But then someone asked, I thought that OPERATOR.SYS is considered the master operator and therefore you have to have it.

This is a frequent source of confusion even for experienced users. From Doug Werth: You are likely referring to the error message

"Executing this command by other than the master operator requires permission by the ALLOW or ASSOCIATE commands. (CIERR 3247)"

Doug goes on to say that in this context the master operator is synonymous with the current logical console and not the user OPERATOR.SYS. "Operator" commands are often wrongly attributed to either OPERATOR.SYS or having OP capability when, in fact, they are commands that are restricted to whomever owns the logical console (ALLOWed commands and ASSOCIATEd devices notwithstanding.)

Doug did not mention it, but further complicating the mix are the commands/functions that only apply to the physical console (ldev 20).

Gavin Scott warned about just stripping OPERATOR.SYS of capabilities (as some suggested) because it is still a user in the (privileged) SYS account. As he said, being a user in an account (and especially being able to log into an arbitrary GROUP) will give even a "no capability" user some power over files that exist there, and, when it is a privileged ACCOUNT, that is not a good thing. You need to prevent any but trusted users from gaining the ability to create a file in a group with PM capability and you must prevent them from gaining WRITE access to any executable file in any group with PM capability.

This thread started out with someone looking for a way for a job to increment the job limit by 1 for the jobq it was streamed in. He lamented that there is no "HP" variable that specifies the jobq and wanted to know how he could get the information. Several people responded that the easiest way is to use the "jinfo" function, as in jinfo('0', 'jobq'), to create his own "HP" variable. Here is where the thread veered off into a lengthy discussion on variable naming with the final result an enhancement request for MPE/iX to prevent users from creating variables that begin with the prefix "HP".

Why prevent user-created variables beginning with the prefix "HP"? From Jeff Vance, Stan Sieler and Tom Emerson:

• CSY might later invent a new predefined variable with the same name (Jeff admitted that when HPLASTJOB was introduced it broke several of his scripts).
• It prevents typing mistakes that could lead to disastrous results, e.g.

… job stream with HPAUTOCONT true …
…
setvar hpautocontinue false
…
… something that might fail
…
purge critical.data

The above would nicely set the user variable "HPAUTOCONTINUE", but would not reset the HP variable "HPAUTOCONT". The potential for disastrous results is obvious.

• Third-party software product installation jobs may rely on the presence, absence or value-type of certain HP variables to auto-configure a system. If you create your own HP variable that has the same name as a real HP variable on a different version of the OS, you are asking for trouble that could even lead to system aborts. One individual admitted this actually happened to him and it was very difficult to track down the source of the problem.

Several people complained that such a change might break existing scripts/jobs, to which Stan replied: "and, it SHOULD break them!" He went on to say that it is better to break bad scripts/jobs now then to risk future errors. As he said, "like flossing, it is something that some people might not like, but they'll benefit from."

By the time the thread petered out, everyone seemed in agreement that preventing user-created variables with the "HP" prefix is a good idea. SIGMPE take note.