HASPASP JESJES2JES3 2391

previous posts

past posts mentioning hasp

370 was initially announced w-o virtual memory and address relocate. basically 360 genre of operating systems continued to run. the low-end and mid-range machines tended to be microcode upgrades ... however real hardware field upgrades had to be purchased and installed on customer 370-155 and 370-165 (and weren't cheap).

the full 370 architecture was in the 370 architecture "redbook" ... distributed out of architecture group in pok in dark red 3-ring binder. early on this was in cms script ... and the principle of operations was a subset ... depending on which option at command invokation, you printed the full architecture book or the principle of operations subset.

the hardware upgrades to 155-165 were fairly expensive & extensive. I remember virtual memory hardware resolution meeting in pok ... the 165 engineers wanted to drop some of the features in the 370 virtual memory architecture (specifically selective invalidate instructions). Their position was that to do the selective invalidate instructions would add six month elapsed time to the engineering work, delaying the corporate announcement of virtual memory for 370 by 6m. the batch virtual memory operating systems (primarily vs2) said that they didn't care ... vs2 would never, ever domore than five page i-os per second ... and the page replacement algorithm would batch those page replacement selections apporx. once per second. The difference between doing a single FTLB once per second or five selective invalidates once per second was negligible.

i also remember getting 3rd shift in pok machine room for some work ... and ludlow(?) and some others working on the prototype for SVS ... basically they borrowed ccwtrans from cp67 and cribbed it together with some low-level stub code to lay mvt out in 16mbyte virtual address space (ccwtrans is what handled translation of ccws from virtual address to real addresses, managed pinning the required virtual pages in real memory during the i-o, etc). they were doing the initial work on 360-67.

reference to old time-line

from that time-line

IBMS-370ARCH. 70-06 71-02 08 EXTENDED (REL. MINOR) VERSION OF S-360 IBMS-370-145 70-09 71-08 11 MEDIUM S-370 - BIPOLAR MEMORY - VS READY IBMS-370-155 70-06 71-01 08 LARGE S-370 IBMS-370-165 70-06 71-04 10 VERY LARGE S-370 IBMS-370.VS 72-08 73-08 12 VIRTUAL STORAGE ARCHITECTURE FOR S-370 IBMVM-370 72-08 72+?? MULTIPLE VIRTUAL MACHINES (LIKE CP-67) IBMOS-VS2(SVS) 72-08 72+?? VIRTUAL STORAGE VERSION OF OS-MVT IBMOS-VS2(MVS) 72-08 74-08 MULTIPLE VIRTUAL ADDRESS SPACES IBMMVS-JES3 72+?? 75-10 LOOSE-COUPLED MP (ASP-LIKE) IBMMVS-JES2 72-?? 72-08 JOB-ENTRY SUBSYSTEM 2 (HASP-LIKE)

...

some issue with above ship dates ... virtual memory operating systems (vm-72??, svs-72??) whouldn't ship before virtual storage hardware was available (73-08??) ... note however, 370-145 was simple re-impl of a different floppy ... 155-165 required extensive hardware field upgrade to add virtual memory support.

another reference giving some vs1, vs2, jes timeline

a hasp-jes2 time-line from the jes2 discussion group archives

note in the above, it lists 8-68 plus 1 as date of HASP II V.2 with BSC RJE (I had also gotten tty & 2741 terminal support running in HASP with a editor with syntax borrowed from cms editor for early crje).

another history of hasp & jes2 (share presentation)

note the above mentions the first SHARE HASP project meeting was at Houston in March 1968. Three people from Cambridge had come out and installed cp-67 at the university in Jan. of 1968. I then got to attend the Mar68 SHARE meeting in Houston where CP-67 was announced.

the above also has following on FS:

You may recall a not-so-secret project that IBM was working in the early '70s. The "Future System" (FS) project was to be a successor to the S-370. When AOS1 and AOS2 came online, the FS project was dragging on and on. IBM Debt Management made the decision to develop MVS as a sort of stopgap measure to keep OS-VS alive until FS came up.

(FS eventually was given up too, but many of its ideas and concepts formed the nucleus for the System 38.)

The HASP team was rebuttembled for MVS in a "burned out A&P" storefront. There they put together the first cut of JES2 (its new name). The machine they tested it on was an S-370 model 162: yet another model that never officially existed outside of IBM. The 162 was a model 165 that had been refitted for FS.

JES2 multiaccess SPOOL was preceded by similar mods written at NIH and Mellon. Likewise, NJE was preceded by user written modifications at the University of Iowa and Triangle Universities Computation Center.

When FS was buried, one of the designers was buttigned to the JES2 team, where he authored HASPSNA -- the SNA support for JES2. (This was way back when SNA was first being promulgated, and was known as "Single Network Architecture" instead of "Systems Network Architecture".) This same guy (one of the speakers at this session) told a horrifying war story: once upon a time an errant 3330 selector channel at a customer location rewrote the entire JES2 checkpoint dataset, shifting its contents left by one bit! He remembers spending one very long night repunching the checkpoint dataset from a dump.

.... snip

other collected FS postings

Before the announcement of 370 virtual memory ... there was an incident where a copy of a corporate document discussing virtual memory leaked. an investigation somewhat narrowed the leaked copy down to someplace in the northeast. after that all corporate copying machines were retrofitted with unique small serial numbers under the glbutt ... which would show up on all copies made from the machine. also, all the 370-145 shipped had an "xlate" label for one of the psw bits on the front light rollers.

as mentioned in prevous post ... my wife did a stint in the gburg jes group and was one of the "catchers" for ASP ... for turning it into JES3 ... this was before she was con'ed into going to pok to be in charge of loosely-coupled architecture.

another project that went on before 370 virtual memory announcement was joint project between endicott and cambridge

to modify a cp-67 kernel to provide 370 virtual machines (support 370 virtual memory architecture). cp-67 already provided 360 virtual machines with 360-67 architecture virtual memory. however, 370 definition had different control register and table formats and some new instructions. the modifications to cp-67 kernel required modifications to simulate the new instructions and when translating virtual tables to shadow tables ... they went from 370 format to 360 format.

there was also a security issue. most of the work went on in cambridge on the cambridge cp-67 service. however, this service also had some number of non-employee use, including some number of students from colleges & univ. around the cambridge area. as a result, rather than modifying the production kernel that ran on the real machine ... the kernel modifications were all done on a cp-67 kernel that was kept isolated in a virtual machine (provided by the "real" kernel running on a "real" machine). for some topic drift ... this security isolation characteristics was also used by a number of commercial time-sharing service bureaus (and rumored, also some number of gov. agencies)

once that was operational, another set of changes were made to the cp-67 kernel so that it used 370 table definitions and instructions. the resulting environment was somewhat

cambridge real 360-67 cp-67-l kernel running on real machine cp-67-h kernel running in 360 virtual machine providing 370 simulation cp-67-i kernel running in 370 virtual mahcine providing 370 simulation cms running in 370 virtual machine

this was operational a year before the first 370-145 engineering model in endicott was working. for early 370-145 engineering validation, a copy of the cp-67-i kernel was taken to endicott and booted on the real machine ... and immediately failed. after some investigation, it turned out the engineers had (incorrectly) reversed two of the new B2xx opcodes. the cp-67-i kernel was patched to correspond with the (incorrect) hardware implementation and then things appeared to run fine.

the "cp-67-i", "cp-67-h", and "cp-67-i" effort was the first major use of the cms multi-level source update mechanism.

the original cms update command took a single "UPDATE" file and applied it to a single source file using sequence numbers in cols. 73-80. The UPDATE source file needed to have the sequence numbers manually typed. The resulting (temporary) updated file was then compiled-buttembled. Periodically *UPDATES* were applied permanently by replacing the original source file with the updated temporary file (which then may or my not be resequenced).

because I was generating such a large amount of source code changes as an undergraduate ... I had created a pre-processor for the update command which would generate the sequence numbers of new-replaced update statements (before pbutting it to the UPDATE command). My process had slightly modified update control statements with "$" that was recognized by the update pre-processor for automatically generating sequence numbers in a temporary update file before it was pbutted to the update command.

somewhat as part of the joint endicott-cambridge effort for cp-67-h and cp-67-i kernels ... there was the multi-level update effort.

basically the source update command file was enhanced to interatively apply a series of different updates to source file before buttembling.

this further evolved in vm-370 as was shipped with the vm-370 product ... as part of the customer source level maint. infrastructure ... aka monthly "PLC" (program level change) tapes were shipped with source level maintenance (along with binary image for customers not wanting to do source level rebuild of their system).

there is folklore that this gave jes2 group some amount of trouble. supposedly jes2 group did all of the development and source code maintenance under cms and used the cms multi-level update process. however, for mvs product release ... the cms source updates then had to be entered into the mvs-based source control system ... before generating official product systems for customer ship (which was not a source level maint process ... but the resulting buttembled and-or compiled executables). i heard rumors that it gave the jes2 group fits trying to get the straight-forward cms multi-level updates into the mvs-based source control system.

part of this had come out of history of hasp also being shipped with full source and to generate a hasp system required buttembling the full source.

a few past posts discussing cms multi-level update procedure, and-or source maint-control systems:

--