« October 2019 | Main

November 21, 2019

Values hidden by time get revealed by vets

Brass treasure key
Photo by Michael Dziedzic on Unsplash

Twenty-four years ago we started unlocking Hidden Value for HP 3000s: Commands that only the veterans know, plus the processes that have been plumbed to bypass MPE's blind alleys.

Some of the value is specific to a 3000 process like using EDIT/3000. It's antique, that editor, but it's on every HP 3000.

I use cut and paste with EDIT/3000 to enter data to batch files.  It works well except that I am limited by the size of the scratch file. Can I change the size of this file so I can paste more at a time?

Immediately after entering Editor, enter "set size=######" to give yourself more space.

For other tasks, like finding forgotten passwords, and keeping them fresh and the 3000's data secret, more elaborate answers have surfaced.

A system manager pitched his plight.

"My operator, in his infinite wisdom, decided to change passwords on manager.sys.  Of course he forgot, or fingerchecked... I don’t know.  At any rate I need some help. Any suggestions, other than a blindfold and cigarette?"

Several versions of help involved the use of utilities from security experts VEsoft. "Do you have the GOD program on your system? If so, it has PM capability, and so it can give the user who runs it SM capability. So it will allow you to do a LISTUSER MANAGER.SYS;PASS=

(That's why GOD should be secured, by the way. A randomized lockword will do the job, visible only to users who have SM capability. When VEsoft installs MPEX, for example, it installs a randomized password to MGR.VESOFT, and to GOD.PUB.VESOFT.)

Paul Edwards, ever a source for HP 3000 training, ran through the backstop methods every system manager should practice to avoid such a dilemma.

1. You run BULDACCT prior to each full backup so you can look in BULDJOB1 for the passwords 
2. You have another user on the system with SM capability and a different password as a backup in case this happens  
3. Your operator used LISTUSER MANAGER.SYS;PASS just after changing the password to verify the accuracy as spelled out in the Operations Procedures section in your Systems Manager Notebook   
4. You have a Systems Manager Notebook

  Then Duane Percox of K-12 app vendor QSS opened up a clever back door:

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=

, <passwd> which is your clue

12:25 PM in Hidden Value, Homesteading | Permalink | Comments (0)

November 19, 2019

Keep Passwords Fresh on 3000s: Methods

Fresh bread
Photo by Clem Onojeghuo on Unsplash

It's usually a good practice to keep passwords fresh. A 3000 development manager once posed a question about how to do this while staying inside the bounds of MPE/iX. He had the usual limited budget associated with HP 3000 ownership.

"Management wants users to be forced to change their passwords on a regular basis. Also, certain rules must be applied to the new password. I don't have budget for the good tools for this, like Security/3000, so I need to write something myself, or see if there's any contributed code to do the job."

Homegrown and bundled solutions followed. When Jeff Vance worked in the 3000 lab at HP, he offered the pseudo random password generator as a solution. It's in the HP Migrations webpage hosted on the website of the company formerly known as Speedware. These HP Jazz solutions that used to be on the HP website are still available at Fresche Solutions.  

There are UDCs on Jazz which force a password to be supplied when using NEWUSER, NEWACCT and NEWGROUP CI commands. These required passwords can be random (uses the script above) or user entered with a minimal length enforced.

Then Vance added as an afterthought, a strategy to program your own password system:

I haven’t thought about it much, but it seems you could have a password file (maybe a CIRcular file?) for each user on the system. This file would have their last N passwords, and the modified date of the file would be the date their password was most recently changed.

A logon UDC could detect if the password file for that user exists. If not create it and require a new password right then.  If the password file exists then get it’s modified date and compare that to today’s date. If greater than X days then in a loop prompt for a new password. Validate the entered password against previous N passwords and your other rules. Maybe run a dictionary checking program to make sure the password is not common, etc.

Update the user-specific password file with their new password, and then logon the user.

From the user community, Donna Hofmeister weighed in with this advice:

If you have no choice other than to develop your own software, then I’d certainly model it after what VEsoft has already done. That is:

Based on a system-wide UDC, examine all sessions (it is just sessions, yes?  By the way, a DSLOGON from inside a job is still a session....) against a ‘database’ (By the way, just how secure is this database?  A real database needs passwords... Who’s going to maintain that? A flat file could be lockworded... but that’s not a slamdunk answer.) which is looking for the ‘age’ of the password (By the way, are you going to provide an advance warning period?). 

If it is time to change the password, get the ‘new’ password from the user... but writing the rules is a pain, and keeping track of reused passwords is just annoying. Auditors in the states love when you can say the password is one-way encrypted.  Dunno what your management is saying for encrypting an MPE password.

Dave Powell coded up a solution in a contribution.

It ought to be possible to do everything for free, using just MPE.  Editing the new password is the ugly part, but if you randomly assign it that issue goes away. The next issue is that the :password command seems to like to be purely interactive, as in:

echo oldpass >> tempf
echo newpass >> tempf
echo newpass >> tempf
:password < tempf
password
Command not allowed in noninteractive environment. (CIERR 2500)
PASSWORD WAS NOT CHANGED.

That leaves the altuser cmd, which needs AM cap.  If you don't want a background job (like Paul's suggestion), you can have the command file (called by  your logon UDC) use the echo command to build job with AM cap, which it then streams, kind of like (untested, but I have working examples of cmd-files building other jobs):

ECHO !!JOB ACCTMGR/PASS.SOMEACCT; HIPRI  >> TF
ECHO !!ALTUSER !HPUSER;PASS=!NEW_PASS >> TF
ECHO !!SETVAR STREAMED_BY   WORD(HPSTREAMEDBY,"()",2) >> TF
ECHO !!TELL !!STREAMED_BY Your new password is !NEW_PASS >> TF
ECHO !!EOJ >> TF
STREAM TF
ECHO Please note your new password when it appears
PAUSE 99; JOB = !HPLASTJOB
PURGE TF, TEMP

If I haven't screwed up the fine print too badly, this code in the middle of the password cmd-file runs the job that changes your password, then waits for the job to tell you what the new password is.  The single exclamations before HPUSER & NEW_PASS mean that values that are variables to the session and command-file become hard-wired values for the job.

Before all this your cmd-file checks the date, gets a random password, etc., as posted by others.  After it the cmd-file writes (or just builds) a file that serves as a timestamp.  But I am not too comfy with putting the passwords into a plain-text file, so I might skip that part (remember, the user needs both read and write access to it).  Put the command file in a group that users have xeq access to, but not read/write access.

12:27 PM in Hidden Value, Homesteading | Permalink | Comments (0)

November 14, 2019

Welcome to Year 19 of the Afterlife

Cheated Death on printer
You remember where you were, perhaps, on the day you learned Hewlett-Packard was done with MPE/iX. You might have been in a meeting, or checked your email before heading home. You might have been installing something a 3000 needed to keep serving your company, or even ready to order a new server to replace the old 9x8 box. Some unlucky vendors were holding orders for new systems.

People did all of that and more on the day HP revealed its 3000 era was on its way to a finish. By 2003 the community was calling the new era The Afterlife. The lifespan of building new HP 3000 hardware was ended when a box rolled off the line at the Roseville plant in early November that year.

Afterlife shirt

And so, on November 14 of 2001, the afterlife of Hewlett-Packard's lifetime started with dismay, anger, and then resignation. The five stages of death proceeded through discussions in a lively 3000 newsgroup. Taking a cue from the horrors of 9/11 in that season, programmers and vendors howled about the relatively unimportant death in their lives.

Doug Greenup was leading Minisoft in that November week. The CEO of a software company whose products were on thousands of systems, he became aware of the HP pullout with just one day's notice.

Alvina Nishimoto from HP called me. She was in charge of third parties with HP at the time. She asked me to sign a non-disclosure which she'd just faxed me. She said she had important news. I signed it and faxed it right back. She called to tell me HP was announcing they were discontinuing the HP e3000, and that HP-UX was their future direction.

HP might have been worried the story was going to get into the world without its influence. The news had been roiling through the 3000 community for more than a week before I learned about it. Wirt Atmar, the founder of AICS and a 3000 stalwart, threw off the lid about the pullout by posting on a developers' mailing list.

I spoke to two of our oldest, most trusted customers yesterday, one a ten-year customer and the other 15 years, about this upcoming announcement. Their first reactions were that it simply sucked their breath away. When I told them about HP's proposed plans of migrating their applications to HP-UX — which as an option has all of the practicality to them of trying to establish a penguin colony in Death Valley — their second reaction was "the hell with HP. If we move, it will be to anything but HP." I think that that's going to be the general reaction.

HP learned a great deal about ending a product line with the lessons that began 18 years ago. Earlier this year the company made a graceful transfer of responsibility for OpenVMS, sending the software as well as support opportunities to an independent firm, VMS Software Inc. HP won't sell any more OpenVMS licenses, although it continues to build Itanium servers that will run the apps created for that OS.

This was a vision that the HP 3000 community took to heart during the first of the 18 years that followed. A similar group of OS experts, organized and led by Adager, wanted HP to transfer the future of MPE/iX to new, independent stewards. HP didn't know how to do this in 2001 or in 2002. The offer took another form in the OpenMPE advocate organization, but eight more years had to slip past before HP's source code made its way into independent software labs.

A new history began 18 years ago, a record of a group of computer customers who kept their own counsel about walking away from a corporate computing asset. The next two years or so will show HP Enterprise customers what might have been possible had MPE/iX found a third party home. VSI is predicting that it will have production-grade OpenVMS ready for a late 2021 release on Intel hardware.

This is more than a shift away from the HP Enterprise resources. VSI is carrying OpenVMS to a new chipset, a commodity home. In 2001, Atmar told HP's business manager for 3000 operations, Winston Prather, such a move was what the 3000 customers deserved.

Opening MPE up and migrating it to an Intel platform offers at least some real hope for a continued and bright future for MPE. More than that, it keeps a promise that most customers believe HP has made to them, and that is very much the nub of the moral and ethical question
that faces you now, Winston.

Migrating MPE to Intel hardware would have permitted MPE to run on inexpensive but high-quality servers. Earlier this month, VSI announced a timeline for such a thing to happen with OpenVMS. A different HP paved the way, perhaps chastened by the past, than the corporation that launched the afterlife. In the beginning, the launch of the server took place in this month. The slogan in 1972 was "November is a Happening." Nothing can change what happened nearly 30 years later, but the decisions over what to do with a loyal enterprise customer base have changed in the years since 2001's happenings.

08:03 PM | Permalink | Comments (0)

November 12, 2019

Customized code care can add time to apps

Sewing spool and scissors
Image by TooMuchCoffeeMan from Pixabay

Almost all MANMAN sites have the original ASK FORTRAN source code, but a few have lost track of some of their mods. It seems hard to believe for some analysts, but source code for applications can go missing, too.

It's easier to believe while considering the age of this software. A 3000 which first booted up a manufacturing site for TE Connectivity in 1978 recently got powered down for the last time. The software had outlasted a half-dozen servers, until finally the need lapsed for a host of an application launched 40 years ago.

TE has its source code for every 3000 instance it continues to run to manage manufacturing across North America and Asia. You can imagine, though, how much care it takes to keep that corporate asset in good working order from the era before PCs until today.

Managing the modifications is the other essential piece of the lifetime-extending effort for MPE/iX ERP solutions. No app suite is as often customized as ERP; the term itself is an extension of the Manufacturing Resource Planning of the 1980s. What was once MRP is now ERP. The planning always needs custom code, tailored to the business processes.

Terry Floyd, the founder of MANMAN support resource The Support Group, said most MANMAN sites — and there are under 100 by now — own and manage their own source code for the main application set. His company deals with modifications for its clients, too. Without the mods, using such apps is a matter of being frozen in time for features. It's like trying to take out a pair of pants without enough material.

09:54 AM in Homesteading | Permalink | Comments (0)

November 07, 2019

What MANMAN sites didn't know until now

 
Just this week I sat in on a call among MANMAN users. There were not a lot of them, but 20 people dialed in or opened a GoToMeeting for a conference call. Regional Users Group meets have disappeared except for the Computer Aided Manufacturing User Society. Unlike some 3000 owners and managers, CAMUS still has something to talk about.
 
The discussion topic is change. Here in 2019, CAMUS users manage HP 3000s that continue to manage manufacturing. That situation will change sooner or later. Manufacturing software is wired in deeper to a company's nervous system. Enterprise Resource Planning (ERP) can apply to many MPE/iX shops. ERP has the longest lifespan of any application package.
 
Not long ago, an ERP system was shut down at TE Connectivity. TE is probably the biggest customer by number of ERP 3000s. The system that was powered off for good hosted software that had been running since 1978. Other ERP instances there, not as old, continue to run.
 
Forty years. One operating environment. A legacy within a legacy community. In essence, though, just the longest lived veteran in a room of greybeard application suites. The shutdown didn't even come up during the RUG call.
 
The meeting was organized by the CAMUS president Terri Lanza, who led the discussion. One of the more interesting parts was the group’s take on Infor support. The vendor's dropping support altogether for MANMAN customers next year. Some customers on the call were just learning that Infor's support verdict has been out since 2018. 
 
Support disappearances are not exactly news in the 3000 world. This strategy by Infor, though is notable. It's perhaps the last departure from an application vendor.
 
That might be due to the number of MANMAN sites still paying Infor support fees. Nine, in all, and that was as of last year. Revenue from support is the canary in the mine shaft for vendor decisions like this.
 
Infor is closing down an operation for MPE/iX that had been available in name only, if the RUG's intel is accurate. In less than a year, even the backup to the best engineers will be working on something else. By May, the app will stop being sold or supported. Go-time for software that's free, right? Not so fast there. The 3000 community has been through this before.

Hewlett-Packard [now called HPE, for the Enterprise half of HP] had 3000 owners hopes in the balance when it first announced it was ending its MPE and 3000 business. A seasoned and well known database tool vendor marshaled financing, enough for a reasonable offer to take over the OS and the hardware.

HP said no, despite being so tied to that vendor that the third party product was on HP's own corporate price list. When it's over at a vendor, it's over. The MPE community proved over the next 15 years that they'll decide for themselves, one site at a time, when things are over. 
 
People on the call had a lot of assumptions and some misinformation about how their application code licensing was going to change — because Infor is stopping all sales. "Here comes open source," or "we can do whatever we want with it" were heard. Neither is true unless Infor does what HP could not do in 2002. MANMAN is still not released into the wild, as far as legal is concerned.
 
There was also some comparison to the license holders of the MPE source code. It is misunderstood, sometimes, that license arrangement. Every line of nearly all MPE/iX routines sits wide open on servers at seven license holders. The database tool vendor Adager, support companies like Beechglen and Pivital Solutions, plus four others can see every line.
 
They can't rebuild the OS, though, or add features within it. The superpower of source is important, a distinguishing feature for these Super Seven. They can solve support problems like nobody else can. Beechglen thinks enough of its source license that Doug Werth said on that call it's a significant part of their software that can carry a 3000's date operations up to 2038.
 
Who in the world would be using MANMAN in 2020? Companies that have their software set up for the very long run. Customers who need the app vendor so little that when Infor reported their clock would run out next year, nothing would change. Some MANMAN sites still standing have their source code just as much as the Super Seven have MPE.
 
Other sites do not, and the news about 2020 arrived just this week for them.
 
The situation looks good for the sites that have MANMAN source. For awhile, MANMAN's creators ASK sold the app with source. It was a different era in the 1970s.
 
Terry Floyd of the Support Group, who has serviced MANMAN sites as a first-line resource for 25 years, said everything but two routines is available for the ERP suite owners to modify as they wish. And if they own their source code, it's 100 percent. That's a better arrangement than MPE's existence inside those support and database companies.
 
ERP does that: it just runs for decades, given community help. A RUG group meeting in November of 2019 fits with that situation like an elderly strongman's grip inside weightlifting gloves.

01:34 PM in Homesteading | Permalink | Comments (1)

November 06, 2019

HP's tech lures Xerox offer to buy

HP printer tech
Photo by Dario Seretin on Unsplash

Plenty of writers and customers get confused about the HP of 2019. Back in 2014, the corporation split into two units, operations that align on devices and datacenters. Hewlett-Packard Enterprise now sells datacenter products and services. It's the arm that created HP 3000s in the 1970s. HP Inc., the part of the company that makes printing, imaging, and PC products, received an offer this week to be purchased by Xerox.

HP Inc. acquired 55 patents from Samsung for business printing not long ago. Now the corporation is being courted by a suitor whose printing legacy is wired deep into the DNA of Hewlett-Packard's spinoff. Patents for LaserJet tech, the engineering that in 1984 took HP into the realm of resellers farther removed from HP than any 3000 VAR, are part of what Xerox is bidding for.

The offer, which HP Inc. confirmed it has received, would sign up Xerox for more than $20 billion in debt, financed by Citigroup. The appetites of the HP which created the 3000 and then cut down the vendor's future in the MPE/iX market helped to spark that 2014 split. HP was striving for an overall Number One status as a technology supplier in the years just before it announced its takedown of its 3000 business.

Management at the vendor aligned on growing sectors of business. While the 3000 had enjoyed a nice revenue increase for several years leading up to Y2K, HP saw the unit as one whose growth had a limited future. "If it's not growing, it's going," one 3000 vendor said he'd heard in reports about HP's future.

This was in the era when PCs were soaring on the HP balance sheets and printer products were being sold in groceries. The corporation had just acquired Compaq and Compaq's Digital group, so while there was a future for OpenVMS and its growth, cutting back on enterprise products became essential in HP's strategy.

Xerox developed the first viable graphical interface technology in its Star systems. The Palo Alto Research Center's tour for a young Steve Jobs at Apple led to the mouse interface becoming an essential part of the Macintosh release. 

In a move that proves there's always value in technology that outlasts its creators, there's now a deal in the market to return some of HP business technology to a corporation that's been a part of business computing history since the 1980s. It can be hard to tell what's going to survive in computing and where it will land. HP Inc. recently announced it will be cutting 9,000 more jobs. Betting on good management is at least as important as betting on good technology. As 3000 owners know, technology like MPE/iX is able to outlive the interests of its creators.

05:46 PM in History, News Outta HP | Permalink | Comments (0)