I need to submit a file to from an HP 3000 to my credit card processor, a file that is an 80-byte file. Before I submit it, I need to zip the file. I’m using the Posix shell and its zip program. I SFTP’d the file, but my vendor is not processing the file because it is supposedly 96 bytes long. If I unzip the file that I zipped, it becomes a bytestream file. I then check — by doing an FCOPY FROM=MYFILE;TO=;HEX;CHAR — and I see that no record exceeds 80 bytes. Why do they think it is an 96-byte file?

Barry Lake of Allegro replies

I would convert it to a bytestream file before zipping it 

:tobyte.hpbin.sys "-at /SG2VER/PUB/LCAUTHOT /SOME/NEW/FILE"

Mark Ranft adds

I would try copying the file to an intermediate server. Zip it. And SFTP it. See if that provides better results.

It only took a matter of weeks to create an unpatched security threat to the world's single-most installed vendor operating system, Windows XP. At about a 30 percent penetration of all PCs, XP is still running on hundreds of millions of systems. A zero-day Internet Explorer bug got patched this month, however, reluctantly by Microsoft. Once it cut its software loose -- just like HP stopped all MPE patches at the end of 2008 -- Microsoft's XP became vulnerable in just 20 days.

MPE, on the other hand, makes a backup file of its account structure that will defy an attempt to steal its critical contents. HP 3000 users can count on the work of an anonymous developer of MPE, even more than five years after patch creation ceased.

The automated protection of MPE's passwords comes through jobstreams from a key backup program. These files, created by using the BULDACCT program, are jobstreams that can only be read by 3000 users with CR (the jobstream's CReator, who might be an operator) or SM (System Manager) privileges, according to Jon Diercks' MPE/iX System Administration Handbook. Diercks advises his readers, "Even if your backup software stores the system directory, you may want to use BULDACCT as an extra precaution, in case any problems interfere with your ability to restore the directory data normally." However, he adds, the BULDJOB files are powerful enough to warrant extra care. After all, they contain "every password for every user, group and account, and lockwords for UDC files where necessary."

Note: the jobstream files you build on your own -- not these BULDJOBs -- can be secured on your own. But you must do that explicitly. These user-created streams' protection is not automatic.

In any case, you should use BULDACCT every day, according to Vesoft's Vladimir Volokh, not just as an optional extra precaution. "Do it before -- well, before it happens," he says. What can happen is a messy manure of a failure of an LDEV, one that scrambles the system directory. 

My system crashed. Now when I bring it back up it starts to behave strangely, indicating several system files cannot be accessed. I can sign on, as MANAGER.SYS, but most of the accounts that used to be on the system cannot be found. When I do a LISTF of PUB.SYS, most of the files have a message associated with them that reads as follows.

I believe the system disk experienced some “difficulties” at some point, and I’m not sure what happened or if it’s repairable. Of course I have a SYSGEN tape. But never having had to use one, I need to know if it contains the SYS account files necessary for me to begin reconstruction and reloading of accounts.

Paul Courry replies:

Bad UFID is a bad Universal File IDentifier. In other words, your file system is corrupted. You can try running FSCHECK.MPEXL.TELESUP (run with extreme care, reading the FSCHECK manual first). But considering the extent of the damage you probably will not be able to recover everything.

John Clogg replies:

Files, groups, and accounts on private volume sets are still there, but you will need to recreate the system directory entries for those accounts and groups. If you have BULDACCT output, that will make the job easier. It’s always a good idea to run BULDACCT periodically and store the result for just this eventuality.

The software vendors most likely to sell products for a flat rate -- with no license upgrade fees -- have been the system utility and administration providers. Products such as VEsoft's MPEX, Robelle's Suprtool, Adager's product of the same name -- came in one, or perhaps two versions, at most. The software was sold as the start of a relationship, and so it focused on the understanding the product provided for people responsible for HP 3000s.

That kind of understanding might reveal a Lewis Carroll Cheshire Cat's smile inside many an HP 3000. The smile is possible if the 3000 uses UDC files, and the manager uses only MPE to do a file PURGE. There is a more complete way to remove things from a 3000's storage devices. And you take care about this because eliminating UDCs with only MPE can leave a user unable to use the server. That grin is the UDC's filename. 

To begin, we assume your users have User Defined Commands. User Defined Commands are a powerful timesaver for 3000 users, but they have administrative overhead that can become foolproof with the right tools. These UDCs need to be maintained, and as users drop off and come on to the 3000, their UDCs come and go. There's even a chance that a UDC file could be deleted, but that file's name could remain in the filesystem's UDC master catalog. When that happens, any other UDCs associated with the user will fail, too. It might include some crucial commands; you can put a wide range of operations into a UDC.

When you add a third party tool to your administrator's box, you can make a purge of such files foolproof. You can erase the Cheshire Cat's grin as well as the cat. It's important because that grin of a filename, noted above, can keep valid users from getting work done on the server with UDCs. This is not the reputation anybody expects from a 3000.

I have someone at a remote site that may need a drive replaced.  How can I tell which drive is a certain LDEV?

Keven Miller, who at 3kRanger.com describes himself as "a software guy with a screwdriver," answers the question -- for those that don't have the benefit of seeing an amber light on a failed drive.

Well, for me, I run SYSINFO.PRVXL.TELESUP first. Then you have a map of LDEV# to SCSI path. Next, you have to follow your SCSI path via SYSINFO.PRVXL.TELESUP.

From the example above, on my 928, 56/52 is the built-in SCSI path. Each disk has a hardware selection via jumpers to set the address of 0 to 6. (7 is the controller). You would have to inspect each drive, which could be one of the two internal ones, or any external ones.

2028 is considered the afterlife for MPE/iX, and MPE in general, based on misunderstanding of the CALENDAR intrinsic. The operating system was created in 1971 and its builders at the time used 16 bits, very state of the art design. Vladimir Volokh of VESOFT called to remind us that the choice of the number of bits for date representation probably seemed more than generous to a '71 programmer.

"What could anyone want with a computer from today, more than 50 years from now?" he imagined the designers saying in a meeting. "Everything will only last five years anyway." The same kind of choices led everybody in the computer industry to represent the year in applications with only two digits. And so the entire industry worked to overcome that limitation before Y2K appeared on calendars.

This is the same kind of thinking that added eight games to the Major League Baseball schedule more than 50 years ago. Now these games can be played on snowy baseball fields, because March 29th weather can be nothing like the weather of, say, April 8 in northern ballparks.

Testing the MPE/iX system (whether on HP's iron, or an emulator like CHARON) will be a quick failure if you simply SETCLOCK to January 1, 2028. MPE replies, "OUT OF RANGE" and won't set your 3000 into that afterlife. However, you can still experience and experiment with the afterlife by coming just to the brink of 2028. Vladimir says you can SETCLOCK to 11:59 PM on December 31, 2027, then just watch the system roll into that afterlife.

It goes on living, and MPE doesn't say that it's out of range, out of dates, or anything else. It rolls itself back to 1900, the base-year those '71 designers chose for the system's calendar. And while 1900 isn't an accurate date to use in 2028, 1900 has something in common with Y2K -- the last year that computers and their users pushed through a date barrier.

Guy Paul (left) and Craig Lalley atop Mt. Adams, with their next peak to ascend (Mt. Hood) on the horizon.

If you consider the last 40 years and counting to be a steady rise in reputation elevation for the HP 3000 and MPE -- what computer's been serving business longer, after all? -- then 2027 might be the 3000's summit. A couple of 3000 experts have climbed a summit together, as the photo of Guy Paul and Craig Lalley above proves. What a 3000 might do up there in 20 years prompted some talk about 2027 and what it means.

The two 3000 veterans were climbing Washington state's second highest mountain, Mt. Adams, whose summit is at 12,280 feet. On their way up, Paul and his 14 year old grandson had just made the summit and ran into Lalley, and his 14 year old son, on their way to the top.  

The trek was announced on the 3000 newsgroup last year. At the time, some of the group's members joked that a 3000 could climb to that elevation if somebody could haul one up there. "Guy is a hiking stud," said his fellow hiker Lalley. "Rumor has it that Guy had a small Series 989 in his back pack. I wasn't impressed until I heard about the UPS."

After some discussion about solar-powered computing, someone else said that if it was started up there on Mt. Adams with solar power, the 3000 would still be running 20 years later.

Then a 3000 veteran asked, "But won't it stop running in 2027?" That's an important year for the MPE/iX operating system, but not really a date of demise. Such a 3000 -- any MPE/iX system -- can be running in 20 years, but it will use the wrong dates. Unless someone rethinks date handling before then.

Jeff Kell, whose HP 3000s stopped running at the University of Tennessee at Chattanooga in December, because of a shutdown post-migration, added some wisdom to this future of date-handling.

"Well, by 2027, we may be used to employing mm/dd/yy with a 27 on the end, and you could always go back to 1927. And the programs that only did "two-digit" years would be all set. Did you convert all of 'em for Y2K? Did you keep the old source?"

On our Series 937 I need a routine that will delete all but the last five files in a group that begins with certain values and have a certain pattern to the file names.

Example: We keep old copies of our PowerHouse dictionaries, but only need the last five. I can not do it by date like other groups of files, since it does not get changed everyday. Sometimes we'll go weeks, even months before we make a change. 

I have a routine for other groups of files (interface files) that get created every day and keep only the last 31 days. This is done very easily with VESOFT’s MPEX by simply checking the create date. I was wondering if anyone has a routine either in JCL or MPEX that will keep the last 5 instances of these files. The two file-naming conventions are PT###### and PL######. The ###### represent MMDDHH (month, day, hour).

A wide range of solutions emerged from HP 3000 experts, veterans and consultants.

Francois Desrochers replies

How about doing a LISTF and use PRINT to select all but the last 5 into another file (PTPURGE):

LISTF PT#####,6;PTFILES
PRINT PTFILES;END=-6;OUT=PTPURGE

You could massage PTPURGE and turn each line into a PURGE. It has been a while since I used MPEX, but maybe it has an indirect file function e.g. %PURGE ^PTPURGE.

Of course MPEX has such a function. Vladimir Volokh of VESOFT supplied an elegant solution involving a circular file, a feature added to MPE/iX more than 15 years back. 

First, build an MPE circular file (to do this, look at HELP BUILD ALL). The nearly 1,000 lines that will follow include an explanation of the CIR parameter. We use logfiles below in our example.

PURGE V
BUILD V; CIR; DISC=5
FILE V, OLD
LISTF LOG####, 6;*V

(MPE's asterisk, by the way, can be used in about 19 different ways, Vladimir adds.)

Your result in V can be your last five names. Now you purge, using MPEX -- because purging something minus something is an MPEX-only function. (Using the caret sign is a way to signal all the files mentioned in the file V.)

%PURGE LOG####-^V

There are other solutions available that don't require a third-party gem like MPEX. 

My HP 3000 system was still on EST, so I wanted to change it during startup. I answered "N" to the date/time setting at end of startup, and it refused my entry of 03/09/14; it returned a question mark. After several quick CR, it set the clock back to 1 Jan 85, which is where it is now waiting.

Gilles Schipper of GSA responds:

While the system is up and running, you could try (while the system is up and running):

:setclock ;date=mm/dd/yyyy;time=hh:mm
:setclock  ;cancel 
:setclock ;timezone=w5:00 (for example)
:setclock ;cancel (again)

Brian Edminster of Applied Technologies notes:

I'd been quite surprised by how many small 'single machine' shops don't properly set the hardware clock to GMT with the software clock offset by 'timezone' Instead, they have their hardware and software clock set to the same time, use the 'setclock correction=' and then give either a +3600 or -3600, for spring or fall time changes. 

Allegro's got a simple command file called FIXCLOCK, on their Free Allegro Software page, that allows fixing the hardware clock AND properly setting the time-offset for the software clock -- all without having to take the system down.

The US rolled its clocks forward by one hour this past weekend. There are usually  questions in this season about keeping 3000 clocks in sync, for anyone who hasn't figured this out over the last several years. US law has altered our clock-changing weekends during that time, but the process to do so is proven.

Donna Hofmeister, whose firm Allegro Consultants hosts the free nettime utility, explains how time checks on a regular basis keep your clocks, well, regular.

This past Sunday, when using SETCLOCK to set the time ahead one hour, should the timezone be advanced one hour as well?

The cure is to run a clock setting job every Sunday and not go running about twice a year. You'll gain the benefit of regular scheduling and a mostly time-sync'd system.

In step a-1 of the job supplied below you'll find the following line:

    !/NTP/CURRENT/bin/ntpdate "-B timesrv.someplace.com"

Clearly, this needs to be changed.

If for some dreadful reason you're not running NTP, you might want to check out 'nettime'. And while you're there, pick up a copy of 'bigdirs' and run it -- please!

I want to upgrade our production 959KS/100 system to a 979KS/200, and I see the Hewlett-Packard HP 3000 Relative Performance chart says we'll go from a 4.6 to 14.6. What does that increase represent? For instance, does each whole number (like 4.0 to 5.0) represent a general percentage increase in performance?

Peter Eggers offered this reply.

Those performance numbers are multiples of a popular system way back when, based on an average application mix as determined by HP after monitoring some systems and probably some system logs of loads on customer systems. No information here as to where you are on the many performance bell curves. The idea is to balance your system resources to match your application load, with enough of a margin to get you through to the next hardware upgrade.

People mention system and application tuning. You have to weigh time spent tuning and expected resource savings against the cost of an upgrade with the system and applications as is.  Sometimes you can gain amazing savings with minor changes and little time spent.  Don't forget to add in time to test, QA, and admin time for change management.

There are a many things to consider: CPU speed and any on chip caching; memory cache(s) size and speed; main memory size and speed; number of I/O channels and bandwidth; online communication topography, bandwidth, and strategy; online vs. batch priorities, and respective time slices; database and file design, access, locking, and cache hit strategies; application efficiency, tightening loops to fit memory caches, and compiler optimizations; and system load leveling.

I am attempting to convert a string into a number for use in timing computations inside an MPEiX job stream. In the Posix shell I can do this:

/SYS/PUB $ echo "21 + 21" | bc
42
/SYS/PUB $

But from the MPE command line this returns blank:

run sh.hpbin.sys;info='-c echo "21 + 21" | bc'

But why? I would like to calculate a formula with containing factors of arbitrary decimal precision and assign the integer result to a variable.  Inside the shell I can do this:

shell/iX> x=$(echo "31.1 * 4.7" | bc)
shell/iX> echo $x
146.1
shell/iX> x=$(echo "31.1 * 4.7 + 2" | bc)
shell/iX> echo $x
148.1
shell/iX> x=$(echo "31.1 * 4.70 + 2" | bc)
shell/iX> echo $x
148.17

What I would like to do is the same thing albeit at the MPE : prompt instead, and assign the result to an MPE variable.

Donna Hofmeister of Allegro replies

CI numeric variables only handle integers (whole numbers).  If your answer needs to be expressed with a decimal value (like 148.17 as shown above) you might be able to do something to express it as a string to the CI (setvar string_x "!x").

This is really sounding like something that's best handled by another solution -- like a compiled program or maybe a perl script.

For what it’s worth, the perl bundle that's available from Allegro has the MPE extensions included.  This means you could do take advantage of perl's 'getoptions' as well as 'hpcicmds' (if you really need to get your result available at the CI level.

If we have a system (volume set) with mostly full disks, and I add a new big empty disk to it, how will MPE/iX do all new allocation on that disk — will it wait until it fills up to the same relative fullness as the existing drives?

See, we have a system with a Nike Model 20 and a bunch of RAID 1 LUNS, and we’ve added five new drives in RAID 5 to the system volume set. But that sounds like we’re on the cusp of a disaster, because while the read performance is measurably better, all the system is going to be doing is writes to this drive for every new extract and scratch file. And as everybody knows, the write performance is like 2.8 times slower to the RAID 5 LUN than the RAID 1 LUN.

[Corrected, to identify the BALANCE command as a part of DeFrag/X.]

Craig Lalley noted, "There is a command you will want to use if you have Defrag/X, [created by Lund, sold by Allegro] The command is BALANCE VS. As an example, 

BALANCE MPEXL_SYSTEM_VOLUME_SET

"There’s online help for this command in Defrag at HELP BALANCE. Without that, I would use system logging to determine the most heavily accessed files and store/restore them to spread the extents."

And there's also help to manage this kind of balancing and defragmentation from VEsoft, as well as that Lund tool.

Way back in the middle 1990s, HP added the Posix shell to the HP 3000, so 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).

It's been said that Posix was a promise only partly fulfilled for the 3000. There was a move to make the system more inclusive, to make it possible to port Unix software onto MPE/iX. Alas, a tech roadblock called the Fork of Death stood in the way of more widespread porting.

Over the years, however, Posix has been a feature to be discovered for most 3000 managers and operators. HP intended it to be essential; the computer's operating system was renamed from MPE/XL to MPE/iX just to call attention to these added Posix, Unix-like capabilities.

MPE failed in the Posix world primarily because of the unix "fork()" concept, so critical to the very nature of all that is Unix. It is a totally alien concept to MPE. MPE was designed to easily add additional new users to an executing process, and maintain the security/integrity of each individual user.  It was not designed to duplicate a current process's environment, including the local data and state, because there was no point.

As one sage developer said of the deathly fork, "Yes, MPE would fork(), but very reluctantly, and very slowly. So nothing that depended on it worked very well."

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.

:LL /BACKUPS/HARTLYNE/S*
ls: File or directory “/BACKUPS/HARTLYNE/S*” 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 while at HP, who's gone on to work in open system and open source development, said this in reply:

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.

Our editor Gilles Schipper posted a fine article on improving CPU performance on 3000s "in a heartbeat." One of our readers asked a question which prompted Gilles to clarify part of the process to speed up a 3000, for free.

Gilles, who offers HP 3000 and HP 9000 support through his firm GSA, Inc., has also replied to a recent question about how to make a DLT backup device return to its speedy performance, after slowing to about a third of its performance.

The Heartbeat article focused on needless CPU overhead that could be caused by a networking heartbeat on 3000s. Gilles points out:

Fortunately, there is a very simple way to recognize whether the problem exists, and also a simple cure. If your DTCs are connected without transceivers, you will not be subject to this problem. Otherwise, to determine if you have the problem, simply type the command

:listf [email protected],2

In the report that is produced, you will notice OPEN files (ones with an associated asterisk ending the file name); these are 1W in size.

There are two such files associated with each configured DTC, file name starting with the letter H, followed by six characters that represent the last six characters of the DTC MAC address, followed by the letter A or B. The EOF for these files should be 0 and 5 for the respective "A" and "B" files.

Otherwise, your CPU is being subjected to high-volume, unnecessary IO, requiring CPU attention. The solution is to simply enable SQL heartbeat for each transceiver attached to each DTC. This is done via a small white jumper switch that you should see at the side of each transceiver. Voila, you've just achieved a significant no-cost CPU upgrade.

Compete details are in Gilles' original article. On speeding up backup time, he pointed out that adding an option to the STORE command will help you track IO retries.

It's always a good thing for the community to read about a tool they need and use, because it usually brings up some notes about allied solutions. When we wrote about replacing code comparison tools for developers who work on the 3000, we got several notes about other solutions. One can't be purchased any longer. Come to think of it, the other one cannot either -- but both of these tools can be obtained and be used in a development environment for HP 3000s.

The first is the much-beloved Whisper Programmer Studio. Bruce Hobbs left us a comment to say that this PC-based dev environment, one built to talk to the HP 3000 and files on the server, "offers a Compare Files item from their Tools menu. It does a fine job in a GUI environment."

Whisper came up in a note that our contributing editor Brian Edminster sent after the story emerged. "I still use it daily at my primary client," Edminster said, while giving us a heads-up he's still looking into how to make Notepad ++ a better player in the MPE development world. 3000 access is a problem to be solved, but Edminster specializes in open source solutions, so we'll stay in touch to see what he discovers.

In the meantime, you can enjoy his rundown on Programmer Studio versus Qedit for Windows.

The other solution for comparing files lies inside MPE/iX itself. That OS is also a product that, like the beloved Whisper, is no longer being sold. (It's being re-sold, however, each time a used 3000 changes hands.) Vesoft's Vladimir Volokh called to remind us of the hidden value inside MPE.

When a 3000 utility goes dark — because its creator has dropped MPE/iX operations, or the trail to the support business for the tool has grown faint — the 3000 community can serve up alternatives quickly. A mature operating system and experienced users offer options that are hard to beat.

One such example was Aldon Computing's SCOMPARE development tool, once a staple for 3000-based developers. It compared source files for more than 15 years in the HP 3000 world. Eventually Aldon left the MPE business. But there are a fistful of alternatives. Allegro Consultants offers a free MPE/iX solution in SCOM, located at

www.allegro.com/software/hp3000/allegro.html

At that Web page, scroll down to SCOM. Other candidates included a compare UDC from Robelle, GNU Diff, diff in the HP 3000's Posix environment, and more. If you're willing to go off the MPE reservation -- and a lot of developers work on PCs by now -- there's even a free plug-in for Notepad++, that freeware source code editor which relaces Notepad in Windows. You can download that plug-in as an open source tool at SourceForge.net

Independent consultant Dan Miller wrote us to hunt down the details on converting between data types on the HP 3000. He's written a utility to integrate VPlus, IMAGE/SQL and Query for updating and modifying records. We'll let Miller explain. He wants to expand his utility that he's written in SPL -- the root language of MPE -- to include packed decimal data.

Can you tell me how to transfer a packed decimal to ASCII for display, then convert ASCII characters to the corresponding packed decimal data item?

I wrote a utility that integrates VPlus, IMAGE/SQL and Query, one that I used in a Federal services contract for data entry and word processing. Basically, VIQ lets me design a VPlus screen with field names the same as IMAGE data items. From the formatted screen a function key drops you into Query. You select the records to be maintained, specify "LP" as output, and execute the "NUMBERS" command (a file equation for QSLIST is necessary before this). From there, you can scroll thru the records, modify any field, and update. I never marketed it commercially, but I have used it at consulting customer sites.

I recently had occasion to use it at a new customer's site and realized that I never programmed it to handle packed decimal format numbers; the customer has a few defined in their database. Typically, database designers use INTEGER or DOUBLE INTEGER formats for numeric data, which occupy even less space -- the goal of using packed decimal) employing ASCII/DASCII, or BINARY/DBINARY intrinsics.

I need to discover the proper intrinsics to transfer the packed decimal numbers to ASCII characters and back. I'm sure there's a way, as QUERY does it. In COBOL, I think the "MOVE" converts it automatically, but my utility is written in SPL.

HP's documentation on data types conversion includes some help on this challenge. But Miller hopes that the readers of the Newswire can offer some other suggestions, too. Email me with your suggestions and we'll share them with the readers.

Mark Ranft, the IT manager who's been stewarding a farm of 3000s at Navitaire/Accenture for many years, recently sent what he calls a geek gift for the holidays. Ranft, who's also done service in the community under his Pro3k service company, offered a restore job for the 3000 console. The job's extra value is preserving error messages.

Here is a HP 3000 geek present for you! I used to do the first system restore interactively on the console, but would occasionally lose some important error messages as they scrolled by and I wasn't able to look back. So I came up with the following expert tip.

By Brian Edminster

Second of two parts

Yesterday I outlined some of the powers of the Posix program pax, as well as tar, to move MPE/iX backup files offsite. Here’s a warning. There are some file types that cannot be backed up by tar/pax while also storing their attributes:  ;CIR (circular) and ;MSG (message) files (and possibly others. I haven’t tested all possible file types yet.  Also, there is an issue with tar that is a fairly well known and has been discussed on the 3000 newsgroup. Occasionally it does not un-tar correctly.  It is unclear if and when this was fixed, but I’d love to hear from anybody that might be in the know, or which specific situations to avoid.

Regardless of these limitations, I’ve found a simple way around this. Use store-to-disk to make your backup, then tar to wrap it, so as to preserve the store-to-disk files’ characteristics, before shipping the files off-system. Later, when you retrieve your tar backups and un-tar them, you’ll get your original store-to-disk files back without having to specify the proper ‘;REC= , CODE= , and DISC=’ options on an FTP ‘GET’. I’ve been doing this for several months now on several systems, and I have not had any failures.

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.

When HP released the A-Class HP 3000 models, the computers represented a new entry point for MPE servers. This lowest-end machine, including an MPE/iX license and the IMAGE/SQL database, sold at retail for $15,900. It ran about 70 percent faster than the 3000's previous low end unit, the Series 918. The customer base was hungry for something this small. HP product manager Dave Snow walked the first one down the aisle at the SIGPROF user meeting.

That was more than 12 years ago. The A-Class was built upon PA-RISC processors, chips that are several generations behind HP's latest Itanium-class CPUs. You might expect that the A-Class boxes could be worth less than one tenth of what they sold for during the year that HP curtailed its 3000 plans.

Cypress Technology has got three of these A-Class servers available via eBay, selling them for $3,400 each. They've been out on the auction website for awhile now -- more than 10 days -- but the Buy It Now price hasn't come down. So far, the sellers are still arranging for a transferrable license for these boxes. That's something that runs up the price of a used 3000. But then, so can the extras.

As the range of expertise on MPE and the 3000 continues to wane, it's fun to revisit a time when knowing commands could make you a leader in a community. The archives of the Newswire run rich into an era before MPE's RISC version, when MPE V was the common coin of data commerce. In those times, regional user group members gathered in person once a year. One such group, the Southern California Regional User Group (SCRUG) mounted a conference so elaborate that it hosted its own Trivial Pursuit version for MPE. Six months before anybody could boot up a PA-RISC 3000, I reported on a showdown between the leading lights in March, 1987 -- a contest moderated by Eugene Volokh in his heartland of SoCal.

PASADENA, Calif. -- It took 10 of the sharpest wits in the HP world to provide it, but entertainment at the SCRUG conference here became a trivial matter for an hour. The prizes were limited to bragging rights, laughter from insiders, and a useless bit of plastic which everybody had and nobody needed.

Vesoft's Eugene Volokh moderated the first all-star HP Trivial Pursuit at the conference, as nine top programmers matched wits with each other and Volokh's list of questions. Correct answers drew a small, round reward: mag tape write rings. "Because," said Volokh, "there is no other use for them."

Competing on four different teams were some of the better-known names from HP's history. Adager's Fred White and Robelle's Bob Green were on hand; local developer Bruce Toback of OPT and Bradmark's David Merit represented the Southern California contingent; Fastran's Nick Demos was on hand from the East Coast, along with Vesoft's Vladimir Volokh adding his Russian wit; and SPLash savants Stan Sieler, Steve Cooper and Jason Goertz made a prominent showing from Allegro and Software Research Northwest.

The questions, like all good trivia, covered HP's most arcane and obscure knowledge of the 3000's OS. Several stumped the teams. For example, "What's the highest alphabetical MPE command, with A as the lowest and Z as the highest?" Green offered VINIT as an answer, but he was told WELCOME was correct.

"No fair," Green said in protest. "They didn't have that one when I started on the 3000."

The classic HP 3000 adventure game Empire has been around since the 1980s. It's now running on a system at Tracy Johnson's datacenter, and he's used the services for the free game to explore network speed on a 3000 -- and how to improve it.

The Empire machine is on an admittedly slow network.  In other words it is on the cheapest Cox business line that was set up for 5Mb upload and 1Mb download. The circuit's real purpose is so visitors in our facility can surf the Internet over wireless without logging into our network.  So the Empire machine was put on it as the default endpoint for connections coming inbound.

My question is, given the outbound speed is only 1Mb, are there any arcane tweaks I could change in NMMGR? Would smaller packet sizes do? Do I really care about checksum?

Jeff Kell replied

Depending on the 3000 model, you're only running at 100Mbps, so there is really no "speed" tweak that is relevant. You want to insure basic connectivity issues. The 3000 isn't that great or reliable at autonegotiation, so you may need to hardcode the 3000 and the switch on the other side to 100Mbps/full duplex.  Nothing sucks worse than autonegotiation failure; a switch will typically "default" to 10/half if autonegotiation fails.

What is the MPE/iX system command to convert a string of digits into an integer value?  I find NUMERIC will tell me if I have a string of digits, and DECIMAL converts a number to a string, but I cannot locate the reciprocal function.

Donna Hofmeister of Allegro responds:

It's actually easier than you think to change a string variable into a numeric one. Here's an example, with some blah-blah-blah to go with it.

: setvar foo "123"    <--- string with all-number content
: echo ![typeof(foo)]   <--- do ': help typeof ' to find out what '2' means
2
: echo ![numeric(foo)]   <--- if you have any doubt about the 'quality' of the content use numeric
TRUE
: setvar foo_n !foo   <--- here's the conversion
: echo ![typeof(foo_n)]   <--- and a test for giggles
1

My HP 3000 system was still on EDT, so I wanted to change it during startup. I answered "N" to the date/time setting at end of startup, and it refused my entry of 11/04/13; it returned a question mark. After several quick CR, it set the clock back to 1 Jan 85, which is where it is now waiting.

Gilles Schipper of GSA responds:

While the system is up and running, you could try (while the system is up and running):

:setclock ;date=mm/dd/yyyy;time=hh:mm
:setclock  ;cancel
:setclock ;timezone=w5:00 (for example)
:setclock ;cancel (again)

More than one kind of jobs question is on the landscape this year.  The most obvious question is how to keep your job as the head coach of a vital 3000 server in your organization. The other question, which has been on the table since 2002, is how to manage jobs on the server where your applications will run, after your organization makes its transition.

There are too many answers to the first question to list them all here. I invite you to send us helpful answers. Based on your responses, we can pay them forward. On Friday Oct. 25, I wrote about one answer: Be an entrepreneur for the first time in your life, even while you're older than 55. It's the biggest age group of entrepreneurs. Another answer might be to master a more nouveau environment for apps. Your value on MPE/iX is kept vital, but mostly because you've acquired new skills for an environment that runs alongside MPE/iX. Be ready, in that case, to embrace more change, plus adopt respect for much younger colleagues.

The second jobs question has not had good answers for Windows -- the migrator's favorite platform -- until 2011. Then MB Foster released a scheduler that replicates the power of MPE/iX scheduling and jobstream management. MBF-Scheduler was built by developers who were masters of MPE/iX jobs.

But the third aspect of a jobs question emerged in the past week from a longtime, advanced MPE manager, Tracy Johnson. Working at Measurement Specialties -- one of the strongest and most devoted users of MPE/iX servers, running 10 factories around the world -- Johnson posed a question about job numbers.

'What's the highest job number allowed before it rolls back to #J1?"

VEsoft's founder Vladmir Volokh gave Johnson an answer, according to the manager. It resolves an everyday need, even though other answers came from experts with decades of MPE/iX experience. Vladimir's name isn't invoked a lot on the 3000 newsgroup where the question emerged. Johnson tagged the answer as one of the best. But that's because he talked with the creator of MPEX.

I'm looking at how to save as much time as possible in rebuilding an HP 3000's software and directories. My options seem to be using STORE, versus the sysgen tape command "tape store=@.@.@". What's the best way to go here?

Donna Hofmeister of Allegro replies

Unless your system is small (like a 918 with 8-12GB of disc), you don't want to try to do a full backup via sysgen. If you really do a full backup then I prefer this syntax “store /;...” as it is self-documenting and you know that the Posix files will be backed up as well. (On older releases of MPE, @.@.@ did not back up Posix files <eek>)

You want to make sure that you run 'buldacct' periodically (and routinely). You also want to make sure that you are somehow backing up your directory (store /;*t;directory, for example). Between the two, you have belts and suspenders (for recovering your accounting structure).

On older releases of MPE, you want to make sure that the network is shut down prior to making your SLT tape. And it's still a good idea to have the system quiesced when making an SLT, since everything in the sys account (and .pub.sys in particular) will be locked while the tape is being made. Nothing quite like grumpy users to make your day...

The arrival of the POSIX.1 software standards in MPE was a compatibility milestone. I remember the call I got from HP's Glenn Osaka, then a product manager at the 3000 division, asking what I'd think about a renaming of MPE. In the fall of 1991 the 3000's OS was called MPE/XL. In just a few weeks, HP wanted to start calling it MPE/iX. Those last two letters were the same as Unix, but the OS didn't ever produce commercial apps from that OS. HP was hawking its Unix hard by that time. Starting in 1992, the 3000 was being portrayed as open.

But a decade of HP effort to win applications from the Unix environment came to an end in the fall of 2001. What was left over from the grafting of POSIX onto the 3000's OS? To this very day, you can use open source software that's been ported to MPE. Or port some yourself, if this will solve a compatibility problem.

HP wasn't shy about telling 1991's customers how much difference that iX was going to make. Unix benefits that the 3000 were supposed to gain included app portability, a Unix development environment, and multivendor connectivity. HP called it the Open 3000.

"Customers now have access to a wide breadth of industry-leading applications," said 3000 GM Rich Sevcik. "It should be viewed as a very exciting incremental set of functionality for the MPE owner, and it's just another example of the smooth evolution of the HP 3000."

While the arrival of Micro Focus, Oracle's apps, Lawson Software ERP or SAP never materialized, some key non-commercial software made its way to the 3000. Lots of it has become essential at connecting the servers to non-3000s, especially through networking. One of the first and most prominent results of Posix was the file-sharing tool Samba.

I've had many A-Class and N-Class systems. I've always used them with fiber-attached disk.  I am wondering about the internal disk drives. Are they hot-pluggable? 

My objective here is to find a better alternative to DLT and DDS tapes for offsite storage. I've had suggestions of DS2100 and Jamaica drives.  But a few 300GB Ultra SCSI drives would hold a lot more data with less points of failure. I intend to set up a BACKUP_VOLUME_SET and use the internal disks to do store-to-disk backups of the system. 

Jim Hawkins, formerly the IO maven for HP 3000 systems at HP, replied with details.

There are multiple layers of changes for actual hot plugs or swaps to work.  

• You need the disk HDD to handle this electrically.
• You need HDD physical carrier and physical interface to comply.
• You need the system physical interface and receptacle to comply. 
• You need your Host System Bus Adapter (HBA) to electrically support this.
• You need the OS to be aware enough of the HBA to not get flustered by absence of the device and deal with any notifications from the HBA of the activity.   

Given that the N-Class disk cage has a screw-based cover and the HDD carriers have no quick release levers (as compared with HASS/Jamaica or VA7400) I would state definitively that there is no hot-plug intention.  At the same time, the SCSI bus is pretty low power and low voltage, so it would be generally not too unsafe to experiment. But you're also close to AC inputs and they are not low power.

Everything is peachy after my new install of MPE/iX (6.0; yes, I know it's very old) on my Series 918 -- except I haven't been able to get Telnet working. It errors every time when I put in the INETDCNF.NET file. In my attempts, it appears that I have missing links to the Posix shell. When I execute SH.HPBIN.SYS -L, I get a $ prompt which suggests that my /etc/profile isn't being executed. How can I fix this to get things working?

Donna Hofmeister replies

You're probably missing all/most of your Posix stuff. You can easily check by doing ":listfile /etc/,2" (you have to use listfile for this). If you see nothing...yeah, well... A quick repair for jinetd would be to do the following:

NEWLINK /etc/services, SERVICES.NET.SYS
NEWLINK /etc/protocols, PROTOCOL.NET.SYS
NEWLINK /etc/inetd.conf, INETDCNF.NET.SYS

On my system, I see the following files with links back to .net.sys:

You might want to go ahead and make those as well....

For restoring your missing files... you're on a bit of a quest.

Our bulletproof Series 918 has finally crashed. It's been a great, solid, stable runner for years. However, I desperately need to find a new, used or refurbished drive to replace its system disk, preferably here in the UK. I assume it was LDEV 1, as it couldn't boot. However, I have two drives in the system drive enclosure, and am not sure how to tell which was designated as LDEV 1.

I figure a like-for-like replacement would be less hassle if I can find one. What I need is a C2490-69365 drive with a massive 2GB of storage, one that has a 50 pin connector.

Craig Lalley answered, with a short method on how to discover which drive is designated as LDEV 1.

Look at the primary boot path.  Then find the SCSI drive with that ID. Disconnect the drive and see if the boot behavior changes.

Keven Miller also replied, with advice about finding drives seemingly everywhere -- and another method to figure which drive is LDEV 1 in a 3000.

I'd prefer to replace that 2GB with a larger one. A 4GB, if you’re running MPE 5.0 through MPE 7.0, and something larger if running MPE 7.5, where you can access beyond the 4GB limit.  I have a 4GB LDEV 1 that houses MPE 6.0, and an 18GB LDEV 2 that’s a user volume for other data. For compatible disks, I have many of have these lying around. I could supply any of the following on my list below, for the cost of shipping only.

I'm importing a Comma Separating Value (CSV) text file into a COBOL II program. I want to compare a numeric field from the file to a number in my COBOL program. In that program, the number is defined as S9(8)V99. The CSV file’s numeric field can vary in length, such as "-1,234.99" or "-123,456.99". If the CSV text file field is always the same length, I know I can move the text field to a COBOL numeric field that is redefined as alpha-numeric. My problem is that 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?

Several HP 3000 programmers and developers recommended Suprtool from Robelle to accomplish this kind of import. Robelle's own Neil Armstrong has offered this advice.

One of the goals I had for Suprtool was what I called "close the loop." What the goal of the project was to essentially provide functions and other enhancements within Suprtool to aid in the import of data into self-describing files, FROM the CSV type files that the Suprtool suite of tools have been able to generate for years.

I added some new functionality such as $split, $number and $clean amongst others to facilitate the importing of data from really any source. I wrote an article about it on our website. The article essentially shows some the steps in Suprtool that you can use to import CSV data into a self-describing file -- or really any data target.

August used to be a month for HP 3000 gatherings. The majority of the community's Interex conferences convened in this month, including one in San Francisco 20 years ago. In 1993, Hewlett-Packard was making a gamble on the future of the database that had already led the 3000 to 70 percent sales growth.

When the year opened, HP was telling customers that unit sales had led the computer out of the wilderness. "It's not a backwater," said HP's UK Managing Director John Golding. "It's an important order and profit generator." But the open aspect of the 3000 was dragging focus away from the server -- HP's own focus. Changes from inside HP's IMAGE labs were going to refocus attention on the heartbeat of the MPE/iX experience.

HP said "it believes it is the first vendor to develop an SQL-based interface that read and write information stored in a previously non-relational database." The new HP IMAGE/SQL, replacing TurboIMAGE, was supposed to bring the 3000 customer a wider array of reporting tools. Maybe even more importantly, IMAGE/SQL would connect the 3000 with other systems' data. The media and analysts were calling those other systems Open. 3000 users needed that word applied to their computer to regain HP's interest.

The ardent fans of IMAGE could see the possibilities of a SQL interface. But HP had made tens of thousands of customers out of companies that found the networked TurboIMAGE worked just fine. The technical trick was to put an interface onto a successful database that wouldn't demand a migration.

Earlier this week we looked at the prospects for creating an OpenSSH server component for HP 3000s. Some veteran developers have spent a bit of time on the engineering and learning the undocumented behavior of parts of MPE/iX. As such, this is work that could benefit from the knowledge in source code. Source was licensed to seven companies by HP.

We also wondered if enabling the server aspect of OpenSSH would be considered an MPE/iX enhancement by Hewlett-Packard -- or just a repair of a bug report. That would mean it was a workaround for anybody who'd like the complete OpenSSH on their MPE system.

The source code was provided to help repair problems and perform workarounds for homesteading HP 3000 customers. HP didn't want anybody creating new features for MPE/iX. But enabling the full range of SSH services doesn't constitute a new feature -- at least not from Brian Edminster's viewpoint. He runs a repository of open source software for HP 3000 users. 

If OpenSSH gets better on MPE/iX, Edminster suggests it won't improve simply by way of MPE internals information.

I'd argue that because OpenSSH is not an HP product -- and if making modifications to allow it to use existing features (even undocumented ones) within MPE/iX can allow it to work -- HP would not have grounds to complain. MPE/iX would not be modified in the process. They may not be happy about it, if such a modification extends the useful life of the remaining systems. But I don't believe they'd have legal standing to object. 

I'm not a lawyer, and I don't play one on TV, the 3000 NewsWire, or the 3000-L. What I'm saying is not legal advice, just my own opinion of the situation. If someone is potentially at risk from HP by acting on the above advice, they should first get advice from competent contract and intellectual property counsel.

However, I'd go so far as to suggest that even if enabling OpenSSH required a binary patch to an existing MPE/iX routine which might not be behaving properly, HP still wouldn't be able to complain.

A little way back in July, we reported that the OpenSSH software on the HP 3000 was still somewhat short of full open source functionality. It could be completed, with some extra help from community experts and some testing. Brian Edminster of Applied Technologies looked into what was needed to create a OpenSSH interactive client that would run under MPE/iX.

For anybody new to OpenSSH, it supplies services for encrypted communication sessions. Secure file transfers are the prize here. This would be one way to use the 3000 as an SFTP server, not just a client.

Edminster said, "The fact remains that 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."

Hirsch had asked years ago "if anybody knows a way to actually write to a terminal while there is a read pending, then I could use OpenSSH as a server on the HP 3000. Apparently there are undocumented MPE/iX sendio() and rendezvousio() calls. There are also tread()/twrite() routines in libbsd.a that I think are intended for this, but there's no documentation for these, either." 

As of this week, the community is looking into connecting these dots and producing documentation.

As HP 3000s continue to age their disks go bad. Disk failure is the top cause of HP 3000 downtime by now, here in the fourth decade of the server's era. While no 3000 internal disks go back that far, it's not tough to find a drive that first went online during the previous century.

It's the fate of any component with moving parts. There's a long-term way around these kinds of failures of legacy drives. MPE/iX apps will run on a virtualized 3000 server, so new and whizzy disks like the world’s fastest hard drive— the Seagate Enterprise Turbo solid state hybrid drive (SSHD) -- can become the harbor for MPE LDEVs. Seagate is touting its device as "The industry’s first enterprise SSHD that combines the capacity of a hard drive with solid-state flash enabling high-speed performance for mission critical data."

Seagate notes that their Enterprise Turbo is part of IBM's System x (Linux) server options, and it performs three times faster than a 15K RPM drive. To be fair, Seagate's new drive only has a five-year warranty. The original HP disk hardware obviously had a lifespan of twice that, as a MTBF.

Even after replacing a faulty HP-grade drive in the original Hewlett-Packard iron — certainly not expensive at today's prices, when you can find one — there are a few software steps to watch. For example, one failed system disk was a member in MPEXL_SYSTEM_VOLUME_SET. When the 3000 was restarted after replacement it reported that this LDEV 4 -- a new drive -- was not available. Even a trip into SYSGEN would give a warning that the LDEV "was is part of the system volume set and cannot be deleted." There was an INSTALL from tape because some of the system files were on that device, which worked successfully. But how to get rid of this disk?

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

Sounds like the 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:

SYSGEN
IO
LVOL

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

Schipper offers a repair solution as well.

These fundamental files are a lot like those used in Windows and Linux and Unix, Fairchild explained. HP engineered "emulation type managers" into MPE/iX, an addition that became important once the 3000 gained an understanding of Posix. In 1994, MPE XL became MPE/iX when HP added this Unix-like namespace.

It's a rare gift to see a primer on 3000 file types emerge from HP. Understanding the 3000 at this level is important to the customer who wants 3000 third party companies to take on the tasks HP has dropped. Although migration advocates point out that HP support is long gone for MPE, the knowledge remains intact among independent providers. Fairchild explained the basics of this basic file type.

Savvy HP 3000 managers who need to move files securely are finding that SFTP works under MPE/iX. But OpenSSH, the root of the open source service for encrypted communication sessions over a computer network, is still short of being fully operational for the HP 3000's environment.

Brian Edminster, the senior consultant at Applied Technologies, explains that "with a bit of work, you could get OpenSSH v 3.7.1p2 working. If I recall correctly, 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, 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."

There is another way to let SSH speak up on MPE, however.

Editor’s note: Previously, when a pair of HP 3000s were felled in the aftermath of a windstorm that clipped out the power, a sound strategy of using an Uninterrupted Power Supply in the IT mix failed, too. After a couple of glasses of merlot, our intrepid IT manager Alan Yeo at ScreenJet continues to reach out for answers to his HP 3000 datacenter dilemma — why that UPS that was supposed to be protecting his 3000s and Windows servers went down with the winds' shift. 

By Alan Yeo
Second in a series

Feeling mellower, with nothing I really want to watch on the TV, I decide to take a prod at the servers and see what the problems are. 

Decide that I'll need input to diagnose the Windows problem, so that can wait until the morning. Power-cycle the 917 to watch the self-test cycle and get the error, do it again. (Well sometimes these things fix themselves, don't they?) Nope, it’s dead! 

“Take out my long spoon and sup with the devil,” as they say, with a Web search. Nope, Google turns up nothing on the error, apart from a couple of old HP-UX workstation threads, where the advice seems to be “time to call your HP support engineer.”  Nothing on the 3000-L newsgroup archives, either. (I'd tell you the 3000 error code, but I've thrown away the piece of paper I had with all the scribbles from that weekend).

Where's a guru
when you want one?

I really wanted to get the 917 back up and running over the weekend, as it had all our Transact test software on it. Dave Dummer (the original author of Transact) was doing some enhancements to TransAction (our any-platform replacement for Transact) and we had planned to get some testing done for early the following week, to help a major customer.  

So it's 11:30 PM UK time, but it's only 3:30 PM PDT! I wonder who's around at Allegro? A quick Skype gets hold of Steve Cooper, who with the other Allegroids (interesting, my spell checker thinks Allegroid is a valid word) diagnose within five minutes that the 3000 has got a memory error. The last digit of the error indicates which memory bank slot has the problem.

We've covered this topic about a year ago on our blog, complete with a thorough examination from VEsoft's Vladimir Volokh. But a couple of recent reports about the future of MPE deserve some air time. The premise has always been that the calendar handling of the 3000's OS will be kaput in about 14 years' time, owing to some 20th Century-style thinking about the CALENDAR intrinsic.

But CALENDAR won't make a 3000 stop working. Jeff Kell, the networking wizard whose employer the University of Tennessee at Chattanooga still has 3000s on the premises, offered this opinion.

Well, by 2027, we may be used to mm/dd/yy with a 27 on the end, and you could always go back to 1927 :)

And the programs that only did "two digit" years would be all set (did you convert all of 'em for Y2K?  Did you keep the old source?)

Our major Y2K-issue was dealing with a "semester" which was YY01 for fall, yy02 for spring, etc.  We converted that over to go from 9901 (Fall 1999) to A001 (Fall 2000) so we're good for another 259 years on that part :)  Real calendar dates used 4-digit years (32-bit integers yyyymmdd).

There might be another HP 3000 in your company's future, but at some point every system, homesteaded or migrated, will have to be shut down. Here's the steps to do the job professionally. 

A customer asked how to turn off an HP 3000 once and for all. While this is a sad time for the IT expert who's built a career on MPE knowledge, 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, who stocks a Technical Wikipedia (TWiki) for the 3000, offered 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."

His steps did not include SOX requirements, but "that might be useful," he said in his usual modest introduction. There are 10 steps Bartram details before switching off the 3000's power button.

Even though FTP won't help much in transferring databases on an HP 3000, a lot of other data can be moved using File Transfer Protocol. The question of how to do this securely using SFTP just came up last week. We've covered the topic before, but a new contributor, Brian Edminster of Applied Technologies, chipped in with some advice and a new resource, built from open source.

The initial question:

I'm trying to use ftp.arpa.sys to FTP a file to a SFTP server and it just hangs. Is there a way to do a secure FTP from the HP 3000?

Brian Edminster replies:

The reason that using MPE's FTP client (ftp.arpa.sys) fails is because as similar as they sound, FTP and SFTP are VERY different animals. Fortunately, there is a SFTP client available for the 3000 -- the byproduct of work by Ken Hirsh and others.

It used to be hosted on Ken's account on Invent3K, but when that server was taken out of service, so was Ken's account. As you've no doubt already noticed, it's available from a number of sources (such as Allegro). I'd like to highlight another source: www.MPE-OpenSource.org

It's a Friday and perhaps time to do some deeper maintenance of your HP 3000. A weekend offers an opportunity to move data from an older system to a newer replacement for homesteaders. Here's some advice on using FTP to make a data migration.

You can use FTP to ensure a safe backup of 3000 data. In one case a manager said he needed to backup KSAM XL files, but the manager didn't know that his FAK files were HP's special Keyed Sequential Access Method database files. "What appears to be program files are moved over," he said, "but database files get left behind. How do I get these files over to our Windows server?"

Please note, IMAGE has priviledge protections which don't exist for KSAM. Purging is controlled, for example. KSAM XL files are really just files combining indexes and data, and can be purged without regard to priviledges. Nonetheless, this 3000 uses KSAM XL is running MPE/iX 6.0 -- so there's more than just some management experience missing from this server. 6.0 is more than 13 years old.

MPEX, Vladimir Volokh reminded us, performs more powerful operations to go beyond HP's security. For example, an SM user can do a COPY @.DATA.PROD, @.DATA.BACKUP. Copying only KSAM files: COPY @.DATA.PROD (CODE=""KSAM""). MPE cannot give you such ability to copy only KSAM files.

One rule of 3000 operations is that these data-containing files act differently than all others while being transfered. So FTPing them to a Windows 2003 server won't be a successful way to ensure a safe data recovery. (There are third-party tools to do this, updated and supported in a way that STORE or HP's TurboStore subsystems will never be supported again.) But if a 3000 is stuck on 6.0, it's probably going to have only enough budget to tap included HP software for file backups and transfers.

Donna Hofmeister, whose resume helping 3000 users occupies a vast chunk of the 3000 newsgroup archives, suggests starting with mystd to store the files to disk -- then transfer the STD file.

Stromasys product manager Paul Taffel is reading our reports closely (always a good idea, to keep up with the latest in your community.) Upon reviewing yesterday's story -- which included an account of the operations a prospective user said he still needs to investigate -- Taffel quickly offered answers to a key question about backups using the CHARON HPA/3000 product.

The 3000 manager, who's investigating emulation en route to a migration, asked

How do we do backups and restores with the emulator? Its architecture is that each HP 3000 LDEV is a separate Linux file, so identifying where MPE files are for backup and restore looks more difficult. If I need to restore a file to one of our production accounts, how do I identify which Linux backup it is on, and how do I then mount that virtual disk to do an MPE restore?

Taffel replies

Copying entire CHARON disk image files is only useful as a way to back up an entire disk (or collection of disks) for Disaster Recovery purposes. To create a backup that is useful for restoring individual files, use the MPE STORE command (or a third-party tool) to write the backup, either to a physical tape (internal SCSI, or external USB drive), or to a virtual tape image. Virtual tape images are stored as files on the Linux server; they can hold the contents of any Store (or SLT) tape, but take far less time to write.

There's been plenty of change in the 3000 manager's life over the last 10 years. Some of it might involve changing the location of HP 3000s from one part of the IT shop to another. Users and support experts have discussed the many ways to adjust a 3000 console's location. The method you choose depends on budget, experience and technical skills depth.

Kent Wallace, a 3000 manager for Idaho-Oregon healthcare delivery system Primary Health, needed to move his 3000 console:

I was asked to move the console another 10 feet (more) from the rack (it's an N-Class HP 3000/N4000-100-22). What are the 3 pin positions on the wire that I need to extend this RS-232 cable?

Reid Baxter of JP Chase offered the most direct answer, for those willing to modify cables. "Pins 2, 3 and 7."

Tracy Johnson of Measurement Specialties added:

In addition to what Reid said, you can also get a 3-pin mini-din extension cord and extend the other end.

Our blog contributing editor Gilles Schipper chipped in with a solution offering even farther movement:

If you want to extend the range of the console to anywhere on the planet (at least where there’s Internet access) you could consider the HP Secure Web Console to replace the physical console.

Depending upon the condition of your physical console, this solution may also save a bit of wear and tear on your eyeballs.

(Schipper wrote us a great article on setting up such a web console.)

This morning I came in to find our backup job stalled. Abortjob was ineffective, as was abortio. I ended up rebooting the system. While coming up, I got the “defective sector” message with “FILE.GROUP.ACCOUNT has an extent with unreadable data.” The file is now locked and I need to use FSCHECK to unlock it. How can I determine which drive this extent is on? I have a good idea which one it is, but I’d like to be 100 percent sure before I replace and reload.

Stan Sieler replies:

FSCHECK’s DISPLAYEXTENTS command may help. Note that, if I recall correctly, it displays logical unit numbers, not exactly LDEVs.

I ran checkslt on the MPE/iX 7.5 SLT and it failed. It failed on a DDS-2 drive on two different systems but passed when a DDS-3 drive was used. The MPE/iX 7.5 SLT is on a 120-meter DDS-2 tape. Is this usual?

Michael Berkowitz replies:

What makes you think you don’t have two bad DDS-2 drives? When we had them, we went through them like water, replacing them every couple of months. They are bad news from the word go.

I have a script that uses FTP to send files to a site which we open by IP address. We've been asked to change to SFTP (port 22) and use the DNS name instead of an IP address, and I don't believe the 3000 supports that. Does it? If so, how?

Allego's Donna Hofmeister replies:

I'm not sure you want to do SFTP on port 22.  That's the SSH port. SFTP is meant to use port 115. Have a look at one of Allegro's white papers on how to do SFTP on MPE

If you are going to use DNS, you must have your 3000 configured for that.  It's easily done. 

By Bob Green

Vladimir Volokh of VEsoft fame called us to pass on an interesting story.

He was doing MPE system and security consulting at a site. One of his regular steps is to run VESOFT’s Veaudit tool on the system. From this he learned that every user in the production account had System Manager (SM) capability!

Giving a regular user SM capability is a really bad thing. It means that the users can purge the entire system, look at any data on the system, insert nasty code into the system, etc. And this site had just passed their Sarbanes-Oxley audit.

Vladimir removed SM capability from the users and sat back to see what would happen. The first problem to occur was a job stream failure. The reason it failed was because the user did not have Read access to the STUSE group, which contained the Suprtool "Use" scripts. So, Suprtool aborted. 

“Background Info Break”

For those whose MPE security knowledge is a little rusty, or non-existent, we offer a a helpful excerpt from Vladimir’s son Eugene, from his article Burn Before Reading - HP3000 Security And You – available at www.adager.com/VeSoft/SecurityAndYou.html

By Brian Edminster
Applied Technologies

I was always jealous of shops that could afford good tools.

Let me explain. Awhile back, I read about HP's history of trying to launch a successor to IMAGE. It was supposed to be called HPIMAGE.  It was supposed to be slicker than... well, it was supposed to have all the ability to dynamically index and/or restructure your data that a modern SQL relational database managment system allows, without losing the speed and robustness that makes TurboIMAGE famous. I can recall a few times that having the ability to dynamically restructure a database (while it's in production!) would have been handy. (See: zero downtime) 

Then again, a well designed database in a stable application normally shouldn't need that sort of thing with any sort of regularity. Lately, I'm seeing the need to re-structure/alter indexing as a symptom of not knowing your data's demographics and/or designed usage patterns -- especially as the application's data volumes grow.  

This need to restructure is also a side-effect of trying to use a single database both as an operational data store (current data only, for day to day production), as well as for research/reporting data warehousing -- where the data is relatively static, but may go back years. Again, that's lazy design. Don't try to make a sports car have the hauling capacity of a truck. You'll end up with neither.

What changes we did need to make, were done with:

1) DBUNLOAD/DBUTIL, PURGE/DBSCHEMA/DBUTIL, CREATE/DBLOAD -- if we were poor (and couldn't afford Adager or other similar tools), or

2) DICTDBU/DBUTIL, PURGE/DBSCHEMA/DBUTIL, CREATE/DICTDBL. This allowed unloading to a tape or disk file -- so if we had enough free space, we could skip using tape, and it was much faster!  Also allowed simple re-structuring of the database.

We could do the adding, moving, deleting, and changing the type of datasets; and adding/removing paths, and/or re-arranging order of items in a set. Unfortunately, this was only present if we were lucky enough to be users of Dictionary/3000, or the HP Customizer technology products like MM or HP's Financial software.

3) Best and fastest of all, Model 2 Adager. This even allows transforming the data types, in addition to adding new elements or sets.

But there are still very useful tools that remain on any HP 3000 which still has Predictive Support. Tools you might not know you’ve got.

By Brian Edminster

After reading the article on the safe and prudent use of privileges from yesterday, the subject touched a nerve with me. I've seen too many HP 3000 sites which have SM (or PM) capabilities assigned to production account users. They don't need it, and it adds risk and insecurity to a 3000. Along the same lines of error, PM is granted on insufficiently secured groups where production programs reside.

That first mistake is usually an instance of using a sledgehammer to kill a fly, usually due to laziness or ignorance. But the latter is a sign of careless security, or ignorance. The misuse of MPE/iX privileges is often triggered because application programmers are too lazy (or ignorant) of ways to properly design their applications. They could use the incredibly powerful and finely granular security provisions that MPE/iX allows to avoid this.  

At the least, they could instead have used a lockworded copy of what is commonly known in the 3000 community as the 'GOD' program. This lets the manager who invokes it temporarily gain 'SM' -- much like the 'su' (superuser) command in your favorite flavor of Unix does.  If something with finer granularity is needed, perhaps this is an opportunity for someone to port at least the concept of 'sudo' to MPE/iX.