SCRIPT/VS 4.0.0: DEVICE 1403N6 CHARS MONO »     The IBM System/360 Line  The IBM System/360 Line  The IBM System/360 Line  The IBM System/360 Line    Document Number 0867-5309   August 8, 2025   Evie Cooper »   FOREWORD  FOREWORD  FOREWORD  FOREWORD  ________    Some amount of the information in this guide originated in Dave  Morton's excellent guide named "IBM Mainframe Operating Systems:  Timeline and Brief Explanation For the IBM System/360 and Beyond."  Most of my knowledge lies in VM and VSE, whereas Dave's seems to be  mostly in MVS. I hope this guide is useful to the mainframe hobbyist  community, and thanks to Dave for producing the original this booklet  was inspired by! In addition, I sourced knowledge from the following  sources:  ź Enterprise Systems Media z/Journal  ź Lynn Wheeler's IBMVM Listserv post archive  ź Various manuals on Bitsavers  ź The CBT Tape archive  ź "IBM Mainframe Public Domain Software Collection"  ź Paul Pierce's System/360 website  ź Melinda Varian's VM and the VM Community  _______________________  ź IBM program product announcements  ź linas.org's Linux ESA/390 page  ź My real-life experiences running these systems  ź Marist Linux/390 webpage  ź Argecy Corp's website  I will say that while I have tried to ensure the information presented  in this guide is as accurate as humanly possible, there will inevi-  tably be some errors. I'm a bit uncertain on some details surrounding  the very early S/360 OSes, and I have placed disclaimers where appli-  cable. Note that I was reading quite a bit of conflicting information  on specifically BOS/360, so read with caution and please alert me at  once if you have a plausible correction (with evidence, please!).  This document was formatted on SCRIPT/VS 1.4.0 with BookMaster Release  4, on z/VM 4.4, on a Multiprise 3000 System/390, powered half by solar  panels sitting on my balcony.  To contact me, email me at wec@bam.moe  wec@bam.moe  wec@bam.moe  wec@bam.moe  ___________   2 Mainframe History »   AI statement: I did not use any generative AI, deep research tools,  AI statement:  AI statement:  AI statement:  ______________  chatbots, or anything; I only used my hands and the sources listed to  produce this document.                    Foreword 3 »   CONTENTS  CONTENTS  CONTENTS  CONTENTS  ________    Foreword 2  Foreword 2  Foreword 2  Foreword 2  Figures 10  Figures 10  Figures 10  Figures 10  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  Mainframe Hardware 1  Mainframe Hardware 1  Mainframe Hardware 1  Mainframe Hardware 1  Origins 1  What is a mainframe? 1  The System/360 3  The System/370 3  Original S/370 and 370/AF 3  3033 4  3081/3083, 370/XA 4  4300 4  3090/4381 5  9370 5  The System/390 5  ES/9000 5  9672 6  The Multiprise Line 6  Multiprise 2000 6  Application StarterPak 3000 6  Multiprise 3000 7  PC Mainframes 7  Personal Computer XT/370 7  Personal Computer AT/370 8  IBM 7437 VM/SP Technical Workstation 8  9371 8  Personal/370 (P/370) 8  S/390 Processor Card and the P/390 8  S/390 Integrated Server 8  System Z 9  Emulation 10  FLEX-ES 10  zPDT 11  Hercules 11  TurboHercules Controversy 12  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  Mainframe Peripherals 13  Mainframe Peripherals 13  Mainframe Peripherals 13  Mainframe Peripherals 13  DASD Disk Drives 13  S/360 Generation 13  S/370 Generation 13  S/370 Generation FBA 15  S/370 XA Generation 15  System/390 Generation 16  System Z Generation 17  Tape Drives 19   4 Mainframe History »   2400 Series 19  2420 Model 7 21  3400 Series 21  8809 and 9347 22  3480 23  3490E 23  3590 23  3592 24  Line Printers 25  1403 25  2821 25  3211 26  3203 27  3618 27  3262 27  5262 28  4245 28  4248 28  6262 29  Console Printer/Keyboards 29  1052 29  3210/3215 29  Card Readers/Punches 30  1442 30  2540 30  3501/3521 31  3505/3525 31  Networking Devices 31  Channel-to-Channel Adapters 31  8232 (LAN Channel Station) 31  3172 (Nways Iterconnect Controller) 33  2216 (Nways Multiaccess Controller) 34  Open Systems Adapter 36  Non-Programmable Communications Controllers 37  2701 37  2702 38  2703 39  AWS2703 39  9370 ASCII Subsystem Controller 39  4331/4341/9370 Telecommunications Subsystem 40  AWSICA 40  2260 Display System 40  2848 Controller 41  2265 41  NCP Communications Controllers 41  3705/3704 42  3710 42  3725 42  3745 42  Communications Controller for Linux 43  3270 Display Controllers 43  3272 43  3271 44  3274 44   Contents 5 »   3174 47  Combination Controller/Displays 50  3299 Multiplexer 51  3270 Display Terminals 51  3277 52  3278 52  3279 52  3290 54  3178/3179 54  3180 54  3191 55  3192 55  3193 55  3194 55  3104 55  3472 56  Printers 56  RJE Terminals 56  2780 Data Transmission Terminal 57  2770 Data Communication System 57  3780 58  3770 58  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  Early OSes - BPS/360, BOS/360, and TOS/360 60  Early OSes - BPS/360, BOS/360, and TOS/360 60  Early OSes - BPS/360, BOS/360, and TOS/360 60  Early OSes - BPS/360, BOS/360, and TOS/360 60  BPS/360 60  BOS/360 60  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  DOS/360, VSE, and z/VSE 62  DOS/360, VSE, and z/VSE 62  DOS/360, VSE, and z/VSE 62  DOS/360, VSE, and z/VSE 62  DOS/360 and TOS/360 62  DOS/VS 62  DOS/VSE 63  SSX/VSE 63  VSE/AF 64  VSE/SP 64  VSE/ESA 64  z/VSE 67  VSEn 69  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  OS/360, MVS, and z/OS 71  OS/360, MVS, and z/OS 71  OS/360, MVS, and z/OS 71  OS/360, MVS, and z/OS 71  OS/360 PCP 71  OS/360 MFT 71  OS/360 MVT and TSO 72  Time Sharing Option 72  HASP and ASP 73  OS/VS1 74  OS/VS1 BPE 74  OS/VS2 SVS 75  OS/VS2 MVS 76  MVS/SE 77  MVS/SP 1.1-1.3 77  ISPF and SDSF 78   6 Mainframe History »   MVS 3.8J 79  MVS/XA 79  MVS/ESA 81  Version 3 81  Version 4 81  OpenEdition 82  Version 5 82  OS/390 82  Version 1 82  Version 2 83  z/OS 83  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  TSS/360 and TSS/370 87  TSS/360 and TSS/370 87  TSS/360 and TSS/370 87  TSS/360 and TSS/370 87  Origins 87  TSS/360 87  TSS's Dynamic Linker 88  Commands 88  TSS/370 89  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  RAX and MUSIC 92  RAX and MUSIC 92  RAX and MUSIC 92  RAX and MUSIC 92  RAX 92  MUSIC 92  The Filesystem 93  The Emulator 93  The Networking 93  The Emails 93  The Job Language 94  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  MTS 96  MTS 96  MTS 96  MTS 96  History 96  Computers Running MTS 99  Front-End Processors 99  Networking and MERIT 100  Job Spooling 100  Versions 101  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  CP/CMS, VM/CMS, and z/VM 108  CP/CMS, VM/CMS, and z/VM 108  CP/CMS, VM/CMS, and z/VM 108  CP/CMS, VM/CMS, and z/VM 108  Origins: before VM 108  CP-40 109  CMS 110  CP-67 110  CP/CMS 111  VM/370 112  VM/370 Update Process 113  VM/370 Release 2 and Growth 113  CPREMOTE, RSCS, and VNET 114  VM/370 BSEPP and SEPP 116  VM/370 Release 6 and BSEPP/SEPP Release 2 116  VM/SP 117  PROFS 118   Contents 7 »   VM/SP R2 and R3 118  VM/Passthrough 119  VM/SP HPO 120  VM/XA MA 121  The OCO Announcement 121  VM/PC 121  VM/SP Release 4 121  WISCNET and VM TCP/IP 122  SQL/Data System 124  VM/SP Release 5 and 6 124  VM/IS 125  VM/XA SP 129  VM/ESA 132  Parallel Worlds 132  VM/ESA Version 2 134  z/VM 136  z/VM 3.x 136  z/VM 4.x 136  z/VM 5.x 137  z/VM 6.x 137  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  Mainframe Linux 139  Mainframe Linux 139  Mainframe Linux 139  Mainframe Linux 139  Bigfoot Linux/i370 139  IBM Linux/390 142  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  Mainframe UNIXes 144  Mainframe UNIXes 144  Mainframe UNIXes 144  Mainframe UNIXes 144  Bell Labs UNIX/370 144  The Purpose 144  The Hacked TSS 146  Memory Model 146  Device Model 147  Deployment 148  Princeton UNIX/370 149  The Initial Port 150  Amdahl 151  UTS 151  IX/370 152  AIX/370 153  AIX/ESA 155  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  TPF and ACP 157  TPF and ACP 157  TPF and ACP 157  TPF and ACP 157  SABRE 157  PARS 157  ACP 158  TPF and TPF/ESA 159  z/TPF 159  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  IBM 9370: DPPX/370 161  IBM 9370: DPPX/370 161  IBM 9370: DPPX/370 161  IBM 9370: DPPX/370 161   8 Mainframe History »   ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  Solaris on System Z 163  Solaris on System Z 163  Solaris on System Z 163  Solaris on System Z 163  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  Popular Mainframe Programs 164  Popular Mainframe Programs 164  Popular Mainframe Programs 164  Popular Mainframe Programs 164  Customer Information Control System (CICS) 164  History 164  Other CICS Versions 165  Application Programming 170  Modern Features 177  CICS Applications 177  GDDM 178  Base GDDM components 178  GDDM-ICU 179  GDDM-IVU 179  GDDM-OPS 180  GDDM-ISE and GDDM-VSE 181  SCRIPT/VS 182  OfficeVision/VM 183  OV/VM 1.1 and 1.2 183  ESA Calendar Feature 188  CallUp 189  Release 3, 4, and the end 190  Standalone Utility Programs 191  Device Support Facilities (ICKDSF) 191  VM Format/Allocate (DMKFMT) 192  VM Standalone Directory Creation Utility (DMKDIR) 192  Standalone I/O Configuration Program (SA IOCP) 193  DASD Dump/Restore (DMKDDR) 193  OS DASD Initialization (IBCDASDI) 194  OS Dump/Restore (IBCDMPRS) 195  Standalone Utilities (ZZSA) 195  ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  Afterword 199  Afterword 199  Afterword 199  Afterword 199  Index 200  Index 200  Index 200  Index 200  Glossary 201  Glossary 201  Glossary 201  Glossary 201        Contents 9 »   FIGURES  FIGURES  FIGURES  FIGURES  _______    1. VSE/ESA 1.1.0 logon screen 65  2. VSE/ESA 2.7.0 programmer-type menu 66  3. CSI TCP/IP stack running a ping from a blank CICS screen 67  4. z/VSE 4.1.0 logon screen 68  5. z/VSE 4.1 system console 69  6. VSEn 6.3.0 logon screen 70  7. OS/VS1 Release 7 BPE Release 3 starting under VM/HPO. 75  8. MVS/SP 1.3.4 IPL top message 77  9. ISPF/PDF user interface on MVS/SP 1.3.4 78  10. SDSF V1R2 on MVS/SP 1.3.4 79  11. Console of an IPLing MVS/XA 2.2.3 system. 80  12. ISPF on z/OS V1R5 84  13. SDSF displaying job output on z/OS V1R5 85  14. z/OS V1R5 Resource Management Facility performance reporting 86  15. TSS/370 Release 3 starting up 90  16. TSS/370 Release 3 user logon and logoff 91  17. MUSIC/SP ESA 5.3 logon screen 95  18. MUSIC's Full Screen Interface 95  19. MTS 6.0A user terminal screen 107  20. VM/370 Release 4 login screen 114  21. PROFS V2 R1.1 Main Menu 118  22. VM/Passthrough menu 120  23. VM/SP Release 4 logon screen 122  24. SQL/DS on VM ISQL 124  25. VM/SP Release 5 logon screen 125  26. VM/IS logon screen (system built on VM/SP Release 5) 126  27. The original BASIC ELIZA on VS BASIC for VM 127  28. DisplayWrite/370 for VM 127  29. ISPF on VM/IS 128  30. QMF, a UI for SQL/DS, on VM 129  31. PROFS V2 R1.1 Main Menu 131  32. VM/ESA V1R1 370 Feature logon screen 133  33. VM/ESA Version 2 Release 1 logon screen 135  34. z/VM Version 4 Release 4 logon screen 137  35. z/VM History -- zoom in! 138  36. Linux/i370 .INS load file 139  37. Linux/i370 parameter/command line file 140  38. A rare view of a running i370 Linux system 141  39. Amdahl UTS 1.0 running under VM/SP R5 152  40. CICS/VS 1.7.0 welcome screen (MVS/SP 1.3.4) 166  41. CICS TS 3.2.0 welcome screen (z/OS 1.5) 167  42. CICS/VSE 1.2 welcome screen (VSE/ESA 2.1.0) 168  43. CICS TS 2.3 welcome screen (VSE/ESA 2.4.0) 169  44. CICS for OS/2 3.1 welcome screen (OS/2 Warp 4) 170  45. CICS macro-level sample program (assembler) 171  46. CICS macro-level sample program (COBOL) 172  47. CICS macro-level sample program (PL/I) 173  48. CICS command-level sample program (COBOL) 174   10 Mainframe History »   49. CICS BMS map sample 176  50. Sample CICS map displayed on a 3270 terminal 177  51. GDDM C program that draws a demo menu 179  52. GDDM-ICU chart 179  53. Example GDDM-OPS presentation 181  54. GDDM-OPS presentation (extracted using GDFSAVE) 181  55. OfficeVision/VM 1.1 Main Menu 185  56. OV/VM 1.1 Calendar 185  57. OV/VM Document Style Choice Menu 186  58. OV/VM DisplayWrite/370 Memo Prompter 187  59. OV/VM 1.2 OVMAIL Menu 188  60. OfficeVision/VM 1.3 ESA Calendar Feature 189  61. CallUp Main Menu 190  62. Standalone ICKDSF 192  63. Sample IOCP definitions for a 3390 193  64. Example DDR run (copying a DASD) 194  65. Example IBCDASDI jobstream 195  66. Example IBCDMPRS jobstream 195  67. ZZSA main menu 196  68. ZZSA device list 197  69. ZZSA dataset list 198              Figures 11 »                      12 Mainframe History »   MAINFRAME HARDWARE  MAINFRAME HARDWARE  MAINFRAME HARDWARE  MAINFRAME HARDWARE  __________________    ORIGINS  ORIGINS  ORIGINS  ORIGINS  The road to commercial computing was fraught with confusion, failures,  and false starts. By the mid-1960s, computers as a machine that a  business could purchase were starting to develop serious customer  bases. The so-called "third generation" of computers featured inte-  grated circuits. In the mid-1960s, you could get a computer from a  variety of now-forgotten names:  ź IBM, who sold the 7090 (a large system), 1401 (a small system),  and 1130 (targeted for low-cost markets); all of these systems  were replaced with the System/360  ź Burroughs, whose B5000 (and later B5500/B5700) led the way in com-  puters that did not require heavy assembly language usage to  program; the OS (MCP) still lives on today  ź UNIVAC, whose 1107 and 1108 gained popularity as batch systems,  lives on today as OS 2200 from Unisys  ź General Electric, whose 600 series (specifically the 645) was the  birthplace of the highly-influential Multics system; otherwise,  GECOS was the OS used for batch loads -- GCOS lives on today  (version 7 and 8, who are somewhat different) as emulated systems  ź RCA (Radio Corporation of America), who diversified into computing  and had reasonable success with their 501 series (their later  Spectra 70 was compatible with the System/360)  ź CDC (Control Data Corporation), whose coming 6000 series would  define supercomputing in the mid-1960s  ź NCR (National Cash Register, though this acronym is never  expanded), whose computers in the early 1960s saw some success in  smaller customers  ź DEC (Digital Equipment Corporation), whose PDP (Programmable Data  Processors) were popular in academia  WHAT IS A MAINFRAME?: Though usually a colloquial term that refers to  WHAT IS A MAINFRAME?  WHAT IS A MAINFRAME?  WHAT IS A MAINFRAME?  some kind of IBM-brand computer (at least today), a mainframe gener-  ally refers to a large computer system with several distinct charac-  teristics:  ź A distributed processing nature. The CPU need not directly drive  peripherals, as it is attached to a variety of coprocessors whose  purpose is to driver peripherals for the host computer CPU(s).   Mainframe Hardware 1 »   ź Extensive teleprocessing capabilities. Mainframes can support many  users (sometimes in the high hundreds range), and, historically,  this necessitated the creation of some kind of network to connect  terminals to terminal controllers. These networks were often  interlinked with other networks (in the past, these were things  like X.25 networks; later, it was the Internet)  ź Large storage arrays. In the early days, this often meant entire  floors of buildings being filled with disk drives; today, it means  several racks of disks on larger machines, ranking in large capac-  ities.  ź Purpose-built fault recovery. Mainframes have historically sought  high uptime, and this is still true for today. Paths to periph-  erals are often multipathed, and devices may be duplicated for  extra reliability. The CPUs of most mainframes are sometimes  duplicated too.  ź An operations team. Being a large and complex system (often  running a suitably large and complex OS), these large computers  are often kept by a number of operators.  Often times, people take computing today for granted. You can go to  the computer store, and you can buy a CPU from either AMD or Intel --  and any programs you write will work on either CPU, provided the OS  ran on both is the same (or is compatible). However, this was not  always the case! If you bought a computer in the 1960s, this were  ______  quite a bit different. You found yourself in a landscape of "one-  model-machines" -- machines that, while certainly rather capable, pre-  sented a hefty challenge when it came to porting software. There was  usually only one (or a few) model(s) of a computer in each CPU archi-  tecture, and this presented a rather difficult issue.  In that era, totally different computers were everywhere, as seen on  __________  the list above. If you were, for example, buying a computer to print  payroll checks and do other accounting tasks, an IBM 1401 would be  fine. If you were doing research or engineering tasks, that 1401 would  be useless -- you'd instead find yourself juxtaposed between a choice  between an IBM 7040, DEC PDP-1, and a bunch of other computers. There  was no reason to buy IBM, and IBM knew this.  Because every CPU architecture in those days was different, you'd need  to rewrite all of your programs when you upgraded computers (as you  might be upgrading from an IBM 7090 to a UNIVAC 1107)! IBM saw this  void, and wondered if they could build a line of machines (rather than  just one machine) with a common CPU architecture. That way, if someone  bought a basic System/360, they could upgrade it later on and not have  to rewrite any code.  While this certainly sounds silly today, this was seen as somewhat  revolutionary back then. Likewise, the OSes found on it had to be  portable across machines -- this will be the primary focus of this  booklet. With that out of the way, let's begin!   2 Mainframe History »   THE SYSTEM/360  THE SYSTEM/360  THE SYSTEM/360  THE SYSTEM/360  The 360 was an early computer, and it was not uncommon in that era to  find systems engineers that were the direct trained descendants of the  original generation of computing pioneers. One of Howard Aiken's stu-  dents was Dr. Frederick Brooks, who would later become the director of  IBM's System Architecture. When the 360 project came up, Dr. Brooks  was selected to be the lead of the whole project -- a tall order and a  difficult task for anyone in that era. He would later go on to win  over 20 awards/honors, and even won the National Medal of Technology  in 1985. The principal architect would be Dr. Gene Amdahl, already  known for his work on earlier (and smaller) IBM computers.  The 360 project was also unbelievably expensive in that era -- it cost  IBM 5 billion dollars; this put the project on the map with giants of  the era like the Apollo Project (which was NASA's project to put men  on the Moon, of which the salaries of the people involved was $5  billion too). Actually, the 360 project completely dwarfed Project  Gemini, the direct precursor to the Apollo Project, by 4 billion  dollars. Needless to say, the 360 project needed to deliver.  Competitors to IBM were rapidly catching up to IBM with similar  machines to the 1401, at a lower cost. IBM knew this, and development  of the 360 coalesced around the early 60s and the hardware was offi-  cially announced in April 1964. In 1965, the first 360 machines were  shipped to customers. This was unbelievably fast, and for good reason  -- 60,000 people were employed to make this possible. A variety of  models were launched then, ranging from the tiny Model 20 (which  itself was a subset of all other 360s), the entry-level Model 30, and  the big powerful Model 75. The Model 91 would come later in January  1966, and it screamed at 16.6 MIPS (million instructions per second, a  common measurement of mainframe CPU speed). All the while, the same  software and I/O devices could be used on all of these machines!  Possibly the most influential model of the System/360 line was the  Model 67, with its optional virtual memory hardware, that would set  the stage for the online timesharing (and not batch-oriented) model of  the successors to the 360. The Model 67 found itself embraced by the  academic world, with many universities and research labs (like Bell  Labs) adopting it for their computing needs (and modifying it to suit  their specific needs, too). The so-called "DAT Box" (unrelated to the  feature found on the 370/Advanced Functions machines that launched  later) was highly sought-after for these machines.   THE SYSTEM/370  THE SYSTEM/370  THE SYSTEM/370  THE SYSTEM/370  ORIGINAL S/370 AND 370/AF: While the 360 was certainly successful, a  ORIGINAL S/370 AND 370/AF  ORIGINAL S/370 AND 370/AF  ORIGINAL S/370 AND 370/AF  successor was definitely in order. The System/370 was announced in  June 1970, with the first machines showing up at customer shops in  1971. By 1972, the unusual lack of virtual memory hardware on the ori-  ginal 370s caused IBM to launch the 370/Advanced Function line --  these contained an infamous "DAT box" (dynamic address translation,  the name for the memory management unit on the 360; note that the   Mainframe Hardware 3 »   370's was different in design). These introduced new generations of  the 360 OSes (the original 370 announcement just ran the 360 OSes,  nothing new for the 370 itself), and upgrades for earlier 370s that  did not have the DAT box were available (the Model 155 and Model 165).  3033: The 370, being derived from the 360, had a rather famous 16  3033  3033  3033  megabyte storage limit (storage being the IBM term for what other com-  puter platforms called "RAM"). As the 370 evolved throughout its life,  the first major gain was something called ECPS (Extended Control  Program Support), which was hardware acceleration to certain OS func-  tions. Seeing that the address space limit was starting to become an  issue. The 3033 (the 303x series was the successor to the second-  generation 370/Advanced Function machines) introduced a function  called "Dual Address Space" -- the MVS operating system (which will be  discussed later) could use this to effectively double the system's  storage capacity (with plenty of caveats, of course).  3081/3083, 370/XA: Needing an actual address space increase that  3081/3083, 370/XA  3081/3083, 370/XA  3081/3083, 370/XA  wasn't a bank-switching technique, the 3033 and 3081 (launched in  October 1981) added a feature called "Extended Real Addressing" -- for  the first time, it was now possible to use 64 MB of real storage (the  physical address bus now had 26 bits, rather than the infamous 24-bit  limit). When the 3081 and 3083 launched, they also contained a  totally new machine operating mode: 370/Extended Architecture (com-  monly called XA). This expanded the address bus up to 31 bits (both  real and virtual; the 26-bit 370 EAS systems were still limited to  24-bit virtual storage spaces), completely overhauled the I/O archi-  tecture, and changed how the system booted.  4300: During the early 80s, there were a variety of smaller air-  4300  4300  4300  cooled System/370s made. Here they are:  ź 4321, announced 1979 and withdrawn in 1981, 8 MB max storage  ź 4331, announced 1979 and withdrawn in 1981: 8 MB max storage  ź 4341, announced 1979 and withdrawn in 1986: 16 MB max storage  ź 4361, announced 1983 and withdrawn in 1987: 12 MB max storage  Paradoxically, the 4341 was not only more performant than the 4361,  but had more storage! This was because the 4331/4361 were developed in  Germany (by the VSE developers; as such, these machines had many  microcode features that greatly increased VSE performance through a  mechanism called ECPS:VSE), and the 4341/4381 were developed in New  York (and targeted totally different workloads). All of these models  utilized a 3270 as a console in lieu of the earlier 3215s (see the  chapter below for more information on these). The 4331 and 4361 had an  integrated DASD controller that drove a string of either 3310s or  3370s; these were FBA DASDs and no CKD DASDs were available without an  external channel-attached controller on this machine.    4 Mainframe History »   3090/4381: After the 370/XA launched, IBM announced Enterprise  3090/4381  3090/4381  3090/4381  Systems Architecture/370 on the 3090E and 4381 machines in February  1988. This added additional addressing modes, 16 access registers (32  bits wide), and a means for a program to use several virtual address  spaces; this would later evolve in 1990 with the ESA/390 architecture.  9370: Note: the 9371 is not discussed here as it is different from  9370 ______________________________________________________________  9370  9370  the 9373/9375/9377; see the PC Mainframes section for information on  ______________________________________________________________________  it  __  While IBM was doing great in the high-end systems department with the  high-performance (and high-dollar) System/370s and 370/XAs, the  midrange department was still cornered by machines like DEC's VAX  line. IBM saw this, and too wanted to break through in that market.  Designed by IBM Endicott in 1985 and released in 1986, the IBM 9370  line was the first major computer that consisted of a CPU emulating a  different CPU (in this case, an IBM 801 RISC CPU emulating a low-end  System/370). This machine was intended to be a "superminicomputer",  suitable for engineering, scientific, and office use. These machines  came in 3 different model classes, each progressively gaining more  support (with the high-end 9377s being able to run MVS/SP). Sadly,  these machines did not sell nearly as well as IBM thought they would,  and have been relegated to "failed products" lists.   THE SYSTEM/390  THE SYSTEM/390  THE SYSTEM/390  THE SYSTEM/390  ES/9000: The IBM mainframe line continued to grow consistently over  ES/9000  ES/9000  ES/9000  time! When it was time to unveil the next upgrade to the 370 in Sep-  tember 1990, IBM opted to launch a totally new architecture and line  of machines. The System/390, much like the System/370, would be a  machine for the 1990s (like the 370 was a machine for the 1970s). The  ESA/390 architecture would succeed the ESA/370 architecture, and the  first new machine to bear it was the Enterprise System/9000 (ES/9000)  line. Gone were the old massive thick device connection channel cables  -- the System/390 introduced a fiber upgrade called ESCON (Enterprise  Systems Connection). The ES/9000 line featured rack-mountable  machines, smaller air-cooled mainframes, and massive water-cooled  mainframes. While the ESA OSes (VM/ESA, MVS/ESA, VSE/ESA) could run on  the ESA/370 3090 or 4381, the ES/9000 line was faster, smaller, and  cheaper.  The ES/9000 series featured 18 different models, as mentioned. The  original 9021s were essentially converted 3090J processors, but  expanded with optional ESCON, sysplex coupling facility support, and  the addition of a new cryptographic coprocessor (which accelerated  DES). Later models could have a Vector Facility array processor, the  cryptographic accelerator (the Integrated Cryptographic Feature), and  a data compression accelerator. In addition, all of the ES/9000s could  be logically partitioned to subdivide the machine's hardware resources  to run multiple OSes simultaneously -- this also meant that there was  a different method of device assignment (see the section at the back  for SA IOCP). The models fell into three main groups:   Mainframe Hardware 5 »    ź 9021, a large watercooled machine that would replace the 3090  ź 9121, an aircooled machine that would replace the 4381  ź 9221, a rackmounted aircooled machine that replaced the 9370  It should be noted that the 9221 was originally a System/370-only  machine (on models 120/130/150) and was later upgraded with ESA/390  capability with the ESA Option, shipped July 1991. The same team that  designed the CPUs in the 9221 used their experience later to design  the CMOS 9672s.  9672: The ES/9000 would later be replaced by a machine using a more  9672  9672  9672  advanced digital logic technology (CMOS, in lieu of ECL, used by the  ES/9000s). These machines bore the model number 9672. There were six  ____  generations of these machines, and a new one came out every year from  1994 to 1999. Each one got progressively faster, and gained more  storage. The last to support 370-mode guests was the G3. The G5 added  support for IEEE 754 floating-point, and the G6 featured one of the  fastest CPUs on the market.  The history of the 9672 was marked originally by two machines (both  launched in 1994): the Parallel Transaction Server, and the Parallel  ___________________________ ________  Query Server (model number 9673). Later in 1994, these two machines  ____________  would be remarked as the Parallel Enterprise Server  __________________________  The final 9672s added something called the Open Systems Adapter; this  was essentially a directly-attached card that emulated Ethernet and  Token Ring interfaces on the mainframe. This would later evolve with  the successor machine line (the System Z).  To facilitate intercommunication and form a sysplex, the 9672s were  often seen with the 9674 Coupling Facility.   THE MULTIPRISE LINE  THE MULTIPRISE LINE  THE MULTIPRISE LINE  THE MULTIPRISE LINE  MULTIPRISE 2000: Launched in September 1996, the Multiprise 2000 was  MULTIPRISE 2000  MULTIPRISE 2000  MULTIPRISE 2000  essentially a cut-down 9672 G3. It (alongside the G3) was the last  machine to support a 370-mode IPL, with all newer machines requiring a  native ESA/370 or ESA/390 OS. Being a cut-down 9672 G3, it had half  the cores and slower cache; alas, it used nearly the same physical  form as the machine it was based from. Disks and tapes were connected  via standard ESCON or parallel (bus and tag) channels. The line was  upgraded on October 1997 with an 11%-faster MP2000. The MP2000 had CPU  model number 2003.  APPLICATION STARTERPAK 3000: Essentially a Multiprise 2000 in a half-  APPLICATION STARTERPAK 3000  APPLICATION STARTERPAK 3000  APPLICATION STARTERPAK 3000  height case, the AS3000 was a short-lived product that paved the way  for the later Multiprise 3000 (one of the best-selling System/390s  made). The AS3000 did not contain an integrated Support Element; this  was provided by a modified IBM Aptiva workstation cabled to the S/390   6 Mainframe History »   CPU card cage with a thick cable (not unlike the one seen on the  MP3000 later). These had no integrated I/O features outside of a disk  array (see the Mainframe DASD chapter below for more information on  this), an integrated 4mm DAT tape drive, an OSA, and 3270 consoles on  the Support Element. The front of the machine that held the power  switch contained the CPU and its support cards, and the back contained  a disk array plus 4mm tape drive (all attached via standard parallel  SCSI). The AS3000 had CPU serial 3000.  MULTIPRISE 3000: In September 1999, the Multiprise 3000 was launched  MULTIPRISE 3000  MULTIPRISE 3000  MULTIPRISE 3000  -- this half-height compact machine featured partially-emulated I/O  and a PCI bus. The partially-emulated I/O consisted of the P/390  device emulators, but the system also contained a real disk array (or  two, if the user chose such a configuration) that was driven by the  S/390 I/O processor: it was considered a "direct system device",  wherein the S/390 CPU drives a card present in the machine that emu-  lates CKD DASD with an SSA RAID array. FBA emulation was not possible;  the user would have to use the (much slower) emulated I/O devices to  achieve this. The CPU itself was derived from either the System/390  9672-R16 (the 7060-H30 and 7060-H50) or the 9672-R26 (the 7060-H70).  There were actually two Multiprise 3000 models that were made but  barely sold outside of IBM: the 7060-H55 and 7060-H75 (built on the  9672-R16 and 9672-R26 platforms, respectively). These were different  from the public-sold 7060s as they actually had Open Systems Adapters.  There were several of these machines sold outside of IBM (one notably  to the City of Los Angeles's Board of Water and Power).  The System/390 Integrated Server was launched before the MP3000 in  1998, but it was essentially a P/390 (discussed next). The MP3000 had  CPU model number 7060.   PC MAINFRAMES  PC MAINFRAMES  PC MAINFRAMES  PC MAINFRAMES  Throughout the years, IBM has always had a fascination with producing  PC-based mainframe-compatibles. These allowed a desktop-sized machine  to run mainframe-native software, albeit at significantly reduced per-  _____________  formance. Here are those machines:  PERSONAL COMPUTER XT/370: Based on the IBM 3270 PC (a PC that could  PERSONAL COMPUTER XT/370  PERSONAL COMPUTER XT/370  PERSONAL COMPUTER XT/370  emulate an IBM 3270 terminal), the XT/370 contained a dual-board  processor card (featuring two Motorola 68000s) with one of those two  boards containing 512 KB of mainframe storage. In addition, a 3270  emulator card was provided for talking to a host mainframe (as this  was not entirely a free-standing machine, but more of a "smart ter-  minal" that just so happened to run 370 code on it). The card stack  ran VM/PC Control Program, which itself was a cut-down version of  VM/SP (which we will definitely discuss later). The XT/370 was  extremely slow, registering 0.1 MIPS (thanks in no small part to the  fact that two 68000s emulated the 370 CPU, while a modified Intel 8087  ________  provided floating-point support). Nonetheless, it was quite a fancy  machine considering the design constraints the engineers faced in  October 1983.   Mainframe Hardware 7 »   PERSONAL COMPUTER AT/370: Launched in 1984, the AT/370 was based on  PERSONAL COMPUTER AT/370  PERSONAL COMPUTER AT/370  PERSONAL COMPUTER AT/370  the Personal Computer AT, and was somewhat upgraded. The PC/AT fea-  tured 16-bit expansion card slots (the ISA bus), and ran 60% faster  than the XT/370.  IBM 7437 VM/SP TECHNICAL WORKSTATION: Launched in April 1988, this  IBM 7437 VM/SP TECHNICAL WORKSTATION  IBM 7437 VM/SP TECHNICAL WORKSTATION  IBM 7437 VM/SP TECHNICAL WORKSTATION  machine was a PS/2 Model 60/70/80 modified with a Microchannel card  bearing a 370 CPU. This machine ran full VM/SP (again, to be discussed  later), and was intended to hook up to a 5080 Graphics System (which  connected to the machine with another Microchannel card). These  machines would run CATIA or CADAM, and it is said that they had the  same performance as a single-terminal 9370.  9371: The 9371 was an important stepping stone for what would later  9371  9371  9371  evolve into the machines show below; based on the earlier 7437 tech-  nology, the 9371 leveraged the 801 RISC CPU (like the other 9370s) but  did not have any real I/O devices -- those were emulated by a 386 CPU  running OS/2. Models 10 and 12 were MCA cabinets that used that 386  running OS/2 for device emulation (and, as such, the DASD consisted of  a MCA SCSI card hooked up to some SCSI disks), whereas Model 14 had  more of a PC emphasis and unlocked the OS/2 side for running nearly  any application (both DOS and OS/2).  PERSONAL/370 (P/370): Based on the earlier 7437 CPU card, the P/370  PERSONAL/370 (P/370)  PERSONAL/370 (P/370)  PERSONAL/370 (P/370)  (which launched in November 1989) was intended to run any 370 OS (so  long as it supported FBA DASD, which meant no MVS) on either a PS/2  (running OS/2) or an RS/6000 (running AIX). Like the 7437, all the  I/O devices were emulated, but the user could choose to also add a 370  channel card to connect real I/O devices. The P/370 was much faster  than the 7437 and it actually rivalled a low-end 4381 -- it scored  about 4 MIPS.  S/390 PROCESSOR CARD AND THE P/390: Launched in 1995, the S/390  S/390 PROCESSOR CARD AND THE P/390  S/390 PROCESSOR CARD AND THE P/390  S/390 PROCESSOR CARD AND THE P/390  Processor Card provided an ESA/390 CPU and 32 MB of main storage. This  would be inserted into a MCA-slot-bearing PC or RS/6000, but a PCI  version came later. There was a third version called the P/390E that  featured 256 MB of storage, and a 1 GB P/390 (these are extremely  rare) was also made.  S/390 INTEGRATED SERVER: In November 1998, IBM launched a machine  S/390 INTEGRATED SERVER  S/390 INTEGRATED SERVER  S/390 INTEGRATED SERVER  that was a Pentium II server (uniprocessor) with a P/390 card. This  so-called Integrated Server used the same chassis as the MP3000, but  had less performance; it did, however, have the ESCON and parallel  channel capability. Alas, this machine was not very performant and did  not sell well.      8 Mainframe History »   SYSTEM Z  SYSTEM Z  SYSTEM Z  SYSTEM Z  Seeing that the ESA/390 architecture was aging in the late 90s and was  still handicapped by the 2 GB storage limit (bought about by the  31-bit address space introduced with the 370/XA line), IBM sought a  upgrade. This was developed in 1999 as "ESAME" (ESA Modal Extensions),  but was eventually renamed to the z/Architecture. The machines from  this line are known as System Z, and the first one was the zSeries  z900. Based on the earlier 9672 G6, this machine launched in December  2000 with either 12 or 20 processors (16 of which could be defined as  central processors, with the leftovers being reserved for I/O duties).  The z800 (lower-end than the z900) would launch in 2002 to provide a  lower-end model; all of the original zSeries machines before the z14  could still operate in ESA/390 mode. Even then, a superscalar Z CPU  did not exist until October 2003 -- the machine that introduced this  (the z990) was a complete redesign of the Z CPU (that featured new  features like out-of-order execution, NUMA, etc) that was not based  off of the earlier 9672 architecture.  The System z9 was released in July 2005, bearing the earlier new Z CP  but with many upgrades. The zAAP acceleration engine was added, which  accelerated Java applications. There were two lines launched: the z9  Business Class and the z9 Enterprise Class (with the z9EC being the  bigger of the two). This would also be the case for the z10, which  launched in February 2008 (EC) and October 2008 (BC); the z10 was  codenamed the "eclipZ" as its clock speed was supposed to eclipse the  _______  commonly-available PC servers at the time.  The successor to the z9 and z10 was the zEnterprise line, of which  there were 4 submodels. Launched in July 2010, the z196 was the  enterprise-class machine (clocked at 5.2 GHz) whereas the z114 was the  business-class machine (clocked at 3.8 GHz). The z114 came in two  physical varieties: the book-style machines had the same physical con-  figuration as the late-generation 9672 machines, whereas the non-book  configuration was native to the z114.  As hardware development rolled on, the z13 launched in 2015 to great  avail. Though the CPU clock speed did not meaningfully increase, the  cache and memory controller were improved. This generation also added  a new variant of the Vector Facility, modelled somewhat after SSE on  Intel/AMD x86 CPUs. The steady architectural improvements made around  this time started to solidify the System Z line as a rather fast com-  puter, as opposed to the earlier view of "lots of I/O, but a weirdly  slow CPU." The processor elements drove DDR3 RAM, in an array somewhat  like a RAID disk array.  Scoring a 30% total-chip (with a 10% per-core) speedup, IBM unveiled  the z14 in July 2017. Of note was the massive die shrinkage; the z13  was fabricated on a 22nm die process, and the z14 was fabricated on  the then-new 14nm process -- this meant better power efficiency! Each  processor package could have up to 10 active cores, and each core sup-  ported two-way simultaneous multithreading (readers may be familiar  with Intel's HyperThreading scheme, this is similar). Rather than  doing what IBM had been doing for years and having dedicated Crypto   Mainframe Hardware 9 »   Express cards, the z14 processor elements now had their own  cryptographic processors (called CPACFs)... for each core!  The new vector facility introduced one generation before gained  packed-decimal SIMD support (which boosted the performance of COBOL  and PL/I applications that were somewhat vectorized), and the memory  controller was replaced with a DDR4 one. Around this time, IBM added  support for System Z to upstream LLVM/Clang, and this included native  support for the z14.  Gaining more and more performance (and also more and more modularity),  the z15 was announced in September 2019. Doubling the cache sizes and  gaining a new data compression coprocessor (similar to the earlier  crypto coprocessors), the number of processing elements per package  grew to 12. These sold somewhat well, and were noted to be rather  performant compared to their predecessors.  In 2021, when AI was starting to become a big thing that caused every  company to shift their marketing focus to it, IBM announced the z16  (with the CPU being called the "Telum") and made it available for pur-  chase in 2022. This was the first CPU to contain a crypto coprocessor,  vector coprocessor, compression coprocessor, and now a neural network  coprocessor! These were programmed with instructionns called NNPAs  (Neural Network Processing Assists) and were implemented at a very low  level. Though nobody rushed out to buy mainframes to train and run AI  models on, the reliability of the processors (and their newfound  ability to run ML inference during normal z/OS operations) led many Z  customers to consider (and often follow through with) adding ML fea-  tures to various applications.  Seemingly not much more performant than the z16, the z17 (launched in  April 2025) gained more support for ML features. In the mid-2020s, AI  chatbots and assistants were all the rage; IBM grew their earlier AI  support but targeted it for true business workloads (analyzing medical  images, computing the risk of lending out a loan, things like that).  As if the CPU was not already accelerated enough, the Spyre ML accel-  erator was released alongside the z16, and was a PCIe card that worked  tightly with the host CPU to accelerate ML workloads.   EMULATION  EMULATION  EMULATION  EMULATION  Throughout the years, there have been several attempts to emulate the  z/Architecture as a logical successor to the P/390. Here are some of  the extant emulators:  FLEX-ES: Fundamental Software launched an emulator in 2005 that was  FLEX-ES  FLEX-ES  FLEX-ES  tightly-controlled and tightly-licensed, and is the only emulator that  IBM has licensed for production workloads. In the mid-2000s, an Intel  PC-based server could easily outperform an old System/390 (especially  an old low-end ES/9000), so IBM ensured FLEX-ES was somewhat difficult  to acquire.   10 Mainframe History »   ZPDT The zPDT is actually a family of emulators:  ZPDT  ZPDT  ZPDT  ź The zPDT proper  ź ZD&T Personal Edition  ź ZD&T Enterprise Edition  The original zPDT is a PartnerWorld ISV offering that allows customers  to run z/OS 1.6, z/VSE 4.1, and z/TPF (all listed versions are "and  future versions"). This is intended only for application development,  and is not licensed for production workloads; strangely enough, it is  against the license terms to publish benchmarks of the zPDTs.  The ZD&T (of which there is also an Enterprise and Personal Edition)  is intended as a, as its name expands out to, as a "Z Development and  Test environment. Many hobbyists petitioned IBM to produce ZD&T Per-  sonal Edition, the result of the infamous "IBM Corporation mainframe  hobbyist license" quest of the early 2020s. Like the zPDT, this runs  on x86_64 Linux. There is, however, a ZD&T Enterprise Edition, as well  as a System Z version that utilities KVM on Linux -- this version  allows native speed execution of System Z OSes while emulating storage  and network devices entirely on a Z host. The original zPDT has the  CPU model number of 1090, and the ZD&Ts have a CPU model number of  1091 (that is, the CPU model number returned to the guest OS).  In 2025, IBM (to much controversy) discontinued the zPDT products in  favor of a new cloud-hosted platform. Many people found this to be a  tone-deaf move on the part of IBM, but few have an underlying under-  standing of the new software stack. In reality, the new zPDT replace-  ment is actually a System Z version of the zPDT that runs its  workloads under KVM (on Linux). All of the I/O devices are emulated,  and, when the "zPDT Enterprise Edition" was released, people discov-  ered that it provided a way to run z/OS on systems without CKD DASD  (which, surprisingly, is a major issue in the mainframe community for  some people -- some people have mainframes that use the built-in zFCP  fibre channel adapter and create emulated FBA DASD drives under z/VM).  This is because, as mentioned, all I/O devices are emulated on this  System Z zPDT.  HERCULES: Seeing a need for a good open-source emulator for the 360  HERCULES  HERCULES  HERCULES  line, Roger Bowler started the Hercules project in 1999. Many other  people would contribute to it over the years, and the current most-  advanced version is "SDL 4.x Hyperion." It should be noted that  Hercules is famously "not legal"  for running production workloads on, and its surprisingly good per-  formance on modern machines has caused IBM to fear it since its incep-  tion; there are many stories floating around the community of IBM  cracking down heavily on Hercules installs on IBM corporate computers,  as well as fearmongering in the community that running  hobbyist/personal installs of IBM OSes on Hercules is sure to result  in trouble; there are, of course, companies in the wild that have been  known to (at least temporarily) run a production workload on Hercules  (at least as a failover option). Since the P/390, zPDT/ZD&T, and   Mainframe Hardware 11 »   Hercules all use the same DASD image file form (which is sometimes  even found on real DASD arrays, the likes of which can be found in the  S/390 IS, the MP3000, and the Bustech DASD emulation products).  Hercules has had an interesting history. Over the years, IBMers have  constantly derided it as "piracy," but many mainframe hobbyists have  found it an indispensable tool (as running an early System/370 in your  house is simply not a feasible thing to do, and P/370s are very rare).  In the early 2000s, many mainframers (in the so-called real world,  i.e. real mainframe customers) started to evaluate using the emulator  as a disaster recovery platform. Not before long, some companies real-  ized that it outsped low-end System/390 machines (like the Integrated  Server 3006) on reasonably-fast computers... and promptly realized  they could save a decent bit of money by running their workload on an  emulator. Since it used the same DASD image format as all of IBM's  emulated DASD systems (like the P/390 and similar), migration was not  difficult -- you could also use real SCSI tape drives with Hercules  and restore dumps of something like a period-accurate DASD array to  the emulated disks.  TURBOHERCULES CONTROVERSY: 2009 marked the peak of IBM's efforts to  TURBOHERCULES CONTROVERSY  TURBOHERCULES CONTROVERSY  TURBOHERCULES CONTROVERSY  crush Hercules when one of the key Hercules developers (Roger Bowler)  founded a company in France called TurboHercules. This enhanced  version of Hercules was not only much faster (scoring apparently over  3200 MIPS on an 8-processor Intel Nehalem system clocking in at no  more than 3 GHz), but unbelievably cheap. As such, Bowler asked IBM to  start licensing z/OS to run on TurboHercules in July 2009. IBM did not  take kindly to this; they became to be rather scared, and, in March  2010, TurboHercules began to file a complaint with the EU regulators.  Bowler's company argued that IBM was in violation of EU antitrust  laws, as IBM was limiting their OSes to only run on IBM hardware.  Surprisingly, Microsoft actually invested in TurboHercules in November  2010. Unfortunately, the EU government's probe into the antitrust  allegations was closed in September 2011... with no action whatsoever.  The company would end up fizzling out (certainly under major threat  from IBM), but TurboHercules's motives live on. Most small VSE systems  could likely be migrated to run on Hercules if 21st Century Software  (the current owners of the VSE line) would allow customers to do so.        12 Mainframe History »   MAINFRAME PERIPHERALS  MAINFRAME PERIPHERALS  MAINFRAME PERIPHERALS  MAINFRAME PERIPHERALS  _____________________    DASD DISK DRIVES  DASD DISK DRIVES  DASD DISK DRIVES  DASD DISK DRIVES  Mainframes were (and still are) well-known for their rather large  amounts of disk storage. On the IBM System/360 family, the DASDs (that  is, Direct Access Storage Device) are of a CKD (count-key-data) archi-  tecture. Unlike the HDDs and SSDs you are likely used to, CKD DASDs  used a format wherein each data record stored on the disk could vary  in length. This meant efficient utilization of disk surface area and  good feature support for the record-oriented storage interfaces  present on the mainframe OSes.  S/360 GENERATION: The first hard disks introduced with the System/360  S/360 GENERATION  S/360 GENERATION  S/360 GENERATION  were adapted from the earlier 7090 peripheral set; these included:  2302, an adapted IBM 1302 disk modified to work with the 2841 disk  2302  2302  2302  ____  control unit, and was introduced in 1964. 112 MB.  _______  2311, a similar device that used a removable disk pack. Announced  2311  2311  2311  ____  alongside the 2302, it hooked up to the same control unit and several  manufactures built compatible units. 7.5 MB.  _______  2314, a 9-drive array introduced on 22 April 1965. Looking somewhat  2314  2314  2314  ____  like pizza ovens, the removable-back disk design quickly became a  success for IBM (and other manufacturers who wished to make compet-  itive products). This disk storage system quickly became the default  disk array of the System/360, and its large size combined with high  reliability (for the day) set the stage for IBM's future dominance in  hard disk technology. IBM later released the 2319, which was a 2314  with one drive assembly missing that was announced in 1970. The  purpose of this product is unclear; it had a much lower rental price  than the 2314, and could directly attach to the integrated storage  controller on the System/370 135 or 145. 29 MB per module.  _________________  S/370 GENERATION: By the time the System/370 was available, hard disk  S/370 GENERATION  S/370 GENERATION  S/370 GENERATION  technology had come a long way. These new disks included:  3330, the new disk drive array for the S/370. Announced in June 1970,  3330  3330  3330  ____  the product line also launched with a new controller (the 3830); each  controller could operate up to 8 disks. The second model of this  product (launched in August 1972) introduced the 3333, which included  a disk string control unit (a "string" being a rack of up to 8 drives  in a row sharing a controller); this meant the string itself did not  have to directly connect to the 3830 control unit. The 3330 line also  introduced a real-time error-correcting code, making the product even  more reliable than the 2314. IBM launched a double-density version of  the 3330 (3330 Model 11) in 1973. 100 MB (single density), 200 MB  ____________________________________  (double density).  _________________   Mainframe Peripherals 13 »   2319, which was a 2314 with one drive assembly missing that was  2319  2319  2319  ____  announced in 1970. The purpose of this product is unclear; it had a  much lower rental price than the 2314, and could directly attach to  the integrated storage controller on the System/370 135 or 145. 29 MB  _____  per module.  ___________  2305, a fixed-head storage drive that was often (incorrectly) called a  2305  2305  2305  ____  "drum", introduced in 1970. Unlike other DASDs we will discuss, this  used its own model of control unit (the 2835) and was constructed such  that there was a fixed head above every track on the disk. The disk  assembly looked rather odd, and this device was not replaced by any  other similar device. These were very sought-after on the System/370  Advanced Functions systems, where the virtual storage features allowed  for paging out to disk; the faster the disk, the faster the machine.  The seek times on these are surprisingly low: 2.5 milliseconds on a  single-density model, and 5 milliseconds on a double-density model.  5.4 MB (single-density), 11.2 MB (double-density)  _________________________________________________  3340, a fixed-disk (i.e. non-removable) disk subsystem famously  3340  3340  3340  ____  called the Winchester (with a 30 MB capacity and an average 30 milli-  second seek time, people joked that it shared a number with a  Winchester rifle) introduced in March 1973, any of the disks can  function as the head of a disk drive string (but the 3344 that was  launched alongside the 3340 could not serve as a string head,  requiring attachment to a 3340). The disk modules were removable, but  the disks were not; that is, when you took the disk apart, you could  remove the storage mechanism but not extract the disks from the head  assembly. The hardware design this disk pioneered became the standard  for later disks (especially those of smaller design): since the heads  were always over the disk, the disk could spin down and stop while the  heads were parked as close as possible to the center hub of the disk  platter stack. This would be replicated by hard disks in PCs later,  hence the colloquial term for a PC hard drive that was common in the  80s: a "Winchester disk." Introduced in March 1973, and was compatible  with the 3830 Model 2/3 from the earlier 3330. 34.9 MB (single-  ________________  density), 68.9 MB (double-density).  ___________________________________  3350, an evolution of the 3340 introduced in 1975 -- they even looked  3350  3350  3350  ____  the same. Each disk was actually two disk units side-by-side, iden-  tifiable because every other unit in a string will have a power  switch. There were several models of this disk (all with the same  capacity): A2, A2F, B2, B2F, C2, and C2F. The A2 and A2F disks had an  additional circuit board mounted in them that allowed them to function  as the head of a disk string; this functionality could be enabled or  disabled with a switch. All strings would start with an A2/A2F disk,  and then could be followed by up to 3 B2/B2F disks or 2 B2/B2Fs with  or  or  or  __  one C2/C2F. The C2/C2F disks were special: they contained an extra  controller that functioned as a hot-spare (the disk units had no such  hot-spare functionality; this would only be seen with later disks  backed by RAID arrays) if the controller circuitry in the A2/A2F  failed. The "F" models featured a fixed head that remained stationary  over the first 5 cylinders of storage; the clever systems programmer  would position a JES2 checkpoint dataset, TSO swap dataset index   14 Mainframe History »   region, or MVS paging dataset index region and get a cheap performance  boost. 317.5 MB.  _________  3375, a CKD version of the 3370 (discussed below). The controller cir-  3375  3375  3375  ____  cuitry was slightly different, but otherwise unchanged. 409.8 MB.  _________  S/370 GENERATION FBA: Something new was introduced for the IBM  S/370 GENERATION FBA  S/370 GENERATION FBA  S/370 GENERATION FBA  4331/4341 in January 1979: a vastly simpler architecture of disk that  used fixed-byte sectors (hence the acronym Fixed Block Architecture).  These are of the same design as standard PC HDDs (and their emulatory  counterpart SSDs). MVS required CKD DASD, but VM, VSE, MUSIC, Linux,  and AIX/ESA could use FBA disks instead. For some customers, this  saved a lot of money; for others, it was a headache, as it meant they  were stuck probably running VSE and unable to easily upgrade to MVS.  3370, the first FBA disk introduced alongside the 4331/4341 (and also  3370  3370  3370  ____  the System/38). Interestingly enough, it was the first hard drive to  ever use the thin-film-head technology that is now standard on HDDs.  These connected to an integrated DASD controller within the 4331/4341.  285.6 MB (model A1/B1), 364.9 MB (model A2/B2)  ______________________________________________  3310, a FBA DASD for the 4331. Launched in January 1979 alongside the  3310  3310  3310  ____  3370, these also attached to an integrated controller on the 4331; not  many of these were sold. 64.3 MB.  ________  9332/9335/9336/0671, some FBA disks seen alongside the 9370. These  9332/9335/9336/0671  9332/9335/9336/0671  9332/9335/9336/0671  ___________________  were SCSI disks announced in October 1986, and were attached to the  host computer using IPI. The 9332 used an IBM 0667 SCSI disk; the 9335  used its own disk; the 9336 used an IBM 0681 SCSI disk. The 0671 was  a bare SCSI disk, attached to an IPI protocol translator (much like  the rest of these disks), and then attached to the host computer. 9332  ____  = 184 MB (single-density) or 284 MB (double-density), 9335 = 412 MB,  ______________________________________________________________________  9336 = 471 MB (single-density) or 856 MB (double-density), 0671 = 319  ______________________________________________________________________  MB  __  S/370 XA GENERATION: While 3350s were often still used on the 370/XA  S/370 XA GENERATION  S/370 XA GENERATION  S/370 XA GENERATION  mainframes, the most dominant model used during this hardware gener-  ation was the...  3380, a large disk introduced in June 1980. The disks were constructed  3380  3380  3380  ____  in a rather interesting way: each disk unit itself held two actuator  mechanisms, and those could access up to 630 MB; put together, both  provided a capacity of 2.52 GB per disk unit (for the confused, this  resulted in each physical disk being split into two volumes, so, the  OS would see two DASDs at two sequential addresses of 630 MB each).  There were manufacturing issues (specifically with regards to lubri-  cation), so the first disks shipped in October 1981. The string con-  figuration was similar to the 3350, wherein a model A disk could start  a string and attach to up to 4 model Bs. This product was also intro-  duced along with a new storage controller: the 3880. When properly  configured, a 3380/3380 pair could process two I/O operations simul-  taneously! A double-density model was introduced in February 1985, and  a triple-capacity model was introduced in August 1987. If connected to  the later 3990 control unit, it is possible to get a quad-path string   Mainframe Peripherals 15 »   (which can handle 4 operations simultaneously). There were three types  of models of 3380: the model As could start strings and be string  members, the model Bs are string members, and the model Cs are special  model As that have in-built controllers and can therefore attach  directly to a parallel block channel (i.e. a bus-and-tag cable). 630  ___  MB (A/B/C), 1.26 GB (E), 1.89 GB (K)  ____________________________________  SYSTEM/390 GENERATION: The S/390 saw the last physical mainframe  SYSTEM/390 GENERATION  SYSTEM/390 GENERATION  SYSTEM/390 GENERATION  disks that implemented low-level CKD (humorously called a SLED, a  Single Large Expensive Disk). There were a few landmark products seen  here:  3390, a series of disks that used pressurized sealed disk assembles  3390  3390  3390  ____  that were driven with brushless DC motors (as opposed to AC motors,  seen on earlier models); introduced in November 1989. Strings were  also different: a model A was placed in the middle, and up to two  model Bs can be attached to the left and right of it. A model A can  have 4 or 8 disk drives within it, and a model B can have up to 12;  one could then attach up to 2 strings to a 3990 (the new controller  introduced with the 3390) and have a disk subsystem of 64 disks. 946  ___  MB (model 1), 1.82 GB (model 2), 2.83 GB (model 3)  __________________________________________________  9345, an unusual and rare CKD DASD array comprised of specially-  9345  9345  9345  ____  designed 5.25" drives in November 1990. These were part of IBM's  Supercomputing Systems Extensions project, and these were the first  hard drives to use magnetoresistive heads (which is the current  standard today). These attached to the 9340 control unit, and it dif-  fered from a 3390 in the sense that it completely lacked the nonvola-  tile cache. These were often seen on ES/9000 systems. 1 GB (model 1),  ________________  1.5 GB (model 2)  ________________  RAMAC and RAMAC II, two poorly-named products (no relation to the IBM  RAMAC and RAMAC II  RAMAC and RAMAC II  RAMAC and RAMAC II  ___________________  305 RAMAC that was the first hard drive ever), were RAID-5 arrays for  System/390s. There were two versions of both: one model attached to a  3990 Model 6 controller, and another model had an integrated con-  troller. Each unit consisted of a rack with 16 drawers, and each  drawer held 4 drives. These were IBM Ultrastar XP type SCSI drives,  using magnetoresistive heads. There was an interesting design fluke  with these; each 3990-6 controller could only connect to one  RAMAC/RAMAC II array, and could only address up to 180 GB. If you  chose to get the integrated controller model, you'd save about  $75,000, but you would lose a bit of performance and caching provided  by the 3990-6. Since most mainframe shops wished to exceed 180 GB of  disk capacity, and the only option was to buy two controllers, IBM  sold two 3990-6es for the price of one! The RAMAC II launched in July  1995.  These machines held an integrated disk array controller that assembled  3390 volumes from the RAID disk arrays. The controller assembled a  massive array from all of the disks, and there were several SCSI con-  trollers within it to spread the load. The choice of a RAID-5 array  (with the antonym to RAID being SLED) lowered costs significantly, and  _____________  the increased performance meant that ESCON channels could finally be  saturated with throughput with disk operations. Since these could   16 Mainframe History »   handle up to 4 ESCON channels, performance was impressive for the  time. This technology would become the foundation for future RAID  arrays IBM provided, and rumors swirled about a RAMAC replacement that  used SSA disks. This would materialize as smaller products found in  the Multiprise line first, and would get its release 5 years in the  future.  Multiprise 2000 Disk Array, and you can probably guess which  Multiprise 2000 Disk Array  Multiprise 2000 Disk Array  Multiprise 2000 Disk Array  ______________________________  System/390 it was found in. Remember, the Multiprise 2000 was a cut-  down System/390 Parallel Enterprise Server, and the integrated disk  array consisted of two rackmount parallel SCSI disk enclosures that  held a total of 16 disks. Two I/O cards would be inserted into the  S/390 CPU's I/O card cage -- one with 68-pin SCSI connectors, and  another with control logic in it. These were essentially cut-down  derivatives of the RAMAC II, and functioned in the same way. The way  the S/390 CPU accessed the disks was also interesting: when the  channel path was defined, it would be defined as an IBM CorporationSD"  (a Internal System Device). When the CPU was initialized, it would  begin to directly communicate with the disk controller cards without  any intermediary ESCON channels.  Multiprise 3000 Disk Array, the successor to the Multiprise 2000, also  Multiprise 3000 Disk Array  Multiprise 3000 Disk Array  Multiprise 3000 Disk Array  __________________________  had a revamped disk array. As mentioned in the section on the MP3000,  this was done by having an IBM SSA (which was big at the time, SSA  stands for Serial Storage Architecture and was the engineering pre-  cursor to technologies like SATA and SAS) controller present on the  PCI bus within the cabinet. When the mainframe CPU is initialized, it  grabs control of the card through a card on the PCI bus called a  "camel card" (for the confused, the S/390 CPU would talk to the camel  card, and that would allow it to talk to both the emulated devices on  the Support Element and the SSA RAID card). Disk I/O operations were  done by the S/390 CPU itself, and this reduced the hardware demands.  SSA disks were much faster than the older parallel SCSI disks, and  each 18.2 GB disk within an array (the MP3000 cabinet could accomodate  two arrays, with more attachable externally) summed to about 73 GB per  array. While the S/390 CPU was running, the OS/2 Support Element would  have to communicate with the S/390 CPU (through the camel card) to  configure the array; the array could be configured with the  OS/2-native SSA configurator program while the S/390 CPU is stopped,  however. The lessons learned from the RAMAC II, MP2000, and MP3000  disk arrays would all be orchestrated together in the successor  product.  SYSTEM Z GENERATION: When the System Z came out, the RAMAC II was  SYSTEM Z GENERATION  SYSTEM Z GENERATION  SYSTEM Z GENERATION  seen as obsolete. Improvements had been made, and the most impressive  (performance-wise) of those improvements came from, of all things, the  Multiprise 3000's array. Despite it not sounding like much, it was a  truly impressively performant solution for the time. There were two  models of disk server that followed this:  The Versatile Storage Server, released in 1998, was a transitional  Versatile Storage Server  Versatile Storage Server  Versatile Storage Server  __________________________  product that bridged the engineering gap between the RAMAC and what  came next. This was developed concurrently with the MP3000 disk array,  and was an adapted/enlarged version of that technology (minus the bus-   Mainframe Peripherals 17 »   mastering PCI SSA RAID card). The 2105-B09 VSS held up to 64 SSA  disks, and these were attached to some VSS storage processors that  provided an ESCON interface. If 64 disks wasn't enough, the customer  could also purchase the 2105-100 expansion rack: this held 112 disks.  While a commercial failure, it would see its primetime in the subse-  quent product.  The Enterprise Storage Server, often called the Shark, was truly an  Enterprise Storage Server _____  Enterprise Storage Server  Enterprise Storage Server  ___________________________  impressive product. For one, this was not just a mainframe storage  array! The ESS model F10 and F20 could be equipped with a variety of  host adapters (that is, a peripheral interface circuit card that pro-  vided an emulation of a disk; for example, it could be a "SCSI  target", and show up as a number of disks to the attached computer).  You could use:  ź UltraSCSI (i.e. SCSI Ultra-3/SCSI-160)  ź Fibre Channel (original 1.25 gigabit Fibre Channel)  ź FICON, the new System Z peripheral interface  ź ESCON, since many System/390s were still in use when this product  launched  The architecture of this was a modular evolution of all of the tech-  nology IBM had sold to that point. The ESS consisted of two clusters,  able to communicate with each other through a shared cache. Each  cluster attached to up to 4 device adapters, and these attached to the  SSA disk loops in a rather odd fashion. Since an SSA loop had a  ring-in and ring-out port, cluster A device adapter 1 connected to  ring-in, and cluster B device adapter 1 connected to ring-out. The  clusters connected to a Common Parts Interconnect bus that attached to  the host adapters seen in the above list.  The controller could assemble RAID arrays from the disks and export  volumes, or the disks can be directly exported to the host adapter  (just not in CKD ESCON mode, since that required DASD emulation, only  in FBA mode). AIX and TPF both had measures to mirror disks/recover  from failures, so the slight performance boost afforded by this tech-  nique was worth it for some customers.  The ESS was a hit, not just for mainframes, but also broke through to  other storage demand markets. People used these on AS/400s (as they  supported the sector sizes required for such a thing), high-end UNIX  machines from Digital/Sun/HP/Data General/Silicon Graphics, PC-based  servers running Windows NT or NetWare, and even those Sequent SMP  NUMA-Q minicomputers. Multiple computers could even be placed on the  same SCSI bus, simply by changing the SCSI ID of each host adapter;  this let users get even more out of the systems.  Providing a path forward from the ESS line was the DS6800, DS8100, and  DS6800, DS8100, and  DS6800, DS8100, and  DS6800, DS8100, and  ___________________  DS8800 series, with one of those being significantly better than the  DS8800 series  DS8800 series  DS8800 series  _____________  other. There were many hardware revisions of the DS8800 line (10 at  the time of writing this), and these consisted of POWER servers fitted   18 Mainframe History »   with HBAs driving a rack of disk drives, and forking those connections  out over Fibre Channel, FICON, or (on older models) ESCON.  The DS6800 (called the "Baby Shark") was a questionably-designed 3U  disk array that could be attached to a System Z. These were intended  to be low-cost, and featured a PowerPC 750GX-based Linux-powered  control computer on-board. These units took direct Fibre Channel disks  (despite their name, they did not have SFP connectors; in fact, they  were essentially SCSI320 drives that spoke the FC protocol directly  instead of parallel SCSI). However, these units were notorious for  their failures, because the control CPU was not properly cooled. Some-  times, these would end badly, with the CPU becoming physically  desoldered from its mount!   TAPE DRIVES  TAPE DRIVES  TAPE DRIVES  TAPE DRIVES  While disks were certainly heavily used on the 360 line, tapes were  where the real mass storage was at. Predating disks, the history of  mainframe tape drives is as old as computing itself! However, the  tapes we are interested in are half-inch plastic-base dense-oxide  __________________________________  reels seen starting in the early 1950s. IBM pioneered the early  7-track format in 1952, with the model 726 tape drive (seen on the 704  7-track format  7-track format  7-track format  ______________  mainframe.  These drives were called "vacuum-column" drives, since there were two  long vertical columns the tape would unroll into (with the head being  in the middle). In other words, the tape would snake off the supply  reel (the one you removed when you took the tape out), down column 1,  up the other side of column 1, past the tape head and capstan mech-  anism, down column 2, up the other side of column 2, and finally onto  the take-up reel. The "vacuum" comes forum the trigger mechanism used  to advance the tape: the most pertinent part to move was the capstan  (which moved the tape left and right on the tape head) and the move-  ment of the tapes within the columns would trigger the motors on both  reels. When the tape level in the vacuum raises above a certain  threshold (marked by a hole in the back of the column), the vacuum  drawn on the tape will be exposed to that hole. A vacuum switch (not  unlike the force-multiplying pneumatic mechanism seen on player  pianos) triggers the motors, and the tape advances either directions  (depending on which of the two columns triggered).  Needless to say, the 726/727/728/729/7330 7-track tape drives were a  big hit before the System/360. Once the 360 came out, we got the fol-  lowing tapes:  2400 SERIES: Though the 7-track format was good, IBM launched a newer  2400 SERIES  2400 SERIES  2400 SERIES  9-track format in 1965 with the S/360. The new 2400 series included  several submodels, and several submodels of controllers. I shall list  the controllers first:  ź 2803 Model 1/2: can control and power up to 8 drives  ź 2803 Model 3: can control and power up to 8 2401-8 drives   Mainframe Peripherals 19 »   ź 2804 Model 1/2: can control and power up to 8 drives, with one  reading and one writing at the same time  ź 2804 Model 3: can control and power up to 8 2401-8 drives, with  simultaneous read/write support  The following 2400 drives were made:  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Table 1. IBM 2404 Drive Models |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Ż Ż Ż |  | Model | Tracks | Modulation | Density/Speed |  Model Tracks Modulation Density/Speed  Model Tracks Modulation Density/Speed  Model Tracks Modulation Density/Speed  _____ ______ __________ _____________  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 1 | 9 | NRZI | 800, 30kbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 2 | 9 | NRZI | 800, 60kbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3 | 9 | NRZI | 800, 90kbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 4 | 9 | PE | 1600, 60kbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 5 | 9 | PE | 1600, 120kbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 6 | 9 | PE | 1600, 160kbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 1 | 7 | NRZI | 200/556/800, |  | | | | various |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 2 | 7 | NRZI | 200/556/800, |  | | | | various |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3 | 7 | NRZI | 200/556/800, |  | | | | various |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 2401-8 | 7 | NRZI | 200/556/800, |  | | | | various |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż ż  For the confused, NRZI is a non-return-to-zero-inverted encoding, and  PE is a phase encoding (these are modulation modes used to record and  read the data on the tape as an analog signal).  There was an alternate controller available that offered much better  performance with newer tape drive: the 2415. There were 6 submodels:  2415  2415  2415  ____  ź Model 1: NRZI, 1 control, 2 tapes  ź Model 2: NRZI, 1 control, 4 tapes  ź Model 3: NRZI, 1 control, 6 tapes  ź Model 4: PE, 1 control, 2 tapes  ź Model 5: PE, 1 control, 4 tapes   20 Mainframe History »   ź Model 6: PE, 1 control, 6 tapes  2420 MODEL 7: Evolving from the earlier 2400 series, the 2420 (spe-  2420 MODEL 7  2420 MODEL 7  2420 MODEL 7  cifically the Model 7) introduced a very clever feature: an  automatically-loading tape mechanism! The operator placed a tape on  the right spool (as was customary, note that this is conventionally  backwards to reel-to-reel audio tape recorders, reel-to-reel VTRs, and  such seen in the broadcasting world), pushed a button, and the machine  would release a belt that spanned the circumference of the tape reel  to access the tape. To thread the tape, the machine would pull the  tape off the reel pneumatically and run it through the machine (of  course, it would drop it down through the vacuum columns too). This  technology would live on in the successor, and was the envy of other  tape drives from DEC and CDC that used the same format!  3400 SERIES: When the System/370 was announced in 1970, it included a  3400 SERIES  3400 SERIES  3400 SERIES  new tape drive line. The 3400 series would be that successor: the 2420  autoloading scheme would be adopted for the 3400 series, and a new  recording mode would be added. The new drives ran at a whopping 1.25  megabit transfer rate! As before, there were a variety of models:  ź 3420: floor-standing vacuum-column units  ź 3410: half-height-standing units  ź 3422: follow-up to the 3420  ź 3430: follow-up to the 3422  Now, let us examine the model characteristics:           Mainframe Peripherals 21 »   ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Table 2. IBM 3400 Drive Models |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Ż Ż Ż |  | Model | Modulation | Density (bpi) | Speed |  Model Modulation Density (bpi) Speed  Model Modulation Density (bpi) Speed  Model Modulation Density (bpi) Speed  _____ __________ _____________ _____  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3420-3 | NRZI or PE | 800 or 1600 | 75 ips |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3420-5 | NRZI or PE | 800 or 1600 | 125 ips |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3420-7 | NRZI or PE | 800 or 1600 | 200 ips |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3420-4 | GCR | 6250 | 1.25 mbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3420-6 | PE or GCR | 1600 or 6250 | 1.25 mbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3420-8 | PE or GCR | 1600 or 6250 | 1.25 mbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3410-1 | PE | 1600 | 20 kbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3410-2 | PE or NRZI | 1600 or 800 | 40 kbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3410-3 | PE or NRZI | 1600 or 800 | 80 kbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3422 | GCR | 6250 | 1.25 mbps |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3430-B01 | GCR or PE | 6250 or 1600 | 312 or 80 |  | | | | kilobytes/second  |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż ż  There were a variety of controllers produced for this line of tapes:  ź 3803-1: 3420 Model 1/3/5  ź 3803-2: 3420 Model 4/6/8  ź 3411: 3410 (drives up to 4 drives)  ź 3430-A01: 3430-B01 (drives up to 3 drives)  8809 AND 9347: The 8809 was released in the mid-80s, and it was a  8809 AND 9347 8809  8809 AND 9347 8809  8809 AND 9347 8809  ____  9-track manual-thread drive that did not utilize a vacuum column.  These units were very compact, and decently fast; alas, they were low-  cost and only used the 1600 bpi density mode. This drive was ori-  ginally for the System/36, but could be connected to low-end models of  the 4300 series.  Somewhat of a technical miracle, the 9347 was an auto-loading, flat-  9347  9347  9347  ____  mount, rack-mount, thin 9-track reel-to-reel drive. You inserted the  tape, and a complex loading mechanism pneumatically sucked the tape  off the reel, ran it through a predefined path, and spun it onto the  take-up reel. These drives did not use vacuum columns, and instead  used a springloaded armature mechanism to alleviate tension. These  were SCSI-interfacing, and were seen with the 9370 series. These were   22 Mainframe History »   1600 or 6250 bpi. Note: the AS/400 line had the 9348, a very similar  __________________________________________________  drive.  ______  3480: While reel-to-reel drives were great, they were not partic-  3480  3480  3480  ularly compact, especially in the 1980s when everything else was  beginning to shrink. IBM's answer to this was the 3480: a cartridge  tape drive. By 1984 when the 3480 launched, cartridge tapes were  standard in all other tape formats: Stereo-8 (i.e. 8-track) tape  players were seen in cars, cassette tapes were all the rage,  VHS/Betamax and U-Matic held video, so on and so forth.  The original 3480 tapes were half-inch square tapes, rolled entirely  on a supply reel within the cartridge. The tape formulation changed to  a chromium dioxide powder (the same used for video tapes of that era  and "high bias" cassette tapes, marked CrO2). When the square car-  tridge was inserted into the drive, an armature loading mechanism  would pull the tape out of the cartridge, past the head assembly  (which was a new magnetoresistive design, sharing technology with hard  disk drives of the era, like the 3380 DASD), and onto the internal  take-up reel.  The original 3480 drive launched in 1984, and was attached to a  System/370 with a parallel channel interface. The drive had a transfer  speed of 3 megabytes per second, recorded with a 38000 BPI density  onto 36 tracks, and the tape passed the heads at 78.6 inches per  second. To avoid buffer-fill issues, a 512KB buffer was provided. The  controller box drove up to 4 drive units, which each contained 2 tape  drives (so, a total of 8 drives). The cartridges held 200 MB.  Successor drives to the 3480 series added ESCON support (though these  were 3490Es, see below); other manufacturers (namely Fujitsu) made  fully-compatible SCSI implementations of the 3480/3490E drives.  In 1986, a new model of 3480 came out: the 3480 IDRC, for Improved  3480 IDRC  3480 IDRC  3480 IDRC  __________  Data Recording Capacity. While this may sound like an increase in  density, it was actually an improvement in controller electronics: it  was a data compression scheme that allowed up to 400 megabytes to be  stored on a tape assuming 2:1 compression.  3490E: The successor to the 3480 was the 3490E, launched in 1991.  3490E  3490E  3490E  These drives almost universally had autoloaders that fed cartridges  into the drives from a stack, and connected via channel, SCSI, or  ESCON. The original model was the 3490-B40 with the 3490-A20 external  3490-B40 3490-A20  3490-B40 3490-A20  3490-B40 3490-A20  ________ ________  controller box. Each tape held 800 MB.  There was also an IDRC capability for the 3490E; these upped cartridge  capacity to 2400 MB (and these drives were almost universally attached  using ESCON).  3590: In 1995, the IBM Magstar product hit the market. This was a big  3590  3590  3590  upgrade over the 3490E drives, albeit being much more expensive. There  are many models of 3590 drive, and many controllers; the original con-  troller, the 3590-A50, was actually an RS/6000 that adapted SCSI 3590  3590-A50  3590-A50  3590-A50  ________  drives to ESCON. Here are the models:   Mainframe Peripherals 23 »   ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Table 3. IBM 3590 Drive Models |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Ż Ż Ż |  | Model | Tracks | Length/Capacity| Speed |  Model Tracks Length/Capacity Speed  Model Tracks Length/Capacity Speed  Model Tracks Length/Capacity Speed  _____ ______ _______________ _____  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3590-B11/B1A | 128 | 320m/634m, | 9 |  | | | 10GB/20GGB | megabytes/second  |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3590-E11/E1A | 256 | 320m/634m, | 14 |  | | | 20GB/40GB | megabytes/second  |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3590-H11/H1A | 384 | 320m/634m, | 14 |  | | | 30GB/60GB | megabytes/second  |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż ż  3592: The successor to the 3590 was the 3592, originally launched in  3592  3592  3592  2003. These drives were attached via ESCON or FICON (via a converter,  like the 3590-A50), SCSI, SAS, or USB (depending on the generation),  The following drive models were produced:  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Table 4. IBM 3592 Drive Models |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Ż Ż Ż |  | Model | Year | Capacity | Speed |  Model Year Capacity Speed  Model Year Capacity Speed  Model Year Capacity Speed  _____ ____ ________ _____  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3592 | 2003 | 300 GB | 40 MB/s |  | (3592-J1A) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | TS1120 | 2005 | 700 MB | 100 MB/s |  | (3592-E05) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | TS1130 | 2008 | 1 TB | 160 MB/s |  | (3592-E05) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | TS1140 | 2011 | 4 TB | 250 MB/s |  | (3592-E07) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | TS1150 | 2014 | 10 TB | 360 MB/s |  | (3592-E08) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | TS1155 | 2017 | 15 TB | 360 MB/s |  | (3592-55F/55E) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | TS1160 | 2018 | 20 TB | 400 MB/s |  | (3592-60F) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | TS1170 | 2023 | 50 TB | 400 MB/s |  | (3592-70F/70S) | | | |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż ż  The F/E/S notation on some models listed indicates the attachment  type:   24 Mainframe History »   ź F: Fibre Channel  ź E: Ethernet  ź S: SAS   LINE PRINTERS  LINE PRINTERS  LINE PRINTERS  LINE PRINTERS  1403: The 1403 was the first printer introduced with the System/360  1403 ____  1403  1403  in its original run. This was a chain-type printer, where the font  would revolve around on a chain and be struck onto the paper (with an  ink ribbon between the font train and the paper) by hammers. On the  1403, the paper was pushed onto the font from behind, with the ribbon  remaining stationary on rollers. The 1403 was the line printer that  was introduced for the 1401 computer; the ones available with the  System/360 were of several models:  ź Model 2: 132 column, 600 lines per minute (upgradable to 1285 if  letters were not required to be printed)  ź Model 3: 132 columns, 1100 lines per minute (1400 if the character  set was swapped out)  ź Model 7: 120 columns, 600 lines per minute  ź Model N1: 132 columns, 1100 lines per minute (1400 when swapped  for the Universal Character Set); featured a motor-driven lid  cover that reached down to the floor to deaden the noise  The 1403 had a feature called "carriage control," wherein a loop of  punched tape (positioned to the right of the print train mechanism)  would have a series of pre-punched holes that described the layout of  the "form," or a map of fixed locations on the paper. For example,  the printer could be given a datastream of a few lines of text  seperated by form feed characters, and it would read the carriage  control tape to know where to skip to when a form feed character was  seen. The position of the tape was mechanically interlocked to the  paper train, so its position always matched the paper's.  There was a similar model, the 1404, that had the ability to print  onto punched cards. The mechanism was rather clever, in the sense that  it could interpret cards (i.e. read what's on the cards and print the  data on the top).  2821: The control unit that the 1403 was attached to was the 2821,  2821 ____  2821  2821  which also serviced other devices (which are described in greater  detail below). The following models were available:  ź Model 1: one 2540 and one 1403  ź Model 2: one 1403  ź Model 3: two or three 1403s   Mainframe Peripherals 25 »   ź Model 4: one 2540 and one 1404 (only for the System/360 model 25,  30, 40, and 50)  ź Model 5: one 2540 and two or three 1403s  ź Model 6: one 2540  The 2821 contained enough buffering logic to buffer one card or one  line of text. A switch was present on the cabinet that switched which  of the two channel connectors on the back panel it would use to  connect to the host computer, so you could use it on two different  computers. Strangely enough, the early models of the 2821 were not  implemented using the SLT integrated circuits of the rest of the  System/360 line, but were instead implemented with Standard Modular  System cards (if you've seen the inside of some of the DEC PDP com-  puters with their flip-chip cards, IBM SMS is not far off). Newer  revisions had some SLT logic, but was not made entirely of SLT.  Finally, in 1985, the product was withdrawn.  3211: The 3211 was the immediate successor to the 1403 series.  3211 ____  3211  3211  Launched on June 30, 1970, the original 3211 could print at 2000 lines  per minute (which was double the speed of the extant 1403 models).  Unlike the 1403, the 3211 was a combination of 3 different distinct  devices:  ź The 3211 itself, the main printer; this was referred to as a  "front printer" because the print hammers would bang the ribbon  into the paper, rather than banging the paper into the ribbon  (like on the 1403). The 3211 boasted the following features:  Ś Interchangable type cartridges for a variety of fonts and con-  figurations.  Ś 90 inch-per-second paper movement during form feeds.  Ś 132 columns, changeable to 150 with a replaced type cartridge  Ś A power stacker that processed the printed output  Ś A control panel that did not require the host computer to be  operational for diagnostics and testing  Ś Programmable forms control buffers (FCBs) in lieu of carriage  control tapes  ź The 3216, the print cartridge; these held a total of 432 letters,  of which were organized such that there were 4 letters per type  element (so, the revolving print train had 108 pieces attached to  it). These type slugs were mounted onto the 108 carriers, such  that they could be replaced. The 3216 included an oil-dispensing  system.  ź The 3811, the control unit that attached the printer to the  channel of the mainframe.   26 Mainframe History »   3203: Another option that replaced the 1403 was the 3203, and was  3203 ____  3203  3203  nearly the same mechanism. The carriage control tape mechanism was  removed, and connected to the mainframe in a rather strange way.  Models 1 and 4 did not require an external control unit, and instead  attached directly to the System/370; the caveat was that the S/370 in  question had to have an integrated 3203 controller. The Model 3  attached to a 3770 batch terminal, and the Model 5 had a parallel  channel adapter.  The printers printed at 1200 LPM except for the model 1, which printed  at half that (600 LPM). The 3203 was special for the time as it could  actually print Braille, and this was done by putting a rubber strip  over a special print train font set that could print Braille dots  without punching holes clean through the paper.  In the early 70s, IBM started to explore printer architectures that  did not use a revolving print train of heavy print elements, and  instead used a flexible band. Other manufacturers at the time had drum  printers (like the DEC line printers, like the LP25, though most were  made by Dataproducts), but IBM thought band printers would yield much  better print quality -- drum printers were fast, but the text often  looked somewhat jerky and was not vertically-lined usually.  3618: The first was the 3618, a so-called"Administrative Line  3618 ____  3618  3618  Printer." This printer was 80 columns (upgradable to 132), but was not  a 370 peripheral. Alas, it was announced in 1973.  3262: The 3262 was the first band printer for 370 systems; there were  3262 ____  3262  3262  a variety of models:  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Table 5. IBM 3262 Models |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Ż Ż Ż |  | Model | Interface | Speed | Date |  Model Interface Speed Date  Model Interface Speed Date  Model Interface Speed Date  _____ _________ _____ ____  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 1 | 370 channel | 650 | Jan 30, 1979 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 2 | 8310 loop | 650 | Oct 2, 1979 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3 | 3270 coax | 650 | Oct 31, 1979 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 5 | 370 channel | 650 | Nov 12, 1982 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 11 | 370 channel | 325 | Oct 2, 1979 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 12 | 8130 loop | 325 | Oct 2, 1979 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 13 | 3270 coax | 325 | Oct 31, 1979 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | B1 | System/36 | 650 | May 17, 1983 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | C1 | System/36 | 650 | May 17. 1983 |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż ż   Mainframe Peripherals 27 »   5262: The successor was the 562, launched on October 2, 1984. These  5262 ___  5262  5262  used a different print band from the earlier 3262, and had a print  speed of 650 LPM. Model 1 was twinax-attached, to a System/36.  4245: The high-speed option of the era was the 4245, launched in  4245 ____  4245  4245  1983. The following models were available:  ź Model 1 (May 3, 1983), 2000 LPM  ź Model 12/20 (April 16, 1985), 1200/2000 LPM; features included:  Ś Improved reliability over the Model 1  Ś 64 dB volume during operation  Ś Capable of printing MICR  Here is a convenient table of the models and their attachments:  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Table 6. IBM 4245 Models |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Ż Ż Ż |  | Model | Attachment | Speed | Date |  Model Attachment Speed Date  Model Attachment Speed Date  Model Attachment Speed Date  _____ __________ _____ ____  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 1 | 370 channel | 2000 LPM | May 3, 1983 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 12 | 370 channel | 1200 LPM | April 16, 1985 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 20 | 370 channel | 2000 LPM | April 16, 1985 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | D12 | 3270 coax | 1200 LPM | May 1, 1985 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | D20 | 3270 coax | 2000 LPM | May 1, 1985 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | T12 | twinax | 1200 LPM | June 16, 1986 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | T20 | twinax | 2000 LPM | June 16, 1986 |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż ż  4248: The 4248 was the successor, and was much faster -- it ran at  4248 ____  4248  4248  2000, 3000, or 3600 LPM! Launched on February 7, 1984, the 132 column  (or 168 columns, if you wish to print 2 documents side-by-side at the  same time) printer had a band that travelled at 45 miles per hour,  with hammers that flew through the air for only 30 microseconds.  There were two models:  ź Model 1, the original described above  ź Model 2, launched in February 1987, could print at 4000 LPM.  The 4248 had a program called Automatic Flight Time Compensation that  would measure how long it took the hammers to strike the page, and  store a table of delays on the microcode diskette; it would then use   28 Mainframe History »   that to calibrate the page advancement speed to prevent drifty and  unaligned text issues.  6262: The grand successor to all of these was the 6262, and the fol-  6262 ____  6262  6262  lowing models existed:  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Table 7. IBM 6262 Models |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Ż Ż Ż |  | Model | Attachment | Speed | Date |  Model Attachment Speed Date  Model Attachment Speed Date  Model Attachment Speed Date  _____ __________ _____ ____  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | A12 | parallel/serial | 1200 | Aug 28, 1990 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | D12 | 3270 coax | 1200 | Feb 2, 1988 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | P12 | Dataproducts | 1200 | Oct 24, 1989 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | T12 | twinax | 1200 | Feb 2, 1988 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 014 | 370 channel | 1400 | Feb 2, 1988 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | A14 | parallel/serial | 1400 | Aug 28, 1990 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | D14 | 3270 coax | 1400 | Feb 2, 1988 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | P14 | Dataproducts | 1400 | Oct 24, 1989 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 022 | 370 channel | 2200 | Oct 24, 1989 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | A22 | serial/parallel | 2200 | Aug 28, 1990 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | D22 | 3270 coax | 2200 | Oct 24, 1989 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | P22 | Dataproducts | 2200 | Oct 24, 1989 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | T22 | twinax | 2200 | Oct 24, 1989 |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż ż   CONSOLE PRINTER/KEYBOARDS  CONSOLE PRINTER/KEYBOARDS  CONSOLE PRINTER/KEYBOARDS  CONSOLE PRINTER/KEYBOARDS  1052: The first typewriter console for the System/360 was the 1052-7  1052 ______  1052  1052  (though other models were occasionally used), which was derived from  the 1050 Data Communications System. There were many subparts to the  1050 system (including 1052 typewriter terminals, 1053 printers, 1057  punches, 1056 readers, 1054/1055 paper tape readers/punches, 1092/1093  programmed keyboards, 1058 printing punches, 1051 control units,and  something called the "IBM 2064 FBI Program"). These attached directly  to the System/360 host computer, and were used as OS system consoles.  3210/3215: The successors to the 1052 were the 3210/3215, launched in  3210/3215 _________  3210/3215  3210/3215  late 1970. There were 3 models:   Mainframe Peripherals 29 »   ź 3210 Model 1: used a Selectric printer with a Card Punch keyboard,  capable of directly modifying data in the host computer's storage;  sat upon a table. Powered by the host processor power circuitry.  ź 3210 Model 2: used the same keyboard/printer elements, was not  capable of modifying data in the host computer's storage; sat on a  pedestal and was connected to the host processor via a long remote  cable. Powered by an internal power supply.  ź 3215: used a 7x7 dot-matrix printhead with an Elastic-Diaphragm  keyboard and printed at 80 characters per second; capable of modi-  fying the host computer's storage, was also powered by the host  computer's power circuitry.   CARD READERS/PUNCHES  CARD READERS/PUNCHES  CARD READERS/PUNCHES  CARD READERS/PUNCHES  The System/360 was a batch machine, so the availability of card  readers and punches was a requirement. There were several available:  1442: An extant (at the time of the 360's release) card reader/punch  1442  1442  1442  machine seen on the 1130, 1800, and 1440 computers. The holes in the  cards were illuminated by fiber optics. The punch famously did not  print a textual representation of the cards to the top! A dedicated  card "interpreter" would be used to print those letters that corre-  spond to every column on the card. The following models were made:  ź Model 1: reads at 80 cards/minute, punches at 50-270 cards/minute;  comes with one stacker (with a second one being optional).  ź Model 2: reads at 400 cards/minute, punches at 91-360 cards/minute  ź Model 6: reads 300 cards/minute, connects to a System/3 or 1130  ź Model 7: reads 400 cards/minute, connects to a System/3 or 1130  ź Model N1: reads 400 cards/minute, connects to a System/360 or  ________  System/370 by way of a parallel channel  ź Model 3: read-only at 300 cards/minute, connects to a 1410 or 7010  ź Model 4: read-only at 400 cards/minute, comes with two stackers  instead of one, connects to a 1440  ź Model 5: punch-only at 180 columns/second, connects to a 2922 Pro-  grammable Terminal or System/360 Model 20  ź Model N2: punch-only at 180 columns/second, connects to a  System/360 (not the Model 20) or System/370  2540: An alternative was the 2540, launched in 1965. There was only  2540  2540  2540  really one model, and these were very often seen on System/360 instal-  lations. These attached to the host through a 2821 control unit (see  ____  the section above for information on this, underneath the 1403 section  ______________________________________________________________________   30 Mainframe History »   in the Printers segment). These were much faster than the fastest  ___________________________  model of 1442; these read at 1000 cards/minute, and punched at 300  cards/minute.  There were two different devices that would show up to the host, the  2540R (reader) and 2540P (punch). The reader had one input hopper and  three output stackers (with the third one being sharable between the  punch or reader, but not at the same time). The punch, likewise, held  three output hoppers (with the third one being shared).  The 2540 could both read and punch column binary mode, allowing for  any data to be stored on cards.  3501/3521: Between the 2540 and its more successful successor, the  3501/3521  3501/3521  3501/3521  3501 reader and 3521 punch seemed to be smaller models of the related  3505/3525 with only one stacker. Little information on this product  exists; it did not seem to be very popular.  3505/3525: The successor was the 3505/3525, launched in 1971 for the  3505/3525  3505/3525  3505/3525  System/370. It read at 1200 cards/minute (or, on the Model B2, 800  cards/minute) and could read cards that were optically marked (like,  if you were to use a pen to color in the spots on the card by hand).  There were 3 submodels of the 3525: the P1, P2, and P3; these punched  at 100, 200, and 300 cards/minute respectively.   NETWORKING DEVICES  NETWORKING DEVICES  NETWORKING DEVICES  NETWORKING DEVICES  The mainframe, being a natural system to experience a connection to a  network, found itself amongst a sea of networking peripherals. Here  are some of those:  CHANNEL-TO-CHANNEL ADAPTERS: While this may seem foreign to those  CHANNEL-TO-CHANNEL ADAPTERS  CHANNEL-TO-CHANNEL ADAPTERS  CHANNEL-TO-CHANNEL ADAPTERS  familiar with PC hardware, this is not uncommon in mainframes! A CTCA  (as it is often abbreviated) lets two mainframes communicate directly  with each other using a channel path. This is roughly equivalent to  connecting two PCs together with PCIe ribbon cables, albeit through a  small box to facilitate the connection. There were two CTCAs made:  3088 CTCAs were the first, and this was originally a box that would be  3088 CTCA  3088 CTCA  3088 CTCA  _________  connected to a spare channel on a System/360. These were available up  until the end of parallel block channels, and was eventually replaced  when ESCON became the standard interface. Note that by the mid-80s,  these devices were emulated; the channel controller itself gained this  ability directly.  ESCON and FICON CTCAs followed shortly thereafter; these were config-  ESCON and FICON CTCA  ESCON and FICON CTCA  ESCON and FICON CTCA  ____________________  ured in the IOCS configuration file as nothing more than a built-in  device and were directly supported by the channel processor (there  were no external boxes to be seen with these).  8232 (LAN CHANNEL STATION): The 8232 LCS was the first attempt to  8232 (LAN CHANNEL STATION)  8232 (LAN CHANNEL STATION)  8232 (LAN CHANNEL STATION)  create an Ethernet, Token Ring, PC Network (an IBM product, an old  version of Token Ring), and MAP (Manufacturing Automation Protocol, a   Mainframe Peripherals 31 »   General Electric product that became IEEE 802.4 Token Bus) interface  box for a System/370 in 1987. The device in question was an IBM 7532  Industrial Computer, and it ran PC-DOS. There were actually two models  of 8232, with Model 1 consisting of one 7532 (and could therefore  connect to up to 2 networks), and a Model 2 that was just two 7532s.  The LCS program, the so-called "IBM LAN Channel Support Program," exe-  cuted under the control of PC-DOS, and the 7532(s) were mounted in a  waist-high 19-inch rack (which had a cutout for the 7532(s)'s power  switch(es)). 4 disks were required during installation:  ź PC-DOS, which would eventually be partially copied to the target  disk  ź The LCS Support Program, which would be customized and written to  the target  ź The Local Area Network Support Program, for configuring network  boards  ź The target disk, which would eventually be bootable and be left in  the drive  The device was internally referred to as a "PCCA" (which I am guessing  means PC Channel Adapter), and ran the following programs in a modular  fashion:  ź 3 modules to allow the LCS to connect to 8 different kinds of  mainframe and to the 2 different types of networks:  Ś MTCMMAIN.EXE (the main task that executed the others)  Ś ETHTASK.TSK (for Ethernet support)  Ś TOKTASK.TSK (for Token Ring support)  ź 3 modules to support the LCS:  Ś MONTASK.TSK (presumably to monitor the function of the device)  Ś PCCATSK1.TSK (to drive the host channel adapter)  Ś SCRN8232.TSK (presumably to drive the display status screen)  ź 1 program to configure everything:  Ś MTCMCONF.EXE  To actually configure the device, the user had to be aware of the fol-  lowing parameters:  ź Model 1 or 2, since the Model 2 meant twice the work  ź Which network cards were installed in slot 5 and 6 of the 7532,  which could be Ethernet, Token Ring, or IBM PC Network   32 Mainframe History »   ź The device address on the host that this would be attached as  ź 32 or 64 control unit blocks for block transfers  ź 1mbps or 3mbps channel speed  ź The memory address, IRQ, and type of the LAN card(s)  Once the configuration and installation was done (which would be done  by producing a DOS disk onto the target disk, running the LAN Support  Program to configure and load the network card drivers at boot, and  then configuring and copying the LCS software), the box was rebooted,  and everything would be ready for the host program.  One can tell that this box is based on earlier work done during the  development of WISCNET for VM (search this document for WISCNET to  read about the developmental history of this box).  Some other manufacturers built machines that were compatible with the  LCS. These included:  ź The Cisco 7200 series ISR, with a parallel channel or ESCON inter-  face board  ź Bustech Netshuttle  ź Polaris StarGate  ź Interlink 3762  3172 (NWAYS ITERCONNECT CONTROLLER): In November 1990, IBM launched  3172 (NWAYS ITERCONNECT CONTROLLER)  3172 (NWAYS ITERCONNECT CONTROLLER)  3172 (NWAYS ITERCONNECT CONTROLLER)  the successor to the earlier (and much slower) LCS. This was 1990, and  this was the era of ESCON -- the new 3172 came with an ESCON adapter,  but were often used with parallel channel adapters. In this era, LAN  networks rarely went past 10 megabits (except for FDDI, which was  truly fast at 100 or sometimes 200 megabits), so a parallel channel  adapter would suffice for most customers.  The 3172 consisted of a rack-mount cabinet with a control panel (the  so-called "operations panel"), a 486 CPU with some RAM, a floppy drive  and hard drive, a channel adapter, a LAN card, and a power supply. The  following LAN options were available, and you could have up to 4 cards  (except for MAP boards, since those required 2 card slots):  ź Ethernet (10 megabit)  ź Token Ring (16/4 megabit)  ź FDDI (100 megabit)  ź MAP 3.0 Broadband Mode (for the unaware, Manufacturing Automation  Protocol is is an IEEE 802.4 10 megabit token-bus network)  ź MAP 3.0 Carrierband Mode (same thing, but 5 megabits)   Mainframe Peripherals 33 »   When the machine was ran in normal mode, OS/2 would load up and run  similar programs to those found on the old 8232 LCS. This device  showed up to the host as a 3088 CTCA, just like the LCS; since this  technically did provide CTCA-style functions, IBM did provide a  special mode that allowed up to 4 T1 lines to be bonded together as a  real CTCA. The 3172 supported the following LAN protocols:  ź SNA; this was proper 802.3 encapsulated SNA and this would be ran  under the control of VTAM  ź TCP/IP; this was either 802.3 encapsulated or DIX (Ethernet II)  encapsulated (the standard in modern times) TCP/IP and this would  be ran under the control of a TCP/IP stack  ź OSI CLNS; this was the infamous TCP/IP competitor that was ran  under the control of OSI Communication Services (a currently lost  program)  WAN cards were also supported (these were IBM Microchannel WAC boards  which held a V.24 or V.35 serial interface), and this in-turn sup-  ported the following protocols:  ź A point-to-point SDLC line (this would talk to downstream 3274s  and 3174s, or an emulation thereof)  ź A point-to-multipoint (i.e. multidropped) SDLC line  ź An X.25 line (which can carry SNA, TCP/IP, and presumably OSI  traffic)  ź Frame Relay  In a LAN mode, there were two distinct operating modes that the 3172  could present to the host. These were:  ź Standard LCS mode; this was the standard but did not offer as good  of performance as it could be  ź 3172 Offload mode, wherein the TCP/IP stack ran on the 3172,  called CLAW (Combined Link Access to Workstation) mode  CLAW mode was rather interesting. It required the installation of  additional software, and ran alongside the ICP (the Interconnect  Program, the program that ran the system).  2216 (NWAYS MULTIACCESS CONTROLLER): In 1999, IBM launched a true  2216 (NWAYS MULTIACCESS CONTROLLER)  2216 (NWAYS MULTIACCESS CONTROLLER)  2216 (NWAYS MULTIACCESS CONTROLLER)  competitor to the Cisco Integrated Service Router (in those days, the  Cisco 7200 was looking like the be-all-and-end-all of multiprotocol  routing). Though the 2216 was primarily a router, it had mainframe  support (then again, so did the Cisco 7200). The 2216 supported the  following port interfaces:  ź Parallel channels   34 Mainframe History »   ź ESCON channels  ź Token-Ring  ź 10/100 Ethernet  ź EIA-232/V.24  ź V.35  ź X.21  ź ISDN PRI (T1/J1)  ź ISDN PRI (E1)  ź ATM multimode  ź ATM singlemode  ź FDDI  ź HSSI  Pretty impressive, right? Well, it also supported the following  network protocols:  ź IPv4, with IPsec  ź IPX  ź AppleTalk Phase II  ź Banyan VINES  ź DECnet Phase IV  ź DECnet Phase V (sometimes called DECnet/OSI)  ź SNA (APPN, DLSw, Frame Relay, and Enterprise Extender)  ź NetBIOS framing  Wow. Now, how was this useful for mainframes? Well, recall that it had  channel and ESCON interfaces. These could be attached to the host,  where they would emulate a 3172 with downstream network nodes; this  meant it could directly support TN3270E by also emulating a 3174 as a  downstream PU of the channel. Since these also supported APPN and HPR,  these were far advanced over an old 3174. To recap, these supported 2  operating modes: IP and SNA (just like the 3172).  These routers had a rather fast CPU: a 233 MHz PowerPC 604; this was  significantly faster than the 486 found in the 3172s, and this pro-   Mainframe Peripherals 35 »   vided much faster network throughput (until it was later replaced with  the OSA).  OPEN SYSTEMS ADAPTER: In the late 90s, it was starting to become  OPEN SYSTEMS ADAPTER  OPEN SYSTEMS ADAPTER  OPEN SYSTEMS ADAPTER  obvious that the extant method of doing networking on mainframes (with  a 3172 or 2216) was too high-latency. The result of the effort to drop  that latency was something called an Open Systems Adapter, seen on  9672 Gen 3 machines and newer. These operated in a radically different  mode called QDIO (Queued Direct I/O), wherein the host CPU would drive  QDIO  QDIO  QDIO  ____  the network card with a memory-mapped-I/O technique (rather than  having something process a CCW program). The new OSA cards supported a  variety of networks:  ź 10/100 Ethernet  ź Gigabit Ethernet (OSA-Express)  ź 10 Gigabit Ethernet (OSA-Express2)  ź 155 ATM  ź 4/16/100 Token Ring  Over the years, there were several hardware revisions of the OSA.  Here is a brief summary of each model:  ź The original OSA and OSA-2: introducing support for QDIO, these  supported Fast Ethernet, 4/16/100 Token Ring, FDDI (optional), and  155 ATM (optional). The IP QDIO mode (see below for something  called OSD mode) was a layer-3 solution only; you could not pass  arbitrary Ethernet datagrams through the adapter (much in the same  way as the LCS). Up to 80 IP stacks could be ran with one channel  path.  ź OSA-Express: adding Gigabit Ethernet support as well as the Inte-  grated Console Controller (see below), the OSA-Express cards found  on the z890 and newer also supported true layer-2 Ethernet. The  number of IP stacks supported was raised to 160.  ź OSA-Express2: new for the z9, 10 Gigabit Ethernet support was  added. You could now have up to 640 IP stacks, allowing many  (probably Linux) VM guests to share the same card and still have  good performance.  There were several operating modes that the card could be put in:  ź The OSE operating mode simulates a 3172 LAN Channel Station (which  was once a modified Microchannel-based PC running an OS/2 program  called ICP that provided TCP/IP and SNA access for Ethernet, FDDI,  and Token Ring networks)  ź OSD mode (which was added on the OSA-Express cards) is the  standard operating mode in which a Gigabit/Fast Ethernet or   36 Mainframe History »   155-megabit ATM controller is driven by the CPU using DMA (this  mechanism is called QDIO, i.e. Queued Direct I/O).  ź OSC mode (the Integrated Console Controller mentioned above)  ź OSN mode, introduced with the OSA-Express2, was intended to  provide an Ethernet interface for Communications Controller for  Linux to use.  Something the z890 and z990 added was the Integrated Console Con-  troller. In the "olden days", you had very few options for providing a  3270 console to a mainframe. If you had a Multiprise 3000, great! If  not, you would need either a 3174 with coax terminals or an IBM 2074  console controller that would emulate a local terminal controller with  TN3270 sockets. The ICC was a special operating mode of the OSA card,  running in the OSC mode. This would claim a LAN port for a TN3270  server, and it would simulate local 3270 terminals. One could then  connect a TN3270 emulator and get a console on the mainframe.   NON-PROGRAMMABLE COMMUNICATIONS CONTROLLERS  NON-PROGRAMMABLE COMMUNICATIONS CONTROLLERS  NON-PROGRAMMABLE COMMUNICATIONS CONTROLLERS  NON-PROGRAMMABLE COMMUNICATIONS CONTROLLERS  In the early days of the System/360, there became some kind of need  for terminals attached to mainframes. Before the aforementioned 3270  series was made available, the dominant way to connect terminals to a  S/360 was through one of these. These devices did continue to exist  into the 80s and 90s in an emulated capacity.  2701: The simplest of the 270x series was the 2701, announced in 1964  2701 270x series  2701 270x series  2701 270x series  ___________  and delivered in 1967. This device was a four-port "Data Adapter Unit"  that provided either synchronous transmit-receive (STR) or bisync  interfaces at up to 40.8 kbps. These officially supported the fol-  lowing devices listed in the product announcement, providing an inter-  esting view of terminal devices available in the mid-1960s:  ź Devices that connected to the IBM 7710/7711:  Ś IBM 7710/7711, the original STR interface that connected IBM  1401 computers together (or to an S/360 via a 270x)  Ś IBM 7701/7702 Magnetic Tape Transmission Terminal  Ś IBM 1009 Data Transmission Unit  Ś IBM 1013 Card Transmission Terminal  ź The IBM 7740 Communication Control System, the successor to the  7710/7711 (often seen alongside the IBM 1410 computer):  Ś IBM 7750 Programmed Transmission Control  ź IBM 1030 Data Collection System:   Mainframe Peripherals 37 »   Ś 1031 Input Station (card reader, badge reader, or manual input  terminal; attaches to the remote computer via the 1031A)  Ś 1032 Digital Time Unit (wrote timestamps onto data)  Ś 1033 Printer (shares the 1031A)  Ś 1034 Card Punch  Ś 1035 Badge Reader  ź IBM 1050 Data Communication System (see the section on the 1052  ____  for more information on this)  ź IBM 1070 Process Communication System:  Ś 1071 Terminal Control Unit  Ś 1072 Terminal Multiplexer  Ś 1073 Latching Contact/Counter Terminal/Digital Pulse Converter  Ś 1074 Binary Display  Ś 1075 Decimal Display  Ś 1076 Manual Binary Input  Ś 1077 Manual Decimal Input  Ś 1078 Pulse Counter  ź AT&T 83B2 Selcall Terminal  ź Western Union Plan 115A Outstation  ź Common Carrier TWX Station  ź IBM 2740/2741  ź IBM 2260/2848  Out of the devices listed here, only the last two (which weren't even  originally included on the supported list in the product announcement)  were "timesharing" devices; the rest of these were devices driven by a  computer in an era before embedded controllers and microprocessors.  2702: If you needed more communications lines, one could get a 2702,  2702  2702  2702  released alongside the 2701. The trade-off was that these 31 lines  were STR-line-coding only, and ran at a lower speed than what was pos-  sible on the 2701. This box supported the same devices as those listed  above for the 2701, minus anything that communicated using bisync (so,  anything starting with a 7 in that model list).   38 Mainframe History »   2703: Announced in 1965 and made available shortly after the  2703  2703  2703  2701/2702, the 2703 was the most popular of the three models. Gone was  the 4 or 31 line count limit, these had 176 (half-duplex) lines that  ran in either STR mode, bisync mode, or TTY mode (i.e. a normal async  serial port). These attached to the host computer via a selector  channel (similar to the 2701/2702), and each device following the  control unit address represented a configured port: the control unit  could be at address 300 and port 5 could be at address 304. While this  box certainly had many communications lines (and was perfect for  timesharing), the line speed was limited to 2400 baud (increased to  4800 baud by 1970), one could connect an IBM 2712 to multiplex 14  extra devices onto one single high-speed line to the 2703 (the host  computer would need to be made aware that a multiplexer was present on  that port).  These devices were quite popular with TSS/360 and later CP/CMS and TSO  users, and were electrically simple (which allowed for quick cloning  by various other manufacturers). Clones included the Memorex 1270, and  three devices made by NCR-Comten.  Since the 2703 was so popular, an emulator program was written for the  3705 that replaced it (see below).  AWS2703: Note: this device ONLY emulates ports on a 2703 running in  AWS2703 ____________________________________________________________  AWS2703  AWS2703  TTY mode  ________  A P/370 and P/390 device manager program that emulated the 2703 and  2540 punch was also available. This was intended to connect to a modem  attached to an asynchronous port, but OS/390 that existed during the  period this device manager was available famously could not actually  utilize a 2703 for TSO! VM, however, could; this was a documented use.  Alas, one could use this to drive all manner of unusual devices from  the P/390 operating system.  This emulator also emulated the 2540 punch, which was explicitly made  available such that RSCS on VM would control the port, and a user  could punch a plotter output file onto a real serial port to drive a  plotter using this technique. While one could drive a plotter in an  unattended fashion, the IBM manuals for the P/390 directly state that  this is a bad idea!  9370 ASCII SUBSYSTEM CONTROLLER: This device was a logically-similar  9370 ASCII SUBSYSTEM CONTROLLER  9370 ASCII SUBSYSTEM CONTROLLER  9370 ASCII SUBSYSTEM CONTROLLER  device to the 2703, and somewhat functioned like one. This was a card  installed into a 9370 that provided up to 16 serial ports that ran in  three different modes:  ź Native ASCII support mode  ź ASCII/3270 conversion mode  ź ASCII/3270 transparent mode  The following devices could be connected:   Mainframe Peripherals 39 »   ź 3101 Display Terminal  ź 3161/3163 Display Terminals  ź IBM Personal Computer  ź DEC VTxxx terminal  ź ASCII printer  ź ASCII plotter  4331/4341/9370 TELECOMMUNICATIONS SUBSYSTEM: While the 37x5 series  4331/4341/9370 TELECOMMUNICATIONS SUBSYSTEM  4331/4341/9370 TELECOMMUNICATIONS SUBSYSTEM  4331/4341/9370 TELECOMMUNICATIONS SUBSYSTEM  was considered a "programmable" communications controller, a non-  programmable analogue was the Telecommunications Adapter. This con-  nected to:  ź Up to 3 Multi-Protocol Two-Line adapters (providing synchronous  serial)  ź Up to 3 Asynchronous Four-line Communications adapters  These lines could be 64 kbps SDLC lines, or 19.2 kbps HDLC (X.25)  lines. This device existed in an analogous form on the IBM 43xx  processors, and these devices are sometimes colloquially called an  INTEGRATED COMMUNICATIONS ADAPTER.  AWSICA: Note: this device is similar to the AWS2703 manager, except  AWSICA _____________________________________________________________  AWSICA  AWSICA  this device operates in BSC mode in lieu of TTY mode.  _____________________________________________________  Though OS/390 VTAM could not use a 2703 in TTY mode for a TSO ter-  minal, OS/390 JES2 (as well as VM/ESA RSCS) could use an emulated (by  this AWSICA adapter) 2703 BSC line for NJE communication. This adapter  used WAC ports (Wide Area Connector ISA card, the manager could also  use the older Multiprotocol adapter cards) in synchronous RS232 mode,  X.21 mode, V.35 mode, or RS422 mode. Depending on the card type used,  the user had to load either AWSMPADD.SYS (for the Multiprotocol cards)  or AWSWACDD.SYS (for WAC cards).   2260 DISPLAY SYSTEM  2260 DISPLAY SYSTEM  2260 DISPLAY SYSTEM  2260 DISPLAY SYSTEM  The 2260 series was the logical precursor to the 3270 series, and was  much more primitive, both from a design standpoint and a functionality  ____  standpoint. Introduced in 1964, this was the first real successful  teleprocessing/timesharing terminal (that wasn't a specialized  graphics device for CAD) seen on the S/360; through the success of the  S/360 and this line, this became the foundation for the first suc-  cessful CRT video text terminal.  There were three models of 2260 display (listed as columns by rows):  ź Model 1: 40x6   40 Mainframe History »   ź Model 2: 40x12  ź Model 3: 80x12  These devices included optional keyboards, which could be either a  numeric-only keyboard or a full typewriter keyboard -- this setup was  referred to in the product announcement as a "man-to-machine communi-  cation" system implementing a "visual I/O concept." When keys were  pressed, the letters typed would be echoed on the CRT screen via way  of the terminal controller (described below). The display could show  uppercase letters, numbers, and 25 special symbols (which included the  space, newline, and other such characters).  The displays were rather odd in the sense that the image was drawn 90  degrees rotated to how a normal CRT television would draw the image:  the scanlines on the CRT screen started at the left-most edge, and  then scanned down (so, top-to-bottom scanning, incrementing rightward  as the image draws). Remember, this was an era before cheap semicon-  ductor RAM chips existed, so the engineers found a very clever sol-  ution for storing the image. Rather than using some kind of odd  storage tube, the engineers found that they could actually fashion up  an acoustic delay line!  2848 CONTROLLER: The screen image was stored in a delay line whose  2848 CONTROLLER  2848 CONTROLLER  2848 CONTROLLER  length and speed-of-sound characteristic meant that one image could be  stored in a big spiral-wound wire loop retained by rubber holders. A  "transmitter" would impart a vibration into the wire as a twist of  sorts, and a "receiver" on the other side was a device that could  detect the torsion (this was a device built somewhat like a phonograph  pickup). The image could be updated by waiting for the timeslot on the  ring (kept up by a counter) and then retransmitting the modified  signal into the ring; since the image will dampen out after one revo-  lution around the acoustic ring, the image must constantly be re-  imparted into the ring by the transmitting transducer. Of course, this  inevitably introduced some issues; if you walked heavily by the con-  troller (or installed the controller by an elevator, door, printer, or  something else that produced vibrations), the image would be scrambled  and gradually fade away on all of the screens!  The 2848 could attach to the host computer by either a channel (oper-  ating locally), or through a communications set (an old term for what  we might call a modem today, either dial-type or leased-line) via a  2701 Data Adapter.  2265: This was a single-unit terminal that attached directly to  2265  2265  2265  either a channel or communications line, and performed the functions  of a single 2260 and 2848. This is analogous to, for instance, the  future IBM 3275 controller-terminal. This was announced alongside the  2770, and is discussed there.   NCP COMMUNICATIONS CONTROLLERS  NCP COMMUNICATIONS CONTROLLERS  NCP COMMUNICATIONS CONTROLLERS  NCP COMMUNICATIONS CONTROLLERS   Mainframe Peripherals 41 »   3705/3704: In 1972, IBM launched a programmable communications con-  3705/3704  3705/3704  3705/3704  troller that would implement SNA networking and drive downstream  3274s/3174s. These came in the form of the 3705, which itself ran  several programs:  ź The EP (Emulation Program): this program emulated the earlier  2702/2703 "dumb" communications controller (which mainly provided  ASCII, Bisync, or STR lines).  ź The NCP (Network Control Program, no relation to ARPAnet NCP or  DECnet NCP): this implemented the Systems Network Architecture  network protocol and attached to cluster controllers (i.e.  3274/3174) over synchronous serial lines or T1 circuits.  ź The PEP (Partitioned Emulation Program): provides a subset of the  EP and a subset of the NCP, used when both functions were needed.  The 3705 drove up to 352 communications lines, and the smaller 3704  (introduced in 1973) supported up to 32 communication lines.  3710: This was the successor to the 3705, and was introduced in 1984.  3710  3710  3710  This was a much smaller network controller that was about as large as  three 8-inch floppy drives set vertically, and was analogous to a  shrunk 3705. These used a 3101 ASCII terminal for the control ter-  minal, unlike an operator panel seen on the earlier 3705s. These had  RS-232, V.35, and X.21 communications adapters, and introduced the  ability to connect to another 3725 (see below) through an X.25  network.  3725: In 1983, IBM decided to overhaul the 3705 architecture by reim-  3725  3725  3725  plementing the formerly-hardware line processors with ones using  microcoded processors. This was a hefty design change, and there were  several models in the series:  ź 3725: The original communications controller in the series  ź 3720: A shrunk version of the 3725 that replaced the 3710  ź 3726: An expansion box for the 3725 (to add more line cards)  The 3725 was configured with 512 KB to 2 MB of main storage (installed  in 256 KB increments), a single type of channel adapter (which could  talk to up to 6 host processors, or 4 multiprocessor host processors),  a single type of communications scanner card (which implemented the  SDLC, BSC, and start/stop protocols), five different types of line  interface cards (for a total of 256 full-duplex or half-duplex commu-  nications lines), and a terminal for the operators console (a 3727).  Each frame added more and more line cards, with 96 with one frame or  256 with two frames (which added 160). The lines ran at a maximum of  256 kbps.  3745: The final NCPs were introduced from 1988 to 1992. The 3745,  3745  3745  3745  introduced in 1988, was directly equipped with T1 line cards to match  the era. These were large machines, spanning three cabinets; the 3476   42 Mainframe History »   Nways Controller was originally an expansion cabinet for the 3745 that  added Token Ring and ESCON connections. In 1995, the 3746-950 was  launched, shrinking and combining the featureset into the final NCP  made.  The following models were made:  ź 130  ź 150  ź 160  ź 170  ź 210  ź 310  ź 410  ź 610  COMMUNICATIONS CONTROLLER FOR LINUX: CCL is a z/Linux (and Linux/390)  COMMUNICATIONS CONTROLLER FOR LINUX  COMMUNICATIONS CONTROLLER FOR LINUX  COMMUNICATIONS CONTROLLER FOR LINUX  based emulator for the 3745, capable of running unmodified 3745/3746  NCP programs. These would be able to communicate with the host via  channel-to-channel adapters (usually under VM), or talk on a network  using a special operating mode of the OSA cards (OSN mode).   3270 DISPLAY CONTROLLERS  3270 DISPLAY CONTROLLERS  3270 DISPLAY CONTROLLERS  3270 DISPLAY CONTROLLERS  The 3270 Display System was a relatively advanced (for its time,  arguably still even today) terminal system that replaced the earlier  2260 system in 1971. These functioned as parts of a distributed  network, attempting to alleviate as much of the host CPU load as pos-  sible during terminal control tasks. We will discuss the controllers  first, then the terminals next.  The 3270 terminals (see below for more information on them) attached  to a communications controller through a coax connection; many sites  used "baluns" (just like in radioelectronics) to connect 3270 termi-  nals to their associated control units over phone lines (in lieu of  "expensive" 93 ohm RG-62 coax cables). The controllers included:  3272: The first channel-attached 3270 controller for S/360 and S/370  3272  3272  3272  machines was the so-called "3272 Local Controller"; this was a  nondescript gray box with a big wire-wrapped backplane inside it. The  circuitry was somewhat similar to the 3271 -- it was almost entirely  comprised of 7400-series logic ICs. The terminals attached to coax  jacks at the back, and the 3272 connected to the host mainframe with a  bus-and-tag cable.   Mainframe Peripherals 43 »   3271: The remote version of the 3272 is the 3271, and it had a V.24  3271  3271  3271  serial port on the back that either connected it directly (via syn-  chronous serial SDLC) to a 2703 or 3705 communications controller, or  could be attached to a synchronous modem (the  3863/3864/3865/3868/3872/5811/5865/5866/5868). These would be intended  for attachment at perhaps a remote office, and the modem could be a  normal dial-type modem or a leased-line modem. Alas, one could also  directly connect it to a 2703/3705 if desired.  3274: The second "local non-SNA" terminal controller (that could also  3274  3274  3274  do "local SNA" and just plain "SNA") was the 3274, and it replaced the  earlier 3271 and 3272. There were several models of 3274, and they  were equipped with 8/12/16/32 ports -- these came in two types:  ź Category A, the newer (despite it coming first) coax interface  with a slightly different coax protocol introduced with the 3274.  These worked with new terminals introduced in the 3274 product  generation, like the 3278 and 3279. The first 8 ports were always  category A; category A ports were seen in the first cluster on a  multi-cluster (i.e. two boards of BNC ports) 3274.  ź Category B, the older coax interface, intended to hook up to  devices like the 3277 terminal and 3284 printer. These were always  found in a cluster that came after the first one.  Conversely, there were 3 different types of 3274 for each model.  These were:  ź A-unit, a local (i.e. parallel channel) control unit that provided  A-unit  A-unit  A-unit  ______  "local SNA" terminals; this showed up to the host computer as one  device. VTAM would have to drive this device as a proper SNA  control unit, and terminals would be addressed as proper SNA  devices. The 3274-xA was intended to replace the 3271.  ź B-unit, also a local channel control unit that provided "local  B-unit  B-unit  B-unit  ______  non-SNA" terminals. This provided many devices (32 if you had 32  ports) to the host, and these devices were either defined as  either displays or printers. Since these were local devices, you  would, instance, find yourself logged into VM with a 3 or 4 digit  device address for the terminal, as opposed to an LU name for a  3274-xA. The 3274-xB was intended to replace the 3272.  ź C-unit, a remote SDLC/BSC or local SNA control unit.  C-unit  C-unit  C-unit  ______  ź D-unit, the same as the 3274-xB except these could not communicate  D-unit  D-unit  D-unit  ______  with 30xx processor.  The 3274s loaded from an 8-inch floppy disk, and held a rather  advanced integrated computer. By the end of its life, it supported  quite an interesting array of software features:  ź 3270 Extended Data Stream and highlighting  ź Programmed Symbol Sets, for custom fonts   44 Mainframe History »   ź A V.24 synchronous serial interface (works up to 14.4kbps)  ź A V.35 synchronous serial interface (works up to 56kbps)  ź SNA or X.25 network attachment on the synchronous serial port  ź DownStream Load for the 3290 and 3179G graphics terminals  ź Distributed Function Terminal (DFT) mode  ź Control Unit Terminal (CUT) mode  ź Support for the 9901 and 3299 multiplexers  ź Entry Assist  ź Dual Logic, allowing 2 sessions to be used on a CUT terminal  There were a number of models, and, while I will not give the exact  details on every one of these, I will provide a table of the models:              Mainframe Peripherals 45 »   ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Table 8 (Page 1 of 2). IBM 3274 Models |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Ż Ż Ż |  | Model | Attachment | Supported | Max Ports |  Model Attachment Supported Max Ports  Model Attachment Supported Max Ports  Model Attachment Supported Max Ports  _____ __________ _________ _________  | | | Processors | |  Processors  Processors  Processors  __________  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-A01 | local SNA | S/370, 30xx, | 32 |  | | | or 4300 | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-B01 | local non-SNA | S/360, S/370, | 32 |  | | | 30xx, or 4300 | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-C01 | local SNA or | S/360, S/370, | 32 |  | | remote SNA | 30xx, or 4300 | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-D01 | local non-SNA | S/370 or 4300 | 32 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-21A | local SNA | S/370, 30xx, | 32 |  | | | or 4300 | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-21B | local non-SNA | S/360, S/370, | 32 |  | | | 30xx, or 4300 | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-21C | remote SNA | S/3, S/360, | 32 |  | | (ASCII or | S/370, 30xx, | |  | | EBCDIC) | 303x, 3081, | |  | | | 308x, 3090, | |  | | | 4300, 8100, or | |  | | | 9370 | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-21D | local non-SNA | S/370 or 4300 | 32 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-31A | local SNA | S/370, 30xx, | 32 |  | | | or 4300 | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-31C | remote SNA | S/3, S/360, | 32 |  | | (ASCII or | S/370, 30xx, | |  | | EBCDIC) | 303x, 3081, | |  | | | 308x, 3090, | |  | | | 4300, 8100, or | |  | | | 9370 | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-31D | local non-SNA | S/370 or 4300 | 32 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-41A | local SNA | S/370, 30xx, | 32 |  | | | or 4300 | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-41C | remote SNA | S/3, S/360, | 32 |  | | (ASCII or | S/370, 30xx, | |  | | EBCDIC) | 303x, 3081, | |  | | | 308x, 3090, | |  | | | 4300, 8100, or | |  | | | 9370 | |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż ż   46 Mainframe History »   ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  Ż Ż Ż  | 3274-41D | local non-SNA | S/370 or 4300 | 32 |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-51C | remote SNA | S/3, S/360, | 12 |  | | | S/370, 30xx, | |  | | | 303x, 3081, | |  | | | 308x, 3090, | |  | | | 4300, 8100, or | |  | | | 9370 | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3274-61C | remote SNA | S/3, S/360, | 16 |  | | | S/370, 30xx, | |  | | | 303x, 3081, | |  | | | 308x, 3090, | |  | | | 4300, 8100, or | |  | | | 9370 | |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż ż  3174: The 3174 (introduced in 1986) was a vastly-improved and simpli-  3174  3174  3174  fied iteration of the 3274. Gone was the 8-inch floppy, the new 3174  booted off of 5.25" floppies. Likewise, the design was adapted to be  more generic: the largest floor-standing models had 10 slots, which  could be populated with either channel adapters or serial cards  (depending on whether or not the unit was a local or remote configura-  tion), or coax adapters. The local models were bimodal -- that is,  they could be either local SNA or local non-SNA.  Over the course of the lifetime of the 3174, several releases of the  "Configuration Support" firmware were made available:  Configuration Support A, the first firmware released alongside the  Configuration Support A  Configuration Support A  Configuration Support A  _________________________  3174, supported everything that existed when it was released (so, syn-  chronous serial, parallel channels, Token Ring). Software features  included:  ź Country Extended Code Page (for foreign languages)  ź Multiple Logical Terminals (terminal multiplexing)  ź Response Time Monitor (which incremented every second during an X  SYSTEM wait period)  ź Intelligent Printer Data Stream  Configuration Support S, which followed A, allowed either a local or  Configuration Support S  Configuration Support S  Configuration Support S  _______________________  remote controller to function as a Token Ring DSPU Gateway system,  wherein up to 80 downstream physical terminal units could be attached  over a network.  Configuration Support B, which expanded the TR DSPU to 250 downstream  Configuration Support B  Configuration Support B  Configuration Support B  ________________________  PUs and introduced a feature that alleviated VTAM's need to perform  polled I/O on the channel: Group Polling.   Mainframe Peripherals 47 »   Configuration Support C, the final version(s), which added neat fea-  Configuration Support C  Configuration Support C  Configuration Support C  _________________________  tures like:  ź ISDN support (answering; PCs would usually originate the call)  ź APPN SNA support  ź 3174 Peer Communication (allowed PCs attached via coax to access a  Token Ring LAN controlled by the controller)  ź 5250 terminal emulation  ź TCP/IP TN3270 and normal Telnet support  ź Ethernet support  The following models existed:               48 Mainframe History »   ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Table 9 (Page 1 of 2). IBM 3174 Models |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Ż Ż Ż |  | Model (Year) | Attachment | Coax (ASCII) | Form Factor |  Model (Year) Attachment Coax (ASCII) Form Factor  Model (Year) Attachment Coax (ASCII) Form Factor  Model (Year) Attachment Coax (ASCII) Form Factor  ____________ __________ ____________ ___________  | | | Ports | |  Ports  Ports  Ports  _____  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-01L | Channel | 4/32, 0/24 | Floor |  | (1986) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-01R | V.21/TR | 4/32, 0/24 | Floor |  | (1986) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-02R | X.21 | 4/32, 0/24 | Floor |  | (1986) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-03R | TR | 4/32, 0/24 | Floor |  | (1986) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-51R | Synch Serial/TR | 9/16, 0/0 | Desktop |  | (1986) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-52R | X.21 | 9/16, 0/0 | Desktop |  | (1986) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-53R | TR | 9/16, 0/0 | Desktop |  | (1986) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-81R | Synch Serial | 4/8, 0/0 | Desktop |  | (1986) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-82R | X.21 | 4/8, 0/0 | Desktop |  | (1986) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-11L | Channel | 4/64, 0/24 | Floor |  | (1989) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-11R | Synch Serial | 4/64, 0/24 | Floor |  | (1989) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-12R | X.21 | 4/64, 0/24 | Floor |  | (1989) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-13R | TR/Ethernet | 4/64, 0/24 | Floor |  | (1989) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-61R | Serial/TR/Ethernet9/16, 8/8 | Desktop |  |  | (1989) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-62R | X.21 | 9/16, 8/8 | Desktop |  | (1989) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-63R | TR | 9/16, 8/8 | Desktop |  | (1989) | | | |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż ż   Mainframe Peripherals 49 »   ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  Ż Ż Ż  | 3174-91R | Synch Serial | 4/8, 0/0 | Desktop |  | (1989) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-92R | X.21 | 4/86, 0/0 | Desktop |  | (1989) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-21R | Serial/TR/Ethernet4/64, 0/0 | Rack |  |  | (1991) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-21L | Channel | 4/64, 0/0 | Rack |  | (1991) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-22R | ESCON/TR/Ethernet 4/64, 0/0 | Rack |  |  | (1991) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-22R | X.21 | 4/64, 0/0 | Rack |  | (1991) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-23R | TR | 4/64, 0/0 | Rack |  | (1991) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-12L | ESCON/TR/Ethernet 4/64, 0/24 | Floor |  |  | (1991) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-90R | TR | 1/1, 0/0 | Desktop |  | (1991) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-91R | Synch Serial | 4/8, 0/0 | Desktop |  | (1991) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-92R | X.21 | 4/8, 0/0 | Desktop |  | (1991) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-14R | Ethernet | 4/64, 0/24 | Floor |  | (1993) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-24R | Ethernet | 4/64, 0/24 | Rack |  | (1993) | | | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | | |  | 3174-64R | Ethernet | 4/16, 0/8 | Desktop |  | (1993) | | | |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż ż  COMBINATION CONTROLLER/DISPLAYS: There were two of these made, and  COMBINATION CONTROLLER/DISPLAYS  COMBINATION CONTROLLER/DISPLAYS  COMBINATION CONTROLLER/DISPLAYS  these combined the functions of a controller and a terminal in some  fashion:  ź 3275, a combination remote SNA controller and terminal, sometimes  used for a system console with one extra optional printer  attached(1971)  ź 3276, a combination remote SNA controller and a terminal, attached  directly to a 2703/3705 or to a synchronous serial modem (just   50 Mainframe History »   like the 3275) but could attach up to 6 terminals or printers (by  way of modules that could be installed in the 3276 controller box  that sat underneath the terminal)  3299 MULTIPLEXER: This external box worked with (originally) a 3274  3299 MULTIPLEXER  3299 MULTIPLEXER  3299 MULTIPLEXER  equipped with the 9901 Multiplexer Feature. This box allowed a single  coax port on the 3274 to provide 8 coax ports to downstream devices,  providing a great increase in density.   3270 DISPLAY TERMINALS  3270 DISPLAY TERMINALS  3270 DISPLAY TERMINALS  3270 DISPLAY TERMINALS  Replacing the earlier 2260 (which we will discuss next), the 3270 is a  block-oriented terminal (rather different from the VT100-clone termi-  nals you're probably used to emulating with programs like xterm) and  printer system. While real 3270 terminals are long gone and the pro-  tocol lives on as Telnet 3270 (or, more commonly, TN3270), it is  interesting to study where all of those classic mainframe green  screens came from.  Being introduced in 1971 (as mentioned in the Controllers section),  the 3270 line was intended to provide the highest number of terminals  on the mainframe possible. That meant the controllers had to do a lot  of work, but so did the terminals! The effect of the extremely effi-  cient design was that a single mainframe with 16 MB of main storage  could supposedly support 17,500 terminals on CICS with this product  line.  As partially discussed earlier, the 3270 terminals interface with a  host controller in one of two methods:  ź Coax connection with a 93 ohm RG-62 cable fitted with BNC connec-  tors; one terminal per cable (alternatively, with a 150 ohm balun  that converts the coax BNC plugs to something that can take a  phone line) -- this interface can transfer 2.3587 megabits per  second.  ź Direct attachment to a 37x5 or 4331 communications controller's  serial port (this is the case for the 3275 and 3276).  There were two operating modes for these terminals:  ź Control Unit Terminal (CUT) mode, wherein the terminal data stream  Control Unit Terminal (CUT)  Control Unit Terminal (CUT)  Control Unit Terminal (CUT)  ___________________________  would be consumed by the controller itself; the controller would  then instruct the terminal to move the cursor to a position on  screen, write a character with attributes, read keys from the key-  board via polling, so on and so forth. The characters transferring  downstream to or from the terminal are not in the EBCDIC character  set, but instead a special "3270 data stream."  ź Distributed Function Terminal (DFT) mode, wherein most of the data  Distributed Function Terminal (DFT)  Distributed Function Terminal (DFT)  Distributed Function Terminal (DFT)  ___________________________________  stream is forwarded off to the terminal -- this, naturally,  requires a more sophisticated terminal, but means the display will  interpret the 3270 data stream protocol itself. This allowed for   Mainframe Peripherals 51 »   extended attributes, more colors, and, most interestingly, full  vector graphics and custom programmed-symbol fonts!  Some terminals were CUT terminals, and others were DFT terminals.  Alas, there were many models of 3270 made. Here are some of them in  quick succession:  3277: Essentially the first 3270 terminal, the 3277 was a rather  3277  3277  3277  interesting product! Not only could you get one of three kinds of key-  boards (a basic keyboard which could only type in uppercase, a text  keyboard that could type in mixed-case or APL, and special keyboard  which only really had a numeric keypad), but you could also get a  selector pen (a type of light pen that allowed for point-and-click  behavior in some applications), or even ASCII character set function.  The other models in the series were:  ź Model 1: 40x12  ź Model 2: 80x24 (a successful product)  ź Model GA (with a RS232 serial port intended to drive either a  Tektronix 4013 or 4015 graphics display)  3278: Improving on the 3277 in 1979, the 3278 had a much-improved  3278  3278  3278  keyboard and new graphics/datastream features. The 5 models were as  follows:  ź Model 1: 80x12  ź Model 2: 80x24  ź Model 2A: 80x24, but with the bottom 4 lines reserved (these were  special console terminals)  ź Model 3: 80x32 or 80x24 (changable with a switch)  ź Model 4: 80x43 or 80x24  ź Model 5: 132x27 or 80x24  Among other design improvements, the 3278 also introduced an extended  highlighting system. Fields could blink, be inverted, be underscored,  or have a different character set. There was also support for pro-  grammed symbols, a means of loading custom fonts (but could also be  used to display monochrome bitmaps with some cleverness). There was an  interesting design flaw that, during a programmed symbol set load,  some models of 3278 or 3279 would have green streaks flash across the  display... the so-called "green lightning." This looked like a fuzz of  green lines, and occasional blue lines would flash in the status area.  3279: The third generation of 3270s came in 1979. These featured  3279  3279  3279  color, and the following models were made:  ź Model 2A: 80x24, base color   52 Mainframe History »   ź Model 2B: 80x24, extended color  ź Model 2C: 80x24, base color, 4 lines reserved (this was a console  terminal)  ź Model 3A: 80x32, base color  ź Model 3B: 80x32, extended color  ź Model S3G: 80x32 extended color, with programmed symbol set capa-  bility  Base Color meant there were 4 colors. This resulted in a color pattern  like this:  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Table 10. Base Colors |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Ż Ż |  | Protection | Intensity | Color |  Protection Intensity Color  Protection Intensity Color  Protection Intensity Color  __________ _________ _____  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | |  | Unprotected | Normal | Green |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | |  | Unprotected | Intensified | Red |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | |  | Protected | Normal | Blue |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | |  | Protected | Intensified | White |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż  Extended Color allows for a expanded data stream, and the following  colors were possible:  ź Neutral/white  ź Red  ź Green  ź Blue  ź Green  ź Pink  ź Yellow  ź Turquoise  In order to allow for the graphics features to be sufficiently uti-  lized, IBM wrote a program package called Graphical Data Display  Manager (or, more commonly, GDDM) at the Hursley Development Labora-  tory (outside of Winchester, England; the machines it was developed on  all bore names starting with WINVM).   Mainframe Peripherals 53 »   3290: The 3290 is a rather interesting terminal, or, as per its  3290  3290  3290  actual name, an Information Panel! Launched on March 8, 1983, the 3290  used a beautiful orange gas plasma display and could run in one of two  modes:  ź Four distinct 3278 Model 2 terminals  ź A single terminal, with a massive 162x62 size  You could also use programmed symbol graphics on it, but the only  caveat was that the controller it was connected to had to support the  Downstream Load feature (since the 3290 had to load its microcode from  the controller).  3178/3179: In the era of simplified electronics design, IBM launched  3178/3179  3178/3179  3178/3179  the 3178 in April 1983. This consisted of a box that sat underneath a  monitor, and a PC-derived keyboard. These were mildly successful, but  were replaced a year later.  On March 20, 1984, IBM announced the replacement to the 3279: the  3179. These were lower-cost and had simpler electronics. There were 3  models:  ź 3279 Model 1: 80x24, no graphics  ź 3279 Model G1: 80x24, graphics  ź 3279 Model G2: 80x43, graphics  The graphics support on the 3179G models was quite desirable, as it  had what IBM referred to as All Points Addressable (APA) graphics --  that is, you could deposit pixels on the display anywhere with a  resolution of 720x384. This terminal also supported vector graphics,  and the vector graphic rasterization was performed on the terminal  itself. These were terminals that required a Downstream Load from the  controller.  3180: Launched on March 20, 1984, the IBM 3180 is one of the most  3180  3180  3180  interesting and complex terminals. There were several submodels:  ź Model 2 and Model 2+: 80x24, basic or extended mode  ź Model 3 and Model 3+: 80x32, basic or extended mode  ź Model 4 and Model 4+: 80x43, basic or extended mode  ź Model 5 and Model 5+: 132x27, basic or extended mode  Basic mode provided a simple terminal, and extended mode allowed for  the screen to be resized, rotated, or a small partition could be  created by the application. These were also intended to connect to a  System/36 (the precursor to the AS/400 for those not familiar with  this platform), and were monochrome green displays.   54 Mainframe History »   3191: Introduced in June 1986, the 3191 was a monochrome green or  3191  3191  3191  amber terminal that could connect to a System/370 or an 8100. There  were two model groups:  ź Model A/B: 80x24  ź Model D/E/L: 80x24 or 80x43  3192: Essentially a (sometimes) color version of the 3191, the 3192  3192  3192  3192  launched in January 1987. As usual, there were several models:  ź Model C: 80x24 or 80x32  ź Model D: Monochrome green, 80x24/80x32/80x44/132x27  ź Model F: 80x24/80x32/80x44/132x27  ź Model G: 80x24 or 80x32, graphics support  ź Model L: Monochrome green, 80x24/80x32/80x44/132x27, but with a  light pen  ź Model W: Monochrome white, 80x24/80x32/80x44/132x27  The 3192G graphics model supported 16 colors and could also attach to  an IBM Proprinter for hardcopy output.  3193: In 1983, IBM launched something that could be seen as a bit of  3193  3193  3193  a graphics workstation. Intended to connect to a scanner and a  printer, the 3193 was actually a high-resolution portrait-orientation  monochrome display. A US Letter or A4 document could be displayed on  the CRT, and the attached scanner would transmit a compressed  datastream to the terminal. There were 2 submodels, with Model 1  having a 122-key keyboard, and Model 2 having a 102-key Enhanced PC  keyboard.  The screen was a whopping 880x1152 pixels, with a line resolution of  80x48. Two logical terminals could be used, and the image data stream  was supported (which GDDM supported).  3194: More of a "smart workstation," the 3194 was a desktop-computer  3194  3194  3194  look-alike that had a 1.44MB PC floppy drive (where data could be  transferred to and from the disk by using the IND$FILE transfer  program on the host). There were 3 models:  ź Model C: 80x24 or 80x32, color (12-inch monitor)  ź Model D: 80x24/80x32/80x44/132x27, monochrome (15-inch monitor)  ź Model H: 80x24/80x32/80x44/132x27, color (14-inch monitor)  3104: A variant of the 3178, the 3104 was intended to only connect to  3104  3104  3104  an 8100 through an R-loop. Little seems to be known about this  product.   Mainframe Peripherals 55 »   3472: The IBM InfoWindow was introduced in 1989, and was the final  3472  3472  3472  dedicated 3270 terminal before PCs running emulators took over. These  terminals supported graphics fully, and could run 5 concurrent ses-  sions! There were a variety of devices that could be attached without  any difficulty:  ź Mouse  ź Color plotter  ź Graphics tablet  ź Barcode scanner  PRINTERS: One of the other features provided by the 3270 line was  PRINTERS  PRINTERS  PRINTERS  support for printers. There were several printers made over the years:  ź 3284 matrix printer  ź 3286 matrix printer  ź 3287 matrix printer (there was a color model available)  ź 3288 line printer  ź 3268-1 (an R-loop printer for an 8100)  ź 4224 matrix printer   RJE TERMINALS  RJE TERMINALS  RJE TERMINALS  RJE TERMINALS  In the batch era (which IBM certainly prolonged), having cheap remote  batch terminals with a card reader/card punch/line printer was a cheap  way to expand the geographical footprint of a computer. These came  from IBM in the form of various Remote Job Entry workstations, which  attached to the host computer through a variety of communications  processors (described below). These connections were made in the form  of bisync connections or STR (Synchronous Transmit/Receive, an early  form of synchronous serial from IBM) connections, either directly to  the computer or through a dial modem, leased-line modem, packet-  switched X.25 network, or some other such similar connection.  RJE was supported by most batch spooling programs on the System/360  line; this included HASP (JES2, OS/360), ASP (JES3, OS/360), RES  (JES1, OS/VS1), POWER (VSE), RSCS and (VM). Some places took RJE and  ran it over other networks, like UCLA's NETRJS that ran on the  pre-TCP/IP ARPANET (and later on the TCP/IP ARPANET). RJE was also ran  over SNA. The RJE terminals themselves, much in the same way as the  3270 terminals, were often emulated by minicomputers/microcomputers.  In the pre-emulation era, IBM made the following batch terminals:   56 Mainframe History »   2780 DATA TRANSMISSION TERMINAL: This was released in 1967, and was  2780 DATA TRANSMISSION TERMINAL  2780 DATA TRANSMISSION TERMINAL  2780 DATA TRANSMISSION TERMINAL  itself comprised of four major subunits:  ź A bisync controller box, these would provide the minimum amount of  electronics necessary to talk to the host computer  ź A card reader and punch, derived from the IBM 1442 described  earlier; this particular iteration read 400 cards per minute and  punched 355 cards per minute  ź A line printer, derived from the IBM 1403, that printed 240 lines  per minute (though the chain could be shortened to a limited char-  acter set to increase print speed to 300 lines per minute)  ź A line transmit/receive buffering box that buffered up to one  print line or one read/punched card  There were in turn four different models made:  ź Model 1: capable of reading cards and printing output from the  host computer  ź Model 2: capable of reading cards, punching cards, and printing  output from the host  ź Model 3: capable of only printing data from the host  ź Model 4: capable of reading and punching cards, but not print  2770 DATA COMMUNICATION SYSTEM: Though not strictly a successor to  2770 DATA COMMUNICATION SYSTEM  2770 DATA COMMUNICATION SYSTEM  2770 DATA COMMUNICATION SYSTEM  the 2780 and more of an alternative, the 2770 was announced in 1969  and supposedly surpassed every other IBM terminal made to that point  in input and output capabilities. The 2770 came with an included CRT  terminal and keyboard, and could drive several downstream devices:  ź 2265 Display Station (see the previous section on the 2260 for  more on this)  ź 2502 Card Reader (model A1 or A2)  ź 5496 Data Recorder (punched the 96-column cards for the System/3)  ź 1053 Printer (model 1)  ź 1017 Paper Tape Reader (5/6/7/8 column, 120 chars/second)  ź 1018 Paper Tape Punch  ź 545 Card Punch (model 3, non-printing; model 4, printing)  ź 50 Magnetic Data Inscriber  ź 1255 Magnetic Character Reader (model 1/2/3)   Mainframe Peripherals 57 »   3780: The successor to the 2780 was the 3780, launched in 1972.  3780  3780  3780  Unlike the predecessor, there was a single model of this (but one  could get an optional card punch with it). The built-in card reader  read cards at 600 cards/minute, the punch (the 3781) punched 91  cards/minute maximum, and the printer printed 300 lines/minute  minimum.  The 3780 was extensively emulated by various other computers, like the  DEC DN60 in the late 70s. Software implementations were also rela-  tively common.  3770: This was the ultimate batch terminal, released in 1974. Suc-  3770  3770  3770  ceeding the 3780, these supported a variety of communications proto-  cols:  ź SDLC  ź BSC  ź Multileaved BSC  ź SNA  This was a series of desk-console terminals that existed in the fol-  lowing models:  ź 3771, with a wire matrix printer:  Ś Model 1: 40 cps printer  Ś Model 2: 80 cps printer  Ś Model 3: 120 cps printer  Ś All models could feature an optional reader and punch  _____________________________________________________  ź 3773, with a diskette and wire matrix printer:  Ś Model 1: 40 cps printer  Ś Model 2: 80 cps printer  Ś Model 3: 120 cps printer  ź 3774, with a wire matrix printer (and optionally a belt printer):  Ś Model 1: 80 cps printer  Ś Model 2: 12 cps printer  ź 3775, with a belt printer (and optionally a diskette):  Ś Model 1: 120 lpm printer   58 Mainframe History »   Ś Model P1: included a display terminal  ź 3776, with a belt printer  Ś Model 1: 300 lpm printer  Ś Model 2: 400 lpm printer  ź 3777, with a train printer  Ś Model 1: 1000 lpm printer  Ś Model 2: adds a card punch  Ś Model 3: adds a tape drive  Ś Model 4: replaces the printer with a slower 3262               Mainframe Peripherals 59 »   EARLY OSES - BPS/360, BOS/360, AND TOS/360  EARLY OSES - BPS/360, BOS/360, AND TOS/360  EARLY OSES - BPS/360, BOS/360, AND TOS/360  EARLY OSES - BPS/360, BOS/360, AND TOS/360  __________________________________________    BPS/360  BPS/360  BPS/360  BPS/360  In the early days of computing, you had to write nearly all of your  software. You might have a vendor-provided compiler for a high-level  language, an assembler, or nothing at all! When IBM launched the 360,  everyone had decided that computers being sold in that era should come  with some kind of operating system. IBM filled that void with, ini-  tially, two OS offerings: for the smaller machines (that is, the Model  30 and machines configured without much main storage), BPS/360; for  the larger systems, the customer could select BOS/360 or later systems  like TOS/360 and DOS/360.  BPS/360 (Basic Programming Support) was a combination of two OS  releases, both launching with the S/360 in mid-1965:  ź A punched-card edition, requiring no permanent storage devices  ź A tape edition, loading a small resident supervisor and using  tapes  The card version of BPS/360 was essentially many decks of standalone  utility programs. Disks and tapes could be initialized from certain  decks, an assembler could be loaded from one deck, and high-level lan-  guages were available too: RPG (Report Program Generator) and a subset  of FORTRAN IV were on offer -- the tape version of the FORTRAN com-  piler required 16 KB of storage, and the tape version of the assembler  likewise had more features (setting up the trend of the card versions  of the utilities being "worse" than the tape versions). Alas, BPS/360  was a bit of a failure. By the time BPS/360 was released, disks were  starting to become rather cheap -- this is definitely in direct con-  trast to the computing landscape of the IBM 1401 and IBM 7090 pre-  cursor errors, were disks were seen as a rare luxury.   BOS/360  BOS/360  BOS/360  BOS/360  Seeing the need for a real proper OS, IBM launched BOS/360 alongside  the System/360. There were initially three versions of BOS/360, which  would later end up being renamed:  ź BOS 8K for disk systems --> BOS  ź BOS 16K for disk systems --> DOS  ź BOS 16K for tape systems --> TOS  At the time of writing this, there exists a copy of the third system  on Bitsavers; it is labelled BOS, but is actually an early version of   60 Mainframe History »   TOS. The renaming of the three products occurred in May 1966, and  manuals from the time period can be somewhat obtuse if the reader does  not have a keen eye for the tape size being used. Alas, the 16K disk  system would go on to live a long and prosperous life (and still  remains alive today). Please do note that I (your author, Evie) am not  100% sure that this information is correct -- there appears to be con-  flicting information online and in manuals.  BOS/360 provided the following facilities:  ź A supervisor, a punched-card job loader, and an IPL loader (neces-  sary to control and operate the system)  ź A linkage editor, a librarian, and a system generation utility  named the Load System Program (all necessary for maintaining the  system)  ź An assembler, an RPG compiler, and FORTRAN, COBOL, and PL/I com-  pilers (for application development)  ź Sort/merge, a debugging aid called Autotest, various file utility  programs, and a remote job entry (RJE) client  Alas, BOS/360 proper (i.e. the 8K disk system that would run off a  2311 DASD disk drive), is merely a simplistic version of the later  DOS/360 system that would be released shortly thereafter. For users  without disk drives and only tape drives (provided they had enough  storage), TOS/360 was a choice. Both DOS/360 and TOS/360 shared many  similarities; there were at least 26 releases of TOS before its dis-  continuation, but DOS continued for at least 26 releases. Note: I am  ___________  not entirely sure on the accuracy of these version numbers -- I kept  ______________________________________________________________________  running into conflicting information in the composition of this work.  _____________________________________________________________________          Early OSes - BPS/360, BOS/360, and TOS/360 61 »   DOS/360, VSE, AND Z/VSE  DOS/360, VSE, AND Z/VSE  DOS/360, VSE, AND Z/VSE  DOS/360, VSE, AND Z/VSE  _______________________    DOS/360 AND TOS/360  DOS/360 AND TOS/360  DOS/360 AND TOS/360  DOS/360 AND TOS/360  DOS/360 and TOS/360 (even though TOS/360 died off) featured a rather  odd memory model -- since the BOS derivatives were considered to be a  "stop-gap OS" until OS/360 came out (which we will discuss next), the  architecture of the system can best be described as "antiquated."  Rather than having a memory-management model reminiscent of other  timesharing OSes like VMS where a program is free to grow its virtual  address space, DOS/360 and TOS/360 presented a variety of fixed memory  partitions within the non-virtual address space. DOS/360 did not have  a relocating loader, so all of the address offsets within programs had  to be made absolute when the program was linked -- this meant that a  program that was link-edited (the "link editor" being the old term for  what we now call just a "linker") for partition 0 would not run in  partition 3. Since there was no virtual memory, a malfunctioning  program in one partition could spell the doom of another partition;  the multiple partitions were merely for timeslicing at the scheduler  level.  Strangely enough, early versions of DOS/360 did not have a batch  spooler; a program would have to be started by hand (but multiple  could be ran from the console). Needless to say, this was rather anti-  quated even for DOS/360 standards; IBM introduced POWER (an acronym  for Priority Output Writers, Execution processors and input Readers),  and Software Design, Inc sold a spooler program called GRASP. Side  ____  note: I have read conflicting dates as to when POWER was introduced,  ______________________________________________________________________  and I cannot confirm that its existence predates GRASP.  _______________________________________________________  Alas, DOS/360 (while TOS/360 languished and eventually died) featured  quite a number of successful third-party applications, but the even-  tual release of OS/360 made DOS look more and more obsolete. Alas,  many customers continued to use DOS and it kept being upgraded along-  side the hardware. With the three memory partitions the system offered  (background, foreground 1, and foreground 2), users found the sim-  plistic system to be quite good for what it was.  Interesting fact I cannot verify: Dave's guide states that BOS/360 had  ______________________________________________________________________  a spooler, while DOS/360 and TOS/360 did not!  _____________________________________________   DOS/VS  DOS/VS  DOS/VS  DOS/VS  As the System/370 matured in 1973 with the addition of the DAT box on  all models (therefore giving the machines virtual storage, i.e.  memory, support), DOS sought an upgrade. While other teams elsewhere  at IBM were working on upgrading other OSes, DOS remained a strange  fixture as it was still rather antiquated in its design. When DOS/VS  was introduced in 1972 (the first version being Release 28; Release 27   62 Mainframe History »   was the last release of DOS/360), users now could run up to 5 memory  partitions (BG, then F1 through F4; F for Foreground, later  colloquially known as Fixed)! Alas, the primitive OS still had the  strange non-relocating-loader limit; though the system was technically  running within a virtual storage address space, it was more of a case  of "there is a single linear virtual address space containing all the  partitions (allowing for paging on and off of DASD), but each parti-  tion still is lined up back-to-back and therefore programs must be  link-edited for the partition they will run in." This "issue" would be  fixed by VSE/SP, but I cannot find a conclusive date when it was.   DOS/VSE  DOS/VSE  DOS/VSE  DOS/VSE  In 1979, IBM introduced extensions to DOS/VS that allowed it to gain  support for the then-new 4300 series; these machines contained a new  feature called ECPS that would speed up I/O performance by sharing the  storage address space the processor used with the I/O channels --  non-4300 systems could, of course, run DOS/VSE anyways. By then, com-  pilers were getting more sophisticated, as were the programs being ran  on the system; CICS/DOS/VS was the primary workload of choice on these  systems, even though CICS/DOS/VS ran on DOS/VS. Alas, DOS/VS did not  really contain advanced networking or online development facilities;  programming CICS consisted of submitting batch jobs (likely origi-  nating from another user under a VM system, which will be discussed  later) and submitting another batch job to make the transaction avail-  able to online terminals. When DOS/VSE became available, it began to  gain a number of solutions to these problems starting in the early  80s.   SSX/VSE  SSX/VSE  SSX/VSE  SSX/VSE  During the life of DOS/VSE, IBM sought it necessary to produce a rela-  tively "turnkey" package of the system. Small Systems Executive/VSE  contained the following products, giving us an interesting list of the  "who's-who" of DOS/VSE program products in 1982:  ź VSE/AF (see below), an upgraded version of DOS/VSE  ź VSE/POWER, the job scheduler  ź ACF/VTAM, for SNA networking and terminal control (which was  finally made available to DOS/VSE systems)  ź VSE/VSAM, providing OS VSAM to VSE  ź CICS/DOS/VS, an online transaction processing system  ź VSE/ICCF, an online program development/test/compile/edit system  that ran under CICS  ź VSE/OCCF, a program that oversaw the system and restarted compo-  nents if they failed   DOS/360, VSE, and z/VSE 63 »   ź VSE/IPCS, a debugger  ź DOS COBOL, a COBOL compiler  ź VSE Back Up/Restore, does what it says  ź VSE/Space Management, used for maintaining DASD storage  ź VSE/DITTO, used to transfer data and files from one device to  another   VSE/AF  VSE/AF  VSE/AF  VSE/AF  Launched in 1983, VSE/AF was seen as a much-needed upgrade to DOS/VSE.  It should be noted how programs were stored and ran on DOS: a so-  called "core image library" would be a dataset that contained multiple  members, of which your programs were stored in. When a program was  called, VSE would fetch the MYPROG core image (which had been already  link-edited and was ready to run) from the library. Maintaining these  libraries was necessary only for program-related tasks. VSE/AF Version  2 changed this. Rather than limiting libraries to just core images  (i.e. programs), IBM suggested they could be used for any purpose --  source files, data files, anything. While this certainly streamlined  storage management on VSE, it was also seen as somewhat of a radical  change; CMS/DOS, a component of VM/CMS that provided DOS/VSE compat-  ibility, could not use VSE/AF Version 2 and newer libraries.   VSE/SP  VSE/SP  VSE/SP  VSE/SP  When the IBM 9370 launched, IBM saw it fit to produce a successor to  SSX/VSE (which, by then, had remained stale; it was now 1986 and  SSX/VSE was commonplace in 1983). VSE/SP combined all of the features  of SSX/VSE, but updated them to the current era. VSE/SP systems often  found themselves running under VM (which was somewhat commonplace at  that time), and it saw extensive transaction-processing usage on  smaller systems that did not run OS (or MVS in that era). VSE/SP was  also a 24-bit system; there was no VSE/XA.   VSE/ESA  VSE/ESA  VSE/ESA  VSE/ESA  As VSE aged and the shops that ran VSE strove to push the system  harder and harder, VSE was due for a major architectural upgrade  around 1990 -- this came in the form of VSE/ESA, which assumed the  role of a 370/XA upgrade for VSE/SP. In that era, there was still a  desire to run what would have then been considered "old and obsolete"  370-only machines (such as 9370s or old 4300 series machines), so the  new VSE/ESA had both a 31-bit and 24-bit nucleus (31-bit being the  colloquial term for 370/XA native). VSE/ESA Version 1 was bimodal,  ______________  whereas Version 2 required ESA/370 hardware. When Version 2 was  released, it included a scheduler called the Turbo Dispatcher that  finally allowed a multiprocessor system to meaningfully be utilized   64 Mainframe History »   with a single VSE image (multiple partitions could run simultaneously  across multiple processors in the machine); up to 4 processors could  be adequately used, but the VSE/ESA nucleus could accommodate up to  10.  VSE/ESA also overhauled the partitioning scheme. While later versions  of DOS/VSE (and therefore VSE/AF and VSE/SP) added a feature to the  link editor to produce a relocatable module, the addresses within each  partition were still technically shared -- this meant that the BG par-  tition could run from X'0000' to X'01FF' and the F1 partition would  run from X'0200' to X'05FF' (these are not real numbers, merely an  example) and it was up to the DAT box to stop a program in BG from  clobbering the memory of F1. VSE/ESA addressed this, and also allowed  for up to 384 MB of storage to be used.  First, each partition (of which there were 12 so-called static parti-  tions, sometimes called fixed partitions) now had their own private  virtual address spaces -- every partition's memory address scheme  started at 0 and it was no longer a strict requirement to make every  program position-independent and relocatable. In addition, VSE gained  a new type of partition known as a dynamic partition, wherein programs  that would spill out of a static partition's address range could run  (but also physically reside in memory past the 16 MB bar). VSE/ESA  Version 1 could run up to 150 dynamic partitions.   IESADMSO1 VSE/ESA ONLINE  5686-032 and Other Materials (C) Copyright IBM Corp. 1990 and other dates  VV VV SSSSS EEEEEEE ++  VV VV SSSSSSS EEEEEEE ++  VV VV SS EE ++ EEEEEEE SSSSS AA  VV VV SSSSSS EEEEEE ++ EEEEEEE SSSSSSS AAAA  VV VV SSSSSS EEEEEE ++ EE SS AA AA  VV VV SS EE ++ EEEEEE SSSSSS AA AA  VVVV SSSSSSS EEEEEEE ++ EEEEEE SSSSSS AAAAAAAA  VV SSSSS EEEEEEE ++ EE SS AAAAAAAA  ++ EEEEEEE SSSSSSS AA AA  ++ EEEEEEE SSSSS AA AA  Your terminal is A001 and its name in the network is D20001  Today is 08/10/25 To sign on to DBDCCICS -- enter your:  USER-ID........ ________ The name by which the system knows you.  PASSWORD....... Your personal access code.  PF1=HELP 2=TUTORIAL 3=TO VM 4=REMOTE APPLICATIONS  10=NEW PASSWORD   Figure 1. VSE/ESA 1.1.0 logon screen   DOS/360, VSE, and z/VSE 65 »   IESADMSL.IESEPROG VSE/ESA FUNCTION SELECTION  APPLID: DBDCCICS  Enter the number of your selection and press the ENTER key:  1 Program Development Library  2 Manage Batch Queues  3 Create Application Jobstream  4 Problem Handling  5 Operations  6 File Management  7 Command Mode  8 CICS-Supplied Transactions     PF1=HELP 3=SIGN OFF 6=ESCAPE(U)  9=Escape(m)  ==>  Figure 2. VSE/ESA 2.7.0 programmer-type menu  Something of particular interest is a little-known controversy sur-  rounding TCP/IP on VSE. For most of its life, VSE was notably anemic  in its networking facilities outside of mainframe-native network pro-  tocols -- VSE had support for SNA and NJE (the two stalwarts of  mainframe networking for most of its existence), but it struggled to  "get with the times" when TCP/IP came around. Furthermore, no version  of VSE ever supported the OSI protocol, something that both MVS and VM  did support (in this context, the "OSI protocol" refers to the OSI  protocol family with CLNS/CLNP, TP0-TP4, etc; this protocol is com-  pletely unrelated to the TCP/IP stack). Throughout its lifetime, there  were at least 2 VSE-native TCP/IP stacks:  ź Connectivity Systems International's TCP/IP for VSE, providing  IPv4 support only  ź Barnard Software's IPv6/VSE, providing both IPv4 and IPv6  IBM would bundle the installers for both stacks after VSE/ESA had been  replaced by its successor, but the customer still had to separately  license the stack.     66 Mainframe History »   PING 1.1.1.1  TCP200I Client -- Startup --  TCP207I Copyright (c) 1995-1999 Connectivity Systems Incorporated  TCP202I Attempting to Establish Connection  TCP204I Connection has been Established  Client manager connected. Generated on 04/08/02 at 02.00  Selected client: PING  001.001.001.001  PING 1 was successful, milliseconds: 00009.  PING 2 was successful, milliseconds: 00009.  PING 3 was successful, milliseconds: 00008.  PING 4 was successful, milliseconds: 00008.  PING 5 was successful, milliseconds: 00008.  Client completed: PING  TCP201I Client -- Shutdown --  TCP205I Connection Complete -- Already Closed     Figure 3. CSI TCP/IP stack running a ping from a blank CICS screen   Z/VSE  Z/VSE  Z/VSE  Z/VSE  When the System Z launched in 2000, there was a notable lack of a new  VSE system until 2005. z/VSE 3.1 was released, but it contained no new  features over VSE/ESA 2.7 that came just before it -- it did not run  in 64-bit mode, and it also did not require Z hardware. In 2007, IBM  did release a Z-native version of the OS: z/VSE 4.1. It actually did  support the 64-bit operating mode, and the user could use up to 8 GB  of storage with it. Though user programs can use 64-bit registers, no  user program will ever actually see a 64-bit address in any partition  -- the supervisor only allowed user programs to see 31-bit virtual  addresses within the partitions. A new set of compilers was released  for the new release, though they were really just rebadges of the  earlier ESA generation of compilers.       DOS/360, VSE, and z/VSE 67 »   IESADMSO1 z/VSE ONLINE  5609-ZV4 and Other Materials (C) Copyright IBM Corp. 2005 and other dates   ++  ++ VV VV SSSSS EEEEEEE  ++ VV VV SSSSSSS EEEEEEE  zzzzzz ++ VV VV SS EE  zzzzz ++ VV VV SSSSSS EEEEEE  zz ++ VV VV SSSSSS EEEEEE  zz ++ VV VV SS EE  zzzzzz ++ VVVV SSSSSSS EEEEEEE  zzzzzzz ++ VV SSSSS EEEEEEE  Your terminal is CL20 and its name in the network is Z62LCL20  Today is 08/10/2025 To sign on to DBDCCICS -- enter your:  USER-ID........ ________ The name by which the system knows you.  PASSWORD....... Your personal access code.  PF1=HELP 2=TUTORIAL 4=REMOTE APPLICATIONS  10=NEW PASSWORD   Figure 4. z/VSE 4.1.0 logon screen            68 Mainframe History »   SYSTEM: ZVSE41 z/VSE 4.1 TURBO (01) USER: SYS  VM USER ID:VSE TIME: 1 8:53:34  F1 0001 1Q14I NO MATCHING PUB FOR 030  F1 0001 1QH3I 146 OF 742 DBLK GROUPS LOST  d q  AR 0015 1C39I COMMAND PASSED TO VSE/POWER  F1 0001 1R49I QUEUE FILE 003% FULL - 1266 FREE QUEUE RECORDS  F1 0001 1R49I USED QUEUE RECORDS: 44, CRE-Q: 3, DEL-Q: 0  F1 0001 1R49I RDR-Q: 25, LST-Q: 16, PUN-Q: 0, XMT-Q: 0  F1 0001 1R49I QUEUE FILE EXTENT ON FBA-250, SYS001, 59904, 1024  F1 0001 1R49I DATA FILE 029% FULL - 530 FREE DBLK GROUPS  F1 0001 1R49I CURRENT DBLK SIZE=07680, DBLK GROUP SIZE=00008  F1 0001 1R49I DATA FILE EXTENT 1 ON FBA-251, SYS002, 376320, 89088  F1 0001 1R49I ACCOUNT FILE 37 % FULL  F1 0001 1R49I ACCOUNT FILE EXTENT ON FBA-251, SYS000, 465408, 2048   ==>  1=HLP 2=CPY 3=END 4=RTN 5=DEL 6=DELS 7=RED 8=CONT 9=EXPL 10=HLD 12=RTRV  ACT_MSG: HOLDRUN PAUSE: 01 SCROLL: 1 MODE: CONSOLE  Figure 5. z/VSE 4.1 system console   VSEN  VSEN  VSEN  VSEN  In 2022, a non-IBM company took over the development of z/VSE. This  company, known as 21st Century Software, released VSE(n). Since 21CW  longer could use IBM trademarks, every program product on the system  was promptly renamed to an alternate name; DITTO became SMDMU, VTAM  became VCDD, so on and so forth. Otherwise, VSE(n) was essentially a  "maintenance release;" the days of new VSE features are long since  gone, with most of the development on VSE happening in the realm of  the "connectors" -- workstation utilities that make administering,  programming, and operating VSE systems a bit easier for a novice user  not familiar with the panel-driven ICCF user interface.       DOS/360, VSE, and z/VSE 69 »   IESADMSO1 VSEn ONLINE  5609-VSE and Other Materials (C) Copyright IBM Corp. 2016 and other dates  2121-VN6 (c) Copyright 21st Century Software, Inc. 2022   VV VV SSSSS EEEEEEE nn nnn  VV VV SSSSSSS EEEEEEE nnnnnnn  VV VV SS EE nn nn  VV VV SSSSSS EEEEEE nn nn  VV VV SSSSSS EEEEEE nn nn  VV VV SS EE  VVVV SSSSSSS EEEEEEE  VV SSSSS EEEEEEE  Your terminal is A000 and its name in the network is D7010001  Today is 08/11/2025 To sign on to DBDCCICS -- enter your:  USER-ID........ ________ The name by which the system knows you.  PASSWORD....... Your personal access code.  PF1=HELP 2=TUTORIAL 3=TO VM 4=REMOTE APPLICATIONS  10=NEW PASSWORD  Figure 6. VSEn 6.3.0 logon screen             70 Mainframe History »   OS/360, MVS, AND Z/OS  OS/360, MVS, AND Z/OS  OS/360, MVS, AND Z/OS  OS/360, MVS, AND Z/OS  _____________________    Initially, before the System/360 was shipped, IBM hoped that there  would be a single batch OS and a single timesharing OS (TSS/360) for  users to select between. Instead, this was not the case; during the  development run of the System/360, IBM had not yet finished the "ulti-  mate batch OS" -- OS/360. As a matter of fact, its development was  dragging so far behind that they were forced to release the aforemen-  tioned BOS/360 and BPS/360 initially. In other words, the BOS/360  derivatives (that is, DOS/360 and TOS/360) were intended to be tempo-  ______  rary operating systems; stopgap measures to hold over customers until  ____  OS/360 released. Sadly, due to major ABI and architectural differ-  ences, users found it rather difficult to port programs from DOS/360  to OS/360 when it eventually did come out.  OS/360's development was so laggy that its release came in three major  waves:   OS/360 PCP  OS/360 PCP  OS/360 PCP  OS/360 PCP  Because OS/360 had logged behind so much in its development, IBM was  desperate to get something shipped. This came in the form of the  OS/360 Primary Control Program, bearing the Single Sequential Sched-  uler (SSS). In 1966, customers could finally get a tape for what was  essentially a single-tasking OS. PCP was a sequential-schedule system  where a job would be submitted from the reader, and rudimentary  spooling facilities meant that the reader would have to be pre-stacked  with every job that the system would run. Needless to say, this was  seen as a rather useless system by nearly every 360 customer.It did  have at least one redeeming quality, though: if your mainframe had 48  KB of storage, you could run PCP and have the facilities of OS/360  without the bloat of a big multi-partition scheduler. For customers  that had CP-40 or CP-67 (which will be discussed later), PCP provided  a storage-light single-user development-capable OS system.   OS/360 MFT  OS/360 MFT  OS/360 MFT  OS/360 MFT  For users that had a more advanced ("midrange 360") system, they could  choose to run OS/360 MFT -- Multitasking with a Fixed number of Tasks.  This option was called "Multiple Sequential Schedulers" (MSS), and was  also a temporary holdover measure until the third scheduler option was  finished. MFT, being a more advanced version of PCP, provided you with  4 memory partitions (similar to how DOS worked). It was notoriously  difficult to manage multiple partitions by hand from the console (as  the operator would have to manually direct jobs from the reader into a  partition such that the OS/360 nucleus could parse the JCL and run the  job), so nearly every site chose to install a program called HASP --  Houston Automatic Spool Priority (as in, "Houston, we have a problem")   OS/360, MVS, and z/OS 71 »   alleviated this, and it would live on in the MVS line as JES2 (which  we will cover later).  When MFT was replaced with MVT (see below), MFT received a major  upgrade called MFT-II: gone was the 4-partition limit, you now had 52  at your disposal! The final releases of MFT-II actually eliminated the  task limit, so stalled jobs could wait in a queue and eventually be  dispatched to an available partition.   OS/360 MVT AND TSO  OS/360 MVT AND TSO  OS/360 MVT AND TSO  OS/360 MVT AND TSO  After much aforementioned delay, OS/360 MVT came out -- Multitasking  with a After much aforementioned delay, OS/360 MVT came out -- Multi-  tasking with a Variable number of Tasks! The scheduler was said to be  of the "multiple priority schedulers" configuration, and could even  run on a multiprocessor system if the customer had the expensive Model  65 Multiprocessing (often called the "Model 65MP"). Since MVT was not  available until 1967, the OS had gained substantial complexity; users  needed at least 512 KB of storage to run this now-released OS/360.  Since MVT provided a non-fixed-partition memory management model, it  was now possible to have various programs running at the same time  with different memory usages. However, this introduced an interesting  problem! Because the System/360s that MVT ran on did not have a DAT  box to perform virtual memory mapping, users found that their MVT  systems would have vastly-underutilized main storage after running  many programs.  This was simply due to the fact that there was no virtual memory; the  scheduler would employ a best-fit algorithm to try to find an avail-  able "memory hole" between two (or more) running programs in main  storage, and the program could use as much storage as it wanted to  until it hit the bound of the next program in the address space. This,  of course, resulted in heavy memory fragmentation, particularly on  timesharing systems.  TIME SHARING OPTION: Speaking of timesharing, the ultimate failure of  TIME SHARING OPTION  TIME SHARING OPTION  TIME SHARING OPTION  TSS/360 (which will be discussed later) resulted in a vacuum-void of a  quality timesharing system (from IBM's perspective; mind you, CP-67  was well on its way to becoming the dominant timesharing system by  this time). IBM's answer to this void came in 1971 with the release of  the Time Sharing Option on OS/360 Release 20.1. Since IBM had many  communications controllers and terminals at the time, there needed to  be some kind of unified way to drive all of these devices; throughout  the life of OS/360 (and DOS/360 too), there were a variety of "tele-  communications access methods" (what we might nowadays might call "an  API"):  ź Basic Telecommunications Access Method (BTAM), providing little  more than basic typewriter terminal control  ź Queued Telecommunications Access Method (QTAM), allowing terminal  devices to be operated like files   72 Mainframe History »   ź Telecommunications Access Method (TCAM), an evolved QTAM with  added message-passing and queuing support  ź Virtual Telecommunications Access Method (VTAM), a true network  interface and cross-system-network  When TSO was unveiled, it used the then-advanced TCAM to support a  variety of terminals -- typewriter terminals, early glass terminals  that used acoustic delay-line memory to store the screen (the 2260),  and the later famous 3270 series. TSO was primarily seen as a massive  aid to programmers, who could now use an online editor, job result  output viewer, debugger, interactive compiler, and more in an online  fashion. While the TSO command line could best be described as "hand-  keyed JCL" and the TSO editor could best be described as "an exercise  in getting lost on a computer," it provided a framework for better  applications further down the road that would turn TSO into a proper  timesharing experience (these being mainly the alphabet soup of ISPF,  SDSF, SDF, and other such things).  Something of particular interest is the modularity of the system.  Because PCP/MFT/MFT-II/MVT were merely just different "kernels"  running the same underlying operating system, absolutely no changes  were necessary to move programs from a machine running one to a  machine running the other; even the batch job JCL that ran the pro-  grams would work. Programs running on the newest release of MFT and  MVT could both spawn multiple subtasks, allowing a form of multi-  threading; both scheduler options provided some form of spooling  (though HASP and ASP filled that void).  HASP AND ASP: OS/360 was intended to be as modular as possible. One  HASP AND ASP  HASP AND ASP  HASP AND ASP  of the results of that was the creation of a universal interface for a  spooler to hook into; the OS/360 nucleus itself would not be respon-  sible for much spooling, instead deferring to a dedicated subsystem  that would perform that and other tasks. There were two major programs  that resulted from this: HASP and ASP.  HASP, or the aforementioned Houston Automatic Spooling Priority, was  the first mature job scheduler for OS/360 MFT/MVT. It would live on as  JES2 on the descendants of OS/360, and was written for the Lyndon B.  Johnson Space Center in Houston, Texas. It was intended to run on a  single machine with one or more processors, and newer versions of it  supported remote workstations (something very important in that era,  as computers were rare and a RJE workstation in a remote office was  quite a useful deal in the 1960s. Eventually, HASP gained multi-  access-spool support, allowing multiple machines connected to the same  spooling disk to both execute queued jobs.  ASP (Attached Support Processor), on the other hand, was a much more  complex beast. Living on today as JES3, ASP is a real loosely-coupled  multiprocessor system that released first in March 1967; two S/360s  would be connected via a CTCA and they did not have to be the same  model. ASP also provided a level of failover should a system crash or  malfunction. Perhaps the coolest feature in the product was the fact  that it actually supported scheduling and dispatch of 7090/7094 jobs;   OS/360, MVS, and z/OS 73 »   the 360 was backwards-compatible with 709x thanks to an emulator  program. The OS could choose to engage it, and ASP would: if it  encountered a 709x job, it would invoke the emulator and run the job  accordingly.   OS/VS1  OS/VS1  OS/VS1  OS/VS1  When the System/370 was announced, a new OS was in order. IBM  naturally sought to provide some kind of new OS. Learning much from  the slow and difficult development of OS/360 and applying what they  had already been doing with DOS/VS, they chose to produce OS/VS1 in  1972. This was, by all accounts, OS/360 MFT-II running within a  single virtual address space. Much like DOS/VS was DOS/360 running  within a virtual address space, OS/VS1 crutched on OS/360's relocating  loader but provided virtual storage paging (what modern computer users  might know as "swapping") to the entire address space.  OS/VS1 had no TSO, but there was a version of CICS available for it  and every compiler that ran under the later OS/VS2 would run on  OS/VS1. VS1 did have its own job scheduler called JES1 (Job Entry  Subsystem 1) that was derived from the basic scheduler found on OS/360  MFT, but it was ultimately a failure (as many people had modified HASP  and ASP in the OS/360 days, and wished to continue to use the software  they had spent so much effort tailoring). JES1 was relatively novel in  the sense that, unlike on MFT where every reader/writer (writer being  a printer or punch) task took up its own partition, VS1 users could  reclaim those partitions and only temporarily use a free partition  when a job started or finished. MFT's scheduler also used multiple  spooling files on the system DASD, but JES1 used a singular common  spooling dataset -- this was a feature inspired by the  spool/checkpoint model of HASP.   OS/VS1 BPE  OS/VS1 BPE  OS/VS1 BPE  OS/VS1 BPE  Plain OS/VS1 had 7 releases, with 4 releases of an add-on product  called Basic Programming Extensions. These added support for more  hardware common on early-1980s System/370 machines (like 3380 DASD and  newer printers), and allowed VM to handshake VS1's console with VCNA  (the precursor to ACF/VTAM on VM). Release 4 of BPE was announced in  March 1984, but VS1 continued to feature IBM service until the 28th of  February, 1990 -- a stunningly-long time for a stopgap OS.      74 Mainframe History »   IPL 14A  IEA760A SPECIFY VIRTUAL STORAGE SIZE  IEA788I NON-PAGING MODE  IEE116A TOD CLOCK INVALID  IEA101A SPECIFY SYSTEM AND/OR SET PARAMETERS FOR OS/VS1 70.D BPE 01.03.0  r 00,'date=80.180,clock=10.10.10,gmt'  IEE055A SPECIFY LOCAL DATE AND/OR CLOCK  r 00,'clock=10.10.10'  IEF597I SYSTEM RESTART IN PROGRESS  IEF450I VMWTR .VM00D . ABEND S2F3 TIME=03.41.01  IEF421I INIT=VMWTR.VM00D (2) NO RESTART  IEF450I VMWTR2 .VM00E . ABEND S2F3 TIME=03.41.01  IEF421I INIT=VMWTR2.VM00E (2) NO RESTART  IEF450I WTR .S7F . ABEND S2F3 TIME=03.41.01  IEF421I INIT=WTR.S7F (2) NO RESTART  IEF450I WTRZ .WTRZ . ABEND S2F3 TIME=03.41.01  IEF421I INIT=WTRZ.WTRZ (2) NO RESTART  IEF450I INIT .P1 . ABEND S2F3 TIME=03.41.01  IEF421I INIT=INIT.P1 (2) NO RESTART  IEF450I INIT .P2 . ABEND S2F3 TIME=03.41.01  IEF421I INIT=INIT.P2 (2) NO RESTART  MORE... VMHPO  Figure 7. OS/VS1 Release 7 BPE Release 3 starting under VM/HPO.   OS/VS2 SVS  OS/VS2 SVS  OS/VS2 SVS  OS/VS2 SVS  Much like OS/VS1, a stopgap port of OS/360 MVT to the System/370 was  released in 1972. Working in the same way as VS1 (where the system ran  within a 16 MB virtual memory address space to allow for paging),  OS/VS2 Release 1 was a major development milestone in what would later  become MVS. Release 1 was often called SVS (Single Virtual Storage),  as that accurately reflected the memory-management model of the OS.  SVS, being an enhancement of MVT, changed a few core scheduler func-  tions to properly take advantage of the new hardware. One such example  was the switchover from using less-accurate timing mechanisms on the  360 to using the 370's interval timer. Likewise, the way that the OS  loads SVC (SuperVisor Call, a system call if you will) routines is  quite different. On MVT, the nucleus would load all of its SVC rou-  tines from SYS1.SVCLIB into various transient area memory blocks.  SVS, instead, would load these from SYS1.LPALIB into the Pagable Link  Pack Area (PLPA) during a cold IPL (that is, starting the system with  the CLPA option) -- this was then pagable, unlike on MVT where paging  was not an option.  Thanks to a lawsuit with Applied Data Research, SVS (and VS1, for that  fact) did not include many applications that OS/360 once came with;  this included compilers, assemblers, a sort/merge program, and some   OS/360, MVS, and z/OS 75 »   timesharing features. This caused a price headache for some users, who  were forced to pay more for what was once free software.  SVS was intended to be a bit more reliable than MVT, and a new feature  that was added to aid this was the Authorized Program Facility;  certain programs could use SVCs that may cause system damage if and  only if they were link-edited with a certain option and were placed  into the system-wide link-list (think of this like the system-wide  PATH on a UNIX system). SVS also permitted users to append to the PLPA  on subsequent warm IPLs (that is, without the CLPA start option); the  Modified LPA would follow the Fixed LPA specified from the SVCLIB  dataset. As primitive as this sounds now, this was seen as an advanced  feature then!  SVS was also a uniprocessor-only system; customers with a multi-  processor 370 configuration would have to wait for MVS. Likewise, it  introduced no new batch spooler; it retained MVT's primitive built-in  spooler, but most customers opted to just use HASP or ASP instead  (side note: there is an image of OS/360 MVT 21.8 retrofitted with SVS  ______________________________________________________________________  HASP that you can download and run on Hercules).  _______________________________________________  SVS did include TSO, and it did include both TCAM and VTAM to drive  terminals. For customers that had 2250 vector-graphics terminals, they  could no longer be used with TSO as the access method library once  provided by OS/360 to drive them was no longer present. As a matter of  fact, SVS didn't even include VSAM at first; VSAM had not yet proven  itself as a major storage access method at the time of SVS's release,  but it certainly did by the time of MVS's release (for the confused,  VSAM was used as the underlying storage engine that many mainframe  database applications use, even to this day; it is a record-indexed or  key-indexed file seeking/storage/retrieval method).   OS/VS2 MVS  OS/VS2 MVS  OS/VS2 MVS  OS/VS2 MVS  Note: also called "MVS/370"  Note: also called "MVS/370"  Note: also called "MVS/370"  Note: also called "MVS/370"  ___________________________  In 1974, after SVS had ran its course two years prior, OS/VS2 was  primed for another upgrade. This came in the form of OS/VS2 Release 2,  famously called Multiple Virtual Storage (or MVS). Unlike SVS, MVS  actually provided multiple virtual address spaces to programs; wherein  each program would only be able to access its own private address  space (in the same way that, for example, processes found themselves  on a virtual memory UNIX system). This provided a massive boom to  system reliability, also aided by the natural inclusion of all of the  big new features added in SVS. Since MVS provided uniform address  spaces within each job address space, it was now possible to implement  commonplace virtual memory features like shared libraries, shared com-  munications segments, and memory-mapped files (though MVS famously did  not provide this).  MVS also provided symmetric multiprocessing support for the first time  on an OS/VS system; SVS was famously lacking in this regard. Alas, ASP  users could still use their loosely-coupled multiprocessing configura-   76 Mainframe History »   tions; they could also choose to upgrade to the new JES3 -- HASP users  would find themselves installing JES2 (as both programs had been  renamed when MVS released, and IBM started to properly include them in  the base OS). Though the second-to-last release of MVT (21.8F) came in  1974 too, MVS was rapidly adopted.  MVS/SE: IBM, seeing that they could charge extra for extensions to  MVS/SE  MVS/SE  MVS/SE  base OS/VS2 MVS, released MVS/System Extensions in 1978. This was  mainly a performance upgrade to existing OS/VS sites, as some repeti-  tive OS kernel function segments were relocated into the machine's  microcode (side note: I do not know how this was done). TSO logical-  ______________________________________________  swapping was introduced too, wherein a user could remain in virtual  memory but be swapped out to the DASD paging file; this definitely  caused the user's online sequence to take a performance hit, but high-  memory-usage conditions could be alleviated thanks to this. There was  another release of MVS/SE, Release 2, that further microcodified the  OS.   MVS/SP 1.1-1.3  MVS/SP 1.1-1.3  MVS/SP 1.1-1.3  MVS/SP 1.1-1.3  The logical upgrade to MVS/SE was MVS/System Product, which bundled  many useful products. These included:  ź ACF/VTAM (SNA networking)  ź DFP (Data Facility Product)  ź TSO Command Package  ź TSO/E (TSO Extensions, replacing the TSO Command Package)  ź JES2 or JES3 Version 1  Other optional products like ISPF and SDSF were frequently bundled,  and this saw hefty adoption. At this point, the version number of MVS  was 3.8, which would be reflected in all subsequent versions of MVS.  3.8  3.8  3.8  During IPL, the system would display the SP release level:   IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2,VER=SP1.3.3 JBB1329  Figure 8. MVS/SP 1.3.4 IPL top message      OS/360, MVS, and z/OS 77 »   ----------------------- ISPF/PDF PRIMARY OPTION MENU ------------------------  OPTION ===>  USERID - WEC  0 ISPF PARMS - Specify terminal and user parameters TIME - 14:50  1 BROWSE - Display source data or output listings TERMINAL - 3278  2 EDIT - Create or change source data PF KEYS - 12  3 UTILITIES - Perform utility functions  4 FOREGROUND - Invoke language processors in foreground  5 BATCH - Submit job for language processing  6 COMMAND - Enter TSO command or CLIST  7 DIALOG TEST - Perform dialog testing  8 LM UTILITIES- Perform library administrator utility functions  9 IBM PRODUCTS- Additional IBM program development products  C CHANGES - Display summary of changes for this release  T TUTORIAL - Display information about ISPF/PDF  X EXIT - Terminate ISPF using log and list defaults  Enter END command to terminate ISPF.   Figure 9. ISPF/PDF user interface on MVS/SP 1.3.4  One of the biggest "upgrades" bought with MVS/SP Version 1 was the  addition of support for the aforementioned Dual Address Space feature  of the 303x System/370 CPUs. Newer versions of MVS/SP gained support  for the Extended Real Addressing (the 26-bit real address scheme)  introduced on the 3033 and 3081; information processing workloads were  starting to get memory-intensive enough by the late 1970s that having  more than 16 MB of real storage began to look more and more attrac-  tive.  ISPF AND SDSF: As MVS/SP was gaining more and more traction, IBM  ISPF AND SDSF  ISPF AND SDSF  ISPF AND SDSF  produced a rather useful user interface for MVS. As TSO was certainly  obtuse to use, many sought some kind of simplified interface. IBM  launched this in the form of the Structured Programming Facility (i.e.  SPF) in 1978. This program used the 3270 terminals to provide a proper  dialog-driven interface, editor, and file manager for TSO. This would  later evolve into the Interactive System Productivity Facility (ISPF),  and it was even ported to VM and VSE!  A similar program was SDSF, the Spool Display and Search Facility,  launched in the mid-1980s. This was a replacement to the cumbersome  TSO way of retrieving spooled batch job output; many sites had both  ISPF and SDSF installed. Both programs still exist on z/OS as staples  of the environment.      78 Mainframe History »   V1R2--------------------- SDSF PRIMARY OPTION MENU --------------------------  COMMAND INPUT ===> SCROLL ===> PAGE  Type an option or command and press Enter.  LOG - Display the system log  DA - Display active users of the system  I - Display jobs in the JES2 input queue  O - Display jobs in the JES2 output queue  H - Display jobs in the JES2 held output queue  ST - Display status of jobs in the JES2 queues  PR - Display JES2 printers on this system  INIT - Display JES2 initiators on this system  TUTOR - Short course on SDSF (ISPF only)  END - Exit SDSF  Use Help key for more information.  5665-488 (C) COPYRIGHT IBM CORP. 1981, 1989. ALL RIGHTS RESERVED   Figure 10. SDSF V1R2 on MVS/SP 1.3.4   MVS 3.8J  MVS 3.8J  MVS 3.8J  MVS 3.8J  In 1981, the final base (i.e. free) release of MVS would release  before all development effort went into successor systems: MVS 3.8J.  This version is most famous to the mainframe hobbyist community that  emerged in the early 2000s, as it was easily attained from a set of  tapes found at Princeton University. The mainframe hobbyist community  has supported MVS 3.8J with updates over the years, making it into  quite the entertaining system for a mainframe newcomer.   MVS/XA  MVS/XA  MVS/XA  MVS/XA  When the System/370 XA (and later ESA/370) machines had hit the main-  stream, it was time for MVS to be alleviated of its 64 MB real storage  limit. At the time MVS/XA was being released, application data needs  had grown past 64 MB (the 64 MB limit being the 26-bit address limit  of MVS/SP). MVS Version 2 (called MVS/XA) was released in 1983,  famously developed under a version of VM/CMS that did hefty hardware  simulation before the hardware it was destined to run on (much in the  same way System/370 software was developed).  XA versions of program products quickly followed, including CICS/VS,  compilers, IMS/VS, etc -- the new MVS/XA machines could now sustain  many more logged-on users with improved swapping. ISPF/PDF had now  become nearly universal, and TSO became (relatively) easy to use   OS/360, MVS, and z/OS 79 »   thanks to it. MVS/XA found itself ran for about a decade, and the 2 GB  real storage limit was decided to be plenty for any computer in the  80s. 24-bit programs could still be ran (as clever S/360 programmers  realized that the upper 8 bits of a 24-bit address could be used for  other purposes), and conversion of programs to the new 31-bit  addressing scheme would be done with the help of an updated XA-capable  assembler (so-called Assembler H). Some 370/XA machines available then  found themselves bearing more than 2 processors, and MVS/XA could  properly utilize these. Over the course of its life, MVS/XA collected  many important changes to the MVS line, which would gradually drag it  towards its next major release -- MVS/ESA.   IEA097I I/O CONFIGURATION 00 SELECTED  IEA091I NUCLEUS 1 SELECTED  | IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2,VER=SP2.2.3  | JBB2223  | IEA347A SPECIFY MASTER CATALOG PARAMETER  IEA940I THE FOLLOWING PAGE DATA SETS ARE IN USE:  PLPA .......- PAGE.VX23CAT.PLPA  COMMON .....- PAGE.VX23CAT.COMMON  LOCAL ......- PAGE.VX23CAT.LOCAL1  IEA301I IEFUJV NOT FOUND IN SYS1.LINKLIB  IEA301I IEFUTL NOT FOUND IN SYS1.LINKLIB  IEA829I SVC 66 FOR BTAM NOT USABLE, MODULE IGC0006F NOT FOUND IN LPA .  IEA826I IEASVC00: SVC244: TYPE 4 ROUTINE IGC0024D NOT FOUND.  IEA191I CONSOLE 010 DEFINED AS MASTER CONSOLE.  IEA958I EXCP APPENDAGE NAME TABLE NOT BUILT  IEF338I DEFAULT EDT ID VALUE 00 USED.  IEA598I TIME ZONE = W.05.00.00   #   Figure 11. Console of an IPLing MVS/XA 2.2.3 system.  In addition to the changes listed, I/O device channels could now be  dynamically selected and reconnected should hardware failures occur;  the 370/XA architecture featured a totally different I/O channel  control model (using subchannels in lieu of plain channels found on  normal S/370 systems), and this design allowed this facility to  develop. Cached DASD controllers were starting to develop in the  mid-80s, and MVS/XA natively supported these (some models of the 3880  had cache, and the 3990 had cache natively). To expand the perform-  ance of systems armed with slower but still relatively quick auxiliary  storage, the Auxiliary Storage Manager was overhauled to allow paging  of jobs more quickly (to get them out of main storage if a constraint  is hit). Expanding VSAM disk storage, the new Data-In-Virtual feature  provided a UNIX-style memory-mapped-file access method (this would be  expanded in MVS/ESA with a feature called data spaces and later   80 Mainframe History »   hiperspaces). The new 370/XA Vector Facility was also supported -- by  this time, mainframes were starting to run a lot of CAD workloads  thanks to advanced vector graphics terminals (like te 5080) gaining  popularity. A vector facility (somewhat akin in function to a modern  GPU 8minus the video output) provided good acceleration for such  applications, and it was trivial to use from FORTRAN programs. The  last release of MVS/XA came in 1989, with the above MVS/XA 2.2.3.   MVS/ESA  MVS/ESA  MVS/ESA  MVS/ESA  VERSION 3: MVS/ESA was a relatively quick product, development-wise.  VERSION 3  VERSION 3  VERSION 3  Building on MVS/XA Release 2 (which itself was MVS/SP Version 2, so  MVS/XA R2 = 2.2.x), MVS/ESA SP Version 3 (so, MVS/SP 3.x.x) released  in February 1988. Running on the new ESA/370 machines, MVS/ESA over-  hauled a few key components of MVS. Rather than allowing a process to  only have a single address space, programs could now use so-called  data spaces (thanks in no small part to having a set of new access  registers on the ESA/370 CPUs). By the time MVS/ESA 3.1.3 was common-  place, Hiperspaces were also present -- these were a bit different  than data spaces, accessed using two macros and functioning somewhat  like DMA from the view of the program. A new facility called data  lookaside (DLF) provided a shared hiperspace facility that multiple  jobs could use called hiperbatch; DFSMS made storage management much  easier by providing an IBM-native tape, DASD, and backup management  product that came with the OS (yet another third-party program you  didn't have to buy or write). Communications were becoming more and  more advanced, too: in 1988, IBM released a TCP/IP stack for MVS/SP,  but its performance was limited by a number of factors. On MVS/ESA,  the TCP/IP stack code saw some substantial performance improvements  and feature additions.  VERSION 4: MVS/SP V4 released in 1990, adding support for the ESA/390  VERSION 4 _________  VERSION 4  VERSION 4  hardware that was then relatively new. A very major feature of MVS (at  least on newer MVS systems) was the parallel sysplex -- specialized  coupling hardware that provided reasonably tight-coupling (well, cer-  tainly moreso than a JES3 cluster) of multiple mainframes together; to  facilitate this, an XCF (cross-coupling facility) box had to be used.  Rather than using assembler macros to add and remove I/O device defi-  nitions (and then having to do a nucleus generation), once could now  use Hardware Configuration Definition dialog system -- this was a  menu-driven application that ran from ISPF, and thanks to Dynamic  Reconfiguration Management, I/O devices could be hot-added and hot-  removed without IPLing. Systems that possessed PR/SM (so, System/390s)  would work with DRM and HCD to do this hardware redefinition  on-the-fly. The MVS console interface was upgraded too, with much more  functionality to aid multiple-console'd mainframes that were starting  to be seen. As networking continued to evolve and IBM pushed APPC  (over SNA), MVS gained native support for APPC applications through  APPC/MVS (meaning that APPC was no longer the realm of VM/CMS; DOS,  OS/2, OS/400, AIX, and any third-party platform had yet to gain APPC  support and would not do so until about 1993 or so). MVS JCL was also  expanded -- you could now use various statements like IF (already seen  in VSE JCL) and INCLUDE to trigger the manual inclusion of a JCL pro-   OS/360, MVS, and z/OS 81 »   cedure. Version 4.1.0 and 4.2.0 was said to be rather unstable and  crashy, but 4.3.0 (the last release in the MVS V4 line) was very  stable.  OPENEDITION: Announced in February 1993 as an expansion to existing  OPENEDITION  OPENEDITION  OPENEDITION  MVS/ESA 4.3.0 systems, OE provided full UNIX emulation and POSIX com-  pliance to MVS. To facilitate this, a UNIX-style hierarchical file  system (which itself was provided by DFSMS) was integrated into the  system, and the OpenEdition (OMVS) kernel would mount various HFS  datasets to various paths within the UNIX-style VFS (virtual  filesystem for those not familiar with UNIX terminology). Most of the  actual command line tooling was not from IBM's own UNIX, AIX, but  instead from Mortice Kern Systems's InterOpen package (which was  famously seen in other UNIX emulator packages for other OSes,  including the famous POSIX subsystem on Windows NT). Strangely enough,  even with OMVS being an emulation of a UNIX environment, it was actu-  ally more POSIX-compliant than most UNIX systems on the market then  (with some UNIX specialists in that era claiming that it was more than  80% compliant with the POSIX, X/Open, Single UNIX Specification, and  UNIX Certification requirements -- moreso than its native UNIX compe-  tition)! OMVS gained the valuable FIPS 151 certification for MVS,  which was necessary if the platform was to remain a purchasable  interest of the US federal government.  VERSION 5: MVS/SP V5 was announced in April 1994, and bought big  VERSION 5 __________  VERSION 5  VERSION 5  expansions to the sysplex and Coupling Facility features: the new Par-  allel Sysplex feature was an even-further-evolved incarnation of the  coupling scheme unveiled in MVS/ESA Version 4. The System Resource  Manager gained a new Workload Manager expansion, called Goal Mode,  wherein the WLM will work with things like CICS to try to pre-allocate  resources (rather than lazily allocate resources when the CICS trans-  action asked for them). Version 5 represented the peak of the MVS/ESA  craft before it was ultimately replaced, and major work was done on  this period in streamlining the OS. A slow P/390 could run it reason-  ably well, even! Alas, the many complex licensing configurations and  installation methods left IBM yearning for a grand unification, and  that would come with OS/390.   OS/390  OS/390  OS/390  OS/390  VERSION 1: In late 1995, IBM began to wonder if it was a good idea to  VERSION 1  VERSION 1  VERSION 1  continue to offer the separate packaging/licensing scheme for MVS/ESA.  While that OS version had definitely gained quite a bit of new fea-  tures over its life, this left IBM and customers with a massive number  of product configurations (and ordering MVS/ESA was apparently  becoming more and more difficult). IBM's answer in late 1995 was to  attempt to unify the packaging and distribution for MVS/ESA, and this  resulted in OS/390. While OS/390 Version 1 and Version 2 (the latest  release of which is OS/390 V2R10) ran up until the year 2000, OS/390  ____________  itself did not really introduce many new products.  The compilers for MVS/ESA were renamed to things like "XYZ for OS/390  and VM" (such as "COBOL for OS/390 and VM"), and OpenEdition was inte-   82 Mainframe History »   grated into the base. VTAM and TCP/IP were combined together under the  Communications Server for OS/390 name, and CICS/ESA became CICS Trans-  action Server. Db2 started to become used in large distributed  systems, and System/390s seemed to be adopted for big database server  loads. By then, it was the year 2000, and MVS was looking rather old  with its 2 GB addressing limit.  VERSION 2: Alas, OS/390 Version 2 (bearing an MVS/SP number of 6.x.x,  VERSION 2  VERSION 2  VERSION 2  though it is no longer displayed on the IPL screen) included a virtual  tape facility through DFSMSrmm and a parallel batch queuing system  called Smart Batch. The last release, V2R10, was released on Sep-  tember 23, 2000; this version was ran on many systems that were  licensed for it but not newer MVS releases (like z/OS) for about a  decade. V2R10 was the direct precursor to the successor to OS/390 --  systems that released after this version found themselves even often  bearing a DASD with a VOLSER of "OS39M1" -- this is the case for the  P/390 development pre-packaged ADCD systems.   Z/OS  Z/OS  Z/OS  Z/OS  The road to z/OS was certainly rather interesting. While the 64-bit  System Z hardware was essentially an expanded System/390 CMOS 9672  machine (see the earlier information on the System/390 hardware), MVS  would need some overhauls to become 64-bit. IBM used (as usual) an  enhanced version of VM/CMS to develop the "64-bit OS/390" -- when it  was done, it was decided to rename the line to the System Z (and  OS/390 to z/OS).  The new 64-bit z/OS had some rather strange limitations. For instance,  it was not possible to place executable code above the 2 GB bar (note:  THE LINE is 16 MB, THE BAR is 2 GB); it had to remain within the first  2 GB of storage. However, data could be placed above the bar; it is  not uncommon to see programs like CICS and Db2 eat up storage past the  bar for its own data. z/OS V2R3 alleviated this, but hardly any super-  visor calls work when the code for the running program resides above  the bar. The z/OS compilers could produce 64-bit-laden operations (as  in, the programs used 64-bit registers), but they themselves did not  ever generate code that resided above the bar.  z/OS V1R5 was the last version that could IPL in 31-bit mode -- future  versions of the OS required a 64-bit system as many core system  modules only shipped in AMODE 64 varieties.  As z/OS proceeded through its life, it gained a variety of third-party  software. IBM produced ports of Node.JS, Golang, and other such pro-  grams; other ISVs (independent software vendors) provided other  similar ports of languages like Python (though Rocket Software's  offerings were notably lambasted by their users).    OS/360, MVS, and z/OS 83 »   Menu Utilities Compilers Options Status Help  ------------------------------------------------------------------------------  ISPF Primary Option Menu  0 Settings Terminal and user parameters User ID . : WEC  1 View Display source data or listings Time. . . : 14:59  2 Edit Create or change source data Terminal. : 3278  3 Utilities Perform utility functions Screen. . : 1  4 Foreground Interactive language processing Language. : ENGLISH  5 Batch Submit job for language processing Appl ID . : ISR  6 Command Enter TSO or Workstation commands TSO logon : ISPFPROC  7 Dialog Test Perform dialog testing TSO prefix: WEC  9 IBM Products IBM program development products System ID : EVIEMVS  10 SCLM SW Configuration Library Manager MVS acct. : ACCT#  11 Workplace ISPF Object/Action Workplace Release . : ISPF 5.5  M More Additional IBM Products   Enter X to Terminate using log/list defaults   Option ===>  F1=Help F2=Split F3=Exit F7=Backward F8=Forward F9=Swap  F10=Actions F12=Cancel  Figure 12. ISPF on z/OS V1R5            84 Mainframe History »   Display Filter View Print Options Help  -------------------------------------------------------------------------------  SDSF OUTPUT DISPLAY WEC TSU00050 DSID 2 LINE 0 COLUMNS 02- 81  COMMAND INPUT ===> SCROLL ===> PAGE  ********************************* TOP OF DATA **********************************  J E S 2 J O B L O G -- S Y S T E M S Y S 1 -- N O D E  18.32.43 TSU00050 ---- MONDAY, 06 OCT 2025 ----  18.32.43 TSU00050 $HASP373 WEC STARTED  18.32.43 TSU00050 IEF125I WEC - LOGGED ON - TIME=18.32.43  19.26.48 TSU00050 IEF450I WEC ISPFPROC DBSPROC - ABEND=S622 U0000 REASON=000000  507 TIME=19.26.48  19.26.48 TSU00050 $HASP395 WEC ENDED  ------ JES2 JOB STATISTICS ------  06 OCT 2025 JOB EXECUTION DATE  2 CARDS READ  699 SYSOUT PRINT RECORDS  0 SYSOUT PUNCH RECORDS  39 SYSOUT SPOOL KBYTES  54.09 MINUTES EXECUTION TIME  1 //WEC JOB 'ACCT#',REGION=8192K  2 //DBSPROC EXEC DBSPROC  F1=HELP F2=SPLIT F3=END F4=RETURN F5=IFIND F6=BOOK  F7=UP F8=DOWN F9=SWAP F10=LEFT F11=RIGHT F12=RETRIEVE  Figure 13. SDSF displaying job output on z/OS V1R5            OS/360, MVS, and z/OS 85 »   RMF V1R5 Processor Delays Line 1 of 13  Command ===> Scroll ===> CSR  Samples: 100 System: SYS1 Date: 10/07/25 Time: 10.03.20 Range: 100 Sec  Service DLY USG Appl EAppl ----------- Holding Job(s) -----------  Jobname CX Class % % % % % Name % Name % Name  TCPIP SO SYSSTC 1 2 0.2 0.2 1 JES2MON  RMF S SYSSTC 1 0 0.1 0.1 1 JES2MON  HTTPD1 SO STCLOM 1 0 0.1 0.1 1 JES2MON  VMCF S SYSSTC 1 0 0.0 0.0 1 JES2MON  VTAM S SYSSTC 1 0 0.0 0.0 1 JES2MON  IBMUSER T TSO01 0 2 0.6 0.6  JES2MON S SYSTEM 0 1 0.1 0.1  JES2 S SYSSTC 0 1 0.1 0.1  WEC TO TSO01 0 1 0.9 0.9  *MASTER* S SYSTEM 0 0 1.0 1.0  WLM S SYSTEM 0 0 0.2 0.2  CATALOG S SYSTEM 0 0 0.1 0.1  RMFGAT S SYSSTC 0 0 0.2 0.2   Figure 14. z/OS V1R5 Resource Management Facility performance  reporting            86 Mainframe History »   TSS/360 AND TSS/370  TSS/360 AND TSS/370  TSS/360 AND TSS/370  TSS/360 AND TSS/370  ___________________    ORIGINS  ORIGINS  ORIGINS  ORIGINS  In the mid-1960s, there was a huge emphasis on a new computing tech-  nology called "timesharing" -- that is, "have a share of time" on the  computer (we would nowadays call this a "multiuser computer").  Timesharing systems were also multitasking and interactive systems,  and would frequently be driven via teleprocessing (that is, terminals  located physically far from the computer). Granted, OS/360 had TSO,  but it was a far cry from a true timesharing system (TSO was commonly  viewed as nothing more than a hand-keyed batch job at a terminal, with  TSO commands that were functionally equivalent to JCL batch job com-  mands); as such, IBM sought a true timesharing system for the S/360 to  try to get a leg up on the competition.   TSS/360  TSS/360  TSS/360  TSS/360  In 1967, IBM made TSS/360 available (it was not an officially sup-  ported product, and never would be; read on to see why this was the  case) for customers that had the System/360 Model 67 (the 67 had the  "DAT box", which was the 360's memory management unit that would later  find its way into every System/370 on the S/370 AF line). Despite  having a very rough launch, TSS pioneered implementations of a lot of  how critical concepts in computing:  ź Very early implementation of symmetric multiprocessing, using a  single "resident supervisor" (kernel) that communicated with other  CPUs in the system through interrupts)  ź Position-independent code, something that alleviated the link-  editing issues of the earlier DOS/360's memory management scheme  ź Combined virtual-memory/virtual-machine architecture for every  running user (this would later influence CP-67, see the section on  VM for more information on this)  ź Dynamic linker (very new for 1967, TSS is perhaps the first real  implementation of it)  ź Table-weighted thread priority scheduler  In that list, there is an entry for a dynamic linker; for those that  are unaware, dynamic linking allows a program to load and get linked  with the language runtime when it loads (as opposed to doing all of  that ahead of time by the linker, which means every routine in the  language runtime library that is used in the program must be linked  into the program itself, increasing program size drastically). To save  memory/storage on the memory-constrained 360 systems, TSS would employ   TSS/360 and TSS/370 87 »   a dynamic linker that would share a language's runtime library between  several programs running it at once (or keep it in memory for another  program to use later).  TSS'S DYNAMIC LINKER: The TSS dynamic linker is relatively similar to  TSS'S DYNAMIC LINKER  TSS'S DYNAMIC LINKER  TSS'S DYNAMIC LINKER  how early UNIX systems implemented dynamic linking (like UNIX System V  release 4.1). For those that are familiar with writing 360 assembler  programs, you will be familiar with the concept of the CSECT. Every  program will have a CSECT (control section), some DSECTs (dummy  sections, somewhat like structs in C), and a TSS-specific area called  a PSECT (a prototype section). There is also a program-writable reg-  ister save area (remember, the 360 didn't have a stack). When a  program is linked dynamically, the TSS loader will load the shared  library (or, well, map it) into the program's address space (read-  only, of course). In order to access the functions, the program will  load the address of the functions in the runtime library from that  PSECT. When a dynamically-linked routine is called, the program will  save its registers into the save area, load the address of the symbol  from the PSECT table, and jump to the routine. As such, every program  will have a unique PSECT table (as the functions will be placed into  the virtual memory address space of the program at any location, so  long as it does not overlap something that's stored with the program).  COMMANDS: Being a time-sharing system, TSS had commands! These con-  COMMANDS _________  COMMANDS  COMMANDS  sisted of 7 different categories (as seen in the manual):  ź "Task Management" (LOGON, LOGOFF, etc)  ź "Data Management" (DELETE, CATALOG, DDEF, etc)  ź "Program Management" (LOAD, DISPLAY, DUMP, etc)  ź "Command Creation" (BUILTIN, PROCDEF, etc)  ź "Message Handling" (LIMEN, BREVITY, etc)  ź "User Profile" (PROFILE, DEFAULT, SYNONYM, etc)  ź "Program Product Language Interface"  Ś ASM (Assembler F)  Ś HASM (Assembler H)  Ś COBOL (COBOL/360)  Ś PLI (PL/I 360)  Ś PLIOPT (PL/I Optimizer)  Ś FTNH (FORTRAN H)    88 Mainframe History »   TSS/370  TSS/370  TSS/370  TSS/370  To little fanfare, IBM did provide a 370-native version of TSS as a  PRPQ (a "Program Request Price Quotation") intended only as a  migration path (hopefully off TSS and onto MVS/TSO) for 370 customers.  As mentioned in the section on the 370's initial launch, the original  370s did not have a DAT box; when TSS/370 launched in 1971, users  would have to adapt their earlier 360/67 DAT box; because TSS/370  relied on intrinsics only found on the DAT box, it is rather difficult  to run TSS/370 under VM.  A fun fact that seems to be poorly recorded: the announcement for  TSS/370 occurred at the same time as the official decommital (and  therefore soft-cancellation) of TSS/360; this was done under heavy  pressure of various execs that, though they tried to kill the CP/CMS  project, realized that it was a far superior timesharing system to  TSS. An interesting note about TSS is that it actually uses 31-bit  ____________  addressing, and the sneak-peak teaser for the 370/XA machines (wherein  __________  all 370 machines would gain a 31-bit address space) was released at  the same time as this TSS debacle. For the curious, this May 1971  meeting was held at the Westchester Country Club.              TSS/360 and TSS/370 89 »   ?  ls  ENTER PHY ADDRESS OF CARD RDR OR DEFAULT = EOB.  ENTER ADDR OF PAGING DISK  251  PRINT MAPS? 0 1 2 3...NONE IVM RESSUP BOTH  3  ENTER CODE FOR FUNCTIONS NOT TO BE LOADED.ALL FUNCTIONS WANTED = EOB  99  QUICK START REQUESTED? IF Y ENTER ADDR OF PACK FOR QUICK START DATA SET--N = EOB  DELTA DATA SETS? Y OR N  n  CURRENT CLOCK VALUE IS 12/05/25 10.27.59 IS CLOCK CORRECT?  no  ENTER DATE AND TIME AS  MM/DD/YY HH.MM.SS  10/07/85 10.28.30  DEPRESS TOD SWITCH  CURRENT CLOCK VALUE IS 10/07/85 10.28.31 IS CLOCK CORRECT?  yes  $ run  BULKIO REQUIRED?  y  Y ACCEPTED  10:28:45 SYSOPER0 NO DRUM PATH AVAILABLE  10:28:45 TSS00001 BATCH MONITOR HAS BEEN INITIALIZED  10:28:45 R=0001 SYSOPER0 VALIDATE THE SYSTEM HARDWARE CONFIGURATION. REPLY OK WHEN DONE.  reply 1,ok  TSS370  STARTUP COMPLETE,USERS MAY LOGON  10:28:56 SYSOPER0 *CZAWS* ASNBD'S DONE: A20E-01.  10:28:56 SYSOPER0 *CZAWU* BSN=0316 STARTED ON 020E, SYSOPER0.SYSLOG.G0030V00  10:28:56 ->->-> SYSOPER0 CZCMD 004I ON PTR 020E MOUNT FORM PAPER  MOUNT CARRIAGE TAPE SAME  MOUNT CHAIN/TRAIN 'PN'  SET DENSITY 6  THEN NR/R  10:29:15 ->->-> SYSOPER0 CZCMD 002I  VERIFY THAT THE FOLLOWING 20-CHARACTER MESSAGE APPEARS ALSO ON PTR 020E,  - *** BUFFER LOADED ABOVE. *  sard  SYSTEM ACTIVITY AND RESOURCES AT 10/07/85 10:29:37  REPLYS: 0  USERS - CONV: 1 BACK: 1 REM : 0 RJEA: 2  QUEUES- EXEC: 0 PRNT: 1 PNCH: 0 TAPE: 0 RJE : 0  AVAIL - PTRS: 1 RDRS: 2 PUNS: 2 TAPS: 48 DISK: 150  PAGES - PUB : 18108 TEM : 0 AUXDR : 0 AUXDK : 22499  TSS370  Figure 15. TSS/370 Release 3 starting up   90 Mainframe History »   ?  logon tss  TSS/370 RELEASE 3.01  ENTER PASSWORD  XXXXXXXXEEEEEEEEMMMMMMMMibm  TASKID=0012 LOGON AT 10:35 ON 10/07/85  _logoff  LOGOFF AT 10:59 ON 10/07/85  TASK ABENDING. ANY BUFFERED OUTPUT CONTINUES.  CZAFJ - NON-ZERO RC FROM RELEAS (CZCAD1)  CZAFJ - NON-ZERO RC FROM RELEAS (CZCAD1)  TASK DELETED  ?  Figure 16. TSS/370 Release 3 user logon and logoff               TSS/360 and TSS/370 91 »   RAX AND MUSIC  RAX AND MUSIC  RAX AND MUSIC  RAX AND MUSIC  _____________    In the void of TSS, several systems emerged. While VM (to be discussed  later) would become the dominant timesharing system on the 370 line,  several one-off systems were written. One of those was called RAX, and  it was introduced in 1966.   RAX  RAX  RAX  RAX  IBM worked with Lockheed to produce Remote Access Computing, a system  _______________________  that evolved out of RACS (an earlier system, seemingly rather poorly  documented). The original target of RAX (which had the program number  360A-CX-17X) was a System/360 Model 30 or better, bearing at least 64  K of storage. There were two choices for terminals: the 1050 remote  typewriter terminal, or the 2260 display terminals (of interest as  they were the precursor to the legendary 3270 series, and famously  used acoustic delay lines to store the screen image).  RAX had online compilers for BASIC (which was derived from CALL/360  BASIC), COBOL, FORTRAN IV, and Assembler F. Several sites adopted this  because of the online nature of the system:  ź US Department of Agriculture  ź McGill University  ź Boston University  ź University of St. Andrews  ź University of Rhode Island  ź Lockheed  ź Bell Aircraft Corp  RAX, being relatively commonplace in an academic environment, led to  the development of further systems, including...   MUSIC  MUSIC  MUSIC  MUSIC  When McGill installed RAX, they found it rather impressive and began  to modify it. In 1972, McGill's stack of RAX modifications was added  to IBM's catalog of user-written programs as the "McGill University  System for Interactive Computing" (i.e. MUSIC). It provided a primi-  tive interactive timesharing environment that rapidly gained more and  more features; when version 4.0 came out (in 1978), true filesystem  permissions and other such features were introduced. When the IBM 4300   92 Mainframe History »   series System/370 machines became available, MUSIC 5.0 gained support  for those but also the "new" FBA DASDs.  In 1985, IBM saw MUSIC and chose to adopt it as a System Product, and  so MUSIC/SP was born. Version 1.0 added real virtual storage support  (which was surprisingly lacking that whole time); version 2.2 in 1990  streamlined performance; version 2.3 introduced the current MUSIC/SP  filesystem and the TCP/IP support the system became so well-known for  all in 1991. Rather than having a "real" TCP/IP stack, MUSIC/SP (when  ran under VM) would be able to talk to the VM/CMS TCP/IP stack via  IUCV and use that for networking services (this will be described in  more detail later).  THE FILESYSTEM: Gaining ideas from other systems like TOPS, the  THE FILESYSTEM  THE FILESYSTEM  THE FILESYSTEM  MUSIC/SP filesystem is assembled as a single file index that can span  multiple DASD volumes. Files could be located in the file index in a  single operation by performing a hash function operation on the  username. The filesystem was modelled after that found on MS-DOS, with  directories and flat files throughout. The DOS "drive letter" was the  user ID, and directories functioned and were used just like on DOS.  There were two kinds of files: public and private. To save on disk  space in an era where disk space was a rare and expensive thing, all  files were compressible.  THE EMULATOR In an era of mainframe OS compatibility, MUSIC joined the  THE EMULATOR  THE EMULATOR  THE EMULATOR  fray with its own MVS emulator. Many of the compilers and language  interpreters were ran on the MVS emulator, to great success! The emu-  lator implemented a small subset of MVS supervisor calls (i.e. system  services), and it was remarked that MVS programs could run on MUSIC  faster than they could run on real MVS (though I have yet to see a  citation for this). Full-screen TSO services were also emulated,  allowing for program packages like GDDM and DisplayWrite/370 to work  flawlessly on MUSIC. Since MVS DASD storage is accessed through  dataset mechanisms and not (generally) a DOS-style filesystem, the MVS  emulator contains a facility to map a MUSIC user file to a MVS dataset  name.  THE NETWORKING: Even though it showed up a few years late to the  THE NETWORKING  THE NETWORKING  THE NETWORKING  TCP/IP stack race, MUSIC/SP's TCP/IP facilities (by way of the VM  TCP/IP stack) were rather famous. Generally, sites would run two  copies of the VM TCP/IP stack, with one being dedicated to MUSIC and  the other being present for CMS applications/users (the two would  interlink using an IUCV socket; see the section on VM for more infor-  mation on both this and the VM TCP/IP stack). MUSIC also had an HTTP  server and browser, a Telnet client, and a visual FTP client to accom-  pany the FTP server program.  THE EMAILS MUSIC was somewhat known for its email handling system, and  THE EMAILS  THE EMAILS  THE EMAILS  several mailers had been written over the years. The most commonly-  used one was called RDMAILER, and it would work with both SMTP sites  and RSCS/NJE (i.e. BITNET) sites through a modified RSCS running on  the VM host (as nearly all MUSIC systems were ran under VM if they  wanted networking). Pieces of WISCNET (itself a TCP/IP stack for VM,  which would later go on to become the famous "FAL" TCP/IP stack IBM   RAX and MUSIC 93 »   provides) were ported to MUSIC, and MUSIC functioned as a "client" to  a WISCNET stack running elsewhere on VM. Though MUSIC never gained  support for protocols like NFS or the Sun ONC/RPC system (even though  MUSIC was often found in UNIX environments at universities), what was  available was of notoriously good quality.  THE JOB LANGUAGE: For the most part, MUSIC's JCL was intended to be a  THE JOB LANGUAGE  THE JOB LANGUAGE  THE JOB LANGUAGE  simplified imitation of the JCL found on MVS systems. Programs could  be ran with ease, as essentially every key program would be found in  the LPA (just like on MVS). For example, the C compiler could be ran  like this:  /SYS REGION=16384  /FILE SYSLIN NAME(CTEST.TEXT) NEW(REPLACE)  /FILE SYSLIB PDS(*.H,$IBC:UPK.*.HDR)  /LOAD C370  /OPT MARGINS(1,80) NOSEQUENCE  /JOB NOGO  #include  int main() {  puts("MUSIC C compiler demo\n");  return 0;  }  Within reason, MUSIC was seen as a rather "easy" system, but its  demise in the early 2000s as it was starting to be seen as obsolete  meant it was over. Also, note that PDS argument to /FILE -- this  assembles a PDS based on those MUSIC disk files.           94 Mainframe History »   MM MM UU UU SSSSSSS IIIIII CCCCCCC / SSSSSSS PPPPPPP  MMM MMM UU UU SSSSSSSSS IIIIII CCCCCCCCC / SSSSSSSSS PPPPPPPP  MMMM MMMM UU UU SSS II CC / SSS PP PP  MM MMMM MM UU UU SSSSSSS II CC / SSSSSSS PPPPPPPP  MM MM MM UU UU SSS II CC / SSS PPPPPPP  MM MM UUUUUUUUU SSSSSSSSS IIIIII CCCCCCCCC / SSSSSSSSS PP  MM MM UUUUUUU SSSSSSS IIIIII CCCCCCC / SSSSSSS PP    Multi-User System for Interactive Computing / System Product    Press the ENTER key to view next page when you see this message ---> More...  Figure 17. MUSIC/SP ESA 5.3 logon screen   --------------------Full Screen Interface for MUSIC------------------ Page 1/1  Command ===>  * NO NEW MAIL *  Place the cursor on an item and press ENTER or RETURN.  MUSIC tools:  Mail Electronic mail facility  Programming Compilers, processors, tutorials, etc  CI Course Information  Internet Internet access, news reader, gopher, etc  More Other general MUSIC tools  MUSIC files:  FLIB * Full Library Screen for current directory  FLIB Filespec=> WE00:* < pattern  FUTIL Other file related utilities  MUSIC environment:  Help General help and online documentation  New Password Change your password  Defaults FSI customization  Profile Profile utility and options  Off Terminate your session and disconnect from MUSIC  Suggest Make a suggestion or send a comment to support staff  F1=Help F2=Suggest F3=End F9=Find F12=Retrieve  Figure 18. MUSIC's Full Screen Interface    RAX and MUSIC 95 »   MTS  MTS  MTS  MTS  ___    The Michigan Terminal System was an interesting OS, born of the 1960s,  ________________________  for the System/360 Model 67. Remember earlier the discussion about the  370-67's DAT box -- this is what was necessary to make MTS work. As  you can probably guess, MTS was a timesharing system, developed by and  for the University of Michigan Computing Center.  MTS itself is comprised of several components, and it evolved to  remain current with other System/360-family OSes over time. Parts  include:  ź The University of Michigan Multiprogramming Supervisor (UMMPS):  UMMPS  UMMPS  UMMPS  _____  the core of the OS; this provided a multitasking, multiprocessor,  timesharing, virtual memory supervisor program that allowed for  the execution of several simultaneous reentrant programs started  by users  ź Command Language Subsystems and Job Programs: these handled user  interaction  ź Various user-written applications and IBM-written applications,  like compilers and runtime libraries  Now, let us examine the history of this fine system.   HISTORY  HISTORY  HISTORY  HISTORY  Before MTS, the University of Michigan had and IBM 7090 mainframe, and  wished to run it for academic purposes. Their solution to this problem  was to take the General Motors Executive System (itself hailing from  the IBM 701) and modify it into the University of Michigan Executive  system (called UMES). This was a batch system, and, by the time it was  adopted, it was obvious that timesharing was the future. While UMES  was certainly tailored to run reasonably well under a load of many  small/short jobs that students and staff would submit, it was clear  that this was a dying form of computing in the academic space.  Remember, before the invention of virtual memory, computer execution  capacities were primarily limited by the availability of real memory,  and that exhausted quickly in that era too.  IBM was famously hesitant to support a timesharing workload on the  System/360 -- this is why many often remark that the 360 itself was a  step back in computing technology, as many other computers (like those  _________  mentioned in the introductory chapter of this book) already had  virtual memory support (and timesharing was readily adopted on these).  Several people who were at the University of Michigan published a  rather influential paper on the topic of timesharing in January 1966   96 Mainframe History »   in the Journal of the ACM entitled Program and Addressing Structure in  ___________________________________  a Time-Sharing Environment.  __________________________  While CTSS (devised at MIT) did not employ a virtual memory system in  the modern sense we understand today, this paper described a  timesharing system that worked with a modern virtual memory system  (and described what would become the System/360-67's DAT box). IBM  was, as discussed elsewhere in this book (particularly in the section  on VM/CMS), hesitant to provide such a thing.  After hefty discussion with the University of Michigan folks that  wrote the paper, IBM finally agreed to design a special variant of the  System/360 Model 65 explicitly intended to support this timesharing  system -- this was called the System/360 Model 65M (the M for  Michigan). Since IBM initially did not provide a timesharing operating  system with the System/360 announcement, this new development at the  University of Michigan started to make headwinds around the computing  industry rather quickly.  Several other System/360 customers caught wind of this: MIT's Lincoln  Laboratory (the one that would later become the wellspring for  CP/CMS), Princeton University (a very influential IBM shop), Carnegie  Mellon University, and even General Motors (who always had a fasci-  nation with timesharing even in the early days of computing)! The  System/360 was already a hit with these customers, but they saw it as  a batch-oriented system -- when they heard that someone was planning  to do timesharing on one, there was a bit of a demand for these  special System/360 Model 65M machines!  IBM would repackage and slightly modify the S/360-65M into the  System/360 Model 67, and it became an officially-supported IBM  product. As soon as that was made available, over 100 customers tried  to acquire one; after the S/360's launch, IBM learned the error of  their ways and relented; as a response, TSS/360 was born (and quickly  died to its customer-written competitors, you can read more about that  in the TSS chapter). This new OS was supposed to be delivered approxi-  mately at the same time as the S/360-67, but people got impatient.  IBM was somewhat slow to deliver that S/360-65M to the University. As  a response, the University Computing Center people cleverly designed a  simple timesharing system for a System/360 Model 50 that they had  (this was funded by an ARPA program called CONCOMP, the Conversational  Usage of Computers). The original codebase for this system consisted  of two halves: a "half-page of code written out on a kitchen table"  and a modified program from MIT called the Lincoln Laboratory Multi-  programming Supervisor -- if that name sounds familiar, that's because  the UMMPS core of MTS is actually derived from MIT's work! The MTS  job program would run under the control of LMMPS, and was quite inter-  esting. Starting in 1965, the University was well on the way to an OS  of their own.  The CONCOMP research project was intended to "anticipate the avail-  ability" of the S/360-67, and the machine was delivered on time with  no delays. However, what the staff at the Computing Center had written   MTS 97 »   was, really, a stopgap measure to "warm up" their minds to write a  full timesharing system. They fully expected to discard this system as  soon as TSS/360 became available, and, they did. The paper on CONCOMP  notes that, while the engineers were happy that the S/360-67 arrived  on time, they were quite unhappy that TSS/360 did not. Furthermore,  TSS was plagued by performance and reliability issues -- something  that came to define TSS as a massive failure in IBM's history. The  paper also lambasted TSS for not even supporting all of the terminals  that IBM had on the market at the time; note that IBM did have graph-  ical terminals, and various soon-to-be-timesharing sites had these! To  make matters worse, IBM did not sell a single terminal controller that  could uniformily control all these varieties of terminals.  Fed up with TSS lacking support and quality for just about anything  that the Computing Center required, the Computing Center staff agreed  that the only way forward was to keep working on that stopgap OS they  threw away a few months ago. Transitioning from the S/360-50 to the  S/360-67 took a while, so the staff continued development on the  S/360-50. The team had several goals they wished to achieve:  ź Design a conversational system that could "support any type of  effective man-made interaction"  ź Develop a hardware attachment that could support a myriad of  remote terminals  ź Be able to support 50 to 60 interactive users with 4 to 6 batch  jobs, concurrently  ź Be able to support high-level language compilers, graphics appli-  cations, and more  ź Participate on a network, those being the early ARPANET and MERIT  network  TSS was doing so bad by then that IBM literally cancelled the project,  but would later reinstate it; all the while, MTS continued to grow.  LLMPS was morphed into UMMPS, and development took off. Being an aca-  demic system first and foremost, a consortium was founded to maintain  and develop MTS. The members were:  ź University of Michigan (1967-1999)  ź University of British Columbia (1968-1998)  ź University of Newcastle upon Tyne (1969-1992)  ź University of Alberta (1971-1994)  ź Wayne State University (1971-1998)  ź Rensselaer Polytechnic Institute (1976-1992)  ź Simon Fraser University (1977-1992)   98 Mainframe History »   ź University of Durham (1982-1992)  The sites that did run MTS often ran multiple MTS systems, and for  good reason: MTS systems could network together!   COMPUTERS RUNNING MTS  COMPUTERS RUNNING MTS  COMPUTERS RUNNING MTS  COMPUTERS RUNNING MTS  The first machine that ran MTS was the single-processor S/360-67 that  the Computing Center acquired in early 1967 (which bore the serial  number 2, the first to leave IBM). This initial implementation did not  yet support virtual memory, but it could sustain 5 online users and 1  background batch job. In November 1967, the engineers added virtual  memory support; this upped the number of users to 50 and the number of  batch jobs to 5. It should be noted that IBM actually sold a duplex  (i.e. two processor) variant of the S/360-67; the Computing Center  acquired one of these in August 1968, and it replaced the earlier  simplex (i.e. one processor) system -- by then, the system could  sustain 70 users and 8 batch jobs.  The University of Michigan continued to upgrade, but not always to IBM  hardware! They received the second Amdahl 470V/6 ever made in 1975,  and MTS worked great on it. Having great success with this IBM compet-  itor, they continued purchasing their computers -- they received the  first shipped Amdahl 5860 in 1982. They chose to return to IBM to  receive the first factory-shipped 3090-400 in 1986, to great success.  MTS's open consortium nature meant that MTS sites often contributed  new code back to the original project (much in the same way that the  development of CP/CMS went). Rensselaer modified MTS to support 32-way  multiprocessor S/370-XA processors in 1984 (a big boom over the ori-  ginal 4 supported by 370-non-XA MTS), but the 6-processor system at  RPI was likely the largest system MTS was ever ran on. In 1991, the  Computing Center upgraded again to an IBM ES/9000-720, and could  support over 600 users! It is believed that the last MTS site to exist  was actually Rensselaer's MTS system, which was retired in June 1999.  FRONT-END PROCESSORS: One of the requirements associated with the  FRONT-END PROCESSORS  FRONT-END PROCESSORS  FRONT-END PROCESSORS  CONCOMP project was terminal and networking support. Initially, the  Computing Center used terminal controllers like the IBM 2703 or  Memorex 1270 to support asynchronous serial lines (many of which were  attached to modems), but this was a terrible solution. For one, the  2703 (unlike the later 3705) was a fixed-function and non-programmable  system; feeling the limitations of this, the CC engineers came up with  a clever solution: attach a PDP-8 (later a PDP-11) to a S/370 via a  parallel channel, and use that to handle networking and terminal  control!  The U of M was the first to attempt this (after all, they had the  idea), and they called it the Data Concentrator. This was a modified  PDP-8 born out of the requirements of the CONCOMP project, and was  actually the first non-IBM device that ever attached to an IBM  mainframe channel interface. This evolved into a two-tier system and  was converted over to a PDP-11 architecture; the second tier was   MTS 99 »   called the Remote Data Concentrator, and it networked with the Data  Concentrator at the Computing Center over synchronous serial (as was  common in the day).  The University of British Columbia produced an upgrade to this system;  they developed two PDP-11 boxes: the Host Interface Machine (HIM) and  Network Interface Machine (NIM) were true network controllers for MTS.  NETWORKING AND MERIT: Though the DC/RDC and HIM/HIM systems were  NETWORKING AND MERIT  NETWORKING AND MERIT  NETWORKING AND MERIT  great, they were initially not the best solution for networking: the  University of Michigan and Wayne State University to design hardware  to support the MERIT Network. This came in the form of a dedicated  PDP-11 that they called a Communication Controller; these attached to  a parallel channel on one end, and talked to remote CCs on the other  end. These first permitted host-to-host remote logon connections, and  later supported terminal-to-host connections (with the terminals being  driven directly by the CC); since batch jobs were still frequently  used, batch-to-host support was also added to facilitate remote job  submission.  The original host-to-host system was explicitly developed to allow  remote access to and from non-MTS computing systems. This first came  in the form of the CDC SCOPE/HUSTLER system that Michigan State Uni-  versity had. Eventually, the MERIT people renamed the CC to be a  Primary Communications Controller, and then developed a Secondary Com-  munications Controller. The PCPs were the main network nodes, and  could communicate with each other via either Ethernet or synchronous  serial. SCPs were in turn connected to PCPs via synchronous serial  links. The PCP and SCP would be able to attach to GTE Telenet, Tymnet,  ADP Autonet, and more -- this was then updated to add support for  TCP/IP connections (and the 370 channel devices emulated on the PDP-11  to do this are now emulated by the Hercules emulator).  The MERIT Network PCP/SCP project was huge: at the peak of MERIT's  development, there were more than 300 PCPs and SCPs with a combined  total of about 10,000 terminal ports.  JOB SPOOLING: Though it was not originally written for MTS (and was  JOB SPOOLING  JOB SPOOLING  JOB SPOOLING  instead written for OS/360), MTS included HASP (which would later  become JES2 on the MVS line). There were other spoolers available, but  nearly every site ran HASP; it was quite well-integrated with the  system, and could handle both card-submitted batch jobs and jobs sub-  mitted by online timesharing users (as one would expect). Of course,  spooled output devices (printers and punches) were under the control  of HASP.      100 Mainframe History »   VERSIONS  VERSIONS  VERSIONS  VERSIONS  Over the years, the following versions of MTS existed:  D1.0  D1.0  D1.0  D1.0  ____  There are two extant versions of MTS 1.0, only one of which has been  archived. The first was produced for the University of British  Columbia's Computer Center in October 1968, and the second was  produced for Newcastle University (i.e. NUMAC). The second one was  produced by copying the tapes from the first version and appending any  changes/upgrades onto the end of the tape volume. This version was  intended to run only on a System/360 Model 67.  The base MTS system was not very feature-rich on this version, but the  system did have some interesting components, including (but certainly  not limited to):  ź Lisp  ź Assembler G  ź GPSS-360  ź PL/360  ź FORTRAN G (FORTRAN II compiler)  ź Support for the 2250 display terminal  ź Support for the 2703 communications processor  ź SNOBOL4  ź WATFOR (Waterloo FORTRAN)  ź Sort/Merge  ź An accounting system  The NUMAC updates included a PDP-8 assembler, updates to all the com-  pilers and assemblers, fixes for the 2780 line driver, and a PL/I  compiler/library.  D1.0 Mod 1  D1.0 Mod 1  D1.0 Mod 1  D1.0 Mod 1  __________  This was a tape that had some revisions to the D1.0 distribution;  these were intended to stack on top of NUMAC's version of D1.0. This  version was believed to be released sometime in 1969, but there are no  certain dates. Update included:  ź WATFOR (Version 0 Level 7, August 6 1968)  ź Updated device tables   MTS 101 »   ź Updated system editor  D2.0-D2.3  D2.0-D2.3  D2.0-D2.3  D2.0-D2.3  _________  This version was released in February 1970, and was a mostly incre-  mental update from D1.0 Mod 1. The D2.0 tapes that do exist mainly  contained documentation updates, but some interesting things were  added:  ź XCOM  ź A new dump/restore program  ź Revised RJE support  ź PL (a dialect of PL/1 for teaching)  ź GPSS/360  ź WATFOR (same version as D1.0 Mod 1)  ź Assembler simulator  D2.1 (from June 1970) was an incremental update that updated device  tables; D2.2 (from 1971) included a format driver to automate system  installation; D2.3 (1972) included a version of BASIC.  D3.0  D3.0  D3.0  D3.0  ____  Released in August 1973, this version included a variety of new tools.  Being a new major release, this was distributed on quite a number of  tapes (coming on 6 1600 BPI tapes, or 9 800 BPI tapes). The last tape  in the tape set (whichever density the site asked for) is a self-  restoring dump/restore tape that would install the MTS starter system.  The D2.2 driver file system provided its driver file on the last tape.  The format of that last tape is as follows:  ź The TSS DASDI program, used to initialize a DASD for the system to  be restored onto  ź The TSS Dump/Restore program, used to read the starter system  further down on the tape  ź The TABLES deck generator program, which would be IPLed to produce  a TABLES card deck used for installation later  ź The OS-derived ISSDASDI program, used to format a DASD pack that  would hold HASP spooling space  ź Data for the TABLES deck generator program  ź The dump/restore data  ź The TABLES program's source   102 Mainframe History »   ź An assembly listing of TABLES  By this release, HASP was fully configured to accept remote work-  stations (using RJE; see the sections earlier in this book on it, or  flip to the index at the back to find it quickly). The version of HASP  found on this MTS release explicilty supported the 360/20, other 360s,  an 1130, an 1800, or a System/3 as an RJE workstation.  The following programs were included on this distribution:  ź Assembler G  ź PL/I  ź PLC  ź GASP  ź BASIC  ź UMLOAD  ź APL  ź PL/I  ź Accounting system  ź Billing system  ź Virtual 67  ź DITTO  ź ASMTIDY  ź TSS assembler  ź Polygraphics  ź SNOBOL4  D3.1-D3.2  D3.1-D3.2  D3.1-D3.2  D3.1-D3.2  _________  Rather than a rather manual update method, these revisions (released  in March 1974 and March 1975, respectively) were much easier to  install (thanks to the power of the installation driver system).  These versions contained differential updates to the various programs  and compilers found on base D3.0, and carried the OS to its next major  release.  D4.0  D4.0  D4.0  D4.0  ____   MTS 103 »   In August 1977, the next release hit. The tapes for this distribution  came either in 1600 BPI or 6250 BPI density variants, and was split  across at least 3 backup tapes with 1 dump/restore tape containing the  starter system (which installed like the D3.0 release). This release  was twice as big as the last release, and was in a slightly different  format. The tapes were in the format of a dump produced by the MTS *FS  program, and the installer could use a program called RAMROD to create  ______  the new nucleus. The release was a massive program update of the pre-  vious release, and did not really add anything new.  D4.1-D4.3  D4.1-D4.3  D4.1-D4.3  D4.1-D4.3  _________  Coming on one 6250 BPI reel in May 1978, D4.1 introduced a better way  of communicating what changes were being made. A clever SNOBOL4  program generated a "change form" that described what changed. This  release was an overhaul of system internals, and not so much programs.  March 1979 bought D4.2, which came with a dump/restore tape (which  meant the system could be installed straight away for a new install  site); alas, that dump/restore tape has seemingly been lost. This  version contained updates to most of the programs and compilers  present on the system; since it came on 3 tapes and was a pretty large  update, the University of Michigan saw it fit to just include a  restorable system.  D4.2A came in July 1979, and was rebadged as Redistribution 16 (RD16)  -- this may seem confusing as first, but U of M asked for all of the  MTS sites to send in tapes containing their system to be redistributed  to every other MTS site. This was done in a rather haphazard method,  and there was no attempt made to produce anything that was consistent,  simple, or easy to install. Alas, a driver file was made, so installa-  tion was at least possible.  D4.2B (RD17) came in October 1979, and was a very small supplement  intended to overlay on D4.2A.  D4.3 released in May 1980, and added support for more hardware.  Growing on the 1977 original 4.0 release, this release included  updates to:  ź PDP-8 cross assembler  ź Linear algebra software  ź Waterloo FORTRAN updates  ź Extended XPL  ź Support for the Memorex 1270 (a 3274 clone)  ź ALGOL compiler updates  ź Additional terminals (TI Model 733, DECwriter)   104 Mainframe History »   D5.0  D5.0  D5.0  D5.0  ____  Around this time, MTS releases started to slow down. Most sites had  started to explore other interactive timesharing systems (including  early UNIX, VMS, and even VM/CMS), but D5.0 was released in August  1981. A full 360 MB distribution on 4 tape reels at 6250 BPI density,  the following new components were included:  ź PL360  ź Extended XPL  ź GASP (mentioned before, this is the General Motors Associative  Programming Language)  ź WIREWRAP  ź REDUCE 2  ź PDP-9 remote graphics terminal driver  ź Statistical computation programs  ź Linear algebra programs  ź Fourier transform routines  ź PDP-8 assembler and linker  ź SPIRES  ź MTS APL  ź Z80 and 8080 assembler  D5.1  D5.1  D5.1  D5.1  ____  This release was mostly the same as D5.0, and was released in August  1983. Note the programs that were added on D5.0 -- MTS was a key plat-  form for the burgeoning microcomputer race (and this would end up  being its undoing!). This distribution consisted of a one-tape update  to the base release, and could be installed with the driver program.  D6.0.  D6.0.  D6.0.  D6.0.  _____  At long last, the last version of MTS was upon the world. Many years  after the D5.1 release, U of M released D6.0 in April 1988. By then,  TCP/IP support had been added using the aforementioned two host inter-  face processor methods, but development had mostly stalled after  D5.1's released -- the shutdown dates of various MTS sites were mostly  in the early 90s (as mentioned earlier). This final version was the  "gold master" of MTS, and consisted of 9 tapes.   MTS 105 »   Alas, this version was the first to support 370/XA machines, and TONS  of new features were added. These include:  ź 370/XA support, but not ESA/370 support. This would be rectified  in the future, though.  ź Named Address Spaces, something that functioned like Discontinuous  Saved Segments on VM. These were used to allow programs to share  libraries and data, and loaded at IPL time into the virtual  address space.  ź Expanded Storage support, which MTS used as a store-through-mode  disk cache. Writes were written immediately to DASD, but reads  were backed by the cache.  ź Vector Facility support. This was used by having an program that  used the opcodes and registers for the VF; MTS would save and  restore the contents of the VF across task-switching timeslices.  ź More message support. This was an enhancement to the *MESSAGES  facility to allow more than 2.1 million messages.  ź More programs: $MAKE, $FTP, $DUPLICATE, $FSM (Full Screen  Message), $HELP, and an improved editor  ź Resource Manager. This was a program, written by UBC, that could  be used to drive an NJE network (it apparently also had printing  support, but this was not used in a distributed-system MTS  cluster).  ź Network support. This added support to the base distribution for  UBCNet and Merit network interface hardware.  ź HIM support. This is the aforementioned TCP/IP host processor for  MTS, developed at UBC. This supported UDP, TCP, and TLNT (telnet)  devices on the logical channel the HIM exposed to the host, and  could run an FTP server.  ź Updated DASDI program. This added support for 3380s and CMS mini-  disks.  ź Rewritten FBA support. This new FBA driver code could use the  integrated 9370 FBA DASD disks (the 9332 and 9335, as well as  clones, were supported).  ź Network Server support. A Server is a different type of connection  to MTS (the other two being Terminal or Batch) wherein a remote  system would connect to a system to perform a login; once that was  validated, files and jobs could be transferred.  Needless to say, MTS got very advanced on this release; this release  was certainly the largest of all of the predecessors by a significant  amount!   106 Mainframe History »   D6.0A  D6.0A  D6.0A  D6.0A  _____  Years after, in January 2012, three hobbyists (who are Mike Alexander,  Jeff Odgen, and Gavin Eadie) dusted off the MTS 6.0 distribution and  tried to get it running on Hercules. To their surprise, it mostly  worked... but the installation process was painful and not very  turnkey. As such, the MTS D6.0A distribution was made available in the  form of a single 3380 disk (alongside a Hercules configuration file).  Author's note: I tried to get this to run on a real S/390 mainframe,  ______________________________________________________________________  but I couldn't get it to IPL; apparently, it will not work with either  ______________________________________________________________________  a Bustech or IBM Shark 3380 controller!  _______________________________________   University of Michigan Computing Center - Device: DS02 Task: 40 ge 1/1  %    MM MM TTTTTTTTTTTT SSSSSSSSSS  MMM MMM TTTTTTTTTTTT SSSSSSSSSSSS  MMMM MMMM TT SS SS  MM MM MM MM TT SS  MM MMMM MM TT SSS  MM MM MM TT SSSSSSSSS  MM MM TT SSSSSSSSS  MM MM TT SSS  MM MM TT SS  MM MM TT SS SS  MM MM TT SSSSSSSSSSSS  MM MM TT SSSSSSSSSS    Figure 19. MTS 6.0A user terminal screen       MTS 107 »   CP/CMS, VM/CMS, AND Z/VM  CP/CMS, VM/CMS, AND Z/VM  CP/CMS, VM/CMS, AND Z/VM  CP/CMS, VM/CMS, AND Z/VM  ________________________    In the wake of TSS's commercial failure as a software platform, a true  successor would emerge. This came in the form of VM/CMS, but its  history was long and convoluted. Despite having a rough start, it  found itself cemented in a rather interesting position in the world of  computing: many saw it as a parallel universe alternative to UNIX, and  several people remarked that CMS had better UNIX features than UNIX  itself (a big example of that being the infamous "CMS Pipelines"  program).   ORIGINS: BEFORE VM  ORIGINS: BEFORE VM  ORIGINS: BEFORE VM  ORIGINS: BEFORE VM  The first timesharing system ever demonstrated in a meaningful  capacity came out of MIT in 1961. The so-called "Compatible  Timesharing System" (or CTSS for short) found itself as both an aca-  demic miracle and a commercial marvel. While CTSS was originally  somewhat primitive, it would later go on to influence every other  timesharing system (including VM, but also Multics). Keep in mind,  computing was radically different during CTSS's heydey; computing then  was nearly entirely based on batch processing, and interactive work  was almost completely ignored. While CTSS was used in a meaningful  capacity from 1964 to 1971, a second-generation system was quickly  wanted. MIT (and others) saw the massive success that academic and  scientific users had with timesharing, and wanted to spearhead the  second "greatest hit in computing" of the time: Project MAC.  While IBM was trying to get commercial computing companies to improve  their timesharing offerings, it quickly became apparent that they  would have to do most of the work themselves. Project MAC would later  go on to produce Multics on the GE (and later Honeywell) mainframe  line, but the "spirit of the problem" still remained. One of the  hardest problems was finding a computer that could actually sustain  many logged-on users. While the Project MAC team settled on the afore-  mentioned platform, many industry vendors provided their own bids for  hardware. One of those was the repeat-supplier IBM (who had already  given MIT plenty of computing hardware and support before), and they  offered a System/360. However, the MIT guys hated the 360! The machine  didn't include the address translation hardware they so desperately  needed for timesharing (the infamous "DAT box" that would form the  virtual storage features of the System/370 machines later), and this  was a major blow to the project.  Nonetheless, they would eventually have their wish and get a DAT box  (which they called a "Blaauw Box" after Gerrit Blaauw, its designer);  sadly, even after all of this, IBM would end up losing the Project MAC  contract (they also lost important connections with Bell Labs, who  famously became a GE customer thanks to their partnership with MIT and  the development of Multics). The MIT guys, armed with their suc-   108 Mainframe History »   cessful fulfilled proposal of what was the first System/360 Model 67  (with that direly-needed Blaauw Box) -- this machine would be destined  to run TSS/360... but the keen reader will know the blazing failure  that this OS was.  Part of the reason IBM never included timesharing as one of the ori-  ginal goals of the System/360 project was simply because of the target  market: the System/360 was intended to be a business batch processing  machine, and not an interactive timesharing scientific/academic  machine. In that era, there were some hot criticisms of virtual  memory systems that most people have forgotten: the first machine to  have virtual memory paging was the Ferranti Atlas (which was one of  the first supercomputers, and was located in the UK). Many people  remarked that the virtual memory features on the Atlas didn't work (or  worked very poorly), and nobody understood why; the engineers would  later attribute it to the machine having a rather low amount of real  memory, and the memory-consuming loads were making the system thrash  heavily.  While IBM was originally devastated by the loss of the Project MAC  contract, the Lincoln Laboratory eventually did get their aforemen-  tioned System/360 Model 67. IBM also got their ducks in the row and  followed GE's lead: they began to take timesharing seriously, rather  than trying to "get rid of" the scientific/academic demands of the  universities with customized PRPQ-type operating systems (like RAX).  However, the shipment of the Model 67 got pushed back further and  further, and the engineers began to get impatient. A System/360 Model  40 was available to the engineers, and they quickly got to work  designing some hardware upgrades and microcode updates that would  implement a reduced-function implementation of the DAT Box on the  360/40. In 1965, they got to work.  CP-40: In the middle of 1965, the engineers could finally start their  CP-40  CP-40  CP-40  work on CP-40's virtual machine control program. They had already been  dismayed with TSS/360 and essentially began to ignore it; they noted  that TSS/360 was comprised primarily of lofty goals and forgotten  hopes. Meanwhile, CP-40 and CMS were coming along nicely!  First, CMS was written. The so-called Cambridge Monitor System would  function as a single-user single-tasking interactive OS that would run  on the 360/40 without the need for the virtual memory features. When  they were ready to try to run several CMS sessions, they hardcoded a  variety of virtual machines into the CP-40 nucleus and regenerated it.  Growing on the lessons learned from the M44/44X project (the first  machine that actually implemented virtual machines, on a modified IBM  7044), the so-called pseudomachines (of which there were 14) with 256K  of storage quickly sprang to life. The virtual CMS disks were pre-  sented to the user's VM by divvying up the computer's real disk  storage into a variety of extents (called "minidisks"), unit-record  devices (printers, punches, and card readers) were emulated using a  spooling technique (still used today by z/VM), and the typewriter ter-  minals provided CP console functions that would allow the user to  start or stop their VM, manage devices within it.   CP/CMS, VM/CMS, and z/VM 109 »   CMS: On the heels of CP-40's development (technically before), CMS  CMS  CMS  CMS  was finding itself maturing. The engineers that implemented the ori-  ginal CMS used a variety of System/360s around the Boston/Cambridge  area (including the famous modified 360-40 while it was still on the  factory floor in Poughkeepsie). The OS of choice that was used for  CMS's development was none other than BPS/360 (if you could even call  that an "operating system" in the traditional sense). To load the  early versions, they used BPS's three-card loader; this was placed  before the CMS nucleus in the deck and the machine was IPLed from the  reader.  Eventually, CMS was becoming mature enough that the programmers could  use CMS to develop CMS (the OS was then said to be "self-hosting");  when CP-40 matured enough to be able to run multiple copies of CMS,  the programmers quickly jumped at the opportunity to do so and  timesharing CP/CMS was born.  CP-67: Eventually, in September 1966, the engineers working on CP-40  CP-67  CP-67  CP-67  at the Cambridge Scientific Center realized that they would be able to  migrate CP-40 to the System/360 Model 67 they had finally gotten.  However, the migration was not so smooth: the engineers ended up  rewriting a substantial amount of CP to be not only more flexible, but  also more performant. Exciting new features included:  ź Dynamically-allocated control blocks  ź Variable number of virtual machines  ź Larger guest virtual storage  ź Most CP modules made reentrant  As CP-67 development rolled on, the engineers at the MIT Lincoln Lab  started to become extremely frustrated with the lack of quality of  TSS/360; they looked at CP-67, saw that it was not only passingly  similar to the old CTSS, but was actually stable and usable (a tall  order for TSS in its era, which often did not stay alive for long and  required constant re-IPLs). Seeing this, the Lincoln Lab computing  crew started asking IBM for a tape of this "miracle" software product.  Keep in mind, IBM was heavily invested in TSS, and a major customer  _______  like the MIT Lincoln Lab ditching TSS would be a major blow to IBM.  Indeed, it was, and the Lincoln Lab put CP-67 into production in April  1967. Both Lincoln and Cambridge worked hand-in-hand on CP-67 by then,  and other customers started to join the CP-67 fray. One of the most  influential ones was Union Carbide: they had been considering running  TSS, but its massive lack of quality led them to seek a suitable  alternative. TSO on OS/360 had not yet matured in any releasable  capacity, so they chose to run CP-67. Because CP-67 was still very  much so an academic software project, they sent some of their computer  staff to Cambridge to work on CP-67; they were directly shaping the  future of the software they were running, something IBM was strangely  scared of engaging in with TSS.   110 Mainframe History »   TSS was not completely dead in the water, however. Melinda Varian  remarked at SHARE 30 (in February 1968) that there were at least 18  sites with System/360 Model 67s trying to run TSS, but none of them  were satisfied with the results. During SHARE 30, IBM famously  announced that they would be de-committing from TSS (this was essen-  tially the final nail in the coffin for TSS, which had nearly no sites  running it as CP-67 was gaining massive popularity over it).  CP/CMS: In May 1968, CP-67 had matured enough that IBM was ready to  CP/CMS  CP/CMS  CP/CMS  start providing it to installations in a meaningful capacity. IBM  released it in the so-called Type III Library (i.e. a collection of  user-written source code libraries) the next month in June. Within 2  months, two timesharing companies were founded to sell CP/CMS  timesharing (those being Computer Software Systems -- later renamed to  National CSS -- and Interactive Data Corporation, eventually renamed  to ICE Data Services) -- these companies poached a variety of key  CP/CMS engineers from Cambridge, Lincoln, and the existing CP/CMS  cites, but these companies' efforts provided a major publicity boost  to CP/CMS, virtual machines, and the cumbersome engineering project  that was the System/360 Model 67.  By April 1969, there were at least 15 360/67 sites that were running  CP/CMS. In June of the following year, Version 2 was done; Version 3.1  (released later in November 1971) could run up to 60 CMS users,  stably, with minimum downtime. By the first quarter of 1972, there  were at least 44 sites running CP/CMS; Version 3.2 was released around  that time as a maintenance release... by then, a quarter of those 44  CP/CMS sites were within IBM. At this point, TSS was essentially dead.  In May 1970, on the heels of the System/370 announcement, the CP/CMS  programmers and architects sought to upgrade CP/CMS to run on the new  System/370 processors (though with caveats; see the section in the  System/370 hardware history at the start of this book on the contro-  versy surrounding the availability of the DAT box on the launch models  of the 370). To achieve this, the CP/CMS programmers actually emulated  a S/370 on a S/360-67; this emulation technique had already been  employed during the S/360-40 to S/360-67 transition, and it would be  pivotal for future generations of the IBM System/370 descendants.  This emulation technique proved to be a major boom for what would  become CP/370's popularity; the OS/VS programmers had no real S/370s  to try their OS on, and being able to emulate the machine they were  targeting meant they no longer had to "fly blind" with development --  this was further helped by a lack of prototype working S/370s during  the OS/VS development cycle. IBM had been trying desperately to get  rid of CP/CMS, but they had completely failed at this point: the  CP-370 developers actually won an IBM award for their efforts| Eventu-  ally, with the S/370 Advanced Function announcement, CP/CMS was offi-  cially discontinued.    CP/CMS, VM/CMS, and z/VM 111 »   VM/370  VM/370  VM/370  VM/370  After CP/CMS's discontinuation, IBM unveiled the S/370 AF systems that  came with stock virtual memory management hardware -- because of this,  IBM announced four new OSes:  ź OS/VS1  ź OS/VS2  ź DOS/VS  ź VM/370  The new VM/370 was a reimplementation of CP/CMS's control program,  which certainly benefitted from the "second time run-through" design  improvement principle. 110 people within IBM were now officially  working on VM/370. It goes without saying that the development of  VM/370 was certainly rather cumbersome. For one, there was the afore-  mentioned massive shortage of prototype System/370s; the result of  this was that CP-370 had to be developed under CP-67 emulating a 370.  This was necessary because the virtual memory relocation hardware on  the 370 was different than the 360: the 370 allowed for two different  page sizes (2K and 4K), plus two segment sizes (64K and 1M) -- the 360  only supported 4K pages with 1M segments.  CP-67 was modified to emulate the 64K segments and to trap/emulate the  370-specific instructions. This modified CP-67 was actually ran as a  guest of the production CP-67 first-level system at Cambridge; in  order to evaluate the functionality of CP-67's emulation of a 370,  CP-370 was ran under that modified CP-67 second-level system. Next,  the 370 CMS could be ran under that third-level CP-370 as fourth-level  virtual machines; CP-370 could also be ran fourth-level with the 370  CMSes running at the fifth level to ensure CP-370 could run itself  under itself.  In January 1971, a prototype System/370-145 (one of the few that had a  DAT box, which was distinctly different in design from the earlier  360/37 one) was made available to the programmers at Endicott. They  travelled up there to test it, and the CP-370 prototype worked on the  first try! The Cambridge people finally got a non-prototype 370-145  with a DAT box in the fall of 1971 amidst security precautions: there  was quite a bit of concern in the center that the people who worked in  the adjacent buildings would notice that the 370 being delivered to  Cambridge had a DAT box, and this would go against what IBM had told  its customers. In February 1972, the first fully-working VM/370 CP  nucleus was IPLed; this resulted in a very high development velocity  moving forward into July 1972, wherein an internal-use-only distrib-  ution of VM/370 was finished on the 5th of the month.  This was on the head of System/370 AF announcement (which would come  on the 2nd of August, 1972); all of the new 370s would have DAT hard-  ware and such, plus the aforementioned operating systems earlier in  this section were announced. Note that VM/370 was up and running in   112 Mainframe History »   the IBM Field Support Centers the day the 370 AF announcement hit  (unlike OS/VS2, which was still far off from being finished).  In order to have a "sane" reference platform, a 370-145 with 512K of  storage was the target for VM/370 Release 1. Note that when Release 1  was available, the largest machine that you could buy was a 370-168  with 8M of storage; the VM/370 marketing team assumed that only about  1 customer would be running VM/370 on a 370-168, but the first one  sold and delivered was destined to only run VM/370 timesharing. A  decade after this announcement, about 10% of the high-end machines  built in Poughkeepsie would have VM installed; 15 years later, VM  would outpace MVS in terms of number of licenses sold.  The VM developers at IBM were notorious for producing an unbelievable  amount of code per each programmer; each programmer produced well over  a thousand lines of assembler code for VM per month. The best part is  the VM programmers were actually having fun! There is an interesting  anecdote documented in VM and the VM Community wherein one of the  _________________________  systems assurance testers was tested with a challenge consisting of a  bunch of junk code: these things would do things like wish the devel-  opers happy birthday if the system had been IPLed on their birthday,  but other things (like something that printed "BONG BONG BONG BONG" on  every terminal at midnight) were left in surprsingly long. The man  who did that testing, Dick Newson, remarks that his team wanted to  modify the VM DIAL command (enterable on the login screen/prompt) to  say "Aren't you glad you use DIAL?" but this fell through due to non-  existent legal threats they were scared of (DIAL is a brand of soap  sold in America).  VM/370 UPDATE PROCESS: By the time Release 1 had solidified, most of  VM/370 UPDATE PROCESS  VM/370 UPDATE PROCESS  VM/370 UPDATE PROCESS  the development on VM was happening within IBM (which included the  Cambridge Scientific Center). Starting in January 1973, the develop-  ment crew was moved to Burlington (adjacent to Boston). Once they were  there, they began to provide service tapes for VM Release 1. These  so-called Program Level Change (or PLC) tapes contained more and more  features that would stack on top of the base. Release 1 PLC 09 added  the CMSBATCH service machine mechanism (which still lives on in z/VM),  the ability to spool a console to a file for further review or  printing, support for the aforementioned 370-168, support for the 2305  paging drum memory unit, a rewritten scheduler that would replace the  basic scheduler (this was called the "biased scheduler"), among other  things.  VM/370 RELEASE 2 AND GROWTH: When Release 2 came out, VM was already  VM/370 RELEASE 2 AND GROWTH  VM/370 RELEASE 2 AND GROWTH  VM/370 RELEASE 2 AND GROWTH  growing somewhat rapidly (in April 1974). The old typewriter terminals  were starting to be replaced by a relatively new (and now famous)  peripheral: the 3270 series terminals. There is an anecdote wherein  Dick Newson walked around MIT and observed the users of early CRT mon-  itors; he noticed that the scrolling was too extreme and came up with  the screen hold feature.    CP/CMS, VM/CMS, and z/VM 113 »   VM/370 ONLINE   VV VV MM MM  VV VV MMM MMM  VV VV MMMM MMMM  VV VV MM MM MM MM  3333333333 777777777777MMMM 00000000  333333333333 77777777777 MM 0000000000  33 VV33 77VV 77 00MM 00  V33 VV 77M 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  33 77 00 00  33 33 77 00 00  333333333333 77 0000000000  3333333333 77 00000000   RUNNING  Figure 20. VM/370 Release 4 login screen  PLC 05 (on Release 2) gained support for the new 3705 communications  processor, which necessitated the creation of commands to load and IPL  the communications processor (as it was a computer of its own). The  3705 generally replaced the earlier 2703, and provided all manner of  telecommunications line capability. To grow on this new support, PLC  11 January 1975) added a now famous subsystem to VM: RSCS (see the  notes on this below). In March 1975 (with PLC 13), OS/VS1-CP paging  handshaking was added as well as the CP monitor system (which was nec-  essary for future programs like VM/RTM). PLC 23 (February 1976) added  IPCS (indispensable for debugging), and VM/370 Release 3 was released  shortly after.  Release 3 added both support for 3350 DASD and also VMCF (which  allowed VMs to intercommunicate, and would later live on as IUCV, aka  APPC/VM).  CPREMOTE, RSCS, AND VNET: Around the time Release 3 was gaining an  CPREMOTE, RSCS, AND VNET  CPREMOTE, RSCS, AND VNET  CPREMOTE, RSCS, AND VNET  install base, various IBMers sought a native inter-VM network system  that could allow for file sharing between systems. This had already  somewhat been written starting in 1969 by two Cambridge people in a  package known as CPREMOTE -- this was essentially the first example of  what we would now call a service virtual machine (which lives on  today, just check out any z/VM system). This program provided a commu-  nications method in which two CP-67 machines shared a common spool  interface. Since it was distributed alongside CP-67, many places  within IBM adopted it quickly, but its shortcomings were obvious.   114 Mainframe History »   Alas, a fork of it was produced (called CP2780) that controlled termi-  nals for RJE (Remote Job Entry, a common feature found on mainframes  at the time; a 2780 was an RJE workstation).  CPREMOTE was certainly rather popular, but it ended up falling into a  situation where it needed to be replaced, badly. This manifested in  1971, wherein the CPREMOTE authors decided it was time to start over,  and try to combine the features of CPREMOTE and CP2780. The resultant  program from this effort was called RSCS, or the Remote Spooling and  Communication Service. The original RSCS was released, as mentioned,  in 1975; it was, however, mostly incomplete. This bothered the  authors, who had literally left in dummy function calls to functions  that would facilitate remote communication over a protocol that would  eventually become known as NJE (Network Job Entry). To alleviate  this, a modified RSCS was produced (which was a PRPQ) called VNET. Now  that it was available, VM/370 sites quickly repurposed some spare BSC  lines on their 2703s and 3705s to form a network: this happened within  IBM naturally, but was initially hampered.  Initially, VNET used asynchronous modems. This meant that an operator  in the computer room had to physically dial a phone number on a tele-  phone, place the phone receiver into the modem acoustic coupler, then  start VNET processing on both sides. Since VNET was mostly used within  IBM, someone had a clever idea: IBM had tons of leased lines between  sites, and some of them were unused. The VNET users, realizing this,  quickly found unused phone lines that ran from one site (or building)  to another, attach it to a synchronous modem, and start the network  links.  The first multi-site network was, as documented in VM and the VM Com-  ___________________  munity, was called Sun (or the Subsystem Unified Network, no relation  ______  to the Stanford University Network of UNIX fame). Apparently, this  was two disjoint networks that were bridged together by a phone cable  ran across a parking lot at a California IBM site. The protocol spoken  over the line used a modified RSCS (which itself would find its code  merged into mainline RSCS, made available as the NJI line driver). An  engineer reverse-engineered HASP/JES2's NJI line driver protocol (as  it allowed for critical things like routing between/through multiple  nodes), which at that point was completely undocumented. When the two  sides negotiated the link, the engineer (Tim Hartmann) ran a banner-  printing program on a machine located in Poughkeepsie and had the  output print on a printer attached to a machine in San Jose... which  was quickly noticed by the author of the HASP/JES2 NJI line driver  code (Ken Field). Upon noticing this, Field requested several more  copies and taped them on the walls all over the building. The  message? Machines of the world unite! Rise to the SUN!  Machines of the world unite! Rise to the SUN!  Machines of the world unite! Rise to the SUN!  Machines of the world unite! Rise to the SUN!  _____________________________________________  By Feburary 1976, there were 50 systems connected to the burgeoning  VNET network (as it had come to be known by that point). By March  1979, there were at least 239 systems spanning 11 different countries.  Because VNET grew so quickly, essentially every VMer at IBM was net-  worked in some form or fashion. Due to this, someone named Peter Capek  hada a bright idea: Make a VM Newsletter, for VM, on VM, sent through  _____________  VM!   CP/CMS, VM/CMS, and z/VM 115 »   The newsletter was replaced in 1983 by a more purpose-built confer-  encing system called IBMVM, managed by a program called TOOLSRUN.  IBMVM was a "conference" comprised of many files (which for some  reason are called "fora", hence TOOLS-adjacent support programs with  FORA in their name). The conference disk was mirrored on systems  attached to the network, and this information-sharing scheme produced  massive gains in productivity for the IBMers (as TOOLS conferences  were starting to be used by everyone, not just VMers).  Of course, IBM's dependence on a network meant it would not be long  before someone would try to exploit said dependence for either  humorous or malicious means. This came in the form of an interesting  script that hit in December 1987. The so-called CHRISTMA EXEC made its  way to VNET through BITNET, which itself was attached to the European  college NJE network named EARN.   VM/370 BSEPP AND SEPP  VM/370 BSEPP AND SEPP  VM/370 BSEPP AND SEPP  VM/370 BSEPP AND SEPP  The road to a VM/370 program product was long and arduous. In 1976,  IBM forked VM/370 Release 3 PLC 06 to emulate 370/XA VMs on a standard  System/370. All the while, IBM was hot on the trail of VM/370 Release  5 in 1977 (which introduced VMAP as an optional program product).  There were also made available two system-extension versions of  Release 5:  ź VM/370 BSEPP (Basic System Extensions Program Product), which  introduced support for FBA DASDs, EDGAR (sometimes called the  Display Editing System, the first real fullscreen 3270 editor),  and CP improvements.  ź VM/370 SEPP (System Extensions Program Product) introduced the  Wheeler Scheduler (offering greatly improved CP dispatch perform-  ance), a variety of user modifications people had written (many of  which were sourced from the Waterloo VM Library), the ability to  send VM accounting records to disk, swap table migration, page  migration, and shadow table maintenance enhancements (the last  three are copied verbatim from VM and the VM Community).  _______________________  Much of the "controversy" around VM/370 in the 1970s (the so-called  Doubtful Decade (as it was named in a SHARE presentation given in  1978) revolved around a series of questionable release choices that  resulted in rather bad user satisfaction during that era. Initially,  users were actually rather disappointed when the original VM/370  release was made available; Release 3 was another low point, but users  began to like VM/370 quite a bit (i.e. were impressed with its sta-  bility) around Release 5.  VM/370 RELEASE 6 AND BSEPP/SEPP RELEASE 2: In 1979, VM/370 Release 6  VM/370 RELEASE 6 AND BSEPP/SEPP RELEASE 2  VM/370 RELEASE 6 AND BSEPP/SEPP RELEASE 2  VM/370 RELEASE 6 AND BSEPP/SEPP RELEASE 2  hit the market. Users quickly installed it, and it was often noted to  be one of the most stable versions of pre-VM/SP VM made. Release 2 of  BSEPP and SEPP introduced a feature that became critical for net-  working later: logical device support; this release also revamped the  CMS filesystem with its new version: EDF (Extended Disk Filesystem).   116 Mainframe History »   The new version of RSCS, the Program Product version, was also  released on the same day; it totally overhauled line driver support  and combined all of the modifications made to RSCS over the years.  Though it was lacking, a CMS HELP facility was also introduced; the  version found in this release was nothing more than a text file dis-  player and was a far cry from the panel-and-menu-based HELP system  seen on z/VM today.  BSEPP and SEPP were essentially stopgap releases, and were essentially  warm-up measures for a truly program-product version of VM. This  would come shortly after in the form of:   VM/SP  VM/SP  VM/SP  VM/SP  In late 1980, VM/System Product Release 1 hit the market. Gone were  the days of having the complete source code to VM; most of VM/SP was  now copyright IBM and written in a language people did not have com-  pilers for (PL/S and later PL/X). Alas, new features were added:  ź EXEC 2, a new CMS scripting language  ź IUCV, the evolution of VMCF  ź A MIH (missing interrupt handler) for device reliability  ź Multiprocessor system support  ź Subsystem communications  ź XEDIT, Xavier's vastly improved EDITor  Though about 100,000 new lines of code were thrown into the system,  there had been a massive lack in testing. Many people realized that  VM/SP Release 1 was thrown out the door and onto the market well  before it should have been, and it was obvious! CMS would randomly  corrupt minidisks, CP would randomly crash, and IBM revamped the PUT  process that made it even harder and slower to get fixes shipped to  customers. VM/SP took all of the improvements of VM/(B)SEPP and  slammed them into a bunch of new code; it was a mad sight to behold.  It seems that IBM did not learn from their mistakes with OS/360, and,  as mentioned, they threw tons of programmers at VM/SP R1's development  crew. Since none of these people were VM experts (or even passingly  good from historical reports), the fixes that this crew did produce  were of terrible quality.  One of the more questionable things added to VM/SP R1 was something  called VTAM -- the VTAM Communications Network Application. This was a  primitive implementation of SNA for VM, and it functioned by having a  dedicated MVS guest system that communicated with CP via VMCF. Need-  less to say, this was not a good solution; many VM systems programmers  quickly became fed up with VCNA as it required them to learn MVS,  learn SMP/E, figure out MVS JCL, and other such things foreign to   CP/CMS, VM/CMS, and z/VM 117 »   them. It would be a while before true SNA networking came to VM with  ACF/VTAM V3 on VM/SP Release 4.  PROFS: In late 1981, IBM made available a program that would end up  PROFS  PROFS  PROFS  becoming absolutely famous: the Professional Office System, or PROFS.  IBM had worked with a company named AMOCO (a federal credit union in  the United States) to develop PROFS, and IBM released it as a PRPQ.  This PRPQ version was a massive success, and IBM released it later as  a fully supported program product in the mid-80s. IBM became somewhat  dependent on PROFS, and, by 1987, there were a million PROFS users  outside IBM. There is an expression that the PROFS main menu welcome  screen was the most displayed thing on any CRT terminal from any man-  ufacturer, but this may just be a clever marketing ploy by someone  steeped in cleverness.   PROFS MAIN MENU A00  Press one of the following PF keys.  PF1 Process calendars Time: 3:21 PM  PF2 Open the mail  PF3 Find documents 2025 SEPTEMBER 2025  PF4 Process notes and messages S M T W T F S  PF5 Prepare documents 1 2 3 4 5  PF6 Process documents from other sources 6 7 8 9 10 11 12  PF7 Process the mail log 13 14 15 16 17 18 19  PF8 Check the outgoing mail 20 21 22 23 24 25 26  27 28 29 30  PF10 Add an automatic reminder Day of Year: 254  PF11 View main menu number 2  5664-309 (C) Copyright IBM Corp. 1983, 1987 PF9 Help PF12 End  ------------------------------------------------------------------------------    ===>  Mail Waiting  Figure 21. PROFS V2 R1.1 Main Menu  VM/SP R2 AND R3: As the 1980s rolled on, IBM decided it was high  VM/SP R2 AND R3  VM/SP R2 AND R3  VM/SP R2 AND R3  time to ditch their heavily patched SP 1 system (the one in  Poughkeepsie is the VM system in question), and the results were stag-  gering. Now that the VMers had a taste of their own medicine, they had  a change of heart; SP Release 2 contained a massive number of fixes  that SP 1 should have had, ranging to a whole host of bugfixes to a  command retrieve key. One of the interesting things added were the  Productivity Tools, the now-familiar FILELIST, RDRLIST, and other such  menu-driven things.   118 Mainframe History »   VM/SP Release 3 added REXX, and it quickly filled a void of the poor  EXEC 1 and EXEC 2 programming environment. Mike Colishaw had been  working dutifully on REXX, trying hard to get it into VM; some people  saw it as BASIC, but many saw it as the true potential-bringer it was.  Not before too long, the entire system was using REXX everywhere.  ___________  VM/PASSTHROUGH: Going by several names, one of which was PVM, was an  VM/PASSTHROUGH  VM/PASSTHROUGH  VM/PASSTHROUGH  interesting cross-system networking product for VM made in the late  70s. PVM emerged as a program named V6 in 1974. Its slated purpose was  __  to allow remote access to the IBM RETAIN (a database system that  service personell can use to catalog problems and note solutions)  system in Raleigh. By 1980, VM/Passthrough was launched as a real  product.  Strangely enough, when PVM was made available as a product, it had  already had years of battle-testing; it was so well-used within IBM  that it was launched with essentially no bugs. PVM started to evolve  quickly, and began to gain many new link types. By its final release  (2.1.1, 1998), it had support for a wide variety of links:  ź CTCA  ź Bisync  ź APPC/VM  ź TCP/IP  ź 3274 emulation  ź IUCV (local system only)          CP/CMS, VM/CMS, and z/VM 119 »   VM/Pass-Through Facility  You can select a node with the cursor and press ENTER  L VMESA N ZVMA N ZVMB N ZVMC N VMHPO N VMSP  N ZVMD N VMESA370 N ZVME N VMESA21 N VMESA12 N VMHPO42  N VMIS N VMESAG N VSEESA N VISIONS N EVIEVM N EVIEVSE  N EVIEVMG    Destination -----------------> Port ------------------------>  Route -----------------------> Language --------------------> AMENG  End Session -----------------> #### Verify ----------------------> OFF  Your Identification ---------> GRAF020 Nickname -------------------->  Session Roll ----------------> ?SELECT Menu Select -----------------> ?MENU  PF8= Scroll CLEAR key = Top Screen PA1= Exit   ****> <****  ****> <****  Figure 22. VM/Passthrough menu  VM/SP HPO: March 27, 1982 introduced a new version of VM: the VM/SP  VM/SP HPO  VM/SP HPO  VM/SP HPO  High Performance Option. The first version was Release 2 (for VM/SP  Release 2). Later versions, namely HPO Release 3.2 and 3.4, were  massive performance booms. One touted feature was an increase in how  much storage could be used; Release 3 added support for the Extended  Real Addressing scheme described in the hardware section, allowing for  64 MB of real storage to be used on the system. Other features  included:  ź Improved storage management and simplified tuning  ź Users can create up to 9900 spool files, rather than having the  entire system limited to 9900 files  ź Scheduler enhancements, mainly with regards to storage over-  commitment  ź Expanded storage can now be used for paging, allowing for rela-  tively fast access to more than 64 MB of real storage  ź Extended hardware support (4381s, 3090s)  ź Sped-up TSAF (will be discussed later)  There were many VM/SP HPO releases, here they are:   120 Mainframe History »   ź R2M5  ź R4M0  ź R4M2  ź R5M0  ź R6M0  VM/XA MA: I shall discuss in more detail later the details of VM/XA  VM/XA MA  VM/XA MA  VM/XA MA  SP (which came later), but the VM/XA Migration Aid was a primitive  31-bit XA-mode version of VM derived from The Tool (as it was known);  it was the program product version of the forked VM/370 CP that could  create XA VMs but modified to run XA VMs on an XA host. Just like the  first run of CP-370, VM/XA MA IPLed first try on a prototype 3081 when  it became available. The Migration Aid was intended as a tool to help  users migrate from OS/VS1 and OS/VS2 to the new MVS/XA, while running  their "old" 370-mode OS/VS images as they moved.  THE OCO ANNOUNCEMENT: February 8, 1983 was a sad day for VMers.  THE OCO ANNOUNCEMENT  THE OCO ANNOUNCEMENT  THE OCO ANNOUNCEMENT  During the runtime of SP 2 and SP 3, IBM announced (as mentioned  earlier) that the complete source would no longer come with the  product. It was now Object Code Only! VM customers fought tooth and  nail against this, even going as far as the time when SHARE published  a white paper; IBM never responded to it. There was a particular good  example of the OCO policy gone wrong with:  VM/PC: If you read the section earlier on the XT/370, you will recall  VM/PC  VM/PC  VM/PC  that the XT/370 was provided with a version of VM called VM/PC. This  was the first real OCO version of VM, and it was a colossal failure.  Many features were implemented incorrectly (or not implemented at  all), and the customers of it were powerless to correct these issues  without the source and associated compilers! As such, VM/PC was dead  as soon as it was released.  VM/SP RELEASE 4: Late in 1985, IBM released SP 4. People adopted it,  VM/SP RELEASE 4  VM/SP RELEASE 4  VM/SP RELEASE 4  but... it was clear IBM had not learnt their lesson. SP 4 had just as  many bugs as earlier versions, but some new features were actually  derided for being bad replacements to earlier features or were of poor  implementation quality. The major feature that was added was CMS HELP  (as mentioned earlier): sure, it was now a menu-driven system, but the  help menu pages were essentially copy-paste versions of the hardcopy  manuals made to be read on CMS.      CP/CMS, VM/CMS, and z/VM 121 »   VM/370 ONLINE--PRESS ENTER OR CLEAR KEY TO BEGIN SESSION   VV VV MM MM  VV VV MMM MMM  VV VV MMMM MMMM  VV VV MM MM MM MM  3333333333 777777777777MMMM 00000000  333333333333 77777777777 MM 0000000000  33 VV33 77VV 77 00MM 00  V33 VV 77M 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  33 77 00 00  33 33 77 00 00  333333333333 77 0000000000  3333333333 77 00000000   RUNNING VMSP4  Figure 23. VM/SP Release 4 logon screen  SP 4 also introduced GCS, the Group Control System. Its slated purpose  was to run a true real port of VTAM on VM, but customers derided it  too for being a closed system with no source. Alas, the new VTAM V3  port to VM was reasonably well-received otherwise. GCS, however,  almost completely stagnated; with no source and little documentation,  only IBM provided programs that ran under it. For reference, GCS pro-  vided a simplified implementation of a MVS scheduler, some supervisor  calls, and console emulation that allowed for porting MVS programs  over to VM; one would think that many customers would move off of MVS  and onto VM because of this (since GCS could, in theory, run applica-  tions either in one VM or in several VMs), but nobody did. When it was  all said and done, there were only a few products that used it: VTAM,  RSCS, NetView, and not much else.  CMS gained a new feature that almost nobody wanted: CMS  Windows(properly called CMS Session Services). It was a cool novelty,  but many people asked what's the point? Release 4 also added multiple  _________________  language support, but it was cumbersome to use, difficult to implement  new languages for, and very awkward. Users that found themselves as  large RSCS routing nodes found their performance degraded, and it  wouldn't get any better with Release 5.  WISCNET AND VM TCP/IP: In the early 80s, people at the University of  WISCNET AND VM TCP/IP  WISCNET AND VM TCP/IP  WISCNET AND VM TCP/IP  Wisconsin had a bright idea: what if we produced a TCP/IP stack for  VM? The result of this was a project called WISCNET, which provided  the aforementioned Internet support for VM. This project was of par-   122 Mainframe History »   ticular interest because IBM worked with the university; in the age of  OCO software coming out of IBM, a product that came with its source  was a breath of fresh air.  By 1984, IBM was selling WISCNET as a PRPQ; this was later adopted by  a team within IBM as a true program product. The result of that effort  was the famous "FAL", so named after its program number (5798-FAL).  While some people saw it as a Pascal monster, others saw it as a solid  product. WISCNET (and later VM TCP/IP) both contained code to build  NJE-to-Internet mail gateways. For sites that had both WISCNET and VM  TCP/IP tapes installed, they would find themselves possessing a  variety of interesting programs:  ź A TN3270 program for UNIX  ź X Windows for VM (later)  ź Both Pascal and C API support, including support for the standard  BSD socket API on CMS  WISCNET's software requirements were rather slim, only requiring VMCF  support for the intercommunication between the TCP/IP stack virtual  machine and server/client VMs. As for the hardware side, things were  much more complicated. In the "modern era" of System/390s, mainframes  possess "open systems adapter" cards (as discussed in more detail in  the earlier hardware sections). These OSAs emulate something called an  IBM LAN Channel Station, essentially a DOS PC fitted with at least two  cards: a bus-and-tag channel card, and at least one Token Ring or  Ethernet card. A program would run on that DOS machine that provided  the service of what became to be known as a "LAN Channel Station." The  8232 LCS became available during the time IBM was selling VM TCP/IP,  so things were much different in the era of WISCNET.  If you wished to attach your WISCNET install to an Ethernet network,  you needed a box called a DACU (device access control unit). This box  contained a shortened DD11-CK UNIBUS backplane that held a bus-and-tag  card and an Interlan Np100 10 megabit Ethernet UNIBUS board. There was  an IBM PC that ran the control software; this device was the direct  inspiration for the later 3172 LCS.  During the time of WISCNET, there were some other competing solutions:  one of which was Spartacus TCP/IP for VM, originally written by people  _______________________  that had written a TCP/IP stack for MVS called KNET. Much like WISCNET  and the DACU, KNET and Spartacus used a similar box to provide an  Ethernet port on the mainframe (theirs was called the K200). Of  course, WISCNET had IBM's backing and ended up winning out; the DACU  was transformed into the 8232 LCS, and the LCS also gained support for  SNA over Ethernet and Token Ring (though it provided a slightly dif-  ferent operating mode to do this). When the P/370, P/390, IS3006, and  MP3000 became available, the system provided device emulators that  emulated both the Ethernet and SNA operating modes of an 8232 LCS. For  more information on the 8232, see the earlier section in this document  that describes it!   CP/CMS, VM/CMS, and z/VM 123 »   SQL/DATA SYSTEM: In an era of uncertain futures of databases, IBM  SQL/DATA SYSTEM  SQL/DATA SYSTEM  SQL/DATA SYSTEM  produced System R -- the first SQL database. While it ran on MVS and  was barely popular, an offshoot of it became a massively popular  product in the 1980s. This product was SQL/DS, and it ran on VM and  VSE; MVS customers got Db2 (which was also SQL). SQL/DS and the VM  Shared File System actually are both derivatives of System R! If  you've used unixODBC or Microsoft SQL Server, you may have noticed a  program named something like ISQL. Believe it or not, this is actu-  ally derived from SQL/DS, which provided commands just like that that  did the same thing (that is, provide Interactive SQL where you can run  SQL statements directly).   isql  ARI0659I Line-edit symbols reset:  LINEND=# LINEDEL=OFF CHARDEL=OFF  ESCAPE=OFF TABCHAR=OFF  ARI0320I The default server name is SQLDBA.  ARI7716I User WEC connected to server SQLDBA.  ARI7399I The ISQL default profile values are in effect.  ARI7079I ISQL initialization complete.  ARI7080A Please enter an ISQL command or an SQL statement.  select * from wec.testtab  ARI7960I The query cost estimate for this SELECT statement is 1.  COL1 COL2 COL3  ------------ ----- ------------  1 HI 2  * End of Result *** 1 Rows Displayed ***Cost Estimate is 1*********************  exit  ARI7601I ISQL ended normally on your request.  ARI0660I Line-edit symbols restored:  LINEND=# LINEDEL=ą CHARDEL=@  ESCAPE=" TABCHAR=]  Ready; T=0.03/0.04 16:43:13   RUNNING EVIEVM  Figure 24. SQL/DS on VM ISQL  Eventually, by the 1990s, SQL/DS was renamed to Db2 for VM and Db2 for  VSE; they have little to no relation to Db2 for MVS or Db2 LUW ("Linux  Unix Windows", which also ran on OS/2).  VM/SP RELEASE 5 AND 6: SP 5 was intended to add more features to SP  VM/SP RELEASE 5 AND 6  VM/SP RELEASE 5 AND 6  VM/SP RELEASE 5 AND 6  4, and several key bugfixes were included. Released in December 1986,  it still contained many new derided features. While later versions of  SP 5 were remarkably stable, the criticism of SP 5 pales in comparison  to SP 6. Hitting the market on October 20, 1987, SP 6 introduced TSAF,  a shared CMS filesystem, and a very unstable version of CMS. The new  CMS SFS was certainly a great idea: you could now have directories...  but if the SFS server VMs crashed, your data was as good as dead (this  has happened to your author's VM systems)! TSAF was a cool feature as   124 Mainframe History »   it allowed for speedy cross-system collections of a singular APPC/VM  domain to be created, but it was not truly useful until the final  releases of VM/ESA a decade later. CMS SP 5 and 6 were also quite  derided: Cornell famously never put CMS SP 5 into production on  account of major bugs; most sites stayed with CMS SP 4. Sadly, some  customers tried to move to VM/XA SP, but it always ended in a dis-  aster; VM/XA SP, while it had been made available, had hardly any fea-  tures (and the ones it did have were either of sub-par quality in  their implementation, or just missing altogether). VM/SP 6 did add  VMSES/E, which made service much easier, but many diehard VM systems  programmers derided it for various reasons.   VIRTUAL MACHINE/SYSTEM PRODUCT   VV VV MM MM //  VV VV MMM MMM //  VV VV MMMM MMMM //  VV VV MM MM MM MM // SSSSSSSS PPPPPPPP  VV VV MM MMM MM // SS SS PP PP  VVV MM M MM // SS PP PP  V MM MM // SSSSSSS PPPPPPPP  // SS PP  // SS SS PP  // SSSSSSSS PP   Fill in your USERID and PASSWORD and press ENTER  (Your password will not appear when you type it)  USERID ===>  PASSWORD ===>  COMMAND ===>  RUNNING VMSP5  Figure 25. VM/SP Release 5 logon screen  VM/IS: Originally intended to be a turnkey package of VM/SP Release 5  VM/IS  VM/IS  VM/IS  or 6 and installed on an IBM 9370, VM/Integrated System was the  "sysprogless VM." This was intended to actually be a massive success,  but, in true IBM fashion in that era, it certainly wasn't. Instead,  VM/IS was a bit of a flop; alas, it included the following products:  ź SQL/DS  ź DisplayWrite/370  ź PROFS  ź QMF   CP/CMS, VM/CMS, and z/VM 125 »   ź VS BASIC  ź GDDM  ź RSCS  ź ISPF  ź FORTRAN  ź TCP/IP  ź VTAM  Alas, VM/IS was certainly a wonderful system. See the following  screencaps for some examples of what the system could do:   VIRTUAL MACHINE/SYSTEM PRODUCT   *************************************************  *** ****** ** * ******* * *** *****  *** ****** * * * ***** *** *** ** ****  **** **** ** ** ** **** **** **** *******  ***** ** *** ***** *** ***** ****** *****  ****** **** ***** ** ****** *** ** ****  ******* ***** ***** * ****** *** *****  *************************************************  Virtual Machine / Integrated System   Fill in your USERID and PASSWORD and press ENTER  (Your password will not appear when you type it)  USERID ===>  PASSWORD ===>  COMMAND ===>  RUNNING VMIS  Figure 26. VM/IS logon screen (system built on VM/SP Release 5)      126 Mainframe History »   IBM BASIC/VM VERSION 1 RELEASE 2.0 1925/09/21 16:14  (c) Copyright IBM Corporation 1982, 1985  * load eliza  255 LINE(S) LOADED. 'ELIZA' IS THE WORKSPACE NAME.  * run  HI! I'M ELIZA. WHAT'S YOUR PROBLEM?  ? nothing much  ARE YOU SAYING NO JUST TO BE NEGATIVE?  ? not really, I'm just being silly  YOU ARE BEING A BIT NEGATIVE.  ? you are right...  SAY, DO YOU HAVE ANY PSYCHOLOGICAL PROBLEMS?  ? probably?  WHAT DOES THAT SUGGEST TO YOU?  ? that you are fun to talk to!  I SEE.  ? thank you for helping me demonstrate VM/IS!  I'M NOT SURE I UNDERSTAND YOU FULLY.  ? that's fine!  COME COME ELUCIDATE YOUR THOUGHTS.  ? okie!  CAN YOU ELABORATE ON THAT?  ?  Figure 27. The original BASIC ELIZA on VS BASIC for VM   DWSAMPLE RFT J1 Page 1  Line 0  ===>  <---+_---1_---+_---2_---+_---3_--V+_---4_---+_---5_---+_---6_---+_>--7_---+_---  ------------------------------------------------------------------- Page 1 ----  To: All Staff  From: Planning Office  Subject: Quarterly Business Meeting  Date: September 23, 1985   This year the Corporet Division has scheduled the Autumn Quarterly  Meeting for Friday, October 23, in Wolverhampton, U.K. So that we  might all prepare for this important meeting, the Planning Office  has compiled the following "mini-report" on one area considered  vital to the company's growth: international development . spell~  ing  We hope the report will help prepare you for some of the major  PF 1=HELP 2=Insert 3=END 4=Instr. 5=RFind 6=Aid  PF 7=Backward 8=Forward 9=Block 10=Command 11=Next 12=Cmdline  Figure 28. DisplayWrite/370 for VM   CP/CMS, VM/CMS, and z/VM 127 »   ---------------------- ISPF/PDF PRIMARY OPTION PANEL ------------------------  OPTION ===>  USERID - WEC  0 ISPF PARMS - Specify terminal and user parameters TIME - 21:20  1 BROWSE - Display source data or output listings TERMINAL - 3278  2 EDIT - Create or change source data PF KEYS - 12  3 UTILITIES - Perform utility functions  4 FOREGROUND - Invoke language processors in foreground  5 BATCH - Submit to batch for language processing  6 COMMAND - Enter CMS command or EXEC  7 DIALOG TEST - Perform dialog testing  8 LM UTILITIES- Perform library management utility functions  9 IBM PRODUCTS- Additional IBM program development products  C CHANGES - Display summary of changes for this release  T TUTORIAL - Display information about ISPF/PDF  X EXIT - Terminate using console, log, and list defaults   Enter END command to terminate ISPF.  5684-123 (C) COPYRIGHT IBM CORP 1980, 1990.  F1=HELP F2=SPLIT F3=END F4=RETURN F5=RFIND F6=RCHANGE  F7=UP F8=DOWN F9=SWAP F10=LEFT F11=RIGHT F12=CURSOR  Figure 29. ISPF on VM/IS            128 Mainframe History »   ______________________________________________________________________________  Licensed Materials - Property of IBM  5645-DB2 5648-A70 (C) Copyright IBM Corp. 1982, 1998  All Rights Reserved.  IBM is a registered trademark of International Business Machines  ______________________________________________________________________________  QMF HOME PANEL Query Management Facility  Version 6 Release 1  ****** ** ** ******** ___  Authorization ID ** ** *** *** ** ___  WEC ** ** **** **** ******* ___  ** ** ** ** ** ** ** ___  Connected to ** * ** ** **** ** ** ___  SQLDBA ****** ** *** ** ** ______  ** ___________________________________  Enter a command on the command line or press a function key.  For help, press the Help function key or enter the command HELP.  ______________________________________________________________________________  1=Help 2=List 3=End 4=Show 5=Chart 6=Query  7=Retrieve 8=Edit Table 9=Form 10=Proc 11=Profile 12=Report  OK, you may enter a command.  COMMAND ===>  Figure 30. QMF, a UI for SQL/DS, on VM   VM/XA SP  VM/XA SP  VM/XA SP  VM/XA SP  As mentioned before, there were three different versions of "VM/XA"  that were made available:  ź VM/XA MA (Migration Aid): a stopgap measure to migrate MVS/SP  systems to MVS/XA; announced 21 October 1981.  ź VM/XA SF (System Facility): announced 12 February 1985, SF was an  expanded version of the Migration Aid that gained support for new  things, like:  Ś Support for the 3090  Ś Support for the 3800 laser printer  Ś "Dedicated" support for the 3370 (FBA) and then-new 3380 (CKD)  DASD  Ś A subset of support for VM/SP's IUCV (which would be necessary  for TCP/IP later)  Ś Multiprocessor guest support    CP/CMS, VM/CMS, and z/VM 129 »   Ś Support for Named Saved Systems, in which saved systems are  stored in spool files (as opposed to hardcoded into DMKSNT at  fixed locations)  Ś CMS 3.1 (from VM/SP Release 3), though somewhat buggy, and  only for "installation and maintenance"  ź VM/XA SP (System Product), of which there were two versions: a  version of VM/XA intended to match the functionality of VM/SP;  announced 11 June 1987. Features included:  Ś A bimodal CMS that supports 31-bit addressing modes  Ś A port of VM/Real Time Monitor  Ś National Language Support for CMS (a feature found in VM/SP)  Ś Support for PROFS (which required a good and usable version of  CMS)  Ś Support for a port of RACF, providing better security over  just DIRMAINT by itself  Most of the "meat and potatoes" of VM/XA came from VM/XA SP, wherein  IBM was trying to supplant the usage of VM/SP HPO on large machines  (like the high-end 308x or 438x processors). Sadly, users found it to  be rather lacking in many ways! For one, users derided the bimodal CMS  (which hit the scene in March 1988) for being horribly unstable and  lacking in support for a large amount of applications. Depending on  the virtual machine's mode, you would get either a 370-mode or XA-mode  CMS. It works like this:          130 Mainframe History »   set machine 370  System reset.  System = 370  ipl cms  DMSACP723I Y (19E) R/O  DMSINS327I The multitasking saved segment VMMTLIB could not be loaded  VM/ESA REL. 2.2 01/21/23 10:22  DMSDCS3993E PIPES saved segment can not be loaded beyond 16M  DMSDCS3993E VMLIB saved segment can not be loaded beyond 16M  DMSWSP100W Shared S-STAT not available  DASD 0222 LINKED R/O; R/W BY OPERATOR  DMSACP723I C (222) R/O  Ready; T=0.10/0.12 10:03:53  set machine xa  System reset.  System = XA  IPL CMS  DMSACP723I Y (19E) R/O  VM/ESA REL. 2.2 01/21/23 10:22  DMSWSP100W Shared S-STAT not available  DASD 0222 LINKED R/O; R/W BY OPERATOR  DMSACP723I C (222) R/O  Ready; T=0.05/0.06 10:04:53  Figure 31. PROFS V2 R1.1 Main Menu  Okay, I know this is a VM/ESA 1.2 system, but it is analogous to VM/XA  Version 2.  VM/XA ultimately was somewhat of a flop; it never had the substantial  amount of effort being poured into it in the same way that VM/SP and  VM/SP HPO had. VM/XA never had the same amount of supported features,  users, or documentation as its internal competition. One of the  biggest issues with it was simply how different its CMS was; some  users of VM/XA SP actually built and ran old versions of CMS from  VM/SP (like Release 3 or Release 4) on VM/XA as 370-mode virtual  machines. While this also meant that there was no way to take advan-  tage of the 31-bit CMS/XA address space, one must also ask if any such  applications ever even existed. For timesharing installations (like  universities) running VM/XA, this solution was perfectly fine. Also,  since VM/XA's CMS was so riddled with OCO modules, any third-party  programs that used CMS nucleus extensions (which large VM programs  did) would be useless on VM/XA. Ultimately, the major flop that was  VM/XA led IBM to seek a suitable replacement... and it came in the  form of...     CP/CMS, VM/CMS, and z/VM 131 »   VM/ESA  VM/ESA  VM/ESA  VM/ESA  VM/ESA was seen as the grand unification of the VM/SP and VM/XA line.  When VM/ESA was announced on September 5, 1990, they had a tall order:  replace VM/SP, VM/SPA HPO, and VM/XA SP. Now, note that VM/SP and  VM/XA were, in no uncertain term, two different systems; the VM/XA  version of CP had diverged so much, its module prefix was changed from  DMK (for the 370 CP) to HCP. VM/ESA would have to encompass two dif-  ferent types of processors: the System/370 machines (of which there  were still certainly some operating in that era) and the System/390  machines (with VM/ESA being the new premier version of VM that would  run on those). As such, there were several versions that would end up  being announced:  ź VM/ESA V1R1 370 Feature (September 28, 1990): the successor to  VM/SP Release 6  ź VM/ESA V1R1 ESA Feature (March 29, 1991): the successor to VM/XA  SP Version 2  ź VM/ESA V1R1.1 ESA Feature (December 27, 1991)  PARALLEL WORLDS: The goals were clear: unify the flailing VM line,  PARALLEL WORLDS  PARALLEL WORLDS  PARALLEL WORLDS  and make VM a system for the 1990s. Of course, this too would be a  tall order -- VM had, at that point, come off of a rather bad decade  of questionable decision after questionable decision, and this version  would also introduce new features. One of those was VM Data Spaces,  which you may recall as being a new feature of MVS/ESA systems (if you  are reading this paper in linear order). VM Data Spaces were essen-  tially the same thing, except a new virtual machine operating mode (to  complement 370 mode, XA mode, and ESA mode) was added: XC mode. A  certain DIAGNOSE function could be used (X'248') to copy data to and  from a Data Space into that VM's main address space. This would end up  being a useful feature for filepool servers. Alas, the 370 Feature  wasn't totally ignored: all of the VM/SP HPO modifications were added  onto 370 Feature (the main ones being the 64 MB real storage limit and  the spool file constraint removal).        132 Mainframe History »   VIRTUAL MACHINE/ENTERPRISE SYSTEMS ARCHITECTURE   VV VV MM MM //  VV VV MMM MMM //  VV VV MMMM MMMM //  VV VV MM MMM MM //  VVV MM M MM // EEEEEEEE SSSSSSS A  V MM MM // EE SS SS AAA  // EE SS AA AA  // EEEEE SSSSSS AA AA  // EE SS AAAAAAA  // EE SS SS AA AA  // EEEEEEEE SSSSSSS AA AA   Fill in your USERID and PASSWORD and press ENTER  (Your password will not appear when you type it)  USERID ===>  PASSWORD ===>  COMMAND ===>  RUNNING VMESA370  Figure 32. VM/ESA V1R1 370 Feature logon screen  Because there were now two concurrent versions of VM riding together  at the same time, much effort had to be put into preserving parity  between the 370 Feature and the ESA Feature. One of those was the ret-  roactive reintroduction of a feature similar to VM/XA that would lower  the amount of times the system programmer would have to generate and  IPL a new CP nucleus on account of configuration changes. The fol-  lowing tasks would often necessitate an IPL on older versions of VM/SP  to change:  ź The list of saved segments (DMKSNT)  ź The logon screen logo and printer separator logo (DMKBOX)  ź The system ID (DMKSYS)  ź 3705 network control programs (when not under the control of VTAM)  ź 3800 printer image libraries  ź National language support libraries  IBM's solution to all of this was something called an override file.  This was essentially a cut-down version of those original assembler  source files, and they mirrored the functionality of the parm disk  mechanism of VM/XA (wherein system configuration files were stored as  plain CMS files within special extents of the system DASD space called   CP/CMS, VM/CMS, and z/VM 133 »   parm disks). Sadly, it was often seen as a rather bad solution to a  problem that could be alleviated by implementing a parm disk style  mechanism for the aging VM/SP nucleus... alas, this never happened.  The ESA Feature also introduced other things that are seemingly for-  gotten, such as:  ź Support for FBA DASD. Believe it or not, VM/XA did not support FBA  _____________________  DASDs! VM/ESA 1.1 introduced support for these (note that VM/ESA  1.0 370 Feature had support from the start).  ź Guest encryption support. MVS/ESA SP 4, when running under ESA  ___________________________  Feature, could now use the cryptographic processors on the host in  a guest.  ź DFSMS/VM. Also called System Managed Storage, DFSMS/VM was  _________  intended to be a port of the MVS feature of the same name, but it  was ultimately a flop.  ź A bimodal CMS This would be the replacement to VM/XA's terrible  _____________  bimodal CMS; the version found on the ESA Feature was actually  reasonable.  VM/ESA VERSION 2: Eventually, Version 1 would come to an end. The 370  VM/ESA VERSION 2  VM/ESA VERSION 2  VM/ESA VERSION 2  Feature would be discontinued after Version 1.5, and Version 2 would  take over with ESA support only. This version represented IBM essen-  tially flailing around in an effort to try to find something that  would make the System/390 mainframe line attractive to new customers,  but, by the mid-1990s, nobody was actively becoming a new mainframe  customer (much in the same way as today). Alas, a lot of new features  came out of the dark days of VM in the mid-90s; VM/ESA V2R1 was  announced on June 12, 1995. New features included:  ź OpenEdition for VM/ESA, more about this below  ______________________  ź 16MB line constraint relief for CMS and GCS virtual machines  ___________________________  ź GMS GUI, an API for CMS that allowed the creation of workstation-  ________  based GUIs (very similar to the ISPF Workstation Agent in the MVS  world)  ź RSCS with TCP/IP support, where RSCS could now natively speak NJE  _________________________  over TCP/IP  ź VSE/VSAM Compression Support, allowing for improved VSAM support  ____________________________  on CMS  ź Distributed Computing Environment for VM, a UNIX-world communi-  ___________________________________________  cations and RPC system that was popular in the era  ź Dynamic CP Exit Facility, wherein CP can gain new features without  ________________________  a re-IPL   134 Mainframe History »   ź LAN File Services/ESA, a combined NFS and SMB server for VM that  _____________________  used an OS/2 server attached to a mainframe as a communications  processor   VM/ESA ONLINE  VV VV MM MM  VV VV MMM MMM  VV VV MM M M MM  VV VV MM M M MM  VV VV MM M M MM  VV VV MM M MM  EEEEEEEEEEEEE SSSSSSSSSSS MAAAAA  EE VV SS MM SS AA AA  EE VVSS MM AAM AA  EE VSS MM AAMM AA  EEEEEEEEEEE SSSSSSSSSSS AAAAAAAAAAAAA  EE SS AA AA  EE SS AA AA  EE SS SS AA AA  EEEEEEEEEEEEE SSSSSSSSSSS AA AA  Fill in your USERID and PASSWORD and press ENTER  (Your password will not appear when you type it)  USERID ===>  PASSWORD ===>  COMMAND ===>  RUNNING VMESA  Figure 33. VM/ESA Version 2 Release 1 logon screen  I shall go in backwards order on this, starting with LFS/ESA. Sadly,  LFS was essentially obsolete the moment it hit; the then-current  System/390 Parallel Enterprise Servers of that year had shelved their  old IBM 3172 LAN Channel Station boxes for the Open Systems Adapter  cards, and those absolutely blew the 3172 away in LAN performance.  LFS, requiring a dedicated communications processor, was almost com-  pletely forgotten about.  Likewise, the CMS GUI Feature was also something else that was ques-  tioned with regards to its necessity. Sure, the GUI client applet ran  on OS/2, Windows, and AIX... but who needed this? This was part of the  "mainframe GUI craze" of the mid-90s (see LANRES for more examples of  this), but that didn't mean that anyone needed it or wanted it. Even-  tually, in the days of z/VM, it was finally discontinued.  OpenEdition, however, was a very interesting feature. Providing a rea-  sonably POSIX-compliant environment for VM, clever people (mainly  Neale Ferguson) ported large amounts of open-source software to VM.  OpenEdition actually provided a port of the Java JVM and JDK; while  this was not often used, it was certainly an impressive feat. Like-  wise, thanks to OpenVM, you could now run things like Apache, Samba,  LDAP services, InterNetNews (an NNTP/Usenet server package), an IRC   CP/CMS, VM/CMS, and z/VM 135 »   server, and more... all from CMS! OpenEdition even provided a form of  POSIX threads, but the fork/exec method ultimately worked better for  most usecases.  The last version of VM/ESA was in 1999 with VM/ESA V2R4; this famous  version represented a big comeback on IBM's behalf. VM/ESA Version 2  had started out rough, but it had ironed out by the turn of the  century. With the new System Z machines, it was time for...   Z/VM  Z/VM  Z/VM  Z/VM  Z/VM 3.X: The first version of z/VM was V3R1 (i.e. 3.1), intended to  Z/VM 3.X  Z/VM 3.X  Z/VM 3.X  continue the version numbering scheme set by VM/ESA Version 1. z/VM  3.1 was intended to be a bit of a stopgap port, but it certainly added  some key new things:  ź 64-bit support for hosts and guests (with retaining what VM called  '32-bit' support for System/390 machines)  ź ESS (Shark) DASD array native Fast Copy support  ź TCP/IP upgrades:  Ś Initial version of SSL for z/VM  Ś OpenVM NFS client  Ś FTP server upgrades to make the server browsable from web  browsers  Ś IP multicasting support  Ś QDIO OSA-Express2 support (adding support for Gigabit Ethernet  and 155 megabit ATM)  ź DFSMS/MVS compatibility  z/VM 3.1 would later get re-released on February 20, 2001, with more  features (or, as the IBM program announcement calls it,  "enhancements"). This version is when z/VM lost the old ROUTED server  and gained the replacement MPROUTE server (that would handle OSPF and  RIP routing, as opposed to ROUTED, which only did RIP).  Z/VM 4.X: z/VM 4.1 was announced on May 29, 2001, and z/VM 4.4 (the  Z/VM 4.X  Z/VM 4.X  Z/VM 4.X  last of the 4.x lineage) was announced on May 13, 2003. Of interest is  the 32-bit nucleus; all versions of z/VM up till 4.4 had a 32-bit  nucleus that you could use (a fun fact for the clever reader: I actu-  ally composed this paper on a z/VM 4.4 system running on a 32-bit  System/390). z/VM 4.2 introduced something called a Guest LAN, wherein  a feature that allowed you to create a virtual network within CP was  added (this would be later expounded upon with z/VM version 4.4, where  it was transfigured into a true virtual Ethernet switch feature that   136 Mainframe History »   no longer required a router served by the TCP/IP service virtual  machine).  Something interested added to z/VM around this time was something  called an EDEVICE. When the System Z machines gained FICON interfaces,  _______  something they quickly gained was support for a FICON controller  running in native Fibre Channel mode. These so-called zFCP cards  allowed native SCSI devices to be mounted on the mainframe... albeit  at the requirement of having OS support for this; z/VM can emulate FBA  DASDs on these zFCP interfaces.   z/VM ONLINE   / VV VVV MM MM  / VV VVV MMM MMM  ZZZZZZ / VV VVV MMMM MMMM  ZZ / VV VVV MM MM MM MM  ZZ / VV VVV MM MMM MM  ZZ / VVVVV MM M MM  ZZ / VVV MM MM  ZZZZZZ / V MM MM  built on IBM Virtualization Technology   Fill in your USERID and PASSWORD and press ENTER  (Your password will not appear when you type it)  USERID ===>  PASSWORD ===>  COMMAND ===>  RUNNING EVIEVM  Figure 34. z/VM Version 4 Release 4 logon screen  Z/VM 5.X: An interesting feature most mainframe hobbyists have for-  Z/VM 5.X  Z/VM 5.X  Z/VM 5.X  gotten about is something called the Integrated Console Controller. In  the "olden days", you had very few options for providing a 3270  console to a mainframe. If you had a Multiprise 3000, great! If not,  you would need either a 3174 with coax terminals or an IBM 2074  console controller that would emulate a local terminal controller with  TN3270 sockets. The z890/z990 (as mentioned above) gained this, and  z/VM 5.1 gained support for controlling those.  Z/VM 6.X: On July 22, 2010, IBM announced z/VM 6.1. The 6.x line was  Z/VM 6.X  Z/VM 6.X  Z/VM 6.X  mainly intended to be a stabilization feature update set, as z/VM was  beginning to find itself in large deployments running many Linux  guests. These fixes would continue until its replacement (7.x) came  out. The next version after this (7.x) was the last real release of  z/VM; subsequent releases were made into a "rolling release" model.   CP/CMS, VM/CMS, and z/VM 137 »                 Figure 35. z/VM History -- zoom in!      138 Mainframe History »   MAINFRAME LINUX  MAINFRAME LINUX  MAINFRAME LINUX  MAINFRAME LINUX  _______________    In the late 1990s, there was a strange gap of a good UNIX system for  mainframes. Sure, there was AIX/ESA and UTS, but they were expensive,  hard to run, and ultimately were commercial failures (compared to the  MVS UNIX environment). In 1998, Linas Vepstas sought to change that.  His project became to be known as the Bigfoot project, and IBM started  a competing project around that time that would be known as "Linux  S/390".   BIGFOOT LINUX/I370  BIGFOOT LINUX/I370  BIGFOOT LINUX/I370  BIGFOOT LINUX/I370  Linas's port was based on a number of things. First, he had to either  produce of acquire a modified version of EGCS (recall the famous  "forking" of GCC into EGCS, and later re-merging); at this point,  there existed a modified version of GCC and Binutils (the GNU assem-  bler and linker) maintained by David Pitts that could assemble  HLASM-syntax assembler files. This compiler toolchain ran on MVS's  UNIX emulator (in this era, it was OS/390 UNIX System Services), but  it did not find itself being used for Linas's project.  Linas took a differentversion of Binutils and GCC. Going off Binutils  _________  2.9.5 and GCC 2.8.1 (by the end of the project; mind you, he started  with Binutils 2.9.1 and EGCS 1.1.1). With this, he was able to start a  hasty port of Linux to the i370 CPU architecture (as that compiler  toolchain, and David Pitts's, knew it as). This port would target  370/XA machines, and would load directly from memory.  Now, it is necessary to understand a new feature of the System/390s  around the time this project was being worked on. The Support Element  gained a new feature to "Load from CD-ROM or Server", wherein a spe-  cific file would contain a memory map and a list of files to populate  the system storage (at the locations specified in the memory map)  with. These files bore the .INS extension, and the Bigfoot/i370 INS  file looked like this:   * INS file to load Linux kernel  * Format: [address where to load]  * The elf-stripped Linux kernel  vmlinux.bin 0x00000000  * Boot command line  cmd_line 0x000d9000  * Load RAMDISK at the same address as given in command line  disk-image 0x00800000  Figure 36. Linux/i370 .INS load file   Mainframe Linux 139 »   A common feature seen on Linux kernels is the concept of the kernel  command line. This provides parameters for the kernel that it needs  either during or after booting, such as the root filesystem to use.  The kernel command line for this system would have been placed imme-  diately after the kernel's end in the memory address space, and it  looks like this:   root=/dev/ram init=/bin/sh -i i370_initrd=0x800000,4096  Figure 37. Linux/i370 parameter/command line file  The ramdisk would contain the root filesystem, as i370 Linux never  gained drivers for anything (except for a 3215 console). This would be  an exactly 4-megabyte (the 4096 at the end of the command line speci-  fies this) disk image formatted with the Linux ext2 filesystem. Upon  loading, this file would be mounted by the kernel's virtual filesystem  layer and ext2 driver as the root; it would also contain the initial  program to run, which in the case of the example I shall demonstrate,  is the shell.  When you wished to load the system, you would instruct the Support  Element to do an IPL from a CD-ROM (which could also be a path on the  SE's filesystem) or a "server" (an FTP server). Since there were no  drivers for anything (including network devices), the system is as  good as useless. Nonetheless, here is a sample load and run of i370  Linux:            140 Mainframe History »   Linux version 2.2.1 (root@linux-arm64vm) (gcc version 3.4.6) #1  Sun Sep 14 02:09:53 PM CDT 2025  Boot command line: root=/dev/ram init=/bin/sh  -i i370_initrd=0x800000,4096  Device 0009 CU ID 3215 Model 00 ready  Device 0009 mapped to unix /dev/console (227, 1)  Device 000D found CU ID 3505 Model 01 ready  Device 000E found CU ID 0000 Model 00 ready  Device 0200 found CU ID 3215 Model 00 not ready  Device 0200 mapped to unix /dev/3270/raw0 (227, 128)  Device 0201 found CU ID 3215 Model 00 not ready  Device 0201 mapped to unix /dev/3270/raw1 (227, 129)  Device 0202 found CU ID 3215 Model 00 not ready  Device 0202 mapped to unix /dev/3270/raw2 (227, 130)  Device 0203 found CU ID 3215 Model 00 not ready  Device 0203 mapped to unix /dev/3270/raw3 (227, 131)  Calibrating delay loop... 465.31 BogoMIPS  Memory: 59640k available (748k code, 940k data, 48k init)  Init Ramdisk: 4096k [00800000,00c00000]  POSIX conformance testing by UNIFIX  Linux NET4.0 for Linux 2.2  Based upon Swansea University Computer Society NET3.039  NET4: Unix domain sockets 1.0 for Linux NET4.0.  NET4: Linux TCP/IP 1.0 for NET4.0  IP Protocols: ICMP, UDP, TCP  Starting kswapd v 1.1.1.1  pty: 256 Unix98 ptys configured  RAM disk driver initialized: 16 RAM disks of 262144K size  loop: registered device at major 7  i370_setup_devices /dev/console (c 227 1)  RAMDISK: ext2 filesystem found at block 0  RAMDISK: Loading 4096 blocks [1 disk] into ram disk...  VFS: Mounted root (ext2 filesystem).  freed initmem from 0010e000 to 0011a000 (12 pages total)  raw3215_open of /dev/console (c 227 1)  can't access tty; job control turned off  / # uname -a  Linux (none) 2.2.1 #1 Sun Sep 14 02:09:53 PM CDT 2025 i370 GNU/Linux  i370_do_signal sh/1 signr=17 handler=8187ca0c  i370_sys_sigreturn: regs=7f800768  / # mount -a  i370_do_signal sh/1 signr=17 handler=8187ca0c  i370_sys_sigreturn: regs=7f800768  / # mount  /dev/root on / type ext2 (rw)  /proc on /proc type proc (rw)  i370_do_signal sh/1 signr=17 handler=8187ca0c  i370_sys_sigreturn: regs=7f800768  /  Figure 38. A rare view of a running i370 Linux system   Mainframe Linux 141 »   Ultimately, there would be IBM's own Linux-for-S/390 port that would  end up totally replacing Bigfoot/i370; Linas's crew was essentially  powerless to beat IBM's crew on their own front... and the i370 Linux  port dies out.  Well, mostly. In September 2024, Linas actually dusted off the old  source code for the i370 port, made it work on Hercules (which was now  mature, as opposed to how it was in the original i370 era), and pub-  lished the source code on his website; this effort is how the earlier  listing of a i370 kernel starting was taken.   IBM LINUX/390  IBM LINUX/390  IBM LINUX/390  IBM LINUX/390  In the late 90s, IBM partnered with Marist College to attempt to do  the same thing (in parallel) as Linas was spearheading. IBM's effort  focused on newer machines (those being the 9672 G2-and-newer), whereas  i370 focused on older machines. Actually, there were several differ-  ences between s390 (as it became to be known, "s390" being the name of  the directory under the Linux kernel source tree that held the  machine-specific code) and i370:  ź The i370 assembler could process HLASM-style code, whereas the  s390 assembler was only capable of understanding the UNIX assem-  bler syntax.  ź The s390 port required a 9672-G2 or newer, whereas the i370 port  could run on any 370/XA-or-newer machine.  ź The s390 project was spearheaded entirely by IBM, whereas i370 was  a "vendor-neutral" project.  The Marist folks worked on Linux/390 intensely, and by 2000, a usable  distribution had been produced. This came in the form of a modified  version of Red Hat that became to be known as "Marist Linux". This OS  could be started in three ways:  ź From a tape, which could be produced from MVS, VM, or VSE  ź From the VM punched card reader (this method is still used today)  ź From an INS file when installing without VM, just like the i370  port (this method is also still used today)  Installation was relatively simple; you would load the kernel (which  itself was followed by the kernel command line text and then the  ramdisk, just like i370), configure a network device, format a DASD,  then restore the root filesystem. After that, re-IPL and you were off  to the races!  By 2001, the System Z was in full swing and s390 Linux was quickly  ported over to it; this came in the form of a modified Red Hat (as  usual) called Think Blue Linux. This ended up being discontinued in  favor of other "mainline" Linux images around that time; Debian   142 Mainframe History »   quickly gained a s390 distribution on their list, as did CentOS, SUSE  Enterprise Linux, and more. Today, s390x (the "x" being the 64-bit  port of s390 Linux to the System Z) Linux's install base is nearly  entirely Ubuntu Server, SUSE Enterprise Linux, Red Hat Enterprise  Linux, and Debian. More and more drivers are on the system today now  than ever, and one can even attach PCIe cards to the System Z PCIe  card cages (via adapters, of course)!                  Mainframe Linux 143 »   MAINFRAME UNIXES  MAINFRAME UNIXES  MAINFRAME UNIXES  MAINFRAME UNIXES  ________________    In the early 80s, there were two competing efforts to get UNIX ported  to the System/370. These were:  ź Princeton University UNIX/370: a native port of UNIX v6 that  evolved into Amdahl UTS  ź AT&T Bell Labs UNIX/370: a hacked version of TSS/370, postdating  Princeton but being intended for much larger systems  Let us examine these two interesting systems, then examine their suc-  cessors. I have taken the liberty of discussing these in reverse  order, as the fruits of Princeton's labor came only after Bell Labs's  endeavor.   BELL LABS UNIX/370  BELL LABS UNIX/370  BELL LABS UNIX/370  BELL LABS UNIX/370  Bell Labs's attempt was certainly more interesting than Princeton's.  For one, they did not directly port UNIX to run on the S/370 CPU;  instead, they took TSS/370 as a base, and replaced the user process  supervisor with one that functioned as a UNIX system. While this may  seem rather odd and inane, this was actually done for good reasons:  first, the I/O model of the S/370 is radically different from the  PDP-11 system UNIX was originally written to run on. Because of this,  the Bell Labs engineers instead chose to do the TSS hack; this also  provided an unexpected benefit: the IBM field service personnel could  run their native problem analysis tools to determine what could be  going wrong with a S/370, as any hardware error reports (from the EREP  program) would be in a standard format that did not necessitate the  writing of UNIX-native code to emulate this format. Put simply, they  took the easiest way out.  THE PURPOSE: One must also understand why this project was started in  THE PURPOSE  THE PURPOSE  THE PURPOSE  the first place: Bell Labs was the progenitor of some of the telephone  switches used throughout North America. One of those was the 5ESS (ESS  meaning Electronic Switching System), a combination analog and ISDN  phone switch. In 1978, Bell Labs started to seriously consider  bringing UNIX over to a larger computer than what they were using; the  5ESS development needs were so large relative to the comparatively  small machines the engineers had to work with that their patience  eventually expired and the project began. The decision to use UNIX for  the 5ESS software development actually predated the formal start of  the project in 1980. By late 1980, the programmers writing the 5ESS  software were using a whopping 9 PDP-11/70s. UNIX was selected in the  first place because the programmers that would be working on the 5ESS  project were already familiar with tools found on PWB/UNIX, which we  now today know as:   144 Mainframe History »   ź make, the program generation and maintenance utility  ź m4, the macro processor  ź awk, the text programming language  ź sed, the text stream editor  ź yacc, Yet Another Compiler Compiler  ź lex, a lexer generator  ź an expanded editor, predating vi  ź SCCS, the UNIX source code control management system  The development crew having to use PDP-11s found themselves in a  rather terrible position. Their 9 PDP-11s meant fragmented develop-  ment, but the machines were connected together "using a commercially  available high-speed network with drivers written for the UNIX oper-  ating system." Alas, they were not using a centralized source code  management system (like Git today); when they were ready to build a  firmware image for the prototype 5ESS they had, they would have to  send all of the objects over to one of the PDP-11s for linking (that  same machine would coalesce all of the object files from the other  systems). Since the 5ESS project began to grow, it was starting to no  longer become feasible to continue to use the approach they were  using; around this time, UNIX/370 caught the eye of the switch engi-  neers.  Since the PDP-11s were obsolete performance-wise and cumbersome to  conduct as an entire network, the search for a replacement began. The  engineers looked at a VAX 11/780, but it was only twice as fast as the  PDP-11. This meant they could halve their PDP-11s, but the VAX systems  were also a lot larger and more power-hungry. As such, someone consid-  ered getting a real mainframe. An IBM 3033 AP System/370 was 15 times  faster than the PDP-11s, and, though it was larger than a room full of  VAX-11s, it was much easier to work with (as it was a single system,  not a disjoint cluster in an era before UNIX had good network  filesystems and remote management tooling). The engineers working on  UNIX/370 dusted off their terminals and got back to work.  As mentioned before, the radically foreign I/O architecture of the  S/370 initially scared some of the engineers. UNIX had several road-  blocks in its original implementation that made the project even more  difficult on top of that:  ź The System/370s were multiprocessing machines (if equipped), UNIX  did not support multiprocessor machines at all.  ź The System/370 memory model was that of paging, not swapping like  it was on PDP-11 UNIX.   Mainframe UNIXes 145 »   ź The customer engineers from IBM expected the aforementioned  EREP-format error logs, UNIX would have to gain code for this.  ź The I/O devices on most System/370 machines could be multipathed,  UNIX didn't even support channelized I/O.  THE HACKED TSS: Needless to say, this would be daunting task. As men-  THE HACKED TSS  THE HACKED TSS  THE HACKED TSS  tioned, the engineers realized they could skip having to write a lot  of new code by adapting TSS/370. Primary sources mention that choosing  TSS/370 as the system to base UNIX/370 off of was, at best, quite con-  troversial. Nobody knew much about the system as it was rather poorly  documented outside of IBM, and its install base (especially after the  announcement of VM/370 being a fully supported system) consisted of so  few systems you could count them on your fingers. In 1979, Bell Labs  talked to IBM about modifying TSS to support the structure the rest of  the UNIX/370 system expected. IBM followed through with this, and,  under a program license agreement, provided Bell Labs with the modi-  fied TSS/370 system in 1980.  This new TSS was surprisingly structured. There were 3 levels of pro-  grams that the OS would run, consisting of userland programs (like  shells, editors, compilers, and other such tools), the UNIX System  Supervisor (adapting TSS to a C-style UNIX kernel interface, this was  essentially a userland port of the UNIX kernel), and the Resident  Supervisor (the TSS core that provided multitasking, hardware manage-  ment, system control functions, and such). Every UNIX process ran  within its own 16-megabyte virtual memory address space (for the first  time in UNIX history), and the Resident Supervisor provided services  to the virtual address spaces (like scheduling the execution of the  address spaces, dispatching the execution queue, managing real  storage, etc).  MEMORY MODEL: Strangely enough, this memory management does not work  MEMORY MODEL  MEMORY MODEL  MEMORY MODEL  like you think it does if you are used to the VAX virtual memory UNIX  model. Each UNIX system process ran in its own containerized address  space along with a copy of the UNIX System Supervisor. A UNIX system  ________________________________________________  process is essentially a virtual UNIX machine; multiple user programs  could run within the address space. The UNIX System Supervisor was  mapped into the high 8 megabytes of the virtual memory address space,  and user programs resided in the lower 8 megabytes. The bottom page  was reserved for interrupt vectors (in true S/370 fashion). Since the  S/370 memory management unit allowed for pages to be shared between  processes (which, in this context, a process running under TSS would  be an entire virtual UNIX machine); this allowed several identical  running copies of various UNIX programs across several UNIX system  processes to be shared. Furthermore, the UNIX System Supervisor could  be shared amongst the system processes, alleviating excess memory  usage.  Due to this design, there were 2 layers of system calls present in  this strange OS. User programs could make UNIX system calls, which  would be trapped by the UNIX System Supervisor. If the system call was  not related to anything that required hardware control, the UNIX  System Supervisor could dispatch and execute that system call on its   146 Mainframe History »   own. If it needed to call the Resident Supervisor (remember, this is  the modified TSS/370 nucleus), it could do so. Interestingly, all of  the UNIX System Supervisor to Resident Supervisor system calls were  processed fully asynchronously; when the system call execution was  done and it needed to return data to the caller, it would actually  trigger an interrupt to the virtual address space. As you can probably  tell by now, the "UNIX address spaces" were absolutely "UNIX virtual  machines", and there was a strong CP/CMS influence on this system!  Likewise, if the UNIX System Supervisor needed to interrupt a user  process, it would do so through a signal (in true UNIX fashion). The  system could even utilize the S/370 Virtual Machine Assist feature,  boosting performance even further by alleviating an unnecessary layer  of system call return indirection.  The S/370, as mentioned, also featured a paging memory architecture.  This meant the UNIX system address spaces could be fully preempted and  paged out of memory whenever there was a storage constraint (or just  inactivity, like an idling shell that's been logged in for a day with  no commands being ran). The Resident Supervisor handled all of the  virtual memory operations, and the UNIX System Supervisors running  under it would not have to do any of their own memory management  outside of handling the brk() system call that grew a user process's  address space. To alleviate memory pressure even more, the Resident  Supervisor could also asynchronously perform page migration -- this  was a feature wherein paged-out processes stored on fast non-RAM  storage (devices such as fixed-head disks, drum memory units, or  "solid-state memory") could be moved over to slower storage (like  normal moving-head DASD disks).  DEVICE MODEL: The disk and I/O subsystem was also rather different  DEVICE MODEL  DEVICE MODEL  DEVICE MODEL  from PDP-11 UNIX. For one, the engineers chose to use the normal UNIX  filesystem of the era... albeit with an enlarged block size (up to  4096, which matches the S/370 page size). The I/O subsystem also  cached as much as it could; on a 16-megabyte S/370, 4 megabytes of  that address space was allocated for disk I/O buffering. Note that  this caching and filesystem I/O processing is done by the UNIX System  Supervisor and not by the Resident Supervisor; this improved perform-  ance quite a bit, and especially moreso if multiple paging layers were  used. Speaking of which, the Resident Supervisor provides underlying  system calls that permit disk access, albeit in a rather unusual way.  Rather than executing disk I/O operations synchronously, the block I/O  layer (in the RS, not the USS) functioned through memory-mapped file  buffers. For example, to read a file, the USS will allocate a buffer,  then signal to the RS to read in the data and deposit it into that  buffer. Likewise, for writing, there is outbound caching; whenever a  write occurs, the RS will claim that the write was successful, but it  really just waits in a flush queue (this is the same as the modern-day  disk caching layers found on modern OS kernels).  Process management within the USS regions was also rather clever. In  this era, UNIX did not have threads; spawning new processes with fork  and exec was essentially the only option. In the modern day, the UNIX  fork call employs a copy-on-write technique; that is, only copy the  memory portions that you absolutely need (and do it one page at a time   Mainframe UNIXes 147 »   to save on space and time). However, UNIX/370 didn't do partial CoW  like one might find on a modern kernel; instead, it would spawn off an  asynchronous copy job and the program would be usable during the copy  through page sharing (of which the shared pages had a rather clever  name: multiplexed pages). UNIX/370 also had design issues related to  process synchronization that needed to be worked out. Consider the  case of being ran under a VM: at any point, while your process is  running within a VM, your execution may be stalled or preempted at any  time. This is also true with UNIX/370: the USS address spaces could  be stalled at any time by the RS for various reasons (page faults,  storage exhaustion, disk I/O). Since the S/370 machine UNIX/370 tar-  geted was also a multiprocessor system, one would also have to figure  out how to synchronize user programs across several physical CPUs. To  address this, the engineers used the Dijkstra Semaphore mechanism in  which resource accesses were counted and serialized between multiple  CPUs.  Terminal handling was also somewhat difficult. On the S/370, the usage  of plain ASCII terminals was rare; this is in direct contrast to what  UNIX expected, wherein full-duplex immediate data transfer was often  necessary to support the usage of nearly all programs (from the shell  to the editor). This may not be an issue on small systems, wherein the  CPU is interrupted with every keypress since it needs to echo the  character back to the terminal, but this becomes very interrupt-heavy  with many logged-on users. The AT&T 3B20 machines (which, in the era  in which UNIX/370 was written, the largest system that ran UNIX) had  front-end I/O processors that alleviated the interrupt load on the  host CPU, but those were tailored to machines foreign to the S/370.  IBM, of course, manufactured 3705s (replacing 2703s) and 3274s;  neither of these were suitable for large amounts of directly-  controlled ASCII terminals. Note that ASCII terminals could be con-  nected to a 2703/3705, but the OS on the host S/370 processor did not  have direct character control over them (a good example to see this  would be noticing the distinct lack of fullscreen programs usable on  ASCII terminals connected to a VM/CMS system).  To alleviate this terminal issue, the engineers found a rather clever  solution to replace the terminal controllers that would be of no use  to UNIX: use an IBM Series/1 as a front-end processor. Bell Labs asked  IBM for help once again to rig up a Series/1 with a S/370 channel  interface as a terminal controller; IBM delivered this code and hard-  ware in late 1980 to great success. Later, the engineers realized they  could use a full AT&T 3B20S as a front-end processor too; this used  conventional UNIX as the OS on it (rather than some strange, to the  engineers, Series/1 OS). Seeing that they had figured out how to run  multiple different computers as terminal controller front-end  processors, some postulated that it would be possible to have  frequently-used typing-heavy programs (like fullscreen editors and  shells) run directly on the front-end processor; this never matured,  but this idea was seen implemented on other non-IBM computers.  DEPLOYMENT: In order to deploy this great system (the original  DEPLOYMENT  DEPLOYMENT  DEPLOYMENT  3033AP), Bell Labs realized an ideal migration would consist of a  gradual turnover to the mainframe. The networking code the 9 5ESS   148 Mainframe History »   development PDP-11s used was ported over to the 370, and the user  migration was done with 10% of the userbase moved over to the 370  every other weekend. The initial deployment had an 80% reliability,  but this was upped to 95% and eventually 98% within 6 months of the  original deployment. Once Bell Labs realized they could now run mul-  ____  tiple mainframes in a UNIX/370 network, they did so; they had a tri-  _____  system network of a 3033AP, 3033UP, and 3081K system (in 1983). Near  the end of their project, they added a 4341 into the fray; this  machine was just as functional as the other systems. Eventually,  UNIX/370 would come to an end, but the important lessons learned from  it would go on to shape UNIX for the better years down the line.   PRINCETON UNIX/370  PRINCETON UNIX/370  PRINCETON UNIX/370  PRINCETON UNIX/370  Computing at Princeton has a very colorful history, and they played  pivotal roles in the community aspect of IBM mainframes. However, our  story takes us to the mid-1970s, when two mainframes were installed in  Princeton's campus. There was a System/370 Model 158 that ran APL  timesharing for the State of New Jersey's educational system; there  was also a System/360 Model 91 monster that only ran batch jobs. Since  so few people had access to the APL system, some departments sought  computers of their own. One of those was the Electrical Engineering  and Computer Science department, who chose to purchase a PDP-11/45. It  originally ran what I believe was RSTS, but it was converted over to  UNIX by 1975. Many EECS students and staff took to the system to great  success, but trouble was on the horizon. In late 1975, New Jersey  decided they would end the relationship in which the 370/158 would be  taken away. The EECS UNIX users then heavily petitioned the Computing  Center staff to consider buying a small PDP-11/70 to timeshare with  UNIX. The original plan that Princeton had was to buy a System/370  Model 145 (because that was all that the university could afford); a  PDP-11/70 would be even cheaper, and save the money quite a large  chunk of money.  IBM, never to be outdone, decided they would try to undercut the DEC  competition and sold Princeton a tremendously discounted 370/158...  which just so happened to be the 370/158 that was already sitting in  the building. In that era, a lot of mainframes were actually rented  ______  from IBM, and the State of New Jersey was doing exactly that. When  they stopped paying for the APL timesharing, Princeton quickly  installed VM/370 on the system, and so began Princeton's famous love  of VM. Sadly, the EECS UNIX users were rather disappointed by the  decision, but not all hope was lost. Tom Lyon jokingly proposed that,  well, since the System/370 was running a virtual machine monitor,  someone could port UNIX (which was written in a high-level language,  only requiring the porting of a compiler) to run under it!  His older classmates told him it was a terrible idea, and the idea was  gone as soon as it left his mind. Surprisingly, not all hope was lost,  though; in the summer of 1975, Eric Schmidt (the former Google CEO and  philanthropist) took an internship at Bell Labs. There, he helped  write the UNIX lex program. He discovered that Bell Labs had a C com-  piler for the System/360 that cross-generated object code from a   Mainframe UNIXes 149 »   PDP-11, but it was unclear who wrote it; Eric figured that Mike Lesk  (who he was working with to write lex) was responsible for its cre-  ation. Seeing that the tools were sitting there, Eric remembered Tom's  seemingly off-the-cuff non-serious remark.  THE INITIAL PORT: Saying yes to Eric's request to assemble a  THE INITIAL PORT  THE INITIAL PORT  THE INITIAL PORT  Princeton team to port UNIX to the 370, the process began. However,  there were many issues to overcome beforehand. Of course, the EECS  folks had their PDP-11/45 (complete with the UNIX source code too, as  one would frequently have in that era)... but it was far from the  370/158 and totally disconnected. Even without a network link, issues  were all-too-present; the PDP-11 did not have a 9-track tape drive,  and the 370 of course did not have a DECtape drive. To overcome this,  Tom writes that a rather crazy workaround involving many hops was  found:  ź The EECS PDP-11/45 was connected to a PDP-8 in the same EECS  building, but it did not have very good reliability  ź An excessively long serial cable that ran from the PDP-8 in the B  wing of the E-Quad to a terminal room in a totally different wing  (the E wing) of the E-Quad; this cable was so long and ran through  two too many buildings, and was plagued by lots of line noise  ź A multiplexed line-of-sight infrared optical link that connected  the terminal room to the computer center located across the street  at 87 Prospect Ave; this link provided a 9600 baud connection, but  it broke during rain or foggy weather (this device was manufac-  tured by Tran Telecommunications)  ź The 370/158 mainframe in the basement of the Computing Center,  wherein the multiplexed optical link was attached to an IBM 2703  communications processor  ź VM/370's RSCS program, which would receive files over one of the  serial links (which was ultimately tied to the serial port on the  PDP-8)  ź A test virtual machine, which would receive the virtual card decks  from RSCS  Needless to say, this complex scheme was less-than-ideal. Nonethe-  less, the C compiler (which ran on the development PDP-11) did not  produce object code, only Assembler XF input listings. This meant that  the C compiler's assembler output would have to be transmitted to VM,  assembled on VM, linked, and finally could be tested. Apparently, the  linker was quite a headache to the UNIX guys, furthering the diffi-  culty. By 1977, Tom had been working rather solo (since two of the  other guys he had on his UNIX team had graduated); he got the kernel  to work reasonably well, ported over the filesystem (which required  disk access to be figured out), got a shell to work, and got some  userland programs ported over. Sadly, the terrible communications  scheme began to degrade, ultimately ending the project in the fall of  1977. However, change would come when a certain company reached out.   150 Mainframe History »   AMDAHL: Amdahl is a company that, throughout the 80s, was IBM's  AMDAHL  AMDAHL  AMDAHL  biggest competitor. It had been founded by one of the lead designers  of the System/360, and offered System/370-compatible (and later  System/390-compatible) machines that sold reasonably well. John Hiles,  who worked for Amdahl, managed to get Tom in one of those "right  place, right time" moments: Tom was doing a summer internship at Bell  Labs in 1977, when Ken Thompson answers the phone: it's John, who was  trying to get information about what was seemingly just a rumored port  of UNIX to the System/370. Tom, being close by to Ken, has a telephone  receiver handed to him, and he begins to explain Princeton's UNIX/370.  UTS: Seeing that UNIX/370 might be a serious future for Amdahl, John  UTS  UTS  UTS  went and acquired a UNIX license from Bell Labs. On spring break in  1978, Tom made it out to Amdahl to do some consulting for a week.  Armed with 4 DECtapes containing the UNIX/370 sources (just to be  clear, this UNIX/370 has absolutely nothing to do with the later Bell  Labs TSS-based UNIX port), he and John rented some time on a PDP-11  held at a local DEC field office. There, he loaded up UNIX on the  rented PDP at that office, and copied the DECtapes over to 9-track  tapes. In a rare feat of preservation, images of these original tapes  not only exist, but are available on GitHub; there were 4 DECtapes:  ź the full UNIX/370 source  ź the UNIX/370 "virgin source"  ź the modified 370 C compiler  ź the modified 370 cross-assembler  Shortly thereafter, in June, Tom began his job at Amdahl. By early  1979, the team had managed to bring over the rest of UNIX v6 to the  370 CPU architecture, and they were running a full UNIX on an Amdahl  470V/6 (of which Amdahl had partnered with Fujitsu to build) under  VM/370. This port of UNIX was named "Au" (like "gold", on the peri-  odic table) and quickly took success to its users. Tom had written a  3270 terminal driver for the OS, which also allowed for full-screen  applications to be written (such as an advanced editor). In late 1979,  Amdahl acquired a UNIX v7 tape from Bell Labs, and Amdahl UTS was  properly announced in 1980.  Tapes for UTS were eventually sent back to Princeton, owing to the  fact that a lot of the UTS developers were Princeton graduates. These  tapes found themselves discarded on the side of the road outside of  the Computing Center, until Dave Jones at Sine Nomine Associates dis-  covered their untimely demise. These tapes were recovered, dumped, and  in that stack were tapes for the original 1980 release of Amdahl UTS  (complete with the PWB/UNIX tooling). Alas, it can be loaded and ran:     Mainframe UNIXes 151 »   IPL 220  Enter system name:  autouts  UTS Version 1.0  Storage = 6144K  1405 free pages  /dev/dsk220:  /dev/dsk110:  /dev/dsk330:  /dev/dsk550:  /dev/dsk660:  no space on dev 4/0  no space on dev 4/0  no space on dev 4/0  no space on dev 4/0  no space on dev 4/0  no space on dev 4/0  no space on dev 4/0  DISCONNECT AT 16:37:29 CDT MONDAY 10/06/25  Press enter or clear key to continue   RUNNING VMSP  Figure 39. Amdahl UTS 1.0 running under VM/SP R5   IX/370  IX/370  IX/370  IX/370  Little is known about IX/370 in this day and age, solely because of  the fact that there are no known extant tapes of it available in this  era. Nonetheless, it was designed to run under VM/SP, and was suppos-  edly popular on the 9370.  What information is available for IX/370 comes from, of all places,  the 9370 product announcements and the associated program product  announcements that followed it. IX/370 boasted that it had virtual  memory storage and paging, which IBM claimed many other UNIX System V  implementations lacked (this is true; note that this product was  produced before the newer UNIX System V Release 4, the version most  commonly seen on UNIX workstations and servers through the 90s).  It also remarked some interesting notes about the filesystem implemen-  tation. The announcements note that IX/370 used a filesystem block  size of 4096 (does this sound familiar?), whereas other UNIX implemen-  tations used 512 or 1024. It also boasts the addition of a system call  that facilitated a filesystem locking mechanism (one might recognize  it from newer UNIX systems: lockf).  Most interestingly, it notes that several IX/370 subsystems could run  under one master IX/370 system. Each subsystem operated independently  of the others, with fully isolated users, programs, and more. This is   152 Mainframe History »   notably similar to the famous Bell Labs UNIX/370 system! Since it had  to run under VM, it supported the VM-emulated line printers (and could  also associate tag data with the print jobs, allowing for file dis-  tribution on an RSCS network). In order to make the system passingly  attractive to an office customer base, IBM licensed INmail and INnet  from Interactive Systems Corporation (of note for their PC UNIX offer-  ings in this era; PC/IX and 386/ix were reasonably popular until Sun  acquired ISC and released Interactive UNIX). To connect to ASCII ter-  minals, both the UNIX/370 Series/1 terminal attachment as well as the  9370's ASCII Subsystem Controller.  Needless to say, all signs point to IX/370 as being derived from the  Bell Labs UNIX/370 project. Alas, no tapes of it exist, so further  study is impossible.   AIX/370  AIX/370  AIX/370  AIX/370  In 1988, IBM partnered with Locus Computing Corporation to produce a  (supposed) port of AIX to the PS/2 (i.e. Intel 386) platform. In  reality, it was a port of the OSF/1 codebase to the 386, and it was  surprisingly expensive for the customers that did buy it. Nonetheless,  the people that did buy it found a reasonably useful system, but it  was not a commercial success.  More interestingly, however, was something else that resulted from the  IBM/Locus partnership (also released that same year, on March 15,  1988): AIX/370. This was a true and real port of UNIX (again, OSF/1)  to the 370 and 370/XA CPU. In a flash of brilliance, it also supported  Token Ring and Ethernet networking through the IBM 8232 LCS boxes  (predating the later 3172); to date, no other version of UNIX on the  mainframe save for Amdahl UTS supported this. It had to be ran under  some version of VM (supported was VM/SP, VM/SP HPO, and, surprisingly,  VM/XA SP), and was fully bimodal; it even supported the 3090's Vector  Facility! It was fully POSIX-compliant, and had feature-parity  matching with both UNIX System V Release 2 and 4.3 BSD (at that point,  ___  those were the only two versions of UNIX that had significant usage  share).  This port was no joke. It had, as evidenced by the announcement  letter:  ź System/370, XA, and 3090 Vector Facility support; quite a tall  order for a totally new OS  ź full TCP/IP support  ź a "DOS Server" feature that may have been related to an earlier  Locus product  ź The Transparent Computing Facility, allowing access to distributed  computing systems   Mainframe UNIXes 153 »   ź full X11 support (albeit through a network; no display devices  attached to the mainframe would be able to show X graphics)  ź an optimizing C compiler  ź a command to invoke a program on CMS (named oncms)  The addressing size limits were rather interesting. When the OS was  running in 370 mode, user programs could access up to 8 MB of virtual  memory; in XA mode, the ceiling was raised to 770 MB (a rather odd  limit). The Vector Facility was also fully supported, and IBM had  planned to release a port of VS FORTRAN (both the compiler and the  Engineering/Scientific Subroutine Library) to AIX/370, but no sur-  viving copies of this exist.  The TCP/IP stack was interesting, as it was the UNIX System V TCP/IP  stack ported straight to the 370. It had support for SMTP, FTP,  Telnet, the BSD socket API, the ability to be a router/gateway (which  supported Ethernet, Token Ring, and channel-to-channel adapters, pre-  sumably for talking to the VM TCP/IP stack directly), and support for  the BSD "r commands" (rsh, rcp, rlogin).  The DOS Server feature was a host-based program that ran on an AIX  system (which could be AIX/6000 or AIX/370) wherein connections from  DOS (3.3) PCs were accepted. The DOS PC would run the IBM AIX Access  for DOS Users program, which provided access to AIX files, printers,  and included a VT100 emulator for remote connection to AIX (this  program also included an absolutely famous unused error message, which  was, and I quote, "Sex feels so fucking good, I just can't stop.", I  am dead serious).  In addition to that DOS Server package, AIX/370 could also talk on an  NJE network (with the aid of RSCS, presumably running on the same VM  system under which AIX/370 executed). Full NETDATA file support was  present, allowing users to easily transmit files, datasets, and emails  between AIX/370 and other OSes.  Since X.25 was quite popular in this era, AIX/370 also had support for  X.25 networks. However, it would require a PS/2 Model 80 (though it  would possibly work with other systems) that had an X.25 synchronous  serial adapter installed, and was running AIX PS/2. The AIX/370 host  would, by way of being on the same LAN as the AIX PS/2 box, be able to  utilize an X.25 network (this almost certainly seemed to be a solution  wherein users would log into the AIX PS/2 system from the AIX/370  system, then be able to make X.25 PAD connections from there or vice-  versa).  The Transparent Computing Facility was another AIX PS/2 overlap  product, and it allowed an AIX/370 system or an AIX PS/2 system to  become a member of a true cluster system. Programs could run on any  host, files could be stored on any host, and you did not have to  switch which node you were logged into in order to run a program on a  different machine. This also incurred a shared file system, and there  were redundancy and locking measures to ensure that a system failure   154 Mainframe History »   on one node would not result in other programs automatically being  reverted to older versions of files. Because of the distributed nature  of this clustering scheme, processes could also hot-migrate from one  system to another in a bit of a load-balancing scheme. Really, this  was a surprisingly advanced program, and the functionality of it has  not been seen since (as no copies of AIX/370 are known to exist, and  it does not seem to be archived for AIX PS/2 either).  IBM, having partnered with Interactive Systems Corporation to provide  first-class ISV application support for both AIX PS/2 and AIX/370,  made available a number of ISC's own programs to both of these  systems. INnet was a UUCP-style networking package that ISC produced,  and it worked hand in hand with INmail to transfer emails to remote  sites. Since it was fully compatible with UUCP, users were not locking  themselves into some proprietary network system that would stop being  useful when support ended. ISC also provided an improved FTP client  (wherein the command that was ran was all-caps too, "FTP") and an  improved editor (INed, a program that is often seen on Interactive  UNIX systems of the same vintage) that was a heavily improved offering  over the built-in UNIX vi program; it supported multiple edit ses-  sions, several windows, and better copy-paste functions. Alas, it was  eventually replaced with...   AIX/ESA  AIX/ESA  AIX/ESA  AIX/ESA  Seeing that it was high time for an upgrade to AIX/370 (only if there  were only ever a few customers), IBM announced AIX/ESA in 1990. This  was overtly based on the OSF/1 codebase, even though earlier versions  were based on it. The most important change was the ability for it to  run without the aid of VM, directly on the real hardware; it also  gained multiprocessor support (though it started with support for 3  CPUs; support for 6 CPUs was added later by September 30, 1992).  Support for HIPPI (High Performance Parallel Interface) adapters was  also added; this was an old interface intended to connect peripherals  to supercomputers, and had an effective throughput of 800 megabits.  AIX/ESA also gained for the new-and-improved 3172 Interconnect Con-  troller (though frequently just called the 3172 LCS), but you could  ________  now use a channel-attached (a parallel channel, mind you; the ESCON  interfaces did not yet function with this scheme) RS/6000 as a  front-end network processor on the mainframe. This supposedly ran  faster than the 3172 LCS boxes, which was accessed like a 3088 CTC  adapter; this was aided by the much faster POWER CPU of the RS/6000  (which certainly dwarfed the CPU performance of the 8283s and 3172s,  which were essentially just PCs).  Since this was based off of OSF/1, there were more features than meets  the eye! For one, you could now dynamically load kernel modules (a  feature now standard on UNIX, but was almost entirely unheard of in  1992), use an advanced UNIX accounting system (not banking, but taking  account of processes), and more.   Mainframe UNIXes 155 »   Sadly, AIX/ESA barely had any installations. It was a massive failure  because it suffered the dreaded fate of competing against a product  from the same vendor. This competition came from MVS/ESA V4R3's  OpenEdition feature, wherein MVS, the stalwart of mainframe operating  systems, had its own UNIX implementation. This system saw much  support, and since it came with MVS, sites that were merely trying to  stay with the latest version of MVS found themselves in possession of  a rather good UNIX environment for free.                  156 Mainframe History »   TPF AND ACP  TPF AND ACP  TPF AND ACP  TPF AND ACP  ___________    The history of TPF is almost synchronous with OS/360, and the  System/360 in general. In the early days of commercial computing,  there was a software system that IBM and American Airlines developed  called SABRE (Semi-Automated Business Research Environment). This was  intended to be a computerized replacement to the earlier way of manu-  ally handling airline reservations: before the dawn of computing,  airline ticket salespeople would sell seats on a flight, and would  then report to the departing city's airport how many seats were being  sold. If the plane was close to full, the head office would send a  message to the salespeople to stop selling any more seats. Seeing that  this was a problem, IBM approached American Airlines in 1953 and asked  for help. By the early 60s, the future was clear -- computers were  the answer.  SABRE: While IBM was working with American Airlines, they chose to  SABRE  SABRE  SABRE  start software development contracts with Pan- Am and Delta Airlines  too. As such, there were three airline reservation systems that IBM  was making in the early 1960s (before the S/360):  ź DELTAMATIC (ran on an IBM 7070), Delta Airlines  ź PANAMAC (ran on an IBM 7080), Pan-Am Airlines  ź SABRE (ran on an IBM 7090), American Airlines  In 1962, nobody had really figured out or perfected the craft of soft-  ware engineering and software development project management. As such,  the development of SABRE ended up being plagued by constant delays,  not to mention that IBM was (at the same time) working on similar  systems for two other radically-diffferent computers.  When SABRE was finished in 1964, it was the first online tranaction  processing system and the first large-scale data processing system  that wasn't owned by the US government. Raytheon built terminals that  attached to the host mainframe via telecommunications lines, and these  were placed in all of the serviced airports that American Airlines had  a presence in. In 1965, IBM finished DELTAMATIC and PANAMAC.  PARS: Seeing that IBM had made a poor decision to write three  PARS  PARS  PARS  radically-different airline reservation systems, IBM sought to unify  the customers' computing needs on the up-and-coming System/360 line --  this replacement program needed to run on a variety of models (with  the specifified range being the Model 40 through the Model 75; the  Model 65 was the most popular). This replacement software package  would be known as PARS: the Programmed Airline Reservation System.  _________________________________________  PARS was originally written to target midsized airlines, rather than  the giants discussed above. The development turnaround time on PARS   TPF and ACP 157 »   was amazing compared to that which came before it: in 1965, shortly  after the annoucement of the System/360 and on the tails of the ship-  ments of the first System/360s, PARS was made available to customers.  The first customer to adopt it was Eastern Air Lines, wherein they  named their install "System One" Later that year, the British Overseas  Airways Corporation chose to build a PARS installation (which they  named BOADICEA, as in, the ancient queen of England). Seeing that  England was a smaller country and would absolutely be making many  international flights, IBM updated PARS to support such features and  BOAC gained their IPARS system (the I was for International).  During that same timeframe from 1971 to 1973, American Airlines was  undergoing their migration off of SABRE and onto a PARS system (which  ran on several System/360 mainframes). Seeing that American Airlines  was having such good success with PARS, all but one of the ten major  US airline carrier companiess followed suit and adopted PARS.  Seeing that the hardware was evolving to the System/370 and different-  sized airlines were having good success adopting it, IBM split the  operating system component from the transaction processing component;  the OS became known as ACP (Airline Control Program) and PARS ran on  top of that.  ACP: In the early 1970s, the PARS systems were seen providing great  ACP  ACP  ACP  success to the companies that installed them. Fewer cancelled flights,  fewer delays, and more -- everyone was taking notice. Unlike the pre-  cursor SABRE system, the design of ACP/PARS was very forward-thinking.  ____  Rather than a centralized system, PARS/ACP was distributed!  distributed!  distributed!  distributed!  However, not everyone was content. With more money moving around in  that era, the big US banks looked upon the airline industry with envy.  They were getting more customers through the door than ever, and the  banks were a decade behind in computing software. In the early 70s,  the banks had adopted CICS and IMS for most of their transaction-  processing workload, but the performance left much to be desired.  The banks had a whole suite of online transaction-processing systems,  but their slow CICS/IMS systems were far from performance-competitive  with the airline computer systems. As such, they begged IBM to give  them a version of the PARS/IPARS transaction processing system, and  they delivered in 1975!  The "new" TPF system was full of interesting software innovations --  for example, the SabreTalk programming language (sometimes called  PL/TPF)! This language wsa produced in a three-way partnership between  IBM, American Airlines, and Eastern Air Lines. By 1973, Eastern Air  Lines was selling the SabreTalk compiler (for $95,000).  Eventually, that program would come to pass; British Airways was the  ______________________________________________________________________  last major user of SabreTalk programs comprising their Flight Oper-  ______________________________________________________________________  ations Computer System (FICO) under the ALCS system... except the pro-  ______________________________________________________________________  grams are compiiled by first transpiling to C (with a  ______________________________________________________________________  commercially-available compiler) and then compiling that C program.  ______________________________________________________________________   158 Mainframe History »   Delta Air Lines also used SabreTalk programs, but has been transi-  ______________________________________________________________________  tioning to C++ on TPF.  ______________________  TPF AND TPF/ESA: In 1979, IBM continued to genericify ACP into the  TPF AND TPF/ESA  TPF AND TPF/ESA  TPF AND TPF/ESA  Transaction Processing Facility (i.e. TPF). There were various ver-  sions of TPF, with TPF/ESA 4.1 being the last version that ran on  ESA/390 machines. Programs for TPF were predominately written in  assembler language.  TPF could run in both a tightly-coupled multiprocessing mode (i.e.  standard multiprocessor mainframes like the 3083), or loosely-coupled  mode across a network. For some reason, a single CPU within a TPF LPAR  is called an instruction stream or i-stream, and a machine with more  __________________  than one i-stream will be running tightly-coupled TPF. Several of  those systems could then be joined together loosely.  Of course, such computer systems require some kind of serialized  access to disks and other such devices. This is done by the Record  Hold Table, which implements spinlocks for synchronization within the  TPF OS nucleus. Of course, the DASD controllers themselves had a  record-locking facility, but one would have to get the LLF (Limited  Locking Facility) PRPQ or the ELLF (Extended Limited Locking  Facility); these two were eventually replaced by MPLF (Multipathing  Lock Facility) which could use the Coupling Facility.  Z/TPF: z/TPF 1.1 was released in September 2005; the new 64-bit  Z/TPF  Z/TPF  Z/TPF  support was nice, but the development model changed drastically.  Before z/TPF, one would cross-develop programs from MVS in assembly  language (or a specialized language like SabreTalk); once z/TPF was  released, this development model changed significantly. Instead of the  old development model in assembler, IBM provided a C-based development  model derived from the GNU development toolchain. IBM had spent much  effort improving the quality of the s390x port of GCC (for z/Linux);  with these improvements available and TPF's development model decades  obsolecent, IBM chose to make Linux the development platform!  _____  Programs that would run on z/TPF would actually be s390x-linux-gnu ELF  files, either compiled on z/Linux or later on PC Linux. If the pro-  grammer wishes to debug a TPF program, it is done so in a client-  server fashion. TPF itself doesn't come with a debugger, and the  programmer has to go buy a third-party debugger (like CMSTPF, TPF/GI,  or zTPFGI; alternatively, Step by Step Trace). IBM now provides a  debugger, running on a PC workstation, called TPF Toolkit -- this is a  modified version of Eclipse (as IBM is known for doing).  TPF provides some basic operating system constructs for tasks like  disk I/O and networking. TPF, naturally, supports both SNA and TCP/IP  networking; likewise, CKD DASD disks and tapes are supported. The TPF  operator's console is a 3270 terminal called the prime CRAS (a strange  __________  acronym, standing for Computer Room Agent Set); user terminals are  local 3270 or local SNA 3270 terminals (both operating modes of a  channel-attached 3x74).   TPF and ACP 159 »   Though I would love to write more, I do not have access to any TPF  systems or install media for it, but I hope this was an informative  writeup on this strange OS.                    160 Mainframe History »   IBM 9370: DPPX/370  IBM 9370: DPPX/370  IBM 9370: DPPX/370  IBM 9370: DPPX/370  __________________    DPPX has an interesting history; the Distributed Processing Executive  was first found on the IBM 8100 Information System in 1978. In 1986,  IBM eventually discontinued the decade-old 8100, and the last version  was DPPX/SP Release 4. Seeing the void, IBM ported DPPX to the  System/370 in a rather interesting successful project: in 1988,  launching with the IBM 9370, IBM unveiled the 8100's replacement.  DPPX is, as having an interesting history, also has a rather odd  architecture. The OS is written in a high-level-language called PL/DS  (PL/Distributed Systems), derived from PL/I. When DPPX was being  ported to the 370, PL/DS 2 also resulted; this was a necessary cre-  ation, since the PL/DS source for the 8100 was filled with inline  assembly and other such primitives.  Since DPPX was intended to be a distributed processing node on a  network of more systems of its kind, the OS was fully operable  remotely (and could be ran without operator intervention). Likewise,  the DPPX commands and dialogs were fitted with extensive online help;  the OS was certainly, for its time, extremely easy to use (compared to  something like VSE or MVS). Of course, these manuals were also avail-  able in print.  The original DPPX featured a key-lookup database, wherein a program  could look up a record by providing a key. At that point, the program  can traverse through the database forwards... but not backwards. Since  it took more CPU time to run the query over then seek backwards to the  right record given that key, application performance could decrease  quite a bit. DPPX/370 fixed this, but it was done in a rather odd  fashion: since the DPPX DBMS provided alternate keys, it would be pos-  sible for every key to have an alternate key that pointed to the pre-  vious record. The program would then select the alternate key, which  was just the binary 1's complement of the primary key. Reading the  next record in the returned data upon selecting that alternate key  would read the previous record associated with the primary key.  DPPX was a surprisingly complex system. The shell was the Host Command  Facility (HCF), and the Distributed HCF application allowed a user to  remotely log into a DPPX/370 system through a teleprocessing network  (inevitably SNA; DPPX/370 never gained TCP/IP support). Much like CICS  on MVS and VSE, DPPX/370 provided the Distributed Transaction Manage-  ment System (DTMS). The Distributed Systems Network Executive (DSNX)  allowed cross-system file sharing, something flashy and new in that  era.  DPPX/370 also provided language compilers for languages besides PL/DS,  those of which were COBOL and FORTRAN. Applications written in any  language that wished to provide full-screen user interfaces could use  the Command Facilities Extensions system, and users that wished to log   IBM 9370: DPPX/370 161 »   into remote mainframes (of the 370 variety) could use Data Stream  Capability (which functioned somewhat like PVM's 3271/3274 emulation).  Finally, there was a Performance Tool to monitor the system's resource  utilization.                   162 Mainframe History »   SOLARIS ON SYSTEM Z  SOLARIS ON SYSTEM Z  SOLARIS ON SYSTEM Z  SOLARIS ON SYSTEM Z  ___________________    Coming soon!                  Solaris on System Z 163 »   POPULAR MAINFRAME PROGRAMS  POPULAR MAINFRAME PROGRAMS  POPULAR MAINFRAME PROGRAMS  POPULAR MAINFRAME PROGRAMS  __________________________    In this section, let us explore some of the more famous mainframe  software products!   CUSTOMER INFORMATION CONTROL SYSTEM (CICS)  CUSTOMER INFORMATION CONTROL SYSTEM (CICS)  CUSTOMER INFORMATION CONTROL SYSTEM (CICS)  CUSTOMER INFORMATION CONTROL SYSTEM (CICS)  When it comes to most popular mainframe programs, CICS is easily a top  5. CICS is a transaction processing system, wherein small programs are  ran over and over (either under the control of a terminal or a network  service request); CICS also does file handling, terminal control,  database manager access, and (later) web support.  HISTORY: CICS was written shortly after OS/360 became mature enough  HISTORY  HISTORY  HISTORY  to host user-written (or, more accurately, IBM-written) programs. It  replaced an earlier program called the Minimum Teleprocessing Communi-  cations System (MTCS) that was written to run under OS/MFT, OS/VS1,  and DOS/VS. MTCS was not intended to be used for high-volume trans-  action processing, and, as such, was entirely singlethreaded; an unof-  ficial multithreaded version was written by IBM Littlewoods, but this  was made well after the heyday of MTCS (as a matter of fact, it was  intended to facilitate a MTCS-CICS bridge -- this was intended to be a  migration path off of MTCS). MTCS transactions were identified by  4-letter transaction codes, and the transaction code would be entered  on a terminal (originally a 2741, later 3270 displays near the end of  MTCS's life) to initiate the program.  CICS was developed in conjunction with the Michigan Bell company  starting in 1966 at IBM Des Plaines; the original target market was  the public utility industry. In 1968, IBM announced the first version  of CICS: the Public Utility Customer Information Control System, or  PU-CICS. When it became apparent that this program would have a  userbase outside of public utility companies, the PU was dropped. This  slightly-updated version was a program product, and was released in  conjunction with Information Management System (IMS) by July 8, 1969.  The basic gist of CICS was finished by 1969, but it didn't support  much (for instance, it only supported 2741 typewriter terminals  attached via a 2703). The first big adopter of CICS was Amoco  (Standard Oil of Indiana), who would eventually undertake rewrites of  major components of CICS. Amoco had tons of Teletype 33 ASR terminals  attached to 2703 ASCII ports, but CICS didn't support non-2741 termi-  nals initially; as such, programmers at IBM Des Plaines tried to add  support for popular third-party terminals of the day, but the team was  handicapped by a rather interesting limitation: they were so poorly-  funded (they weren't funded at all, actually) that they could not  afford $100 a month to rent terminals to test. This was compounded by  IBM management, constantly falsely stating that batch processing was  the future of computing and not timesharing/interactive   164 Mainframe History »   systems/virtual memory (see the aforementioned discussion around the  failures of IBM there)!  Seeing that IBM was less than helpful, the Amoco programmers opted to  make the support improvements happen themselves. They found out that  after starting CICS with IBM's untested non-2741 terminal support,  ________  OS/360 would just crash. As a response, Amoco programmers had to  rewrite the CICS Terminal Control Program!  CICS was eventually handed off to IBM Palo Alto, but it was seen as a  smaller and less-important product than IMS; by then, IMS had a trans-  action monitor, database manager, and things of that nature -- it was  certainly more technically-advanced than CICS, but not everyone wished  to adopt it (and many stuck with CICS, even to this day). IBM chose to  actually end CICS development in 1974 and tried to get everyone to  move to IMS, the IBM Hursley site (over in England) took over develop-  ment. They had just finished developing the PL/I compiler (only to  kick it off to some other IBM office) and were therefore familiar with  many of the CICS customers (due to most CICS customers writing trans-  actions in PL/I and COBOL).  By 1972, there were three versions of CICS available:  ź DOS-ENTRY: intended to run on DOS/360 machines that did not have  much memory  ź DOS-STANDARD: intended to run on DOS/360 machines that had more  memory (and could support application development)  ź OS-STANDARD: intended to run on the large OS/360 machines  CICS was updated gradually over time with several other versions; the  DOS/360 versions of CICS ultimately evolved into two major releases of  CICS:  ź CICS/VSE, the traditional CICS version for VSE/SP and newer ver-  sions  ź CICS Transaction Server for VSE, used to support CICS/ICCF on ver-  sions of VSE starting with VSE/ESA V2  The MVS CICS versions progressed through various versions, and were  updated to support virtual storage on OS/VS2 (CICS/VS), updated for  MVS/XA (CICS/MVS), and enhanced for MVS/ESA (CICS/ESA). When OS/390  was released, CICS/ESA became CICS Transaction Server, a name that  sticks to this day with z/OS. When z/OS did come out, CICS was updated  to support 64-bit programs.  OTHER CICS VERSIONS: There were a number of spin-off versions of  OTHER CICS VERSIONS  OTHER CICS VERSIONS  OTHER CICS VERSIONS  CICS, including:  ź CICS/VM: released in 1988, this was intended to provide a CICS  analogue for VM/CMS systems. This was not a real CICS subsystem,  and was instead a series of libraries that would run alongside   Popular Mainframe Programs 165 »   normal CMS program modules. This was intended to be a simplified  environment for converting CICS transactions over to interactive  CMS programs.  ź CICS for Windows NT and OS/2: intended for application development  and small customers, these programs were remarkably similar and  supported a client-server communication model (wherein CICS  clients provided 3270 displays to the CICS system; users could  also use TN3270 clients). VSAM file support was provided by  Btrieve, and it fully worked with Db2 connections.  ź CICS for AIX, HP-UX, Solaris, and DIGITAL UNIX: a UNIX conversion  of the CICS/NT and CICS/2 products, these products were intended  to be a step-up from the PC-based editions. The same client-server  and Db2 support was present.  ź TXseries, the updated name for the above two programs  ź CICS/400, a full CICS subsystem for OS/400 (IBM i) that interoper-  ated with the inbuilt OS/400 database (sometimes called Db2/400,  even though OS/400 itself was a database manager). Users would  open CICS sessions by running the STRCICS CL command.   ***DFH2312 WELCOME TO CICS/VS *** 19:24:44    CCCCCC IIIII CCCCCC SSSSSS VVVV VVVV SSS  CCCCCCCC IIIII CCCCCCCC SSSSSSSS VVV VVV SSSSS  CCCC CC III CCCC CC SSSS SS VVV VVV SSSS  CCC III CCC SSSS *** VVV VVV SSSS  CCC III CCC SSSS *** VVVVVV SSSS  CCCC CC III CCCC CC SS SSSS VVVVV SS SSSS  CCCCCCCC IIIII CCCCCCCC SSSSSSSS VVVV SSSSSSSS  CCCCCC IIIII CCCCCC SSSSSS VVV SSSSSS     Figure 40. CICS/VS 1.7.0 welcome screen (MVS/SP 1.3.4)    166 Mainframe History »   WELCOME TO CICS 18:26:37    ******\ ******\ ******\ ******\(R)  ********\ ******\ ********\ ********\  **\\\\**\ **\\\ **\\\\**\ **\\\\**\  **\ \\ **\ **\ \\ **\ \\  **\ **\ **\ *******\  **\ **\ **\ *******\  **\ **\ **\ \\\\**\  **\ **\ **\ **\ **\ **\ **\  ********\ ******\ ********\ ********\  ******\\ ******\ ******\\ ******\\  \\\\\\ \\\\\\ \\\\\\ \\\\\\     Figure 41. CICS TS 3.2.0 welcome screen (z/OS 1.5)            Popular Mainframe Programs 167 »   VSE/ESA CICSOLD 00:25:59    CCC IIII CCC SSS VVV VVV SSS EEEEEEE  CCCCC II CCCCC SSSSS VV VV SSSSS EE EE  CC CC II CC CC SS SS VV VV SS SS EE  CC II CC SS *** VV VV SS EEEEE  CC II CC SS *** VV VV SS EEEEE  CC CC II CC CC SS SS VV VV SS SS EE  CCCCC II CCCCC SSSSS VVV SSSSS EE EE  CCC IIII CCC SSS V SSS EEEEEEE     Figure 42. CICS/VSE 1.2 welcome screen (VSE/ESA 2.1.0)            168 Mainframe History »   VSE/ESA ONLINE 00:27:45    ******\ ******\ ******\ ******\  ********\ ******\ ********\ ********\  **\\\\**\ **\\\ **\\\\**\ **\\\\**\  **\ \\ **\ **\ \\ **\ \\  **\ **\ **\ *******\  **\ **\ **\ *******\  **\ **\ **\ \\\\**\  **\ **\ **\ **\ **\ **\ **\  ********\ ******\ ********\ ********\  ******\\ ******\ ******\\ ******\\  \\\\\\ \\\\\\ \\\\\\ \\\\\\ TM     Figure 43. CICS TS 2.3 welcome screen (VSE/ESA 2.4.0)            Popular Mainframe Programs 169 »   ######## ########## ###### ######  ######## ############ ####### #######  #### #### #### ####### #######  #### ######### ######## ########  #### ######### #### ####### ####  #### #### #### #### ##### ####  ######## ############ ##### ### #####  ######## ########## ##### # #####   CICS for OS/2 (*)  Version 3.1   94H5431(C) Copyright IBM Corp. 1988,1997. All Rights Reserved.  Portions (C) Copyright Pervasive Software Inc. 1997,1998.  All Rights Reserved.  (*) CICS and OS/2 are trademarks of IBM Corp.  Enter to continue.   Figure 44. CICS for OS/2 3.1 welcome screen (OS/2 Warp 4)  APPLICATION PROGRAMMING: CICS introduced a rather different method of  APPLICATION PROGRAMMING  APPLICATION PROGRAMMING  APPLICATION PROGRAMMING  application development. Initially, CICS used a library of assembler  macros for calling CICS services. This was called Macro-Level Program-  Macro-Level Program-  Macro-Level Program-  Macro-Level Program-  ____________________  ming.These looked like this sample assembler program that read a  ming.  ming.  ming.  _____  string from a terminal and then echoed it:          170 Mainframe History »   COPY DFHCSADS COPY CSA AND TCA SYMBOLIC STORAGE DEFS  COPY DFHTCADS  LENGTH DS H  MESSAGE DS CL32  COPY DFHTCTTE COPY SYMBOLIC STORAGE DEFINITIONS  COPY DFHTIOA  MYSTR DS CL32  CICSTEST CSECT  BALR 2,0  USING *,2  L 11,TCAFCAAA SET UP TCTTE AND TIOA ADDRESSABILITY  L 10,TCTTEDA  MVC MYSTR,=C'ENTER TEXT TO ECHO'  MVC TIOATDL,=H'18'  DFHTC TYPE=(WRITE,READ,WAIT,ERASE)  L 10,TCTTEDA  MVC LENGTH,TIOATDL SAVE INPUTTED LENGTH  MVC MESSAGE,MYSTR SAVE INPUTTED MESSAGE  DFHSC TYPE=GETMAIN,CLASS=TERMINAL,NUMBYTE=32 ALLOC MEMORY  L 10,TCASCSA  ST 10,TCTTEDA  MVC MYSTR,MESSAGE MOVE INPUTTED STRING TO OUTPUT  MVC TIOATDL,LENGTH MOVE LENGTH  DFHTC TYPE=WRITE WRITE STRING  DFHPC TYPE=RETURN EXIT PROGRAM  END  Figure 45. CICS macro-level sample program (assembler)  As you can see in the above example, there are a variety of macros for  various functions, such as:  ź DFHFC: file control  ź DFHTC: terminal control  ź DFHDI: batch data interchange  ź DFHIC: interval control  ź DFHKC: task control  ź DFHPC: program control  In addition, there are a variety of canned storage definition macros.  Now, one might ask, what about COBOL and PL/I? Well, these were sup-  __________________________  ported, but it was extremely primitive. Note that COBOL does not have  pointers like PL/I does, so a COBOL CICS macro-level program would  have to leverage the linkage section to actually do anything. Note  that the linkage section is normally used for communication between  programs (like passing parameters to subprograms), but this was crufty  and unergonomic.   Popular Mainframe Programs 171 »   Examine the following COBOL program that does the same thing as the  assembler program above:   IDENTIFICATION DIVISION.  PROGRAM-ID. CICSMCRO.  ENVIRONMENT DIVISION.  DATA DIVISION.  LINKAGE SECTION.  01 DFHBLLDS COPY DFHBLLDS.  02 TCTTEAR PIC S9(8) COMP.  02 TIOABAR PIC S9(8) COMP.  01 DFHCSADS COPY DFHCSADS.  01 DFHTCADS COPY DFHTCADS.  02 SAVE-LENGTH PIC S9(8) COMP.  02 SAVE-MESSAGE PIC X(36).  01 DFHTCTTE COPY DFHTCTTE.  01 DFHTIOA COPY DFHTIOA.  02 TIOAMSG PIC X(36).  PROCEDURE DIVISION.  MOVE CSACDTA TO TCASBAR.  MOVE CSAOPFLA TO CSAOPBAR.  MOVE TCAFCAAA TO TCTEAR.  MOVE TCTEDA TO TIOABAR.  MOVE 'ENTER MESSAGE TO BE ECHOED' TO TIOAMSG.  MOVE 26 TO TIOATDL.  DFHTC TYPE=(WRITE,READ,WAIT)  MOVE TCTTEDA TO TIOABAR.  MOVE TIOATDL TO SAVE-LENGTH.  MOVE TIOAMSG TO SAVE-MESSAGE.  DFHSC TYPE=GETMAIN,NUMBYTE=36,CLASS=TERMINAL  MOVE TCASCSA TO TIOABAR.  MOVE TIOABAR TO TCTTEDA.  MOVE SAVE-MESSAGE TO TIOAMSG.  MOVE SAVE-LENGTH TO TIOATDL.  DFHTC TYPE=WRITE  DFHPC TYPE=RETURN  GOBACK.  Figure 46. CICS macro-level sample program (COBOL)  This is not very easy to use, but it was the price the programmers in  the late 1970s paid. A PL/I program looks similar:      172 Mainframe History »   CICSMCRO: PROC OPTIONS(MAIN,REENTRANT);  %INCLUDE DFHCSADS;  %INCLUDE DFHTCADS;  2 SAVE_LENGTH BIN FIXED(15);  2 SAVE_MSG CHAR(36);  %INCLUDE (DFHTCTTE);  %INCLUDE (DFHTIOA);  2 TIOAMSG CHAR(36);  TIOAMSG = 'ENTER MSG TO BE ECHOED';  TIOATDL = 26;  DFHTC TYPE=(WRITE,READ,WAIT) TIOABAR=TCTTEDA;  SAVE_LENGTH = TIOATDL;  SAVE_MSG = TIOAMSG;  DFHSC TYPE=GETMAIN,NUMBYTE=36,CLASS=TERMINAL  TIOABAR = TCASCSA;  TCTTEDA = TIOABAR;  TIOAMSG = SAVE_MSG;  TIOATDL = SAVE_LENGTH;  DFHTC TYPE=WRITE;  DFHPC TYPE=RETURN;  END;  Figure 47. CICS macro-level sample program (PL/I)  This is certainly more readable than the COBOL version, but this is  still extremely cumbersome to write. As one might imagine, this would  eventually be replaced: this came with an update produced in the early  80s, and was known as Command-Level Programming.  Command-Level Programming.  Command-Level Programming.  Command-Level Programming.  __________________________  Rather than manually calling macros from high-level languages or  writing the program entirely in assembler, command-level programs  would use a variety of EXEC CICS statements -- these would, in turn,  be processed by some kind of precompiler (which one was invoked  depended on the language being used). The result of this was that  application development time fell significantly, as did user com-  plaints.         Popular Mainframe Programs 173 »   Examine the following sample COBOL program:  IDENTIFICATION DIVISION.  PROGRAM-ID. CICSHI.  ENVIRONMENT DIVISION.  DATA DIVISION.  WORKING-STORAGE SECTION.  01 WS-MESSAGE PIC X(40).  01 WS-LENGTH PIC S9(4) COMP.  PROCEDURE DIVISION.  BEGIN.  MOVE 'HELLO MVS CICS!' TO WS-MESSAGE  MOVE 15 TO WS-LENGTH  EXEC CICS SEND TEXT  FROM(WS-MESSAGE)  LENGTH(WS-LENGTH)  END-EXEC  EXEC CICS RETURN  END-EXEC  STOP RUN.  Figure 48. CICS command-level sample program (COBOL)  To translate this program, you would pass it through the DFHECP1$  program. The other translators are:  ź Assembler: DFHEAP1$  ź C: DFHEDP1$  ź COBOL: DFHECP1$  ź PL/I: DFHEPP1$  To run these procedures, one could do it by hand or by using a stored  procedure that came with CICS. There were many of these, and they were  as follows:        174 Mainframe History »   ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Table 11. |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | Ż Ż |  | Language | Non-LE | LE |  Language Non-LE LE  Language Non-LE LE  Language Non-LE LE  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | |  | Assembler | DFHEITAL (online), | (none) |  | | DFHEXTAL (batch) | |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | |  | C | DFHEITDL (online), | DFHYITDL (online), |  | | DFHEXTDL (batch) | DFHYXTDL (batch) |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | |  | C++ | (none) | DFHYITEL (online), |  | | | DFHYXTEL (batch) |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | |  | COBOL | DFHEITVL (online), | DFHYITVL (online), |  | | DFHEXTVL (batch) | DFHYXTVL (batch) |  ĐŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŻ  | | | |  | PL/I | DFHEITPL (online), | DFHYITPL (online), |  | | DFHEXTPL (batch) | DFHYXTPL (batch) |  żŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚš  ż ż  After the program was translated, compiled, and linked, it would need  to be defined to the system. This was conventionally done in the past  by updating the DFHPCT (program control table, which defines trans-  actions) and DFHPPT (processing program table) and re-assembling it.  By 1985, online resource definition was now possible; one could run  the CEDA transaction and define the transaction.  Another useful feature for application development was a function  known as Basic Mapping Support (i.e. BMS). This was an assembler-macro  Basic Mapping Support  Basic Mapping Support  Basic Mapping Support  _____________________  way of defining panels. CICS BMS maps were always cumbersome, obtuse,  and best left generated by some kind of generator; the most common  generator was IBM Screen Definition Facility II (SDF II), popular on  MVS and VSE.  Here is an example CICS BMS map source:         Popular Mainframe Programs 175 »   PRINT ON,NOGEN  LOGPNL DFHMSD TYPE=MAP,LANG=C,FOLD=UPPER,MODE=INOUT,STORAGE=AUTO, *  SUFFIX=  LOGMENU DFHMDI SIZE=(24,80),MAPATTS=(COLOR,HILIGHT),COLUMN=1,LINE=1, *  DATA=FIELD,TIOAPFX=YES,OBFMT=NO  DFHMDF POS=(1,1),LENGTH=1,ATTRB=(PROT,BRT)  DFHMDF POS=(1,76),LENGTH=4,INITIAL='LOGM',ATTRB=(PROT,BRT), *  COLOR=PINK  DFHMDF POS=(2,30),LENGTH=23,INITIAL='LogManager370 Main Menu',*  ATTRB=(PROT,BRT),COLOR=YELLOW  DFHMDF POS=(6,3),LENGTH=1,INITIAL='1',ATTRB=(PROT,BRT), *  COLOR=NEUTRAL  DFHMDF POS=(6,9),LENGTH=22,INITIAL='Add entries to logbook', *  ATTRB=(PROT,BRT),COLOR=TURQUOISE  DFHMDF POS=(8,3),LENGTH=1,INITIAL='2',ATTRB=(PROT,BRT), *  COLOR=NEUTRAL  DFHMDF POS=(8,9),LENGTH=25, *  INITIAL='Update entries in logbook',ATTRB=(PROT,BRT), *  COLOR=TURQUOISE  DFHMDF POS=(10,3),LENGTH=1,INITIAL='3',ATTRB=(PROT,BRT), *  COLOR=NEUTRAL  DFHMDF POS=(10,9),LENGTH=27, *  INITIAL='Remove entries from logbook',ATTRB=(PROT,BRT), *  COLOR=TURQUOISE  DFHMDF POS=(12,3),LENGTH=1,INITIAL='4',ATTRB=(PROT,BRT), *  COLOR=NEUTRAL  DFHMDF POS=(12,9),LENGTH=24, *  INITIAL='Query logbook statistics',ATTRB=(PROT,BRT), *  COLOR=TURQUOISE  DFHMDF POS=(14,3),LENGTH=1,INITIAL='5',ATTRB=(PROT,BRT), *  COLOR=NEUTRAL  DFHMDF POS=(14,9),LENGTH=34, *  INITIAL='Generate ADIF and store to dataset', *  ATTRB=(PROT,BRT),COLOR=TURQUOISE  DFHMDF POS=(16,3),LENGTH=1,INITIAL='6',ATTRB=(PROT,BRT), *  COLOR=NEUTRAL  DFHMDF POS=(16,9),LENGTH=4,INITIAL='Help',ATTRB=(PROT,BRT), *  COLOR=TURQUOISE  DFHMDF POS=(18,3),LENGTH=1,INITIAL='7',ATTRB=(PROT,BRT), *  COLOR=NEUTRAL  DFHMDF POS=(18,9),LENGTH=4,INITIAL='Quit',ATTRB=(PROT,BRT), *  COLOR=TURQUOISE  DFHMDF POS=(22,1),LENGTH=11,INITIAL='Option ===>',ATTRB=(PROT,*  BRT),COLOR=GREEN  * CHOICE CHOICE  CHOICE DFHMDF POS=(22,14),LENGTH=1,ATTRB=(UNPROT,NORM),COLOR=BLUE, *  HILIGHT=UNDERLINE  DFHMDF POS=(22,16),LENGTH=1,ATTRB=(PROT,NORM)  DFHMDF POS=(24,2),LENGTH=6,INITIAL='F3=End',ATTRB=(PROT,BRT), *  COLOR=BLUE  Figure 49. CICS BMS map sample   176 Mainframe History »   When assembled and displayed by a program using the EXEC CICS SEND MAP  command, it looked like this:   LogManager370 Main Menu   1 Add entries to logbook  2 Update entries in logbook  3 Remove entries from logbook  4 Query logbook statistics  5 Generate ADIF and store to dataset  6 Help  7 Quit   Option ===>  F3=End  Figure 50. Sample CICS map displayed on a 3270 terminal  Of course, CICS maps were dependent on the device. CICS supported many  terminals in its day, some of which weren't really traditional termi-  nals (like supermarket barcode scanners, RJE batch terminals, an audio  response phone communication device, and other such strange devices).  MODERN FEATURES: Over the course of the 90s and 2000s, CICS gained  MODERN FEATURES  MODERN FEATURES  MODERN FEATURES  many features that modernized it. These included the ability to call  CICS services from Java applications (all the rage in the late 90s),  REST API support (critical for the modern age), and a full CICS Web  subsystem that permitted a CICS region to function as a web server or  web client.  The web service functions are achieved through a tapestry of config-  uration options, and is certainly more than meets the eye at first.  For example, one can first prepare CICS to receive web client con-  nections by definining a TCPIPSERVICE, then give it a URIMAP to build  a list of URLs, then either allow it to serve static content from z/OS  UNIX files or generate dynamic content programmatically. If that seems  __  too basic, CICS can also dynamically generate HTML forms from BMS maps  (like those described above).  CICS APPLICATIONS: While there are more CICS applications that exist  CICS APPLICATIONS  CICS APPLICATIONS  CICS APPLICATIONS  than I could ever readily compose a writeup for, here are some influ-  ential early ones:   Popular Mainframe Programs 177 »   ź Source Program Maintenance Online II: SPMOL-II (with the worst  verbal name ever, "spimoli") was a circa-1970s online editor  _________  program that ran within CICS. Since OS/VS1 did not run TSO,  SPMOL-II provided the only good interactive editing facility that  OS had; the slated purpose of this program was not for general  text editing but explicitly for the development and maintenance of  source programs (as the name might imply; put simply, this was  written to be an online editor for COBOL, PL/I, and facilitate the  submission of JCL directly into the JES2 INTRDR in lieu of a card  deck).  ź STAIRS  ź ATMS III: an online administrative document processing subsystem,  ATMS evolved from the earlier ATS/360 (Administrative Terminal  System) and was designed as a successor to it that ran under CICS  (instead of doing everything itself: ATS/360 did all disk I/O by  directly executing channel programs). To facilitate the formatting  of documents, IBM SCRIPT/VS ran under ATMS III and could save to  files and/or spool to printers.  ź GDDM: while not strictly a CICS program, the Graphical Data  Display Manager provided graphics support for 3270 terminals that  supported graphics as well as a whole barrage of AFP and similar  (like PostScript) printers. The base GDDM applications minus  GDDM-OPS (the Online Presentation System), as well as most user-  written programs, could run under CICS.   GDDM  GDDM  GDDM  GDDM  The blurb directly above this describes GDDM in passing, but the  Graphical Data Display Manager provided a true graphics subsystem for  the mainframe. Gone were the days of text-only graphics and printouts,  this new program from 1988 made everything much more colorful and  artistic. There were a number of programs shipped with a full instal-  lation of GDDM:  BASE GDDM COMPONENTS: The basic GDDM package contained a series of  BASE GDDM COMPONENTS  BASE GDDM COMPONENTS  BASE GDDM COMPONENTS  library routines, copyfiles/headers/macros, and examples for various  programming languages. One of those was the GDDM-REXX interface, which  expedited application development. GDDM applications could be written  pretty easily by using simple commands not unlike the commands for  graphics seen on old 8-bit home computers that ran BASIC from a ROM;  this example C program would draw a basic screen and capture mouse  input from the light pen (or mouse, if displayed on a 3270 emulator  like PCOMM):     178 Mainframe History »   #include  #include  #include   int main() {  int dtype, devid, segid, symbid;  fsinit();  gssati(1,1);  gsseg(5);  gscm(3);  gscb(10.0, 10.0);  gsmove(1.0, 90.0);  gstag(1);  gschap(1, "#");  gstag(2);  gschap(2, "#");  gsenab(3, 1, 1);  gsread(1, &dtype, &devid);  gsenab(3, 1, 0);  gsqpik(&segid, &symbid);  fsterm();  printf("picked segment id: %d, symbol id: %d\n", segid, symbid);  return 0;  }  Figure 51. GDDM C program that draws a demo menu  (thanks Vinatron for the program)  _________________________________  As one might imagine, GDDM found itself used for many programs that  required any and all graphics!  GDDM-ICU: The ICU, or the Interactive Chart Utility, provided a sim-  GDDM-ICU  GDDM-ICU  GDDM-ICU  plistic way of generating charts on a mainframe. Data can easily be  imported and exported in a simple tabular format (and, of course,  edited on the spot). All manner of standard charts were supported, and  this program was often used in conjunction with a page printer (loaded  with transparencies) to produce presentation slides.  Charts would often look something like this:   Figure 52. GDDM-ICU chart  GDDM-IVU: Intended to work with the 3193 portrait display and  GDDM-IVU  GDDM-IVU  GDDM-IVU  scanner, the Image Viewer Utility provided a scanner and image display  utility for ADMIMG-format pictures. Since no printer natively sup-  ported ADMIMG files and one might wish to preview monochrome graphics  for inclusion in DCF/BookMaster documents later, this program can load  and save AFP page segment files.    Popular Mainframe Programs 179 »   GDDM-OPS: In the past, Microsoft PowerPoint was not really a thing;  GDDM-OPS  GDDM-OPS  GDDM-OPS  as such, producing slides for a presentation was much more difficult.  Originally, presentation slides were hand-drawn or hand-typeset  directly onto transparency slides, but these were not the same as the  presentations we would later come to see dominate every business  meeting ever -- producing printed text was a rather cumbersome ordeal,  and usually involved expensive typesetting equipment and the like.  Certain people realized that you could use graphics systems from tele-  vision to produce slides, but they were of poor resolution (since  television was limited to about 480 lines in this era); Genigraphics  was the first to produce a widely-adopted computer whose job was  graphic design (and these were quickly used to produce presentation  slides onto transparencies).  In the mid-80s, IBM decided they would try to take their hand at  producing a competitor to the popular Genigraphics computers. IBM had  already been working on GDDM (as seen above), and some 3270-compatible  terminals (and, of course, PCs running 3270 emulators) could drive  "video projectors" to illuminate a projection screen.(1)  GDDM Online Presentation System leveraged the then-new advanced  graphics features of the 3270 line (see the section in the first half  of this book on the 3179-G) to render beautiful presentation slides  for display on a terminal, printing with a printer (this output could  then in-turn be photographically transferred onto slides), or on  several terminals (provided that OPS was being ran on VM). OPS sup-  ported MVS and VM, and used a rather odd command language:         ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  (1) A video projector is what we would nowadays refer to as just a  "projector"; this is in contrast with a film projector or slide  projector, which were more common in the mid-to-late 80s   180 Mainframe History »   )ops prefix !; reset; trc off  )ops dark; aspect 100 67; reset  ! * draw the red line  !line 2 65.4 83 w 1.2 dr r  !mix on  !rays 88 62.5 7 dr r  !rays 92 62.5 7 dr g  !rays 96 62.5 7 dr b  !text 'z/OS' cc 92 62.5 ss admuukso h 5 sh 15 col w  !mix off  ! * The next line is the chart heading. Uses admuuhi as the symbol set  ! * is drawn in red, with a height of 7.8.  !text 'Objectives' 1 57.0 ss admuuhi col r h 7.8  ! * set the symbol set, color and height for the bullet text  !ss admuuh; col y; h 5  ! * start the bullets at x=6, y=47  !start 6 47  ! * ensure text wraps at edge  !tf xmax 95  ! * start the 'unordered list'  !tful psp .4l  ! * and now the bullet text. add/delete bullets as necessary  !tfli Figure out how to run SQL statements  !tfli Write a program  !tfli Precompile/compile/link/bind/run it  !tfli Show interactive and batch program prep  !tfli Memorize JCL  !tfli Write CICS and Db2 application  !tfeul  Figure 53. Example GDDM-OPS presentation  When processed, OPS presentations could look like this:   Figure 54. GDDM-OPS presentation (extracted using GDFSAVE)  OPS stopped being updated in 1993 as Microsoft PowerPoint displaced it  (and other earlier presentation packages, like Harvard Graphics on  MS-DOS), but it continued to be available in most GDDM installs (and  is even still available to this day).  Usage requires either a real 3270 terminal with vector graphics  support, or a 3270 terminal emulator with graphics (out of the scope  of this document, but IBM Personal Communications i.e. PCOMM is  ideal).  GDDM-ISE AND GDDM-VSE: Not to be confused with the operating system  GDDM-ISE AND GDDM-VSE  GDDM-ISE AND GDDM-VSE  GDDM-ISE AND GDDM-VSE  of the same name, the Vector Symbol Editor is used to create custom  vector symbols (i.e. vector fonts) and the Image Symbol Editor is  used for creating bitmapped fonts. These can be used by user-written  GDDM programs, GDDM-OPS, or GDDM-ICU.   Popular Mainframe Programs 181 »   SCRIPT/VS  SCRIPT/VS  SCRIPT/VS  SCRIPT/VS  SCRIPT is a program derived from one of the earliest programs ever  written for a computer: RUNOFF. This was a program that ran on, of all  _______  platforms, CTSS; it provided a basic text formatting function that  pagination and justification. The original RUNOFF was written in MAD  in 1964; by 1967, it had been rewritten in BCPL and was bought over to  Multics.  In 1968, at the peak of CP-67's development at Lincoln Labs, IBM con-  tacted Stuart Madnick (at MIT) to produce a simple document formatter  that would run under CP-67's CMS. This program was modelled by its  author after the CTSS RUNOFF program (seeing that CTSS and its popular  programs were a memory still hot on the mind of the early CP-40 and  CP-67 users/developers), and was compatible. Since this was the late  60s and early 70s, this version of SCRIPT was not terrifically useful;  it supported typewriter terminal and line printer output only.(2)  This program was ported over to OS/VS TSO; this version was ported by  William Dwyer (Yale University) in 1974. Shortly thereafter, several  students at the University of Waterloo became disappointed by the lack  of features afforded to them by this NSCRIPT program, and rewrote it  as Waterloo SCRIPT (i.e. WSCRIPT).  WSCRIPT  WSCRIPT  WSCRIPT  WSCRIPT would continue to be updated, and worked on MVS, CMS, and  MUSIC -- the MUSIC version was used to format the manuals for that  operating system into PDFs (by way of outputting PostScript).  What is more interesting is IBM's development of SCRIPT. By 1978,  their own rewrite of SCRIPT had been updated so substantially that it  began to gain support for more and more line printers -- it had gained  the ability to output a FORTRAN carriage control listing, which per-  mitted the printing of various paper sizes, bold and underlined text,  and strikeout text. This program was renamed to the Document Composi-  __________________  tion Facility, and it ran under the big three mainframe OSes (MVS, VM,  _____________  VSE).  DCF supported the then-new IBM 3800 Printing Subsystem (which intro-  duced a greatly-advanced printer data stream); in the mid-80s, DCF 3.0  gained support for the newly-introduced Advanced Function Printers  (the most popular of which was the IBM 3820) which supported full  graphics printing!  SCRIPT was used with several custom macro packages, but IBM put out  two major ones:   ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  (2) Typewriter terminal output would have been done likely on an IBM  2741-style terminal; you would eject your cheap paper used for  your login session, load some nicer paper, hit enter at the prompt  after invoking SCRIPT that prompted you to load that paper, and  wait on the printout to grow.   182 Mainframe History »   ź GML (Generalized Markup Language) Starter Set  GML is an interesting language, because it is the direct source  for SGML (Standardized GML) and, by extension, XML and HTML! The  GML package that came with DCF was called the GML Starter Set, and  it included a large library of macros for automating the pro-  duction of various document elements (title pages, tables of con-  tents, footnote lists, etc).  ź BookMaster  BookMaster, of which this document is actually composed in, is a  _______________________________________________  superset of the GML Starter Set macros that may or may not be used  in conjunction with BookManager, a program used to produce online  BookManager  BookManager  BookManager  books that could either be printed (of course, by running the  input source straight through DCF/SCRIPT with BookMaster  installed) or displayed online with a 3270 terminal! BookManager  and BookMaster are technically two different programs, but are  heavily related on account of this.  Over the years, IBM DCF/SCRIPT gained support for quite a number of  output devices, including:  ź Terminals: 3270 and 2741  ź Line printers: 1403, 3800 (a laser printer, but treated like a  line device in this mode)  ź AFP page printers: 3800-3, 3820, 4250, 3812, 4224, 4028  ź PostScript printers  All of these output devices had several variations for several paper  sizes.   OFFICEVISION/VM  OFFICEVISION/VM  OFFICEVISION/VM  OFFICEVISION/VM  Note: before reading this, read the PROFS section in the VM chapter!  Note: before reading this, read the PROFS section in the VM chapter!  Note: before reading this, read the PROFS section in the VM chapter!  Note: before reading this, read the PROFS section in the VM chapter!  ____________________________________________________________________  OV/VM 1.1 AND 1.2: OfficeVision/VM was an evolution of PROFS, but  OV/VM 1.1 AND 1.2  OV/VM 1.1 AND 1.2  OV/VM 1.1 AND 1.2  intended to function alongside PCs. When OV/VM 1.1 was announced on  May 16 of 1989, PCs running DOS (and sometimes OS/2) were in plentiful  supply -- these usually ran some kind of host connection program like  Communications Manager/2 or Personal Communications, but could just as  easily run a front-end to OV/VM. The "OS/2 Office Feature" provided  this feature on OS/2, and the DOS Office Direct Connect Feature pro-  vided it for DOS. OV/VM 1.1 included extended DisplayWrite/370  support, since it was presumed that this would be the dominant word  processing system; it ended up indeed being the dominant document  system for many businesses for quite a while!    Popular Mainframe Programs 183 »   PC users that needed to send a fax could use the Office Facsimile  Application, but this program required an external fax server in order  to send and receive the documents.(3)  OV/VM 1.1 released in December 1989, and OV/VM 1.2 released in March  1990. Throughout its life, OV/VM supported a number of extra programs:  ź DisplayWrite/370, a full-screen word processor that used  RFT-format files(4)  ź AS (Application System), an application development and exeution  engine sometimes used to write business applications in the era  OV/VM was popular  ź DCF (Document Composition Facility, i.e. SCRIPT), for formatting  typeset documents without the usage of DisplayWrite/370  ź ISPF/VM, used to display the OV/VM administration dialogs, some  user panels (like the one used to generate author profiles), the  DOS Office Direct Connect dialogs, the Control File Aids (settings  editors), and the PROFS database split/merge/transfer functions.  ź RSCS, used for networking OV/VM systems together  ź Host-Displaywriter Document Interchange (HDDI), a program that  converted DCF documents to and from RFT format.  ź GDDM, if users wanted to store images in documents  OV/VM supported extensive inter-system communications with both RSCS  support for email and remote calendars, as well as full APPC/VM  support for remote calendars, mailboxes, and distribution managers.      ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  (3) In this era (the late 80s), modems that could send and receive  faxes were extremely rare and expensive; it would not be till the  late 90s when every modem ever could do so  (4) RFT is Revisable Form Text, and is unrelated to Microsoft's Rich  Text Format (RTF); many PC word processors (including WordPerfect,  Microsoft Word, Ami Pro/Lotus Word Pro, etc) could load and save  RFT files.   184 Mainframe History »   OfficeVision/VM Main Menu A0  Press one of the following PF keys.  PF1 Process calendars Time: 4:16 PM  PF2 Open the mail  PF3 Find documents 1926 JANUARY 1926  PF4 Process notes and messages S M T W T F S  PF5 Prepare documents 1 2  PF6 Process documents from other sources 3 4 5 6 7 8 9  PF7 Process the mail log 10 11 12 13 14 15 16  PF8 Check the status of outgoing mail 17 18 19 20 21 22 23  24 25 26 27 28 29 30  PF10 Add an automatic reminder 31 Day of Year: 011  PF11 View main menu number 2  5684-084 (C) Copyright IBM Corp. 1983, 1989 PF9 Help PF12 End  ------------------------------------------------------------------------------    ===>  Figure 55. OfficeVision/VM 1.1 Main Menu   PROCESS CALENDARS  Calendar for: System Administrator  -----------------------------------  Calendar date: 01/11/26  ------------------ Time: 9:09 PM  Press one of the following PF keys. 2026 JANUARY 20  S M T W T F  PF1 Work with the day's schedule 1 2  PF2 View 7 days of the calendar 4 5 6 7 8 9  -- 11 12 13 14 15 16  PF3 View the conference room schedules 18 19 20 21 22 23  PF4 Work with the next day's schedule 25 26 27 28 29 30  PF5 Work with the previous day's schedule Day of Year:  PF6 View the month  PF7 Schedule a meeting  PF8 Print 7 days of the calendar  --  PF10 View calendar main menu number 2   PF9 Help PF12 Return  Figure 56. OV/VM 1.1 Calendar   Popular Mainframe Programs 185 »   LIST OF AVAILABLE DOCUMENT STYLES  Press the PF key for the document style you want.  PF1 STANDARD This is an RFT interoffice memo.  PF2 DISTLIST This is an RFT memo beginning with "To: Distribution".  PF3 BUSINESS This is an RFT formal letter to send outside your company  PF4 STANDDCF This is a DCF interoffice memo using the memo prompter.  PF5 DISTDCF This is a DCF memo beginning with "To: Distribution".  PF6 BUSDCF This is a DCF formal letter to send outside your company.  PF7 BLANK This is an empty RFT format file.  PF8 MEETING This is a DCF interoffice meeting notice.   Screen 1 o  PF9 Help PF10 Next Screen PF11 Previous Screen PF12 Return  ===>  Figure 57. OV/VM Document Style Choice Menu            186 Mainframe History »   9 RFTD A5 PROMPT  ** Prompt: Type addressee:  ===>  <---+_---1_---+_---2_---+_---3_---+V---4_---+_---5_---+_---6_---+_---7_>  ------------------------------------------------------------------- Page  January 11, 1926 Draft 9  P. R. ADMINISTRATOR , 222-222-2222  LARGE CO.  TECHNICAL  BUILDING 55  WASHINGTON, DC 222222  SYSADMIN/VMESA12   Memo to:  Subject:  Reference:   PF 1=Block 2=Insert 3=Cmdline 4=Instr. 5=Tspell 6=Ai  PF 7=Next 8=Command 9=HELP 10=Forward 11=Backward 12=EN  Figure 58. OV/VM DisplayWrite/370 Memo Prompter  OV/VM 1.2 (April 24, 1992) added some pretty serious improvements; the  most meaningful improvement was the introduction of the new OVMAIL  facility, a totally-rewritten user interface that greatly increased  user productivity with emails.          Popular Mainframe Programs 187 »   ML00 OfficeVision/VM Mail Items 1 to  Type / or an action next to an item and press Prompt or ENTER.  --Name-- --Type-- M- --Blocks-- --Date-- ---------Description------  _____ In-basket  _____ Non-OV/VM Mail  _____ Document Log      Personal Storage is 01% full (8 of 900 blocks).  Command ===>  F1=Help F2=Keys F3=Exit F4=Prompt F5=Refresh F6=TopBot F7=Backward  F8=Forward F9=Retrieve F10=Sort F11=Find F12=Cancel  Figure 59. OV/VM 1.2 OVMAIL Menu  ESA CALENDAR FEATURE: Before OfficeVision/VM Release 3 was announced  ESA CALENDAR FEATURE  ESA CALENDAR FEATURE  ESA CALENDAR FEATURE  and made available, an interesting enhancement was made available in  October 1993: the ESA Calendar Feature. This was a massive upgrade to  _____________________  the earlier and more primitive OV/VM calendar (which had not meaning-  fully evolved since PROFS 2.11)! The product announcement provides a  rather quaint list of enhancements this new calendar had:  ź Improved calendar performance and capacity, especially related to  the calendar search function; it was now handled client-side (on  the user virtual machine) in lieu of deferring the search opera-  tion to the calendar manager service machine  ź Exploitation of VM Data Spaces, allowing for faster calendar oper-  ation if all of the calendar servers in a distributed arrangement  (under one VM system) run with XC-mode CMS  ź Usage of 31-bit CMS addressing, permitting for calendars that may  spill over 15 MB  ź Ability to use SFS for calendar storage, previously not possible  with the earlier calendar  ź Allows for distributed calendar processing across several calendar  servers    188 Mainframe History »   ź The protocol between the client and the server is now fully docu-  mented, allowing for all manner of custom applications to be  written  ź Supports a laundry list of network protocols:  Ś APPC/VM  Ś IUCV  Ś RSCS  Ś CPI Communications  ź Backwards-compatible with earlier user-written (in assembler)  OV/VM calendar exits  One might ask why my description of this ESA Calendar Feature is so  lengthy, and it is due to the obvious amount of work that was placed  into it: it is clear that a skunkworks group made this highly-advanced  program!   CW00 Process Calendars  Calendar for W. E. C____________________________  Date. . . . . 01/11/26 Sunday  Select one of the following. Then press Enter. Time: 8:58 PM EST  1_ 1. Work with the day's schedule 2026 January 2026  2. View 7_ days of the calendar S M T W T F S  3. View the conference room schedules 1 2 3  4. Work with the next day's schedule 4 5 6 7 8 9 10  5. Work with the previous day's schedule 11 12 13 14 15 16 17  6. View the month 18 19 20 21 22 23 24  7. Schedule a meeting 25 26 27 28 29 30 31  8. Print 7_ days of the calendar Day of Year: 11  9. View the business week  10. View six month calendar  11. Manage list of authorized users  12. Search facility  13. Add company holidays  CCL000I (C) Copyright IBM Corporation 1993. All Rights Reserved  Command ===>  F1=Help F2=Options F3=Exit F10=Next month F11=Previous month F12=Cancel  Figure 60. OfficeVision/VM 1.3 ESA Calendar Feature  CALLUP: An aptly-named program, CallUp was a phone directory program  CALLUP  CALLUP  CALLUP  that was very often seen alongside OV/VM. Some of the very large OV/VM  systems made heavy use of CallUp, and IBM themselves used it for far  longer than most people would consider its useful life to be!   Popular Mainframe Programs 189 »   File Distribute Inquire Options Help  ________________________________________________________________________  Search Request  To request a search, type the search data and press Enter.  Lines 1 to 14  Corporate and Personal Directories  Name . . . . . . . . .  Search Location(s) . . =SAMPLE  Department . . . . . .  User ID . . . . . . . .  Node ID . . . . . . . .  Manager . . . . . . . . 1. Yes  2. No  Telephone Extension . .  Additional Data . . . .  Services Directory  (C) Copyright IBM Corporation 1988, 1992. All rights reserved.  Command ===>  F1=Help F2=Set 2 F3=Exit F4=Profile F5=Refresh F6=Fuzzy search  F7=Backward F8=Forward F9=Command F10=Actions F11=Dist list F12=Can  Figure 61. CallUp Main Menu  RELEASE 3, 4, AND THE END: OV/VM 1.3 was announced on June 11, 1996,  RELEASE 3, 4, AND THE END  RELEASE 3, 4, AND THE END  RELEASE 3, 4, AND THE END  and included an updated ESA Calendar Feature. This release was not  very complex, but the following things were added:  ź Usage of VMSES/E  ź Retention Management System (old documents can now be auto-purged)  ź Support for remote in-baskets and remote conference room sched-  uling added  ź Added SMTP support  ź Proofreading added(5)  ź Time zone support added to the ESA Calendar Feature  ź OVMAIL facility now integrated into the base  OV/VM Release 4 (announced November 18, 1997) was the final version of  the PROFS line, and the stated purpose of this release was full Y2K   ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ  (5) The OV/VM proofreader is derived from an IBM program that was  never officially released called PROOF   190 Mainframe History »   compliance; in addition, numerable changes and enhancements were  added:  ź The OV/VM user code saved segment is now relocatable above 16 MB,  allowing for the base OV/VM program (and not just the ESA Calendar  Feature) to feature full 31-bit addressing  ź The user A-disks can now be in SFS (somehow, this was not per-  mitted with older OV/VM releases); filesystem permissions are  fully integrated too  ź The database/calendar/mailbox/distribution managers can now run  arbitrary CMS commands from their consoles  ź MIME emails are now supported when received through SMTP  ź Users can now postpone (and save) a note, to work on it later  ź The NOTIFY command has been improved  ź The RECALL command has been improved (this command allows you to  un-send mail)  ź The OVMAIL note editor has been rewritten and substantially  improved   STANDALONE UTILITY PROGRAMS  STANDALONE UTILITY PROGRAMS  STANDALONE UTILITY PROGRAMS  STANDALONE UTILITY PROGRAMS  Throughout the history of mainframes, there were several notable  standalone utilities used for maintaining the system. Here is a  selection of some of them:  DEVICE SUPPORT FACILITIES (ICKDSF): Device Support Facilities (ICK is  DEVICE SUPPORT FACILITIES (ICKDSF)  DEVICE SUPPORT FACILITIES (ICKDSF)  DEVICE SUPPORT FACILITIES (ICKDSF)  just the prefix) is a program that is used to format and initialize  DASDs. This program ran under MVS, VM, VSE, AIX/370/ESA, and possibly  others; Linux, Solaris, MUSIC, MTS, and TPF users would have to run  the standalone version described here. This was normally loaded from a  tape, and it would wait for an interrupt from some kind of  console/terminal device after IPLing. You would do that by pushing an  attention key on a 3270, 3215, or possibly others. Once the messages  appeared, you could use it.  ICKDSF was sometimes wrapped by a program called CPFMTXA on VM; in the  early days, this program was called Format/Allocate.      Popular Mainframe Programs 191 »   ICK005E DEFINE INPUT DEVICE, REPLY 'DDDD,CUU' OR 'CONSOLE'  ENTER INPUT/COMMAND:   ICK006E DEFINE OUTPUT DEVICE, REPLY 'DDDD,CUU' OR 'CONSOLE'  ENTER INPUT/COMMAND:   ICKDSF - SA DEVICE SUPPORT FACILITIES 11.0B TIME: 1  11/20/25 PAGE 1  ENTER INPUT/COMMAND:  end  END     VM READ VMSP5  Figure 62. Standalone ICKDSF  VM FORMAT/ALLOCATE (DMKFMT): This program was used in the VM/370 era  VM FORMAT/ALLOCATE (DMKFMT)  VM FORMAT/ALLOCATE (DMKFMT)  VM FORMAT/ALLOCATE (DMKFMT)  to, after initializing DASDs with ICKDSF, would lay out the disks for  VM CP. You would allocate the following kinds of space with it:  ź PERM: used to store minidisks  ź DRCT: used to store the system directory  ź PAGE: paging space  ź SPOL: spooling space  ź PARM: used to hold parm disks (VM/XA only, CPFMTXA)  This program was eventually replaced by a successor seen on VM/XA:  CPFMTXA. This program was ran from CMS, and did not run standalone; if  you needed to perform these functions standalone, you would actually  use ICKDSF's CPVOL command!  In the VM/370 era, you would run this program (most likely) by IPLing  it from a virtual machine's card reader with the DASD you wished to  format attached to said VM.  VM STANDALONE DIRECTORY CREATION UTILITY (DMKDIR): This program does  VM STANDALONE DIRECTORY CREATION UTILITY (DMKDIR)  VM STANDALONE DIRECTORY CREATION UTILITY (DMKDIR)  VM STANDALONE DIRECTORY CREATION UTILITY (DMKDIR)  exactly what the name implies: it loads from a card reader, and is  followed by a deck containing a VM directory. This would be used   192 Mainframe History »   during a VM/370 or VM/SP tailored installation procedure or cross-  system generation, which would involve and necessitate the creation of  a system directory. The filename was "IPL DIR"  STANDALONE I/O CONFIGURATION PROGRAM (SA IOCP): While not strictly a  STANDALONE I/O CONFIGURATION PROGRAM (SA IOCP)  STANDALONE I/O CONFIGURATION PROGRAM (SA IOCP)  STANDALONE I/O CONFIGURATION PROGRAM (SA IOCP)  program one might would load from a reader or something similar, the  SA IOCP program is critical to any mainframe. Since mainframes since  the System/370 era (this list would include the 370/XA machines) no  longer use a hardwired logic method of I/O configuration and channel  assignment, it became necessary to define some kind of I/O configura-  tion file. Naturally, these looked something like this:   CHPID PATH=04,TYPE=CNC  CTLUNIT CUNUMBR=400,PATH=(04),UNIT=3990,UNITADD=((00,256),CUADD=0  IODEVICE ADDRESS=(400,16),CUNUMBR=400,UNIT=3390,UNITADD=0,STADET=Y  Figure 63. Sample IOCP definitions for a 3390  This snippet here does the following things per each line:  1. Defines an ESCON (CNC) channel on channel path ID 4.  2. Defines a 3990 (CKD DASD) control unit on CHPID 4 with 256 maximum  devices attached to it. This CU is at address 400.  3. Defines 16 3390 DASDs, starting at device address 400 (technically  unrelated to the CTLUNIT's CU number), attached to the controller  with CU number 400 (that's the DEVICE -> CTLUNIT linkage).  In order to "cook" this into a working IOCDS dataset that the  mainframe CPU loads during the power-on-reset phase of the IPL, one  must either run the IOCP programs on the various OSes (IOCP programs  are known to have existed for MVS/ESA, VM/ESA, VSE/ESA, and AIX/ESA,  as well as their more modern counterparts), or run the standalone  __  IOCP!  The SA IOCP program is not loaded like a normal standalone program  might be (like from a reader or a tape), but instead loaded directly  from the SE. Under CPC Customization, there is an option for config-  uring I/O devices -- dragging the group icon onto that icon will open  a dialog showing several options of known IOCDS datasets and IOCS  sources (an IOCDS is a "processed" version of an IOCS source file) and  the option to edit an IOCS is provided. After an edit, you would  choose the option from the menu at the top left to build an IOCDS  dataset. Once that is done, the mainframe can be re-powered-on with  the new IOCDS (since you are prompted which one you want to load  during the power-on procedure). The SA IOCP program itself does run on  the S/390 or System Z CPU, but is stored as a memory image.  DASD DUMP/RESTORE (DMKDDR): DDR is one of the classic programs seen  DASD DUMP/RESTORE (DMKDDR)  DASD DUMP/RESTORE (DMKDDR)  DASD DUMP/RESTORE (DMKDDR)  from VM, and is often used by systems programmers to migrate DASDs  between system by way of first dumping them on tape. DDR is a simple  program that asks for an input and output device -- these devices can   Popular Mainframe Programs 193 »   be disks or tapes. It can also copy DASDs by specifying two DASDs for  the input and output devices. Otherwise, it will dump to tape or  restore from tape.  The tape format can be one of the following options, all similarly-  named:  ź Mode Compacted (MODE COMP), wherein compression is done by the  tape drive itself; this is the 3480 IDRC or 3490E IDRC enablement  option, but works for other tapes. This is specified on the output  device like "OUTPUT 590 3490 (MODE COMP."  ź Compacted, wherein DDR does software compression, specified before  any MODE options with the COMP.  ź LZMA compaction, wherein DDR uses the LZMA compression instruction  of an S/390 G6 or newer -- this is specified with the LZCOMP  option.   ddr  VM/ENTERPRISE SYSTEMS ARCHITECTURE DASD DUMP/RESTORE PROGRAM  ENTER:  input 100 dasd  ENTER:  output 200 dasd  ENTER:  copy all  HCPDDR716D NO VOL1 LABEL FOUND  DO YOU WISH TO CONTINUE? RESPOND YES, NO OR REREAD:  yes  HCPDDR716D NO VOL1 LABEL FOUND  DO YOU WISH TO CONTINUE? RESPOND YES, NO OR REREAD:  yes  COPYING  END OF COPY  ENTER:  END OF JOB  PRT FILE 0220 SENT FROM WEC PRT WAS 0220 RECS 0006 CPY 001 A NOHOLD  Ready; T=0.01/0.10 10:50:51   VM READ EVIEVM  Figure 64. Example DDR run (copying a DASD)  OS DASD INITIALIZATION (IBCDASDI): Hailing from the OS/360 era,  OS DASD INITIALIZATION (IBCDASDI)  OS DASD INITIALIZATION (IBCDASDI)  OS DASD INITIALIZATION (IBCDASDI)  IBCDASDI was a much more cumbersome way of doing tasks that would  later be performed by ICKDSF. The input jobstreams were rather convo-  luted:    194 Mainframe History »   DINIT1 JOB 'INITIALIZE AN EXAMPLE DASD UNDER VM'  MSG TODEV=1052,TOADDR=009  DADEF TODEV=3380,TOADDR=100,IPL=NO,VOLID=TEST01,BYPASS=YES  VLD NEWVOLID=TEST01,OWNER=DEMO  VTOCD STRTADR=1,EXTENT=5  END  Figure 65. Example IBCDASDI jobstream  Naturally, one would need to IPL this program and tell it which input  device to use with a terminal input like "input=1442,00c." After that,  the program will read the above jobstream from the reader, and the  initialization will occur (hopefully).  OS DUMP/RESTORE (IBCDMPRS): This program is very similar to the above  OS DUMP/RESTORE (IBCDMPRS)  OS DUMP/RESTORE (IBCDMPRS)  OS DUMP/RESTORE (IBCDMPRS)  IBCDASDI program,DMPRS was always ran by MVS systems programmers to  restore a starter system from tape to a temporary DASD such that they  could build the system. The input jobstreams looked like this:   DASD1 JOB 'RESTORE MVS STARTER SYSTEM SYSRES PACK'  MSG TODEV=1052,TOADDR=009  RESTORE FROMDEV=3400,FROMADDR=580,TODEV=3330,TOADDR=150,  VOLID=MVSRES  END  Figure 66. Example IBCDMPRS jobstream  STANDALONE UTILITIES (ZZSA): ZZSA is a program written by Jan Jaeger  STANDALONE UTILITIES (ZZSA)  STANDALONE UTILITIES (ZZSA)  STANDALONE UTILITIES (ZZSA)  that provides an emergency rescue environment and standalone  fullscreen editor -- the only other real option for shops that broke  their MVS install is to be running it under VM, wherein they can use  CMS's OS simulation to edit a probably-erroring PARMLIB member. This  program could IPL from a DASD, tape, reader, or VM saved segment  (which is how the below screenshots were captured), wherein it would  present a 3270 user interface and an editor that is not unlike that of  ISPF's. With this, users could hopefully un-brick their mainframes.        Popular Mainframe Programs 195 »   ZZSAPRIM Stand Alone Utilities  Option ===>   0 ListDev - List all devices  1 Browse - Browse dataset or member Console 000  2 Edit - Edit dataset or member IPL Device ???  3 ListVTOC - List Volume Table Of Contents IPL CPU 000  4 ListPDS - List PDS directory CPU Version FF  5 DispVol - Display DASD volume label CPU Serial 010  6 Dump - Dump DASD record by CCHHR CPU Model 706  7 Zap - Alter DASD record by CCHHR Date (TOD) 22/  X Exit - Terminate program Time (TOD) 16:  Jan Jaeger - Version 12/07/9  Figure 67. ZZSA main menu            196 Mainframe History »   ZZSABROW Device List  Command ===> Line 0000 Co  ********************************* Top of Data ***************************  SCH=0000 DEV=0009 CHP=00 C/T=3274-1D  SCH=0001 DEV=000C CHP=00  SCH=0002 DEV=000D CHP=00  SCH=0003 DEV=000E CHP=00  SCH=0004 DEV=0190 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=0005 DEV=0191 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=0006 DEV=0193 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=0007 DEV=019D CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=0008 DEV=019E CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=0009 DEV=0370 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=000A DEV=0CF1 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=000B DEV=0CF2 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=000C DEV=0123 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=000D DEV=0124 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=000E DEV=0125 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=000F DEV=0126 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=0010 DEV=0127 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=0011 DEV=0128 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=0012 DEV=0129 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  SCH=0013 DEV=0194 CHP=FD C/T=3990-E2 D/T=3390-0A VOL  F3=End F5=RFind F7=Up F8=Down F10=Left F11=Right  Figure 68. ZZSA device list            Popular Mainframe Programs 197 »   ZZSABROW VTOC listing VSAM01(0100)  Command ===> Line 0000 Co  ********************************* Top of Data ***************************  Z9999992.VSAMDSPC.TE1F9DC4.T9B02555 DSORG=VS RECFM=???? BLKSIZ  Z9999996.VSAMDSPC.TE1F9DBB.TED3F3A5 DSORG=VS RECFM=???? BLKSIZ  ******************************** Bottom of Data *************************        F3=End F5=RFind F7=Up F8=Down F10=Left F11=Right  Figure 69. ZZSA dataset list  Alas, no mainframe is without it!           198 Mainframe History »   AFTERWORD  AFTERWORD  AFTERWORD  AFTERWORD  _________    I have composed this to, the best of my ability, to be as accurate as  I can make it. I have composed this since the 2nd of August to be the  ultimate reference or the mainframe hobbyist community; I hope that  this is sufficient and brings people some fun and insightful know-  ledge!                 Afterword 199 »   INDEX  INDEX  INDEX  INDEX  _____    ĐŚŚŚŚŚŚŚŚŚŚŻ 3270 Display System (continued)  | Numerics | Terminals  Numerics  Numerics  Numerics  żŚŚŚŚŚŚŚŚŚŚš 3104 55  3178 54  1052 29 3179 54  1403 25 3180 54  1404 25 3191 55  1442 30 3192 55  2216 34 3193 55  2260 40 3194 55  2265 41 3277 52  2848 41 3278 52  270x 3279 52  2701 37 3290 54  2702 38 3472 56  2703 39 CUT/DFT mode 51  2712 39 Printers  AWS2703 39 3501/3521. 31  9370 ASCII Subsystem 39 3505/3525 31  4331/4341/9370 Telecommuni- 3618 27  cations Subsystem 3705 42  (ICA) 40 3710 42  AWSICA 40 3725 42  2770 57 CCL (Communications Con-  2780 57 troller for Linux) 43  2821 25 EP 42  3088 31 NCP 42  ESCON/FICON CTCA 31 PEP 42  Parallel CTCA 31 3780 58  3172 33 4245 28  CLAW mode 34 4248 28  WAC (WAN Adapter Card) 34 5262 28  3203 27 6262 29  3210 29 8232 (LCS) 32  3215 29  3211 26  3262 27 ĐŚŚŚŻ  3270 Display System | B |  B  B  B  Controllers żŚŚŚš  3174 47  3271 44 BOS/360 60  3272 43 BPS/360 60  3274 44  3299 51    200 Mainframe History »   ĐŚŚŚŻ DOS/VS 62  | C | DOS/VSE 63  C  C  C  żŚŚŚš SSX/VSE 63  VSE Products  CICS CICS/DOS/VS 63  History 164 DITTO 63  MTCS 164 VSE ACF/VTAM 63  Programming 170 VSE/ICCF 63  Command-level 173 VSE/POWER 63  Macro-level 170 VSE/AF 64  Versions 165 VSE/SP 64  DPPX/370 161  ĐŚŚŚŻ  | D | ĐŚŚŚŻ  D  D  D  żŚŚŚš | E |  E  E  E  żŚŚŚš  Disks  0671 15 Emulators  2302 13 FLEX-ES 10  2305 14 Hercules 11  2311 13 TurboHercules 12  2314 13 zPDT 11  2319 14 ZD&T 11  3310 15 zPDT Enterprise Edition 11  3330 13  3340 14  3350 15 ĐŚŚŚŻ  3370 15 | G |  G  G  G  3375 15 żŚŚŚš  3380 16  3390 16 GDDM 178  9332 15 GDDM-ICU 179  9335 15 GDDM-ISE 181  9336 15 GDDM-IVU 179  9345 16 GDDM-OPS 180  DS line GDDM-VSE 181  DS6800 19  DS8100 19  DS8800 19 ĐŚŚŚŻ  ESS/Shark (Enterprise Storage | I |  I  I  I  Server) 18 żŚŚŚš  MP2000 disk array 17  MP3000 disk array 17 IX/370 (IBM) 152  RAMAC/RAMAC II 17 AIX/370 153  VSS (Versatile Storage AIX/ESA 155  Server) 18  DOS/360 62  POWER 62  TOS/360 62    Index 201 »   ĐŚŚŚŻ OS/360 71  | L | MFT 71  L  L  L  żŚŚŚš MVT 72  ASP 73  Linux 139 HASP 73  Linux/370 (Bigfoot, i370) 139 TSO 72  INS file 139 PCP 71  Kernel command line 140 OS/390 82  Linux/390 (IBM, s390) 142 Version 1 82  OS/VS1 74  BPE 74  ĐŚŚŚŻ OS/VS2 75  | M | SVS 75  M  M  M  żŚŚŚš Link Pack Area 75  OS/VS2 MVS 76  MTS 96 MVS 3.8J 79  Communication Controller MVS/SE 77  (CC) 100 MVS/SP 77  MERIT Network 100  PCP/SCP 100  CONCOMP 97 ĐŚŚŚŻ  UMMPS 96 | P |  P  P  P  MUSIC 92 żŚŚŚš  Email system 93  Filesystem 93 PC mainframes  MUSIC JCL 94 P/390 8  Networking facilities 93 S/390 Integrated Server  OS emulator 93 (3006) 8  MVS/ESA 81 VM/SP Technical Workstation  OpenEdition 82 (7437) 8  Version 3 81 P/370 8  Version 4 81 XT/370 7  Version 5 82 AT/370 8  MVS/XA 79  ĐŚŚŚŻ  ĐŚŚŚŻ | R |  R  R  R  | O | żŚŚŚš  O  O  O  żŚŚŚš  RAX 92  OfficeVision/VM 183 RJE (Remote Job Entry) 56  CallUp 189  ESA Calendar Feature 188  Open Systems Adapter  ICC (Integrated Console Con-  troller) 37  OSD 37  OSE 37  QDIO 37    202 Mainframe History »   ĐŚŚŚŻ System/390 (continued)  | S | ES/9000 (continued)  S  S  S  żŚŚŚš 9221 5  ESCON 6  SCRIPT 182 Multiprise 2000 6  BookMaster 183 Multiprise 3000 7  DCF/SCRIPT 182  GML 183  Waterloo SCRIPT 182 ĐŚŚŚŻ  System Z 9 | T |  T  T  T  System z12 9 żŚŚŚš  z12BC 9  z12EC 9 Tapes  System z13 9 2400 19  System z14 10 2415 20  System z15 10 NRZI 20  System z16/Telum 10 PE 20  System z17/Telum II 10 2420-7 21  System z9 9 3410 21  System z10 9 3411 22  zAAP 9 3420 21  zIIP 9 3422 21  zEnterprise 9 3430 21  z114 9 3480 23  z196 9 3480 IDRC 23  System/360 3 3490E 23  DAT Box (360) 3 3590 23  Model 67 3 3803 22  System/370 3 8809 22  3033 4 9347 23  ECPS 4 TPF 157  3081 4 ACP 158  3083 4 SABRE 157  Extended Real Addressing 4 DELTAMATIC 157  3090 5 PANAMAC 157  370/Advanced Functions 4 SabreTalk 159  4300 Series 4 TPF/ESA 159  4321 4 z/TPF 159  4331 4 TSS 87  4341 4 TSS/360 87  4361 4 Commands 88  4381 5 Dynamic linker 88  9370 5 TSS/370 89  DAT Box (370) 4 Discontinuation 89  ESA/370 5  System/390 5  9672 6  Application StarterPak 3000 7  ES/9000 5  9021 5  9121 5    Index 203 »   ĐŚŚŚŻ VM/CMS (continued)  | U | VM/XA (continued)  U  U  U  żŚŚŚš VM/XA MA 129  VM/XA SF 129  UNIX/370 (Bell Labs) 144 VM/XA SP 130  UNIX/370 (Princeton) 149 z/VM 136  Amdahl UTS 151 VSE/ESA 64  Utilities Dynamic partitions 65  DMKDDR 194 Fixed partitions 65  DMKDIR 193 TCP/IP for VSE 66  DMKFMT 192  IBCDASDI 194  IBCDMPRS 195 ĐŚŚŚŻ  ICKDSF 191 | Z |  Z  Z  Z  SA IOCP 193 żŚŚŚš  ZZSA 195  z/OS 83  64-bit only 83  ĐŚŚŚŻ z/VSE 67  | V | VSEn 69  V  V  V  żŚŚŚš  Version 2 83  VM/CMS  CP-40 109  CMS 110  CP-67 110  Origins 108  Blaauw Box 109  Ferranti Atlas 109  Project MAC 108  VM/370 112  BSEP 116  BSEPP 116  CPREMOTE 114  RSCS 114  TOOLSRUN 116  VNET 114  VM/ESA 132  Version 2 134  VM/SP 117  Object Code Only (OCO) 121  PROFS 118  VCNA 118  VM TCP/IP 122  VM/PC 121  VM/SP HPO 120  VMCF 118  WISCNET 122  VM/XA 129  Bimodal CMS 130    204 Mainframe History »   GLOSSARY  GLOSSARY  GLOSSARY  GLOSSARY  ________    Linux/i370. See Bigfoot Linux.  Linux/i370 _____________  Linux/i370  Linux/i370  OSA. Open Systems Adapter, a network interface card for System/390  OSA  OSA  OSA  and System Z systems.  ICA. The Integrated Communications Adapter found on the ES/9000 and  ICA  ICA  ICA  emulated on the P/390, IS3006, and MP3000 systems that provides WAN  interfaces on SDLC or BSC ports.  SDLC. Synchronous Data Link Control, a synchronous-serial WAN inter-  SDLC  SDLC  SDLC  face similar to X.25's HDLC.  X.25. An obsolecent WAN network protocol family common in the era of  X.25  X.25  X.25  mainframes.  Token Ring. An obsolecent networking technology pushed by IBM that  Token Ring  Token Ring  Token Ring  used a ring network topology to form a LAN, as opposed to Ethernet  (which forms a bus topology)  FDDI. Fiber Distributed Data Interface, a mixed WAN/LAN high-speed  FDDI  FDDI  FDDI  ring network that was popular in the 1990s in large systems. Requiring  two fiber pairs and nothing more, some FDDI rings spanned entire con-  tinents.  ATM. Asynchronous Transfer Mode, a WAN network protocol stack that  ATM  ATM  ATM  was inspired by the virtual-circuit-switched protocols that came  before it (like X.25).  ATM LANE. ATM LAN Emulation, used to simulate an Ethernet network  ATM LANE  ATM LANE  ATM LANE  over an ATM virtual circuit. Supported on the OSA cards.  LEXX. The Live Parsing Editor, originally written to edit GML docu-  LEXX  LEXX  LEXX  ments, but later enhanced with other languages. The first syntax-  highlighting editor, its influence on modern IDEs cannot be forgotten.  DAT (tape). A 4mm helical-scan tape format intended for audio  DAT (tape)  DAT (tape)  DAT (tape)  storage, but later reused by computers under the name DDS (Digital  Data Storage). The Multiprise 3000 and S/390 Integrated Server (as  well as being possible on a P/390) had a DAT drive that showed up to  the host as a 3480 cartridge tape drive.  OMA. Optical Media Attach, a scheme in which a virtual tape is assem-  OMA  OMA  OMA  bled from files on a CD. IBM provided a program called Optical Media  Attach/2 that ran on OS/2, and by means of a channel adapter card  (either parallel or ESCON), a fake tape drive appeared to the host.  Used to distribute OS install media, programs, and documentation.   Glossary 205 »   SSA. Serial Storage Architecture, the architectural precursor to SATA  SSA  SSA  SSA  and SAS. IBM pushed this technology in the late 90s and early 2000s to  decent success, and it featured good performance. Though the SSA RAID  cards had a rather obtuse user interface, they were often better than  the competition. The IS/3006 and MP3000 both used SSA.  IS/3006. System/390 Integrated Server model 3006.  IS/3006  IS/3006  IS/3006  MP3000. Multiprise 3000.  MP3000  MP3000  MP3000  Shark. IBM Enterprise System Storage (ESS) DASD array.  Shark  Shark  Shark  VTL. A Virtual Tape Library, often seen attached to modern  VTL  VTL  VTL  mainframes, emulating tape drives with disk files; used for backup.  Bustech. A DASD emulation product that was available in the early  Bustech  Bustech  Bustech  2000s; acquired by Dell and then later killed.  RJE. Remote Job Entry, a remote batch job and output retrieval system  RJE  RJE  RJE  that used batch terminals armed with printers, card readers, and some-  times card punches  NJE. Network Job Entry, an upgraded RJE that supported file transfer  NJE  NJE  NJE  and command execution  ALCS. AirLine Control System, a transaction monitor that runs on MVS.  ALCS  ALCS  ALCS  Versions include 2.3.1 (running on OS/390 2.10 and z/OS 1.1) and 2.4.1  (running on z/OS 1.10). Distinct from CICS.  Personal Communications (PCOMM). IBM's 3270 and 5250 terminal emu-  Personal Communications (PCOMM)  Personal Communications (PCOMM)  Personal Communications (PCOMM)  lator for PCs, also supports VT emulation (as in, the DEC VT100 and  VT220) as a side-effect of needing to be able to do so to properly  emulate 3270 NVT mode.          206 Mainframe History » *** .EDF#INIT 500 13 *** *** NAME (INDEX) LCL AREA SIZE *** *** &@zero@ls 48 1 <0> *** TABLE SPLIT ON PAGE 46. '.EDFETABL' WAS IMBEDDED AT LINE 2546 OF 'MFOSHIST' TABLE SPLIT ON PAGE 49. '.EDFETABL' WAS IMBEDDED AT LINE 2748 OF 'MFOSHIST' STARTING PASS 2 OF 3. TABLE SPLIT ON PAGE 46. '.EDFETABL' WAS IMBEDDED AT LINE 2546 OF 'MFOSHIST' TABLE SPLIT ON PAGE 49. '.EDFETABL' WAS IMBEDDED AT LINE 2748 OF 'MFOSHIST' STARTING PASS 3 OF 3. TABLE SPLIT ON PAGE 46. '.EDFETABL' WAS IMBEDDED AT LINE 2546 OF 'MFOSHIST' TABLE SPLIT ON PAGE 49. '.EDFETABL' WAS IMBEDDED AT LINE 2748 OF 'MFOSHIST' TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 65. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 66. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 68. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 69. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 70. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 78. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 79. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 84. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 85. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 86. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 90. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 95. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 107. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 118. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 120. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 124. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 127. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 128. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 129. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 133. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 137. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 185. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 189. TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 194.