Checks on MPE's subsystems don't happen
February 4, 2015
Once we broach a topic here on your digital newsstand, even more information surfaces. Yesterday we reported on the state of HPSUSAN number-checking on 3000 hardware. We figured nobody had ever seen HPSUSAN checks block a startup of MPE itself, so long as the HPCPUNAME information was correct. The HP subsystems, though, those surely got an HPSUSAN check before booting, right?
Not based on what we're hearing since our report. Brian Edminster of Applied Technologies related his experience with HP's policing of things like COBOL II or TurboStore.
I can't claim to be an expert in all things regarding to software licensing methods. But I can tell you from personal experience that none of HP's MPE/iX software subsystems that I've ever administered or used had any sort of HPSUSAN checks built into them. That would include the compilers (such as the BASIC/3000 interpreter and compiler), any of the various levels of the HP STORE software versions, Mirror/iX, Dictionary/3000, BRW, or any of the networking software. (I'll note that the networking software components were quite picky in making sure that compatible versions of the various components were used together, in order for everything to work properly.)
The only time I saw HP-provided software examined using the HPSUSAN was when server hardware was upgraded. It checked the CPU upgrades, or number of CPUs in a chassis.
But there's no dissenting story out there regarding what's ethical to do with intent about respecting software checks and licensing. There are always such possibilities for managers who live outside the lines. And sometimes it might be an oversight. As an example, O'Pin Systems -- a first-issue advertiser in the 3000 Newswire more than 19 years ago -- still has Reveal customers out in the MPE world relying on that reporting tool.
One such site was having a hard time with a boot-up on a different MPE/iX server. A START command to Reveal's RSPCNTL will stream a job, but RSPCNTL would terminate before a prompt was given. "I think this may indicate that the product is not validated on the new machine -- which would require re-validation," a former developer for O'Pin told us. "I don't recall exactly what's checked, but the variables HPSUSAN and HPCPUNAME are almost certainly checked for a match. VAR OPINSERIAL will appear to be set to 0, if RSPCONTROL determines that there is a validation fault."
Re-validation can be a matter of placing a call to the vendor's support line -- if there's anyone left on the vendor's staff who understands that the company still has an MPE/iX product in the field. O'Pin has such a support staffer.
Edminster had a cogent comment about this need for this validation during an era when 3000 outposts are shrinking.
I'm don't propose that software purchased for one system be moved to another, unless that's within the bounds of the original software agreements. Just because a vendor has stopped selling a product, or stops pursuing license violations of that product, doesn't make the product freeware.
It also does not make that product yours to use as though you owned it.
Most software was 'sold' with a 'right to use' license. That doesn't mean you own it, now or ever. It means that you are licensed to use it under the terms in the original contract, or as amended since.
That may sound like splitting hairs. But as intellectual property goes, it can make the difference between being able to make a living on the fruits of your work, or not.