March 09, 2018

Fine-Tune Friday: Account Management 101

Newswire Classic

By Scott Hirsh

Ledger-bookAs we board the train on our trip through HP 3000 System Management Hell, our first stop, Worst Practice #1, must be Unplanned Account Structure. By account structure I am referring to the organization of accounts, groups, files and users. I maintain that the worst of the worst practices is the failure to design an account structure, then put it into practice and stick with it. If instead you wing it, as most system managers seem to do, you ensure more work for yourself now and in the future. In other words, you are trapped in System Management Hell.

What’s the big deal about account structure? The account structure is the foundation of your system, from a management perspective. Account structure touches on a multitude of critical issues: security, capacity planning, performance, and disaster recovery, to name a few. On an HP 3000, with all of two levels to work with (account and group), planning is even more important than in a hierarchical structure where the additional levels allow one to get away with being sloppy (although strictly speaking, not planning your Unix account structure will ultimately catch up with you, too). In other words, since we have less to work with on MPE, making the most of what we have is compelling.

As system managers, when not dozing off in staff meetings, the vast majority of our time is spent on account structure-related activities: ensuring that files are safely stored in their proper locations, accessible only to authorized users; ensuring there is enough space to accommodate existing file growth as well as the addition of new files; and occasionally, even today, file placement or disk fragmentation can become a performance issue, so we must take note of that.

In the unlikely event of a problem, we must know where everything is and be able to find backup copies if necessary. Periodically we are asked (perhaps with no advance notice) to accommodate new accounts, groups, users and applications. We must respond quickly, but not recklessly, as this collection of files under our management is now ominously referred to as a “corporate asset.”

You wouldn’t build a house without a design and plans, you wouldn’t build an application without some kind of specifications, so why do we HP 3000 system managers ignore the need for some kind of consistent logic to the way we organize our systems?

A logical, adaptable, documented account structure is a huge time saver in many respects. As most of us now manage multiple systems, we have no time to waste chasing down lost files, working with convoluted file sets, struggling to keep access under control or reacting to full volume sets.

I once had a conversation with a co-worker who was an avid outdoorsman. He was discussing rock climbing and I asked him about exciting rock climbing experiences. His reply: “In rock climbing, anything exciting is bad.” I would say the same thing about system management. By getting your account structure under control, you build a solid system management foundation that translates into much more pleasant work.

If this were a “best practices” column, we would discuss the best ways to clean up your system’s account structure. But this is worst practices, so let’s look at the no-nos.

No naming standards,
bad naming standards

Oscar Wilde once said, “Consistency is the last resort of the unimaginative.” Do you think he was referring to HP 3000 system management? If so, not much has changed since Oscar’s day.

• In one account the jobs are located in group JCL. In another account, group JOBS. The developers keep “special” jobs in a group you never heard of in the critical application account. And just to make things more interesting, all your so-called “production” jobs are kept in an account called JCL, containing all kinds of groups, including “TEMP.”

By having consistency across accounts I control, I can easily find what I need when I need it. If jobs are always in the same group across accounts, I can LISTF @.JOBS.@, etc. Backups/recoveries are easier, updates are easier, training new operators is easier. Sure, consistency is boring, but we must resist the lure of adrenaline.

• I’m going out on a limb here, but my guess is that your UDCs, the few you have left, are in a different place in every account. Why is that? And your system UDC (singular) is located in the SYS account, right? Because it’s the SYStem UDC, of course! Maybe it’s not such a bad thing to have another, non-SYS account for globally accessible files. What’s the catch? The system UDC file needs to be in the system volume set, for obvious reasons (learned that one the hard way).

• An MPE file name consists of a whopping maximum of eight characters. That should make every character count, right? So why do jobs that live in a group called JCL or an account called JCL all start with the letter J? File that under the department of redundancy department.

• We manage the systems, so we make the rules, right? Wrong. If we want the rules followed, if we want the best rules possible, we must get input and buy-in from all the others who will be expected to honor our rules. Ignoring users when it’s time to develop naming standards and other system policies is a classic Worst Practice, and a good way to ensure continued chaos. And don’t forget that upper management will need to be involved when a little “gentle” persuasion is required.

Scott Hirsh is former chairman of the SIG-SYSMAN Special Interest Group.

Posted by Ron Seybold at 06:51 PM in Hidden Value, Homesteading | Permalink | Comments (0)

Get e-mail notice when the NewsWire blog gets a new entry. Just say "Blog Me" in a message to

March 02, 2018

Fine-Tune Friday: One 3000 and Two Factors

RSA SecurID fobPeople are sometimes surprised where HP 3000s continue to serve. Even in 2018, mission-critical systems are performing in some Fortune 500 companies. When the death knell sounds for their applications, the axe gets swung sometimes because of security. Two-Factor security authentication is a standard now, serving things like Google accounts, iCloud data, and corporate server access.

Eighteen years ago, one HP 3000 shop was doing two-factor. The work was being coded before smartphones existed. Two-factor was delivered using a security fob in most places. Andreas Schmidt worked for Computer Sciences Corporation, which served the needs of DuPont in Bad Homburg, Germany. CSC worked with RSA Security Dynamics to create an RSA Agent that connected a 3000 to an RSA Server.

Back in that day, authentication was done with fobs like the one above. Now it's a smart device sharing the key. Schmidt summarized the work done for what he calls "the chemical company" which CSC was serving.

Two-Factor Token Authentication is a state-of-the-art process to avoid static passwords. RSA Security Dynamics provides an MPE Agent for this purpose which worked perfectly for us with Security/3000, but also with basic MPE security. The technical approach is not simple, but manageable. The main problems may arise during the rollout because of human behavior in keeping known procedures and avoiding changes, especially for security. But to stay on HP 3000 into the future, the effort is worth it, especially for better security.

The project worked better when it relied on the Security/3000 software installed on the server hosting Order Fulfillment. Two-factor security was just gaining widespread traction when this 3000 utilized it. Schmidt acknowledged that the tech work was not simple, but was manageable. When a 3000 site is faced with the alternative of developing a replacement application away from MPE/iX, or selecting an app off the shelf like SAP, creating two-factor is within the limits of possibility. Plus, it may not be as expensive as scrapping an MPE application.

Schmidt's article covers an Agent Solution created by CSC. Even 18 years ago, remaining on the 3000 was an issue worth exploring. When many outside firms access a 3000, two factor can be key.

DuPont wanted two-factor tested on its NT systems, plus the 3000.

NT and MPE were selected as pilots: NT because of the large number of servers running that environment; and MPE because of the thinking that this platform might be different from all others and more difficult to implement. However, the company also recognized the importance of running its 3000-based Order Fulfillment Process with a lot of different outside partners.

RSA’s first attempt to develop an agent for MPE was very simple: A token had to become configured for a combination of MPE-USER-ID.MPE ACCOUNT. This combination could not be reused on another token. It was not possible to use wildcards or to add SESSION-IDs or MPE-GROUP to have a complete logon string. Because of the MPE characteristic to share logons (on all levels of capabilities) this version of the agent was not what we were looking for. (More drastically: This agent could not function for the MPE platform).

The second attempt was much better: everything was changed to the chemical company’s already-existing Security/3000 setup. Now Security/3000 invokes the RSA Agent to contact the RSA Server. It transmits either the SESSION-ID or the MPE-USER-ID as the name of the token. If the token is known and allowed to access the HP 3000, the agent asks the user for the current tokencode plus PIN.

This agent also functions without Security/3000 by adding some lines to the System’s Logon UDC. This drops some additional functions in combination with Security/3000, like verifying a user profile in any case (SESSION-ID,MPE-USER-ID.MPE-ACCOUNT is defined as allowed logon in Security/3000, all others will be refused before starting anything), but it will work.

The project report details show this could be installed even before two-factor took a wide foothold in IT. Schmidt doesn't share the code in his article because it was custom work for a dedicated customer. But the process is worth a look, even if only to prove that custom code brings a 3000 into security compliance.

"One thing is essential," Schmidt wrote. "The RSA Agent for MPE does not replace the MPE password process like it does for Unix or NT. It is activated first when the HELLO string has been entered and the MPE password hurdle has been passed (Account, User, and/or Group Password) and (as an option) the basic check within Security/3000 for profile existence is passed. Now any other logon UDC functions are invoked, and this activates the RSA Agent.

Having Security/3000 in place is a good idea to replace the session passwords (if any) by supplying the tokencode.

Not having session names in place, the RSA Agent will add an additional password. I do not recommend eliminating the MPE password — it’s still a fence around your system and is needed for batch security (depending on the streaming security you have in place).

Complete details are in the NewsWire website's archived Technical Articles. Go forth and secure, if preserving an application is a better choice than locating an app replacement.

Posted by Ron Seybold at 06:52 PM in Hidden Value, Migration | Permalink | Comments (1)

February 23, 2018

Friday Fine-tune: Check on LDEV availability

Is there a way to have an HP 3000 jobstream check to see if a tape drive (LDEV) is available? I am not seeing a HP system variable that seems to list the status. I can see via a SHOWDEV that the device is available or not. I just need a jobstream to be able to do the same.

Roy Brown replies

We use a utility,, that we found in our ORBIT account alongside Backup+. We use this, in a command file run as a jobstream, to check that tapes are mounted ready for our nightly backups, and, in the backup job itself, to eject them when complete.

Tom Hula says,

It's been awhile since I've messed with the 3000. I have a utility that I received from Terry Tipton many years ago that does that checking. It is called CHKTAPE. So if the tape drive is dev 7, I have CHKTAPE 7 in the jobstream and then check for the results in CHKTAPE_RESULT. We are looking for a value of 0, but here are all the results:

0 - Tape is unowned, online, at BOT and writeable
1 - Tape is unowned, online, at BOT and write protected
2 - An error occurred.  Probably an invalid device number
3 - Device is not a tape drive
4 - Device is owned by another process
5 - Device is owned by the system
6 - Tape is not online
7 - No tape in device

Terry has a reminder that the program must reside in a group with PM capability. I have been using it on all my backups since without any problems. Let me know if you are interested in getting a copy of this utility.

Alan Yeo adds,

We use the little ONLINE utility from Allegro to put a tape on-line, or back on-line; we use it to put automatically back on-line to do a verify after the store.

Donna Hofmeister replies

Here's a scripted solution to the question. MPE has the best scripting language of any OS. Thanks, Jeff (Vance)!

The following will return CI variables that can be easily used in a job:
parm tape=0,entry=main

if "!entry" = "main"
 if "!tape" = "0" or "!tape" = "?"
   echo ![basename(hpfile)] [tape_ldev_num]
   echo              req.
   echo ![basename(hpfile)] is designed to check the 
   echo !desired tape
   echo   device to see if a write-enabled tape is mounted and
   echo   available for use.
   echo The boolean variable _TAPE_READY will be returned.
   echo The string  variable _TAPE_LABEL will be returned, if available.
 if numeric("!tape")
   setvar _ct_tape !tape
   echo ERROR: The parameter "!tape" is not numeric
 file sdtemp;rec=-80,,f,ascii;temp
 if finfo("*sdtemp","exists")
   purge sdtemp,temp
 showdev !_ct_tape > *sdtemp
 if hpcierr <> 0
   echo !hpcierr   !hpcierrmsg
   escape !hpcierr
 setvar _ct_tape_ready false
 setvar _tape_ready false
 setvar _tape_label ''
 xeq !hpfile !_ct_tape,process < *sdtemp
 if _ct_tape_ready
   setvar _tape_ready true
 if _ct_tape_label > ''
   setvar _tape_label _ct_tape_label
 deletevar _ct_@
 purge sdtemp,temp
 reset sdtemp
elseif "!entry" = "process"
 setvar _ct_eof finfo(hpstdin,'eof')
 while setvar(_ct_eof,_ct_eof-1) >= 0
   input _ct_rec
   if numeric(word(_ct_rec))
     if pos("AVAIL    (W)",_ct_rec) > 0
       setvar _ct_tape_ready true
     setvar _ct_tape_label   repl(str(_ct_rec,43,14),' ','')

In a job, it might look something like this:

!chktape 7
!if not _TAPE_READY
! tellop No Tape is mounted
! setjcw jcw=fatal

Posted by Ron Seybold at 09:03 PM in Hidden Value, Homesteading | Permalink | Comments (0)

February 16, 2018

Friday Fine-tune: Deleting Bad System Disks

As HP 3000s age their disks go bad, the fate of any component with moving parts. Even after replacing a faulty drive there are a few software steps to perform. Wyell Grunwald explains his problem after replacing a failed system bootup disk

Our disk was a MEMBER in MPEXL_SYSTEM_VOLUME_SET. I am trying to delete the disk off the system.  Upon startup, the 3000 says LDEV 4 is not available.  When going into SYSGEN, then IO, then DDEV 4, it gives me a warning that it is part of the system volume set — and cannot be deleted. How do I get rid of this disk?

Gilles Schipper of support provider GSA said that INSTALL is something to watch while resetting 3000 system disks.

Sounds like your install did not leave you with only a single MPEXL_SYSTEM_VOLUME_SET disk. Could it be that you have more than one system volume after INSTALL because other, non-LDEV 1 volumes were added with the AVOL command of SYSGEN — instead of the more traditional way of adding system volumes via the VOLUTIL utility?

You can check as follows:


If the resulting output shows more than one volume, that's the answer.

He offers a repair solution as well.

The solution would be as follows:

1. Reboot with:


2. With SYSGEN, perform a DVOL for all non-LDEV1 volumes


4. Create new SLT.

5. Perform INSTALL from newly-created SLT.

6. Add any non-LDEV1 system volumes with VOLUTIL. This will avoid such problems in future.

If you do see only one system volume with the LVOL command, the only thing I can think of is that VOLUTIL was used to add LDEV 4 to the MPEXL_SYSTEM_VOLUME_SET after the install.

Posted by Ron Seybold at 07:43 PM in Hidden Value, Homesteading | Permalink | Comments (0)

February 09, 2018

Using a PURGEGROUP to clean volumes up

Empty file cabinetIs using PURGEGROUP a way to clean up where groups reside on multiple volume sets? I want to remove groups from Volumesets that aren't considered HOMEVS.

Tracy Johnson says

The syntax for a command on group PUB.CCC might read


Denys Beauchemin says

The ALTGROUP, PURGEGROUP and NEWGROUP commands act on the specified volumeset after the ONVS keyword.

The HOMEVS keyword is used to specify in which volumeset the group is supposed to reside and where the files will be found in a LISTF or FOPEN.

If you have the same group.account existing on multiple volumesets and they have files in them, the entries on volumesets—other than what is in HOMEVS for that group—are invisible. If you want to get to them, you need to point the group's HOMEVS to that volumeset and then you can get to the files.

If there are no files in the group.account of other volumesets, it's not a big deal.

Keven Miller says

You could review the volume scripts available that were once on HP's Jazz server. 

Take care in using  the PURGEGROUP command. You can have files existing in the same group name, on separate volumes—which makes mounting that group a problem. So make sure the group on the volume is clean of files you might desire before the PURGEGROUP.

HP's documentation for the PURGEGROUP command has a similar warning.

In the two pages devoted to PURGEGROUP, the manual says,

Do not attempt to purge the PUB group of the SYS account. The public group of the system account, PUB.SYS, cannot be completely purged. If you specify this group in the group name parameter, all non-system and inactive files are purged, which seriously impairs the proper functioning of the entire system.

Posted by Ron Seybold at 04:09 PM in Hidden Value, Homesteading | Permalink | Comments (0)

February 02, 2018

Simplifying MPE/iX Patch Management

NewsWire Classic

By John Burke

Patching-machineEven though Patch/iX and Stage/iX were introduced with MPE/iX in 1996, these HP tools are poorly understood and generally under-used. Both are tremendous productivity tools when compared with previous techniques for applying patches to MPE/iX. Prior to the introduction of Patch/iX and Stage/iX, system managers did their patching with AUTOPAT, and you had to allow for at least a half-day of downtime. Plus, in relying on tape, you were relying on a notoriously flaky medium where all sorts of things could go wrong and create “the weekend in Hell.”

Patch/iX moves prep time out of downtime, cutting downtime in half because you create the CSLT (or staging area) during production time. Stage/iX reduces downtime to as little as 15-20 minutes by eliminating tape altogether and, furthermore, makes recovery from a bad patches as simple as a reboot.

This article is based upon the Patch Management sessions I have presented at Solutions Symposia. The complete set of 142 slides (over 100 screen shots) and 20 pages of handouts are downloadable in a file from The complete presentation takes you step-by-step through the application of a PowerPatch using Patch/iX with a CSLT and the application of a downloaded reactive patch using Patch/iX and Stage/iX. Included is an example of using Stage/iX to recover from a bad patch.

Why should you care about Patch Management? Studies and surveys suggest that 50-80 percent of all HP 3000s will still be running by 2006-2009 – even HP now agrees. Keeping a system running smoothly includes knowing how to efficiently and successfully apply patches to the system. HP has committed to supplying bug fix patches to MPE/iX and its subsystems through 2006, including two PowerPatches per year. [Ed. note: The process continued through 2008.] There may also be new functionality added, either to support new devices or in response to the System Improvement Ballot (SIB).

Patch/iX is a tool for managing patches. It can be used to apply reactive patches, a PowerPatch, or an add-on SUBSYS tape with a PowerPatch. Patch/iX is actually a bundle including the PATCHIX program and a number of auxiliary files that are OS release dependent. Patch/iX allows you to:

• Qualify all patches in a set of patches;

• Install reactive patches at the same time as a PowerPatch;

• Selectively apply patches from a PowerPatch tape; and,

• Create the CSLT (or staging area for Stage/iX) while users are still on the system; i.e., when it is convenient for you without incurring downtime.

Stage/iX is an OS facility for applying and managing the application of patches. Stage/iX reduces system downtime for applying patches to the length of time required for a reboot and provides an easy and reliable method for backing out patches. Stage/iX includes an interface to Patch/iX that creates the “staging area” and two utilities:

• STAGEMAN, which allows you to manage all aspects of patch staging, including which version of the OS will be used for the next update; and,

• STAGEISL, an ISL utility available from the ISL prompt whenever the system is down. It contains a subset of STAGEMAN functionality that allows you to recover from most problems.

Steps in staging

The set of all operating system files, for example NL.PUB.SYS, etc., are considered the current Base OS. Stage/iX creates and manages staging areas, which are HFS directories that hold versions of files that are different from the Base. More than one staging area can exist at a time. Each staging area contains the difference, or delta, between the Base OS and a patched version of the OS.

When a staging area is activated on the next boot, the files in the staging area are moved into their natural locations while the Base versions of the files are saved in a Stage/iX archive HFS directory. To back out a patch, the reverse takes place and the system is restored to its original state.

Once you are satisfied with the new and patched OS, you can COMMIT the staging area to the Base, deleting the staging area directory and all archived Base files. Note that Stage/iX and Patch/iX allow new patches to be staged and applied in a cumulative fashion. In other words, if you create a new staging area while another staging area is active, the new staging area will contain all the changes between the Base and the active staging area plus all the new changes.

Whether or not you use Patch/iX and Stage/iX, the key to successful OS patching is preparation. Information is the key to preparation. The System Software Maintenance Manual (S2M2) for your particular release of MPE/iX is the bible for all patch management activities. It contains a checklist for each possible update and patch activity along with detailed sections corresponding to checklist items. A hardcopy version and a PDF version on CD usually ship with each major OS release.

A PowerPatch usually comes with some patch-specific documentation – make sure you have it available before you start.

Finally, before you ever sit down at the keyboard, create a Patch Book for the specific patch activity you will be attempting. You can do it with the hardcopy manual and a copy machine, but I prefer to use the PDF version, printing out the two-page checklist and each section that makes up the checklist to create my Patch Book.

How to apply patches

Before proceeding too far, check HPSWINFO.PUB.SYS to ensure the patch has not already been applied. [Note that Patch/iX will tell you if a patch, or even a superceding patch, has already been applied, but it only takes a moment to check HPSWINFO and it could save you some time.] Each patch has an eight character ID. For example, consider TIXMXC3B. The first three characters indicate the subsystem; in this case TIX stands for TurboIMAGE. The next four characters are internal to HP’s patch management mechanism. The final character is the version identifier; in this case “B” indicates the second version of this patch.

First off, identify the proper checklist, in this case Checklist B, and create your Patch Book. Next, review the information about the patches at the ITRC; in particular, look for any patch dependencies.

You need to make sure you have the latest version of Patch/iX installed on your target system. This is critical to your success. All sorts of bad things can happen if you use an old or incomplete version of the Patch/iX bundle. To check the version of Patch/iX, sign on as “MANAGER.SYS,INSTALL” and type in PATCHIX VERSION, The program will respond with something like: Patch/iX Version B.01.09

Once you have the current Patch/iX and your patches, you are ready to run Patch/iX and create your staging area. There are four steps in any run of Patch/iX:

• “Select Activities,” where you define what type of patching activity you want to perform. You have the choice of adding a PowerPatch, adding reactive patches from tape, adding reactive patches from download or adding SUBSYS products.

• “View Patches” (optional): You can actually view information about all the patches that have been applied previously to your system. Note that this can easily number in the hundreds for a system that is kept reasonably up to date.

• “Qualify Patches,” where Patch/iX does a lot of work to determine which patches of the set you supply it with can and/or should be applied.

• Create the stage, the tape, or both that will be used to actually change the OS.

This is all done while normal production continues and places a minimal load on your system. Once you have created your stage with Patch/iX, you run STAGEMAN to activate your staging area with the SET command. The next time you boot your system (and this can be done remotely from your home at 3 AM Sunday morning if you like), your changes will take effect. Total downtime is the time it takes to do a SHUTDOWN followed by a START NORECOVERY.

What if something goes wrong? If you have problems after successfully rebooting your system and you want to back out your patches, simply run STAGEMAN and use the SET command to make the Base the active stage, reboot your system and you are right back where you started. Suppose you cannot even boot the system successfully after setting the stage? Simply boot to the ISL prompt and use STAGEISL (see Fig. 3 below) to set the active stage to BASE, reboot and, again, you are back to where you started.

Figure 3: Using STAGEISL to recover from a SYSTEM ABORT due to a bad patch

Once you are satisfied with your changes after reasonable testing you can again run STAGEMAN and this time use the COMMIT command to make the active stage the Base and free up the disk space occupied by the old Base.

Posted by Ron Seybold at 10:41 PM in Hidden Value, Homesteading | Permalink | Comments (0)

January 26, 2018

Fine-tune: Policing logins, telnet on 3000s

How can I set up a time constraint to a particular login, or group of logins, onto the HP 3000?

If you do not have a security product, you could create a UDC using OPTION LOGON, which would check the system time (for example, < 6:00am OR > 7:00pm), then ECHO a warning to the user, and then issue BYE. You might want to include the OPTION NOBREAK as well.

How can I restrict inbound telnet by IP address?

You can limit incoming telnets to your machine by using the INETDSEC.NET.SYS file. If you haven’t made use of this file previously, there’s a sample file — INSECSMP.NET.SYS — that you can copy to INETDSEC.NET.SYS and make changes from there. You will also need to link it with the Posix name using this command:

NEWLINK /usr/adm/inetd.sec, INETDSEC.NET.SYS

Details are in HP's Configuring and Managing MPE/iX Internet Services manual.

How can I dynamically control hardware compression on my DDS drives?

The name of the command file is devctrl.mpexl.telesup. An example:

xeq devctrl.mpexl.telesup 38;compression=disable

The help command “help devctrl.mpexl.telesup” will display the parameters. 

The full syntax must be entered on a single line:

DEVCTRL.MPEXL.TELESUP dev=(ldev) eject=(enable/disable/nochange)
compression=(enable/disable/nochange) load=(online/offline/nochange)

Posted by Ron Seybold at 08:20 PM in Hidden Value | Permalink | Comments (0)

January 19, 2018

Friday Fine-tune: How to add disks and redesign HP 3000 volume sets

Disk-drive-platter-hp3000I am in serious need of some hardware and hardware setup redesign. Essentially, we have 30GB of disk all in the system volume set and want to add 20GB more and go to multiple volume sets. How do I do this?

This checklist can be used to add new disks and completely redesign the volume sets:

1. Perform two full system backups and verify each.
2. Create a new sysgen tape.
3. Check the new sysgen tape with CHECKSLT.
4. Copy @.@.SYS to a separate tape and verify.
5. Verify all disk drives configured and working properly.
6. Create a BULDACCT job for each new volume set with just the accounts destined for that volume set.
7. Verify that a current full BULDACCT exists on tape.
8. Shut down the system.
9. Restart the system.
10. From the ISL prompt, INSTALL.
11. In VOLUTIL, scratch all drives except for ldev 1.
12. In VOLUTIL, do "NEWVOL volset:member# ldev# 100 100" for each volume in the system volume set (other than ldev 1).
13. In VOLUTIL, do "NEWSET volset member# ldev# 100 100" for the master volume for each new set.
14. In VOLUTIL, do "NEWVOL volset:member# ldev# 100 100" for each volume in each new
15. Restore SYS account files with ;KEEP;SHOW;OLDDATE options.
16. Stream all BULDACCT jobs to create accounts structure.
17. Restore all files with ;KEEP;SHOW;OLDDATE options.
18. Spot-verify applications.
19. Once everything appears OK, run a BULDACCT.
20. Perform a full system backup.

In Step 15 watch out when you restore from a separate tape with @.@.SYS. You want to verify that tape. You'll like the feeling of knowing you can get at least the operating system back up without third-party backup software intervention. (In case you're still using a third-party tool for backups.) 

A few rules of thumb:

1. Don't mix unlike-size drives on a single volume set. This is mostly an operational consideration. Avoid having the small volumes in the set fill up first with plenty of space left on the larger volumes.

2. Put the more critical user accounts on faster, newer disk drives.

3. Set up the volume sets in a business-logical manner. In other words, put accounts in a volume set with other, related accounts, if possible.Try to clearly isolate the volume sets along boundaries.

4. If you're redesigning the disk environment and doing an INSTALL, be sure to have at least two verified backups.

5. Don't be afraid to have a volume set made up of drives configured on multiple controller paths. For example, you might have three single-ended IO controller cards (if it's an older 3000). On a few of your sets, you can have drives from each.

Posted by Ron Seybold at 06:49 PM in Hidden Value, Homesteading | Permalink | Comments (0)

January 12, 2018

Disaster Recovery Optimization Techniques

Newswire Classic

Editor's Note: The 3000s still in service continue to require disaster recovery processes and plans. Here's a primer on crafting what's needed.

By Gilles Schipper
Newswire Homesteading Editor

While working with a customer on the design and implementation of disaster recovery (DR) plan for their large HP 3000 system, it became apparent that the mechanics of its implementation had room for improvement.

In this specific example, the customer has a production N-Class HP 3000 in its primary location and a backup HP 3000 Series 969 system in a secondary location several hundred miles removed from the primary.

The process of implementing the DR was more manual-intensive than it needed to be. As an aside, it was completed entirely from a remote location — thanks to the Internet, VPNs and the use of the HP Secure Web Console on the 969.

One of the most labor-intensive aspects of the DR exercise was to rebuild the IO configuration of the DR machine (the 969) from the full backup tape of the production N-Class machine, which included an integrated system load tape (SLT) as part of the backup.

The ability to integrate the SLT on the same tape as the full backup is very convenient. It results in a simplified recovery procedure as well as the assurance that the SLT to be used will be as current as possible.

When rebuilding a system from scratch from a SLT/Backup, if the target system (in this case the 969) differs in architecture from the source system (N-4000) it is usually necessary to modify all the device paths and device configuration specifications with SYSGEN and then rebooting the system in order to even be able to utilize the tape drive of the target system to restore any files at all.

(This would be apart from the files restored during the INSTALL process — which does not require proper configuration of any IO component at all).

Some would argue that this system re-configuration needs to be completed only once since any future system rebuilds would require only a “data refresh” rather than a complete system re-INSTALL.

I say that this would be true only in very stable system environments where IO configurations — including network printer configurations — are static and where TurboIMAGE transaction logging is not utilized. Otherwise there could be unpleasant results and complications from using stale configurations in a real disaster recovery situation.

In any case, there really is no reason to take any chances, since the labor-intensive step of creating a proper DR target system configuration environment is achievable minus the labor-intensive part – or at least without repetition of the manual chore of re-configuring the target system each time the DR is exercised.

Unless both the production system and the DR system are architecturally similar (i.e. they belong to same HP 3000 family) the configuration of the target system (the DR machine) cloned from the source system (the production machine) will be non-trivial.

At a minimum, before data restore can begin on the DR machine, the path hierarchy of the tape drive associated with the backup tape must be re-created. Further, if the subsequent restore requires more than just the system disk, all the path components for all the disk drives must also be created.

In a real DR situation, this task can be daunting at best – particularly since it may be difficult in that event to be able to access the appropriate documentation that describes the pertinent SYSGEN configuration requirements. It be preferable to complete this configuration well in advance of the hope-it-never-happens event.

In fact, it is entirely possible to create an appropriate DR configuration environment that is (almost) completely integrated into one’s production environment.

SYSGEN IO requirements

In order to provision a potential DR HP 3000 system’s IO configuration requirements into an existing production HP3000 SLT, it is only necessary to configure all of the DR path components into the existing production system’s IO configuration.

The fact that these paths do not exist on the production (source) system is immaterial — as long as you can withstand the menacing, although perfectly innocuous — console error messages that accompany a reboot of a system so configured.

There is also the small matter of actual device numbers — and that is why I included the “almost” when mentioning “completely integrated” earlier.

Clearly, it is not possible to have duplicate device numbers when configuring both production and DR devices into the production SYSGEN IO configuration. So, in order to distinguish between the two systems (one the real production, the other virtual DR), I simply add 100 (you can choose any number) to the device numbers associated with the virtual machine. Then when actually testing or invoking the DR process, it is a simple matter to change the device numbers in a batch job designed for that purpose.

Another batch job could be pre-built that would add the appropriate disk drives and volume sets to the system’s disk pool, using VOLUTIL. These batch jobs would be included in the full backup tape and could be restored almost immediately following the INSTALL by referencing :file tape;dev=107 (to use my example of adding 100 to the corresponding virtual device)

The command :restore *tape;{fileset}; directory;olddate; keep;create;show (where {fileset} corresponds to the fileset that would include the appropriate device number change and volutil batch jobs. One could take this technique one step further in the case where the DR target machine is unknown.

In such a situation, you could create a SYSGEN IO configuration that includes path constructs for any possible virtual machine that you could think of and include them in the host configuration – adding 100 for devices associated with virtual machine 1, 200 for virtual machine 2, and so on.

Posted by Ron Seybold at 07:23 PM in Hidden Value | Permalink | Comments (0)

January 05, 2018

Friday Fine-tune: How to discover the creation date of a STORE tape

Newswire Classic

By John Burke

It is probably more and more likely that, as the years pass by, you will discover a STORE tape and wonder when it was created. Therefore it is a good idea to review how to do this. I started out writing “how to easily do this,” but realized there is nothing easy about it — since it is not well-documented and if you just want the creation date, you have to do a bit of a kludge to get it. Why not something better?

It turns out the ;LISTDIR option of RESTORE is the best you can do. But if you do not want a list of all the files on the tape, you need to feed the command the name of some dummy, non-existent file. ;LISTDIR will also display the command used to create the tape.

By the way, this only works with NMSTORE tapes. For example, when ;LISTDIR is used on a SYSDUMP tape that also stored files, you get something like this (note that even though you are using the RESTORE command, if it contains the ;LISTDIR option, nothing is actually restored):

:restore *t;dummy;listdir


FRI, DEC 31, 2004, 3:22 PM


WED, MAY 7, 2003, 7:06 AM



Posted by Ron Seybold at 10:43 PM in Hidden Value, Homesteading | Permalink | Comments (0)

January 03, 2018

How to make a date that lasts on MPE/iX

January 1 calendar pageNow that it's 2018, there's less than 10 years remaining before HP's intrinsic for date handling on MPE/iX loses its senses. CALENDAR's upcoming problems have fixes. There's a DIY method that in-house application developers can use to make dates in 2028 read correctly, too.

The key to this DIY repair is to intercept a formatting intrinsic for CALENDAR.

CALENDAR returns two numbers: a "year" from 0 to 127 and a "day of year" from 1 to 366.
FMTCALENDAR takes those two numbers and turns it into a string like Monday, January 1, 1900.  It takes the "year" and adds it to 1900 and displays that. "In a sense," explains Allegro's Steve Cooper, "that's where things 'go wrong'."
If one intercepts FMTCALENDAR and replaces it with their own routine, it can say if the "year" is 0 to 50, then add 2028 to it, otherwise, add 1900 as it always did.  That would push the problem out another 50 years.
This interception task might be above your organization's pay grade. If that's true, there are 3000-focused companies that can help with that work. These kinds of repairs to applications are the beginning of life-extension for MPE/iX systems. There might be more to adjust, so it's a good idea to get some help while the community still has options for support.

Posted by Ron Seybold at 11:48 AM in Hidden Value, Homesteading | Permalink | Comments (0)

December 29, 2017

Friday Fine-Tune: Moving DDS stores to disk

Moving-van-640Editor's note: In the last two weeks 3000 owners have been asking about DDS tape storage migration and how to find 38-year-old systems. Here in the last working day for the year 2017, it seems like we're running in a time machine. Here's some help on moving old data to new media.

We're taking Monday off to celebrate the new year. Not many people figured the 3000 would have users working in that 15th year since HP stopped making the server. We'll be back Wednesday with a new story. Seems like anything can happen.

I want to restore some files from a DDS tape to a store-to-disc file. It been a while I am not sure if this is something that can be done. I need some help with the syntax.

Alan Yeo says

I think you need to restore the files from the tape and then store them to disc, as the resulting disc file needs to build a header of the files it contains.

So after restore, the store to disc syntax is something like

!SETVAR BACKUP_FILE "nameoffileyouwantocreate"
!STORE fileselectionstring;*BK;SHOW;PROGRESS=5

Keven Miller adds

There is also TAPECOPY that reads STORE tapes and creates an STD (Store to Disk) on disk -- provided the STORE is all on one tape. I have a copy of the program on my website. Look for TAPECOPY, it's a tar file.

At another location on my site you can see the Text file document, and a .wrq file for using with Reflection with Labels option, or the .std  file which is a store-to-disc.

I also have Tapecpyv, an SPL version usable on both MPE/iX and MPE/V. This SPL one is the latest.

The syntax


Reads the STORE tape on dev 7 into STD file MYSTD.

Posted by Ron Seybold at 05:22 PM in Hidden Value, Homesteading | Permalink | Comments (0)

December 15, 2017

Making a 3000 respond to networks, faster

I have a new HP 3000 A-500 installation that I can't Telnet to. Ping works both ways, but I get nothing with Reflection's Telnet. What do I need to check on the 3000 to get Telnet running?

Robert Schlosser says:

Two things come to mind: Check if the JINETD job is running [run it by streaming JINETD.NET.SYS]; and if the line "telnet 23/tcp" is in your SERVICES.NET.SYS file.

Donna Hofmeister adds:

You also need to have INETDCNF.NET configured.

There's a collection of 'samp' files in .NET that in most cases need to be copied to their 'real' file name in order to make TCP/INETD networking work.

Hofmeister, one of the community's more experienced hands with the standard Unix and Posix utilities built into MPE/iX and the HP 3000, explains.

The samp files are 

BPTABSMP -- bootptab (most people don’t use)
HOSTSAMP -- hosts
INCNFSMP -- inetd configuration
INSECSMP -- inetd security 
NETSAMP  -- reachable networks
NSSWSAMP -- nsswitch
PROTSAMP -- protocol
RSLVSAMP -- DNS resolving
SERVSAMP -- services

I believe each of the files also has a counterpart in /etc which is a link to the real file in .NET.SYS. If the real files are missing from .NET.SYS then many things (including Telnet and FTP) won’t work.
Our N-Class response times have slipped into unusable measurements. Linkcontrol only shows an issue with Recv dropped: addr on one path. Our enterprise network monitoring software sends a packet that the HP 3000 cannot handle. Do I need to shutdown and restart JINETD or restart the network to have my TCP changes in NMMGR take effect?

Craig Lalley wonders:

How are your gateways defined? If you change the gateway


then you could try deleting the wrong gateway and see if it helps. You may have a router broadcasting a wrong gateway.

Hofmeister says the problems might be in the physical layer:

Did you change NMMGR before or after the reboot? If after, you're going to want to reboot again. Your packet loss is disturbing. I'd be suspicious of a physical layer problem.

Problems in the physical layer can be addressed by replacing parts, Mark Landin advises.

  • Could be a bad network cable or connector. Replace them.
    Could be a bad network switch port. Connect the system to another port (properly configured, of course).
  • Could be a bad NIC. Swap them in the 3000 and see if the problem moves with the card.

Hofmeister points back to TCP timer issues"

On PCI (A- and N-Class) systems with 100bt cards, you're more likely to see 'recv dropped: addr' counts due to the way the card handles (or not, actually) traffic routed for a different destination.

Typically these counts are nothing to be concerned about. What is concerning are the TCP statistics.  Retransmits are almost always a function of using the default (or otherwise messed up) TCP timers.

Posted by Ron Seybold at 08:23 PM in Hidden Value | Permalink | Comments (0)

December 01, 2017

Fine-tune Friday: ODE's 3000 diagnostics

DiagnosticsOne diagnostic super-program, ODE, holds a wide range of tests for HP's 3000 hardware. These testing programs got more important once HP mothballed its Predictive Support service for the HP 3000 in 2006. Predictive would dial into a 3000, poke around to see what might be ready to fail, then report to HP's support engineers. ODE's diagnostics are a manual way to perform the same task, or fix something that's broken.

However, ODE includes programs that require a password. Stan Sieler has inventoried what was available in MPE/iX and examined each program for whether it's unlocked for customer use. That was back in the days when 3000 owners were still HP support customers. Today the 3000 owners are customers of third party support firms like Pivital Solutions, or Sieler's own Allegro. The locked programs remain in that state, more than six years after HP shuttered its support operations.

ODE's options received a run-through from Sieler.

Disk Firmware Download Utility 2 (DFDUTIL2)
Version B.02.21 (23rd Sep 2003)
No disks were found.

Note: Didn't seem to want a password. Since Seagate disks are so prevalent, one would expect some means of updating firmware on them ... if firmware updates exist.

Version B.00.23

Note: Needs a password

Note: although it doesn't "see" Seagate drives, you can configure them in and access them.

Version B.00.22
No supported devices found on this system.

Note: doesn't "see" Seagate drives, and you can't configure them in.

Version B.01.12

Needs a password

Version B.01.07
Please wait while the system is scanned for Fibre Channel Adapters...
No Fibre Channel Adapters were found. The test cannot continue. Aborting.

(No password requested up to that point.)

Version A.01.53

Needs a password

WDIAG is the PCXW ODE-based diagnostic program. It tests the processor of the various PCXW-based systems in the offline environment. The program consists of 150 sections, 1/150, which are organized into the following groups

1. CPU data path tests, Sections 1/6 (6 sections)
2. BUS-INTERFACE tests, Sections 7/10 (4 sections)
3. CACHE tests, Sections 11/25 (15 sections)
4. TLB tests, Sections 26/34 (9 sections)
5. CPU instruction tests, Sections 35/86 (52 sections)
6. CPU extended tests, Sections 87/101  (15 sections)
7. Floating point tests, Sections 102/134 (33 sections)
8. Multiple processor tests, Sections 140/150 (11 sections)

Version B.00.35

Version B.00.15

Posted by Ron Seybold at 06:09 PM in Hidden Value, Homesteading | Permalink | Comments (0)

November 03, 2017

Dealing with PCL in modern printer networks

HP 3000s generate Printer Command Language, the format syntax HP created for its line of laser printers. The 3000s were glad to get PCL abilities in their applications and utilities, but PCL is not for everybody. Multifunction devices not schooled in HP technology, such as those from Xerox, need a go-between to extend the 3000's printing.

The easiest and most complete solution to this challenge is Minisoft's NetPrint, written by 3000 output device guru Richard Corn. When we last reported on Corn's creation it was helping the Victor S. Barnes Company pass 3000 output to Ricoh multifunction printers.

But for the company which can't find $995 in a budget for that 3000-ready product, there's a commercial Windows alternative you might try to integrate into your system designs. Charles Finley of Transformix explains that the path to print outside of PCL has multiple steps.

Finley says of the fundamentals:

1. You need to get the print output from the HP 3000 to some device that is external to the HP 3000
2. You may need to intercept the PCL generated on the HP 3000 and format it for the intended device.

On the one hand, you can license the product of either Richard Corn or Minisoft to manage all this -- or if you want to use what MPE provides, you need to intercept the stream by using something that pretends to be an HP LaserJet.

In the second scenario, assuming you can connect the printers to Windows computers, you can use LPD and an interceptor of some kind. A commercial product we have used is RPM from Brooks Internet Software to accomplish the communication part of the process, plus some other PCL translator product to convert the PCL to whatever you need on the printer.

We had two projects in which, instead of the RPM product, we provided our own little interceptor (described at that does the same kind of thing as RPM. We have the Windows machine pretend that it is an HP PCL printer and configure the HP 3000 to print to it. We used other commercial software (two different products) to intercept the output intended for what it thinks is a LaserJet and format the print output so that it prints correctly.

I believe in each case the customers wanted to translate the PCL to PDF and do other stuff with it on the Windows computer before actually printing it. In one case, they wanted to store the PDF on the Windows computer and store reference data in a SQL Server database so that customers could selectively view and print the file at will.

Posted by Ron Seybold at 01:33 PM in Hidden Value, Homesteading | Permalink | Comments (0)

October 27, 2017

Advice on keys for 3000s, and KSAM files

When building a TurboIMAGE database, is it possible to have IMAGE automatically sort a segmented index for the key field?

Gilles Schipper says

No, but you can create TurboIMAGE b-tree index files which allows generic and range searches on items that are indexed - specifically master dataset key items. Only master dataset key items can be associated with b-tree index files.

You can find out more starting at Chapter 11 of the TurboIMAGE manual.

How can I reduce the size of my existing KSAM files? I have removed lots of records from the system and the KSAM files are consuming lots of magnetic real estate, even though there are few records left.

Chuck Trites says

Make a copy of the KSAM file. Then use the verify in KSAMUTIL to get the specs of the file. Purge the KSAMFIL and the KEYFILE if there is one. Build the KSAM file with the specs. FCOPY from the copy to the new KSAM file and you are done. It won't copy the deleted records to the new file.

Francois Desrochers explains

Do a LISTF,5 to get the current key definitions.

Build a temporary output file with all the same attributes:


Copy the records from the original file to the temporary file


Purge the original file and rename the temporary file:


Posted by Ron Seybold at 08:24 PM in Hidden Value, Homesteading | Permalink | Comments (0)

October 25, 2017

OpenSSL's gaps for 3000s surface again

HP did its best, considering what was left of the MPE/iX lab budget, to move the server into modern security protocols. Much of the work was done after the company announced it would end its 3000 business. The gaps in that work are still being being talked about today.

OpensslA message on the 3000 newsgroup-mailing list noted that installing the SFTP package for the 3000 uncovers one gap in software. John Clogg at Cerro Wire said that "I successfully generated a key pair and loaded the public key on the server, but that didn't solve the No key exchange algorithm problem. One posting I found seemed to suggest that the problem was an old version of the SSL library that did not support the encryption the server was trying to use." A note on enabling the 3000's OpenSSL from 2010 still wished for a library newer than what's left on MPE/iX.

The work that remains to be done—so a 3000 can pass sensitive info via SFTP—has been on a community wish list for many years. Backups using SFTP are missing some updates needed to the SSL library. At least the server's got a way to preserve file characteristics: filecode, recsize, blockfactor, type. Preservation of these attributes means a file can be moved to any offsite storage that could communicate with the MPE/iX system. Posix on MPE/iX comes to the rescue.

In the heart of the financial industry in 2003, a modest-sized HP 3000 connected to more than 100 customers through a secure Internet proxy server. That encryption combination was emerging as HP went into its last quarter of sales for the system. But today's standards are miles ahead of those of 2003.

"The old OpenSSL library does not support the ciphers needed to meet current standards," Clogg said. "I was able to make the connection work because the FTP service provider has a configuration setting to enable "insecure old ciphers." Fortunately, this will work for our purposes, but it would be unacceptable if we were transferring banking, credit card or PII data."

The 3000's OpenSSL library is older than 1.01e, which another homesteader says is the cutoff for security that protects from the Heartbleed hacks and RSA key generation compromises.

James Byrne of Hart & Lyne said

The appropriate fix is to update the SFTP client software and associated OpenSSL libraries to versions which possess the high grade key exchange algorithms required by the sshd server. But given the stage of life the HP 3000 has entered, that may not be possible.

We handled a similar problem some time in the past by setting up a Linux host to act as an SFTP proxy. We connected the HP 3000 to the proxy via a cross-over cable to a NIC devoted solely to the HP 3000. Files were then securely transferred between the proxy and the HP 3000 via plain old FTP.

Clogg hoped that "Maybe some porting guru will do a port of the current SSH and SSL libraries someday. In the meantime, James' use of an intermediate server is probably the best solution."

Posted by Ron Seybold at 07:40 PM in Hidden Value, Homesteading | Permalink | Comments (0)

October 20, 2017

Fine-tune: Database passwords, slow clocks

We are trying to access a database on our old system using QUERY and it is asking for a password. I have done a LISTF ,-3 on the database, but there is no lockword listed (which I assumed would be the password). Where do I find the password assigned to a database?

John Burke replied

Assuming you do not have access to the original schema and you want to know what the password is, not just access the database, then sign on as the creator in the group with the database, run DBUTIL.PUB.SYS and issue the command SHOW databasename PASSWORDS.

Mike Church and Joseph Dolliver added

If you just want to access the database, log on to the system as the database creator and, when asked for password, put in a “;” semicolon and hit return.

Why is my system clock running slow? Our HP 3000 loses about one minute per day.

Bob J. replies

One possibility was addressed by a firmware update. HP's text from a CPU firmware (41.33) update mentions:

“System clock (software maintained) loses time. The time loss occurs randomly and may result in large losses over a relatively short time period. Occurrences of the above problem have only been reported against the HP 3000 979KS/x00 (Mohawk) systems. Software applications that perform frequent calling of a PDC routine, PDC_CHASSIS, affect the amount of time lost by the system clock. Your hardware support company should be happy to update for you.”

[Editor's note: as this question was posed a few years ago, today's hardware support company will be an independent one. We've always recommended Pivital Solutions.]

Tongue firmly in cheek, Wirt Atmar noted

My first guess would be relativistic time dilation effects as viewed by an observer at a distance due to the fact that you’re now migrating off of the HP 3000 at an ever accelerating rate. My second guess, although it’s less likely, would be that your machine has found out that it’s about ready to be abandoned and is so depressed that it simply can no longer work at normal speed. We’ve certainly kept this information from our HP 3000s. There’s just no reason that they need to know this kind of thing at the moment.

And in the same vein, Bernie Sherrard added this, referring to HP's promised end of 3000 support on Dec. 31, 2006

Look at the bright side. At a loss of one minute per day, you won’t get to 12/31/2006, until 2 AM on 1/2/2007. So, you will get 26 hours of support beyond everyone else.

Posted by Ron Seybold at 08:57 PM in Hidden Value, Homesteading | Permalink | Comments (0)

October 16, 2017

Getting the Message Across for MPE/iX

MessagesNot long ago, the HP 3000 community was wondering about the limits of message files in the operating system. HP introduced the feature well back in the 20th Century, but only took Message Files into Native Mode with MPE/iX 5.0. That's certainly within the realm of all operating HP 3000s by today. The message file, according to HP's documentation, is the heart of the 3000's file system InterProcess Communication.

Message files reside partly in memory and partly on disk. MPE XL uses the memory buffer part as much as possible, to achieve the best performance. The disc portion of the message file is used only as secondary storage in case the memory buffer part overflows. For many users of IPC, MPE XL never accesses the disc portion of the message file.

Yes, that says MPE XL up there. The facility has been around a long time.

What do you do with message files? A program could open a message file and write a data record every 2 seconds. The data record could be the dateline plus the 2-word return from the CLOCK intrinsic. In another example, a message file could be used to enable soft interrupts. It might then open a log file to write progress messages from the interrupt handler.

HP's examples of using message files are illustrated using Pascal/XL, so you know this is 3000-specific technology. You'd think they'd be little-used by now, but this month the developers on the 3000 mailing list were asking about limits for the number of message files. An early answer was 63, but Stan Seiler used a classic 3000-era method to discover it: testing.

The answer is 4083. Or, why testing counts.

I just successfully opened 4,083 new message files from one process. Since the max-files-per-process is 4095, I suspect I could probably have squeezed in a couple more, but my test program already had some files open.

That this programming facility is still in use seems to suggest it's got utility left. Multiple programs and processes use message files to communicate. HP explains in an extensive document, "Suppose that a large programming task is to be divided into two processes. One process will interface with the user. This process is referred to as the "supervisor" process. It does some processing tasks itself and offloads others to a "server" process. This process only handles requests from the supervisor and returns the results."

Posted by Ron Seybold at 07:29 PM in Hidden Value, Homesteading | Permalink | Comments (0)

October 06, 2017

Staying Secure with MPE/iX Now and Then

Account-relationships-securityThe IT news is full of reports about security breeches. If an Equifax system with 143 million records can be breeched, then Yahoo's 3 billion email accounts were not far behind, were they? Security by obscurity for outward-facing MPE/iX systems isn't much protection. That being said, the high-test security that is protecting the world's most public systems seems to failing, too. A few years ago, the US Office of Personnel Management had its systems hacked. Millions of fingerprints were stolen from there.

Hewlett-Packard built good intra-3000 security into MPE/iX, and third parties made it even more robust. Back in the 1980s I wrote a manual for such a product called EnGarde that made MPE/iX permissions easier to manage. Vesoft created Security/3000 as the last word in protecting 3000s and MPE/iX data. Eugene Volokh's Burn Before Reading was an early touchstone. The magic of SM was a topic explored by 3000 legend Bob Green in a Newswire column.

Homesteading managers will do well to make a place in their datacenter budgets for support of the 3000. Security is built-in for MPE/iX, but understanding how it works might be a lost art at some sites.

The fundamentals of securing an MPE/iX system go way back. A wayback server of sorts at the 3k Ranger website provides HP's security advice from 1994. It's still valid for anyone, especially a new operator or datacenter employee who's got a 3000 to manage. They just don't teach this stuff anymore. 3000s get orphaned in datacenters when the MPE/iX pros move on into retirement or new careers.

The printed advice helps. A direct link to the Ranger webpage can be a refresher course for any new generation of 3000 minders.

Managers of MPE/iX systems need to look out for themselves in securing HP 3000s. Hewlett-Packard gave up on the task long ago. In the era that led to the end of 3000 operations at HP, the vendor warned that its software updates for MPE/iX were going to be limited to security repairs after 2008. They weren't kidding. The very last archived HP 3000 security bulletin on the HP Enterprise website had stern advice for a DNS poisoning risk.

BIND/iX and DNS were marvels for MPE/iX platforms in the 1990s. HP told all its customers early in 2009 that for that year's DNS poisoning, "The resolution is to discontinue the use of BIND/iX and migrate DNS services to another platform." Ouch.

HP's 3000 group did its part to bring the community up to date during that year of 2008. Another resource on the 3k Ranger site is a Powerpoint slide deck from Jeff Bandle, an HP MPE/iX engineer at the time. The presentation of MPE/iX Network Security: An Overview is only nine years old, but by now it appears to represent HP's final word on securing HP 3000 networks. If there's ever any need at a homesteading site to show a network manager which MPE/iX networking services are controlled by configuration files, Bandle's slides have a complehensive list on pages 29-35.

This stuff might be lost if not for the redundant archiving among the community's support resources. A DIY approach is possible for experienced managers. A guide to help navigate the advice is even better. Much of the homesteading community would be best served by a support contract with one of the remaining 3000 resources like Pivital Solutions.


Posted by Ron Seybold at 01:07 PM in Hidden Value, Homesteading, Web Resources | Permalink | Comments (0)

September 29, 2017

Friday Fine-Tune: Libraries, Large Disks

LibraryWhere can I find a list of HP DLT libraries and what version of MPE can drive them?

No libraries are supported on MPE in random mode. While autoloaders can easily be made to work quite well on the HP 3000, one requires specialized software in order to make use of the full functionality of a DLT library. What is important from an HP 3000 point of view is as follows:

• The tape drives in the library must be supported on MPE and can be connected to the 3000. This means the drives must be DDS or DLT4000, DLT7000 and DLT8000. If the system is an HSC (pre-PCI) architecture, the drives must be HVD SCSI. If the system is a PCI system (A- or N-Class,) the drives can also be LVD.

• The connection to the library robot or picker, must also be supported on the 3000, again HSC needs HVD and PCI can do LVD or HVD.

• Finally you must have software that will connect to the picker and drive it. This software can either be running on MPE or on another system, to which the picker is connected. MPE itself cannot drive a robotic library.

I want to install disc drives larger than HP's 144GB. What issues should I consider?

The maximum disk size for MPE/IX is theoretically 2^31 sectors. Due to overhead and rounding DISCFREE output will show 2,147,483,632 sectors for such a disk, this is equal to 549,755,809,792 bytes. So, a disk of this size would likely be sold as a 550 GB disk (powers of ten) though it contains 512 GB from an engineering perspective (powers of two).

Even with the Large Disk Patches, MPE/iX users should be cautious when considering the usage of disks larger than 18-36 GB on MPE/iX systems for the following reasons:

MPE/iX transaction throughput increases when MPE is allowed to spread IO across disks. Even though newer disks are faster than older disks there are limits to disk speed and bus speed which must be taken into account.

Moving from nine 2 GB disks to one 18 GB disk, for example, will often create a disk IO bottle neck. For best performance we recommend that the number of MPE LDEVs never be reduced - if one has nine 2 GB disks then they should be replaced with nine 18 GB disks to ensure no loss of throughput.

The ultimate incarnation of MPE and its lowest (machine dependent) layer was specifically designed for the PA-RISC architecture. This thin layer allowed the MPE lab to create an operating system that had very little shielding from the hardware layer. While the HP-UX approach was to create a (thicker) layer, which allowed for greater hardware independence, MPE’s approach allowed operations to move more expeditiously through the computer, thus giving it the ability to do more (and generate more IO).

I've heard about IMAGE/SQL's dynamic rollback recovery, but need to know more about its applicable intrinsics.

Employing DBXBEGIN, DBXEND, DBXUNDO can be used to protect the unloading of millions of database records. Using MPE/iX’s transaction manager (XM), uncommitted logical transactions can be rolled back dynamically (online) while other database activity is occurring. The dynamic transaction can be rolled back in the following ways:

1. Programmatically with a call to the DBXUNDO intrinsic, or;

2. Automatically when the application aborts or a system failure occurs within the transaction.

The SYSINFO program has crashed our N-Class. In the past, HP just told us don’t run the program. It's always seemed to be a useful tool. What should I watch out for?

From Hidden Value editor emeritus John Burke:

SYSINFO is one of those darling little programs that is available from HP on every system but technically unsupported. The Catch-22 comes in when in various documentation HP suggests you run SYSINFO to check something or other, but then will not support you if something goes wrong.
SYSINFO in the past was notorious for crashing loaded, multi-processor systems when “all”, “mem”, “module” or “cpu” commands were called. As far as I know, this is still a potential problem. It also had the nasty habit of breaking mirrors in a Mirror/iX environment though I believe that has been fixed.

As of MPE/iX 6.5, STM introduced additional complications; for example, “mem” can just start looping chewing up CPU time and never returning information if STM is not running correctly. There are other reports about bogus information being returned. SYSINFO can be a very useful program for displaying information about your system. However, it must be run with great care.

Posted by Ron Seybold at 04:45 PM in Hidden Value, Homesteading | Permalink | Comments (0)

September 22, 2017

Importing CSV Text Into COBOL II

CSV iconI'm importing a Comma Separated Value (CSV) text file into a COBOL II program. I want to compare a numeric field from the file to a number. But the input text field can be different for each record. How do I code in COBOL to accommodate the different number sizes in the text file?

Walter Murray, who worked inside HP's Language Labs where COBOL II was developed before moving out into the user community, noted that Suprtool was likely the best solution to the problem. But after someone suggested that COBOL's UNSTRING statement could be useful, he had his doubts. 

Along with suggesting that "importing the file into an Excel spreadsheet, and saving it in a more civilized format," Murray had these notes.

The UNSTRING statement will be problematic, because one of your fields may have one (or more?) commas in it, and you may have an empty field not surrounded by quotation marks. You might have to roll your own code to break the record into fields.  If you are comfortable with reference modification in COBOL, your code will be a lot cleaner.

Once you do isolate the check amount in a data item by itself, you should be able to use FUNCTION NUMVAL-C to convert it.  Yes, NUMVAL and NUMVAL-C are supported by COBOL II/iX, as long as you turn on the POST85 option.

Olav Kappert offered a long but consistent process.

First thing to do is to not use CVS; use tab-delimited. No problem with UNSTRING. Just use the length field and determine if the length = 0.

Do an UNSTRING of the fields delimited by the tab. Then strip out the quotes. Determine the length of each field and right-justify each field and zero-fill them with a leading zero. Then move the field to a numeric field.

You now have your values. Do this for each field from the unstring. You can create a loop and keep finding the ",".  By the way, determine the record length and set the last byte+1 to "~" so that the unstring can determine the end of record. Long process, but consistent in method.

In addition to generating a CSV file with leading zeroes, Alan Yeo suggested using the X field.

Move the CSV value to a full size X field, then strip trailing spaces, and then move the result to an X redefines of your numeric. Please note, as your numeric is V99, you might also want to strip all "." and "," before the compare.

Dave Powell offered up a general purpose, bullet-proof COBOL program to accomplish the task, fully referenced at the 3000-L newsgroup archive. The entire discussion of the mission is also online at the archives.



Posted by Ron Seybold at 07:05 PM in Hidden Value, Homesteading | Permalink | Comments (0)

September 15, 2017

Friday Fine-tune: Disk and memory checks

The utility cstm has the ability to show the configuration of your current memory installation: the makeup of 3000 memory in terms of boards used. What command delivers this information?

First, enter the MAP command to see a map of the hardware on your system. Each item on the resulting list has a line number. Note the line number for “memory” and use it in the “select device” command, then enter the “info” command. For example, if the memory is device 64:

cstm>select device 64

If you enter the map command now, you will see the status of the memory will be “Information starting” or “information running”. When the status changes to “Information Successful,” you can display the result with the “il” (information log) command. Note: You can avoid the necessity of repeatedly looking at MAP to determine whether the info function has completed by entering “wait” at the prompt following the “info” command. You will not receive another prompt until the info process has completed.

Another answer without using cstm is to run SYSINFO.PRVXL.TELESUP and at the prompt type MEMMAP. You should avoid this solution if using Mirror/iX, since it will break the mirror.]

What MPE command shows me much total hard disk space I have available to me, and how much of that is being used? Also is it possible to break that up per account? For instance, can it tell me how much hard drive space I would gain by purging a particular account?

Use :DISCFREE C for checking disc space used and available by drive and in total. :REPORT z.@ will let you know how much your accounts are using. You may want to run :FSCHECK and do a SYNCACCOUNTING first.

Posted by Ron Seybold at 11:59 PM in Hidden Value, Homesteading | Permalink | Comments (0)

September 08, 2017

Fine-tune Friday: Moving systems quickly

Here in the 14th year after HP stopped building 3000s, customers continue to use them. They use them up, too, and when that happens it's time to move a system from one machine to another. Here's some timeless advice from a net.digest column of the NewsWire on how to move quickly.

How do you move a large system from one machine to a completely new system, including disk drives, in the quickest way possible and minimizing downtime? In this particular case, it is a 7x24 shop and its online backup to a DLT4000 takes 16 hours.

Stan Sieler came up with an interesting approach to this particular problem, an approach that can be extended to solve a variety of problems in large 7x24 shops.

• Buy a Seagate external disk drive.

• Configure the Seagate on both the old system and the new system.

• Connect the Seagate on the old system.

• volutil/newset the Seagate to be a new volume set, “XFER” (REMEMBER: Volume set names can and should be short names!)

• Do one (or more) STORE-to-disks using compression with the target disk being the new Seagate drive.

• When the entire system is backed up onto the XFER disk, VSCLOSE it and unplug it (Caution: The safest approach is to power off your system first.)

• Attach the new disk to the new system (see caution above) and reboot.

• Set up the XFER group on the new system.

:newgroup xfer.sys

:altgroup xfer.sys; homevs=XFER

• restore the data

:file xferA; dev=99 (or whatever ldev XFER is)

:restore *xferA; /; olddate;create (if necessary)

Obviously, this leaves out interesting things like setting up UDCs, directory structure, etc. The point of this note is to introduce the concept of using a 36Gb disk drive as a transfer media.

Bijo Kappen and Patrick Santucci both pointed out that TurboStore’s store-to-disk module is smart enough to create another “reel” when the 4Gb file limit is reached. From the TurboStore/iX documentation:

If STORE fills up the first disk file specified for the backup, it creates as many additional disk files as needed, or uses existing disk files. They will be built with the same default file characteristics as the first disk file. The naming convention used for additional files is to append the reel number to the end of the first disk filename. The resulting name will be an HFS-syntax name. For example, if STORE needed three disk files to store all files, they would be named:




John Lee reported doing the very thing Stan suggested:

“This does work. We do it all the time here when moving information between systems.

“Another variation we’ve found useful is using large, inexpensive, disks for archive purposes. Instead of purchasing often expensive archival devices such as CD or optical jukeboxes, just throw the information on some cheap hard disks inside a cheap enclosure and hang it off your system. Users then have access to all this information online. It might not be right for everybody, but in many cases it is."

Posted by Ron Seybold at 06:58 PM in Hidden Value, Homesteading | Permalink | Comments (0)

September 01, 2017

Steps for a Final Shutdown

Kane-death-deadlineWe're hearing a story about pulling the next-to-last application off an HP 3000 that's run a port facility. At some point, every HP 3000 has to be guided into dock for the last time. These are business critical systems with sensitive data—which requires a rigorous shutdown for sending a 3000 into a salvage yard.

While this is a sad time for the IT expert who's built a career on MPE expertise, doing a shutdown by the numbers is in keeping with the rest of the professional skill-set you can expect from a 3000 manager. I am reminded of the line from Citizen Kane. "Then, as it must for every man, death came to Charles Foster Kane." Nothing escapes death, but a proper burial seems in order for such a legendary system.

Chris Bartram, whose 3k Associates website offers a fine list of public domain MPE/iX software, has chronicled all the details of turning off an HP 3000. "I have performed last rites for a 9x8 server at a customer site," he says, "and have been through the exercise a couple times before."

There are 10 steps that Bartram does before switching off the 3000's power button for the last time.

Bartram reported that he first purged all accounts except sys, hpspool, and 3000devs (and had to log off all jobs, shut down the network, and disable system UDCs to do that). Then:

2) Reset/blanked all system passwords (groups, users, accounts)

3) Purged all groups from SYS account that I could (aside from in-use groups) as well as all users except MANAGER.SYS,OPERATOR.SYS, MANAGER.HPSPOOL.

4) Went through PUB.SYS listf (file by file) looking for anything that might be a job stream or contain user data (or anything not critical to keeping the system up) and PURGEd it

5) Went into VOLUTIL and condensed my discs

6) Created a group called JUNK.SYS (you would need to do this on each volset; this box only had the system vol set)

7) Wrote and ran a short script that copied NL.PUB.SYS (the largest file remaining on the system) into JUNK.SYS in a loop using filenames A####### and X####### until all disc space was used up

8) Typed the command PURGEGROUP JUNK.SYS

9) Went into NMMGR and changed IP addresses on the box to something bland/different; including the default gateway (also deleted any entries in the NS directory if there are any)

10) Sequentially PURGE @.GROUP.ACCT for all groups (leaving PUB.SYS until last)

11) Shut down the box.

Posted by Ron Seybold at 10:23 AM in Hidden Value, Homesteading, Migration | Permalink | Comments (0)

August 25, 2017

SSDs: Not a long-shot to work with MPE/iX

Hewlett-Packard Enterprise is not entirely sure if it's leaving the support forum it once devoted to the HP e3000. (After so many years, "e3000" is still the go-to keyword while looking at the HPE resources that remain online.) To test if the forum was still alive, or entirely in archive stasis, I posed a question. Could an IDE SSD drive get a hookup to a 3000 using an SCSI converter?

Is there enough bus connectivity in the e3000 to install an SSD on the server? There are SSD drives that can link up via IDE and I've found a SCSI to IDE converter.

One reply bounced back on the forum. "Torsten" said, "If this is really an HP3000 server, this sounds like the most crazy tuning idea."

Not so crazy, we've seen. In 2015, after one 3000-L newsgroup user compared putting SSDs in 3000s to a McLaren racing engine in an SUV, a more plausible solution emerged: using SSDs to support a virtualized 3000 running on an Intel-based PC. "You could house your 3000 in a Stromasys emulator running on a Linux box with VMware," said Gilles Schipper of GSA, "employing as many SATA SSD disks as you want on your host."

But there was a time in another May when SSDs running native in HP's 3000 hardware was a possibility worth investigating. It was also a necessity, because it was the only way.

It was almost six years ago, and the Charon emulator was still in development. Extending the future of the HP hardware still a necessity for a homesteading user. Stan Sieler of Allegro said he'd be looking into what would be needed to bring solid state storage to MPE.

"I'm thinking about SSD and SATA/SCSI adapters to speed up the 'obsolete' -- but still world's-best -- business computer, the HP 3000," Sieler said in May, 2009. "I'm hoping to do some tests in the near future."

Sieler said that those SATA/SCSI adapters would be a crucial part of putting SSD on its MPE feet. "Few SSD drives have SCSI interfaces... hence the SATA/SCSI adapter component," he said. "An SSD with a SCSI interface would look completely like an SCSI disk drive."

This kind of design, to mimic the SCSI interface, would've helped to avoid using the SCSI Pass-Through code HP engineered during 2007. The community still hasn't heard reports of how the pass-through works, and HP said that employing it is "not for the faint of heart."

A HP-hardware based 3000 would need to ensure that old hardware could be represented in its original form. An IT shop preserving MPE applications, instead of the platform -- not so much. A virtualized 3000 will do. The Stromasys Charon installations can be run from an SSD.

Posted by Ron Seybold at 07:46 PM in Hidden Value | Permalink | Comments (0)

August 18, 2017

Fine-tune Friday: SCSI codes, and clean-ups for UDCs and 3000 power supplies

Cleanup-siteI need to clean up COMMAND.PUB.SYS on my 3000. There's a problem with BULDACCT. Is there a utility to help manage the UDC catalog?

Stan Sieler replies:

One option is "PURGE," which ships on all MPE systems :) Of course, that means you have to rebuild the UDC catalog. We recently encountered a site where, somehow, an HFS filename had gotten into COMMAND.PUB.SYS. You can't delete UDC entries with HFS filenames, nor can you add them. I had to edit the file with Debug to change the name into something that could be deleted.

Keven Miller adds:

I believe you want the utility UDCSORT from the CSL, the UDC sorting and reorganization program.

There are so many SCSI types. It's got to be the most confusing four letter acronym. Is there a guide?

Steve Dirickson offers this primer:

SE (single-ended): TTL-level signals referenced to ground; speeds from 5 Mhz to 20 MHz

Differential (HVD): something around +/-12V signals on paired wires (old-timers think “EIA 20mA current loop”); same speeds as SE

LVD (Ultra2): TTL-level differential; 40 MHz clock

Ultra160: same as LVD, but data signals double-clocked, i.e. transfers on both clock transitions like DDR DRAM. LVD and Ultra160 can co-exist on the same bus with SE devices, but will operate in SE mode. HVD doesn’t co-exist with anything else.

Upon arrival this morning my console had locked up. I re-started the unit, but the SCSI drives do not seem to be powering up. The green lights flash for a second after the power is applied, but that is it. The cooling fan does not turn either. The  fan that is built into the supply was making noise last week. I can’t believe the amount of dust inside.

Tom Emerson responded:

This sounds very familiar. I’d say the power supply on the drive cabinet is either going or gone [does the fan ‘not spin’ due to being gunked up with dust and grease, or just ‘no power’?] I’m thinking that the power supply is detecting a problem and shutting down moments after powering up [hence why you see a ‘momentary flicker’].

Denys Beauchemin added:

The dust inside the power supply probably contributed to its early demise. It is a good idea to get a couple of cans of compressed air and clean out the fans and power supplies every once in a while. The electrical current is a magnet for dust bunnies and other such putrid creatures. 

Tom Emerson reminisced:

Years ago at the first shop where I worked we had a Series III and a Series 48. Roughly every 3-6 months an HP technician would stop by our office to perform Preventative Maintenance. Amazingly, we had very few hardware problems with those old beasts. Once we didn't have a tech coming out to do PMs anymore, we had hardware related failures, including a choked-up power supply fan on a disk cabinet.

Finally, Wayne Boyer said"

Any modular power supply like these is relatively easy to service. It is good advice to stock up on spares for older equipment. Just because it’s available somewhere and not too expensive doesn’t mean that you can afford to be down while fussing around with getting a spare shipped in.

The compressed air cans work—but to really do a good job on blowing out computer equipment, you need to use an air compressor and strip the covers off of the equipment. We run our air compressor at 100 PSI. Note that you want to do the blasting outside! Otherwise you will get the dust all over where ever you are working. This is especially important with printers as you get paper dust, excess toner and so forth building up inside the equipment. I try and give our equipment a blow-out once a year or so. Good to do that whenever a system is powered down for some other reason.


Posted by Ron Seybold at 01:47 PM in Hidden Value, Homesteading | Permalink | Comments (0)

August 11, 2017

Friday Fine-Tune: A Diagnostics Tour

Newswire Classic
From Stan Sieler

There are two kinds of diagnostics: online and offline.

The online come in two flavors:

1. Older releases of MPE/iX have online diagnostics accessed via SYSDIAG.PUB.SYS (which is a script that runs DUI.DIAG.SYS). (MPE/iX 6.0 and earlier, possibly MPE/iX 6.5 (I'm not sure))

2. Newer releases of MPE/iX have online diagnostics accessed via CSTM.PUB.SYS (which is a script that runs /usr/sbin/stm/ui/bin/stmc).

Both are, well, difficult to use. (HP-UX also switched from sysdiag to stm.) Both have some modules that require passwords, and some that don't.

The offline diagnostics are on a bootable CD or tape. The lastest offline diagnostics CD (for PA-RISC) that I could find was labelled "2004."

That CD has seven diagnostics/utilities. I tried running all of them on an A-Class system. The "ODE" one is special; it's a program that itself hosts a number of diagnostics/utilities (some of which require passwords).

I'm not saying these diagnostics are "password-protected," because that implies they need protecting. "Password restricted" or "password deprived" might be a more accurate phrase. :)

filename type start size created
XMAP -12960 832 1568 04/08/10 17:12:26
ODE -12960 2400 880 04/08/10 17:12:26
EDBC -12960 31344 1696 04/08/10 17:12:26
EDPROC -12960 33040 6928 04/08/10 17:12:26
MULTIDIAG -12960 39968 6256 04/08/10 17:12:26
TDIAG -12960 46224 7216 04/08/10 17:12:26
CLKUTIL -12960 53440 240 04/08/10 17:12:26

ISL> tdiag
...probably doesn't require a password (can't run on A-Class)

ISL> clkutil
no password

ISL> edproc
...probably doesn't require a password (can't run on A-Class)

ISL> edbc
...probably doesn't require a password (can't run on A-Class)

ISL> xmap
...probably doesn't require a password (can't run on A-Class)

ISL> multidiag
****** MULTIDIAG ******
****** Version A.01.12 ******
Enter password or a <CR> to exit:

All the rest from here on are ODE utilities/diagnostics. I ran each one, and document whether or not it requires a password. (A few utilities seem to have little or no use because HP hasn't provided a method of saying "Hey, my disk drive isn't an HP drive, and it's over here.")

ISL> ode (collection of diags/utilities, each different) 

****** Offline Diagnostic Environment ******
****** TC Version A.02.26 ******
****** SysLib Version A.00.78 ******
****** Loader Version A.00.62 ******
****** Mapfile Version A.01.61 ******

(ODE) Modules on this boot media are:

filename type size created description
README2 TM 63 04/07/13 64 bit version that displays README fil
MAPPER2 TM 146 04/07/13 64 bit version of the system mapping ut
MEM2 TM 257 04/07/13 64 bit Memory diagnostic
AR60DIAG2 TM 590 04/07/13 Fibre Channel 60 disk array utility (64
ARDIAG2 TM 682 04/07/13 64 bit version of the ICE & ICICLE disk
ASTRODIAG2 TM 273 04/07/13 64 bit version of the ASTRO IO Controll
COPYUTIL2 TM 320 04/07/13 64 bit version of the Disk-to-tape copy
DFDUTIL2 TM 264 04/07/13 64 bit version of the Disk firmware dow
DISKEXPT2 TM 241 04/07/13 64 bit version of the expert disk utili
DISKUTIL2 TM 222 04/07/13 64 bit version of the nondestructive di
NIKEARRY2 TM 324 04/07/13 Nike disk array utility
VADIAG2 TM 906 04/07/13 hp StorageWorks Virtual Array Utility
WDIAG TM 1084 04/07/13 CPU diagnostic for PCX-W processors
IOTEST2 TM 880 04/07/13 64 bit version that runs ROM-based self
PERFVER2 TM 126 04/07/13 64 bit version that runs ROM-based self

ODE> mem2
****** Version B.02.27 ******
Enter password or a <CR> to exit:

ODE> ar60diag2
****** AR60DIAG2 ******
****** Version B.03.29 ******
Enter password or a <CR> to exit:

ODE> ardiag2
****** ARDIAG2 ******
****** Version B.05.11 ******
Enter password or a <CR> to exit:

ODE> astrodiag2
****** ASTRODIAG2 ******
****** Version B.00.25 ******
Enter password or a <CR> to exit:

ODE> copyutil2
****** COPYUTIL2 ******
****** Version B.01.11 (19th Mar 2004) ******

no password
NOTE: didn't seem to want to see Seagate disk drive.

Copy Utility (COPYUTIL) Help Menu

UTILINFO - Shows information on COPYUTIL including quick start info.

HELP - This menu, or use HELP <help item> for more detailed help.

DISPMAP - Displays the devices found.

TAPEINFO - Reads the header of a tape and displays the information,
such as the product string and path of the disk, the
creation date, the vol #, and so forth.

TAPEDRVINFO - Reads the hard compression mode of a tape drive and
displays the information.The info is only available for SCSI/FIBRE DAT tape drives.

DRVINFO - Shows inquiry information of any disk drive or tape drive.

TLINFO - Shows inquiry information for a Tape Library/Autochanger. The addresses of robot hands, magazine slots and tape drives are listed there.

TLMOVE - Moves a tape from a magazine into a tape drive, or vise versa.

BACKUP - Copies data from a disk to tape(s).

RESTORE - Copies from tape(s) back to a disk (The tape must be made with COPYUTIL's BACKUP command).

VERIFY - After a successful BACKUP, by VERIFY user may double check the contents of the tape(s) with the data on the disk.

COPY - Copies from a disk device to another disk device. The supported devices are restricted to SCSI devices so far.

FORMAT - Formats a given disk back to its default values.

TERSEERR - Turns on or off the terse error flag. Default is off.

IGNOREERR - Turns on or off the ignore error flag. Default is off.

ODE> dfdutil2

****** Disk Firmware Download Utility 2 (DFDUTIL2) ******
****** Version B.02.21 (23rd Sep 2003) ******
No Disks were found.

Didn't seem to want a password.

Since Seagate disks are so prevalent, one would expect some means of updating firmware on them ... if firmware updates exist.

ODE> diskexpt2
****** DISKEXPT2 ******
****** Version B.00.23 ******
Enter password or a <CR> to exit:

Note: although it doesn't "see" Seagate drives, you can configure them in and access them. 

ODE> diskutil2
****** DISKUTIL2 ******
****** Version B.00.22 ******
No supported devices found on this system.

Note: doesn't "see" Seagate drives, and you can't configure them in.

ODE> nikearry2
****** NIKEARRY2 ******
****** Version B.01.12 ******
Enter password or a <CR> to exit:

ODE> vadiag2
****** VADIAG2 ******
****** Version B.01.07 ******
Please wait while the system is scanned for Fibre Channel Adapters...
No Fibre Channel Adapters were found. The test cannot continue. Aborting.

(No password requested up to that point.)

ODE> wdiag
****** WDIAG ******
****** Version A.01.53 ******
Enter password or a <CR> to exit:

(from a friend:)

WDIAG is the PCXW ODE based diagnostic program. It is intended to test the Processor of the various PCXW based systems in the offline environment. The program consists of 150 sections, 1/150, and are organized into the following groups:

1. CPU data path tests, Sections 1/6 (6 sections)
2. BUS-INTERFACE tests, Sections 7/10 (4 sections)
3. CACHE tests, Sections 11/25 (15 sections)
4. TLB tests, Sections 26/34 (9 sections)
5. CPU instruction tests, Sections 35/86 (52 sections)
6. CPU extended tests, Sections 87/101 (15 sections)
7. Floating point tests, Sections 102/134 (33 sections)
8. Multiple processor tests, Sections 140/150 (11 sections)

ODE> iotest2
****** IOTEST2 ******
****** Version B.00.35 ******

no password required

ODE> perfver2
****** PERFVER2 ******
****** Version B.00.15 ******

no password required

Posted by Ron Seybold at 03:00 PM in Hidden Value, Homesteading | Permalink | Comments (0)

August 04, 2017

Friday Fine-Tune: HP 3000 DLT vs. DDS

Dlt Backing up enterprise-grade 3000s presents interesting choices. Back in the 1990s when the 3000 being built and sold by HP, DDS at first had only two generations, neither of which were reliable. A DDS tape used to be the common coin for OS updates and software upgrades. The media has advanced beyond a DDS-4 generation to DAT-360, but Digital Linear Tape (DLT) has a higher capacity and more reliability than DDS.

When a DDS tape backup runs slower than DLT, however, something is amiss. DLT is supposed to supply a native transfer rate of 15 MBps in the SureStore line of tape libraries. You can look at an HP PDF datasheet on the Ultrium SureStore devices certified by HP for MPE/iX at this link.

HP 3000 community partners such as Pivital Solutions offer these DLTs, At an estimated cost of about $1,300 or more per device, you'll expect them to beat the DDS-3 transfers of 5 MBps.

When Ray Shahan didn't see the speed he expected after moving to DLT and asked the 3000 newsgroup community what might be wrong. Advice ranged from TurboStore commands, to channels where the drives are installed, to the 3000's bandwidth and CPU power to deliver data to the DLT. Even the lifespan of the DLT tape can be a factor. HP's MPE/iX IO expert Jim Hawkins weighed in among the answers, while users and third-party support providers gave advice on how to get the speed which you pay extra for from DLT.

Dave Gale wrote in an answer that device configuration and CPU are potential problems:

If you are using a DLT it likes to get data in a timely manner. Otherwise it will do the old 'shoe shine'. This means that other devices on the line can affect the bandwidth on the channel and starve the DLT. If you are using something like RoadRunner, then the CPU can be a real factor in this equation (especially single-CPU machines). So, you may not only want to check the statistics portion of the report, but monitor your machine during backup with Glance or SOS.

Gilles Schipper of GSA said that a TurboStore command is essential. "If you're using HP TurboStore, are you using MAXTAPEBUF option on STORE command?" MAXTAPEBUF and INTER can make a major difference, cutting a backup to DLT  from 7 hours to under 2 by  adding the parms.

HP's Hawkins said channel configurations of backup devices are key to ensuring that DLT tops the DDS speed:

Generally this shouldn’t happen. It might happen if the DLT and disc are on the same channel while the DAT/DDS was on a separate one. Might also happen with large numbers of small files on semi-busy system as some DAT are better at start/stop than DLT. If you are running STORE the STATISTICS option can give a broad indication of throughput for A/B comparison.

One simple piece of advice is to try a new DLT tape, too.

Posted by Ron Seybold at 01:53 PM in Hidden Value, Homesteading | Permalink | Comments (0)

July 28, 2017

Fine-Tune Friday: Moving Backup Files

Editor's note: Today's 3000 technique talk is written by Brian Edminster, an HP 3000 veteran who's been maintaining MPE/iX apps in a support role for many years. Edminster's experience goes back into the 1980s, making him a good match for some of the classic MPE/iX apps that are still serving companies. He's available for contract or long-term engagements through his company Applied Technologies.

By Brian Edminster 

First of two parts

Once store-to-disk backups are regularly being processed, it’s highly desirable to move them offsite — for the same reasons that it’s desirable to rotate tape media to offsite storage. You want to protect against site-wide catastrophic failures. It could be something as simple as fire, flood, or a disgruntled employee, or as unusual as earthquake or act of war.

Regardless of the most pressing reason, it really is important to keep at least some of your backups offsite, so as to facilitate rebuilding / recovering from scratch, either at your own facility, or at a backup/recovery site.

The problem comes in that the MPE/iX file system is far more structured than Unix, Windows, or any other non-MPE/iX file system-based storage mechanisms. While transferring a file off MPE/iX is easy via FTP, sftp/scp, or rsync, retrieving it is problematic, at least if you wish the retrieved files and the original store-to-disk files to be identical (i.e., with the same file characteristics: filecode, recsize, blockfactor, type, and so forth).

What would be optimal is automatic preservation of these attributes, so that a file could be moved to any offsite storage that could communicate with the MPE/iX system. Posix on MPE/iX comes to the rescue.

For FTP transfers between late-model MPE/iX systems this retrieval is automatic, because the FTP client and server recognize themselves as MPE/iX systems.  For retrieving files from other systems, HP has made that somewhat easier by making its FTP client able to specify ‘;REC= , CODE= , and ;DISC=’ on a ‘GET’:

Figure 1If you do not specify the ‘buildparms’ for a file being retrieved, it will default to the file-type implied by the FTP transfer mode: ASCII (the default), binary, or byte-stream (often called ‘tenex’ on Unix systems).  The respective defaults used are shown below:

Figure 2 GreyWhat follows is an example of automatic preservation of these attributes, so that a file could be moved to any offsite storage that could communicate with the MPE/iX system.  And this is yet again where Posix comes to the rescue, via the venerable ‘tar’ (Tape ARchiver), or ‘pax’ archiving utilities.

‘pax’ is a newer backup tool, designed to be able to read/write with tar format archives, newer ‘ustar’ format (that includes Extended Attributes of files). At the same time it has a more ‘normal/consistent’ command syntax (as Unix/Posix stuff goes, anyway), plus a number of other improvements. Think of it as tar’s younger (and supposedly more handsome) brother.

A little known feature of most ‘late-model’ tar and all pax commands is the ability for it to recognize and utilize Extended Attributes.  These will vary with the target implementation platform, but for the tar and pax commands included with releases after v5.5 of MPE/iX this capability is not only present — but contrary to the man command’s output and HP’s Posix Command Line manual, it’s the default! You use the -A switch to turn it off, returning tar to a bytestream-only tool.

While not externally documented, via a little experimentation I’ve determined that the following series of Extended Attributes value-pairs are in the MPE/iX Posix implementation of a tar or pax ‘file header’ for each non-Posix file archived:

MPE.RECORDSIZE= value in bytes
MPE.BLOCKFACTOR= integer value
MPE.RECORDFORMAT= integer value (0=unstructured?)
MPE.CCTL= integer value (0=nocctl)
MPE.ASCII= integer value (0=binary, 1=ascii)
MPE.FILECODE= integer value, absent for ‘0’
MPE.FILELIMIT= value in bytes
MPE.NUMEXTENTS= integer value, may be absent
MPE.NUMUSERLABELS= integer value (0=no user labels), and
MPE.USERLABELS=[binary content of user labels]

Posted by Ron Seybold at 08:58 PM in Hidden Value | Permalink | Comments (0)

July 21, 2017

Friday Fine-Tune: Nike Arrays 101

Newswire Classic
by John Burke

Many 3000 homesteaders have picked up used HP Nike Model 20 disk arrays. For many years there has been a glut of these inexpensive devices on the market and they work with older models of HP 3000s. However, there is a lot of misinformation floating around about how and when to use them. One company posted the following to 3000-L:

Nike_Model_20_In_Close_Up“We’re upgrading from a Model 10 to a Model 20 Nike array. We're deciding whether to keep it in hardware RAID configuration or to switch to MPE/iX mirroring, since you can now do it on the system volume set. We’re considering the performance issue of keeping Nike hardware RAID versus the safety of MPE Mirroring. How do you switch from one to the other? You can use the second Fast and Wide card on the array when using MPE mirroring, but you can’t when using Model 20 hardware RAID."

“So, with hardware RAID, you have to consider the single point of failure of the controller card. If we ‘split the bus’ on the array mechanism into two separate groups of drives, and then connect a separate controller to the other half of the bus, you can’t have the hardware mirrored drive on the other controller. It must be on the same path as the ‘master’ drive because MPE sees them as a single device.

"Using software mirroring, you can do this because both drives are independently configured in MPE. Software mirroring adds overhead to the CPU, but it’s a trade-off. We are evaluating the combination of efficiency, performance, fault tolerance and cost.”

First of all, Mirrored Disk/iX does not support mirroring of the System Volume Set – never did and never will. Secondly, you most certainly can use a second FWSCSI card with a Model 20 attached to an HP 3000.

Another poster elaborated on the second controller. All of the drives are accessible from either controller but of course via different addresses. Your installer should set the DEFAULT ownership of drives to each controller. To improve throughput each controller should share the load. Only one controller is necessary to address all of the drives, but where MPE falls short is not having a mechanism for auto failover of a failing controller.

In other words, sysgen reconfiguration would be necessary to run on a single controller after SP failure in a dual SP configuration. You could have alternate configurations stored on your system to cover both cases of a single failing controller but the best solution is to get it fixed when it breaks. The best news is that SP failures are not very common.”

There is a mechanism in MPE for ‘failover’ called HAFO: High Availability FailOver. Unfortunately it is only supported with XP and VA arrays and not on Nike arrays or AutoRAIDs.

“We have seven Nike SP20 arrays," said Andrew Popay, "totaling 140 discs spread across all the arrays, using a combination of RAID 1 (for performance) and RAID 5 (for capacity). We use both SP’s on all arrays, with six arrays used over three systems (two per system). One of our systems has two arrays “daisy-chained.” The only failures we have suffered on any of the arrays have been due to a disc mechanism failing.

"We never find any issues with the hardware raiding; in fact, as a lot of people have mentioned, hardware raiding is much more preferred to software raiding. Software raiding has several issues, system volume, performance, ease of use, etc. Hardware raiding is far more resilient.

“As for anyone concerned about single points of failure, I would not worry too much about the Nike arrays, I would say they are almost bullet proof. For those who require a 24x7 system and can’t afford any downtime what so ever, maybe they should consider upgrading to an N-Class, with a VA or XP. Bottom line: SP20’s are sound arrays on the HP 3000s, easy to configure, setup and maintain.”

Posted by Ron Seybold at 06:36 PM in Hidden Value | Permalink | Comments (0)

July 07, 2017

Fine-tune Friday: opening disk, adding HASS

I need contiguous file space for my XM log file. How do I get this?

Many operations on the HP 3000 require contiguous disk space. Other files also require contiguous space; for example, consider the contiguous disk space on LDEV 1 required for an OS update. If you do not have one of the several third-party products that will create contiguous disk space on a drive, you may still be able to get enough free space by using CONTIGVOL.

However, occasionally, CONTIGVOL will stop with a message of “*Warning: Contigvol - Inverse Extent Table Full, Internal resource limit.” What can you do? Run it again. HP’s Goetz Neumann reported the message "is a warning that an internal table has filled up. It appears CONTIGVOL only handles looking at 40,000 extents at a time. You can run CONTIGVOL multiple times if the first run does not condense the free space enough because of this limitation.

I am adding two drives to a HASS (Jamaica) enclosure that already has several drives. How do I do this?

Gilles Schipper, Lars Appel and Chris Bartram reply:

First, a note of caution. If you dynamically add disk drives to, say, your MPEXL_SYSTEM_VOLUME_SET, you could find yourself in a pickle if you subsequently perform a START RECOVERY by accident or design. So while you can add drives dynamically as a convenience, it is a good idea to schedule a SHUTDOWN, START NORECOVERY as soon as possible to “fix” the new drives in your base configuration.

You do not even have to take down the system to add the drives to an HASS enclosure. The following steps will do the job.

• Set proper SCSI IDs. Make sure the SCSI addresses of the HASS enclosures are what you believe them to be. Do not make any assumptions. You need to set the SCSI address dip switches properly and ensure they are unique for the controller they are attached to. You will probably need a little flashlight to check the settings.

• Plug in the new drives.

• Use IOCONFIG to add the appropriate paths and device IDs. Note that the ldevs cannot be in use by, for example, vt or telnet sessions. So, you may still need to do this “off hours.”

• Use VOLUTIL to NEWVOL or NEWSET. For example, 

>newvol mpexl_system_volume_set:member99 99 100 100 

(This example is for LDEV 99 — the “99” in member99 does not need to correspond to the LDEV number, it only needs to be unique for that volume set.)

It might be a good idea to first run the drives in a NEWSET for a while, exercising them a little. You could also use that extra volume set to exercise seldom used VOLUTIL commands or NEWACCT options like ONVS/HOMEVS. Finally, SCRATCHVOL them and add them to the desired volume set.

Posted by Ron Seybold at 09:55 PM in Hidden Value, Homesteading | Permalink | Comments (0)

June 30, 2017

Fine-Tune Friday: Jazz refuge, Query-JCL tip

Editor's Note: We're taking Monday July 3 off to celebrate Independence Day, and we'll be back on July 5 with a new report.

Where did the files HP hosted on go? So many articles reference that HP 3000 labs site.

The Jazz server contents were moved to several servers. A system at Speedware (a company now called Fresche Legacy) has much of what was hosted on Jazz. Those Jazz links at Speedware (now Fresche Legacy, and deeply absorbed with IBM iSeries work) are tucked away under Not exactly the place where you'd look for homesteading tools, but available anyway.

How can I supply to QUERY a variable from within a JCL job? The physical paperwork for a file on the 3000 is being copied to digital format. We mark the files as deleted, (logically, not physically). Tracking this destroyed paperwork is done manually (a tedious and error prone process). How can I write something on the 3000 to create a comma delimited file of files shredded the day before?

John Long replies

This may help:

PREVDATE = 20170607

I'm not sure how (or even if) query reads variables. (Nothing in the manual about it). Which is why you might have to 'build' your jobstream daily and replace the date in the 'USE file.'

Keven Miller shares this QUERY XEQ file

!setvar qdate1 "20170606"
!setvar qdate2 "20090710"
!echo find date=![qdate1] > q1
!echo find date=![qdate2] > q2
xeq q1

xeq q2


Then the spoolfile

Priority = DS; Inpri = 8; Time = UNLIMITED seconds.
Job number = #j25.
WED, JUN 7, 2017, 2:38 PM.
HP3000 Release: C.60.00 User Version: C.60.02
MPE/iX HP31900 C.16.01 Copyright Hewlett-Packard 1987.
All rights reserved.
STREAM DATE: WED, JUN 7, 2017, 2:38 PM

:setvar qdate1 "20170606"
:setvar qdate2 "20090710"
:echo find date=![qdate1] > q1
:echo find date=![qdate2] > q2

HP32216D.03.20 QUERY/NM WED, JUN 7, 2017, 2:38 PM

xeq q1

find date=20170606

Posted by Ron Seybold at 07:31 PM in Hidden Value | Permalink | Comments (0)

June 23, 2017

Friday Fine-Tune: A 3000's Intrinsic Savvy

Homer-at-blackboardAs the clock counts down to the 10-year deadline for calendar services changes, our thoughts turn to HPCALENDAR. That's the intrinsic HP wrote for the 6.0 and 7.x releases of the 3000 OS, a new tool to solve an old problem. Alas, HPCALENDAR is fresher than the bedrock CALENDAR, but it's only callable in the 3000's Native Mode.

But poking into the online resources for MPE Intrinsics, I learned that once more HP's re-shelved its 3000 docs. Things have gotten better: everything now lives on the much-better-focused HP Enterprise website. You can, for the moment, locate the guidelines to intrinsics for MPE/iX at

The Intrinsics Manual for MPE/iX 7.x is also a PDF file at Team NA Consulting. Independents like Neil Armstrong help the community that's using HP's resources for 3000s these days. It used to be much simpler. In the 1990s, the Interex user group ran a collection of well-written white papers by George Stachnik. We're lucky enough to have them with us today, cut loose from ownership and firewalls. One is devoted to the system's intrinsics.

By the time The HP 3000--for Complete Novices, Part 17: Using Intrinsics was posted on the 3K Associates website, Stachnik was working in technical training in HP's Network Server Division. He'd first written these papers for Interact, the technical journal devoted to 3000 savvy for more than two decades. Even though Interact is long out of print, Stachnik's savvy is preserved in multiple web outposts.

Stachnik explains why intrinsics tap the inherent advantage of using an HP 3000.

When an application program calls an MPE/iX intrinsic, the intrinsic places itself in MPE/iX's "privileged mode." The concept of privileged mode is one of the key reasons for the HP 3000's legendary reputation for reliability. Experienced IT managers have learned to be very wary of application programs that access system internal data structures directly. They demand that MPE/iX place restrictions on HP 3000 applications, to prevent them from doing anything that could foul up the system. This is what led to the development of the intrinsics. Application programs running in user mode can interact with the operating system only by invoking intrinsics.

Even if your company has a migration in mind, or doesn't have an unlimited lifespan for the 3000, knowing how intrinsics work is an intrinsic part of learning 3000 fine-tuning that might be inside classic applications. Tools can help to hunt down intrinsics, but it helps to know what they do and what they're called. You can fine-tune your 3000 knowledge using Stachnik's papers and HP's Intrinsic documentation.

Posted by Ron Seybold at 08:34 PM in Hidden Value, Homesteading | Permalink | Comments (0)

June 16, 2017

Friday Fine-Tune: Cleaning Up Correctly

Classic 3000 Advice
By John Burke

Good intentions about maintenance sometimes stumble in their implementation. As an example, here’s a request for help on cleaning up.

Cleanup-tools“We have a 989/650 system. Every weekend we identify about 70,000 files to delete off the system. I build a jobstream that basically executes a file that has about 70 thousand lines. Each line says ‘PURGE’. This job has become a real hog. It launches at 6 AM on Sunday morning, but by 7 PM on Sunday night it has only purged about 20,000 files. While this job is running, logons take upwards of 30 seconds. What can I do?”

This reminds me of the old joke where the guy goes to the doctor and complains “Gee, doc, my arm hurts like hell when I move it like this. What can I do?” The doctor looks at him and says “Stop moving it like that.” But seriously, the user above is lucky the files are not all in the same group or he would be experiencing system failures like the poor user two years ago who was only trying to purge 40,000 files.

In either case, the advice is the same; purge the files in reverse alphabetic order. This will avoid a system failure if you already have too many files in a group or HFS directory, and it will dramatically improve system performance in all cases. However, several people on the 3000-L list have pointed out that if you find you need to purge 70,000 files per week, you should consider altering your procedures to use temporary files. Or if that will not work, purge the files as soon as you no longer need them rather than wait until it becomes a huge task.

If all the files are in one group and you want to purge only a subset of the files in the group, you have to purge the files in reverse alphabetical order to avoid the System Abort (probably SA2200). PURGEGROUP and PURGEACCT will be successful, but at the expense of having to recreate the accounting structure and restoring the files you want to keep. Note that if you log onto the group and then do PURGEGROUP you will not have to recreate the group.

Craig Fairchild, MPE/iX File System Architect explained what is going on. “Your system abort [or performance issues] stem from the fact that the system is trying desperately to make sure that all the changes to your directory are permanently recorded. To do this, MPE uses its Transaction Management (XM) facility on all directory operations.

“To make sure that the directories are not corrupted, XM takes a beginning image of the area of the directory being changed, and after the directory operation is complete, it takes an after image. In this way, should the system ever crash in the middle of a directory operation, XM can always recover the directory to a consistent state - either before or after the operation, but not in a corrupted in-between state.

“On MPE, directories are actually just special files with records for each other file or directory that is contained in them. They are stored in sorted alphabetical order, with the disk address of the file label for that file. Because we must keep this list of files in alphabetical order, if you add or delete a file, the remaining contents of the file need to be “shifted” to make room, or to compact the directory. So if you purge the first file alphabetically, XM must record the entire contents of the directory file as the before image, and the entire remaining file as the after image.

“So purging from the top of the directory causes us to log data equal to twice the size of the directory. Purging from the bottom of directory causes XM to log much less data, since most of the records stay in the same place and their contents don’t change. The system abort comes from the fact that more data is being logged to XM than it can reliably record. When its logs fill completely and it can no longer provide protection for the transactions that have been initiated, XM will crash the system to ensure data integrity.”

Goetz Neumann added, “PURGEGROUP (and PURGEACCT) do not cause a SA2200 risk, since they actually traverse the directory in reverse alphabetical order internally. This is useful to know for performance reasons. Since these commands cause much smaller XM transactions, it is faster to empty a group by logging into it and then PURGEGROUP it, instead of using PURGE @.

“There is a little-known tool to help prevent you from running into these situations in the first place: DIRLIMIT.MPEXL.TELESUP. A suggested (soft) limit for directory files would be 2MB. This would limit MPE to not have more than 50,000 files in one group, and (very much depending on the filenames) much less than 50,000 files per HFS directory. (These are XM protected just as well, and tens of thousands of files in an HFS directory is not a good idea from a performance standpoint, either.)

“Another way to reduce the risk of SA2200 in these situations would be to increase the size of the XM system log file (on the volume set that holds the group with the large number of files), which is available in a VOLUTIL command.

Posted by Ron Seybold at 08:59 AM in Hidden Value, Homesteading | Permalink | Comments (0)

June 09, 2017

Friday Fine-Tune: Split up MPE/iX versions

Multiple-personalitiesHas anybody had success trying to split a single HP 3000 system into two different OS versions by using two sets of disks? There is no need for sharing of information between the two operating systems, and they would run independently of each other at different times of the day.

Guy Paul replies:
This is certainly possible, as we have done this in the past for customers who couldn’t tolerate any downtime for OS upgrades. Hence, we came up with a solution to have a duplicate set of SYSVS discs that we upgraded while they were still on the old OS. Come day of the ‘real’ OS upgrade, we brought them down, stored off any modified files, switched over to the new OS, restored any modified files and they had an OS upgrade in about 45 minutes. So it is possible.

You should probably consider using BULDACCT to synchronize the accounting structure.

Gilles Schipper adds:
This should be entirely possible. I do this sort of thing all the time. By simply booting from the appropriate boot path, you can do exactly as you wish. In fact, I have even shared common volume sets among different LDEV 1 system volume sets, with different MPE versions.

What's the name and syntax of the Posix utility that allows you to assign a new file, give the file the same name as the one you're replacing—and the new file will replace the old file when the last user closes it?

Andreas Schmidt replies:
You want to use mv, a utility to rename and move files and directories. The syntax is

mv [-fi] file1 file2
mv [-fi] file... directory
mv -R|-r [-fi] directory1 directory2

Where do I start to configure my HP Laser printer to be a network printer off the HP 3000. Don’t I need steps for I need steps for the NMMGR process?

Jeff Woods replies:
Odd as it might seem, network printing isn’t configured using NMMGR but instead depends on SYSGEN devices with the ID HPTCPJD, plus a text file called NPCONFIG.PUB.SYS defining each printer LDEV.

(This might have more than one LDEV associated with each IP address, perhaps to give different environments such as landscape vs. portrait or duplex printing or special margins or line spacing as needed).

The process is pretty well documented in Chapter 3 of HP's Native Mode Spooler Reference Manual (tip of the hat to NA Consulting for the manual link).

Posted by Ron Seybold at 06:32 PM in Hidden Value | Permalink | Comments (0)

June 02, 2017

Sendmail fine-tunes, if you still need delivery

By Andreas Schmidt,
with Mark Bixby, and Jens von Bülow

Relying on the HP 3000, you may want to use this box for incoming and outgoing e-mails as well. This is possible using a collection of software bundled with the HP 3000, or available in the public domain:

• Sendmail/iX, the mail transport agent well known on HP-UX that was ported to MPE/iX;

• Syslog/iX, the event logging subsystem required by Sendmail/iX;

• MAILX.HPBIN.SYS, the mail reader, and;

• Qpopper, the POP3 protocol for downloading.

Sendmail/iX and Syslog/iX have been ported to MPE. MAILX.HPBIN.SYS is part of the Posix shell part of each MPE/iX release since 4.5. The combination of all four of these utilities will enable your HP 3000 to receive Internet e-mails sent to you@host.domain and send Internet e-mails into intranets.


Syslog is the standard event logging subsystem for Unix. It consists of a server daemon, a client function library, and a client command line utility. It is possible to log to files, terminal devices logged on users, or forward to other syslog systems. Syslog can accept data from the local system via an AF_UNIX socket, or from any system on the network via an AIF_INET UDP socket on port 514. The sendmail mail transport package is one of the Internet tools which log to syslog. Syslog/iX is bundled with MPE/iX in the SYSLOG account. If somebody was a little too aggressive about cleaning up unused FOS files, you can restore the SYSLOG account from the backup of your OS. Otherwise, you can locate your FOS tape and manually extract and install the SYSLOG account.


Sendmail is a mail transport that accepts fully formatted e-mail messages from local host system users, queues the messages, and then delivers the messages to local or remote users. It listens on TCP port 25 for incoming SMTP messages from remote systems, and delivers these messages to local host system users by appending the message text to the user’s mailbox file.

Sendmail is not a mail user agent. It does not have the ability to compose or to read e-mail. To cover this functionality, HP bundled the program /SYS/HPBIN/MAILX into the shell utilities. Sendmail is also not a POP3 server that will enable network clients to access Sendmail/iX mailboxes.


This program helps read and send electronic mail messages. It has no built-in facilities for sending messages to other systems. But combined with other programs (a mail routing agent and a transport agent like Sendmail/iX) it can send messages to other systems. MAILX only offers limited support for various message headers (i.e. Subject:, From:, To:, Cc:, etc). If you need to do anything fancy, like MIME headers, you’ll need to call SENDMAIL.PUB.SENDMAIL directly and pass it a fully formatted message containing all headers and body text.

To read messages from your mailbox in /usr/mail/ type :MAILX.HPBIN.SYS

To send messages use :MAILX.HPBIN.SYS [options] user1 user2 ... An :EOD finishes the message text.

The files in /usr/mail/ are named USER.ACCOUNT and are accessible only for this user.


Qpopper is a server that supports the POP3 protocol for downloading Internet e-mail from software clients. Qpopper does not include a message transfer agent or SMTP support but normally works with standard Unix mail transfer agents such as sendmail. On MPE/iX it works therefore perfectly with Sendmail/iX.

The installation procedure basics are:

• The link /usr/local/bin/popper must point to /SYS/ARPA/POPPER.

• In SERVICES.NET.SYS, port 110/tcp must be reserved for pop3 service.

• INETDCNF.NET.SYS must start this service via pop3 stream tcp nowait MANAGER.SYS /SYS/ARPA/POPPER popper.

• For relaying via Sendmail/iX, a file /etc/mail/relay-domains must exit in mode 644 (-rw-r—r—) owned by MGR.SENDMAIL.

Having successfully installed this, you may now change your Internet browser so that your HP 3000 is the incoming POP3 server. You may do as we did: we created a new account POP3 with plain vanilla users per mailbox. The PC e-mail client needs to be configured in the following way:

Server Name: your POP3-enabled HP 3000

Server Type: POP3 Server, User Name: USER1.POP3 (e.g., SCHMIDA.POP3)

You may want to remember to set a password and an adequate check time for new e-mail. It’s up to you whether you want to download the new messages to the PC and not to keep on the host or not.

A nice feature is the aliasing in Sendmail/iX. Your HP 3000 acts as a POP3 and SMTP server for all Internet e-mail software agents.

Is there a proper way to shut down sendmail?

• Use the Posix kill signal from SERVER.SENDMAIL or any user with SM capability. (The following can be easily turned into a job.)

kill $(head -n 1 /etc/mail/

• Only use :ABORTJOB as a last resort! (This is true for all of the Posix things that got ported to MPE)

If you don't need to run a mail server (e.g. sendmail) on your 3000, you shouldn't. In most cases, using a mail client will be "just the ticket." Point the client at your in-house (SMTP) mail server and enjoy.


Posted by Ron Seybold at 07:29 PM in Hidden Value, Homesteading | Permalink | Comments (0)

May 26, 2017

Friday Fine-Tune: Tape to Disk, Posix time fix

C1539 tape driveEditor's Note: Monday is the Memorial Day holiday here in the Newswire's office. We'll be back with a new article on May 31. With every day that passes, HP's original hardware gets older and more likely to fail. Virtualization of hardware brings newer hardware into service with 3000s and helps with this problem, a risk that's greatest on the 3000's moving components. Especially tape drives like the C1539 above; even HP's discs are less likely to fail. Enjoy this advice on how to put stored data from tape into a store-to-disk file, as well as keeping dates accurate in MPE/iX's Posix name space.

I have some information on a tape. How do I create a store to disc file with it?

There are a few solutions. The first and easiest is to simply restore the info to a system (RESTORE *T;/;SHOW;CREATE;ACCOUNT=WORKSTOR) where WORKSTOR is an account you create to pull the data in.  Then a simple FILE D=REGSFILE;DEV=DISC and STORE /WORKSTOR/;*D;whatever else should create the disc store.

The second is to use FCOPY. The STORE format is FILE TAPEIN;DEV=TAPE;REC=8192,,U,BINARY.

John Pitman adds, "If you mean copy it off tape to disk store file, I’m not sure if that can be done. In my experience with tapes, there is a file mark between files, and EOT is signified by multiple file marks in a row. But it may be possible. If you do a file equate and FCOPY as shown below, you should be able to look at the raw data, and it should show separate files, after a file list at the front.


Here is our current store command, and the message it provokes. MAXTAPEBUF speeds it up somewhat


Why is the date/time in the Posix shell way off from the time on MPE, and what can be done to fix it? It’s over three weeks off.

Homesteading Editor Gilles Schipper replies:

First, check to ensure your timezone offset is correct and there are no pending time clock changes.


SYSTEM TIME: TUE, OCT 19, 2010,  5:46:38 PM

If the incorrext timezone and/or time correction is non-zero, you can fix both with the :SETCLOCK command.

Next, ensure that the TZ variable is appropriately set. This can be done with a system logon UDC that executes the following:

comment the following is for Eastern Time
comment use the following for california

Posted by Ron Seybold at 06:11 PM in Hidden Value, Homesteading | Permalink | Comments (0)

May 12, 2017

How to Step Through a CSLT Reinstall

Stepping-stonesAssume you've seen your Series 918 crash to its bones. You replace the 3000 and need to reinstall from CSLT. Many a 3000 site hasn't done this in a long time. This is when you're getting in touch with your independent support company for advice and walking the steps to recovery.

Oh. You don't have a support company to call. One more thing that's been dropped from the budget. You could ask on the 3000 newsgroup for help, so long as your downtime isn't serious. This support strategy is one way to go, and James Byrne got lucky this week. One expert walked him through the critical steps.

"I am working my way through the check-lists for reinstalling from a CSLT," Byrne said, "and I have come to the conclusion this stuff was written more to obscure than to illuminate." The HP documentation advised him to boot from disk, something he couldn't do. "Fortunately this is a backup 3000, and nothing too bad can happen yet."

Gilles Schipper, our esteemed homesteading contributor, provided the answers. The problem lay in a bad boot drive, but how do you discover that's true? We'll get to that in a bit. First, the CSLT reinstall.

"Assuming you have no user volume sets:

1. Mount CSLT in appropriate drive and boot from alternate path
2. From prompt, type INSTALL
3. At completion, boot from primary path and START NORECOVERY (this is your second "boot".)
4. Mount whichever tape contains your directory (could be the CSLT or your latest full backup - if directory on both, use whichever is more current)
5. Log on as MANAGER.SYS and restore directory (:file t;dev=?;restore *t;;directory - note 2 consecutive;)
6. Use VOLUTIL to add additional discs to MPEXL_SYSTEM_VOLUME_SET.
7. Mount backup tape and:
:restore *t;/;keep;create;olddate;partdb


Ah, but what to do if you have user volume sets?

"So," Schipper said, "with user volume sets:

Modify step 6 to read as follows:
6. Use VOLUTIL to add additional discs to MPEXL_SYSTEM_VOLUME_SET, as well as any additional user volumesets that you have.
The approprite VOLUTIL commands you will need are:
1. NEWVOL command to add additional volumes to the existing MPEXL_SYSTEM_VOLUME_SET
2. NEWSET command to add first (master) volume of user-volumeset1, say
3. NEWVOL command to add additional volumes to user-volumeset1
4. repeat 2 and 3 for each additional user volumeset

Then, prior to step 7, add step 6A, which is the repeat of step 5, which is to AGAIN restore the directories from the tape containing the directories so that they are restored to the master volumes of their respective user volumesets.

And then step 7 remains as before.

The bad LDEV1 discovery? You can always swap out a known good drive. Byrne did this and noted he had to restock his cache of backup drives. "Only three left," he said. "Time to order more, perhaps." Advice on checking for bad drives before a boot:

"Instead of INSTALL, type ODE," Schipper said. "Then run Mapper. That should show you all of your devices including hard drives. Although that may even show drives that cannot be INSTALL'ed to. Also, check all of your SCSI terminators."

Stan Sieler added this to the remedies for a bad disk. "Try doing:

  start norecovery message

"That 'message' option will cause 'start' to generate a **LOT** of output. Hopefully, the last few dozen lines might provide a clue to the problem."

Do all the backup that you need when protecting that HP 3000. The success of its backups falls in the lap of the system's managers. (Running CHECKSLT from the TELESUP account will verify if a CSLT is still good enough to boot your system. You'll want to check that CSLT to ensure it'll run on any tape drive, not just the one it usually runs on. Alignment issues kick DDS drives out of service regularly.) Don't forget about keeping your CSLT healthy.

Posted by Ron Seybold at 03:53 PM in Hidden Value, Homesteading | Permalink | Comments (0)

April 28, 2017

Friday Fine-tune: directories and tombstones

ByetombstoneA 3000 manager wanted to know about adjusting privileges on their server. When the community's veterans started to respond, extra information rose up. Some of was about the management of files in MPE/iX, the kind of legacy recorded on what's known as a tombstone.

Tombstones are data used to solve 3000 problems and establish file access. HP says in its manual for programming in MPE/iX that "It's frequently necessary to obtain status information on a file to determine the cause of an error." A File Information Display is frequently called a tombstone, providing:

  • Actual physical and operational file characteristics.
  • Current file information, pertaining to end of file, record pointer, and logical and physical transfer count. Information on the last error for the file and the last HPFOPEN or FOPEN error.
  • When a file is opened, the final characteristics may be different from those originally requested because of defaults, overrides, :FILE commands, and the file label.

You can use the PRINTFILEINFO intrinsic to print a tombstone. It requires that you specify the file number returned when the file is opened by HPFOPEN or FOPEN. The tombstone can display either a full or short format.  If the file is open, it provides a full display. Otherwise, it provides a short display. Calling this intrinsic does not automatically abort the program.

You can call the PRINTFILEINFO intrinsic from programs written in COBOL II/XL and HP FORTRAN 77/iX. When calling from COBOL II/XL, use the FD filename. You can call the name PRINTFILEINFO directly from HP FORTRAN 77/iX programs. You can obtain the required file number by using the FNUM intrinsic.

Tombstones came up after one list member resurrected an answer about privileges from a 11-year-old post. Ray Shahan, still managing archival systems for Republic Title of Texas, heard his name in discussion about TD and RD privileges and how to control them. He quipped about not being heard from in ages.

"I have been asked by our security group to remove TD and RD privileges from our HP 3000," Reggie Monroe wrote this week. "These are for Reading and Traversing Directories. Does anyone know what the impact of this would be, if any?"

Tracy Johnson replied that "Unless your users have access to Posix files, you can categorically state you don't have any to remove."

There is an old comp.sys.hp.mpe posting where Ray Shahan wants to add TD and RD privileges. Just do the opposite, though that may be a bad thing if applied to MPE groups and accounts treated as directories.

The original TD and RD posting

The advice from the 2005 discussion included using Posix to enable "execute" permissions on all directories needed to get to the directory you want. So the opposite would be to disable those permissions. The ALTSEC command does this.The process will also include adding ACDs to the directory.

Once considered a new feature of MPE/iX, Access Control Definitions are pseudo bits of information on the HP 3000.

ACDs are ordered lists of pairs.The pairs are made up of access permissions and user specifications that control access to objects. Objects are passive entities that contain or receive information, such as files, directories, and devices. Each entry in the ACD specifies object access permissions granted to a specific user or group of users. In addition to being granted access to an object protected by an ACD, users can also be granted access to read the ACD itself.

ACDs can be applied to any MPE/iX files using the ALTSEC command. This command was enhanced to support directories. If a file has an ACD, this method of specifying access to the file takes precedence over other security features, such as lockwords and the file access matrix. ACDs cannot be placed on root, account, group, or directories.


Posted by Ron Seybold at 11:37 AM in Hidden Value, History, Homesteading | Permalink | Comments (0)

April 10, 2017

3000 backup strategy for closing Sundays

ClosedOnSundayEaster Sunday is on this week's horizon. While it's a rare day of closure at our local HEB grocery chain, Sundays are another sort of closure for 3000 managers. Nearly all of them want their partial backups of the weekdays to wrap up before the backup begins that will serve the work week. If you do full backups every night and want to make the new strategy to do partials during the week and a full on Sunday, there's a way to make that work. Donna Hofmeister, one of the former OpenMPE directors, explained the strategy in a message to 3000 managers.

First you need to decide what kind of partial you want to do.  On Tuesday, do you want to backup all files changed since Sunday's full backup or do you want to backup all files changed since Monday's backup?  (and so on....)

There are some things to think about here. If your "line in the sand" is always Sunday, then you have to deal with knowing that by Friday/Saturday your "partial" backup is likely going to be sizeable and will take longer to run. On the other hand, if you ever have to do a big restore, your restore plan is plan is pretty simple -- you'll need your last partial and your last full backup.

If your "line in the sand" is always yesterday, then your "partial" backups will be relatively small and quick. The flip-side is your big restore could be very complicated, since you'll need every partial backup through Monday plus your full backup. I think most people set the backup date as "Sunday" and do partials from there. But there's a technical bit that's also important.

The bit concerns the command restore ....;date>=!my_lastfull. Donna went on to explain.

"!my_lastfull" is a CI variable that contains a date in "mm/dd/[yy]yy" format.  This is a value that your *full backup job* needs to establish.  So your full backup job should do something like:

         file lastfull,old
         echo !hpmonth/!hpday/!hpyear>*lastful

Your partial job will need to do something like this:

         file lastfull,old
         input my_lastfull < *lastfull

There's plenty of logic that needs to be added to the above examples. (You'll note that there is NO error checking/what-if handling, etc.) This should be enough to get you started.

On incremental vs. differential backups — the former is a backup of changed files since the last full OR partial. The latter is a backup of changed files since the last full.

HP's wisdom about date management for the built-in STORE facility for HP 3000s is in several places. 3K Ranger's Keven Miller volunteered his, and Neil Armstrong's TeamNA Consulting has a downloadable one on file as well.

Posted by Ron Seybold at 07:40 PM in Hidden Value, Homesteading | Permalink | Comments (0)

April 07, 2017

Friday Fine-Tune: Creating the perfect CSLT

Editor's note: A classic technique, detailed here by the NewsWire's Hidden Value editor emeritus John Burke.

PerfectTapeA question about creating a CSLT for a Disaster Recovery test turned into a general discussion about what the perfect CSLT should look like. A system manager wanted to use the STORE option on the SYSGEN TAPE command to store additional files onto the CSLT he was creating for his DR test but was running into trouble trying to specify STORE options as part of the SYSGEN TAPE command. In particular, he wanted to simply add ;SHOW to get a listing of all files stored.

The answer to his original question is to use an indirect file, as in


where the indirect file contains whatever STORE directives you want in addition to the file list.

One contributor recommended robust efforts to get a listing: “A backup tape is of limited value without a listing. For Disaster Recovery purposes it is also a good idea to have the original HP tapes and patches with you as it is possible to create an SLT that does not install or work on a different HP 3000 system.” This same contributor also suggested creating a disk file with a listing of all the stored files.

However, several people questioned whether this list of files which the thread originator had proposed storing was sufficient. Stan Sieler probably said it best:

“I’d put much more in the STORE section, at the minimum:


(To explain, NL, SL, XL are dumped in the CSLT portion, so no need to dump them in the STORE section; DUMPAREA is a 32Mb file created at INSTALL time and there’s absolutely no need to dump it to a tape.)

(or wherever you put your dumps.)

(It’s surprising how much you might want tools at an early stage.)

“If most of your user data is in one or two accounts, other than SYS, TELESUP, and the rest of the system might fit well onto one DDS/DLT, you might find it more useful to do:


(where USERS, SALES are the ‘user’ accounts)

“Why? It guarantees you’ll get everything you’re likely to need in a recovery/install situation (except, of course, for the major portion of the user’s data). I’d also specify:

;show;directory=MPEXL_SYSTEM_VOLUME_SET,…etc.; progress;partialdb

Posted by Ron Seybold at 07:14 PM in Hidden Value, Homesteading | Permalink | Comments (0)

March 30, 2017

Puts, Gets, and Serving Up Transfers Faster

Server TrayHP 3000s are exchanging files with other servers, a process that's included the FTP protocol for more than 15 years. This capability was once so magic that the arrival of Samba file exchange on MPE/iX was lauded as a breakthrough. FTP is quite a ways off the most current of transfer protocols. One manager's started a discussion about how to improve transfer speeds to and from the 3000, though. He's using DSCOPY as well, but prefers the PUTs and GETs of FTP.

The advice that's current about FTP/iX says that hard-coding the 3000's ports (100mb full duplex, or 10mb half) is one way to speed things up. Ensuring your traffic is not running through a proxy (called "being proxied) is another idea. Measuring the speed of a PUT against a GET is one step in discovering why the 3000's FTP might seem slow.

In 2008, MPE/iX gained a secure version of FTP—at least part of one. This SFTP functionality arrived at the end of the Hewlett-Packard lab era for 3000s, a period when new tools were not being placed into wide use. Sites were locking down their 3000 scope of operations to ensure stability. The port of this then-current functionality fell short of complete: only an FTP secured client got created. PUTs could be secured, as well as GETs. But only from Windows, Unix, or Linux hosts to the 3000. The 3000 wasn't going to dish out files using secured FTP. There are notes in place to carry the work forward, though.

MPE/iX tools and components are also out there to complete this securing of file transfers. OpenSSH is the best-known protocol. A quick-start bundle can be downloaded from the MPE-OpenSource website run by Applied Technologies. There are SFTP installation instructions at Applied, too. Someone who's got a need for securing FTP transfers will need to do the server side of the porting, which was completed on the client side by Ken Hirsh, Mark Bixby, and Mark Klein. Requests to speed up FTP are a sign this porting would be more than just an open source hobby project.

Brian Edminster, the senior consultant at Applied Technologies, explained that "with a bit of work, you could get OpenSSH v 3.7.1p2 working. The issue is that 'select' is busted under MPE/iX, and that's what's required for ssh to work correctly."

The fact remains: ssh cannot connect to a remote system and execute commands that produce any output. Ken Hirsch did the original port, but he only really needed the SFTP client -- so the issue with ssh wasn't addressed.   

Ken also posted on the 3000-L newsgroup in 2008, asking if there was any interest in getting an ssh and sshd/sftp-server working (server daemon) -- so the 3000 could do port forwarding, act as a SFTP server, receive inbound ssh connections, and so on. Apparently he didn't get enough response to carry forward.

Back in 2005, Hirsch posted his goal. 

I could get an interactive ssh client to work on MPE/iX.  I don't know how, but I know it's possible! It would not be possible to get an ssh server working in such as way that an ssh client could run any program. But it would be possible to get enough of the server running so that you could use the server to do port forwarding.

In 2008, he added the note which Edminster referenced. "If anybody knows a way to actually write to a terminal while there is a read pending," Hirsch said, "I could use OpenSSH as a server on the HP 3000. Apparently there are undocumented MPE/iX sendio() and rendezvousio() calls, of which I know nothing. There are also tread()/twrite() routines in libbsd.a that I think are intended for this, but there's no documentation for these, either."

Posted by Ron Seybold at 07:11 PM in Hidden Value, Homesteading | Permalink | Comments (0)

March 17, 2017

Friday Fine-Tune: Moving all disks at once

I want to take all my disks, system volume set, and the user volumes, and move them to another machine that has no disks. How can I best do this?

Lars Appel replies

You might use SYSGEN to create two different config groups in the SYS account, one for the old system (e.g. CONFOLD), and one for the new system (e.g. CONFNEW). To create the new config you might start with one of the existing config templates, e.g. CONF9x8.SYS for 3000/9x8 systems. Use BASEGROUP to open it, adjust IO to your needs and KEEP it as CONFNEW.

7935Just make sure that every disk gets an LDEV in the new config. Paths and LDEVs (except for LDEV 1) do not need to be the same on the new system. MPE/iX will notice (and "collect") all available volumes during bootup (as long as they are "visible" by a configured LDEV number).

Shutdown the system, plug disks into the new box, power it on, boot from the primary path (or enter the appropriate path for LDEV 1) and at the ISL prompt do a START NORECOVERY [NOSYSSTART] GROUP=CONFNEW.

You might also need to adjust NMCONFIG with NMMGR as a different system will probably have the LAN cards at a different physical path. In case you make a copy of NMCONFIG, make sure it stays on LDEV 1 (FILE;DEV=1).

We replaced LDEV1 on our HP 3000, did an INSTALL. Then we did
The MPE-filespace was restored normally, but the HFS filespace was not. RESTORE told me to use CREATE=PATH which I then did. The DIRECTORY is on my STORE tape - so what went wrong?

Wolfgang Kinscher, and Gilles Schipper reply:

If you are planning an install keep this in mind: Do not specify the option "DIRECTORY" with a partial (DATE>=) backup. STORE will not put the HFS directory structure on tape. Do the following instead: STORE ;*T;DIRECTORY stores all of your MPE/HFS directories on tape. Then do your partial backup without DIRECTORY option

After the install, first restore your DIRECTORY with RESTORE *T;;DIRECTORY and then restore your partial and your latest full backup respectively.

Posted by Ron Seybold at 09:13 PM in Hidden Value | Permalink | Comments (0)

March 10, 2017

Friday Fine-Tune: Going Beyond JBOD

By Gilles Schipper

Mod 20sOne of the most cost-effective ways of advancing the reliability of your legacy system may be to replace your existing “JBOD” disk system with a much more reliable disk system. MOD20 units, still a better deal than individual disks, can provide a good starting point to implement RAID. JBOD is an acronym meaning “just a bunch of disks” — which would characterize the majority of HP 3000 systems as they were initially sold. JBOD disk systems comprise a set of independent — typically SCSI-connected — disks, which are each seen by the HP 3000 as a single logical device number or LDEV. Each disk LDEV is associated with a “volume set” and the failure of a single disk renders the “volume set” to which it belongs inoperable and un-accessible.

Traditionally, most 3000 systems have comprised a single volume set (specifically, the required SYSTEM volume set, with the brevity-challenged label “MPEXL_SYSTEM_VOLUME_SET”).

Systems comprising a large number of “JBOD” LDEVs increased the likelihood of system downtime, since the failure of a single, old disk effectively resulted in a “down” system — requiring a time-consuming disk replacement and system reload before the system could properly function once again.

To mitigate such delicate exposure to a single disk failure, many installations implemented the “User Volume Set” feature built in to MPE/iX, then constructed multiple volume sets so that the failure of a single disk affected only the volume set to which it belonged.

For practical purposes, the only real benefit to this approach was to reduce the amount of time required to replace the disk and reload only the data residing on the affected volume set. (In reality, it was usually quite unusual for a system to continue normal, or even minimal operation with even a single unavailable volume set).

To further improve system reliability and minimize downtime an optional, additional-cost software  product was available in the form of software mirroring — aka “MPE/iX mirroring.”

This enabled the system administrator to configure non-system volume set disk drives to be associated with  identical corresponding “mirror” disks. The software was responsible for dynamically duplicating the contents of  both disk drive “mirrors” such the failure of one of the two mirror drives could be tolerated without affecting the continuous operation of the system. The damaged disk could then be replaced and the dynamic disk duplication would resume.

Only if both mirror pairs failed would there be a corresponding system outage and data loss. However, software mirroring was still far from ideal. Since it was unavailable for the MPEXL_SYSTEM_VOLUME_SET, the failure of a system disk, unprotected by mirroring software, would result in certain system down time.

Further, software mirroring exacted a price in terms of CPU and I/O overhead that could otherwise be utilized for actual “useful” processing. 

And, as a wise person once said, given a choice, a feature is almost always better implemented in hardware than software. This certainly applies to disk mirroring and nicely aligns with the the Nike MOD20 RAID disk system, which is (one of the) HP 3000’s solutions to the compromises associated with software mirroring.

The MOD20 features dual controllers, duplicated (even triplicated) power supplies, and up to 20 disk drives housed in a single frame/enclosure that provides significant improvements over the MPE/iX software mirroring functionality.

Each MOD20 provides for a maximum of 8 logical units (LUN’s) to be configured — each of which appears as a single logical device no. (LDEV no.) to the HP 3000. A maximally and optimally configured MOD20 will include 20 disk drives and be configured as follows:

14 disks to be defined as type RAID1, using up 7 LUNS—since each LUN comprises two separate mirrored disks. RAID level 1 is equivalent to simple mirroring whereby one disk is dynamically maintained as a duplicated mirror image on its mirrored twin disk, which must of identical size and model.

If one disk of the mirrored pair fails, the other disk can take over the responsibility of presenting the requisite data IO to and from the host system with no perceived performance degradation. The remaining 6 disks can be configured as a single LUN comprising 4 RAID 1/0 disks and 2 hot spares.

A RAID 1/0 configuration takes an even number of disks and duplicates the contents of half of them (as a group) onto the other half.

The hot spares would act as dynamic replacements for any disk in the MOD20 that fails, such that even the  failure of one or two disks would not prevent the entire disk subsystem from maintaining its fail-safe mirroring capability. Without the hot-spare feature, failure of a single disk would allow normal system activity to continue but without further fail-safe capability for the failing LUN only.

Chances of both disks in the same LUN failing are extremely remote. That is why I advise you to forgo the hot spare capability. Utilize a 6-disk RAID 1/0 LUN instead of a 4-disk RAID 1/0 LUN, giving you additional usable disk space overall.

Posted by Ron Seybold at 08:04 PM in Hidden Value, Homesteading | Permalink | Comments (0)

March 03, 2017

When and how to back up 3000 directories

Editor's Note: Homesteading Editor Gilles Schipper weighs in on  using the 3000's store directory option, rather than invoking the buldacct program, to make clean backups.

By Gilles Schipper
Homesteading Editor 

CityDirectoriesIt's common to see confusion surrounding the use of the ;directory store option versus the buldacct directory creation program. In order to benefit from the store ;directory option, one has to utilize the option almost perfectly in both the store and the restore following a system INSTALL. Consequently, it becomes much easier to fall back on the buldjob options to re-create the directory -- although that option is inferior.

In order to be able to effectively utilize the directory option, the first thing that must be done properly is to ensure that the appropriate ;onvs= option is also used in the case where user volumesets are utilized. Otherwise, the non-system volumeset directories do not get restored after the INSTALL since they are not on the tape.

But even if the store part is done correctly, the other opportunity to go wrong presents itself during the reload process.

The proper procedure during reload is as follows:

1. perform INSTALL
2. restore ;directory from tape
3. re-create disk and volumeset environment via VOLUTIL

Then -- and this where many go wrong,

4. Again restore ;directory from tape (this re-creates the volumset directory environment on the master volumes for all user volumesets for those utilizing it)
and then
5. restore files
6. reboot with start norecovery (to enable network functionality)

Of course, for those that do not utilize user volumesets, the directory option becomes much less error-prone. And, for those that utilize third-party backup utilities, the ;directory option -- as utilized in the MPE store command -- is generally replaced with a similar option in the various backup utilities.

The bottom line: for those that utilize the MPE store command to perform their backups, the properly-used ;DIRECTORY (and, if appropriate) corresponding ;ONVS= options) -- together with correct restore procedures as indicated above -- will get the desired result 100 percent of the time. Notwithstanding, of course, any tape issues occurring, which would be problematic no matter which directory re-creation option is used.

The bottom line is that the proper way to perform a full backup if you're using the MPE backup facility:

:file t;dev=tape
:store /;*t;partdb;directory;onvs=mpexl_system_volume_set,big;

Of course, upon further reflection, and better than the store command: use sysgen to create a backup tape that not only contains all files, but also the SLT -- so that this one tape alone can be used to INSTALL and RELOAD your system. The use of sysgen for such purpose will require use of an indirect file.

Posted by Ron Seybold at 09:12 PM in Hidden Value, Homesteading | Permalink | Comments (1)

February 24, 2017

Friday Fine-Tune: Opening Up MPE's Shell

Way back in the middle 1990s HP added the Posix shell to the HP 3000. The improvement meant customers who had Unix and MPE running in the same shop could train operators and managers with a single set of commands. Posix was a plus, making the 3000 appear more Unix-like (which seemed important at the time).

Over the years, however, Posix has been a feature waiting be discovered for most 3000 managers and operators. The computer's operating system was renamed from MPE/XL to MPE/iX just for this added Posix feature. But enough history; Posix is still on the 3000 and remains a powerful interface tool, an alternative to the CI interface that HP created for the system. You can even call Posix commands from the CI, a nifty piece of engineering when it can be done.

That's not always possible, though. A customer wanted to know how to "expand wildcard shells" using Posix. He tried from the CI and had this story to relate.

ls: File or directory is not found

So how do I do this? I need to be able to tell tar to archive all of the reels of a STD STORE set via a regexp. It does not work in tar, and it apparently does not in ls—so I speculate that there is something special about the innovation of Posix utilities from the CI that I am not aware of. What is it?

Jeff Vance, the 3000 CI guru at while at HP, replied "Wildcards on most (all) Unix systems, including Posix implementations, are done by the shell, not the individual programs or in-lined shell commands, like ls in your example. A solution is to run the shell and execute ll from within.

The magic Posix shell command to do the expansion:

Screen Shot 2017-02-27 at 11.22.22 PMAn interesting footnote if you've read this far: The Posix shell for the 3000 is one part of the operating system that was not built by HP. The shell was licensed by HP from MKS, and Hewlett-Packard paid royalties to MKS so Posix could work inside of MPE/iX. That was an issue that posed a potential snag for source code licensing from HP. But the outside license issues never ended up blocking emulation or source-license arrangements. Managers have used Posix on the 3000 as a way to get familiar with commands in Unix systems. In the great majority of instances, these commands are the same.

Posted by Ron Seybold at 11:10 PM in Hidden Value, Homesteading | Permalink | Comments (0)

February 03, 2017

Fine-tune Friday: Care and feeding of UDCs

Screen Shot 2017-02-06 at 1.53.00 PMMercury Insurance is a long-time HP 3000 shop still running a server in production. Last week Reggie Monroe reached out for a refresher on administration of HP 3000 User Defined Commands (UDCs). These are the HP3000's equivalent of scripting in Unix environments. UDCs are a better version of Command Files, according to Jon Diercks and his MPE/iX System Administration Handbook. UDCs are catalogued, Diercks says, so they can be loaded for individual user accounts.

UDC definition
Click for details

There's a superior PowerPoint slide deck online at the 3K Associates website that covers how to create and use UDCs. But the Diercks book (no longer in print, but available online) is more concise on the use of UDCs. It's also only available as an $80 book today on the used market; put yours in a safe place. Monroe's question asked about "a command to list all users, and the logon UDC associated with them, if one is set."

The initial answer was the command HELP SHOWCATALOG,ALL. This brings an administrator to

SHOWCATALOG [listfile][;USER=username[.accountname]]

But Alan Yeo pointed out that the MPE/iX command only locates system-level UDCs. 

You don't actually get what you think you asked for, so whilst :showcatalog ;user=@.@ sounds very hopeful, in fact it only shows the system level UDCs not account ones. As far as I'm aware the only place you can find them all is in the BULDJOB2 file in PUB.SYS. You do have a BULDJOB2 file don't you? And it's up to date?

And here's where Vesoft's utility does a job the 3000's OS cannot. VEAUDIT LISTUDC @.@ finds UDCs of all kinds.

We have chronicled much of MPEX during the 21 years of the NewsWire's publication. The utility was even the sole subject of the Inside Vesoft column back in the era when HP was starting to lock down 3000 futures. In 2002 Steve Hammond illustrated the distinction of UDC administration under VEAUDIT. It becomes important because security on a 3000 includes management of the UDC catalogs. And yes, there's a tool for the security, too.

VEsoft’s Vladimir Volokh told me he had been asked to find out if any users on a system had the VEsoft utility GOD in one of their UDCs and if it had the lockword embedded in the UDC. He gave me a series of two commands that did the trick and they had some added value to boot. Once I saw the commands, I was impressed with the simple elegance, but like a good programmer, I had to deconstruct it, break it down and reassemble the whole thing. If you’d like to play along, you need: MPEX, VEAUDIT (both available from, who else, VEsoft) and a healthy programmer’s curiosity (you’re going to have to provide that yourself).

The details of the exercise show "GOD.PUB.VESOFT’ [is found using VEAUDIT] and we have accomplished our mission. But wait. What are those CIERR907 files? Those are files in the list that don’t exist! But they are UDCs that have been set! Looks like you can do some housecleaning and those UDCs can be un-set. How about that — you got some value added, you killed two birds with one stone, (insert your favorite cliche here). Time to play system manager again."

When you add a third party tool to your administrator's box, you can make a purge of such files foolproof. MPE/iX cannot select to show a complete set files by attributes such as program capability. Or for that matter, by last accessed time, or file size, or file security. It's a long list of things that MPE makes an administrator do on their own. Missing something might be the path to looking foolish.

VEAudit and MPEX will root out UDCs and do a foolproof purge, including file names. VEAudit will list all of the UDCs on a server, regardless of user -- not just the ones associated with the user who's logged in and looking for UDCs. The list VEAudit creates can be inverted so the filename is the first item on each line. Then MPEX will go to work to do a PURGE. Not MPE's, but a user-defined purge that looks for attributes, then warns you about which ones you want to delete, or would rather not.

Posted by Ron Seybold at 11:49 PM in Hidden Value, Homesteading | Permalink | Comments (0)

January 27, 2017

Friday Fine-Tune: Memory and disk behavior

By Jeff Kubler
Kubler Consulting

Hard-disk-headAlong with the relationship between your CPU measurements and overall performance, memory and disk make up the other two components of your HP 3000 performance picture. Main memory is the scratch pad for all the work that the CPU performs. Every item of data that the CPU needs to perform calculations on or updating to must be brought into main memory.

The CPU must manage memory. It must cycle through the memory pages, marking some as Overlay Candidates (this means that new data from disk may be placed here), noting that some are in continued use, and swapping others out to virtual or what is called transient storage. Swapping to disk occurs when data is in continued use but a higher priority process needs room for its data.

To accommodate this higher priority process and its need for memory space, the Memory Manager will swap the memory for the lower priority process out to disk. The more activity the Memory Manager performs, the more CPU it takes to do this. Therefore it is the percentage of CPU used to manage memory that we use as a measurement.

Page Faults per Second

A Page Fault occurs each time a memory object is not found in memory. The threshold for the number of Page Faults per second that can be incurred before a memory problem is indicated varies with the size and the power of the CPU. Larger machines can handle more Page Faults per second while a smaller box will encounter problems with far fewer. We have found that the number of Page Faults per second a system can endure without problem rises with the relative performance rating of the machine.

An exceptional number of Page Faults should never be used as the sole indicator of memory problems but when observed should be tested with the memory manager percentage. If both agree, you have a memory shortage. There are some strange things that I have observed with Page Faults, so it does not stand alone as an indicator of memory shortage.

The number of Page Faults per second and the amount of CPU needed to manage Memory are always evaluated in conjunction with each other. That is to say the high Page Fault Rate will not be considered a problem if the Memory Manager Percentage is not above 4 percent.

Disk Environment

The Disk Environment is referred to as Secondary Storage. This is where all the data needed for system use is stored. Since Main Memory is not large enough to store all of the data that will be needed by all the processes, there must be a location for this larger pool of data. Even though the Disk Environment does not have the significance it once had, this area can still be a bottleneck. As the CPU speeds increase, bottlenecks become more significant.

Several different factors can affect the Disk Environment. One of these is data locality. Data locality pertains to two different types. There is data locality within Image datasets and data locality across the disk itself.

Data locality across disk: This refers to the location of separate pieces of files (called extents). When files are placed on the disk, they can be placed in contiguous sectors or sections of files, or they can be placed in non-contiguous locations or even on many different disks. When files are not in contiguous locations they are said to be fragmented. The advantage of contiguous location is that greater efficiencies are allowed in retrieving data. When files need to be read, the head movement of the disk drive is minimal if files are in contiguous locations. The head moves to the location and the retrieval begins.

As the disk fills up the system cannot find one contiguous location to build any new file. Therefore, the system breaks the file up into extents and places the file wherever it can. A system reload will put files back into contiguous location (usually back on the location of the files file label) or products such as Lund Performance Solutions De-Frag/X can be used to put the files back into contiguous location.

Operating systems allocate disk space in chunks as they create and expand files and transient disk space (swap areas, etc.). When files are purged, these chunks are released for reuse. Over time the disc space may end up fragmented into many small pieces, which can slow the performance and the reliability of the system.

To observe and correct MPE fragmentation, you can use the De-Frag/X product from Lund Performance Software or use the Contigvol command of MPE/iX's Volutil program. The latter creates contiguous free disk space on a volume. Contigvol work about as well as VINIT CONDense did -- that is, it's stable and reliable, but requires multiple passes to get the best results.

Data locality within IMAGE datasets is the other area of major concern. There there are two different types of datasets to be concerned with, detail datasets and automatic or master sets.

The Detail Datasets

This type of set holds the day to day data input. Detail sets begin with nothing in them. When records are added 1 is added to something called the high-water-mark, a number that tells how many records have been in the set, and the record is placed in the set.

The problem is that IMAGE automatically reuses space that is given up when a record is deleted. This space is often called the delete chain. New records are placed in the most recent location available on the "delete chain." This means that new records are not in the same physical locality as the rest of the records and may be far removed from the other records.

The ideal state for a detail database is one where the detail entries are sorted by the key field. This allows the data to be retrieved in the smallest amount of IOs making efficient use of the MPE systems pre-fetching of data. When this is not the case we can measure the dataset lack of efficiency with something called the Elongation factor. This is simply a measure of how many more IOs the user must perform to retrieve desired data.

The Master Datasets

These have unique identifiers (field names). There are two types of master sets, a manual master and an automatic master set. Manual masters have user-entered master entries while automatic masters have automatic entries placed in them to accommodate access to detail records. The issue of importance to performance here is something called the hashing algorithm. This is the method used by the database to calculate the location of the next record placed in the database. The intent is to cause the master set to be as equally distributed as possible.

The hashing algorithm uses the size of the set in its calculation. A poor size or a size that is not large enough will result in an unequally distributed database. A poor size is most easily described as one that does not consist of a prime number. This means that when the hashing algorithm calculates a location there is a higher potential that a record will already exist in that location. When this happens a secondary position must be calculated. When secondaries are placed in another block within the database, another IO must occur to retrieve needed data. Since IO to disk is the slowest type of access, we want to avoid this at all costs.

Posted by Ron Seybold at 07:14 PM in Hidden Value, Homesteading | Permalink | Comments (0)

January 06, 2017

Friday Fine-Tune: Logging, IP logins, SNMP

Due to a disk crash, I had to reload my HP 3000 system recently. I’ve just discovered that system logging has been suspended. How do I resume system logging?

Paul Christidis replies:

The reason for the suspension of logging was most likely due to a duplicate log file name. When the SLT was created the then-current log number was recorded, and when you restarted the system from your most recent SLT it tried to open the sequentially next log file. Said file already existed.

  • MOVE the existing log files to a hold area
  • Determine what logfile the system resumed on
  • Perform a series of SWITCHLOG commands until the logfile number advances to one more than the highest number in the hold area
  • Then move the held logfiles back to the pub.sys group — replacing the ones created by the series of ‘switchlog’ commands.

Is there a way to see the IP address associated with a particular login?

Any user with SM can do the following, for example:


The command :listf,8 will list all sessions and will show their associated IP address.

I’ve got an older model HP 3000 and I'd like to start monitoring it with SNMP for things like CPU utilized, jobs running or whatever other cool stat I can SNMP-grab. The problem I have is I can’t find the MIBs for it anywhere.

Andreas Schmidt replies:

First of all, I do not recommend the use of SNMP on the 3000, for performance but also security reasons. SNMP is not the securest protocol, as you know. Nevertheless, here are some hints:

• In the group NET.SYS you will find the SNMPUDC. This should be set in any case for MANAGER.SYS or on system level.
• Having set this, a SNMPCONTROL STATUS will show you the status of the SNMP subsystem.
• SNMPCONTROL START / STOP are self-explaining.
• The MIBs specific for MPE can be found in the document HP SNMP/XL User’s Guide

Posted by Ron Seybold at 06:53 PM in Hidden Value, Homesteading | Permalink | Comments (0)