Secure transfers come out of open shell

The Secure Copy Protocol (SCP) is a suite of transfer solutions that's in a transition position for the HP 3000. Enough work has been completed to bring this software into use under MPE/iX.

Donna Hofmeister, an OpenMPE director, has reported that

When Jeff Vance was at HP, he wrote a FTP script that used the Posix program ‘crypt’ to encrypt/decrypt files leaving an MPE system. If the destination system was also MPE, the file would be automatically decrypted upon delivery.

An expert in open source solutions that run on the 3000 says that SCP clients already have logged work on HP 3000s. Server-side SCP components are still in the future, though, for MPE/iX.

Hofmeister added, "I wrote a very simple decryption shell script for Unix/Linux. If someone had a lot of time on their hands and had intimate knowledge of Unix/Linux porting, there’s a remote possibility, I think, of moving this to the 3000. If all that you're looking for is 'push' (from MPE/iX) functionality, sftpput should work for you."

Brian Edminster of Applied Technologies explained the biggest challenge at the moment is finding OpenSSH download sources, since HP pulled the plug on the Invent3k Web server.

SCP (and sftp) clients are available for MPE/iX and work fine on version 7.5. You can contact me if you’d like to discuss how to get a copy of your own. I’ve had extensive experience with the sftp client, and some with the scp client. Both work remarkably well, although there are some ‘quirks’ it helps to  be aware of. I’d be happy to discuss those too.

The limitation here is that while files can be put to or retrived from other systems, since only the  client is available, the 3000 must originate the transaction. This can make for some process redesigns if your existing applications are used to your 3000 being the ‘server’.  And no, jinetd doesn’t need to be running for SCP or sftp to  work.

There is a port (although technically not complete) of what is by now a fairly old but still workable version of OpenSSH to MPE/iX. It was done by Ken Hirsh, which he had gratiously made available to the 3000 community via his Invent3k account. Unfortunately, the ‘Invent3k’ community development server that HP had made available some years ago is, like Jazz, no longer online. [OpenMPE has plans to rehost the Invent3k programs.]

I don’t recall what version of MPE was used, but I’ve used the ported software successfully on 7.0 and 7.5.  I suspect it’ll work on 6.0 or later, but as yet haven’t tested it myself. His port included the ‘ssh’ command line client, but it had very limited functionality due to technical issues.

It also included the client components sftp and scp, as well as an ‘entropy’  (random number) generator written in Perl. This last piece is necessary because the ‘random’ number functions under MPE/iX aren’t very random. At  least, not as far as serious cryptography is concerned. This Perl script (modified by Ken to run on MPE) was originally written by others to get around not having a kernel-based entropy source for their systems either. Poor quality random number generation is not just a MPE/iX issue.

The ‘server’ components (sshd, sftpd, and scpd) were never ported for reasons that Ken could possibly explain. It might have been something as simple as he didn’t need them. From my perspective I’m thankful that Ken did the port in the first place.

I have installed his OpenSSH port many times, and even tightly integrated it  with legacy applications. Sftp is still in use many times a day with those  applications, and since first installed several years go has safely and securely transferred terabytes of data, with no clear end-date for this application’s life.

I did a presentation on this at the 2008 GHRUG conference. Look at the bottom of the ‘Links & Other Resources’ page at my Web site.

I’m currently in the process of adding even more use of sftp and scp to replace standard FTP in this client’s applications, at the insistence of their PCI  auditors -- and so will have more stories to share.

Paper clip enables resets for disks

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

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

The GSP was the answer when Larry Simonsen asked

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

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

Lalley added that a GSP reset is an annual maintenance step for him.

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

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

Resource 3000's Stan Sieler (one of the Allegro Consultants) has a fine white paper online about MPE/iX system failure and hang recovery that includes GSP tips.

HP's documentation on resetting the GSP for the 900 Series 3000s, remotely through commands, is still online at the HP Web site.

How to Peer Into TurboIMAGE databases

I am looking for a way to permit ordinary users (programmers and support staff) to see who is using a TurboIMAGE database, and what locks are in effect and are pending -- the information you would see with DBUTIL using SHOW ... USERS and SHOW ... LOCKS or SHOW ... ALL.

I have to work within these constraints:  (1) Can’t let them log on with SM capability.  (2) Can’t let them log on as the database creator.  (3) Can’t reveal the password on the MPEX GOD program.  (4) Can’t reveal the password on DBUTIL. Is there a utility to do this?

Eric Sand replies

To keep things simple, I would just create a “RELEASED” job that can execute DBUTIL with the proper passwords to the DB that you want to examine and direct the output to a file that anyone can read.

The job that wants the locking info would stream this DBUTIL job using the “COMMAND” intrinsic and then parse the output file. This could be done by the “CALLING” program repeatedly if needed and report its findings. Each file could be created unique by composing its name based on a sequential numbering scheme from the results of a LISTF.

Community needs HP support users to test final FTP patch

A new patch to repair a broken command in FTP/iX needs testing now, but the 3000 community must now rely on HP support customers to test HP's lab work. The FTPHDK7A patch repairs the MGET command in the 3000's FTP file transfer program, the industry standard to move files between servers. But like a significant number of HP's 2007-08 lab projects, this patch is trapped in beta-test limbo.

HP's release policy remains unchanged about the patches it's created. Each one must be tested by 3000 owners before the vendor will release the patch to all 3000 sites, even the customers who don't use HP support. The beta-test limbo has seen a lot of patches check in, and far fewer checked out for public release. HP was supposed to be considering reducing the test requirements. But the vendor closed its lab without altering the policy.

OpenMPE has a list of unresolved 3000 issues like this one that HP left behind. MGET isn't critical unless a customer needs bulk transfer of many files in a directory. The bug also existed in last year's HP-UX version of FTP, according to Allegro's Donna Hofmeister. But the HP-UX version of this patch received the tests needed for a full HP release.

Even though HP now has only support division level engineers working on 3000 issues until 2011, nothing is different for the vendor. HP wants to avoid giving any supported customer an under-tested patch. But only HP's support customers can free up this beta-test software. HP won't let the full 3000 community do any beta testing — even after OpenMPE asked to set up a non-customer beta test team.

What's more, HP's engineering load was so heavy last year, the 3000 labs only had enough manpower to create MPE/iX 7.5 patches. FTPHDK7A is only crafted for this latest MPE/iX. At least half the 3000s today are running an earlier release. But even this 7.5-only software needs HP support customers to help the homesteaders.

"If you still have an HP software support contract and are willing to apply the patch -- for the good of the community, frankly -- please call the Response Center," said Hofmeister. Her husband James, who's in the HP's networking support center, discovered the bug last year. "In order for the patch to be General Released, more people need to request and install the patch. Be a good sport and place a call," Donna added.

Until the patch is sprung from beta jail, the GET command, one file at a time, will have to be workaround for FTP. HP had  better reasons for its exacting test process when the community of 3000 users was bigger and patches still rolled out of the lab. In 2009, the policy is a relic, outdated procedure designed to protect HP's liability rather than assist the full 3000 community.

HP helps network 3000s with classless IP

HP is still offering free technical advice for the HP 3000 through its IT Response Center experts Web site. Just this week, an Hewlett-Packard support specialist who moderates the board answered a question about configuring a 3000 for a private network.

You can browse that HP Forum for answers to questions at the MPE/iX Web page. HP's advice might not be any better or worse than a third party support expert's, but at least the vendor is still answering questions from the 3000 community. For example, here's a recent Q&A between a user and an HP Canada networking expert.

How do you configure a /24 IP address using a private 10.x.x.x network? Here's the config we want:

Host IP: 10.140.6.11
Mask: 255.255.255.0
Gateway: 10.140.6.254

Do we need to add anything to the 'Configured Reachable Networks' fields?

HP moderator Emile Kwan Fong said

This is done using the NMMGR program. To configure the IP and Subnet mask, go to the path NETXPORT.NI.<NIname>.PROTOCOL.IP.

Kwan Fong, who's been answering questions for the past eight years on the site, added

To configure the gateway, go to the path NETXPORT.NI.<NIname>.INTERNET. You can leave the the default @ for the "reachable networks" fields. Make sure you validate NETXPORT.

You may want to stop/restart the network or hard boot (start norecovery) the 3000 for the changes to take effect.

PING, IMAGE made easier on 3000

I’m looking for a program that will read IMAGE log files. I know Bradmark has something to analyze these files that I can purchase, but at the present time I really don’t have any money in the budget. What’s available for free?

Cathlene McRae of HP helps out:

CATCHLOG is a good program to use, and it can be obtained at the new Jazz sites. The first one open is at Client Systems: clientsystems.com/hpe3000downloads.html

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

Robert Schlosser says:

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

OpenMPE director Donna Hofmeister adds:

You also need to have INETDCNF.NET configured.

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

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

The samp files are

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

I believe each of the files also has a counterpart in /etc which is a link to the real file in .NET.SYS. If the real files are missing from .NET.SYS then many things (including Telnet and FTP) won’t work.

Ways to Recover a 3000 Password

My operator, in his infinite wisdom, decided to change passwords on MANAGER.SYS.  Of course he forgot, or fat-finger-checked; I don’t know.  At any rate, I need some help.  Any suggestions, other than a blindfold and cigarette?

Chuck Trites offered this solution:

Do you have the GOD program on your system ? If so, it has "SM" capability so it will allow you to do a LISTUSER MANAGER.SYS;PASS=

Duane Percox of QSS added a simpler approach:

If your operator can log onto operator.sys:

file xt=mytape;dev=disc
file syslist=$stdlist
store command.pub;*xt;directory;show

Using your favorite editor or other utility search for the string: "ALTUSER MANAGER  SYS"

You will notice: PAS=<the pwd>  which is your clue.

Plus, Steve Ritenour suggests that a logon to the TELSUP account will unlock the passwords. For some 3000 managers, the subject itself should be filed in a place not easily found. "These responses are all well and good," said Bruce Collins of Softvoyage, "but shouldn't we be thinking twice about posting this kind of information (i.e. how to hack an HP 3000) to the 3000 newsgroup?"

Bill Lancaster of Lund Performance Solutions disagreed. Secrecy about password recovery is not really a secret, he said.

A Google search with the right words will yield far more dangerous information about the 3000 that anything in this thread.  The genesis of this information on the net came through BBS’s in the 1980s. 

I’m afraid the barn door is already open.

IMAGE logging: the poor man's shadow

Tracy Johnson, a business analyst at Measurement Specialties and an OpenMPE board member, suggested recently that the logging feature of the 3000's database IMAGE has powerful potential.

IMAGE logging is a wonderful tool for audit purposes, presuming you have the programs to read them. Ergo, we bought a tool to read our IMAGE logs from MANMAN/HP, and it has proven a remarkable means to establish blame and do finger-pointing.

Johnson's finger is aided by a third-party tool. The HP 3000 environment grew rich and powerful over the past three decades as a result of third-party engineering such as the software from Summit Systems.

David Byrns of Summit Systems, which serves the 3000 manufacturing community but creates all manner of tools for 3000s, explained. "The 3000 Audit Tool that Tracy refers to works on all HP 3000 applications that use IMAGE, not just MANMAN."

The Audit Tool has had a long history of helping 3000 customers. Nearly four years ago we detailed the software's scope in a story written before our current blog went online. We wrote:

Byrns has built a career out of keeping manufacturing companies online and up to date on HP 3000 systems. His latest tool can go to work outside those factories to make SOX compliance easier for the 3000’s lean IT staffs.

“This is my first tool that goes beyond the MANMAN community,” Byrns said. “I wrote this for MANMAN sites, but there’s been a lot of interest from other sites, too.”

Our 2005 article has more details on this tool to empower your HP 3000's logging potential.

Contributed tool spools 3000 output to Word

Michael Anderson, one of the independent support providers and contract developers in the 3000 community, posed a question: How can you get the 3000's spooler output into shape for use in Microsoft Word?

There's an answer among the third party tools, yes; Hillary Software’s product, ByRequest. The product will pick up spoolfiles from the HP 3000 and convert them into Word or Excel format. But what if your 3000 budget is as tamped down as the stock market? You'd be looking for something created by the community.

Dave Powell has your answer. He's built a command file called hp2rtf, tapping the Rich Text Format that's a little-used but powerful bridge for Word document exchange.

Powell recently said

My “hp2rtf” command file will convert spool-file reports that aren’t too fancy into rich text format on the HP 3000 side. Then you can FTP or e-mail to almost any machine with any semi-civilized word processor. Rich-text support is pretty universal. It converts HP page breaks, and more, and has a parameter for font size, which defaults to a size that will let you fit 132 columns on a  page in landscape mode.

You can get hptrtf from Powell by e-mailing him. The software is another candidate for finding a home on that community software server that OpenMPE is assembling.

Who's to mind the CALENDAR?

Last year we took note of the HPCALENDAR intrinsic and its ability to create accurate timestamps for decades to come on the HP 3000. The intrinsic isn't new, though, even though HP advised its customers in November to begin using it on HP 3000s.

No, HPCALENDAR harks back to version 5.5 of MPE/iX. Its power lies in the 3000 for use by programmers who want accurate dates beyond 2038 for application files. But the operating system itself? It continues to use the old CALENDAR intrinsic, which only gives an accurate timestamp to 2027.

Is it foolish to be considering the timestamping ability of a 3000 some 19 years into the future? HP must have thought so while it made technical decisions for this system over the past seven years, knowing the vendor would step out of the 3000 community. You see, HPCALENDAR was never integrated into the operating system itself.

Now, with the 3000's development labs closed down, the community can wonder who'll keep the calendar functions up to date for MPE/iX.

Vesoft's Vladimir Volokh called to update us on the CALENDAR mistake, based on an error we made in our November printed issue. Although I carefully reproduced all of the HP technical details about using HPCALENDAR, a "display quote" on the page didn't get the facts correct"

The newer intrinsic extends the 3000's date accuracy for more than 30 years beyond 2008. 2038 will be the last year to accurately store timestamps.

Actually, it's Unix that's going to lose the ability to store timestamps accurately by 2038. Volokh explained that since HPCALENDAR uses 23 bits to store timestamps, there are 8.3 million places to store a date. If only HPCALENDAR had been wired into MPE/iX, instead of just available for application programmers to use as an intrinsic.

3000 goes in an open direction

More than 11 years ago, HP was teaching HP 3000 skills to the world. George Stachnik, an HP employee who communicated 3000 advantages to customers, wrote a series of articles for HP 3000 newbies. In an early part of his series that started in 1997, he summed up HP's view of the system's future (Where's the HP 3000 Going?) as the company saw it back then.

The evolution of the HP 3000 has been driven by the open systems revolution that swept across the IS industry beginning in the 1990s. By 1990, most new computer applications and technologies were being developed on (and for) Unix computers. This trend threatened to leave proprietary architectures like the HP 3000 out in the cold.

In response, HP began bringing industry standard interfaces from the HP 9000 to the HP 3000, focusing first on functions that were standardized by IEEE’s Posix committees. Version 4.0 of MPE XL was renamed to“MPE/iX” (the iX stands for “Integrated PosiX”). The Posix functionality made it easier than it had been to port software from Unix to the HP 3000. Other industry standards (BSD Sockets, SQL, ODBC, Java) have been brought to the 3000 by HP in subsequent OS releases. All this open systems functionality has continued to be enhanced on subsequent releases.

Of course, that Posix functionality remains in MPE after seven successive releases. HP has not eliminated much from the 3000's feature set after more than 30 years of development. Posix makes the HP 3000 behave like Unix systems. HP was betting in 1997 that this similarity could preserve the system. Even though HP shifted its bets four years later about the 3000, using the Posix shell is a way to get an IT staffer introduced to the 3000 from a Unix perspective.

Consider that this weekend starts the eighth year of 3000 survival after HP changed its bet. Adding Posix may not have had the effect HP intended for the vendor's 3000 business. But it edged the system into open source, which could be a key to surviving another seven years.

It's good to remember how much hope HP projected, as well as how much effort the supplier made, here at the end of the seventh year of The Transition. Keeping the system in growth mode was a challenge too complex for Hewlett-Packard to meet. HP had failures in the past with the 3000, like the abortive System 3000 introduction in 1972.

Stachnik explained how Posix would change interfacing with a 3000 in his article. But he underlined the design choices that make this computer a lasting value for those who are staying with it, as well as those taking longer than expected to leave it.

Many computer vendors say that their systems software is “tuned for transaction processing” but in the case of the HP 3000, this is no idle claim. A tremendous amount of R&D work was done at HP to understand exactly what kinds of stresses are placed on computer systems by commercial transaction processing workloads. And the payoff from this R&D was an HP 3000 that was tuned for the best possible performance.

HP got its payoff in open source applications not long after Stachnik's article, earnings that continue to deliver today in DNS services harder to hack than any "industry standard" system, Samba file sharing and more. It all began with an integration of Unix into the HP 3000, differences Stachnik explained in an accompanying article. Have a look at what he wrote, one of the "3000 for Dummies" lessons which continues to teach, here at the end of the seventh year of migrations. HP was directing this system out of the cold in the 1990s. It's still warm to the touch today.