July 24, 2013

Delete disks completely after replacement

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.

Turbo SSHDIt'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.

The solution would be as follows:

1. Reboot with:

START NORECOVERY SINGLE-DISC SINGLE-USER

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

3. HOLD, then KEEP CONFIG.SYS

4. Create a 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, then VOLUTIL was used to add LDEV4 to the MPEXL_SYSTEM_VOLUME_SET after the install.

Posted by Ron Seybold at 08: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 editor@3000newswire.com.

July 17, 2013

An MPE Power Tool: Byte Stream Files

Although he left HP's MPE labs long ago, system architect Craig Fairchild still subscribes to the Newswire to keep an eye on with 3000 matters. Four years ago, after he'd ended his official 3000 work, he educated the community on the use of byte stream files in the OS. The knowledge is still useful for any homesteader today.

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

Byte stream files are the most basic of all file types. They are simply a collection of bytes of data without any structure placed on them by the file system. This is the standard file model that is used in every Unix, Linux and even Windows systems. MPE's file system has always been a structured file system, which means that the file system maintains a certain organization to the data stored in a file. The MPE file system understands things like logical records, and depending on the file type, performs interesting actions on the data (for example, circular files, message files, KSAM files and so on).

Fairchild detailed how HP gave MPE's byte stream files the knowledge of "organization of data" for applications.

To bridge the gap between standard byte stream file behavior (only the application knows the organization of data) and traditional MPE file type behavior (the file system knows what data belongs to what records), emulation type managers were created. To an MPE application, a byte stream file looks and behaves like a variable record file, even though the data is stored in a way that would allow any Posix application to also read the same data. (Posix applications also have emulator type managers that allow them to read fixed, variable and spool files in addition to plain byte stream files.) The way that the byte stream emulator detects record boundaries is through the use of the newline (\n) character, which is used, by convention, to separate data in ASCII text files on Unix-based systems.

The underlying properties of a byte stream file is that each byte is considered its own record. In MPE file system terms, a record is the smallest unit of IO that can be performed on a file. (You can write a partial record fixed length record, but the file system will pad it to a full record.) Since the smallest unit of IO that can be performed on a byte stream file is a single byte, that becomes its MPE record size. In the MPE file system, the EOF tracks the number of records that are in a file. Since the record size of a byte stream file is one byte, the EOF of a byte stream file is also equal to the number of bytes in the file. This is why one 4-byte variable sized record is equal to 5 byte stream records (4 bytes of data + 1 \n character).

It's also worth noting that any file can be in any directory location and will behave the same way. (Well, almost. CM KSAM files are restricted to the MPE namespace. And of course the special files (that you don't normally see) that make up the file system root, accounts and groups are also restricted... one root, accounts as children of the root, groups as children of accounts. And lockwords aren't allowed outside the MPE namespace. But other than that the first sentence is true.)

The general model that we had in architecting the whole Posix addition was that behavior of a file does not change regardless of where it is located. This was summed up in the saying, "A file is a file." So there are no such things as "MPE files" and "Posix files." There's just files.

What does change is the way you name that file. Files in the MPE namespace can be named either through the MPE syntax (FILE.GROUP.ACCOUNT), or through the HFS syntax (/ACCOUNT/GROUP/FILE). You can also use symbolic links to create alternate names to the same file. This was summed up as a corrallary to the first saying, "But a name is not a name."

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

July 15, 2013

OpenSSH may get unquiet for 3000's users

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

Edminster, who keeps a repository of open source tools available for the community at his MPE-OpenSource website, said "OpenSSH isn't the only implementation of the ssh/sftp/scp protocol, although it is arguably the definitive open source one." He said he's looking for a client or two to help underwrite his R&D to port across this key encryption utility.

That said, in my 'copious' spare time, I'm working on porting the 'dropbear' ssh application.  It's much simpler, and much more restrictive -- but it appears to have a much greater chance of success than having to significantly rework OpenSSH to make it work under MPE/iX.  

Unfortunately, the current OpenSSH v 3.7.1p2 port meets my client's needs -- so if I want to spend any significant time on the dropbear (or other) ssh packages, I'll need a benefactor or two.

As always, if you have questions, don't be afraid to ask. If you have some spare time, try putting up SFTP (from Allegro or MPE-OpenSource) on your HP 3000. You'll find it suprisingly easy.

Hirsch said that with an interactive SSH client, an enterprising IT manager could tunnel a telnet connection over the SSH connection.

So on your PC, you would run:

ssh -L 9999:hp3k.yourcorp.com:23 justforwarding@hp3k.yourcorp.com

Then connect Reflection (or other terminal emulator) to localhost::9999

You can do this with an ssh server running on some computer other than the HP 3000, of course. Just set up a PC or Linux system as an ssh host. There would be a secure connection between the PC and sshhost.yourcorp.com and an unencrypted connection between sshhost and the HP 3000 (presumably both behind the same firewall).

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

July 08, 2013

UPS Redux: Finding Gurus and a False Dawn

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.

Okay, I'm not going to start climbing around the back of the rack at this time of night. I leave it until the morning, but at least I know what the problem is.

False Dawn

Feeling refreshed, let's get these hardware problems sorted. Get the Windows server booted with “Hirens Boot CD” magic set of tools for fixing loads of stuff. Diagnoses that there are a couple of missing .DLL's. Okay, patch them in, still problems! seems to be a hall of mirrors every time we patch something in, the next missing file is found. This could go on for ages. 

Try various Windows recovery reinstalls, but they all fail, Windows 2003 doesn't think it's installed, but would happily install if I let it reformat the hard drive. Not the recovery I was looking for. Run some disc-checking utilities and basically whilst the disc checks out okay, the file directory (or whatever it's called) is smashed. Do we spend a lot of time rebuilding a Windows system that's only running one piece of software that should have been moved off anyway? Simple choice, no. Leave it to my co-worker Mark to figure out what to do to get mail flowing again, whilst I take a look at the 917 memory problem.

Pulling the memory card is no problem. Working out which of the five banks is bad takes a bit more work, but a bit of plug engineering and a couple of reboots shows that we have 64MB (2x32) of bad memory. No problem, plenty left, so remove it and reboot. Great, get to the ISL prompt, do a START NORECOVERY and go get a cup of coffee and a cigarette, and I’ll soon have this system back up.

SYSTEM ABORT from SUBSYS 143

SYSHALT 7,$0267

FLT DEAD

Oh, hell.  

Long Story Short (or another one bites the dust)

Okay, it's about time we cut this story short — although I am certain you want to read about someone else's trials and tribulations, even as I suspect you’re only reading to find out why your UPS is useless. Suffice it to say that the 3000's LDEV 2 had also been fried, which we replaced, then the DAT drive was dead, which was replaced, but was still dead.

So in the end, we decided our fastest recovery solution was to scrap the 917 and merge its data with a 918 that has a clone in the shop. It’s a choice which makes DR recovery a lot simpler, also one less piece of kit burning electricity, that should help save the ice caps!

So what got Fried? HP 3000, Dell Intel Server, one modem, one DTC 16 -- and of course the two APC UPS's that were supposed to be protecting everything.

Why? Okay, okay, I've finally got around to the Meat and Potatoes bit. Given that the APC “Smart” UPS's had done such a wonderful job of protecting everything, it didn't seem much point sending them off anywhere for repair and putting them back into service. Also, I needed to get some replacements in ASAP. But the conundrum was why they hadn't protected everything as had been my expectation, so it’s about time to do some research on UPS's.  

It turns out there is a little bit of a clue in the three letter acronymn. The “U” stands for “Uninterruptible” not “Clean.”  I discover that there are two main types of UPS: the normal Line-Interactive. Everyone makes them, everyone's got one UPS like the APC Smart UPS. Then there’s the “On-line” ones. The major difference is that standard “Smart” UPS's (most of the time) feed a mains supply out to everything plugged into it. In contrast, the  on-line versions feed everything from an inverter 100 percent of the time.

But I hear you say (and as I thought) “My APC UPC filters the power, chopping down over voltage, boosting under voltage, and supplying power if the mains fails.”  Well the answer in classic 3000-L mode is, “Yes, but it depends.”  Now I'm no electrical expert, but I’ve worked up a layman's interpretation.

There’s something in the mix called Dirty Transfers.

Line Interactive UPS's do AVR, Automatic Voltage Regulation. Instead of going to battery during low or high input voltages, this sort of unit will use an Autotransformer to increase or reduce the voltage to a safe operating range without running on the battery. Within their stated tolerances, they can run almost indefinitely doing a number of things.

  • AVR Boost, where the UPS is compensating for a low utility voltage;
  • AVR Trim, when it is compensating for a high utility voltage.
  • If the voltage fluctuates outside a set range, or on some of them if the rate of change of the voltage exceeds a given threshold, then they will Transfer, using the battery power via an inverter. The UPS then monitors the AC supply and when it deems it is back within tolerance it transfers back to the mains supply.  

It is this Transfer Time (TT) that can cause some problems. Such as those at our shop.

In the finale: Keeping it clean, and learning you're an HP customer once again.

Posted by Ron Seybold at 09:10 AM in Hidden Value, Homesteading, Newsmakers, User Reports | Permalink | Comments (0)

July 01, 2013

Will MPE spell its end date in 2028?

CalendarPage9thWe'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).

Another manager checked in to tell us his system won't get to experience the new two-digit power of a 2028 edition of the virtualized HP 3000 -- certainly driven by a CHARON virtualized 3000 at that point.

Entitled "Schlegel's HP3000 end of life," the message was delivered by Tom Ruganis, MIS Manager Emeritus.

I have been an HP user/manager for 37 years at Schlegel in Rochester, New York, starting on a Series II. We are now running a single 968RX, down from a network of six 3000s. For the last 20 years, we have run a mix of MANMAN and in-house Sales/Order Entry with a lot of local “enhancements.”

Our plans are to replace this with Enterprise IQ from IQMS, running on a Windows-based server, based in South Dakota. Hopefully this will occur soon, as I will be retiring as of this Friday (7/5/13).

In the meantime, I will be providing contract support.

It will be a sad day when we finally pull the plug.

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

June 26, 2013

Steps for Doing a Final HP 3000 Shutdown

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. 

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

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:35 PM in Hidden Value | Permalink | Comments (0)

June 24, 2013

Open source resource: Secure FTP on 3000

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

Edminster goes on to explain he administers that site, as well as puts together the 'pre-packaged' install available there. It's in a single store-to-disc file in Reflection 'WRQ' format, making it easy for the majority of sites to retrieve and use. Here's the URL:

http://www.mpe-opensource.org/navigation/Package_Name/sftpquick-start.html

I have a customer that's been using SFTP daily as part of their PCI compliance solution for several years. They push and pull data hourly from dozens of Point-of-Sale systems all over the country, and have moved lots of data this way.  

The biggest caveat from that customer's implementation is that if you're moving data over a WAN, SFTP seems to be more sensitive to jitter and latency issues than conventional FTP.  We ended up having to upgrade a couple of their more anemic 'last mile' circuits to accomodate that.  

In all other respects, it’s quite a robust solution, and can be tightly integrated with existing legacy apps. I know; I've done it.

If you have any questions about how to use the pre-packaged install -- or how to get around any limitations you might run into,-- don't hesitate to contact me. I've used this on dozens of systems over the last decade, and have transferred many, many gigabytes of data with it.

 

 

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

June 21, 2013

How to Transfer Data Files on a 3000

DatabasetransferIt'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.

"First try this little experiment," Hofmeister began in her answer.

    file mystd;dev=disc
    store a@.pub.sys;*mystd;show

if it works, you just stored/archived all the files that begin with 'a' in the .pub group of the .sys account into a file called 'mystd' (my store-to-disc).  You can expand the number of files being stored into your STD file by modifying your store command to:


    @.pub.sys -- all files in .pub.sys
    @.@.sys   -- all files in .sys
    @.@.acct  -- all files in .acct (for example)
    @.@.@     -- all files on the system (and it's actually better to say '/' instead of '@.@.@')

Keep in mind that as you increase the scope of what your storing, so does the size of your STD file. In other words, to store the whole system you need 50 percent or more free space , which you probably don't have. So, break what you're storing into chunks (do one account at a time) and things should go smoothly.

If STD doesn't work, you might be able to get tar to work. The same space precautions apply.  One advantage of using tar is you should be able to verify the tar file on the destination system -- something you can't do with STORE without a 3000 in the mix.

Chris Bartram, who still operates an information treasure-house in 3k.com, added explicit advice about FTP and the 3000's files.

If you package all the MPE files up in either a store-to-disk (aka std) or a tar "wrapper" (disc file) you can transport that file around at will -- as a BINARY file -- don't try to transfer it as ASCII or CR/LF translations will trash it.

Once you get it back on the 3000, a simple file equation directing your source (tape) to the new (std) file name (and add the ;DEV=DISC to the file equation) will allow you to restore the files onto the 3000 preserving all the MPE specific file attributes they started with. Tar will work similarly for almost all MPE files, but can't handle database/PRIV files and probably not MSG (message) files and a few other very MPE-specific files.

tar works the same way on MPE as on *nix boxes. But is much more "familiar" if you run it from the Posix shell (sh.hpbin.sys), though that's not necessary. Treat the tar file just like you would on a *nix box.

For store-to-disc files, you use the same MPE syntax for storing files as you do normally; the only difference is that the output device is file-equated to ;dev=disc. As mentioned, be aware of the disc space required to store another copy of your backed-up files online.

Likewise, when you restore instead of pointing to tape, you point to the disc file -- and don't forget to add ;dev=disc to that file equation as well. If the store-to-disc files are going to be very large (several gigabytes) you can use some additional syntax to break them into chunks - but hopefully you needn't worry about that for now.

Treat a store-to-disc file just like a tar file. Record size and most other attributes aren't so critical, but if you move it around do NOT let FTP transfer it in ASCII mode or it will corrupt the file.

As for examples; I back my primary HP 3000 up to a disc file then transfer (FTP) it to a Linux server. Here's the gist of my JCL:

!FILE t=FULLB.PUB.BACKUP;DEV=disc
!CONTINUE
!STORE / - /BACKUP/ ;*T &
! ;SHOW=SHORT,dates,path;progress=5;directory;tree;&
! onvs=MPEXL_SYSTEM_VOLUME_SET,WORK;STATISTICS;COMPRESS=HIGH

!ftp.arpa.sys
open ftpserver
user userid password
del hp3000-full
binary
put FULLB.PUB.BACKUP hp3000-full
quit

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

June 20, 2013

How to Back Up On An Emulated 3000

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

The technique of copying an entire CHARON disk image file is useful when moving an entire virtual HP 3000 to another server, or returning the local server to a prior state. You can, for example, back up your system, conduct a test of your month-end processing, and then return your system to its original state, quickly and easily, by copying the Linux folder containing your disk images. One important note: the virtual CHARON HP 3000 must be shut down before copying the virtual disk image files.

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

May 17, 2013

Many Different Ways to Move Your Console

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

Former HP support engineer Lars Appel offered another take on Schipper's strategy:

While Gilles is right about the possibility of using the web console, it would probably be easier to use the already built-in dedicated LAN port of the N-Class systems that gives access to the GSP by telnet.

I prefer the “telnet console” over the “web console” because it gives more freedom in the choice of terminal emulator — whereas the web console typically lacks features like “easy cut and paste” or special key mappings (e.g. German language ;-) or something similar.

This prompted Schipper to clarify his suggestion:

Lars is absolutely right about the built-in “secure-web-console” that comes with all N-Class and all but the earliest A-Class e3000s.

And, yes, the built-in is definitely more functional, allowing cut-and-paste as well as telnet access, whereas the external variety has only Java access to it via a web browser and no cut-and-paste.

So, if one has a choice, the built-in is definitely superior and available with only proper configuration.
However, the external secure web console is available for all HP 3000s, and would still be most useful where is internal secure web console is not an option.

Jeff Kell, curator of the 3000 newsgroup where the advice appeared, added the last word and a little joke:

The internal one isn't really "secure" — it's plaintext telnet. The GSP "documents" some secure access mode (ssh? https?) but I could never get it to work on our A-Class.  Maybe it's an HP-UX thing. 

The external web console was the really insecure "secure" web console.  It used a secret decoder ring :-)

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

May 02, 2013

Value Hidden, and Uncovered

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.



But how can I have two bad DDS-2 drives?

Gilles Schipper notes:

Not surprising at all. I once experienced the following situation. Our customer had a disk crash. Fortunately, it happened just after a full backup. HP replaced the faulty disk drive and we proceeded to perform a system reload from the just-completed backup that had been to a DDS-2 tape drive.

As soon as we mounted the tape (on exactly the same tape drive that created it), we received a console message indicating AVR error on LDEV 7. I knew right away we had a problem. HP returned to replace the tape drive with another DDS-2 drive. Still no joy. We recommended replacing the drive with a DDS-3 tape drive. As soon as this was done, the reload proceeded without further problems.

The bottom line is stay away from DDS-2 drives, as far away as possible. From this experience and others, I have concluded that the DDS-2 drive is, to put it mildly, flaky.

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

April 30, 2013

How to Shift a 3000 from FTP to SFTP

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. 

However, if you've never done anything on your 3000 make it act like a real computer (oh -- that's right, it is a real computer and fully capable of using DNS), this can turn into a can o'worms.

For 'DNS lite', it's probably simplest to:

1. copy hostsamp. net to hosts.net

2. edit hosts.net to make sure it has

127.0.0.1 loopback
1.2.3.4   name    <--- where 1.2.3.4 and name are corrected to the system you want to connect to

3. copy the NSSWSAMP.net to nsswitch.net

4. edit nsswitch.net to have this line:

hosts : files[SUCCESS=return NOTFOUND=continue]

With this done, the 3000 sorta kinda acts like it's using DNS (because it's looking the the hosts file for how to translate 'name' into '1.2.3.4')

Tony Summers provides a caveat:

One warning. The upgrade from FTP to sFTP (or SSH FTP etc) can involve more change to your scripts that you expect.  

What we do for FTP (originally on the HP 3000, and now on the HP-UX server) is build a text file with the commands (the sample below, edited)

cat FTPT0070
open ftpserver.site.co.uk
user USERNAME PASSWORD
ascii
get /export/002_iccm_extract_1161.csv ICR21161

quit

The file is then presented to the FTP client. On the HP 3000 it was something like....

RUN FTP.ARPA.SYS < FTPT0070 > FTPS0070  

Then both the output file, FTPS0070, and any JCWs set by the FTP program were inspected to test the success of the FTP session.

cat FTPS0070

Connected to xxxxxx.co.uk

220 Welcome to FTP service - xxxx.
331 Please specify the password.
230 Login successful.
200 Switching to ASCII mode.
200 PORT command successful. Consider using PASV. 550 Failed to open file.
221 Goodbye.

In particular,  the 3-digit status codes were analysed,  looking for error codes like "550".If you do something similar in your FTP scripts,  then all I can say is welcome to a very different world.

Karsten Brøndum adds:

Here's a completely different approach. 

Depending on your skills in the Java area there is a nice LPGL package called ftp4j (which requires Java 1.4 or later) that i have used a couple of times. (By the way, ftp4j will do both SFTP and FTPS). I've found it way easier than to fiddle with files with text files containing commands, especially when it comes to error handling.

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

April 15, 2013

SM for Everyone!

By Bob Green

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

RobelleTechHe 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

<beginarticlequote>

When a user tries to open a file, MPE checks the account security matrix, the group security matrix, and the file security matrix to see if the user is allowed to access the file. If he is allowed by all three, the file is opened; if at least one security matrix forbids access by this user, the open fails.

For instance, if we try to open TESTFILE.JOHN.DEV when logged on to an account other than DEV and the security matrix of the group JOHN.DEV forbids access by users of other accounts, the open will fail (even though both TESTFILE’s and DEV’s security matrices permit access by users of other accounts).

Each security matrix describes which of the following classes can READ, WRITE, EXECUTE, APPEND to, and LOCK the file:

• CR - File’s creator

• GU - Any user logged on to the same group as the file is in

• GL - User logged on to the same group as the file is in and having Group Librarian (GL) capability

• AC - Any user logged on to the same account as the file is in

• AL - User logged on to the same account as the file is in and having Account Librarian (AL) capability

• ANY - any user

• Any combination of the above (including none of the above)

...

Whenever any group is created, access to all its files is restricted to GU (group users only).

<endarticlequote>

As Eugene points out above, account users do NOT have Read access by default to a new group in their account. This was the source of the problem at the site Vladimir was visiting. When the jobs could not read the files in the new STUSE group, the system manager the wielded the MPE equivalent of the medieval broadsword: give all the users SM capability.

ALTUSER PRODCLRK; CAP=SM,IA,BA,SF,...

This did solve the problem, since it certainly allowed them to read the STUSE files, but it also allowed them to read or purge any file on the system, in any account.

What he should have done was an Altgroup command immediately after the Newgroup command:

ALTGROUP stuse; access=(R:any;a,w,x,l: gu)

or specified the correct access when the group was built:

NEWGROUP stuse;access=(r:any;a,w,x,l:gu)

Since the HP 3000 runs in a corner virtually unattended (except for feeding the occasional backup tape), we often forget many of the options on the commands that are used sparingly. Neil Armstrong, my cohort in our Labs, often does a Help commandname to remind himself of some of the pitfalls and options on the lesser-used commands, NEWGROUP being one of them.

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

April 09, 2013

Good tools making an impact, then and now

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.

 

The Predictive Support files in the SYS account include two very useful tools. While auditing the content of a system, I found : 

PSQUAD.PRED.SYS (yep, that's a March 1992 'CM' version of Quad, the customizable editor credited as being developed by Jim Kramer of Quest Systems and Kenneth Stout of Summit Information Systems). It's no QEDIT, to be sure. But Quad sure beats having to use EDIT/3000. 

There’s also PSUNLDDB.PRED.SYS and PSLDDB.PRED.SYS. Believe it or not, these are re-named versions of DICTDBU and DICTDBL!

To use these, 

  • copy PSUNLDDB.PRED.SYS to DICTDBU.PUB.SYS, 
  • copy PSLDDB.PRED.SYS to DICTDBL.PUB.SYS, and
  • copy DICTCAT.PRED.SYS to DICTCAT.PUB.SYS

Okay, perhaps moving these files is bordering on unintended use, and not considered kosher. In that case, set a file equation for the catalog (file dictcat.pred.sys=dictcat.pub.sys), and alter file and group security so you can run the files as they sit.  

Either way, this gives you a tool that beats DBUNLOAD/DBLOAD for database capacity maintenance and manipulation — if should you be unfortunate enough to not have the proper tools like Adager, or even DBGeneral.

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

April 05, 2013

Living a Privileged 3000 Life without SM

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.  

Sudo is a Unix tool that is designed to allow specific non-super-users restricted (and optionally logged) access to commands that normally require 'su'.  In MPE/iX parlance, it's a way to allow specific users restricted and logged access to commands requiring more than regular 'vanilla' user capabilities.  My take on this is that proper use of MPE/iX's privileges would make a "SuDo/iX" unnecessary, but your mileage may vary.

You might ask, what's the harm of allowing SM to an application user who is normally 'captive' within a logon, no-break UDC that forces the user into the application, and logs them off on exit?  How about the admin (who shall remain nameless, even though they're retired now) that accidentally did a 'Purge @.@.@;Yes' -- except they were thinking they were logged into a test server, not one of the production machines.

And as for regularly changing passwords to application databases, auditors are usually talking about "user application access" passwords. From a best practices perspective, these shouldn't be the actual database passwords, but rather should be values stored in a table of authorized application users and their respective privileges.

That said, if you find yourself with a need to regularly change the physical database passwords, put that call to the DBOPEN routine (or retrieval of the password to be used for it) into a XL library.  That means recompiling the library, not the application, when the passwords have to change.

And lastly, if your system has to be that tight, you probably shouldn't store user application passwords in clear-text in the database, either.  Instead, apply a one-way hash to the value when it's initially stored.  Then, any time a user supplies their password, it's run through that hash again and compared with the stored value. If they match, the passwords match.  

The folks at Beechglen have a callable 'MD5' hash routine just for this purpose. Look for heading about 'MD5 Checksum' at "http://www.beechglen.com/mpe/data-encryption. In poking around the Freeware section of Beechglen's site, I saw they have a program called 'su' that is essentially a more controlled version of the old 'GOD' program. I haven't used it personally, but anything that allows more granularity of control in granting access and power is a good thing.

 

 

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

April 04, 2013

Privileges litter the path to passed audits

Yesterday we studied the ways that migrated HP 3000 data can become forgotten while making provisions for an audit. Since some HP 3000s work as mission-critical servers, these active, homesteading systems must weather IT and regulatory audits. The 3000 is capable of passing these audits, even in our era of PCI, HIPAA and Sarbanes-Oxley challenges — all more strenuous than audits of the past.

However, establishing and enforcing a database update procedure is a step onto filling the gap in the security of an MPE/iX system. HP 3000 managers should take a hard look at how their users employ System Manager (SM) privileges. (Privileged Mode, PM, and System Supervisor OP should also be watched. Overall, there can be 21 capabilities to each user.) In their most strict definition, those privileges can expose a database. Hundreds of users can be created at Ecometry sites; even seasonal help gets SM users, according to one consultant's report, users which are seldom deleted after the holiday has passed. One site had a script to create new users, and each had PM capability, automatically.

VEAudit from VEsoft, using its LISTUSER @.@ (CAP("SM")) filter, can give you a report of all of the SM users on your HP 3000. You can even ask for the SM users where password="". (Now there's a good list to find: SM users who have no passwords.) There is no MPE command that will do such things, we are reminded by VEsoft co-founder Vladimir Volokh. Even after more than three decades of his business as a 3000 software vendor, he also offers consulting on MPE operations and management, and still travels the US to deliver this. 

Privileges are often a neglected aspect of 3000 operations, especially when the system's admin experts have moved on to non-3000 duties, or even to other companies. (Then there's the prospect that nobody knew how to use privileges in the first place.) Some SM users have disturbed the integrity of 3000 databases. It's easy to do accidentally. A creator of a database can also update a 3000 database — a capability that can foul up a manager's ability to pass some audits.

 

If you are worried about arbitrary access via QUERY, you can "disable subsystem access" via DBUTIL. This will, of course, only disable the access on QUERY.

Some less-adept auditors can also demand that a database's password be changed every 90 days. It's quite impossible to do, considering the database password is built into every application program.

So a database's security might be compromised through SM privileges, but it depends on the meaning of "update." This term can be construed to be as restrictive as using DBUPDATE to change an entry. It can also refer to UPDATE access DBOPEN MODE 2. 

To get very specific, an update can mean that the modify date has been changed in the file label of one or more IMAGE-related files. In a very general definition, an SM user can update the database simply by way of a restore from tape. (OP privileges permit this, too.)

Auditors sometimes ask broad questions, the sort of inquiry that fits better with the everyday use of HP 3000s in an enterprise. But for MPE/iX experts, "update" means any kind of modification capability.

So you can answer your auditor's question and say "no, SM privileges don't permit any of our users to update a database in another 3000 account." This answer is true, to the extent that the auditor's concern is about changing data — not just making a minor date change or using DBOPEN MODE 2. For auditors without MPE/iX and IMAGE expertise, well, they might not go so far in their examinations.

As for the SM user's ability to muck up an IMAGE database, it’s a mistake that is not difficult to make. An SM user who obtains a database password can corrupt an IMAGE database just by using the restore command. We’ve heard a story that such a user might explain, "Oops, I thought I was signed onto the test  account."

It's important to make a system fool-proof, because as Vladimir says, "fools are us." 

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

March 18, 2013

Still Patching After All These Years

PatchesHP solved the problems of the 3000 and MPE with patches, revised software which Hewlett-Packard still distributes today. Probably not as seamlessly as it did while the company supported the system. But just as inexpensively: MPE/iX is one of the only HP operating systems with free patches. The still-engineered and fully-supported OS lineup requires an HP support contract to retrieve patches, even the critical ones.

Patches resurfaced in my reporting this afternoon while I interviewed a consultant to a large site, one where 22 HP 3000s once ran altogether. Today it's a couple of N-Class servers. He was feeling good about the chances for a Stromasys emulator there, partly because the customer is already running on MPE/iX 7.5. The final generation of the OS is required to run the Charon HPA/3000 emulator.

"We got away from using Large Files, too," he added. "I think HP never did fix that corruption bug in those." That would be the >4GB corruptor, discovered in 2006 by Adager and finally fixed in '07 by HP's IMAGE/SQL labs. The repaired software required a millicode patch, the first one HP'd written for the 3000 in 16 years. You can get that patch via HP's Response Center website. But that's not how most 3000 managers are getting these patches today.

The number of HP contract-holding 3000 administrators has dropped since the 2007 date of patch MILNX10A. Most people are calling into HP's support line, then plowing through the confusion that arises when you ask for something related to HP and a 3000.

"If one has a functioning support center logon, then yes -- you can download the patch via the Web," said one indie support provider. "I find most people need to call the support line. I always tell them to take their patience with them, as it can be challenging to get past the initial call handlers.  ("No…my 3000 is not a printer…")  You’ll eventually get to the one (?) person still handling MPE patching requests."

We are told, by Allegro Consulting's Donna Hofmeister, that "the magic incantation when dealing with the Response Center folks is to use transfer code 798. That’ll get you to an MPE person."

MILNX10A is important enough to patch, especially on a 3000 that's got databases that are still growing. One traditional advisory in the 3000 community is that "there are three things that can happen when you apply a patch, and two of them are not good." So that limits an administrator's gusto for patching -- but this corruption problem was a big enough deal for HP to label that patch critical.

The patch repairs access to any in-house applications that have used Large Files, or do a sort with a temporary file that can exceed 4GB. If your app has not been modified since March 30, 2000, it's safe. That's when HP introduced the Large File feature.

Large Files has been engineering which HP worked to remove from customers' 3000s. A 2006 patch was designed to turn off Large Files and get those files on the 3000 converted to Jumbo files, much better engineered. Jumbos were at work where our consultant was arranging an audition for the emulator.

MILNX10A is not stageable because it requires a installation job. It is most easily installed by using HP's autopat.  Autopat, at its conclusion, will say "stream this.job." A couple of blinks later, milli.lib.sys (and friends) is updated.

MILNX10A won't be enough to fix this corruption problem. HP's repair also requires MPENX11A. Unlike the millicode patch, MPENX11A is not stageable, as it is a patch that requires a reboot. A manager can use Patch/iX to get the patch staged and schedule a reboot.

If you don't know if you should apply this patch, contact your support provider. If you're patching, pay attention to when you run 'unpackp.' We'd love to hear any experience you might have while navigating the free phone support from HP for these patches.

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

March 08, 2013

Change your clocks, all the time

ClockgoingforwardThe US will roll its clocks forward by one hour this weekend. That means it's time to anticipate the questions 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 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!

 

Also, this job depends on the variable TZ being set -- which is easily done in your system logon udc:

    SETVAR TZ "PST8PDT"

Adapt as needed. And don't forget -- if your tztab file is out of date, just grab a copy from another system. It's just a file.

This job below was adapted from logic developed by Paul Christidis:

 !JOB SETTIME,MANAGER.SYS;OUTCLASS=,5
!TELLOP       SETTIME  
!TELLOP       ALL MPE SYSTEMS
!TELLOP ==SETTIME -- SYNCs SYSTEM CLOCK W/ TIME SERVER !
!# from the help text for setclock....
!# Results of the Time Zone Form
!#
!#   If the change in time zone is to a later time (a change to Daylight
!#   Savings Time or an "Eastern" geographic movement), both local time
!#   and the time zone offset are changed immediately.
!#
!#   The effect is that users of local system time will see an immediate
!#   jump forward to the new time zone, while users of Universal Time
!#   will see no change.
!#
!#   If the change in time zone is to an earlier time (a change from
!#   Daylight Savings to Standard Time or a "Western" geographic
!#   movement), the time zone offset is changed immediately.  Then the
!#   local time slows down until the system time corresponds to the
!#   time in the new time zone.
!#
!#   The effect is that users of local system time will see a gradual
!#   slowdown to match the new time zone, while users of Universal Time
!#   will see an immediate forward jump, then a slowdown until the
!#   system time again matches "real" Universal Time.
!#
!#   This method of changing time zones ensures that no out-of-sequence
!#   time stamps will occur either in local time or in Universal Time.
!#
!showclock
!showjob job=@j
!TELLOP =====================================  SETTIME   A-1
!
!errclear
!continue
!/NTP/CURRENT/bin/ntpdate "-B timesrv.someplace.com"
!if hpcierr <> 0
!  echo hpcierr !hpcierr (!hpcierrmsg)
!  showvar
!  tellop NTPDATE problem
!endif
!
!tellop SETTIME -- Pausing for time adjustment to complete....
!pause 60
!
!TELLOP =====================================  SETTIME   B-1
!showclock
!
!setvar FallPoint &
!   (hpyyyy<=2006 AND (hpmonth = 10 AND hpdate > 24)) OR &
!   (hpyyyy>=2007 AND (hpmonth = 11 AND hpdate < 8))
!
!setvar SpringPoint &
!   (hpyyyy<=2006 AND (hpmonth =  4 AND hpdate< 8)) OR &
!   (hpyyyy>=2007 AND (hpmonth =  3 AND (hpdate > 7 AND hpdate < 15)))
!
!# TZ should always be found
! if hpday = 1
!    if SpringPoint
!# switch to daylight savings time
!      setvar _tz_offset   ![rht(lft(TZ,4),1)]-1
!      setclock timezone=w![_tz_offset]:00
!    elseif FallPoint
!# switch to standard time
!      setvar _tz_offset   ![rht(lft(TZ,4),1)]
!      setclock timezone=w![_tz_offset]:00
!    endif
!  endif
!endif
!
!TELLOP =====================================  SETTIME   C-1
!
!showclock
!EOJ

Mark Ranft of 3k Pro added some experience with international clocks on the 3000.

If international time conversion is important to you, there are two additional things to do.

1) Set a system-wide UDC to set the TZ variable. (And perhaps account UDCs if accounts are for different locations)

:showvar tz
TZ = CST6CDT

2) There is also a tztab.lib.sys that needs to be updated when countries change when or if they do DST.

:l tztab.lib.sys
ACCOUNT=  SYS         GROUP=  LIB     

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

TZTAB            1276B  VA         681        681   1       96  1  8


:print tztab.lib
# @(#) HP C/iX Library A.75.03  2008-02-26

# Mitteleuropaeische Zeit, Mitteleuropaeische Sommerzeit
MEZ-1MESZ
0 3 25-31 3  1983-2038 0   MESZ-2
0 2 24-30 9  1983-1995 0   MEZ-1
0 2 25-31 10 1996-2038 0   MEZ-1

# Middle European Time, Middle European Time Daylight Savings Time 
<< snipped >>

 

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

March 01, 2013

Next weekend, it's all in the 3000's timing

Time-changeEditor's Note: Daylight Saving Time begins at 2AM local time around most of the world next weekend. A lot of HP 3000s run around the clock to serve companies, so a plan to keep the 3000 on time is essential. The founder of the HP 3000 open source repository MPE-OpenSource.org, Brian Edminster, offers a plan, some experience, and a sample jobstream to help get you through our semi-annual time change.

By Brian Edminster

Here's an important implementation note for anyone that wants to put up a 'time synchronization' client on their HP 3000: Do not use it to adjust for spring and fall time-changes!  Use a job that runs on the appropriate dates/times to do a 'setclock timezone=' command.  I have an example below that is a derivative work from something originally posted by Sam Knight of Jacksonville University, way back in April, 2004 on the 3000-L mailing list.

I've updated the job to be more readable, to account for a 'looping' effect that I found in the fall from running on a fast CPU, and to run at 2AM -- the 'official' time that time-changes apply. I have this job set to be intiated by 'SYSSTART.PUB.SYS' on server bootup, and then automatically reschedule itself each Sunday at 2AM.

I'd suggest doing whatever sort of time synchronization necessary before this runs each weekend - so the time corrections complete before this job runs.

Here's the spring and fall time change jobstream code. You can use this and modify it for your specific needs. Note that it's set up for the Eastern US time zone. (That's the TIMEZONE = W5:00 -- meaning the number of hours different than GMT -- and TIMEZONE = W4:00 lines.)  Modify these lines as necessary for your timezone.

!JOB TIMECHG,MANAGER/user-passwd.SYS/acct-passwd;hipri;PRI=CS;OUTCLASS=,1
!
!setvar Sunday,    1
!
!setvar March,     3
!setvar November, 11
!
!showclock
!if hpday = Sunday and &
!   hpmonth = November and &
!   hpdate < 8 then
!   comment (first Sunday of November)
!  SETCLOCK TIMEZONE = W5:00
!   TELLOP ********************************************
!   TELLOP Changing the system clock to STANDARD TIME.
!   TELLOP The clock will S L O W   D O W N  until
!   TELLOP we have fallen back one hour.
!   TELLOP ********************************************
!elseif hpday = Sunday and &
!       hpmonth = March and &
!       hpdate > 7 and hpdate < 15 then
!   comment (second Sunday of March)
!  SETCLOCK TIMEZONE = W4:00
!   TELLOP *********************************************
!   TELLOP Changing the system clock to DAYLIGHT SAVINGS
!   TELLOP TIME.  The clock jumped ahead one hour.
!   TELLOP *********************************************
!else
!   comment (no changes today!)
!   TELLOP *********************************************
!   TELLOP No Standard/Daylight Savings Time Chgs Req'd
!   TELLOP *********************************************
!endif
!
!comment - to avoid 'looping' on fast CPU's pause long enough for
!comment - local clock time to be > 2:00a, even in fall...
!while hphour = 2 and hpminute = 0
!   TELLOP Pausing 1 minute... waiting to pass 2am
!   TELLOP Current Date/Time: !HPDATEF - !HPTIMEF
!   showtime
!   pause 60
!endwhile
!
!stream timechg.jcl.sys;day=sunday;at=02:00
!showclock
!EOJ

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

February 28, 2013

A Thorough Chill of the OS Business

LGFridgeThe consumer product maker LG has announced it's purchasing the webOS team, talent and tech from HP. This means a company whose lineup includes french door refrigerators now owns the most modern mobile OS in the world. As it turns out, great technology like webOS doesn't have much value in the hands of a company which can't create demand for the magic.

There's so little value left in webOS that the joint release about the sale says "HP and LG do not expect this transaction to have a material impact on either company's financial statements." And so, without even a report of what webOS cost, HP froze itself out of another OS product line.

Some operating systems not only have enduring value, but they are also drawing top talent to their community. It happened late last year for RedHat's Linux; Jeff Vance took his next step away from HP's 3000 guru days, when he made his transfer from K-12 vendor QSS to the Hat. Vance arrived at QSS with gusto for newer development environments and got to ply his passion for years there.

But the signals sent by selling off an innovative OS for "no material impact," well, they say a lot about how system makers create their value in 2013. The mobile OS that was going to unseat Apple made its HP departure with the same language as 3000 customers shared about MPE/iX. The end of the line wasn't really the end of the line, was it?

 

At webOS Nation, the site's editors watched HP turn to a commodity technology the vendor doesn't own. They asked "Is this the end of webOS, or just the end of HP and webOS? Is this news of an HP Android tablet a nail in the coffin of Open webOS -- or is it just a nail in the coffin of HP webOS?"

Just swap in MPE/iX in those questions and you can hear the echo of 2002-05. An avid vendor base wanted a further life for MPE/iX, but HP didn't even want to sell out of that OS. The company got asked, too, in the months that followed the 3000-exit decree from HP. "Sell us the 3000 business, since you're getting out," one MPE stalwart vendor offered. HP declined while it went cold on its most storied business OS -- one used at big sites, too.

However, knowing deep secrets of extraordinary technology still has its advantages, even today. An HP veteran of 31 years sat at the Old Austin Cafe next to us last night. My friend Scott Hirsh, formerly of the 3000 world's system manager leadership and now tackling tech presales at Dell, wanted an authentic Texas chicken-fried steak to enjoy with us. That HP fellow "couldn't help but overhear" us raving about history and HP and the 3000. A handshake later he was sharing colleagues-in-common with Scott.

The HP veteran had started out in sales at the Neely Region (the US West) and soon moved to 3000 sales in the Series III era. He'd held jobs as a CE and an SE in a company where software was designed to sell servers. Where even a Local Area Network offering became LAN/3000. Just because it was a standard tech didn't mean HP wanted to brand it.

"I miss the days of Bill and Dave," he said by way of introduction. We were all on the same team for awhile over our steaks. But he also was carrying the torch of tech in newer environments, installing 3Par storage with its many nuances for an HP site.

"These days I never see the inside of offices at HP," he said when we talked about changing technical structures. He's on the road 80 percent of the time, with the off days at his home office. An expert in the 3000's OS might find a similar future, if they can find customers who still value their operating system.

Posted by Ron Seybold at 02:54 PM in Hidden Value, Migration, News Outta HP | Permalink | Comments (0)

January 08, 2013

How to Make HP's Diagnostics Free on MPE

ComputerdiagnosticMore than two years ago when HP officially closed its formal HP 3000 support, the vendor left its diagnostics software open for use by anybody who ran a 3000. Throughout the years HP sold 3000 support, CSTM needed a password only HP's engineers could supply. But the CSTM diagnostics tools started to run on January 1, 2011 without any HP support-supplied password. 

However, managers need a binary patch to free up the diagnostics. Support providers who've taken over for HP know how to enable CSTM. The community has a former Hewlett-Packard engineer to thank, Gary Robillard, for keeping the door to the diagnostics open. Robillard says he is "the engineer who, last worked on CSTM for MPE/iX when I was still a contractor at HP back in 2008."

A 3000 site must request a patch to get these expert tools working. HP arranged for 3000 sites to get such patches for free at the end of 2010. We tracked the procedure in a Newswire story, just in case that HP link above goes dark.

One such patched version of CSTM needs a binary patch. This month Robillard was revisiting his binary patch fix, which can be a part of using these diagnostics, with the HP patch ODINX19A noted below.

Versions of CSTM [patched] with ODINX19A or ODINX25A allow the expert tools with no licensing, but you still have to issue the HLIC command. 

If you install ODINX25A/B/C (6.5,7.0,7.5) you won't need to do anything except issue the hlic command with any password. The HLIC command might say it was not accepted, but the license is activated anyway.

At the end of 2010, Robillard said his patch corrects the problem with ODINX19A -- and gives 3000 managers access to these system diagnostics -- for servers running the 6.5, 7.0 or 7.5 versions of CSTM.

If you have installed ODINX19A, you need to do the following:

Logon as MANAGER.SYS. It's safest to create an input file to sompatch.

1. Run editor.pub.sys

2. Add the following three lines EXACTLY. The sompatch will only work if the instruction at offset 268 matches 86a020c2. The message "Error: Old value does not match" is displayed and no changes are made)

Here are the contents of BINPCHIN file (You will want to copy and paste these); 

~~~~~The 3 lines are below~~~~~~~

; Fix problem in DIAGMOND after 12/19/2010
modify ms_init_manage_sys  + 268,1 86a020c2|08000240 
exit
~~~~The 3 lines are above~~~~~~~~
//
K binpchin,unn 

• Make sure DIAGMOND is not running (run STMSHUT.DIAG.SYS)
copy /usr/sbin/stm/uut/bin/sys/diagmond,DIAGMOND 
run sompatch.pub.sys;stdin=BINPCHIN;INFO='DIAGMOND' 
copy DIAGMOND,/usr/sbin/stm/uut/bin/sys/diagmond;YES 
• Restart DIAGMOND (run STMSTART.DIAG.SYS

After a few minutes, a "SHOWPROC 1;TREE;SYSTEM" should show the DIAGMOND process, and either the mapping processes, or memlogd, diaglogd and maybe cclogd (on A/N Class 3000s only).

Posted by Ron Seybold at 05:53 PM in Hidden Value, Homesteading, News Outta HP | Permalink | Comments (0)

January 03, 2013

Panel producer pursues PDF processes

NorbordNorbord, an international producer of wood-based panels, runs some of its operations on an HP 3000. This $1 billion company with 13 operating sites around the world needed to create PDFs on its 3000, a task assigned to John Pickering of the company. He went to the 3000 newsgroup for advice on how to do this, working to discover free, online resources already stocked away by indie support companies.

Pickering began by pursuing shareware, which is can sometimes be the budget choice for 3000 shops. (There's a superior and tested PDF-creating solution from Hillary Software, byRequest, which does this for 3000s as well as other enterprise systems.) But if a site wanted to bale together shareware like the txt2pdf software, a manager like Pickering needs Perl to run.

I'd be happy to use the shareware txt2pdf, but I don't know where to begin. The Sanface web site indicates that Perl is required, but that isn't on this 3000, either.

Allegro Consultants, supporting 3000s and crafting MPE software even in 2012, ponied up the Perl that Pickering needed to run txt2pdf.

You can get perl from Allegro," said veteran 3000 expert Donna Hofmeister at the company. "You'll want to get a copy of our SFTP PDF whitepaper as well, since it discusses how to install perl."

Keven Miller of 3K Ranger, another support provider and consultantcy, put the code for txt2pdf online at his site.

I've placed TXT2PDF.c version 1.1 from Phil Smith onto my site (It's MPE Software item #13) for those that might want to review it.

It's most likely not as advanced as the Sanface product. Probably need to change its name also.

Finally, Robert Mills reported that while he managed 3000s at Pinnacle Entertainment from 2001 to 2008, txt2pdf version 1.1 never gave him many problems in production use.

I had to increase the size of either the pageObs and/or locations arrays, because some of our reports were causing an abort (think that I doubled the size of them).

We didn't have HP's C compiler, so I downloaded GCC and it worked fine. Also, I had some other utilities that were only available in C source, which also compiled and worked when using GCC.

The Gnu C Compiler (GCC) Mills mentioned is the public domain bootstrap software of the 3000's open source software era. It was first forged in the 1990s by Mark Klein, whose DIS International hosts the compiler's software. The latest versions of GCC and related tools may be downloaded from DIS.

An open document format such as PDF was once locked away from HP 3000s until such open source options appeared. We chronicled the other aspects of PDF techniques for HP 3000 use in a story almost two years ago.

The longer that HP 3000s remain online worldwide, the more these updated features will need to be added to the MPE toolbelt. The community is not shy about sharing its experience, and it seems to be well-stocked in what's needed to use open source solutions.

Posted by Ron Seybold at 06:31 PM in Hidden Value, History, Homesteading, User Reports | Permalink | Comments (0)

November 29, 2012

Power of File Equations: HP 3000 Flexibility

Editor's Note: HP's George Stachnik spent more than a decade teaching HP 3000 customers how to use the best of the system, back in the days when HP was selling it, and then when the vendor was pushing migration. On the former mission, Stachnik wrote a 33-part series in InterACT magazine, The HP 3000 for Complete Novices. Our archives have revealed a paper copy of Part 14, which included figures you can't find anywhere else. The figures make the article, one of more than 20 available online at the 3k.com website, even more useful. Here's an excerpt of this advanced MPE/iX tutorial.

By George Stachnik

Let’s turn our attention to more advanced characteristics of MPE files: file equations. 

Suppose you were writing a COBOL program to read data from an input file. Let's assume that when this program is placed into production, its input file is called INFILE. In COBOL, you could code the filename right into the file definition. When you run such a program on an HP 3000, it will look for a file called INFILE and attempt to read data from it.

Of course, Murphy's Law dictates that as soon as you have a program that is "locked into" a particular filename, a need will arise to have it read a file with a different name. For this reason, most commercial operating systems provide a way of assigning a temporary alias to a file. Perhaps the best example is the granddaddy of all commercial operating systems: IBM's MVS operating system.

Most mainframe applications refer to files not by their filenames, but by temporary aliases called DDNAMES. On IBM mainframes, DDNAMES are assigned using DD statements in a job control language called (fittingly enough) JCL. JCL is an old (and cryptic) language, but the concept of DDNAMES is a good one. It allows mainframe application programmers a degree of flexibility. 

The HP 3000 provides a similar capability. MPE allows you to assign temporary aliases called "formal file designators" using :FILE commands.

Figure 1, shown below, shows an example of the simplest form of file command:

   :FILE INFILE=MYFILE

FileEquationFig1001Such a command is often referred to as a "file equation" because of the equal sign ("=") in the middle of the command. In this example, the filename MYFILE has been assigned a formal file designator of INFILE. The formal file designator can be used as a temporary alias for the filename. So MYFILE can now be referenced by two names: MYFILE and INFILE.

Figure 1 shows an example of how a file equation might be used in conjunction with a program that has been coded with the filename INFILE. On the left side of Figure 1, we see the application program as it normally works--reading its input from INFILE. But the right side of the figure shows what happens when we issue the file equation before running the program. In essence, this FILE command tells MPE that any program that tries to read a file called INFILE should be redirected to a different file (in this case, MYFILE).

The scope of a file equation is limited to the session in which the file command is issued. In other words, file equations are in effect only until you log off. For example, suppose you issued the file equation shown on the right side of Figure 1, and then immediately ran a program designed to read data from INFILE. The program would be redirected to MYFILE, just as the figure shows. You could run the program repeatedly during your session, and it would be redirected to MYFILE every time.

But as soon as you log off the system, any file equations that you've issued will die with your session. The next time you log on to your HP 3000, things will be back to normal (as shown on the right side of Figure 1). If you run the program again, it will revert to looking for an input file called INFILE.

Furthermore, the impact of file equations is limited to your session only. It is not global--it doesn't affect other users who may be logged on at the same time. So if you issue a file equation that assigns the formal file designator INFILE to the filename MYFILE, while another user runs the program, the program will behave normally for them, but it will be redirected when you run it.

There's another use for the :FILE command. Yes, file equations can be used to assign a temporary alias called a "formal file designator" to a file. The example shown below is a bit more complicated. The command is:

:file x=myfile;acc=append

This file equation does two things. First of all, it assigns the formal file designator "x" to MYFILE, so that a program that writes to a file named "X" will be automatically redirected to write to MYFILE. But this file equation also contains another parameter. The keyword "ACC=APPEND" (the "ACC" stands for "access") tells MPE that any data that is written to the formal file designator "X" should be appended to the file being written to.

Normally, when you write to a file that already contains some data, MPE/iX would simply write over the data that is already there. But the ACC= APPEND keyword preserves any data that's already in the file and appends the new data to the end of the file.

In order for this file equation to work, we need a program to write to an output file called "X." Of course, we could get out our trusty COBOL compiler and write one, but there's an easier way. Our old friend FCOPY can write to any formal file designator we like. All you need to do is to put an asterisk ("*") right before the output formal file designator. Returning once again to our figure above, we see the following FCOPY command:

:fcopy from=;to=*x

This command leaves off the input filename, just as we saw earlier. FCOPY will therefore read its input from $STDIN (i.e., from the keyboard). The output filename ("x") is preceded by an asterisk, or "star" ("*"). This tells FCOPY, "You are going to write your output to 'x'--but 'x' isn't a filename, it's a formal file designator. Go look at the file equation that I've specified, and it will find what file I want you to write to, and how to write to it."

FileEquationFig5Putting the :FCOPY command above together with the file equation in Figure 2 above (click for detail), we are telling the HP 3000 to read data from our terminal keyboard and append it to the end of MYFILE.

At the top of our figure, we saw that there was one record already in MYFILE when we started. The figure shows four additional records being added to the file. Record number 2 contains the number 2 (followed by 79 blanks). Record 3 contains the number 3, and so on. After we've added record number 5, FCOPY dutifully returns to our terminal keyboard for a sixth record. Watch what happens.

I've typed the character string "This one won't work!" Ordinarily FCOPY would have written a sixth record containing this string to our output file. But as you can see, something has gone horribly wrong. The error message "*134*FOUND EOF IN TOFILE" has been displayed instead, and FCOPY has terminated.

The error message isn't as cryptic as it looks. FCOPY is simply trying to tell us that MYFILE has a capacity of five records and we just tried to append a sixth record to the file. When it tried to write record six, it found the EOF (end of file), and it knows it can't write past the EOF.

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

November 06, 2012

Voting for Security, Obscurity and Propriety

As I write this the polls have closed in the eastern-most time zone for the US elections. Nearly all of the ballots cast in this election have passed through some kind of electronic device, from a touchpad to a click wheel to other, non-uniform interfaces. You might visit a dozen counties in one state alone and see as many proprietary devices. Proprietary carries a negative vibe, this decade as well as this evening. A troubling report in Forbes related how experimental software patches in Ohio might be on live production voting machines today. Those are likely to produce unintended results, as such beta patches often do on HP 3000s.

But the word proprietary has a root of propriety, and that means proper: according to agreed-upon and accepted processing. You'd never sling out beta patches on an HP 3000 because it's just not proper. Your intention is to produce expected, reproducible and fact-checkable results. The fallout from using a proprietary interface, software or patch is simple: someone who's an insider needs to check it. And in a sinister aspect, knows how to crack it.

EugeneblogDecades ago the steady value of the HP 3000 and MPE was its security, one which flowed from privileged mode code. Then during the '90s it was the system's obscurity, once open-source and open system computers took the IT lead. Few people knew the 3000 well enough organize a serious breach. You were much more likely to be hacked from the inside, according to Eugene Volokh's classic Burn Before Reading. The same might turn out to be true this week, if the worriers from Forbes have conjured up a plausible nightmare about election machines. This evening, the biggest news outlets also fretted about the prospects.

Even during this data revolution, the 3000 is remaining settled in its nest of propriety as it's become ever more proprietary. The solution to the balloting mess is to standardize on devices and open the software. Not because the latter is harder to hack, but because an opened-up system is easier to scan for malware. The HP 3000 didn't need security patches after 2008 because the systems practiced propriety to earn their keep, and they were secure through their obscurity. National election voting systems don't have to meet that bar today. It costs too much, apparently.

My security expert colleague Steve Hardwick said that he's been involved in developing a secure voting system which could maintain its propriety. But the project didn't see the light of day in any of the 50 US states.

I did some work on a standard that would have provided very secure voting software. The effort was abandoned due to final cost of the units. Any system, including the physical one in place today, can be circumvented. I have not seen anything showing the comparative security to the physical one. At least the lawyers will have a field day. I wonder if this is the "hanging chad" of this election.

Nobody's hoping for such a thing, especially with so much at stake. But an HP 3000 veteran might be wondering, sometime tomorrow, how such a set of incompatible systems, installed entirely at local whim and desire with software so complex it can't be independently verified for security, could be rolled into production for this country's Big Event. It's the kind of thing that would get an IT pro of age 50 or more fired, if the results became improper.

To establish security of HP 3000s by now is a matter of sticking to an environment that's stable and limiting the access -- just like Eugene wrote in the 1980s. You keep track of who's got access and when to determine where the theft or malfeasance may have occurred.

The very fact that  someone is trying to run payroll across  a  phone  line  at  11 P.M. on a  Saturday is an indication of unauthorized  access. Thus, it is worthwhile to implement some form of security  that  prohibits access to certain user IDs and accounts at certain  times  of  day, days of week,  and/or from certain terminals. Alternatively,  you might want to force people to answer an additional password  at certain times, or especially when signing on from certain terminals.

This  may seem like a poor approach  indeed -- after all, if the thief hits  the time of day, day  of week, or terminal prohibition/password, this  means  that  he  has  successfully  penetrated the  rest of your security system, which will never happen -- right? In reality, this is a   very  potent  way  of  frustrating  would-be  security  violators, especially if the attempted violators are promptly investigated. Thus, another maxim appears:

Some forms of access are inherently suspect (and therefore require Extra  Passwords)  or  are  Inherently security  violations. Thus, access to certain user IDs at certain times of day, on certain days of the week, and/or from certain terminals should be specially restricted.

Eugene Volokh could understand those basics and preach them to his community of computer pros 30 years ago in his paper. By now, he's in government work, in the sense that he's a constitutional law expert and a maven of free speech. We might all hope, before our week is finished, that the philosophy that 3000 users knew in the 1980s about authorized access has traveled from Eugene's first community to his current one: the realm of the US courts.

Nobody ever hopes for a test of security, but it's expected that a system will pass -- or that changes, recalculations and improvements will result from any lack of propriety.

 

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

October 22, 2012

Marking Time with MPE's TZTAB File

By Gilles Schipper
GSA Associates 

Last in a series

Twelve days from today, Daylight Saving Time ends and will give HP 3000 users a reason to look at their clocks. This week may be an appropriate time to think about implementing some best practices associated with clock maintenance for the HP 3000s that you administer. One special nuance for MPE administrators is the TZTAB file. It's code that turns out to be important to third-party and independent software on your system.

TZTAB file and SETVAR TZ 

In other installments in this series, I mentioned the TZTAB file and TZ variable and their relevance to popular third-party software suites. Although not utilized by MPE, by and large, this file and variable are important for some widely-used software. 

And, due to a relatively recent change to the universal TZTAB file required to accommodate the new Daylight Savings rules effective in 2007, it's useful to understand the quite simple format of the TZTAB file, and the corresponding TZ variable that points to its appropriate location in the file.

Let's illustrate by using Aleutian Time (Hawaii) as an example. The TZTAB file (which is located in the LIB.SYS group), contains:

# Aleutian Standard Time, Aleutian Daylight Time (US)

AST10ADT

0 3 24-30 4  1970-1973 0   ADT9

0 3 6     1  1974      0-6 ADT9

0 3 22-28 2  1975      0   ADT9

0 3 24-30 4  1976-1986 0   ADT9

0 3 1-7   4  1987-2006 0   ADT9

0 3 8-14  3  2007-2038 0   ADT9

0 1 25-31 10 1970-1973 0   AST10

0 1 24-30 11 1974      0   AST10

0 1 25-31 10 1975-2006 0   AST10

0 1 1-7   11 2007-2038 0   AST10

So, where does that mention anything to do with Hawaii? It doesn't.

However, the first item in a Google search for "Aleutian Standard Time" does.

How to interpret TZTAB

Let's repeat the portion below that is associated with Aleutian Standard Time. We'll add a reference number at the beginning of each line.

1.  # Aleutian Standard Time, Aleutian Daylight Time (US)

2.  AST10ADT

3.  0 3 24-30 4  1970-1973 0   ADT9

4.  0 3 6     1  1974      0-6 ADT9

5.  0 3 22-28 2  1975      0   ADT9

6.  0 3 24-30 4  1976-1986 0   ADT9

7.  0 3 1-7   4  1987-2006 0   ADT9

8.  0 3 8-14  3  2007-2038 0   ADT9

9.  0 1 25-31 10 1970-1973 0   AST10

10.   0 1 24-30 11 1974      0   AST10

11.   0 1 25-31 10 1975-2006 0   AST10

12.   0 1 1-7   11 2007-2038 0   AST10

Line 1 is simply a comment line (#) in column 1, that identifies the common reference to the time zone

Line 2 is the actual value that the TZ variable needs to be set to for many Unix/Posix/Linux commands that need a time-reference to work properly.

All subsequent lines represent specific fields that have meaning according to their positional ordinal.

The first value (which is 0 in all lines) represents the minute of the hour.

The second value represents the hour of the day  (0 or 3 in all lines)

The 3rd value represents the day or day-range in the month.

The 4th value represents the month.

The 5th value represents the year or year-range.

The 6th value represents the day of the week (Sunday=0).

The 7th value is a string that represents the time zone adjustment in the form tznameDIFF, where "tzname" matches the first or last 3 characters of the TZ variable in line 1, and the DIFF represents the number of hours offset from UTC (Universal Time Clock, aka Greenwich Mean Time(GMT)).

In the above example, since only lines 8 and 12 apply to the current (and all future known) years, I will translate each of the 2 lines:

0 3 8-14  3  2007-2038 0   ADT9

On Sunday (6th field = 0), March (4th field=3) 11 (3rd field = 8-14), the first minute of the adjusted time will take place at 03:00 (fields 2 and 1, respectively), the adjustment resulting in the time being 9 hours from UTC (numeric part of seventh field).

Which means nothing for Hawaii, since Hawaii does NOT adhere to Daylight Savings Time.

One more thing: The above line suggests that the time adjustment BEGIN at 2:00AM, since the first minute of the ADJUSTED TIME should be 03:00 AM - which is exactly what happens when the time is moved forward one hour at 2am.

So, using the example above, we can see that:

0 1 1-7   11 2007-2038 0   AST10

means:

The first minute of the adjusted time will be at 1:00am on whichever day in November (1 thru 7) falls on a Sunday, in the years 2007 thru 2038. The adjusted time will be 10 hours removed from UTC. Again, since Hawaii does not adhere to Daylight Savings Time, no actual adjustment is necessary.

Let's use another example, using Eastern Time. The relevant portion of the TZTAB file is:

1.   # Eastern Standard Time, Eastern Daylight Time

2.   EST5EDT

3.   0 3 24-30 4  1970-1973 0   EDT4

4.   0 3 6     1  1974      0-6 EDT4

5.   0 3 22-28 2  1975      0   EDT4

6.   0 3 24-30 4  1976-1986 0   EDT4

7.   0 3 1-7   4  1987-2006 0   EDT4

8.   0 3 8-14  3  2007-2038 0   EDT4

9.   0 1 25-31 10 1970-1973 0   EST5

10. 0 1 24-30 11 1974      0   EST5

11. 0 1 25-31 10 1975-2006 0   EST5

12. 0 1 1-7   11 2007-2038 0   EST5

Line 1 is simply a comment line (#) in column 1, that identifies the common reference to the time zone

Line 2 is the actual value that the TZ variable needs to be set to for many Unix/Posix/Linux commands that need a time-reference to work properly.

All subsequent lines represent specific fields that have meaning according to their positional ordinal.

The first value (which is 0 in all lines) represents the minute of the hour.

The second value represents the hour of the day  (1 or 3 in all lines)

The 3rd value represents the day or day-range in the month.

The 4th value represents the month.

The 5th value represents the year or year-range.

The 6th value represents the day of the week (Sunday=0).

The 7th value is a string that represents the time zone adjustment in the form tznameDIFF, where "tzname" matches the first or last 3 characters of the TZ variable in line 1, and the DIFF represents the number of hours offset from UTC (Universal Time Clock).

In the above example, since only lines 8 and 12 apply to the current (and all future known) years, I will translate each of the 2 lines:

0 3 8-14  3  2007-2038 0   EDT4

On Sunday (6th field = 0), March (4th field=3) 11 (3rd field = 8-14), the first minute of the adjusted time will take place at 03:00 (fields 2 and 1, respectively), the adjustment resulting in the time being 4 hours from UTC (numeric part of seventh field).

The above line suggests that the time adjustment BEGIN at 2:00AM, since the first minute of the ADJUSTED TIME should be 03:00 AM - which is exactly what happens when the time is moved forward one hour at 2am.

So, using the example above, we can see that:

0 1 1-7   11 2007-2038 0   EST5

means: “The first minute of the adjusted time will be at 1:00am on whichever day in November (1 thru 7) falls on a Sunday, in the years 2007 thru 2038. The adjusted time will be 5 hours removed from UTC.”

Using these examples, you can construct your own TZTAB.LIB.SYS file  that satisfies the requirements of your particular HP 3000 system.

The bottom line to all of this: The TZTAB.LIB.SYS file, in conjunction with the TZ variable, is utilized by the MPE Posix environment, as well as some third-party software suites -- if and when necessary to accommodate GMT and local times.

If you can't find copies of NTPDATE or the TZTAB file, send me a request by email (gilles@gsainc.com) and I will send you a copy of both in a single Reflection-label storefile format file. Thanks to Mark Ranft and Jeff Kell for assistance in acquiring these files.

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

October 19, 2012

Changing Clocks for Good Maintenance

By Gilles Schipper

Second in a series

Two weeks from this weekend, Daylight Saving Time ends for 2012. It may be an appropriate time to think about implementing some best practices associated with “Clock Maintenance” for the HP 3000s that you administer. For example, there's the task of changing the system clocks for other than trivial or TIMEZONE changes.

Your system clocks can be inaccurate either because they are out of sync with each other (ie. wrong TIMEZONE setting) or they simply contain the wrong time, or both. If your problem is an incorrect TIMEZONE (as shown by the SHOWCLOCK command) you can easily and quickly correct with the SETCLOCK TIMEZONE= command.

Keep in mind that if this command would normally result in a backwards time adjustment, the change will take place gradually such that the system clocks will never go back in time.(This default behaviour can be overridden with the ;NOW option of the SETCLOCK command). If the SETCLOCK command results in a time advancement, the advancement takes place immediately.

Again, you can use the SHOWCLOCK command to see the current time, timezone as well as the pending time correction in seconds. If you are experiencing both a timezone problem and clock accuracy issues, that's another matter.

If you are experiencing both a timezone problem AND a clock accuracy issue, you can effect a correction as follows:

:setclock timezone=w5:00

:setclock ;cancel (which cancels any pending gradual changes and permits the subsequent setclock command to succeed.)

:setclock ;date=mm/dd/yy;time=hh:mm;now (the date/time should correspond to your desired “software” clock - ie, the actual location-specific date/time.)

Be careful if the above command sequence will result in the clocks being adjusted backwards that could affect any scheduled jobs or any running application that is date/time sensitive.

If the timezone is correct and you wish only to adjust your software clock, you can simplify by:

:setclock ;correction=no-of-seconds (plus or minus)

Regular Clock Maintenance

Now that you've set your system clocks appropriately, just like any nice-looking grass lawn, they need regular maintenance to stay nice-looking -- or accurate.

From my experience, HP 3000 system clocks are woefully inaccurate if left to their own. They tend to lose time over periods of time - notwithstanding power failures combined with non-functioning main-board batteries and UPS's, in which case the magnitude of clock discrepancy would be much larger.

The System Administrator can solve the clock maintenance problem in two ways:

1. Manually, by checking the system clocks at regular intervals with the SHOWCLOCK command, and, when necessary, issue the appropriate SETCLOCK command to effect adjustments, or

2. Automagically, by utilizing an available utility, called NTPDATE, scheduled to run at regular intervals to adjust your system clocks to the correct time.

Naturally, being a suitably lazy SysAdmin, I prefer option 2.

Since this utility works extremely well when used modestly, I choose to execute it once daily - at most. (Depending upon how inaccurate your system clock is and your tolerance for clock variances, you can choose to run it weekly or monthly)

The NTPDATE utility should be available from whoever is currently maintaining the old Interex contributed library, or an echo of the old HP Jazz site. It comprises a single program, called NTPDATE and can be located in PUB.SYS or whichever group/account you wish having PM capability.

To execute, simply

:ntpdate.pub.sys “pool.ntp.org”

It will synchronize your software clock with the time servers at pool.ntp.org and according to the value of your TIMEZONE setting. You can follow the ntpdate command with a showclock command to see if any adjustments were necessary. You can replace pool.ntp.org with any suitable time server that you prefer and have access to.

Placing this command in a regularly executing job stream will keep your system clocks accurate and worry-free while you work on other things. 

Next time: The nuances of HP's TZTAB file formats

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

October 18, 2012

It's About Time

By Gilles Schipper
GSA Associates

First in a series

NeonClockWith the impending end of Daylight Saving Time (DST) -- just two weeks from this coming Saturday night -- it may be an appropriate time to think about implementing some best practices associated with “Clock Maintenance” for the HP 3000s that you administer.

To refresh your memory, beginning in the year 2007, DST was extended by approximately one month for most time zones in the US and Canada. Consequently, for most locations, DST now begins at 2:00AM the second Sunday every March, and ends at 2:00AM the first Sunday each November.

The rules for specific time zones are contained in a file named TZTAB.LIB.SYS, whose exact format and interpretation will be shown in detail later in this series. Suffice it to say, this file is largely irrelevant for the normal operation of the HP 3000. 

But it is relevant and important for various software products  that are common to the HP 3000 environment, including, among others, products by Nobix, IBM/Cognos, and Speedware -- but surprisingly not by a very useful utility, NTPDATE, which I'll describe in detail.

And for those products that do utilize the TZTAB file, it behooves to set the variable TZ to its appropriate value, for example:

:setvar TZ, EST5EDT (appropriate for the Eastern Timezone, which, during Eastern Standard Time, is 5 hours west of Greenwich Mean Time (GMT)). 

Two Clocks, Two Times

Each HP 3000 contains two separate clocks, commonly referred to as the hardware clock and the software clock.

Typically, the hardware clock is set at system boot time, with the ISL CLKUTIL command. This clock should be set to coincide with the GMT.

The software clock can be set at the ISL START NORECOVERY dialogue. This clock should be set to the actual local time in effect.

If both hardware and software clocks are set properly the system's TIMEZONE setting will reflect the difference between the two.

This can be checked with the command :showcloc

SYSTEM TIME: MON, SEP  3, 2012,  2:25:01 PM
CURRENT TIME CORRECTION:            0 SECONDS
TIME ZONE:    4 HOURS  0 MINUTES WESTERN HEMISPHERE

The SETCLOCK command

There are occasions when it's desirable to modify one or both of the hardware and software clocks - without requiring a system boot. The SETCLOCK command permits us to do exactly that.

As shown above, the SHOWCLOCK command will directly show you the value of the “SOFTWARE” clock (contents of SYSTEM TIME). 

The value of the “HARDWARE” clock is shown indirectly with the combination of SYSTEM TIME and TIME ZONE.

In the above example, the value of the “HARDWARE” clock is MON, SEP 3, 2012, 6:25:01 PM -- which is the value of the SOFTWARE clock plus 4 hours (TIMEZONE of 4 HOURS WESTERN HEMISPHERE). (If the TIMEZONE value showed EASTERN HEMISPHERE, the corresponding TIMEZONE value would be subtracted from the SOFTWARE clock to arrive at the HARDWARE clock.)

The SETCLOCK command has the following parameters:

SETCLOCK

Alters the system time or system time zone.

SYNTAX 

     SETCLOCK  {DATE= date spec; TIME= time spec [;GRADUAL | ;NOW]}
              {CORRECTION= correction spec [;GRADUAL | ;NOW]}
              {TIMEZONE= time zone spec}
               {;CANCEL}

You can see more detail associated with the individual parameters by issuing the command :help setclock, all

For those whose system clocks are generally quite accurate and properly maintained (and I will show you how to ensure that later), the command you will need to invoke twice annually is:

:setclock timezone=W5:00 (First Sunday in November, at 2:00AM, assuming Eastern Timezone)

and

:setclock timezone=W4:00 (Second Sunday in March, at 2:00AM, assuming Eastern Timezone)

These commands can be launched by a job stream that executes, say, once a week-- such as a full backup, for example -- by simply utilizing system date variables to calculate whether the following Sunday is either the first Sunday in November or second Sunday in March, and then stream a job that Sunday at 2:00AM which modifies the TIMEZONE with the appropriate SETCLOCK command.

However, there may be occasions when less granular modifications to your system clocks are necessary. One such occasion could be when your HP 3000 experiences the following conditions/events:

1. It shuts down (ungracefully) due to a power failure, and
2. It is unprotected by a UPS system, and
3. Its internal battery is no longer functioning 

The internal battery is what maintains the hardware clock. A non-functioning battery will cause your system to lose its proper clock value and typically boot up with a value of January 1, 1972 - or some ridiculously erroneous value like that.

Incidentally, this battery is easily replaceable - at least it is on my model 928. The battery it uses is a 3-volt lithium, Panasonic BR2325 - obtainable at most camera supply stores - but, hurry, camera supply stores, like the HP 3000, is a dying breed). If the Panasonic is unavailable, a suitable replacement would be a 3-volt lithium RENATA CR2325.

The battery is located on the main system board - the one containing the CPU, which you can also identify with its included black toggle switch donating “normal” when positioned to the left, and “service” when positioned to the right. To remove that board for battery replacement, you will need to remove the metal plate that covers the disabled RJ45 and AUI ports of the board.

Next time: The task of changing the system clocks for other than trivial or TIMEZONE changes

Gilles Schipper is founder of the system support supplier GSA Associates and Homesteading Editor for the 3000 Newswire.

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

September 28, 2012

3000 Memoir Project: Wins from Easy Use

The 3000 Memoir Project is a living and growing history of your community, told by the server and its software. There are excepts of the book to be published next year, in paper as well as e-book formats. 2013 will mark the genuine 40-year anniversary of the system, while 1974 marks the start of the user group that integrated community pioneers.

We're looking for your stories of the first time you encountered a 3000. Call me at 512-331-0075, or send an email to the NewsWire's offices.

In this installment, the 3000 tells about relative ease of use versus mainframe standard, stories told to, and told by, Paul Edwards -- a former IBM mainframe manager, US veteran, and director of several user groups. By the HP 3000

I was sold on ease of use, and fun. 

PaulEdwards-atSaltLickI like what Paul Edwards and the others said about working with me, versus those entrenched mainframes. See, HP didn’t think of selling me as a big datacenter computer at the start. I was supposed to be a wheel-it-in computer. Some of my early ads showed people “rolling it up to the side of the desk,” Edwards says. My early models, the Series 30s and 40s, even had me built into desks as if I was part of the office furniture, instead of running the office.

That’s because I was a new idea in computers: something that regular office workers could manage, with the help of people like Edwards at HP.

They had a great database they gave me for good in 1976, IMAGE, and one of the fun examples of it used statistics from the NFL. Orly Larson at HP had cooked up the demo of IMAGE, “and every HP sales site had a copy of it. It was just a six-dataset database. But we’d say to the Systems 3 people, ‘let me show you how you can retrieve something, or update databases. They were amazed. It was fun. IBM systems weren’t fun – they were work.”

Edwards says that back in those early days, you couldn’t take fundamentals for granted. Like just writing a file. Me, I did it like a swimmer just jumping in after years of practice, not even thinking about it. “When I came to the 3000, I didn’t have to worry where on a disk I was going to put a file,” he says. “I just wrote out a file. On the IBMs, I had to specify which sector, which disk platter.” He called it one of the most advanced bits of tech that I had when he first started using me.

He says the other magic that made me easy was IMAGE, my strong heart of a database. I even had a built-in QUERY, something that the other computers’ owners had to write themselves. “It was fascinating to me,” Edwards says, “because you could just build an application with QUERY on the fly. You could just send a report out to a printer and show it immediately to the customer. It was the ease of sitting down to the terminals and developing with COBOL and IMAGE. Tools like QUERY, FCOPY for files, they would’ve loved to have had all of those built-in on the mainframes. I thought I’d died and gone to heaven.”

Of course, my console was a 50-pound beast, the 2640 or 45. This wasn’t a weight contest, so I could even have little tape drives in those consoles. I also had card readers to help Edwards and his cohorts absorb the IBM mainframe programs into my MPE. HP gave me my own version of RPG — that code still feels funny on my bones — which was a lot like IBM’s RPG, Edwards says. He’d do my updates, in the earliest days, by using 9-track tapes with a new version of MPE. I even had a paper tape reader for early demos, although the tape wasn’t paper — it was really mylar.

Comparing tape to disk was another place where I could shine in stealing IBM’s customers. Edwards worked in Frito-Lay’s manufacturing operations before he joined my family.  “I went from a tape-based operating system to a disk-based one,” he says. “It was light years ahead of the mainframe.”

I had a lot of ardent fans coming on in those days. People would punch out programs on cards from the System 3s, then go to work using the Data Entry Library. It was my first part of my body that had a human name: the DEL/3000. “We’d build the screens quickly, so the customers could come in and review them,” Edwards says. They’d give HP guys T-shirts from my birthplace in California that said, “Series I Has Begun.” Call them out to what they called the factory, back when they actually built me next to the labs, so they could learn something new and sometimes have beer blasts afterward in the parking lots. They they’d go back and cross-train the others at their HP offices. SEs and CEs collaborated.

Eventually Edwards left my Dallas office to go out on his own. A lot of the sharp SEs would do that in the early ‘80s, when he was just getting a fresh start as an indie consultant. He worked with Speedware on projects, taught things like Robelle’s Suprtool. From a time when my 7910 disks, with one fixed and one removable platter, held just 10 Mb, I’ve grown my reach into places like 500Gb disks, and maybe soon, up in that vague and uncharted storehouse for data called the cloud. Edwards tells me that he’s still got a Series 928 of his own at home that he fires up for consults. “Once or twice a year I’ll vacuum out the fuzzies, but other than that, it just runs,” he says. I like that reputation. I’ve held on more than three times as long as Windows XP, another computer body that Edwards says has fierce loyalists. I might get inspired by Paul to go to newer heights. He wants to take his FAA exam to extend his piloting experience, so he might get to fly classics in the Commemorative Air Force like the T-28 trainer — a prop aircraft that’s 20 years older than me. “They’re now looking for younger guys,” Paul says about the CAF, “but not necessarily that much younger.”

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

September 06, 2012

Core memories spark a cold start for 3000s

Editor’s Note: Jon Diercks, the author of the only comprehensive MPE/iX administration book, offered us this story of the 3000’s very first year. It was a time of HP retreat from the minicomputer market: HP staff resigning, others unselling a system touted just months earlier as “a happening,” as the slogans of 1972-73 said in HP labs and offices.

Diercks worked at Anderson University in the 1990s alongside Tom Harbron, who’d been the college’s computer department director during 3000’s first months on the market. Diercks said Harbron was heavily involved in early discussions with HP about MPE and IMAGE. 

The institution began as Anderson College, and its very first HP 3000 was one of the earliest models. Diercks said the bragging line in those days was "Anderson College has the first HP 3000 ever installed anywhere between the Rockies and the Appalachians."

Harbron’s report on the 3000’s 1973 is part of Diercks’ 3000 memories, and so he’s contributed the writing as part of our 3000 Memoir Project — in all of its authentic, human and humbling beginnings. It's the first story I've read that details the 3000's retreat. An HP employee who couldn't look his customers in the eye about the 3000, and so resigned. A man whose job was to unsell the 3000s -- and later would bundle the greatest software HP ever wrote, IMAGE, to the Classic hardware, which not long after, fell behind the state of the art.

By Tom Harbron

Reports of problems with the HP 3000 operating system, MPE, continued to be received in the opening weeks of 1973. While it was not encouraging, I had confidence in the basic soundness of the 3000’s design and the integrity of Hewlett-Packard to ultimately deliver what had been promised.

HP’s Phil Oliver called and scheduled a meeting with me for February 6, 1973.  He brought along Bob Stringer, who had replaced Ed Pulsifer as the District Sales Manager; Ed McCracken, who was now HP's Market Manager for Government, Education, and Medical Markets; and Jay Craig, who was a new HP salesman from Indianapolis. McCracken would tell me, years later when he was the 3000 division manager, that the morning in my office was the most difficult day of his career. The people that HP hired were, mostly, an honorable group of people.

On that day in 1973, they had some bad news to deliver. Specifically there were seven points:

1. HP cannot bring the software components of the system up to full specifications before Fall 1973.

2. They are devoting “maximum resources” to correcting the problem.

3. The system will currently support no more than 4-6 simultaneous users.

4. HP will loan an additional 64K bytes of core storage to bring the system up to this 4-6 user level of performance.  (We had ordered the system with 64K bytes of core storage.)

5. IMAGE will be further delayed to January 1974.

6. Because of hardware difficulties, a slower console printer would be provided.

7. They would like us to cancel the contract.  Lacking that, they wish to amend the contract.

It was a tense meeting. McCracken was going about the country, visiting customers, and unselling the 3000. It was hard for everyone. Phil Oliver would return to his office later that day and resign. He told me he couldn’t look his customers in the eye. Ed Pulsifer had already resigned for similar reasons. 

I resisted their pleas to cancel the contract for four fundamental reasons. 

First, I had faith in the basic design of the system. I had run benchmarks that had come in almost exactly where I had predicted from the timings in the ERS. MPE was clearly a better design than nearly anything else then available. The combination was more cost effective than anything else by a factor of two or three. Moreover, I had met many of the people involved with the project and had confidence that they could do the job, given the time and resources.

Second, there really were no viable alternatives on the market at the time. DEC tried long and hard to sell us, but in the end their salesman conceded that the systems DEC had were either too feeble or far too large for our needs; the HP 3000 was a perfect fit. IBM tried hard to sell us on various timesharing patches to their systems, none of which worked well. The only systems available that would do the work were the XDS Sigmas and they cost five times as much as the 3000.

Third, I thought that HP had to make the 3000 succeed if they were to remain a growth company.  At that time, HP had about half of the instrument market and could not significantly expand their market share without anti-trust problems.  Their other market areas, such as microwave, were respectable, but in small markets that were not growing very fast.  

The only way that HP could continue to grow at historic rates was by entering the computer business in a major way. With $25 million already invested in the 3000, they were unlikely to write off that investment and content themselves with their existing markets.  If the 3000 failed, they would have had to immediately start over on another computer project.

Fourth, we had already invested several man-years in application development for the HP 3000 at the time that HP was trying to unsell the system.  It would have been a financial disaster for us to write off all of that work and begin again with a different system.  We really had no option beyond the 3000.

Years later, in a speech before the Users’ Group, McCracken said “I want to thank those of you who had faith that the HP 3000 would succeed at a time when many at HP had profound doubts.”  I’m sure he was thinking of that cold February day he spent in my office.

Posted by Ron Seybold at 05:55 PM in Hidden Value, History, Homesteading, User Reports | Permalink | Comments (0)

August 30, 2012

In the Beginning, There Was Tape

By Brian Edminster
Applied Technologies

First in a series 

In the beginning, there was tape. And if you’ve been around awhile, you remember it was on big reels about a foot across, was about a half-inch wide, and could have as much as 2400 feet of it on a reel. Yeah, they were heavy, too.

Data was recorded in parallel ‘tracks’ along the length of the tape. In this case nine of them, hence the name ‘9-track’ tape. At 800 bpi, that yielded a capacity of nearly 20Mb. Later technology allowed higher density, when 1600 bpi upped that capacity to about 120Mb. The last incarnation of 9-track was a whopping 6250 bpi — yielding nearly 1Gb of storage for a single reel of tape.

By comparison, anyone can get USB flash-drives that’ll hold 16Gb for $10 down at Walmart. 

Very few, if any later model 3000’s (those that run MPE/iX vs. MPE/V) will even have a 9-track tape drive on them. And that’s a good thing. These 9-track tapes take up far too much physical storage space, and are far too slow to read and write. They might have been okay, back when disk drives were 50Mb, 120Mb, 404Mb, or even 570Mb (the capacities of the old HP 7920, 7925, 793x, and 7937 disk drives, respectively).

Unfortunately, a 2Gb drive is pretty much the smallest drive you’ll see on a 3000 these days, and larger drives are more common. This presents a problem: What do you do when it takes potentially dozens of tapes — and many hours — to do your daily backups?

Again, advancing technology comes to the rescue. Instead of further density increases on 9-track tapes, a variant of the digital cartridge tape called DDS (Digital Data Storage) came into common use for backups. For any new managers who haven’t seen one, a DDS cartridge is just a little smaller than a standard pack of cigarettes.

DDS drives and media also progressed in technology over time, growing in both speed and capacity (and generally, in reliability as well) as the table below shows.

TapeTableSmAs it turns out, transfer speed (how fast the drive can read/write data) also scaled upwards as capacity grew — so that even if you didn’t need the capacity, there’s often a speed advantage to the larger capacity drives. For any system that needs a new or replacement DDS drive, I’d never recommend anything less than a DDS3, unless there was an absolute requirement to write DDS1 tapes. 

Also note that once you get to DDS3 and beyond, you’ll likely need a dedicated SCSI channel for the drive, in order to take advantage of the drive’s speed. If you cannot keep the tape drive’s buffers fed, it has to stop and re-position, which slows it down significantly. Note that this can occur while reading tapes as well. 

If you have sufficient CPU capacity available, software compression can also speed up reading/writing of backups by reducing the amount of data sent to and from the drive. I’ve also heard from people I trust that you are unlikely to experience the difference in backup time which is implied by read/write speed difference between DDS4 and DDS5 — at least not when attached to a 3000.

As I mentioned in an article covering VSTORE on the NewsWire’s blog, DDS drives slowly lose alignment as they wear. They have a remarkable tolerance for this, all things considered (especially DDS3 and subsequent drives). It’s still something to be on guard for, especially if you’re relying on your backups to be readable when the chips are down. 

Regarding media reliability: various sources give differing answers, but as a general guideline DDS tapes will take about 100 passes or so before they wear out. If you use the same tape once a week, expect to get about two years life out of it, before it wears out. You could get more uses, but the longer you go, the farther you’ll get into borrowed time territory. Don’t expect a catastrophic failure, but you’ll have to clean the drive more often. And face possible write failures and/or VSTORE failures. 

Failure is not something you want to tempt by scrimping with your backup tapes. Buy the best quality you can, and replace them yearly. Like doing backups in the first place, it’s cheap insurance. Would a rock climber wait until his ropes break before replacing them? I know I wouldn’t.

Next time: New media for a new millennium

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

August 28, 2012

Porting to Posix on the HP 3000

One of the leading lights in HP 3000 development has been researching how to port software to Posix under MPE/iX. David Dummer, who created DataExpress and played a major role in making Transact a genuine language, was looking for help to resolve an error while compiling.

Why would a 3000 homesteader want to port software to Posix? One reason is to ready an application for the journey to one of the *nixes, like HP-UX or Linux. Here's Dummer's dilemma.

I have been trying for some days to port a Unix application to an HP 3000. One of the source files contains calls to the Posix functions of 'tcgetattr' and 'tcsetattr' for terminal handling control. I compile this source under the Posix shell, as the MPE C compiler doesn't appear to be able to find the included 'termios.h' header file. The application program is then created by the MPE linkage editor.

At execution time the loader denotes the two Posix functions as unresolved externals. From my reading of articles on Porting to Posix I would have expected these two functions to be in the relocateable library file '/lib/libc.a' 

I then decided to write a makefile and to perform all of the compile and build functions under the Posix shell. This appears to cure the missing function problem, but the resulting application aborts before reaching the first statement in the mainline program.

Mark Bixby, who wrote that seminal resource on porting to MPE applications to open source, weighed in with some advice for developers.

Bixby was cautioning homesteaders as far back as 2002 that they'd need to get comfortable with porting, because crucial 3000 software was certain to be in need of upgrades over the life of a homestead installation. Bixby's now working at K-12 app provider QSS, which is still supporting HP 3000 apps.

My extensive MPE Posix porting knowledge has largely been recycled in the eight or so years since I last did substantive MPE work. But if I recall correctly, the libbsd distribution -- or perhaps was it the Posix porting wrappers -- which used to be available from jazz.external.hp.com contained tcgetattr and tcsetattr implementations.

Lars Appel, another prodigious porter who moved Samba across to MPE/iX, pointed at repositories of these wrappers which are still online, hosted in the independent community now that HP's closed down that HP 3000 Jazz server.
As far as I recall, Steve H's porting wrappers also included those two. The Client Systems main Jazz page leads to http://clientsystems.com/portwrappers650.html

And you can typically only compile and use those few routines that you need -- you don't have to build and link the whole wrappers package.

More advice came about the Posix shell commands cc or cc89, a script with lots of extras added. Reports said it was pretty tricky to replicate that at the MPE command prompt. So the first rule of success would be to compile Posix programs only under the Posix shell.

MPE: run .\testposx;unsat=debug will get a developer to debug, for anything that was called but not available. Otherwise, use MPE: run .\testposx;debug

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

August 22, 2012

Securely Storing Passwords

Editor's Note: Security is one of the limiting factors in adopting cloud computing. HP, as well as its partners, will tell you that cloud computing and similar remote access is a forward-thinking alternative to HP 3000 centralized on-site computing. But there's that security thing.

More than 30 years ago VEsoft's Eugene Volokh chronicled the fundamentals of security for 3000 owners trying to protect passwords and user IDs. Much of that access hasn't changed at all, and the 3000's security by obscurity has helped it evade things like Denial of Service attacks, routinely reported and then plugged for today's Unix-based systems. Consider these 3000 fundamentals from Eugene's Burn Before Reading, hosted on the Adager website.

Logon security is probably the most important component of your security fence. This is because many of the subsequent security devices (e.g. file security) use information that is established at logon time, such as user ID and account name. Thus, we must not only forbid unauthorized users from logging on, but must also ensure that even an authorized user can only log on to his user ID.

If one and only one user is allowed to use a particular use ID, he may be asked to enter some personal information (his mother's maiden name?) when he is initially added to the system, and then be asked that question (or one of a number of such personal questions) every time he logs on. This general method of determining a user's authorizations by what he knows we will call "knowledge security."

Unfortunately, the knowledge security approach, although one of the best available, has one major flaw -- unlike fingerprints, information is easily transferred, be it revealed voluntarily or involuntarily; thus, someone who is not authorized to use a particular user id may nonetheless find out the user's password. You may say: "Well, we change the passwords every month, so that's not a problem." The very fact that you have to change the passwords every month means that they tend to get out through the grapevine! A good security system does not need to be redone every month, especially since that would mean that -- at least toward the end of the month -- the system is already rather shaky and subject to penetration.

There's a broader range of techniques to store passwords securely, especially important for the 3000 owner who's moving to more popular, less secured IT like cloud computing. We've asked a security pro who manages the pre-payment systems at Oxygen Financial to share these practices for that woolier world out there beyond MPE and the 3000.

By Steve Hardwick, CISSP

There has been a lot in the news recently about password theft and hacking into email accounts. Everything needs a password to access it. One of the side effects of the cloud is the need to be able to separate information from the various users that access a centrally located service. In the case where I have data on my PC, I can create one single password that controls access to all of the apps that reside on the drive plus all of the associated data.

There is a one-to-one physical relationship between the owner and the physical machine that hosts the information. This allows a simpler mechanism to validate the user. In the cloud world it is not as easy. There is no longer a physical relationship with the user. In fact a user may be accessing several different physical locations when running applications or accessing information. This has led to a dramatic increase in the number of passwords and authentication methods that are in use.

I just did a count of my usernames and passwords and I have 37 different accounts (most with unique usernames and password). Plus there are several sites where I use the same usernames and password combinations. You may ask why are some unique and why are some shared. The answer is based on the risk of a username or password be compromised. If I consider an account to have a high value, high degree of loss/impact if hacked, then it gets a unique username or password.

Email accounts are a good example. I have a unique username and password for my five email accounts. However, I do have one email account that is reserved solely for providing a username for other types of access. When I go to a site that requires an email address to set up an account , that is the one I use. Plus, I am not always selecting a unique password. The assumption is that if that username and password is stolen, then the other places it can be used are only other web site access accounts of low value. I also have a second email account that I use to set up more sensitive assess, google drive for example. This allows me to limit the damage if one of the accounts is compromised, and so I don't end up with a daisy chain of hacked accounts.

So the next question is how do you go about generating a bunch of passwords? One easy way is to go into your favorite search engine and type in password generator. You will get a fairly good list of applications that you can use to generate medium to strong passwords. But what if you don't want to download an application -- what is another way?

When I used to teach security this was one trick I would share with my students. Write a list of four or five short words that are easy to remember. Since my first name is Steve we can use that. This of four or five short number 4-5 digits in length 1999 for example. Now pick a word and number combination and intersperse the numbers and letters S1t9e9v9e would be the result of Steve and 1999. Longer words and longer numbers make strong passwords – phone numbers and last names works well. With 5 words and 5 numbers you get 25 passwords. One nice benefit of this approach comes when you need to change your password. Write the number backwards and merge the word and data back together.

Next: How to remember all of those passwords. 

Steve Hardwick (CISSP) is the Product Manager at Oxygen Financial, which offers advanced payment management solutions. He has over 20 years of worldwide technology experience. He was also a CISSP instructor with Global Knowledge for three years and held security positions at several companies.

Posted by Ron Seybold at 02:49 PM in Hidden Value, Migration, Newsmakers | Permalink | Comments (0)

August 07, 2012

Follow that VSTORE onto other drives

Editor's note: After reading our article on SLT creation and validation yesterday, consultant Brian Edminster adds some notes on how to employ VSTORE in your 3000 management. He's also working on an article that covers backup automation.

By Brian Edminster
Applied Technologies 

If possible, do your VSTOREs on a different (but compatible model) of tape drive than the one the tape was created on. Why? DDS tape drives (especially DDS-2 and DDS-3 models) slowly go out of alignment as they wear.

In other words, it's possible to write a backup tape, and have it successfully VSTORE on the same drive. But if you have to take that same tape to a different server with a new and in-alignment drive, you could have it not be readable! Trust me on this -- I've had it happen.)

If you'll only ever need to read tapes on the same drive as you wrote them, you're still not safe. What happens if you write a tape on a worn drive, have the drive fail at some later date -- and that replacement drive cannot read old backup tapes? Yikes!

Using the 'two-drive' method to validate backup (and even SLT) tapes is a very prudent choice, if you have access to that array of hardware. It can also often help identify a drive that's going out of alignment -- before it's too late! 

There's another possible media choice, using store-to-disk. which I'll be writing about shortly.  

Unfortunately, SLTs have to be written to tape (at least, for non-emulated HP 3000s). However, your drive will last years longer if you only write to it a few times a year.

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

August 06, 2012

What You Need to Do and Check for SLTs

At a recent visit to a customer's shop, VEsoft's Vladimir Volokh spread the word about System Load Tapes. The SLTs are a crucial component to making serious backups of HP 3000s. Vladimir saw a commonplace habit at the shop: Skipping the reading of the advice they'd received.

"I don't know exactly what to do about my SLT," the manager told him. "HP built my first one using a CD. Do I need that CD?"

His answer was no, because HP was only using the most stable media to build that 3000's first SLT. But Vladimir had a question in reply. Do you read the NewsWire? "Yes, I get it in my email, and my mailbox," she said. But like other tech resources, ours hadn't been consulted to advise on such procedures, even though we'd run an article about 10 days ago covering CSLTs. That tape's rules are the same as for SLTs. Create one each time something changes in your configuration for your 3000.

Other managers figure they'd better be creating an SLT with every backup. Not needed, but there's one step that gets skipped in the process.

I always say, "Do and Check," Vladimir reports. The checking of your SLT for an error-free tape can be done with the 3000's included utilities. The venerable TELESUP account, which HP deployed to help its support engineers, has CHECKSLT to run and do the checking.

There's also the VSTORE command of MPE/iX to employ in 3000 checking. If your MPE references come from Google searches instead of reading your NewsWires, you might find it a bit harder to locate HP's documentation for VSTORE. You won't find what you'd expect in a 7.5 manual. HP introduced VSTORE in MPE/iX 5.0, so that edition of the manual is where its details reside for your illumination.

It's also standard practice to include VSTORE in every backup job's command process.

There's another kind of manager wouldn't be doing SLTs. That's the one who knows how, but doesn't do the maintenance. You can't make this kind of administrator do their job, not any more than you can make a subscriber read an article. There's lots to be gained by learning skills that keep that 3000 stable and available, even in the event of a disk crash. Management might not respect the 3000's ability to take on new developments. But a company always respects the 3000's reliability.

CHECKSLT, and care and feeding of SLTs, are well-covered in a NewsWire column written by John Burke almost 13 years ago. His advice still holds today.

HP’s documentation tells us we need to have a current SLT. And that it can be created using the TAPE command within SYSGEN. If you look hard enough you will also find the warning that the CSLT you may have created when doing an update or manage patch is not adequate. That is about it for SLT recommendations.

Is this recommendation correct? Well, in the sense that it is necessary to have an SLT created by the TAPE command, then, yes, it is correct. You can re-install your system in the event you lose a drive in the system volume set using this SLT and appropriate other backups. But is this recommendation complete? I think not.

As has been proven countless times, the people who write manuals (and not just at HP) are not out in the real world. They are not running shops where if you get a six-hour maintenance window once a month you consider yourself lucky. They are not running shops where you have to have procedures that can be understood and followed by someone with only basic training in system operation. They are not running shops where cell phones go off like July 4th fireworks as soon as anything unusual happens.

You can find HP's VSTORE page in that 5.0 command manual online, just like the NewsWire's advice. Vladimir, you find him in your office, if he's traveling your way. But managers also find that he recommends our advice -- perhaps because we first get the instructions to do it, and then have our reports checked. Do and Check are words to live by, not just for managing 3000s.

Posted by Ron Seybold at 04:40 PM in Hidden Value, Homesteading, User Reports, Web Resources | Permalink | Comments (0)

July 27, 2012

MM/3000 stalwart serves, stocks 3000 docs

We're still thinking about how to organize and capture the wealth of lively links at hp3000links.com. This site has been without an administrator for most of a year, and it's still got more than 100 links on it that lead to useful information.

But the links to HP's documentation on the 3000's software and hardware go nowhere. Most of them were hosted on HP servers that have either been retired -- like the 3000 division's Jazz webserver -- or they point at a baffling HP webpage where somewhere or other there's a way to find documentation.

However, there's another web resource that seems to pop up quickly when we do a search for HP manuals like the MPE/iX 7.5 Maintenance Manual. It seems that one of the stalwarts of the HP Manufacturing Management application, Scott Petersen, has been stockpiling 3000 manuals at his hpmmsupport.com site. MM/3000, as it was called through the '90s, sold a lot of new 3000s -- because in choosing a platform it's all about the application, isn't it?

It is, until you make that choice, and then you're facing system administration like keeping an SLT up to date for your 3000. How to create a CSLT is part of that 7.5 manual. Petersen's site has it and much more.

HP's official position on this kind of document archival has been in flux. For awhile in the 2008-2010 era, the manuals were supposed to be in HP's websites only, or hosted as part of a licensing agreement with a third party. At one point HP was saying the manuals wouldn't go public until 2015. But HP's got bigger woes to resolve than whether's there's too much exposure for its 3000 manuals. HP won't even sell you support for your system by now. Unless you insist.

Petersen said that access to these documents is vital to supporting the 3000.

I have needed the 3000 information in the past and felt that it was a good community service to place the manuals and other things oout there for all to see. I am a pack-rat and decided that having access to the information was critical.

Petersen adds that he's "always on the lookout for things that might go away relating to the 3000, and adding them to the site if it is appropriate." MM/3000 didn't go away after HP dropped it. The software was bought and revived and expanded by former HP employees who became eXegeSys, with products named to match. Manufacturers were surprised, too. But the apps have supported a diverse group of users from governments, sports clubs, job shop manufacturers, process manufacturers and pharmaceutical companies.

Many of these have migrated to other applications. Our goal is to continue the process of high quality support for those organizations that have either not been willing or able to move to another platform and application. We knew the application when it was designed, and we are aware of how customizations have allowed the application to change.

This was an application vendor as surprised as any about HP's exit from the 3000, if memory serves from my meeting with them in 2002. But they've perserved, well beyond HP's capabilities. Things don't go away easily in a community stocked with these kinds of stalwarts.

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

July 25, 2012

Matches of Mountain Lion and MPE/iX

By Brian Edminster
Applied Technologies

Mountain-lionI follow far too many blogs, in my vain attempt to stay informed on the state of technology (software, hardware, and other). When Apple released its state of the art OS today, I kept on researching. As a byproduct of those attempts, I happened on an article from Information Architects, Mountain Lion’s New File System, and found it quite interesting.

In short, it appears that Apple -- in working to move away from a many-leveled folder hierarchy to 'force' a two-level hierarchy in its file-systems (iOS, and now in OSX) -- is now basically moving towards where MPE was from the beginning.

In MPE's case, it's Account and Group, rather than Application, and folder within Application. But the resemblance is striking.

MPE applications can 'see' -- and when necessary -- access, across accounts. I'm not entirely sure how that'll be achieved in OSX or iOS, although I'm fairly sure that those better-versed in Apple products could point it out to me.

I also noted that, perhaps for different reasons of which I'm not sure -- I'm going purely on conjecture here --Microsoft is doing the same basic thing in its folder structures. The folder structures in Windows 7 are becoming more libraries of 'kinds of things'-based, plus it tries to 'hide' you from the 'pathing' to get to a file. So far, I find their implementation far less satisfying that Apple's has been.

I can't honestly say that (for the filesystem structure, at least) that MPE was so far ahead of its time that other OS's are just now catching up. But I am curious about what drove the two-level structure. Perhaps someone who worked in the labs might have that insight to share. 

Regardless of the reason, good designs often converge in a particular direction or way. And I suspect that this may be an example of that as much that as anything else.

I know that the late Wirt Atmar of AICS Research firmly believed in simple paradigms for storage concepts (often explained as file-cabinet drawers and folders) -- and that MPE's filesystem fit that quite well. He firmly believed that was one of MPE's great strengths.

Posted by Ron Seybold at 05:20 PM in Hidden Value, Newsmakers | Permalink | Comments (2)

July 24, 2012

Make backups, but a CSLT is just as vital

Many homesteading HP 3000 shops are working with limited system administration. If you're reading this blog, that probably doesn't apply to your own 3000 shop. But you can pass on advice about backing up to any 3000 site you know. A backup of applications and databases isn't enough.

The CSLT needs to be fresh and available, too. The Custom System Load Tape tells the 3000 how the configuration is set up for devices attached to the system that you're restoring. (The original SLT that was distributed from HP has a generic configuration. This customized SLT reflects your physical configuration of your specifically-built system.) Also referred to as a boot tape, it contains the system load utilities, diagnostic subsystems, base system files, and other HP system files such as IMAGE, FCOPY and EDITOR.

A CSLT is generated with the system generator (SYSGEN) utility. You can build a CSLT for individual systems, each with a different configuration, after updates. These configurations tell the 3000 what other volumes are available to accept data. You can also put a full backup on the end of a CSLT, but it's better to have that backup on separate tapes. (Separating a backup from the CSLT also speeds up creating a CSLT.) Consultant Paul Edwards advises that managers make a CSLT at least every other time during a backup, plus having two tape drives on each system. "Being paranoid makes for a good system manager," he says. "If you're not paranoid enough, you better have a good resume."

Overlooking the CSLT is so common that even some admin pros have done it from time to time. For one such pro, an A-Class 3000 was recently rebuilt and had its apps consolidated. But the rebuilt system didn't have its CSLT freshened, which was discovered when the boot volume failed. 

We lost LDEV1 in the 'system' volume-set. The apps and databases are fine, but I'd neglected to make a fresh CSLT once the rebuild/configure/setup was complete. Fortunately, all the data volumes are protected with Mirror/iX -- but rebuilding the system volume accounts, network config, administration jobs and so on has been a pain.

An honest mistake like this is not one you need to make yourself. Even if, as another 3000 consultant notes, your shop has gone into Frugal Mode while it makes in-house moves. You have the right to be wrong in Frugal Mode. But you really don't want that right, unless you've got plenty of extra time.

"This is not a mistake I'll ever make again," said our CSLT rebuilder. "Until it's complete and stable, I now make a new CSLT at the end of each day's changes (in addition to the regular backups we do as Store-To-Disk, and then FTP to a NAS). Hopefully I'll never have to go through this hassle again."

AUTOINST updates temporary copies of the system libraries and then creates a CSLT. This can take up to two hours. One set of instructions to do this is available in HP's MPE/iX 7.5 Maintenance Manual. The process hasn't changed much from the 6.0 release of MPE/iX, either. We've got a pointer to each manual; just search for "CSLT" in each PDF file.

We've previously published a paper by Gilles Schipper on the use of BULDACCT versus the STORE command while backing up. The ;DIRECTORY and ;ONVS= options are a key there. What's more, one of our most prodigious contributors Brian Edminster is sketching out a technical, but easy-to-use, Automation of Backups and Effectively Eliminating Use of Tapes article.

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

Posted by Ron Seybold at 04:13 PM in Hidden Value, Homesteading, Migration, User Reports | Permalink | Comments (0)

July 13, 2012

Use MPE Input Files to Create Output Files

Intrinsics are a wonderful thing to power HP 3000 development and enhancement. There was a time when file information was hard to procure on a 3000. It was a long time ago, as I was reminded by Olav Kappert in his call about his HP 3000 history. "The high point in MPE software was the JOBINFO intrinsic," he said. Kappert started with the 3000 in 1979.

Fast-forward 33 years later and you'll find questions from a different programmer still working on a 3000, adding features to a system. The Obtaining File Information section of a KSAM manual on MPE/iX holds an answer to what seems like an advanced problem. That manual sits in a tucked-away corner of HP's website today, the HP Business Support Center page for 3000 documentation and manuals.

I'm still using our old HP 3000, and I have access to the HP COBOL compiler. We haven't migrated and aren't intending to. My problem is how to use the characteristics of an input file as HPFOPEN parameters to create an output file. I want that output file to be essentially an exact replica of the input file (give or take some of the data). I want to do this without knowing anything about the input file until it is opened by the COBOL program. 

I'm using FFILEINFO and FLABELINFO to capture the characteristics of the input file, after I have opened it. After I get the opens/reads/writes working, I want to be able to alter the capacity of the output file.

Francois Desrochers replies

How about calling FFILEINFO on the input file to retrieve all the attributes you may need? Then apply them to the output file HPFOPEN call.

Donna Hofmeister adds 

You might want to get a copy of the "Using KSAM XL and KSAM 64" manual. Chapters 3 and 4 seem to cover the areas you have questions about. Listfile,5 seems to be a rightly nifty thing.

But rather than beat yourself silly trying to get devise a pure COBOL solution, you might be well advised to augment what you're doing with some CI scripts that you call from your program.

In a lively tech discussion on the 3000-L list, Olav Kappert added, 

Since you want to do this without knowing anything about the input file until it is opened by the COBOL program, the only way is to use one of the MPE intrinsics to determine all the characteristics of the file in question. Then do a command build after parsing that information.

Michael Anderson added details on how the 3000's CI scripting can build upon the fundamentals of file information and COBOL.

I like Donna's plan.This is a strategy that will also help whenever you want similar functionality on a NON-MPE platform. Also, although COBOL is very capable, an external script might be a better tool. You don't always need a hammer.

This is hypothetical, to try to make a point. From your MPE CI prompt, type HELP FINFO. You should be able to set some variables (SETVAR FILEA "XXX"), and using FINFO add some more variables. Then from COBOL using HPCIGETVAR, string together a BUILD command (with a bigger LIMIT maybe), and call "HPCICOMMAND". You could string the build command from a command, into a single variable, then COBOL only needs to HPCIGETVAR once.

You can also write a script to do everything you want, and call HPCICOMMAND to run the script, pass it parms. It's pretty cool, and it makes your COBOL application more portable. (Same program, different script).

For example: On MPE I once wrote (using COBOL) a small utility to CALL DBINFO, extract all the meta-data from any IMAGE database, and then create, and write to the NEW KSAM COPYLIB, ending up with all the COBOL copylib modules needed for all datasets for any database, including call statements and working storage. My point to all this: I used CI scripting to create and write to the copylib. I actually used ECHO to write the copylib ksam file from a CI script. Now, seeing how I work more on HP-UX and Linux, plus OpenCOBOL and Eloquence, I should be able to compile this same program on Linux with minimal modifications, only changing the external script.

I use this method to access SQL databases, and much more, using OpenCOBOL and the Tcl/Tk developer exchange. This way I can run the same program, same script almost anywhere, no matter, Windows, Mac, or Unix.

Eric Sand, another veteran of the 3000, commented that this kind of challenge really shows off the range of possibility for solving development problems. "You can create almost any cause and effect in MPE that you can imagine," he said. "Reading about your concern gave me a little rush, as I mentally organized what I wanted to do to address your concern."

Posted by Ron Seybold at 05:50 PM in Hidden Value, Web Resources | Permalink | Comments (0)

July 11, 2012

Web console resets, environment rebuilds, dumping form printers lead Hidden Value

I switched from an A400 to an A500 some time back, and I only realized I had not set up the remote web console after the console was down. Where can I configure this? This last time my only access was via VPN, or verbally over the phone. ("What can you see? Okay, so type...") I want to be able fix this myself next time. The console is the built-in one, and not an external box.

Gilles Schipper replies

You can configure your web console from the main console via the GSP interface. Specifically, the command you're looking for is LC (LAN configuration).

This command can be invoked even while the system is up and running by typing ctl-B (control and B together). For more help, at the GSP interface, type HELP, then HELP LC. 

Craig Lalley adds that if you arrive at a password roadblock and need to clear a console back to the default login, "at the physical console, hit the GSP reset in the back of the system, then press P on the keyboard. It will reset the passwords."

I need to rebuild an environment from one HP 3000 system to another. Trouble is, we want to have groups from the same account end up on different user volumes. Is there a way to do this using BULDACCT? 

Keven Miller adds

BULDACCT was made for processing complete accounts. Do BULDACCT  CHC%VSACCT=MEDADV_1. Then edit BULDJOB1 for the other group, changing MEDADV_1 to _2

After Donna Hofmeister notes that "newacct has to be done on both volumes," Mark Ranft replies 

What I usually do is use BULDACCT to move the entire accounting structure. Then I surgically PURGEGROUP and NEWGROUP (with the appropriate HOMEVS= and ONVS= options, plus CAP= and ACCESS= etc) to duplicate the special groups.

Jim Hawkins notes

MPE/iX RESTORE supports changing volume set specifications on RESTORE (vol, volclass volset) . That is, you can take files/groups/accounts originally on one volume set and place them onto another volume set.

We are still using multipart pre-printed forms and RS-232 dot matrix printers, all direct connected to our HP 3000 for our MANMAN purchase orders, invoices and checks. Obviously, these old HP printers are getting tired and problematic. Our immediate target is the printing of purchase orders. Are there ways to migrate from these form-based printers without breaking the bank?

Lisa Christiansen replies

One option that would work without requiring programming expertise is using ByRequest software from Hillary. We are taking the print ques from MANMAN and overlaying the form/jpeg to print the forms. We also have it set up so that the reports (invoices, POs, and electronic payments) can be emailed to the various parties. 

Ed Stein adds

We moved to the ability to laser-print, or email purchase orders in PDF format, using eFORMz and eDirect from Minisoft. For vendors who require a faxed purchase order, we email the PDF of the purchase order to an email-to-fax service, otherwise we email them a PDF copy. We only laser-print purchase orders for vendors who either require a mailed copy or do not have an email address or fax number.

Can I configure a disk larger than 36GB on MPE/iX 5.5? The reason the customer is locked into 5.5 is they use Oracle 7.3 — so I'm now trying to set up a test bed to see if I can move the system up to 7.5 and still have all the wheels stay on. But we might not be able to migrate off 5.5, and the only way to get the enough disc space is to try going to 73GB drives. It doesn't look like 73GB are supported, but that doesn't mean someone hasn't been able to make them work 

Jim Hawkins replies

Although your mileage may vary, there is nothing "unsafe" about trying to access 73 GB on 5.5. Of course, there is a 4GB cap on LDEV1, regardless of disk's physical capacity). What's unsafe is the fact that you're likely running on 15-plus year old equipment -- and running on disk-to-firmware-to-HBA combinations they were never tested by us at HP. 

When researching "Large Disk" support in early 2000s, my observation was that disk size constraints were last re-engineered around the 4GB mark during MPE/XL 2.x (early 1990s). From there, most of the code worked pretty well up until 512GB, where we run off the rails of some 30 bit limits.

What didn't work okay up to 512GB was addressed by the "Large Disk" patches for 7.5. Things like REPORT running out of space to display a sector count, DISCFREE output etc. The only allocation change I made had to do with trying to spread IO across disks in a more granular way -- really an optimization, rather than an inherent limit.

Allegro's Stan Sieler adds

I remember that when Allegro encouraged HP to handle big disks, I found some definite problems in some obscure things — and that's why we filed a number of bug reports (including JAGad48770 in 2000) and then lobbied with Mike Paivinen, Louis Runnestad, and the CSY lab manager at the time to get really big disks supported. (Ironically, that triggered extra work for me... I had to make sure that De-Frag/X supported them, too.)

Unfortunately, I can't recall the details of what things had problems. Some of the things were offline utilities (for example, DISKCOPY, or DISCUTIL's SAVE command) that could be significant. Some were cosmetic (e.g., incorrect output from DISCFREE). 

In the back of my mind, I have a suspicion that on some releases MPE might create some disk-based data structures that are too small — in a way that could potentially cause an overwrite of data ... but I really don't remember what it was, or which MPE release (might have been *very* long ago, sorry!). 

My old notes say that 5.5 with PowerPatch 5 had an "official" max disk size of 18 GB and that I thought I'd seen a working 36 GB drive on a system. The same notes say that the base release of 5.5 officially had a 9 GB max disk drive size.

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

June 29, 2012

Celebrate net printing's anniversary: use it

Seven years ago this week HP's 3000 lab engineers announced that networked printing was ready for beta testing. This was one of the last enhancements first demanded by a wide swath of the 3000 community, then delivered by HP. The venerable Systems Improvement Ballot of 2004 ranked networked printing No. 1 among users' needs.

MPEMXU1A is the patch that enables networked printing, pushed into General Release in Fall, 2005. HP had given the community a OS-level substitute for good third party software from RAC Consulting. It might have been the last time that an independent software tool got nudged away by HP development.

The HP 3000 has the ability to send jobs to non-HP printers over a standard network as a result of the enhancement. The RAC third party package ties printers to 3000 with fewer blind spots than the MPEMXU1A patch. HP's offering won't let Windows-hosted printers participate in the 3000 network printing enhancement. There's a Windows-only, server-based net printing driver by now, of course. The HP Universal Print Driver Series for Windows embraces Windows Server 2008 and 2003.

Networked printing for MPE/iX had the last classic life that we can recall for a 3000 enhancement. The engineering was ready to test less than a year after the request. This software moved out of beta test by November, a relatively brief 5-month jaunt to general release. If you're homesteading on 3000s, and you don't need PCL sequences at the beginning and end of a spool file, you should use it. Commemorate the era when the system's creator was at least building best-effort improvements.

MPE/iX 6.5 was still being patched when networked printing rolled out. That's a release still in steady use at some homesteading shops. Plenty of later patches were only created and tested for the 7.0 and 7.5 PowerPatch kits.

Deep inside the Internet somewhere is a white paper that HP's Jeff Vance wrote, a guide he called "Communicator-like" after the classic HP technical documents. HP's pulled off its Jazz repository of tech papers where NWPrinting.html once was available. Our open source software expert Brian Edminster tracked down that gem at the Client Systems website -- the company was one of two which licensed HP's tech papers. But you could check in with your independent support provider, to see if they've got it.

Networked printing was never as comprehensive as indie solutions for the 3000, but at least it was delivered on the OS level via patches. The vendor warned that adding new printers was going to be an uneven process.

HP will support this enhancement on a “best-effort” basis, meaning we will attempt to duplicate and resolve specific spooler problems -- but we cannot guarantee that all ASCII based printers are supported by this enhancement.

While that might sound like a show-stopper seven years later, you'd be surprised how many printers of that era are still attached at homesteading 3000 sites.

Where do you get the patch? That's where HP's still doing its work. The MPE/iX patches were given special dispensation from the pay-for-patches edict of 2010. They're still free by calling HP. The printer and MPE might seem like old technology. But HP's still using telephones to deliver them, so there's that throwback.

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

June 14, 2012

Open Sourcing Access to Linux or Windows from MPE/iX

DSLINE is a classic networking access service provided for HP 3000s. The software is so classic that HP once charged separately for NS3000/iX Network Services. One user wanted to employ DSLINE to make connections, starting from MPE systems and into remote Linux and Windows servers. Sending commands was the task to be performed.

"I currently use a Reflection script to do the job," said Krikor Gullekian. "However, we are moving away from that and creating a JCL for it. I am using FTP to create a file on the host system which is activating commands to run, and that works, but it's a little cumbersome. That's why I was wondering if there were any other way."

Another community member pointed to using the ssh client included on the HP 3000. In theory, so long as the Linux and Window servers have an ssh server, then Gullekian should be able to run remote commands via ssh. But there's some hurdles to overcome in using ssh on a 3000 for remote command execution.

Brian Edminster of Applied Technologies, who's maintaining a repository of these sorts of open source tools for 3000s, warns that ssh needs some improvements to let it perform the same level of work as Linux or Windows versions of the remote access tool.

Unfortunately, the available ssh client for MPE/iX is none too current, and is essentially 'broken' with regard to remote command execution. As I recall, it has something to do with SELECT being busted on MPE/iX. It works well enough to support scp and sftp though, but that's pretty much it.  

Edminster has created workarounds for anyone who needs password-free invoking of secure remote scripts, however. What's more, it appears that the MPE way of writing such received files to disk is more secure than the other platforms' FTP services.

"What I've had to do in environments," Edminster says, "where I want passwordless secure remote script invocation (ala ssh) is to have a scheduled task (via cron or whatever) that looks for and executes specifically named scripts, one that then removes the script when done executing."

To avoid having the remote cron beginning to execute a partially sftp-put file, I'd send it with a '.tmp' suffix, and then rename it upon successful completion of the put and/or chmod the file to make it executable when I'm ready to have it run (rename and chmod being atomic operations). This is necessary because, unlike MPE/iX, many systems FTPd (and likewise, sftpd) will start writing the received content to disk as soon as it receives it -- making a partially received file 'visible'.    

Yes -- we've been spoiled in MPE/iX Land. 

For what it's worth, on my bucket list is either an update to the OpenSSH port (with an attempt to fix remote command execution), or port of other, simpler ssh implementations. If the OpenSSH implementation for MPE/iX is what you want to try, you can get the necessary files either from the fine folks at Allegro (from their website), or from www.MPE-OpenSource.org.

I'd be happy to work with anyone that needs help getting this OpenSSH port installed and operating -- including how to get around some of its limitations.

Over at the Allegro website, Edminster's MPE OpenSource site is named as the best destination for such software.

Those looking for MPE/iX ports of Open Source software that were formerly hosted at HP’s “Jazz” and other sites will appreciate http://www.mpe-opensource.org. Currently the site offers an updated all-in-one package of the components required to implement the SFTP Secure File Transfer Protocol on MPE/iX 6.5 or later. This package includes Perl, the Gnu Compiler Collection (GCC), as well as GNU tools, SSL, SSH, and required dependencies.

With that said, Allegro's Donna Hofmeister did point out that the company has a great whitepaper on using SFTP, as well as accompanying downloads. Look for "SFTP" on the Allegro whitepaper page.

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

May 25, 2012

Paper passes on primers on MPE, and more

Imagine it's your first day managing an HP 3000. You don't have to travel in a time machine to find that kind of event. However, a magic carpet of the past ensures the delivery of time-tested fundamentals. The carpet is paper, where so much MPE lore first unspooled for your community. If not for articles on paper, much of the 3000's wisdom would never have made it to the web.

As for that first day, an IT manager at Disston Tools in South Deerfield, Mass. has had that date arrive just this month. He's a total newbie, taking over for a veteran who's leaving this manufacturer. Everybody's a newbie at something. It's just like publishing news: if it's something you didn't know, then it's news to you.

NewsprintNot many Interweb resources call themselves publishers, but we do. We started with ink on paper, my partner Abby and I, initially for a cross-platform IT publisher before the NewsWire was first delivered from our own offices. This week we delivered our 155th print issue. The May edition will be available to our community newbie, as well as one veteran that community icon Vladimir Volokh scouted out in Los Angeles. Vladimir hand-delivers print issues on his consulting trips, much to our delight.

With all that print heritage, I took note of a retrenchment in printed news this week. The daily newspaper in New Orleans will be daily no more. The Times-Picayune is going to three times weekly in print and everyday online. This is a newspaper that won two Pulitzers for its Katrina reporting. Sadly, the caliber of content doesn't bulwark many publications anymore. Advertisers, like our fine sponsors, determine how often the presses roll.

In the alternative, of course, there's the Interweb. I use the jokey term for online news because it's completely pervasive and so up to date that the future seems like yesterday if you bury your head in links. Knowing where to look, however, becomes a great mission for printed publications. We always hear that people have found our reports for the first time when they get a print issue of the NewsWire. It's nice to have that outpost, and essential to who we are and how we deliver. But for printed pages long gone, it's great to have host sites that preserve things like George Stachnik's instruction about using files in MPE, and much more. It's one of 21 articles in a series he wrote for the now-departed InterACT magazine. All are preserved for the education of newbies, as well as the rest of us.

Chris Bartram at 3K Associates has collected Stachnik's articles, as well as many other papers, at the 3k.com website. (Think about how long that site has been around. It's so fundamental it's got a two-character domain name. Fewer than 1,300 of those in existence.) Our community is lucky to have the riches of several of these kinds of sites. Open source software, at mpe-opensource.org. Tech papers at robelle.com, adager.com, allegro.com.

But most of those papers started out on paper. Because MPE's preserved its roots, even an article like Stachnik's written more than a decade ago will be useful at Disston Tools. The company's covering its MANMAN support needs with service from the Support Group, Inc. Terry Floyd there gave us a heads-up about the new IT guy, and we're glad to send the new member our printed May issue.

Print-ExclusiveSponsors in your community still believe in the power of paper, even while they buy Adsense keywords from Google and build Twitter feeds and pursue Facebook Likes. We're always mindful that the NewsWire depends on support as well as new readers and faithful followers. We once led off with print reporting and archived it on the Web. But about the time Katrina was hitting New Orleans we switched out our lead horse -- with some exception. Every printed issue carries content that's only available in paper as an exclusive, for awhile. If you'd like your own printed copy in the US, we'd be glad to send it to you. (Click on the icon above to send us a message.) Our non-domestic web-only readers, thousands of them, have access off the page. Like the Times-Picayune, we're working with a blended model of the old and new, even as we link wisdom from the elders to our new readers.

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

May 21, 2012

HP runs ahead and behind, then and now

The iconic entity called Interex emerged this month 28 years ago. HP had announced it would catch up to 32-bit computing with Spectrum. And the vendor whose sales still didn't exceed $7 billion said in 1984 that touchscreens were the most intuitive interface. Being ahead and behind all at once is a sign that you're still developing, making leadership while you catch up your customers

RandomAccessInteract84Hewlett-Packard used the 1980s in your community to push out new ideas. Touch-based personal computing hit the market in the HP 150, one of the Series 100 PCs that transformed the International Association of Hewlett-Packard Computer Users. Before HP cast its seeds of PC innovation, Interex didn't exist. In a May column from executive director Bill Crow in InterACT magazine, the user group renamed itself "to define the association's independence" from HP.

Although that user group has been in the grave more than six years, its members' insights haven't evaporated. An era of ink on paper (click above for detail) has preserved milestones like HP running more than 25 years ahead of the industry with touchscreens. It's easy to forget your community was reaching for a breakthrough office experience even while it was dragging along chips devised a decade earlier.

Ed McCracken, a GM of HP's Business Development Group, announced in early '84 the seven basic principles guiding HP's "office automation strategy:

1. The workstation is the most important component, followed by the distributed data processing system (DDS)
2. All workstations will be personal computers
3. The touchscreen is the most intuitive interface
4. Workstations will not tie directly to mainframes but to an intermediate DDS
5. A pragmatic approach to open architecture is required
6. High quality is essential
7. There must be an intuitive integration linking managers' workstations, secretarial workstations, and the other components of the system.

Number 3 is the most striking of the guides offered by McCracken, the man who drove the genius of bundling the rising DDS of the 3000 with a crack database. But in '84 HP was already considering IMAGE a database that needed a successor. The vendor was following in IBM's wake, right down to a new partnership with a small company built by an IBM ex-pat. Interex also recognized that Alfredo Rego -- "the man behind Adager" -- was on par HP's CEO, John Young. Both gave 1984 user conference speeches, but Rego recognized that IMAGE was to remain the force behind the 3000's success.

It wasn't going to come through a new processor family -- although the Spectrum project's 32 bits were critically overdue. Like today, software mattered more than hardware like Itanium. Oracle's database, built upon the same IBM roots, will determine the fate of the last remaining OS that HP ever built with its own R&D. Databases are lynchpins.

HP saw as much when it partnered with Esvel Inc. The firm founded by Kapali Eswaran, one of the founding members of the IBM System R relational DB product, would develop "scalable database architecture for HP." The next product turned out to be Allbase, but HP already wanted a common database among its real-time, scientific (HP-UX) and office systems.

Like then, the vendor's reaching for some commonality with its Itanium futures. Last year Intel was announcing new underwear for the chip the industry forgot, promising that Xeon architecture would share base elements with Itanium. HP wants to have it both ways -- a market in a the commodity space along with the power of software built on proprietary hardware. You've still got that kind of power in your MPE-IMAGE world. Because Oracle's got HP by the scruff of its enterprise neck, the software still calls the plays. But now HP doesn't control the database -- to the point of seeing customers define themselves as Oracle shops. Oracle's not leaving HP computing. It's departing the computing most profitable to HP.

Esvel was the first step that HP took toward embracing an industry standard for its enterprise business. Back in 1984 the little company had already delivered the seeds of DB2 to IBM. HP was chasing Big Blue in every field but instruments back then. The vendor which created the HP 3000 believed in a pragmatic approach to open architecture: standards were less important than reliable value. In less than seven years HP didn't believe that anymore, driving the Open Enterprise with open systems.

Allbase earned a few footholds in the Open Enterprise, but IMAGE ruled the 3000's roost. Just like Oracle does today, HP's database had become the common coin of computers for HP business. You couldn't switch over billions of records without a lot of magic in 1984. Hewlett-Packard had the right idea about touch interfaces, but the wrong technology and message. This May the message is in the hands of the software providers, not the hardware makers. HP used have R&D enough to be both, which is what still makes the 3000 value durable beyond all accepted wisdom. 

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

May 10, 2012

Intrinsic Advice: Finding HP's 3000 Savvy

While I fine-tuned (okay, corrected) yesterday's report about the current lifespan for MPE date intrinsics, my associate technical editor Vladimir Volokh suggested we include HP's documentation page for HPCALENDAR. That's the intrinsic HP wrote for the 6.0 and 7.x releases of the 3000's OS, a new tool to solve an old problem. Alas, HPCALENDAR is fresher, but it's only callable in the 3000's Native Mode.

But poking into the online resources for MPE Intrinsics, I stumbled on HP's re-shelving of its 3000 docs. No longer available at the easy-to-recall docs.hp.com, these manuals are at HP's Business Support Center. And just about nowhere else within a 10-minute search across Google's search engine. (Bing did no better.) So where are the guidelines to intrinsics for MPE/iX? All docs for the 3000's software are at the BSC 3000 docs page.

The Intrinsics Manual for 7.x is a PDF file at 

h20000.www2.hp.com/bizsupport/TechSupport/CoreRedirect.jsp?redirectReason=DocIndexPDF&prodSeriesId=416035&targetPage=
http%3A%2F%2Fbizsupport2.austin.hp.com%2Fbc%2Fdocs%2Fsupport%2FSupportManual%2F c01712464%2Fc01712464.pdf

A lot to remember, but not much is simple while 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 02:20 PM in Hidden Value, Homesteading, Migration, Web Resources | Permalink | Comments (0)

May 09, 2012

Which bits produce the 3000's stall in 2028?

Vw-egoUpdate: We advise you to read our following day's report about HPCALENDAR and the CALENDAR intrinsic, for a complete view of the future viability of MPE. Also, the first entry in this series, including advice on what to expect from a 3000 running during 2028.

At the risk of beating a dead horse, we will return to the 3000's roadblock in 2028 one last time. We can wrap up our CALENDAR intrinsic discussion with an explanation of the reason for its hold on the 3000's far future. But it might be useful to consider that 2028 is not so far away that engineers aren't already conceiving its technology. When you merge VW and 2028, you can get an image like the one above.

Before the future, though, there's always history. When MPE was created in 1970, it started as a project called Omega. The miracle of this engineering was its use of 32-bit computing, still a novelty at the time. But when HP canceled Omega in favor of a 16-bit 3000 -- a management choice that prompted black armbands among HP staff -- it sealed the server into a 57-year period of service.

That's because, we were reminded by MPEX co-creator Vladimir Volokh, 16-bit 3000s left only enough intrinsic room for 127 years of accurate dates. The intrinsic CALENDAR, written for the eldest MPE Segmented Library (SL), uses only 7 bits to describe which year is in effect. That delivers a maximum number of 127 years which you can express, and MPE was built with 1900 as its base for dates.

From HP's Intrinsics Manual:

CALENDAR
date

16-bit unsigned integer
(assigned functional return)
Returns the calendar date in the following format:
Bits Value/Meaning
7:9
Day of year
0:7
Year since 1900

HP only allotted 7 bits to describe the year for MPE. Who'd expect that the OS would have a lifespan of more than 50 years? Someone who figured newer and better tools would take over by then. It's commonplace to believe in the equivalent of flying cars -- Volkswagen's 2028 model concepts (shown above) are online in the company's German video and Flash site. Maybe cars will fly in some places, maybe not in others. Oh, for one extra bit. But HP ordered 16 extra, just too late to influence the heart of MPE.

Working in the realm of the original 16-bit MPE intrinsics, "You cannot make less than 9 bits for the date of the year," Vladimir said. "That would be less than 365 days. So that leaves us 7 bits to express the year."

The vintage-'90s HPCALENDAR, reaching into the new elbow room of 32 bits, can use as many as 23 bits for the year. That intrinsic will cover 8 million years, even more. HPCALENDAR is available in Native Mode MPE, and it remains the best choice for any new work done on a 3000's applications.

But MPE's existing intrinsics provide the barrier here: the oldest are in Segmented Library (SL) -- and the newer HPCALENDAR is in Native Library (NL). And the only companies with any chance of adjusting the 3000's dates into 2028 and beyond are those which have insight into MPE/iX source. Then there's knowing what to do with it. They must get into the MPE source and recompile it to use HPCALENDAR.

For complete reference, here's the manual page for HPCALENDAR:

NM callable only.

This intrinsic returns the date in the supported
date type code 4 listed in the table, 
“Supported Date Formats.”
Syntax

I32

   date := HPCALENDAR;

Operation Notes

Where date is the 32-bit unsigned integer
(assigned functional return). This returns the
calendar date in the following format:

Bits Value/Meaning

23:9 Day of year

0:23 Year since 1900

Dates don't vex MPEX, Vladimir reminded us. It can do operations with DATE. "If you have MPEX, and who doesn’t," he says, "DATETOCALENDAR is a function in MPEX."

Vladimir also talks, on his return from consulting trips to 3000 sites, about the level of 3000 knowledge he sees in even long-time users. Management relies on the HP guys to tell them what’s up, and the HP guys don’t know.

"There are all kinds of excuses not to know what you’re doing," he says. He tells of his philosophy about learning. You draw a circle to represent what you know. "Inside the circle is what you know, outside is what you don’t know. You go along the circumference. Only by going along there can you see what you don’t know. So you learn, and you draw a bigger circle, a bigger circumference. The more you know, the more you know what you don’t know."

In converse, consider the smallest circle of knowledge, just a point. Vladimir adds, "When you know nothing, you think you know everything."

No one knows who will be working in the years near 2028 on HP 3000s. But in an era where Amiga computer games can be played on iPhones -- and companies now earn money for such a creation -- it's easy to say we don't know who will break this 2028 barrier. And they might be driving a car called a Volkswagen, and using a computer called the 3000, and neither will resemble what we know today, more than 15 years away.

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

May 01, 2012

RAIDing LDEV1, finding code for migration

What are the solutions for replacing our 4GB internal LDEV1 with something that supports RAID -- or at least disk mirroring? We currently have our production data in 'Jamaica' units, fully mirrored (Mirror/iX), but I've been worried about that ancient LDEV1. We do everything possible to not shut down power. It has reached the point where I have concern that if the drive ever lost its taste for power, it might never spin up again -- and the thought of a RELOAD is not fun.

Mod 20Jack Connor says

There are two fairly low cost solutions which could handle RAID for your 3000. These would be the Mod 10/20 (at left) and Autoraid 12H units, both of which connect via FWD SCSI. A Mod 10/20 would require two FWD cards/connections to be available; the 12H, just one.

Gilles Schipper says

If the HP 3000 is not an A-Class or N-Class, then the best solution would be a Mod 10/20 or an Autoraid 12H. If it is an A-Class or N-Class, the best solutions include any number of fiber-capable devices -- such as a VA7xxx, an XP unit, and others. You could use the Mod 10/20 and Autoraid, but why would you, unless cost is the most important factor?

Craig Lalley says

One problem to consider is the model of HP 3000. The older "NIO" backplanes used in the 9x9s and earlier do not support native Fibre Channel. The N-class boxes do. To boot from a VA7xxx array, you would need the A5814A-003 Fibre to SCSI "brick" if you are not using an A-Class or N-Class.

We have recently begun our migration off the HP 3000. How can I determine what programs reference the data items in our TurboIMAGE databases, since the application vendor we currently use did not provide us with a data dictionary?

Robot3000Michael Berkowitz says

Since you're using COBOL and probably use copy libraries, you could use Robot/3000 from Productive Software Systems. (Screen shot of Robot shown at left)

Larry Simonsen adds

Another option is to use the 3000's grep command in MPE/iX.

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

April 30, 2012

3000's use in 2028: bug, or feature?

The CALENDAR intrinsic that blocks HP 3000 use in 2028 has been described as a bug. On the first day of that year, dates will not be represented accurately. Some in your community consider that New Year's Day, less than 16 years from now, as the 3000's final barrier. But it depends on how you look at it -- as a veteran, or a voyager.

VladimirNov2010A voyager sees CALENDAR as a deadline for departure. This is a part of MPE that was designed in the 1970s, a period when HP had just scrapped a 32-bit release of the 3000's first OS. And just like the Y2K date design, HP engineers never figured their server's OS had any shot of working by the 21st Century -- let alone 2027. But VEsoft's Vladimir Volokh says, "It's difficult to predict anything, especially the future." An IT pro who's planning to depart the 3000 believes CALENDAR is a bug, but that's not how Vladimir sees it.

"This is not a bug, really," he said. "It's a limitation. The end of 2027 date was as far away as infinity when MPE was created." This is a man who defines the term veteran, the kind of professionals who had to work inside 4K memory spaces to build 3000 programs. Limited and expensive resources like memory and disc were supposed to be extended with newer computers. "Every analyst told us a computer would live five years, at most," Vladimir said.

But as a veteran, you've now come to see the day when MPE's lifespan is reaching eight times that prediction. The veteran who chooses to see CALENDAR as a limitation can refer to HP's own lab response. Engineers during the '90s built HPCALENDAR to start extending the 3000's date limits.

The HP 3000's date intrinsics will outlast those in Unix, so long as a program uses HPCALENDAR. HP advised its 3000 customers in 2008 to begin using it on HP 3000s. HPCALENDAR harks back to version 5.5 of MPE/iX. Its power lies in the 3000 for use by programmers who want accurate dates beyond 2038 (the limit in Unix) for application files.

Lifting the limits in application date handling -- that's one level of engineering skill. Extending the operating system limits beyond the 16-bit CALENDAR is a task with a greater challenge. It doesn't mean that it cannot be done. What matters is how healthy the 3000's best experts will be in 10 years or so. Vladimir says he'll be younger than 90 by then. Almost everyone in today's community will be even younger. And isn't 70 the new 60? It will matter when the 3000 needs the last set of bits to move from 16 to 32.

There's a old joke about software shortcomings being called features, rather than a bugs. Veterans learn to call them limitations and look for ways to overcome these aging designs. Everything is aging, even something as omnipresent at Windows XP. (Microsoft wants to end the life of that OS, used on more than 90 million computers, by 2014. Good luck with that.) XP is dying, the 3000 is dying. Well yes, says Vladimir. He tells his hundreds of customers who he visits, "We are all dying. But slowly."

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

April 16, 2012

Migration racks up list of emulated tasks

Some HP 3000s which remain in service are using many MPE nuances to get their jobs accomplished. Each of these tasks needs to be emulated in a migration away from the server. Even as companies embark on migrations to reduce risks, the list of tasks that they hope to replicate from their in-house apps can be surprising.

Such is the case at MM Fab, a fabric manufacturer in LA's South Bay Area. The 3000 shop is now taking its first year of steps off the system, developed and managed by Dave Powell. He shared a list of the things that an emulator must do if it were to succeed at replacing HP's 3000 hardware at his shop. The list also serves as a extensive catalog of the capabilites required of any new operating environment.

"We are thinking about migrating," Powell shared, months before the decision was made. "Which means we have to think about the choice between buying a package vs some form of emulation. Which means I could use some assurance that the [3000 hardware] emulation tools out there would actually work for us."

I can't afford to take this for granted because our system uses some rare features and does unusual things. Lots of them. Example: we do lots of tricky escape-code screen handling (mostly for point-and-shoot, drill down inquiries) that breaks some terminal emulators. Reflection 10.0 works, as does Minisoft WS92 v5.4 and actual terminals from 262x on, but last I checked, Minisoft Secure92 fails big-time. Not trying to make Minisoft look bad, but I need to make the point that software that works elsewhere may not work for us.

"We never cared about portabililty," Powell said, "because we never had any intention of moving to any other platform." From such situations are customers made for the Stromasys virtualization engine. If you're uncertain of whether you're using any MPE nuances in your application, it's a good strategy to get an evaluation of what's in production use today. Even if you're not migrating.

Powell said he doesn't think terminal emulation will be a big migration issue. In an emulation, "I think we could just keep on using the two products that work -- I just need to emphasize that we are off the beaten track, feature-wise."

Since there won't be as much room for all the details of MM Fab's custom-code tricks in our printed edition, we thought we'd put them on display here. This list might be useful to let you see if any of this is working inside your in-house apps. For the record, Stromasys says that anything that's working on MPE today will work in its emulator. The only exceptions they've found were HP's internals diagnotics, like SHOWCLOCKS.

A new platform/replacement app would have to embrace the top-level abilities in Powell's custom-code list. It's the kind of situation that makes some 3000 customers a poor fit for a migration, because these nuances were built over more than 20 years of IT budgets. A migration or replacement would address these all at once -- a cost structure that many 3000 shops cannot endure today.

Powell's MPE magic:

Job queues with separate job limits.

Smart :pause command (wait up to 'x' seconds for that job to log off).

MPE functions like finfo and jinfo.

User functions. Some of them are extra date / calendar routines beyond the built-in ones, like "how many days till end-of-month?" or "how many work-days in the next 'n' days?" and "how many months old is this file?"

MPE variables. User variables plus system variables like hpdatetime, hpaccount, hpfile, hpcpusecs, hpjobcount, hpstreamedby.

Message files / circular files / temp files, including temp message files and temp circular files.

Lots of command files, with tricks like with multiple entry points, input or output or both redirected to files, etc. Command files that use :echo to build a job (in a temp file) which they then stream. (I always wanted a way to have UDCs/command-files run offline, or feed parms into a job like UDCs do, so I finally rolled my own).

Jobs that use :echo or :print to build command-file subroutines (also in temp files), which they can then call lots of times with different parms, like running the same program over and over with one cmd-file parm becoming the info that is passed to the program to tell it what to report, another parm becoming part of the file name where it stores the report output, and another parm telling it who to email the report to.

Lots of do-it-yourself logging, with overglorified :echo to circular files, so I don't need to worry about the logs getting too big.

VPlus, with heavy use of vchangefield in newer apps, and family-of-forms in older ones, both to dynamically make some fields inputable and others display-only, changing the display enhancements so users can see which is which.

Creative escape codes in vplus apps to do things that VPlus didn't do as nicely as we wanted, mostly setting function-key labels and screen-printing.

Lots of escape sequences in non-VPlus terminal IO, mostly in character mode.

Extra terminal control features like turning echo on and off, time-out reads, etc. (Hint: escape codes that cause the terminal to send data back to the computer may work most of the time, but don't get solid unless echo is off. Even so, if something goes wrong you don't want the computer to wait forever for an answer).

Lots of env-files for both lasers and old impact printers, mostly changing orientation, print-size and lines per inch so the same report can print on either type of printer. Some reports have a run-time way to tell them how many lines per page, so by coordinating that with env-files I can have a report that normally does 132-column 60 lines do really-small-print portrait mode 124 lines per page on a laser. Also some tray-selection in env-files.

Do-it-yourself fancy laser-printed invoices with legalese in very-tiny print, company name in big print, etc. No special forms package here, just me spending quality time with the PCL documentation.

Converting simple report output to PC-readable format. That's a one-liner on our 3000 with my HP2RTF command file. The new system doesn't have to use RTF, but it does have support a common PC-readable format, has to preserve/translate HP-style line-spacing and page-breaks, and has to support changing print-size and line spacing so the PC file will look normal on screen and printed page. And it has to be easy to invoke in batch.

Email reports. This is also a one-liner here, thanks to a set of command-files I have wrapped around a nifty mail program originally from Telamon. The command files provide logging, improved error-checking, distribution lists, and even automatic retries at gradually-increasing intervals if there is an internet connection problem. I would like to keep that functionality. If possible I'd like to keep the outer layers of my command files, wrapped around whatever mail-sending pgm exists on a new system.

Mass file rename/delete/print/email, with ability to select by date, file age, file size, etc. Some use MPEX, others use my own routines (listf into a file, read it back, maybe call finfo).

IMAGE b-tree dbfinds.

COBOL macros. Intrinsics like command. Any and every HP extension that ever seemed helpful over the last 30 years.

Posted by Ron Seybold at 04:37 PM in Hidden Value, Migration, User Reports | Permalink | Comments (2)

April 11, 2012

Changing IP Addresses for HP 3000s

I need to change the IP address of our HP 3000 in the near future, and it's been over 10 years since I've done anything like this. Here's what I think needs to be done:

NMMGR
Open Config
NS
Guided Config
Put in the network interface, (LAN1), then press Config Network
Enter the new IP address
Save Data
Validate

Tracy Johnson replies:

I would go with Unguided Config. Guided may change things (besides the IP address) to defaults that may have modified over the last 10 years.

Craig Lalley adds:

Depending on the old IP address and the new IP address, you may want to also change the subnet, and the gateway. The gateway can be accessed by hitting F4 for Internet. The gateway is found at the path NETXPORT.NI.LAN.INTERNET

If you are making the change because of a new switch/router, make sure the network guys configure the port for the HP 3000 correctly. In other words, if you have a 100MB card, make sure it is set to 100MB/full duplex and do the same on the HP 3000, and turn off auto negotiate.

Lalley noted that this kind of reconfiguration goes smoother when a manager takes the time to check the network timing settings. Those are available at the path NETXPORT.GPROT.TCP.

Independent IT consultant Al Nizzardini adds that creating a new System Load Tape is an important part of the process. Gilles Schipper of indie support company GSA also explained a key step.

After making the change via NMMGR and validating both netexport and DTS, you need to:

netcontrol net=lan1;update=internet

to actually effect the change

Posted by Ron Seybold at 04:31 PM in Hidden Value, Homesteading, User Reports | Permalink | Comments (1)

April 05, 2012

Migrating Data for Extended Homesteading

Update: Added advice from Brian Edminster on using Jeff Vance's free UDC, UDCVOL.

The redoubtable 3000-L mailing list still boasts more than 600 readers, and more than 100 of them answer questions about 3000 operations. The discussion helps homesteaders, or those who are making moves to extend the life of 3000s.

Or replace them with other 3000s. A reseller recently asked for help on data migration of the homestead variety. He got instructions useful for anyone populating a fresh disc with production data.

I'm using MPE/iX 6.5 on a 9x7 3000, and trying to move data from a system volume set to a private volume set. I made a full backup and have created a private volume set, but I'm having problems restoring my data to the private volume set.

Craig Lalley of EchoTech replied:

You need to build the accounts and groups on the private volume before the restore. On the old system, run BULDACCT like this

acct_list%VSACCT=user_set

Purge the old accounts, then STREAM BULDJOB1. This will build the "buckets," the accounts/groups on the private volume. Then do the restore.

Brian Edminster of Applied Technologies took note of a free program to control volume operations.

An even better idea is to use Jeff Vance's Volume Mgmt UDC's, available at the OpenMPE 'JAZZ' page. It's a step up from doing it manually, because you can set up a config file that will automagically put accounts/groups on the proper volumes. I use this on all my systems, and for all my clients that have non-system volumes. (Basically, anybody with a system big enough to have more than one disk)

Purging that old account was part of several replies to the question. Keven Miller of 3K Ranger said, "You can avoid doing the NEWACCT,NEWGROUP,ALT... yourself by using the ;CREATE and ;VOLSET=p-volume  on the restore. But you will likely want to purge the old account first."

Tracy Johnson of Measurement Specialties said that the concept for the migration is "to make duplicate accounts with NEWACCT on the new volume set with the ONVS parameter, as well as any NEWGROUP commands you may need. Once done, you need to ALTGROUP the groups with the HOMEVS parameter. A pair of job streams can be created with the BULDACCT command. And purging the old data is a good idea. Otherwise you end up with phantom disc space usage."

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