February 12, 2020

Adding a naked Seagate drive to a 3000

Seagate Barracuda 31841

James Byrne reported on a way to get a Seagate disk drive to mount in a Series 918. 

We have a 918LX that we are trying to configure as a spare. The unit has three 18Gb disc drives installed, Seagate model ST31841N. We can see the drives in Mapper at 52.56.6/5/4. We can use DISCUTIL to mount 52.56.4 and 52.56.6 — but we cannot get the drive at 52.56.5 to mount.

This problem drive is a new unit just removed from its factory packaging.

Naked Seagate SCSI drives require a low level format to a sector size of 512 for the HP 3000 to mount them. We have a Windows-based tool called Seatools from Seagate that can perform this formatting from a Windows host — at least, from a host that has a suitable 50N SCSI interface card installed.

The same thing can be accomplished by doing a full install of MPE/iX from tape to such a disc. The install of MPE/iX directly to that disk which we could not mount solved the mounting problem.

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

Pivital Solutions: Your complete
HP 3000 resource

February 10, 2020

3000 market maven Charles Finley dies at 70

CharlesFinley_8_2_2013
Charles Finley, whose career in the HP 3000 community spanned eras from powerful regional user group conferences to trusted HP reseller status, then led to new success as a migration maven, has died at age 70.

Finley built a reputation with the community from his first steps in the Southern California 3000 market. Buoyed by the remarkable manufacturing community in the area, by the middle 1980s he was operating the ConAm reseller and worked to establish the Southern California Regional User Group. SCRUG hosted conferences successful enough to rival those from Interex in scope.

Finley also played an essential part in founding an invitation-only MPE developer conference, using a novel format called the un-conference. It delivered information that otherwise would not be presented if only one person were in charge of the agenda. In the early times for groundbreaking tech, the 3000 community had a forum to explore new choices. "Things that could be overlooked like NT, Linux, VMware are noticed, because one person in the group happened to notice it and think it was important," he once said. "The rest of us benefitted by it."

Once HP curtailed its 3000 futures, Finley evolved the ConAm reseller business into Transformix, owned and operated with his wife Deborah. She assumes the post of president of the firm that has created and deploys a migration suite for carrying legacy applications from MPE/iX and other environments applications onto new platforms, especially Linux.

Finley was a Vietnam-era Marine Corps veteran. His widow said the CEO of Transformix delivered his skill and innovation with a duty to the work and the customer.

"Charles was unsurpassed in his passion for the business, his drive for perfection and professionalism, and his commitment to the integrity of customer relationships," Mrs. Finley said. “I saw that every day in the way he spoke about his work."

"This is both a personal and professional loss for many of the people who have known and loved him. Everyone who knew Charles regarded him as a man devoted to his family, his employees, his customers, and his friends."

Condolences may be sent to Deborah via email. The family requests that donations in lieu of flowers can be made to the charity Charles held close: Copley-Price Family YMCA 619.280.9622. Deborah asks to please designate that your donation is in memory of Charles H. Finley, Jr.

The company he leaves in her management is an integration, reseller, and consulting organization specializing in migration of legacy systems to current hardware and software. Transformix is headquartered in San Diego.

Mrs. Finley said the passing was unexpected. Charles Finley is listed as a speaker at next month's SCALE 18X technology conference. His seminar, Transforming Legacy Applications to an Open Source Modern Technology Stack, was the latest in a line of talks at the Southern California Linux Expo.

This year's seminar would "provide attendees with an understanding of the steps involved to transform legacy applications by retargeting them to an Open Source Java Framework. The seminar shows how the CUBA-Platform framework—which was designed for development of modern web application—is also well suited to enhance and extend legacy applications."

Finley was a significant voice in the migration community. While outlining differences between legacy migration, modernization, and transformation,
his experience smoothed the way for legacy applications to use modern technology stacks, including Java.

His SCALE seminar for this year was "a hands-on workshop transforming a legacy application for those who want to know more."

"If you have a PostgreSQL database already, you can generate a working Java web application in minutes using the CUBA-Platform. Moreover, you can do this without knowing any Java! Also of interest is the fact that professional developers and 'citizen developers' can use the platform for development."

Posted by Ron Seybold at 04:41 PM in History, Homesteading, Migration, Newsmakers | Permalink | Comments (0)

February 04, 2020

Chicken, egg: First the 3000's OS, then chips

Rooster
Editor's Note: A technical paper from the DEC world asserted that VMS was the first operating system designed before the chipset that it ran upon. MPE's earliest designs were just as innovative. We asked Stan Sieler for some history.

By Stan Sieler

I'd assume that the 16-bit Classic instruction set architecture and the original MPE were designed at about the same time — probably with the architecture being mostly ready/running (real or simulated/emulated) before the software was ready. Once MPE was up and running, some years later there were arguably one to three architectures designed for it (exclusively or not).    

FOCUS

A group of about 12 of us (labs, chip people, me for the OS lab) designed a 32-bit architecture for the next generation HP 3000.        

The architecture was an evolution of an earlier FOCUS used by Ft. Collins for some HP 9000s (after the 68000 models, before the PA-RISC models), and it (the earlier) was either used by the Amigo (HP 300) and/or was inspired by the Classic 3000 architecture. The project got dropped in favor of the VISION architecture.

VISION        

This was the object-oriented architecture (with 64-bit virtual addressing) that was going to be the next-gen HP 3000, running what was going to be called HPE. We had HP 3000/4x computers with rewritten firmware emulating it, and there were a couple of hand-made real CPU boards beginning to run when I left HP in September 1983 to start Allegro. 

At that time, I had a crude command interpreter running on it under my process management code (I was in charge of process management). VISION was very very interesting.  If I had access rights to an object (say, a record from an IMAGE database with an employee name, a date-of-hire, and other information), I could send another process a "descriptor" (virtual address) that would give them access to precisely the subset I wished (e.g., read access to date-of-hire field of the record). But, that concept is gone now.  No one can do that :(        

VISION was dropped in favor of PA-RISC about a month or so after I left. I commented to Joel Birnbaum that it was dropped because I'd left HP. His reply was, "If I knew that, I'd have gotten rid of you sooner."    

About 1982-1983 I began to hear about an architecture that HP Labs was working on that would allow you to run MPE, RTE, and maybe even HP-UX simultaneously.  It was code-named "Rainbow." I think Rainbow turned out to be PA-RISC.

PA-RISC

In the 1980s, RISC (Reduced Instruction Set Computer) was all the rage. People thought it meant quicker execution due to less complex instructions. I am still dubious. I think they underestimated the types of computations and instruction/memory interactions needed — and, indeed, you can see people throwing more and more and more cache towards RISC in an effort to address the speed imbalance between the CPU and memory.

HPE, essentially an extended version of MPE, was designed to run on PA-RISC. To the extent that the virtual memory (and IO) was quite different, that part of the OS was designed for the architecture.

Most of HPE, later MPE XL, then MPE/iX, doesn't care what the architecture is, any more than  Linux/Unix/Windows cares what the architecture is. I seem to recall that a few aspects of the memory protection mechanism (including the Protection ID registers) may have been influenced by HPE's needs.  

Of course, at the same time, HP-UX was being ported from 68000 / FOCUS to PA-RISC, so there may have been interactions there, as well. Note, however, that HP-UX never fully utilized the PA-RISC architecture — particularly the memory addressability, where HPE / MPE XL / MPE/iX had it beaten by far. I don't think HPE, HP-UX, or Netware (which was on PA-RISC briefly, circa 1993) used all the capabilities, including the ability to, in controlled circumstances, let user code directly access some IO instructions.

Itanium (IPF)  

I think I heard that a basic MPE/iX kernel of sorts had been successfully ported to Itanium before the HP 3000 was killed. Obviously, HP-UX was also ported to IPF.   The primary influence MPE/iX and HP-UX probably had was the Itanium ability to run in either little-endian mode (Intel X86 style for Windows) or big-endian (Class, and PA-RISC style, for MPE/iX and HP-UX).

Other operating systems running on Itanium — which have been released in some cases, not released in others — include Windows, Netware, Solaris, OpenVMS, and Tru64 Unix. This list of systems tends to imply that the architecture was not specifically oriented towards one particular operating system.

In short, I think most operating systems exist (perhaps in an earlier form) prior to the chip architecture, but that most architectures are mostly independent of the operating system design/features. The memory addressability mechanism almost always affects major aspects of the internals of the operating system (as it would with VISION).

Photo by Ashes Sitoula on Unsplash

Posted by Ron Seybold at 04:29 PM in History, Homesteading, News Outta HP | Permalink | Comments (0)

January 30, 2020

Calendar date issues are already surfacing

Hurdles
The 2028 date hurdle for MPE/iX has been well documented and thoroughly discussed. Although the January 1, 2028 deadline — when MPE/iX CALENDAR processes will start to report dates as January 1, 1970, and so on — seems like it's years away, it's much closer. Calendar issues emerge as programs call for dates.

Programs that call for dates in the future are already facing the hurdle. Systems that use Unix, Linux, or other operating systems this month have triggered these involuntary date rollbacks already.

In one recent case, a top 100 pension fund had a nightly batch job that computed the required contributions, made from projections 20 years into the future. It crashed on January 19, 2018 — 20 years before Y2038.

HP 3000s have been key tools in many financial and resource planning operations. While dates are usually used to track transactions as a matter of history, some ERP users look forward to forecast their resource needs.

MPE/iX has a Y2028. Unix and Linux have a Y2038. This is important to know for a legacy system manager's planning and tactics. There's no good reason to tear down a legacy system if its only show-stopping flaw is date handling. A solution for the 3000 community is already at hand in several spots. 

Stromasys reports it has been working with an independent developer for a 2028 fix, something available to its Charon emulator sites. That update was shared with us in July of last year. It's not public yet, but that indie developer confirms the work is in progress. Beechglen has a 2028 solution it is selling as a service.

There are additional developers and consultants who say they're ready to repair 2028 issues with MPE/iX systems. It's important to know that the HP 3000, as one of the older legacy systems still working in businesses, is in no worse shape than systems driven by Linux or Unix. It's only a matter of when, not if, a date handling process will need to be addressed.

The legacy of an operating system is a condition defined very broadly. Legacy systems have been successful for a long time, and the vendor's focus has usually slipped away from these legacies. It can remind us of that term "proprietary" that was hurled at the 3000 for a decade before HP quit on its futures. Nearly all technology has a proprietary aspect, even if it only amounts to a support clause that makes one knowledge resource crucial to the OS health. 

Photo by Interactive Sports on Unsplash

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

January 28, 2020

What good are Nike arrays?

HP NIke Array
By John Burke

3000 users still can employ used HP Nike Model 20 disk arrays. There was once a glut of these devices on the market — meaning they were inexpensive — and they work with older models of HP 3000s. Here's a note from one company using these Nike arrays.

"We’re upgrading from a Model 10 to a Model 20 Nike array. I’m in the middle of deciding whether to keep it in hardware RAID configuration or to switch to MPE/iX mirroring, since I can now do it on the system volume set. It wasn’t in place when the system was first bought, so we stayed with the Nike hardware RAID. We’re considering the performance issue of keeping it Nike hardware RAID versus the safety of MPE Mirroring. You can use the 2nd Fast-Wide card on the array when using MPE mirroring, but you can’t when using Model 20 hardware RAID.

So, with hardware RAID, you have to consider the single point of failure of the controller card. If we ‘split the bus’ on the array mechanism into two separate groups of drives, and then connect a separate controller to the other half of the bus, you can’t have the hardware mirrored drive on the other controller. It must be on the same path as the ‘master’ drive because MPE sees them as a single device.

Using software mirroring you can do this because both drives are independently configured in MPE. Software mirroring adds overhead to the CPU, but it’s a tradeoff you have to decide to make. We are evaluating the options, looking for the best (in our situation) combination of efficiency, performance, fault tolerance and cost.

Note: Mirrored Disk/iX does not support mirroring of the System Volume Set – never did and never will. Secondly, you most certainly can use a second FWSCSI card with a Model 20 attached to an HP 3000

All of the drives are accessible from either controller but of course via different addresses. Your installer should set the DEFAULT ownership of drives to each controller. To improve throughput, each controller should share the load. Only one controller is necessary to address all of the drives, but where MPE falls short is not having a mechanism for auto-failover of a failing controller.

In other words, SYSGEN reconfiguration would be necessary to run on a single controller after SP failure in a dual SP configuration. You could have alternate configurations stored on your system to cover both cases of a single failing controller but the best solution is to get it fixed when it breaks. The best news is that SP failures are not very common.

There is a mechanism in MPE for ‘failover’ called HAFO - High Availability FailOver. It is only supported with XP and VA arrays, and not on Nike’s or AutoRAIDs (because it does not work with those).

Andrew Popay provided some personal experience.

"We have seven Nike SP20 arrays, totaling 140 discs spread across all the arrays, using a combination of RAID 1 (for performance) and RAID 5 (for capacity). We use both SP’s on all arrays, with six arrays used over three systems (two per system). One of our systems has two arrays daisy-chained. The only failures we have suffered on any of the arrays have been due to a disc mechanism failing.

"We never find any issues with the hardware raiding; in fact, as a lot of people have mentioned, hardware raiding is much more preferred to software raiding. Software raiding has several issues, system volume, performance, ease of use, etc. Hardware raiding is far more resilient.'

As for anyone concerned about single points of failure, I would not worry too much about the Nike arrays, I would say they are almost bulletproof. For those who require a 24x7 system and can’t afford any downtime whatsoever, maybe they should consider upgrading to an N-Class, with a VA or XP. Bottom line: SP20’s are sound arrays on the HP 3000s, easy to configure, set up and maintain.

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

January 23, 2020

When the HP Way Led the 3000 Astray

Winding road forest

Editor's Note: Being a legacy system expert has its frustrating days. If experts of today ever wonder why they got into the lifespan of Hewlett Packard and MPE, they can look back to the start and the promise of the 3000. Bill Foster was a part of the HP team that created the system, before he went on to found Status Computing. the story below shows the an HP which had to remake MPE.

All the Foster you want, in an HP history worthy of being a book, is at his website.

By Bill Foster

If there ever was a company that always seemed to do the right thing, it was HP back in the 70’s. We had a term called The HP Way. There was no written definition — it was something you felt. When something good happened it was part of The HP Way. When you had the inclination to do something bad — cut corners on a project, treat a customer badly, turn in an inflated expense account, fire a really bad employee — these things didn’t happen. They were not The HP Way. It’s like we walked around with little halos over our heads.

Of course, if this was the only place you worked, you assumed all companies were like HP. You had to leave Hewlett Packard to become a part of the real world. So, we shipped HP 3000 serial #1 to the Lawrence Hall of Science in nearby Berkeley. A couple of weeks later they shipped it back. That 3000 could support at most two or three users on a good day -- nowhere near 16 or 32 or whatever they promised.  And MPE was crashing three or four times a day.

A few months and a couple of machines later HP punted and withdrew the 3000 from the marketplace. They gave free 2116 computers to the customers in hopes of appeasement — The HP Way. Bill and Dave were fuming -- this had been by far the most expensive project in the company’s history, and Hewlett Packard was being inundated with bad press — something that had never happened in the entire history of the company.

In fairly quick succession Paul Ely came down to save things and a few months later my boss Steve Vallender left. I don’t think Steve was fired — HP never fired anyone back then, they just promoted them into oblivion. But Steve was somewhat un-promotable — he lacked a college degree and HP was pretty snobbish about that.

Dick Hackborn asked me if I wanted Steve's old job. Are you kidding? Sure! Hurt me! I was looking to move up the ladder — this was a fantastic break. My guess was they chose me over my hardware counterpart because management finally figured it was better to put a software guy in charge of computer projects. No matter -- here I was, not even 30 years old, running all the hardware and software development for HP's computer business.

My first and most important job was to come up with a plan for the hockey pucks.  A year earlier, Dick Hackborn had hired a couple of smooth-talking marketing bozos out of IBM. Hackborn created a group called Product Marketing within his Engineering group to compete with the real Marketing group at the other end of the building.

This was very out of character for HP — to hire senior people from the outside. One of their first actions was to give mementos of a project to the engineers who had developed it — something tangible to remember their efforts. Apparently this was done all the time at IBM. The IBM marketing bozos came up with the idea of a brass paperweight about the size of a hockey puck, but about half the thickness. Stamped on each one were three overlapping circles signifying batch, realtime, and timesharing — things that the 3000 was supposed to do.  And each individual’s name was engraved on the back.

These were supposed to be handed out months earlier, but with all the problems, Vallender had hidden them away in a file cabinet. My first command move was to sneak in one weekend, lug them out to my car, and take them home to my garage.  The last thing I wanted was for anyone to get wind of them. The next step was to try to get some kind of usefulness out of the 3000 machine, and that meant fixing MPE.

Image by David Mark from Pixabay

Posted by Ron Seybold at 05:36 PM in History, News Outta HP | Permalink | Comments (0)

January 21, 2020

Using RAID5 on an HP 3000

Hard-Drive
By Gilles Schipper
Homesteading Editor

RAID storage, including a low-cost MOD20 array, can improve a 3000's performance. Here are a few things to consider if you will be acquiring a MOD20.

Although possible, I would not recommend utilizing RAID5 LUNs in an HP 3000 environment — unless your greatest priority is to maximize disk space availability at the expense of performance.

RAID5 offers fail-safe functionality over a group of disks (minimum of three) by means of one disk of the RAID5 disk being allocated as a parity disc. The benefit of RAID5 over RAID1 is that it results in a greater amount of overall usable disk space than RAID1. However, it performs poorly in an HP 3000 environment, and cannot be booted from if specified as the system disk (LDEV 1).

Although the supported maximum memory configuration of each Storage Processor (SP) unit is 64MB, 128MB works best (although not all of it can be used).

Each SP has 4 memory slots. You can maximize the performance of the MOD20 by populating each SP with four 32MB memory SIMMs, 72-pin, FPM with parity, 60ns.

The NIKE MOD20 is a very capable and useful solution to the fragile environment afforded by a JBOD environment — particularly because most 3000 JBOD disk systems tend to be very mature and consequently relatively unreliable and prone to failure.

And, although the MOD20 disk system itself is also quite long in the tooth, it’s got built-in fail-safe mechanisms. Also, the MOD20 would appeal to those with very limited budgets, since the devices are quite inexpensive in the used-equipment market.

There are other, more advanced RAID systems that also support the HP 3000 environment. These include the HP Autoraid12H system, various VA7400 systems, some of the HP XP-family members, as well as EMC systems. This list is in order of increasing cost, for the most part.

The bottom line: if you are not already utilizing RAID technology for your 3000, now would be a good time to consider it seriously.

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

January 16, 2020

MPE/iX Command File Scripts Explained

Code on screenBy Ken Robertson

The MPE/iX command interpreter has a generous command set, pushing the shell into the realm of a true programming tool. Its ability to evaluate expressions and to perform I/O on files allows the end-user to perform simple data-processing functions. The CI can be used to solve complex problems. Its code, however, is interpreted, which may cause a CI solution to execute too slowly for practical purposes.

Command files are a collection of commands in flat files, of either variable or fixed length record structure, that reside in the MPE or POSIX file space. Basically, command files are what you could call MPE Macros. Anything that you can do in the CI interactively, you can do with command files, and then some. You can use command files in situations that call for repetitive functions, such as re-compiling source code, special spooler commands, etc. Command files are also great when you want to hide details from the end-user.

A command file is executed when its name is typed in the CI, or invoked from a command file or programming shell. Just as in program execution, the user’s HPPATH variable is searched to determine the location of the command file.

MPE Scripts Versus Unix Scripts

For the average task, the MPE scripting language is easier to read and understand than most Unix scripts. For example, command line parameters in MPE have names, just like in regular programming languages.

Of course, there are several script languages on Unix and only one on MPE! On Unix you can write shell scripts for any of the many shells provided (C shell, Bourne shell, ksh, bash, etc). Although there is also now a Posix shell on MPE, most scripts are written for the CI. Several third-party tools, such as Qedit and MPEX, emulate HP scripting and integrate it with their own commands.

A command file can be as simple as a single command, such as a Showjob command with the option to only show interactive sessions (and ignore batch jobs):

:qedit
/add
1      showjob [email protected]
2      //
/keep ss
/e
:

You have created a command file called SS — when you type SS you will execute showjob [email protected]

On MPE, the user needs read (r) or execute access (x) to SS. On Unix you normally must have x access, not just r access, so you do a chmod +x on the script. This is not necessary in MPE, although, if don’t want users to be see the script, you may remove read access and enable execute access.

Structure of a Command File (aka CI script)

A script is an ASCII file with maximum 511 byte records. Unlike Unix, the records may contain an ASCII sequence number in the last 8 columns of each line. The command file consists of 3 optional parts:

1. Parameter line with a maximum of 255 arguments:
parm sessionnumber
parm filename, length=”80”

2. Option lines:
option nohelp,nobreak
option list

3. The body (i.e., the actual commands)”
showjob job=!sessionnumber
build !filename;rec=-!length,,ascii
In MPE scripts, there is no inline data, unlike Unix ‘hereis’ files.

Parameters

Notice in the example above that parameters are used with an exclamation (!), as opposed to the $ in Unix. The same is true for variables. Parameters are separated by a space, comma or semicolon. All parameter values are un-typed, regardless of quoting.

In a typical Unix script, the parameters are referenced by position only ($1, $2, $3, …). In an MPE script, the parameters have names, as in the function of a regular programming language, and can also have default values. In Unix you use [email protected] for all of the parameters as a single string; in MPE you use an ANYPARM parameter to reference the remainder of the command line (it must be the last parameter).

Here is a script to translate “subsys” and “err” numbers from MPE intrinsics into error messages. The subsys and error numbers are passed in as parameters:

parm p_subsys=108,p_error=63
setvar subsys hex(!p_subsys)
setvar error hex(!p_error)
comment the hex conversion allows for negative numbers
comment the #32765 is magic according to Stan!
setvar cmd “wl errmsg(#32765,!subsys);wl errmsg(!error,!subsys);exit”
debug !cmd

As you can see above, the Setvar command assigns a value to parameter or to a new variable. But there are also system pre-defined variables. To see them all do Showvar @;hp. To get information on variables, do help variable and to get help on a specific variable, say hpcmdtrace, do help hpcmdtrace (set TRUE for some debugging help).
In most MPE commands, you must use an explicit exclam ! to identify a variable: build !filename

However, some MPE commands expect variables, and thus do not require the explicit !. For example, Setvar, If, ElseIf, Calc, While, and for all function arguments, and inside ![expressions].

Warning: variables are “session global” in MPE. This means that if a child process, or scripts, changes a variable, it remains changed when that child process terminates. In Unix you are used to the idea that the child can do whatever it likes with its copy of the variables and not worry about any external consequences.

Of course having global variables also means that it is much easier to pass back results from a script! And this is quite common in MPE scripts.

Options

Options allow you to list the commands as they are execute (option list), disable the Break key (option nobreak), enable recursion (option recursion), and disable help about the script (option nohelp).

The script body below shows active process information. This example shows many of the commands commonly used in scripts: If, While, Pause, Setvar, Input and Run. Other commands you will see are Echo, Deletevar, Showvar, Errclear.

WHILE HPCONNSECS > 0
    IF FINFO("SQMSG",0)
       PURGE SQMSG,TEMP
    ENDIF
    BUILD SQMSG;REC=-79,,F,ASCII;TEMP;MSG
    FILE SQMSG=SQMSG,OLDTEMP
    SHOWQ;ACTIVE >*SQMSG
    SETVAR PINLIST ""
    WHILE FINFO("SQMSG",19) <> 0
         INPUT SQLINE < SQMSG
         IF POS("#",SQLINE) <> 0 THEN
           SETVAR PIN RTRIM(STR(SQLINE,47,5))
           SETVAR PINLIST "!PINLIST" + "," + "!PIN"
         ENDIF
    ENDWHILE
    IF FINFO("SPMSG",0)
       PURGE SPMSG,TEMP
    ENDIF
    BUILD SPMSG;REC=-79,,F,ASCII;TEMP;MSG
    FILE SPMSG=SPMSG,OLDTEMP
    SETVAR PROC "SHOWPROC PIN="+"!PINLIST"+";SYSTEM >*SPMSG"
    !PROC
    WHILE FINFO("SPMSG",19) <> 0
         INPUT SPLINE < SPMSG
         IF POS(":",SPLINE) <> 0 THEN
           ECHO !SPLINE
         ENDIF
    ENDWHILE
    PAUSE 30
ENDWHILE

Handling Errors

In most Unix scripts, if a step fails, you check for an error with an If-conditional and then take some action, one of which is ending the script. Without an If, the script continues on, ignoring the error.

In MPE, the default action when a step fails is to abort the script and pass back an error. To override this default, you insert a Continue command before the step that may fail. You then add If logic after the step to print an error message and perhaps Return (back 1 level) or Escape (all the way back to the CI).

     continue
      build newdata
      if cierror<>100 then
         print "unable to build newdata file"
         print !hpcierrmsg
         return
      else
         comment - duplicate file, okay
      endif

You can set HPAUTOCONT to TRUE to continue automatically in case of errors, but this can be dangerous. The default behavior at least lets you know if an unexpected problem occurs.

User Defined Commands (UDC)

UDCs are like Command File scripts, except that several are combined in a single “catalog” file. They are an older feature of MPE, so you may see them in older applications even when scripts seem like a better solution. The primary reason that they are still useful is that they support Option Logon, which invokes the command when a user logs onto the system.

More Information

Tim Ericson’s collection of UDCs and Command files has recently been resurrected and re-published in the public domain at www.3kassociates.com/index_cmd.html

Image by fancycrave1 from Pixabay

Posted by Ron Seybold at 08:42 AM in Hidden Value, Homesteading, Newswire Classics | Permalink | Comments (0)

January 14, 2020

Listserv still serving advice after 26 years

Bank vault safety deposit boxes
The 3000-L Listserv repository is the HP 3000 resource that's been in the longest continuous use for the MPE/iX ecosystem. HP had a Jazz website for about 13 years, content that was carried over to Fresche Legacy's servers once HP's labs closed. 3000-L was online for about a year or so before the NewsWire entered the Web.

The content on the 3000-L was a big reason I believed we could do a monthly HP 3000 newsletter. We curated and learned, education and advice we shared with readers. Even after 26 years, 3000-L can be searched for answers that go back to the era of MPE/iX 4.0.

That repository is full of history about the people who have created the MPE ecosystem, too. with enough patience, most answers will be hiding in the hundreds of thousands of email messages. All are logged by subject line. 3000-L can be searched within date ranges, too.

3000-L was once so robust that we could publish a column about its gems once a month as part of the first 10 years of the NewsWire. 

The columns are archived in our 1996-2005 pages. We called them NetDigest, and for awhile they were written by John Burke, who helped us found the NewsWire with his knowing voice and deep technical experience.

For the source material for those columns, refer to the 3000-L search panel.

For the columns, refer to the Tech Page of the '96 - '05 issues. Once you arrive at the Tech Page, just do a search within the page for the phrase net.digest. We've got 106 columns there.

Photo by Jason Pofahl on Unsplash 

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

January 09, 2020

How to Encrypt 3000 Log-on Passwords

Padlock
NewsWire Classic

Is there a way to encrypt MPE logon passwords to keep auditors satisfied that the HP 3000 is secure? We need to show that they cannot be easily read with the ;pass parameter (i.e. listuser xxx.yyy;pass)

The replies generated one of the longest threads of the month on the 3000-L.

Tracy Johnson offered an opinion that “the answer to your auditors is not in encrypting passwords. The answer lies in restricting AM and SM capability to only those key personnel who can use the the “;pass” parameter within established policy. AM and SM capability also presumes the same capability to change another user’s password, and therefore also the ability to look it up.”

Chris Boggs reported in a virtual testimonial that “Our auditors were not satisfied by even limiting SM and AM capabilities to only two individuals (both in our department). Since we had Vesoft's Security/3000 already, I changed our regular logon ID’s to use the Vesoft password which is encrypted.

"There are other features in Vesoft security which are handy when dealing with auditors such as password obsolescence, password “history,” minimum password standards, inactivity logouts, day/time restrictions, automatic deactivation of logonID’s after a certain number of failed logon attempts, and probably a few others.”

Bradmark’s Jerry Fochtman said some Interex Contributed Software Library routines can help. “I developed a routine to return the passwords for user/group/account (based upon caller’s capabilities) during this time. It also signaled if the password was encrypted, simply returning blanks in this case. There was another routine which given a password, would encrypt it based upon HP’s approach and tell the caller if the entered password matched the one in the system directory.”

Fochtman also took note of the Vesoft abilities and added his humble opinion on the security solution from Monterrey Software, “SAFE/3000. It also utilizes one-way encryption for its passwords. And in terms of strictly security, it is a better tool in several areas, such as network security.”

Michael Gueterman, whose company Easy Does It Technologies does pre-audits for 3000 sites, added notes on using only session-level passwords.

“That’s fine for some things, but I still recommend keeping at least MPE Account passwords in place for all but the most “open” areas. For accounts with SM or PM, I also recommend MPE User passwords as well. Also, when at all possible, explicitly define what people are ALLOWED to access, instead of using generic wildcards. Wildcards make auditors unhappy, and an unhappy auditor is dangerous!”

Image by meineresterampe from Pixabay

Posted by Ron Seybold at 03:41 PM in Hidden Value, Newswire Classics | Permalink | Comments (0)

Search