 |
I develop Algol 68 Genie mainly on Debian. To test releases, I keep a "zoo" with operating systems as FreeBSD, OpenBSD and Raspberry Pi OS installed on virtual machines running on top of Debian. Virtualisation began half a century ago as a method of sharing mainframe resources between different operating systems, applications or users.
A well-known example was VM/370 which derived from CP/CMS from the 1960s. The concept was elegant - a mainframe is an expensive resource, so to accommodate different operating systems or many users or servers, the actual machine is virtualised to present itself as many individual machines. Virtualisation works efficiently when a computer emulates itself, and that is what VM/370 did - run many virtual IBM 370's on one physical IBM 370. For timesharing users VM came with the Conversational Monitor System CMS, a small but robust single-user shell. It was the system I worked on when I was a student, and I have fond memories of it. Needless to say that the VM/370 heritage lives on up to the present day in z/VM, as MVS lives on in z/OS.
What is the status of these Jurassic operating systems? The predecessor of MVS, MVT is in the public domain. VM releases through VM/370 Release 6 were open source, and are now also considered to be in the public domain. Since MVS 3.8 was available for order directly from IBM as a no charge product, several Hercules users obtained MVS 3.8J from IBM and made available not only distribution tapes, but even turnkey systems like TK4- for use with Hercules.
For several years I have been using MVS with ALGOL68C on a "hobby mainframe" for use as a reference for Algol 68 Genie. Next to MVS, people have been working on resurrecting VM/370 Release 6, and over time several implementations have come and gone. At the time I built a VM emulation based on professor René Ferland's nifty vm6pext release. The only guest was MVS, that I based on a version that derives from TK4- but was modified by Bob Polmanter to behave well on VM, for instance by spooling job output to the CMS user who scheduled the job.
In part I constructed a VM emulation just for having the satisfaction of being a privileged user - albeit a lonely user - on VM, something unthinkable in the 1980's on the real thing. Below is its VM logon screen as displayed on CRT (Cool-Retro-Terminal), a terminal emulator that mimics vintage cathode-ray tube screens. This display takes me back to the terminal room at the Nijmegen academic computer center in the 1980's.
My main research subject in the 1980's concerned computational chemistry. Most code that I wrote in Nijmegen was in now vintage but back then modern Fortran on VM/370 and later VM/SP. For some time I ranked among the heavy users of the university's computer center, which I thought was kind of cool.
Recently, a VM/370 distribution has been made available that should become a community edition of this vintage system. It makes CMS usable again by adding for instance a full-screen editor, the FORTRAN H compiler and much more. Hence I did not think very long before deciding to give the VM/370 community edition a whirl and migrate my vm6pext setup. On this community edition, I installed as guest operating systems MVS, MVT, VM/370 (VM can run itself and used to be developed this way), and UTS (a Unix system for VM). For much of this, there are tutorials on the moshix channel.
On a modern workstation my emulated system runs circa an order of magnitude faster than the real iron of the 1980's, and I do not have to share it with 150 other timesharing users, which was a common workload at the time. I really doubt whether my workstation could handle 150 interactive users but at the time hardware handled that load. This still is an impressive feat, a consequence of the optimized design of every aspect of a mainframe. The CPU was one component of many, the spider in a web of autonomous equipment such as channel processors or peripheral controllers - north- and southbridges avant la lettre, but campus-wide.
I reconfigured VM's kernel giving MVS direct access to memory to avoid double paging which is a performance sink when MVS runs on top of VM. Once VM is up, I boot MVS (sorry, ipl MVS) from within a telnet session connected to VM as described below. The VIRTUAL=REAL notification means that double paging is avoided.
$ telnet s370 3270
Trying 127.0.1.1....
Connected to s370.
VM/370 ONLINE
logon mvs ********
STORAGE IS VIRTUAL=REAL
LOGON AT 21:30:00 GMT FRIDAY 05/07/21
CP
ipl 148
IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2
Once MVS has booted you can DIAL into MVS using a 3270 terminal emulator, and you will be greeted by my personal TSO logon screen:
MVS/370 Online
VV VV MM MM
VV VV MMM MMM
3333333333 777777777777 MM00000000
333333333333 77777777777MM MM0000000000
33 VV33 77VV 77 MMMM00MM 00
V33 VV 77M MM 00MM 00
33 VV 77MM 00MM 00
3333VV VV 77 MM 00MM 00
3333 VVVV 77 MM 00MM 00 _ _
33 VV 77 MM 00MM 00 ." \\`. (v)
33 77 00 00 ( \\ \\_\_ )\
33 33 77 00 00 \\ _" //\ )
333333333333 77 0000000000 `/ // /// /
3333333333 77 00000000 (// .__-"
"-" \\
Enter logon userid [reconnect]
====>
RUNNING VM370CE
On the MVS guest I installed ALGOL68C. Since the system permits scheduling MVS batch jobs from CMS, I can run ALGOL68C as CMS user in batch mode. Perhaps one day somebody will recover A68C or FLACC for CMS, however for my purposes running batch jobs suffices. I prepare JCL batch files for MVS on CMS with the full screen editor, for instance below trivial A68C program:
File: FACT A68C A1 RECFM: F LRECL: 72(80) Lines: 10 Current: 10
===== * * * Top of file * * *
===== //FACT JOB 1,MARCEL,MSGCLASS=A
===== //FACT EXEC A68CCG
===== //A68.SYSIN DD *
===== BEGIN PROC fac = (INT n) INT: (n <= 0 | 1 | n * fac (n - 1));
===== FOR k TO 10
===== DO print(k, fac (k), new line)
===== OD
===== END
===== /*
....+....1....+....2....+....3....+....4....+....5....+....6....+....7..
=====
* * * Bottom of file * * *
===>
Unchanged EE V1.2.5, 1 File(s)
A more complex JCL file is below, that runs a segmented A68C program, with source files stored on MVS:
File: CLUSTRUN JCL A1 RECFM: F LRECL: 72(80) Lines: 62 Current: 9
===== * * * Top of file * * *
===== //CLUSTER JOB (1),MARCEL,CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),
===== // USER=MARCEL,PASSWORD=********
===== //SCRATCH EXEC PGM=IEFBR14
===== //CLUSTER DD DSN=MARCEL.CLUSTER.ENV,DISP=(MOD,DELETE,DELETE),
===== // UNIT=3375,VOL=SER=PUB001
===== //*
===== //* EXAMPLE OF RUNNING A SEGMENTED ALGOL68C PROGRAM.
===== //*
....+....1....+....2....+....3....+....4....+....5....+....6....+....7..
===== //* ENVIRON
===== //A68ENV EXEC PGM=A68C,REGION=768K
===== //STEPLIB DD DSN=A68CLIB.MOD,DISP=SHR
===== //INIT DD DSN=A68CLIB.SYS(INIT),DISP=SHR
===== //SYSENV DD DSN=A68CLIB.SYS,DISP=SHR
===== //CODE DD UNIT=SYSDA,DISP=(NEW,PASS,DELETE),
===== // SPACE=(CYL,(1,1),RLSE)
===== //ENVOUT DD DSN=MARCEL.CLUSTER.ENV(CLUSTER1),DISP=(NEW,PASS,DELETE),
===== // SPACE=(CYL,(1,1,1)),DCB=RECFM=VB,
===== // UNIT=3375,VOL=SER=PUB001
===>
Unchanged EE V1.2.5, 1 File(s)
I submit JCL files from CMS to MVS and fetch the output when the job finishes:
submvs clustrun jcl PUN FILE 1894 TO MVS COPY 01 NOHOLD Ready; T=0.01/0.01 22:37:05 PRT FILE 1895 FROM MVS COPY 01 NOHOLD readcard clustrun listing RECORD LENGTH IS '132' BYTES. Ready; T=0.02/0.06 22:46:15
Next to running ALGOL68C, I use VM/CMS for the preservation of vintage Fortran code for computer simulations in chemical physics, and vintage statistical stuff. But that is a story for a future post .
|
|
© 2002-2025 J.M. van der Veer (jmvdveer@xs4all.nl)
|