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)

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

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: 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
: echo ![numeric(foo)]   <--- if you have any doubt about the 'quality' of the content use numeric
: setvar foo_n !foo   <--- here's the conversion
: echo ![typeof(foo_n)]   <--- and a test for giggles

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
!if hpday = Sunday and &
!   hpmonth = November and &
!   hpdate < 8 then
!   comment (first Sunday of November)
!   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)
!   TELLOP *********************************************
!   TELLOP Changing the system clock to DAYLIGHT SAVINGS
!   TELLOP TIME.  The clock jumped ahead one hour.
!   TELLOP *********************************************
!   comment (no changes today!)
!   TELLOP *********************************************
!   TELLOP No Standard/Daylight Savings Time Chgs Req'd
!   TELLOP *********************************************
!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
!stream timechg.jcl.sys;day=sunday;at=02:00

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: 


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


Step Two - Create this job

:job jsltall,manager.sys;outclass=,1          
tape store=^fsltall.job.sys                  
:tellop END OF JSLTALL --------------  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, 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:


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


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

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

 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;,i0036431.usl.sys;create;show

2. :STREAM I0036431.USL.SYS 

3. After I0036431 finishes,


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:


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:


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


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

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


SYSHALT 7,$0267


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 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 ( 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:

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:

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

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: -- 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, 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:

!STORE / - /BACKUP/ ;*T &
! ;SHOW=SHORT,dates,path;progress=5;directory;tree;&

open ftpserver
user userid password
del hp3000-full
put FULLB.PUB.BACKUP hp3000-full

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

June 20, 2013

How to Back Up On An Emulated 3000

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

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

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

Taffel replies

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

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

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

May 17, 2013

Many Different Ways to Move Your Console

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

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

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

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

Tracy Johnson of Measurement Specialties added:

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

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

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

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

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

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

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

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

This prompted Schipper to clarify his suggestion:

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

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

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

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

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

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

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

May 02, 2013

Value Hidden, and Uncovered

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

Stan Sieler replies:

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

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

Michael Berkowitz replies:

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

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

Gilles Schipper notes:

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

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

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

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

April 30, 2013

How to Shift a 3000 from FTP to SFTP

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

Allego's Donna Hofmeister replies:

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

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

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

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

1. copy hostsamp. net to

2. edit to make sure it has loopback   name    <--- where and name are corrected to the system you want to connect to

3. copy the to

4. edit to have this line:

hosts : files[SUCCESS=return NOTFOUND=continue]

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

Tony Summers provides a caveat:

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

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

cat FTPT0070
get /export/002_iccm_extract_1161.csv ICR21161


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


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

cat FTPS0070

Connected to

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

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

Karsten Brøndum adds:

Here's a completely different approach. 

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

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

April 15, 2013

SM for Everyone!

By Bob Green

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

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

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

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

“Background Info Break”

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


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

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

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

• CR - File’s creator

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

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

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

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

• ANY - any user

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


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


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


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

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

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

or specified the correct access when the group was built:

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

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

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

April 09, 2013

Good tools making an impact, then and now

By Brian Edminster
Applied Technologies

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

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

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

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

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

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

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

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

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

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


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

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

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

To use these, 


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

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

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

April 05, 2013

Living a Privileged 3000 Life without SM

By Brian Edminster

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

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

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

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

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

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

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

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

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



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

April 04, 2013

Privileges litter the path to passed audits

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

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

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

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


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

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

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

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

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

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

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

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

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

March 18, 2013

Still Patching After All These Years

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

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

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

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

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

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

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

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

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

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

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

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

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

March 08, 2013

Change your clocks, all the time

ClockgoingforwardThe US will roll its clocks forward by one hour this weekend. That means it's time to anticipate the questions about keeping 3000 clocks in sync, for anyone who hasn't figured this out over the last several years. US law has altered our clock-changing weekends during that time, but the process to do so is proven.

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

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

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

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

    !/NTP/CURRENT/bin/ntpdate "-B"

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:


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:

!# 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.
!showjob job=@j
!TELLOP =====================================  SETTIME   A-1
!/NTP/CURRENT/bin/ntpdate "-B"
!if hpcierr <> 0
!  echo hpcierr !hpcierr (!hpcierrmsg)
!  showvar
!  tellop NTPDATE problem
!tellop SETTIME -- Pausing for time adjustment to complete....
!pause 60
!TELLOP =====================================  SETTIME   B-1
!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
!TELLOP =====================================  SETTIME   C-1

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

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
0 3 25-31 3  1983-2038 0   MESZ-2
0 2 24-30 9  1983-1995 0   MEZ-1
0 2 25-31 10 1996-2038 0   MEZ-1

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


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

March 01, 2013

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

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

By Brian Edminster

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

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

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

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

!JOB TIMECHG,MANAGER/user-passwd.SYS/acct-passwd;hipri;PRI=CS;OUTCLASS=,1
!setvar Sunday,    1
!setvar March,     3
!setvar November, 11
!if hpday = Sunday and &
!   hpmonth = November and &
!   hpdate < 8 then
!   comment (first Sunday of November)
!   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)
!   TELLOP *********************************************
!   TELLOP Changing the system clock to DAYLIGHT SAVINGS
!   TELLOP TIME.  The clock jumped ahead one hour.
!   TELLOP *********************************************
!   comment (no changes today!)
!   TELLOP *********************************************
!   TELLOP No Standard/Daylight Savings Time Chgs Req'd
!   TELLOP *********************************************
!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
!stream timechg.jcl.sys;day=sunday;at=02:00

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

February 28, 2013

A Thorough Chill of the OS Business

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

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

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

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


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

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

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

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

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

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

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

January 08, 2013

How to Make HP's Diagnostics Free on MPE

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

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

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

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

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

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

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

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

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

1. Run

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

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

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

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

• Make sure DIAGMOND is not running (run STMSHUT.DIAG.SYS)
copy /usr/sbin/stm/uut/bin/sys/diagmond,DIAGMOND 
copy DIAGMOND,/usr/sbin/stm/uut/bin/sys/diagmond;YES 

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

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

January 03, 2013

Panel producer pursues PDF processes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

November 29, 2012

Power of File Equations: HP 3000 Flexibility

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

By George Stachnik

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

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

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

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

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

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


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

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

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

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

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

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

:file x=myfile;acc=append

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

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

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

:fcopy from=;to=*x

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

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

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

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

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

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

November 06, 2012

Voting for Security, Obscurity and Propriety

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

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

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

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

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

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

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

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

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

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

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

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

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


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

October 22, 2012

Marking Time with MPE's TZTAB File

By Gilles Schipper
GSA Associates 

Last in a series

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


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

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

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

# Aleutian Standard Time, Aleutian Daylight Time (US)


0 3 24-30 4  1970-1973 0   ADT9

0 3 6     1  1974      0-6 ADT9

0 3 22-28 2  1975      0   ADT9

0 3 24-30 4  1976-1986 0   ADT9

0 3 1-7   4  1987-2006 0   ADT9

0 3 8-14  3  2007-2038 0   ADT9

0 1 25-31 10 1970-1973 0   AST10

0 1 24-30 11 1974      0   AST10

0 1 25-31 10 1975-2006 0   AST10

0 1 1-7   11 2007-2038 0   AST10

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

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

How to interpret TZTAB

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

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

2.  AST10ADT

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

4.  0 3 6     1  1974      0-6 ADT9

5.  0 3 22-28 2  1975      0   ADT9

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

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

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

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

10.   0 1 24-30 11 1974      0   AST10

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

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

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

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

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

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

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

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

The 4th value represents the month.

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

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

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

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

0 3 8-14  3  2007-2038 0   ADT9

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

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

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

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

0 1 1-7   11 2007-2038 0   AST10


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

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

1.   # Eastern Standard Time, Eastern Daylight Time

2.   EST5EDT

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

4.   0 3 6     1  1974      0-6 EDT4

5.   0 3 22-28 2  1975      0   EDT4

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

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

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

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

10. 0 1 24-30 11 1974      0   EST5

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

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

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

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

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

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

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

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

The 4th value represents the month.

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

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

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

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

0 3 8-14  3  2007-2038 0   EDT4

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

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

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

0 1 1-7   11 2007-2038 0   EST5

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

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

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

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

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

October 19, 2012

Changing Clocks for Good Maintenance

By Gilles Schipper

Second in a series

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

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

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

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

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

:setclock timezone=w5:00

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

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

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

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

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

Regular Clock Maintenance

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

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

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

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

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

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

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

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

To execute, simply “”

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

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

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

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

October 18, 2012

It's About Time

By Gilles Schipper
GSA Associates

First in a series

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

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

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

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

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

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

Two Clocks, Two Times

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

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

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

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

This can be checked with the command :showcloc

SYSTEM TIME: MON, SEP  3, 2012,  2:25:01 PM

The SETCLOCK command

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

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

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

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

The SETCLOCK command has the following parameters:


Alters the system time or system time zone.


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

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

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

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


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

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

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

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

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

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

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

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

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

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

September 28, 2012

3000 Memoir Project: Wins from Easy Use

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

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

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

I was sold on ease of use, and fun. 

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

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

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

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

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

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

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

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

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

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

September 06, 2012

Core memories spark a cold start for 3000s

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

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

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

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

By Tom Harbron

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

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

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

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

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

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

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

5. IMAGE will be further delayed to January 1974.

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

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

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

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

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

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

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

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

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

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

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

August 30, 2012

In the Beginning, There Was Tape

By Brian Edminster
Applied Technologies

First in a series 

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

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

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

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

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

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

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

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

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

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

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

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

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

Next time: New media for a new millennium

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

August 28, 2012

Porting to Posix on the HP 3000

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

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

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

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

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

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

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

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

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

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

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

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

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

August 22, 2012

Securely Storing Passwords

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

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

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

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

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

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

By Steve Hardwick, CISSP

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

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

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

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

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

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

Next: How to remember all of those passwords. 

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

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

August 07, 2012

Follow that VSTORE onto other drives

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

By Brian Edminster
Applied Technologies 

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

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

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

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

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

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

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

August 06, 2012

What You Need to Do and Check for SLTs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

July 27, 2012

MM/3000 stalwart serves, stocks 3000 docs

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

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

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

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

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

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

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

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

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

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

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

July 25, 2012

Matches of Mountain Lion and MPE/iX

By Brian Edminster
Applied Technologies

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

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

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

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

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

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

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

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

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

July 24, 2012

Make backups, but a CSLT is just as vital

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

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

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

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

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

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

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

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

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

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

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