July 21, 2014

Maximum Disc Replacement for Series 9x7s

Software vendors, as well as in-house developers, keep Series 9x7 servers available for startup to test software revisions. There are not very many revisions to MPE software anymore, but we continue to see some of these oldest PA-RISC servers churning along in work environments.

9x7s, you may ask -- they're retired long ago, aren't they? Less than one year ago, one reseller was offering a trio for between $1,800 (a Series 947) and $3,200. Five years ago this week, tech experts were examining how to modernize the drives in these venerable beasts. One developer figured in 2009 they'd need their 9x7s for at least five more years. For the record, 9x7s are going to be from the early 1990s, so figure that some of them are beyond 20 years old now.

"They are great for testing how things actually work," one developer reported, "as opposed to what the documentation says, a detail we very much need to know when writing migration software. Also, to this day, if you write and compile software on 6.0, you can just about guarantee that it will run on 6.0, 6.5, 7.0 and 7.5 MPE/iX."

BarracudaSome of the most vulnerable elements of machines from that epoch include those disk drives. 4GB units are installed inside most of them. Could something else replace these internal drives? It's a valid question for any 3000 that runs with these wee disks, but it becomes even more of an issue with the 9x7s. MPE/iX 7.0 and 7.5 are not operational on that segment of 3000 hardware.

Even though the LDEV1 drive will only support 4GB of space visible to MPE/iX 6.0 and 6.5, there's always LDEV2. You can use virtually any SCSI (SE SCSI or FW SCSI) drive, as long as you have the right interface and connector.

There's a Seagate disk drive that will stand in for something much older that's bearing an HP model number. The ST318416N 18GB Barracuda model -- which was once reported at $75, but now seems to be available for about $200 or so -- is in the 9x7's IOFDATA list of recognized devices, so they should just configure straight in. Even though that Seagate device is only available as refurbished equipment, it's still going to arrive with a one-year warranty. A lot longer than the one on any HP-original 9x7 disks still working in the community.

One developer quipped to the community, five years ago this week, "On the disc front at least that Seagate drive should keep those 3000s running, probably longer than HP remains a Computer Manufacturer."

But much like the 9x7 being offered for sale this year, five years later HP is still manufacturing computers, including its Unix and Linux replacement systems for any 3000 migrating users. 

So to refresh drives on the 9x7s, configure these Barracuda replacement drives in LDEV1 as the ST318416N -- it will automatically use 4GB (its max visible capacity) on reboot.

As for the LDEV2 drives, there are no real logical size limits, so anything under 300GB would work fine -- 300GB was the limit for MPE/iX drives until HP released its "Large Disk" patches for MPE/iX, MPEMXT2/T3. But that's a patch that wasn't written for the 9x7s, as they don't use 7.5.

Larger drives were not tested for these servers because of a power and heat dissipation issue. Some advice from the community indicates you'd do better to not greatly increase the power draw above what those original equipment drives require. The specs for those HP internal drives may be a part of your in-house equipment documentation. Seagate offers a technical manual for the 18GB Barracuda drive at its website, for power comparisons.

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

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

July 09, 2014

How to Employ SFTP on Today's MPE

Is anyone using SFTP on the HP 3000?

Gavin Scott, a developer and a veteran of decades on MPE/iX, says he got it to work reliably at one customer a year or so ago. "We exchanged SSL keys with the partner company," Scott said, "and so I don't think we had to provide a password as part of the SFTP connection initiation."

At least in my environment, the trick to not having it fail randomly around 300KB in transfers (in batch) was to explicitly disable progress reporting -- which was compiled into the 3000 SFTP client as defaulting to "on" for some reason. I forget the exact command that needed to be included in the SFTP command stream (probably "progress <mumble>" or something like that), but without that, it would try to display the SFTP progress bar. This caused it to whomp its stack or something similarly bad when done in a batch job, due to the lack of any terminal to talk to.

As SFTP is a pure Posix program, I ended up making Posix-named byte-stream files for stdin and stdout, and generally did all the SFTP stuff from the Posix shell. The MPE job ended up being a bunch of invocations of SH -c to execute an echo command to make the stdin file, and then another SH -c to run SFTP with a ;callci setvar varname -- $? or something like that -- on the end to capture the Posix process exit code back into the CI.

I also parsed/grepped the stdout file after the SFTP completed/exited, in order to test for seeing the actual file transferring message. I also wanted to make sure that all of the stdin content had been processed, so I could detect unexpected early termination or other problems that might not show up in $?.

That's all from memory, as I don't have access to the scripts any longer. In the end, SFTP was completely reliable, after working through all of its little issues.

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

June 18, 2014

The Long and Short of Copying Tape

Is there a way in MPE to copy a tape from one drive to another drive?

Stan Sieler, co-founder of Allegro Consultants, gives both long and short answers to this fundamental question. (Turns out one of the answers is to look to Allegro for its TapeDisk product, which includes a program called TapeTape.)

Short answer: It’s easy to copy a tape, for free, if you don’t care about accuracy/completeness.

Longer answer: There are two “gotchas” in copying tapes ... on any platform.

Gotcha #1: Long tape records

You have to tell a tape drive how long a record you with to read.  If the record is larger, you will silently lose the extra data.

Thus, for any computer platform, one always wants to ask for at least one byte more than the expected maximum record — and if you get that extra byte, strongly warn the user that they may be losing data.  (The application should then have the internal buffer increased, and the attempted read size increased, and the copy tried again.)

One factor complicates this on MPE: the file system limits the size of a tape record you can read.  STORE, on the other hand, generally bypasses the file system when writing to tape and it is willing to write larger records (particularly if you specify the MAXTAPEBUF option).

In short, STORE is capable of writing tapes with records too long to read via file system access. The free programs such as TAPECOPY use the file system; thus, there are tapes they cannot  correctly copy.

Gotcha #2: Setmarks on DDS tapes

Some software creates DDS tapes and writes “setmarks” (think of them as super-EOFs). Normal file system access on the 3000 will not see setmarks, nor be able to write them.

Our TapeDisk product for MPE/iX (which includes TapeTape) solves both of the above problems. As far as I know, it’s the only program that can safely and correctly copy arbitrary tapes on an HP 3000.

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

June 03, 2014

Paper clips play a role in 3000's guardian

The HP 3000 was designed for satisfactory remote access, but there are times when the system hardware needs to be in front of you. Such was the case for a system analyst who was adding a disk drive to a A-Class HP 3000.

BentpaperclipCentral to this process is the 3000's Guardian Service Processor (GSP). This portion of the A-Class and N-Class Multifunction IO card gives system managers basic console operations to control the hardware before MPE/iX is booted, as well as providing connectivity to manage the system. Functions supported by the GSP include displaying self-test chassis codes, executing boot commands, and determining installed hardware. (You can also read it as a speedometer for how fact your system is executing.)

The GSP was the answer to the following question.

I need to configure some additional disk drives and I believe reboot the server. The GSP is connected to a IP switch and I have the IP address for it, but it is not responding. I believe I need to enable it from the console. Can this be done from the soft console, using a PC as the console with a console # command?

A paper clip can reset the GSP and enable access, says EchoTech's Craig Lalley.

Lalley added that a GSP reset is an annual maintenance step for him.
Look on the back of the CPU and you will see a small hole labeled GSP RESET.  You need your favorite techie paper clip. Just insert the paper clip, and you will feel it depress. It takes about a minute to reset. Don't worry, it only reboots the GSP, and will not affect the HP 3000.

I find it is necessary to reset the GSP about once a year.  It seems to correlate to when you really need to get access, and you can't get physical access to the box. Good old Murphy's law.

Lalley calls the GSP, which HP introduced with its final generation of 3000s, one of the most useful things in the A-Class and N-Class boxes.

The GSP is a small computer that is always powered on when the plug has power. With it, it is possible to telnet to and be the console. While multiple admins can telnet in and watch, only one has the keyboard.

It is possible to reboot, do memory dumps and even fully power down the HP 3000 from the GSP.  Use the command PC OFF to power down. The GSP is probably the best feature of the N-Class and A-Class boxes.

Allegro's Stan Sieler has a fine white paper online about MPE/iX system failure and hang recovery that includes GSP tips.

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

May 30, 2014

Deleting 3000 System Disks That Go Bad

Hard-disk-headAs Hewlett-Packard's 3000s age, their disks go bad. It's the fate of any component with moving parts, but it's especially notable now that an emulated 3000 is a reality. The newest HP-built 3000 is at least 11 years old by now. Disks that boot these servers might be newer, but most of them are as old as the computer itself.

A CHARON-based 3000 will have newer drives in it, because it's a modern Intel server with current-day storage devices. However, for the nearly-total majority of the 3000 system managers without a CHARON HPA/3000, the drives in their 3000s are spinning -- ever-quicker -- to that day when they fail to answer the bell.

Even after replacing a faulty 3000 drive — which is not expensive at today's prices — there are a few software steps to perform. And thus, our tale of the failed system (bootup) disk.

Our disk was a MEMBER in MPEXL_SYSTEM_VOLUME_SET. I am trying to delete the disk off the system.  Upon startup of the machine is says that LDEV 4 is not available.  When going into SYSGEN, then IO, then DDEV 4 it gives me a warning that it is part of the system volume set — cannot be deleted.  I have done an INSTALL from tape (because some of the system files were on that device), which worked successfully. How do I get rid of this disk?

Gilles Schipper of 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 offered a repair solution, as well. 

Schipper's solution would use these steps:

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 System Load Tape (SLT)

5. Perform an INSTALL from the newly-created SLT

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

Those SLTs are also a crucial component to making serious backups of HP 3000s. VeSoft's Vladimir Volokh told us he saw a commonplace habit at one shop: Neglecting to read 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 just like other tech resources, ours hadn't been consulted to advise on such procedures, even though we'd run an article about 10 days earlier that explained how to make CSLTs. That tape's rules are the same as SLT rules. 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 for you 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 Newswire, 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.  (Thanks to Digital Innovations' HP MM Support website for its enduring MPE/iX manual archives).

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

There's another kind of manager who won'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.

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

May 15, 2014

Techniques for file copying, compressions

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

Barry Lake of Allegro replies

I would convert it to a bytestream file before zipping it 

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

Mark Ranft adds

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

Tony Summers suggests there is good background instruction, to understand how MPE/iX files are different than those in Unix, at Robelle's MPE for Unix Users article.

I thought there was an option to FCOPY part of a record. If the record contains TODAY IS MONDAY and you want only columns 10-12, I thought there was an FCOPY subset option-- one that would result in just the characters in those positions (MON). Am I halucinating?

Francois Desrochiers replies

The SUBSET option is used to select records by record numbers or strings in certain columns, but you cannot select parts of records. It always works on complete records. You have to use other tools such as Suprtool, Qedit, Editor, Quad, or the Posix "cut" to extract columns.

Olav Kappert adds

You can also pipe the record into a variable and the parse whatever you want out.

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

May 07, 2014

MPE automates (some) password security

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

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

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

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

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

Put the BULDACCT option into your backup's stream file, so its jobstreams are created before your backups. Daily backups, of course. You're doing daily backups, right? And then storing that tape someplace other than the top of the HP 3000. You'd be surprised, said Volokh, how many 3000 sites use that storage location for a backup tape.

The BULDACCT option includes the jobstreams in the backup tape. After your backup is complete, you should PURGE these two streams from your 3000's disk.

Those BULDACCT jobstreams (BULDJOB1 and BULDJOB2) are automatically secured at the file level. This protects BULDACCT streams  from hackers' pry-bars, a very good thing -- because this stream contains all system information including passwords.

You can then RESTORE these streams if you still have a disk error that leaves files intact, but ruins the directory structure. BULDJOB1 contains the instructions to rebuild directory structure, a job that runs before you RESTORE files. BULDJOB2 contains the SETCATALOG commands needed for to reassign all user, account and system UDCs, according to Diercks' fine book. Still available, by the way, online via O'Reilly's Safari e-book service.

Volokh says that if any of the above still seems unclear, 3000 managers can call him at Vesoft and he'll walk managers through the process. "For details, just call us. Don't chase the horse after the barn door has been opened."

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

May 05, 2014

File ID errors mean a reach for BULDACCT

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

BADUFID error

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

Paul Courry replies:

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

John Clogg replies:

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

Since you have missing accounts as well as the UFID problem, it seems your system directory is damaged. I think it’s a safe bet that your system volume set is clobbered. You need to do an INSTALL from your SLT. This will re-install your operating system and give you a brand new directory

You will also need to restore the contents of your system volume set. Make sure you use the KEEP option so you won’t lose any files created by the INSTALL. You might want to purge or rename COMMAND.PUB.SYS before the restore, so you get your SETCATALOG definitions restored along with the files.

Larry Barnes notes:

Your SYSGEN tape may or may not have the SYS account on it. It depends on how the tape was created. You can generate a SYSGEN tape and have it include certain accounts. I usually include sys and TELESUP on the tape.

 

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

April 29, 2014

Foolproof Purges on the HP 3000

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

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

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

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

First you have to find all of your UDCs on a system, and MPE doesn't make that as straightforward as you might think. Using SHOWCATALOG is the standard, included tool for this. But it has its limitations. It can display the system-level UDC files of all users in all accounts. But that's not all the UDCs on a 3000.

MPE, after all, cannot select to show a complete set files by attributes such as program capability. Or for that matter, by last accessed time, or file size, or file security. It's a long list of things that MPE makes an administrator do on their own. Missing something might be the path to looking foolish.

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

By using MPEX -- the X stands for extended functionality -- you can groom your own PURGE command to look out for files that have been recently used, not just recently created. MPE doesn't check if a purged file is a UDC file. 

Such 3000 utilities provided the server and its managers with abilities that went far beyond what HP had built into MPE and its IMAGE database. Now that MPE is moving on, beyond HP's hardware, knowing these third party tools will transfer without extra upgrade fees is like ensuring that a foolproof MPE will be running on any virtualized HP 3000.

They're an extra-cost item, but how much they're worth depends on a manager's desire to maintain a good reputation.

In the earliest days of the sale of these tools, vendors were known for selling them for the price of the support contract alone. That's usually about 20 percent annually of the purchase price. If a $4,000 package got sold that way, the vendor billed for just $800 at first. It made the purchases easier to pass through a budget, since support at the manager-tool level was an easier sell. Think about it. Such third parties passed up $3,200 per sale in revenues in the earliest days. They also established relationships that were ongoing and growing. They were selling understanding of MPE, not just software.

As we wrote yesterday, this kind of practice would be useful for the community's remaining software vendors. This is not the time to be raising prices to sustain MPE computing, simply because there's a way to extend the life of the hardware that runs MPE. As the number of MPE experts declines, the vendors will be expected to fill in the gaps in understanding. Those who can do this via support fees stand the best chance of moving into the virtualized future of 3000 computing.

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

April 16, 2014

How to tell which failed drive is which LDEV

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

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

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

3kRangerLDEV

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

On an A-Class, you have the two internal drives

0/0/1/1.15 (intscsia.15) (I think top drive)
0/0/2/1.15 (intscsib.15) (I think bottom drive)

Plus an external, Ultra2 wide on 0/0/1/0
Narrow single ended on 0/0/2/0
slot-1 on 0/2/0
slot-2 on 0/4/0
slot-3 on 0/6/2
slot-4 on 0/6/0

Then, depending how the externals are housed, it could be just an address switch on the back of the housing case. Not sure about an N-Class, or a 9x7, or a 9x9. But the processes are the same. If you're running anything more complex, like RAID, a hardware guy will help.

Hardware guy Jack Connor of Abtech adds

There's the 12H, NIKE, VA family, and XP disc frames that are the common arrays.

Or, if it's not an array, but something like a Jamaica disc enclosure, you can look at SYSGEN>IO>LD to determine what all discs should be present, then do a :DSTAT ALL to see who's missing and record that  path including the SCSI address.

You then would go the card that has the major path, such as 0/2/0/0, and then follow that cable to the Jamaica enclosure. Look at the back to determine from the dip switch setting what each slot's SCSI address is.  That would be the failed drive.

Also, often times with a Jamaica enclosure the drive will have either a solid green light on or, alternatively, be totally dark while all the other drives see activity (with flashing green lights).

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

March 28, 2014

MPE's dates stay at home on their range

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

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

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

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

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

The days of the week are exactly the same for dates in 1900 as for the year 2000, Vladimir says. "It's ironic that we'll be back to Y2K, no?" he asked. VESOFT's MPEX has a calendar function to check such similarities, he added.

The MPE/iX system will continue to run in 2028, but reports which rely on dates will print incorrectly. That's probably a euphemism, that printing, 14 years from now. But it's hard to say what will survive, and for how long. Or as Vladimir reminded us, using a quote from Yankee baseball great Yogi Berra, "It's tough to make predictions, especially about the future."

The year 2028 was 67 years into the future when the initial MPE designers chose the number of bits to represent CALENDAR dates. Who'd believe it might matter to anyone? "Will Stromasys continue to run after 2028?" asked one ERP expert a few years back during a demo. "Just as well as MPE will run," came the reply, because CHARON is just a hardware virtualization. The operating system remains the same, regardless of its hosting.

And as we pointed out yesterday, one key element of futuristic computing will be having its own date crisis 10 years after MPE's. Linux has a 2038 deadline (about mid-January) for its dates to stop being accurate. Linux-based systems, such as the Intel servers that cradle CHARON, will continue to run past that afterlife deadline. And like the Y2K days of the week that'll seem familiar in MPE's 2028, an extension for Linux date-handling is likely to appear in time to push the afterlife forward.

Perhaps in time we can say about that push-it-forward moment, "You could look it up." Another quote often misunderstood, like the 2028 MPE date, because people think Berra said that one, too. It's not him, or the other famous king of malapropisms Casey Stengel. You Could Look It Up was a James Thurber short story, about a midget who batted in a major league game. Fiction that became fact years later, when a team owner used the stunt in a St. Louis Browns ballgame by batting Eddie Gaedel. You never know what part of a fantasy could come true, given enough time. Thurber's story only preceded the real major-league stunt by 10 years. We've still got more than 13 years left before MPE's CALENDAR tries to go Out of Range.

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

March 27, 2014

Beyond 3000's summit, will it keep running?

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

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

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

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

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

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

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

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

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

At that summit, Paul said that two climbers "talked for a few minutes we made tentative plans to climb Oregon's tallest mountain, Mt. Hood, pictured in the background. We have since set a date of May 16th."

We've written before on the effects of 2027's final month on the suitability of the 3000 for business practice. Kell's ideas have merit. I believe there's still enough wizardry in the community to take the operating system even further upward. The HP iron, perhaps not so much. By the year 2028, even the newest servers will still be 25 years old. Try to imagine a 3000 that was built in 1989, running today.

Better yet, please report to us if you have such a machine, hooked up in your shop.

Why do people climb mountains? The legend is that the climber George Mallory replied, "because it is there." 2028 is still there, waiting for MPE to arrive. Probably on the back of some Intel-based server, bearing Linux -- unless neither of those survives another 14 years. For Intel, this year marks 15 years of service for the Xeon processor, currently on the Haswell generation. Another 25 years, and Xeon will have done as much service as MPE has today.

There is no betting line on the odds of survival for Xeon into the year 2039. By that date, even Unix will have a had its own date-handling issue. The feeling in the Linux community is that a date solution will arrive in time.

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

March 25, 2014

How to Delete All But the Last 5 Files

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

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

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

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

Francois Desrochers replies

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

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

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

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

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

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

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

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

%PURGE LOG####-^V

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

Olav Kappert replied

This is easy enough to do. Here are the steps:

Do a listf into a file 'foo'

Set 'count' = end-of-file count
Set 'index' to 1
Set 'maxindex' to 'count' - 5
Read 'foo'
Increment 'index' by 1
If 'index' < 'maxindex' then
Purge file
Loop to read 'foo'

The exact syntax is up to you and MPE.

Barry Lake adds

Very simple if you're willing to use the Posix shell. If this needs to be done with CI scripting, it's certainly possible, but way more complicated. Someone else may chime in with an "entry point" command file to do this in "pure" MPE. But here's the shell method:

Posix Shell Delete Last 5

So... move the last 5 out of the way, delete whatever's left, then move the 5 back into place.

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

March 11, 2014

FIXCLOCK alters software, hardware clocks

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

Gilles Schipper of GSA responds:

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

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

Brian Edminster of Applied Technologies notes:

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

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

Here's the jobstream code for both the spring and fall time changes. 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

Do a showclock to confirm results. Careful, though, of any existing running jobs or sessions that may be clock-dependent.

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

March 10, 2014

Getting 3000 clocks up to speed, always

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

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

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

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

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

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

Clearly, this needs to be changed.

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

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 10:17 PM in Hidden Value, Homesteading | Permalink | Comments (0)

March 05, 2014

What does a performance index represent?

I know this may be a tough question to answer, but thought I'd at least give it a try.

SpeedometerI'm doing an analysis to possibly upgrade our production 959KS/100 system to a 979KS/200, and I see the Hewlett-Packard performance metric chart that tells me we go from a 4.6 to 14.6. What does that increase represent? For instance, does each whole number (like 4.0 to 5.0) represent a general percentage increase in performance? I know it varies from one shop to another, so I'm just looking for a general guideline or personal experience -- like a job that used to take 10 hours to run now only takes 7 hours. The "personal experience" part of this may not even be appropriate, in that the upgrades may not be close to the metrics I am looking at.

Peter Eggers offers this reply, still worthy after several years

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

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

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

Since you didn't understand the performance numbers, you might hire a good performance consultant that knows the HP 3000. Of course, look for the "low hanging fruit" fruit first for the biggest bang for the buck, and continue "up the tree" until you lose a net positive return on time invested.

You'll also hear it mentioned that adding memory won't help if the system is IO-bound. That is typically not the case, as more memory means more caching which can help eliminate IOs by retrieving data from cache, sometimes with dramatic improvements. This highlights the need for a good performance guru -- as it is easy to get lost in the details, or not be able to see "the big picture" and how it all fits together.

Aside from Eggers' advice, we take note of the last time HP rated its 3000 line.

At HP World in 2002, it announced the final new 3000 systems, all based upon the PA-8700 processors. At the high end, HP announced a new N-Class system based upon the 750 MHz PA-8700 processor. The new N4000-400-750 was the first HP e3000 to achieve an MPE/iX Relative Performance Units (MRPU) rating of 100; the Series 918 has an MRPU of 1.

HP contends that the MRPU is the only valid way to measure the relative performance of MPE systems. In particular, they maintain that the MHz rating is not a valid measure of relative performance, though they continue to use virtual MHz numbers for systems with software-crippled processors. For example, there are no 380 MHz or 500 MHz PA-RISC processors. Unfortunately, the MRPU does not allow for the comparison of the HP e3000 with other systems, even the HP 9000.

HP has changed the way it rates systems three times over the life of the HP 3000. During the middle years, the Series 918 was the standard with a rating of 1. In 1998, HP devised a new measurement standard for the systems it was introducing that no longer had the Series 918 at 1. It is under this new system that the N4000-400-750 is rated at 100. Applying a correction factor, AICS Research has rated the N4000-400-750 at 76.8 relative to the Series 918’s rating of 1.

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

March 04, 2014

Experts show how to use shell from MPE

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

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

But from the MPE command line this returns blank:

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

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

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

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

Donna Hofmeister of Allegro replies

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

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

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

Barry Lake of Allegro adds

The answer to your question of why, for the record, is that the first token is what's passed to the shell as the command to execute. In this case, the first token is simply "echo", and the rest of the command is either eaten or ignored.

To fix it, the entire command needs to be a single string passed to the shell, as in:

:run sh.hpbin.sys; info='-c "echo 21 + 21 | bc"'
 42
 END OF PROGRAM
 :

And if you want to clean that up a bit you can use XEQ instead of RUN:

 :xeq sh.hpbin.sys '-c "echo 21 + 21 | bc"'
 42

Or, you can do it with, for example, Vesoft's MPEX:

 : mpex

 MPEX/3000  34N60120  (c) VESOFT Inc, 1980  7.5  04:07407  For help type 'HELP'

 % setvar pi 3.14159
 % setvar r  4.5
 % calc !pi * !r * !r
            63.617191
 % setvar Area !pi * !r * !r
 % showvar Area
 AREA =            63.617191
 % exit

 END OF PROGRAM
 :

But the only thing I want is to be able to use a complied program which handles arbitrary precision variables from inside a job stream — such that I can return the integer part of the result to an MPE/iX variable.

Barry Lake replies

If you're happy with truncating your arithmetic result — that is, lopping off everything to the right of the decimal point, including the decimal point — then here's one way to do it:

/SYS/PUB $ echo "31.1 * 4.7" | bc
 146.1
 /SYS/PUB $ echo "31.1 * 4.7" | bc | cut -f1 -d.
 146
 /SYS/PUB $ callci setvar result $(echo "31.1 * 4.7" | bc | cut -f1 -d.)
 /SYS/PUB $ callci showvar result
 RESULT = 146
 /SYS/PUB $ exit

 END OF PROGRAM
 : showvar result
 RESULT = 146
 :

Perfect! Thank you. And this construct accepts CI VAR values as I require.

:SETVAR V1 "31.1"
:SETVAR v2 "4.7"
:XEQ SH.HPBIN.SYS;INFO='-c "callci setvar result $(echo ""!V1 * !V2"" | bc |
cut -f1 -d.)"'
:SHOWVAR RESULT
RESULT = 146

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

February 28, 2014

How MPE Balances New Disk Space

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

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

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

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

BALANCE MPEXL_SYSTEM_VOLUME_SET

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

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

HP designed the 3000's storage management so that the MPE/iX algorithm will be picking which "most empty" disk to write to next based on percentage full, not sector counts.

MPE watches the percentage full that will cause a switch to another disk. The watching has gotten more precise. An older algorithm would wait until there was a 1 percentage difference in fullness to switch -- and as an example, that would mean 3 GB of data on a 300 GB disk. Now MPE waits until there’s just a .01 percentage.

MPEX from VEsoft can be an aid for manual load balancing after disk installation, before production use. It has commands that can be used to build a DEFRAG process. There's also that DeFrag/X software from Lund to manage storage assignment.

As a last resort, one HP MPE veteran suggests that if nothing else helps, and no MPEX or DEFRAG are at hand, "managers could try to limit the penalty by moving large but less "interesting" files/accounts to the new LDEV (freeing space on the old LDEVs) and then use the VOLUTIL ALTERVOL command to limit the remaining PERM space on the new LDEV afterwards. Yes, a somewhat insane approach, I know."

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

February 24, 2014

Expanding that Posix Shell on the 3000

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

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

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

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

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

But enough history; Posix is still on the 3000 and remains a powerful interface tool, an alternative to the CI interface that HP created for the system. You can even call Posix commands from the CI, a nifty piece of engineering when it can be done. That's not always possible, though. A customer wanted to know how to "expand wildcard shells" using Posix. He tried from the CI and had this story to relate.

:LL /BACKUPS/HARTLYNE/S*
ls: File or directory “/BACKUPS/HARTLYNE/S*” is not found

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

Jeff Vance, the 3000 CI guru while at HP, who's gone on to work in open system and open source development, said this in reply:

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

Greg Stigers then supplied the magic Posix shell command to do the expansion:

SH.HPBIN.SYS '-c "/bin/ls -l /BACKUPS/HARTLYNE/S*"'

In a note of thanks, the customer said that getting the answer by working with the HP 3000 community's newsgroup "is like having an entire IT department right outside my door."

An interesting footnote if you've read this far: The Posix shell for the 3000 is one part of the operating system not built by HP. The shell was licensed by HP from MKS, and Hewlett-Packard pays royalties to MKS so Posix can work inside of MPE/iX.

For now, enjoy using Posix as a way to get familiar with the commands in Unix systems. In the great majority of instances, these commands are the same.

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

February 17, 2014

Durable advice speeds up HP 3000s

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

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

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

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

:listf h@.pub.sys,2

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

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

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

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

We have a DLT tape drive. Lately it wants to take 6-7 hours to do backup instead of its usual two or less.  But not every night,  and not on the same night every week.  I have been putting in new tapes now, but it still occurs randomly. I have cleaned it. I can restore from the tapes no problem. It doesn’t appear to be fighting some nightly process for CPU cycles. Any ideas on what gives?

Something that may be causing extended backup time is excessive IO retries, as the result of deteriorating tapes or tape drive.

One way to know is to add the ;STATISTICS option to your STORE command. This will show you the number of IO retries as well as the actual IO rate and actual volume of data output.

Another possibilty is that your machine is experiencing other physical problems resulting in excessive logging activity and abnormal CPU interrupt activity — which is depleting your system resources resulting in extended backup times.

Check out the following files in the following Posix directories:

/var/stm/logs/os/*
/var/stm/logs/sys/*

If they are very large, you indeed may have a hardware problem — one that is not "breaking" your machine, but simply "bending" it.

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

February 11, 2014

Making a few more comparisons of code

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

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

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

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

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

The HP 3000's File Copier, FCOPY, includes a COMPARE option. Vladimir called to remind us (after he mentioned celebrating his 75th birthday last week) that FCOPY COMPARE will only work on a single file at a time. "But with MPEX, you can use it on a file set," he said.

If you're able to log onto a 3000 you can find FCOPY and COMPARE with it. MPEX is for sale, so that makes a complete solution set. Alas for Whisper, it dropped out of the market. The company that built the Studio ended an 18-year run in 2009, according to company founder Graham Wooley. The UK's Whisper built and promoted the Programmer Studio PC-based toolset, selling it as a development environment which engineered exchanges with the 3000 but could be used to create programs under Windows. Robelle responded promptly with a Windows version of Qedit, and the 3000 ecosystem had a lively competition for programming tools for more than five years.

Programmer Studio seems to be available as 1. A free download, or 2. A $299 product, also downloadable. Sources include Download A to Z, and another location is googooster.blogspot.com. But with commerical products on hand, we'd urge some caution about downloading free versions of formerly commercial software. Heaven only knows what might come down into a Windows hard drive while looking for something with so much value -- but now being offered for nothing.

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

February 07, 2014

Code-cutter Comparing Solutions for 3000s

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

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

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

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

When the subject first surfaced, Bruce Collins of Softvoyage offered details on using diff in the HP 3000's Posix.

run diff.hpbin.sys;info="FILE1 FILE2"

The file names use HFS syntax so they should be entered in upper case. If the files aren't in the current account or group, they should be entered as /ACCOUNT/GROUP/FILE

Donna Hofmeister offered a tip on using Robelle's compare UDC:

Regarding Robelle's compare.  Being a scripting advocate, I strongly recommend adapting their UDC into a script.... and take a few seconds to add a wee bit of help text to the script, to make life more enjoyable for all (which is the reason for scripting, yes?)

Other environments that might be operating in the 3000 datacenter provide alternatives. Former HP engineer Lars Appel brought up a Linux option in the KDE development environment:

If using KDE, you might also find Kompare handy...

http://en.wikipedia.org/wiki/Kompare (see screenshot)

On MPE, as others mentioned, there is still the Posix diff in two flavours: the HP-supplied in /bin and the GNU version that lives in /usr/local/bin. The former allows two output formats (diff and diff -c); the latter also allows “diff -u”.

Oh, regarding /bin/diff on MPE... I sometimes got “strange” errors (like “file too big”) from it when trying to compare MPE record oriented files. A workaround was to use tobyte (with -at options) to created bytestream files for diff’ing.

Appel has noted the problem of comparing numbered files, like COBOL source files, when one or both files have been renumbered.

With Posix tools, one might use cut(1) with -c option to “peel off” the line number columns before using diff(1) for comparing the “meat”. Something in the line of ... /bin/cut -c7-72 SourceFile1 > BodyText1.

Posted by Ron Seybold at 11:25 PM in Hidden Value, Homesteading, User Reports, Web Resources | Permalink | Comments (1)

January 20, 2014

How to convert 3000 packed decimal data?

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

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

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

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

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

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

In the Data Types Conversion Programmer's Guide (tip of the hat to HP MM Support), we read about techniques to convert to real data types when when working outside of the COBOL library and compiler. From HP's documentation:

To Packed Decimal  

The compiler procedure HPACCVBD converts a signed binary integer to a packed decimal.  The input number is considered to be in twos complement form, from 2 to 12 bytes long. 

Packed-decimal procedures must be declared as intrinsics to be called from within high-level NM languages. In languages other than COBOL and RPG, follow these steps to convert from an input real to a packed decimal:

   1.  Multiply or divide the real number by an appropriate power of 10. 

   2.  Convert the resulting value to an base-ten integer. 

   3.  Convert that integer to a decimal.

The MOVE command is used to change one decimal to another within COBOL or RPG. But outside of COBOL or RPG, use the compiler library functions HPPACSRD and HPPACSLD to perform right and left shifts on packed decimals. You specify the amount of offset (the number of digits to be shifted).

To convert a packed decimal to a BASIC decimal, you should convert first to a twos complement integer or type ASCII, and then convert to decimal within BASIC with an assignment.  For example, assign an integer value to a decimal with decval = intval * n0, where n00 is the appropriate power of 10.  To convert between ASCII and decimal, use the VAL or VAL$ internal functions.

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

December 27, 2013

Expert's restore job INSTALLS, RELOADS

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

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

After I boot a system, set up disks, tapes and console access and set up the volumes for the MPEXL_SYSTEM_VOLUME_SET, I copy and paste the file below from a PC text file into the console. Once it's complete, the tellop commands simply spell DONE. I wanted it to show so I would notice it more than a single LOGOFF.

Note: I intentionally added the pause to ensure the tape in LDEV 7 reloads before the job starts.

Editor's Note: For those who might not know, the ">" indicates a redirect to a file; two in a row indicates an append to a temporary file. (Thanks to Vladimir Volokh for pointing this MPE fundamental out to us.) You can see a version of the job which you can cut and paste online at the 3000 newsgroup archive.

RanftJob

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

December 18, 2013

Store to Disk preserves backups' attributes

By Brian Edminster

Second of two parts

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

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

If you have a version of STORE that has compression, use it to reduce the size of backup.  If not, use the ‘z’ option in the tar/pax archive you create from your store-to-disk backup.  Do not use both.  They don’t play well together, and you may end up with a larger tar file.

But what about the tar archive size limit of 2GB?  There’s an easy way around this as well, as this limit is common on early Unix and Linux systems. Just pipe the output through ‘split’ to create chunks of whatever size you want. Below, there's simple examples for both directions.

Piping Tar Figure 1, just below, is an example of the ‘cksum’ file produced.

Checksum 1 Grey

Below, Figure 2 is an example of a ‘cksum’ created of the files as they’re stored on the NAS. 

Checksum 2 GreyAs both the hashes and #bytes shown in each file are the same as on the MPE/iX server — we know the backups are transferred correctly.  The same technique can be used ‘in reverse’ to verify that when FTP’d back to the FTP server, they’re still intact.

When un-taring this backup, ‘cat’ the pieces together and pipe it through tar.   At least, that’s the way it’s supposed to work.  Yes, there is a known issue with the MPE/iX Posix shell’s built-in cat command. But I’ve so far been unable to successfully use the external cat command to successfully cat either.  Here’s how this should work for a 2-chunk tar backup:

sh>/bin/cat ./CS1STD1.ustar.aa ./CS1STD1.ustar.ab | tar -xfv - *

Unfortunately, for me at least, it always throws an error indicating bad format for the tar files.There is a work-around, however.  Note that while ‘cat’ing the tar ‘chunks’ didn’t work using the internal or external cat command, untar with multi-file option does work.  Even though it gives a minor error messages, files were returned to proper store-to-disk format, and the recovered store-to-disk backup is intact and has been used to recover the desired files. To do this, use tar like this: 

sh>tar -xfv ./CS1STD1.ustar.aa *  

Also note that when using tar in this way, it will ask for the name of the 2nd-nth component tar files, as it finishes reading each prior piece.  You must give the filename and press return to continue for each.  I believe that it should be possible to script this so that it’s fed the filenames, but I haven’t gotten around to doing that yet.  

Brian Edminster is president of Applied Technologies.

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

December 17, 2013

HP 3000 Backup Files, On the Move

By Brian Edminster 

First of two parts

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

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

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

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

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

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

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

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

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

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

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

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

December 04, 2013

A-Class servers bid to retain some value

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

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

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

Let's pause here for a moment and consider the value retention of this piece of IT equipment. A robust PC, tricked out at the top end of 2001 technology, couldn't even manage the price of a doorstop in today's marketplace.

Take HP's fastest laptop of 2001, the Omnibook 6000. Listed at a minimum of $1,799 on its release, the computer

...combines the power of Intel's fastest mobile processor with HP's tradition of providing reliable, manageable, stable, secure and expandable products. Its sleek styling with magnesium alloy cover, rubberized corners and grips, and spill-resistant keyboard, help make this a durable machine that holds up well for people on the go. 

Today on the same eBay website, that $1,799 computer is selling for $95. You can get one as cheap as $40.

HP's computers, whether laptop or rack-mounted, were built to last with above-the-norm components. No, you won't mistake the drives and memory in that Omnibook with those that have the quality of an A400-100-110 HP 3000. But after a dozen years, without a license that would satisfy an auditor, the 3000 sells for more than 20 percent of its list. The Windows-based laptop, portable in a way that only the 3000 user could dream about, is selling for about 5 percent.

These A-Class systems each have a 9GB boot disk (yeah, smaller than a thumb drive's capacity) and a 300GB main storage disk, along with a whopping 2GB of RAM. The sellers report that they're working on getting an auditor-happy license for the pre-installed MPE/iX 7.5 on the A-Class, too.

These came from HP as part of the e3000 trade in program. I am still in the process of getting all the license transferred on all these A400 and A500 boxes that we got. So to answer your question about a licensed copy of MPE/iX, not yet but yes soon, hopefully.

HP took the value protection of its 3000 line a little too seriously. The horsepower on these A-Class boxes was hobbled by MPE/iX, so a chip that ran at 440MhZ was made to perform at 110. But with MPE/iX as its core value, and the fact that these were the ultimate generation of HP-crafted 3000s, several thousand dollars for trade-in servers that are more than a decade old proves a point about value protection.

When you can find someone offering an Omnibook for $195, running the latest Linux and PostgreSQL installed, you'll have something to compare.     

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

December 03, 2013

When MPE's Experts Vied at Trivial Pursuit

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

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

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

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

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

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

There were others more obscure, but less difficult for the panel. The product number of MPE (HP 32002). The distinguishing feature of the 2641 terminals (an APL command set) and the product which preceeded V/3000 (DEL/3000, for Data Entry Language).

Non-technical trivia was also included. One that had to be answered by the audience was "What does the HP stand for in HP Steak Sauce?" (House of Parliament). And on one question, Eugene himself was humbled by an overlooked answer. He'd asked what four MPE commands can only be executed by the file's creator. The panel found RELEASE, RENAME, ALTSEC and SECURE. But a crowd member said, "There's one more."

"One more?" said Volokh.

"Think about it -- BUILD," came the reply from the crowd.

HP's history offered some political wit in one question. After asking what post David Packard held in the US government (Assistant Secretary of Defense) Volokh added, "and what years did he serve?"

Green, a Canadian, quipped back "In the Nixon administration, which was too long, to be sure."

As the laughs subsided, the Soviet-born US citizen-moderator chided back, "Now, we'll not have foreigners commenting on our government."

But it was an exchange including father and son of that Volokh family that showed the beneficial byproduct of the contest -- expanding the knowledge of HP's engineering roots. Eugene asked the panel, "What is the earliest date of the century the DATELINE intrinsic works with?" A first answer came from the panel, and then Vladimir answered with March 1, 1900.

His son then gave the correct answer: Feb. 29, 1900. "It incorrectly assumes that 1900 was a leap year," Eugene said. "I should know, since Feb. 29 is my birthday."

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

November 26, 2013

Tweaks for network speed arise from Empire

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

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

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

Jeff Kell replied

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

Kell added that "Checksums only matter if you care if the data is accurate :) If you turn them off, errors may go undetected."

If you have enough traffic on the link to really generate congestion, you may want to check your TCP timers. There have been numerous postings in the past on tweaking the default timers (which tend to recover slower than the typical network device on retransmits).

Donna Hofmeister from Allegro added a link to a relevant whitepaper.

"Take a gander at the Allegro paper on TCP timers: http://www.allegro.com/?page_id=79. And yes, checksum matters."

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

November 08, 2013

How to do Digits-to-integer, and EDT to EST

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

Donna Hofmeister of Allegro responds:

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

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

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

Gilles Schipper of GSA responds:

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

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

Brian Edminster of Applied Technologies notes:

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

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

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

Do a showclock to confirm results. Careful, though, of any existing running jobs or sessions that may be clock-dependent.

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

October 28, 2013

Vladimir resolves a 3000 jobs question

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

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

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

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

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

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

"I'm using MPEX in a night job that cleans up old spool files after midnight," Johnson told me this afternoon.

I really care how to set the job number, using MPEX:

%deletespoolfile @.@.@(spool.readydate < today-7)

-----Deleting #O...

... several hundred spool files later...

-----Deleting #O315330, $STDLIST, #J1225, MMAUDJAS,MANAGER.MMV090 (704 sectors)

The above $STDLIST was created the same day, (not > seven days before)

I have noticed this symptom occurs after JOB numbers have rolled over from #J16383 back to #J1, so I there must be a counter when using spool filesets.  In other words, it happily deletes spool files it finds using the date criteria, (working sequentially). But when the job number rolls back to one, it assumes the next spool file with a lower job number encountered is "earlier" than the one before it. (#J1 must be 'earlier' than #J16383, yes?)

Via a phone conversation -- how fundamental, that old-school contact -- Johnson learned this about 3000 jobs:

Before the fix:

%deletespoolfile @.@.@(spool.readydate < today-7)

After the fix: 

%purge @.OUT.HPSPOOL(CREDATE < TODAY - 7 AND NOT OPENED)

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

October 17, 2013

How to Rebuild a System Better, Faster

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

Donna Hofmeister of Allegro replies

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

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

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

Hofmeister added that one of her own CI scripts, sysinfo, has morphed into "topaz, and is available to Allegro's customers. Getting this job is worth the cost of support!"

Jack Connor of Abtech adds

Just as a matter of preference, I normally do a BULDACCT @ at the beginning of the weekly full backup, then the DIRECTORY option along with ;ONVS=MPEXL_SYSTEM_VOLUME_SET, PRODUCTION_SET, etc as a belt and suspenders approach for that day we all hope never comes.

Mark Ranft of Pro 3K outlined the use of sysgen

Here are instructions for a complete backup of basic MPE/iX system via SYSGEN's TAPE option.  It is best if everything fits on a single DDS (or DDS-2 or DDS-3 or DDS-4) tape cartridge, but it will ask for a second (additional) tape(s) as needed.

Note:  I included a 'second_volume_set' which can be changed or removed

Note 2:  The line below is >80 characters, so you have to know how to create a file so that this does not wrap (or make other adjustments.) 

Step One - Create an indirect file containing the following as a single line... 

@.@.@;onvs=mpexl_system_volume_set, second_volume_set

;progress;maxtapebuf;compress=high;online=start;partialdb;directory

Step Two - Create this job

:job jsltall,manager.sys;outclass=,1          
:sysgen                                      
tape store=^fsltall.job.sys                  
exit                                          
:tellop END OF JSLTALL --------------  EOJ    
:eoj                                          

Feel free to add a BULDACCT to this.

 

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

October 15, 2013

What Posix Delivered, and Didn't, for 3000s

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

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

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

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

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

One HP lab engineer of that time said the goal of the POSIX.1 effort was "to increase the availability of some types of applications on the 3000, and to provide for modernization and connectivity with other 'open' platforms. POSIX.1 allowed the Apache Web server, Samba, and many other open source tools to be ported at low cost to the 3000."

The cost was so low that a then-essential Web Server, Apache, was ported by a non-HP engineer who needed the software for his community college's datacenter. Mark Bixby was later hired by the lab and became crucial to what was called Internet & Interoperability.

Posix also brought industry-standard administration interfaces to the OS. The ideal there was to be able to take Unix-trained IT staffers and put them to work managing HP 3000s. Or to make the 3000 no different than Unix management, so the MPE server wouldn't stick out too much. Unix was claiming to be an open choice -- that engineer was correct in putting quotes around open -- ever since the late 1980s.

But Posix was never going to future-proof the 3000's environment, in spite of the promises made about its prospects at HP. It was never engineered enough to provide binary compatibility. By the middle '90s, the Newswire was covering "Proposition 3000" to make the 3000's FTP GET, its tar -xzf, its make and make install work like HP's Unix counterparts.  No vendor would ever certify code for every Unix, or even Linux distros in existence today.

But a majority of open source code has a good track record for just working.

The promise of "open" was always on the other side of serious engineering costs. Until Intel processors ruled the planet, you'd have to worry about hardware support and low-level incompatibilities. Things like page sizes, sector sizes, supported devices, ioctl() codes, incompatible drivers and so on.

Eventually even architectural differences between MPE and the Unix world made Web services a non-starter. A Unix standby called the "fork() of death" that made production web services on the 3000 an impossibility. One legendary MPE expert, Jeff Kell of the University of Tennessee at Chattanooga, said the fork simply wouldn't go into the meatiest part of the OS.

"fork() is such an alien and invasive concept to the MPE mindset, yet a laissez-faire operation on *ux," he said. "It would have required some really heavy lifting, perhaps beyond the fork() conversion folks' abilities or resource scope." Plainly put, more engineering time might have brought MPE into line with Unix, but it might have been too great a difference in design, too.

When you can apply Perl, or other open source resources like the ones found at www.mpe-opensource.org, to a 3000's mission, you see the benefit of changing that XL to an iX. Posix was HP’s first effort at making MPE more standards-friendly. The engineering led to the potential for open source programs such as Samba, Apache and more to make it across the porting divide — and give the 3000 its first genuine cross-platform tools. The Posix work in MPE made GNU C for the 3000 a possibility, back in the nascent era of the open source movement. And without GNU C, nothing else would be available from the open source library today.

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

September 16, 2013

Prospects for Hot-Plugging HP 3000 Disks

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

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

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

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

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

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

 

Hawkins took the time to answer the question with some theoretical possibilities.

Might you be able to pull/push a drive where you've closed the volume?  Likely it would work, but there may be all kinds of noise and stress on the SCSI bus which may not be well handled. However, I think each disk is on its own HBA channel which isn't shared with anything else, and so unlikely to abort someone else's IO.  

This takes us to the last issue: mechanical wear.  

These connectors were likely intended for more or less permanent mating of two components. Very likely they have a limited number of cycles that they are specified to hold-up. I've seen connectors that are specified for fewer than 25 cycles before you lose gold contact material.   This is okay for normal HDD where one might replace one or two per slot in a system lifetime, but not sufficient if you're doing nightly back-ups and swaps.  Connectors, where there is an expectation of a high number of pull/replace cycles, have special designs.  

Now a little good news here is that the N-Class was still pretty much old-school HP design, so likely they didn't pick up something cheap that saved them .2 cents per unit on gold plating. No idea though if the HDD connector is a 10-, 100-, 1000-cycle part. Your system, your risk. 

Mark Ranft, who posed the pluggable question, pointed out that the HP design choices for 3000s seemed to make the servers and their components good candidates for exceptional wear.

It is especially helpful to understand the concept of mechanical wear on the connectors. HP always had excellent and innovative hardware engineering on their HP 3000 (and HP-UX) servers. Remember, you can drop them off a building and still self-test them

I've been doing some digging and I found the following link to the HP-UX forum.  The Unix N-Class appears to allow hot-pluggable drives.   

The actual power supply and the fans are in the front of the N-Class.  The power receptacles in the back have internal cords that lead to the front.

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

August 28, 2013

How to Restore Posix on a New 3000

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

Donna Hofmeister replies

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

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

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

bootpd
bootpquery
bootptab
hosts
inetd
inetd.conf
protocols
resolv.conf
services

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

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

 You can check your tapes (do a vstore) to see if any of them have slash-lowercase files. Maybe you'll get lucky!  If so, do

"restore *t ; /  - @.@.@; keep" 

If you're not so lucky, try this... 

1. Restore the following from the FOS tape:
    restore *t;@.hp36431.support,i0036431.usl.sys;create;show

2. :STREAM I0036431.USL.SYS 

3. After I0036431 finishes,

   :STREAM SUPACCT.PUB.SYS

Barry Lake at Allegro Consultants also suggested a look at the "Plug & Play Posix" paper on Allegro's website. "It's a little dated," he said, "but then, so is MPE/iX 6.0." 

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

August 19, 2013

Replacing LDEV 1 drives: many options

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

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

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

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

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

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

Miller's list below came with instructions on making some drives work.

From what I've experienced, any SCSI disk should work. I got an IBM 4GB drive from someplace, and it wouldn’t work. I put it onto a Unix box (HP-UX, Linux I don't recall) then found that the low level format was a 514 block size, not 512. I had to learn about using "setblock" to reformat the drive. Then, I could install MPE onto it as an LDEV 1.

I have these disks laying around

4GB Seagate ST14207W FastWide SCSI-2 68F
2GB Western Digital WDE2170-007 Ultra Fast Wide 68F
18GB IBM Ultrastar IC35L018UCD210-0 SCSI-LVD/SE U160 80pin
18GB IBM DNES-318350 SCSI-LVD/SE U160 80pin
36GB IBM Ultrastar DDYS-T36950 U160 80pin
36GB Maxstor ATLAS 10K IV U160 80pin
36GB Maxstor ATLAS 10K III U160 80pin

To discover which disk is LDEV 1, power up. See what the primary boot path is. It's likely that your path is 52/56.6.0, and your two drives have jumpers set for address 6 and 5. I believe that 6 in the path has to match the address setting, which is how you join devices to paths. (I'm a software guy, but I try to do my own hardware.)  So the primary path = 56.6.0; I believe LDEV1 = drive with SCSI address 6.

Miller also addressed, so to speak, preferences for data recovery.

You mention you don't have to restore all the data. I hope that means your other drives are on a different volume set. Trying to replace one drive in a multi-drive volume set can be ... undesirable. Files most likely will span over more than one disk. You can use the low level utility DISKUTIL from the ISL prompt (you'll need a bootable disk, or the CD "HP 9000 Offline Diagnostics Environment PA 0409" which HP had available for free at one time).

Using DISKUTIL you which can save off a file from a single disk/LDEV, to recover later (with the VOLUTIL, or RECOVER command). But I don't think you want to go there unless you have to.

In the end, the manager with the failed drive did compare the jumpers on the disks, then changed another of his disks to SCSI address 6. Loading from the SLT commenced, with a note that "there's life in the old girl yet!"

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

August 09, 2013

Techniques of CSV Importing, Revealed

CSV iconI'm importing a Comma Separating Value (CSV) text file into a COBOL II program. I want to compare a numeric field from the file to a number in my COBOL program. In that program, the number is defined as S9(8)V99. The CSV file’s numeric field can vary in length, such as "-1,234.99" or "-123,456.99". If the CSV text file field is always the same length, I know I can move the text field to a COBOL numeric field that is redefined as alpha-numeric. My problem is that the input text field can be different for each record. How do I code in COBOL to accommodate the different number sizes in the text file?

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

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

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

Walter Murray, who worked inside HP's Language Labs before moving out into the user community, noted that Suprtool was likely the best solution to the problem. But after a suggestion that the UNSTRING statement could be useful, he had his doubts. Along with suggesting that "importing the file into an Excel spreadsheet, and saving it in a more civilized format," Murray had these notes.

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

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

Olav Kappert offered a long but consistent process.

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

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

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

In addition to generating a CSV file with leading zeroes, Alan Yeo suggests

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

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

 

 

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

August 08, 2013

HP placed a bet on SQL with open IMAGE

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

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

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

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

This kind of backward compatibility was once religion at HP. Software created for a 1970s 3000 ran unmolested on a '90s server. It stanched the turnover rate for the computer, since an '80s model would run well into the next decade. But even with that self-imposed governor of churn -- the abiding value of investing a six-figure cost into a system -- the 3000 was managing 30 percent turnover in 1993. Almost one system in three was being upgraded.

So changing the essential database on the 3000 was no small bet. A satisfied customer base was a crucial component of the 3000's healthy profits. HP had to add connections to databases that were not locked to a hardware vendor, such as Oracle, Ingres, Informix and Sybase.

In much the same way that HP's engineers managed to launch a new hardware architecture that ran classic software in 1987, IMAGE/SQL emerged by the summertime conference as a seamless hit. The new interface was considered a gateway to wider use of IMAGE data. The chairman of the IMAGE Special Interest Group Jerry Fochtman flew the checkered flag in a letter to the HP Chronicle that year.

The new IMAGE/SQL feature will provide users with a wealth of new opportunities, using leading edge technology tools to meet ever-changing business needs. This new world of data management now opened to the thousands of existing IMAGE applications will indeed have a major impact on how we utilize the wealth of information currently maintained in existing IMAGE databases.

The tech was executed so well that HP didn't feel the need to celebrate a SQL extension at the San Francisco conference. "To HP's credit, they have again successfully added new functionality to IMAGE which is backward compatible with existing user application investments," Fochtman said. The key there was users' applications. The 3000 grew to its heights by being a general-purpose computer that companies wrote their own software for -- and those customer applications are the ones which remain running today among homesteaders.

The SQL shift didn't impress third parties like Oracle as much as HP 3000 users hoped, however. Three summers later, HP rolled out the HP DataMart Manager software for "small and midsize data warehouses." But through four pages of HP press release about the Manager, only HP 9000s running as open systems got a mention at the software rollout. Not even the list of clients could include the 3000. "It supports most popular data-access, reporting and OLAP tools that run on Unix, Windows, Windows NT, Macintosh and OS/2 operating systems."

C'mon. OS/2?

Data access was at the heart of IMAGE gaining its SQL interface, but the addition wasn't sticky enough to earn the 3000 any extra care from HP's alliances and strategy leaders three years later. SQL did its work for existing customers, however. It gave thousands of them extra years of value for data on their HP 3000s. And it continues to do so, two decades later.

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

August 07, 2013

Open source enables MPE enhancements

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

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

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

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

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

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

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

During the brief discussion out on the 3000-L newsgroup, Allegro's Stan Sieler identified the behavior of some routines that could help complete OpenSSH. He quipped that if somebody such as Ken Hirsch -- who started the OpenSSH project rolling more than seven years ago -- wanted to know more about the likes of "a way to actually write to a terminal while there is a read pending," they could've just asked Stan.

Edminster makes a case that documenting system internals and processes, out in the clear, is a backup resource to the community. (This is also documentation which these support firms paid to license, so they have their rights to make it a customer benefit, instead of open explanation.) It's a complicated line to cross, because in this case the MPE/iX internals would have to be understood and utilized to extend OpenSSH -- an open source package.

My understanding is that the agreement between HP and the licensed MPE/iX source holders is to prevent compiling and/or distribution of any new or enhanced copies of MPE/iX. I believe the specific reason MPE/iX source was licensed was to allow 'dissecting' the code — to see what it really does under the hood, regardless of what the documentation says (or doesn't say).  

Why? To allow better understanding of how it works — so that coding workarounds can be developed for applications, and so that in the case of the discovery of a bona fide bug in a critical area of MPE/iX. In this way, at least the option exists of creating a binary patch that can be used to fix a bug (or mitigate the ill-effects of the bug, if a fix is not feasible).

And really, compiling a documentation wiki of system internals and processes (especially the Posix routines as implemented and undocumented user-callable MPE/iX internals) along with workaround best practices for porting code, would be a very valuable thing to preserve existing knowledge.  

Back when MPE/iX was subject to change -- because new releases came out from time to time -- using procedures not documented by HP was considered a 'Bad Idea'(tm).  Now that the OS is, for all intents and purposes, static, that may no longer be the case. While Stan Sieler was right in saying: "You could have just asked me," it also begs the question: What happens when, someday, he's not available to answer?

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

August 06, 2013

Community experts explore Opening SSH

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

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

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

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

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

We asked out on the 3000 newsgroup if anybody with access to source code or inside knowledge of these routines might help. First, Keven Miller of 3K Ranger looked into the MPE routines.

Long ago I looked at the libbsd contribution, and was sad that it didn't come with the sources. Just include files. So, with Ron's request, I started playing with it. So, here are some details of my testing....

 1. I extracted the OIO module from libbsd.a (NMRL), which contains tread,twrite.

 (I had to manipulate the libbsd.a file some, in order to access it)

 2. I created this C test program

 /*------------------------------------------------------*/
#pragma intrinsic FOPEN
#pragma intrinsic FCLOSE
proc int main ()
{
 int R, n;
 short f;
 char buf [40];

f = FOPEN ( "TTY", 0644, 00004 ); /* cctl,und,stdin,ascii r/w */
printf ("tread 5>");
fflush (stdout);
memset (buf, '*', 10)
buf [10] = 0
R = tread (f, buf, 5)
printf ("tr %d [%s]\n", R, buf);

n = sprintf (buf, "-twrite-")
R = twrite (f, buf, n);
printf ("tw %d\n", R);

R = tread (f, buf, 0);
printf ("Done\n");
FCLOSE ( f, 0, 0 );
return 0;

}
/*-------------------------------------------------------*/

So it appears to run okay.

  • tread acts like a binary read. It must read the count characters. i.e., 5 in my code.       
  • Return does not terminate the read.   
  • tread returns the number of characters read. It uses an MPE file number.   
  • twrite returns the number of characters written.

Next, I need to test as two processes or two threads to have them both active.

However, the problem is it leaves the terminal in some odd state. Once the program ends, I get the CI prompt. But when I hit return, it appears to be hung. It can receive TELLs. If from another session, I do abortio on its stdlist device, it shows SOFTWARE ABORT, then get the CI prompt. But hung again.

After aborting the session, (in Reflection NSVT), I can log back in and have a normal TTY.

Oh, and the program requires PM. Underneath tread/twrite, it calls sendio and rendezvousio. I did try FOPEN with nowait-io set. tread didn't read (no echo of characters) and could not complete the read.

Stan Sieler of Allegro took on the task next, but he issued a caveat about working with the deep-inside routine. (Allegro has licensed source code for MPE/iX, but there's no obvious path between that source and Sieler's testing). He addressed the need to use the tread and twrite calls.

Yes and no, it depends.  (There's some terminology and background needed to explain.)

So, in brief... "genmsg", an undocumented routine in the kernel of MPE/iX (and MPE V), has the ability to do "non-preemptive," "soft preemptive" and (allegedly) "hard preemptive" writes to terminals, including network terminals

(However, it's not clear if true (MPE V style) "hard preemptive" writes were ever implemented on MPE/iX.)

But genmsg requires privileged mode, and the routine is capable of aborting the system if called incorrectly. I usually hesitate to post information about potentially dangerous routines.

This doesn't conclude the quest to finish up OpenSSH for the 3000 user, so a server as well as a client is available. But now the ball is rolling, thanks to this notice from some other MPE experts.

It's not clear if enabling the server aspect of OpenSSH would be considered an MPE/iX enhancement by Hewlett-Packard -- or just a repair of a bug report, and then a workaround for anybody who'd like complete OpenSSH on their MPE system.

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

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)

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)