4 ms·

I could add so much to this page. - COBOL on punch cards - RPG II/III - PDP/Vax Shared Memory Modules - Hierarchical Data File Storage - Recursive Expressi

I could add so much to this page. - COBOL on punch cards - RPG II/III - PDP/Vax Shared Memory Modules - Hierarchical Data File Storage - Recursive Expression Evaluator - Batch Processing large datasets - Compressed dates and numbers So many of these teach you structural complexity that you’d never learn in today’s world.

markus_zhang 1y ago
Just curious what is special about PDP/Vax Shared Memory Modules? I know Win NT is basically the child of VMS and David Cutler worked on PDP before VAX, so maybe this is the reason?
- ChicagoDave 1y ago
  You had to map out how modules would swap in and out of memory, so they had to be encapsulated modules. At least for the PDP you didn't have relational data stores so all data was in hierarchical data files (each record had a parent-child indicator, so you might read an 'M' record, then many 'D' records). You certainly could not load all of the data into memory even one set of M+D+sub records might blow out your limits. You had to carefully think through how your code worked at a molecular level always banging up against a memory wall.
  - ChicagoDave 1y ago
    This is what data prior to SQL Server and Oracle looked like: ************************************** * MEDICAL INSURANCE CLAIMS HIERARCHICAL FILE - CIRCA 1982 * * RECORD TYPES: H=HOSPITAL(MASTER) P=PATIENT D=DIAGNOSIS C=CLAIM DETAIL * ************************************** H001MEMORIAL GENERAL HOSPITAL 19820415NEW YORK NY10001212555010001520000 P001001JOHNSON ROBERT M19450312001234567819820102BCBS D001001001HYPERTENSION 401.9 19820102 D001001002DIABETES TYPE 2 250.00 19820102 C00100100119820102OV0992001200120 C00100100219820102LAB8100305003050 C00100100319820102RX1150002500250 P001002SMITH MARY F19580624002345678919820115AETNA D001002001PNEUMONIA 486 19820115 C00100200119820115ER0992505002500 C00100200219820115XR7100108001080 C00100200319820115RX1150012501250
  - markus_zhang 1y ago
    Thanks Dave. Guess db back then is very different.
    - ChicagoDave 1y ago
      To clarify, that's a text file. We ran batch programs overnight to process claims and create billing reports (this is fake data, but I consulted on insurance and legal systems back in the mid-eighties). That batch program was modular and would run several "passes" over the file (sequentially) to do varying types of work (create new data, create reports). These programs could also change a record if they needed to. A claims record might have a status indicator like "submitted" (S), "billed" (B), "denied" (D), "paid" (P). Everyone that writes code today works on the shoulders of such systems and some of these systems still exist (social security, hotel reservations, flight scheduling, banking, insurance) all original designed by IBM. Most of these have Java and DB2 layers on top of them now, but the underlying data is in many cases still there. The modularization was because 32mb that had to be split up to handle varying functionality (procedural BASIC or C). There would be a MAIN module, then any number of sub-modules and you'd describe how they would swap in and out as needed. (See PDP-11/RSTS-E Task Builder). Relational databases were magic when we started using them in the early nineties. NOSql databases are also magic. Graph databases are pure wizardry.

markus_zhang 1y ago

Just curious what is special about PDP/Vax Shared Memory Modules? I know Win NT is basically the child of VMS and David Cutler worked on PDP before VAX, so maybe this is the reason?

ChicagoDave 1y ago
You had to map out how modules would swap in and out of memory, so they had to be encapsulated modules. At least for the PDP you didn't have relational data stores so all data was in hierarchical data files (each record had a parent-child indicator, so you might read an 'M' record, then many 'D' records). You certainly could not load all of the data into memory even one set of M+D+sub records might blow out your limits. You had to carefully think through how your code worked at a molecular level always banging up against a memory wall.
- ChicagoDave 1y ago
  This is what data prior to SQL Server and Oracle looked like: ************************************** * MEDICAL INSURANCE CLAIMS HIERARCHICAL FILE - CIRCA 1982 * * RECORD TYPES: H=HOSPITAL(MASTER) P=PATIENT D=DIAGNOSIS C=CLAIM DETAIL * ************************************** H001MEMORIAL GENERAL HOSPITAL 19820415NEW YORK NY10001212555010001520000 P001001JOHNSON ROBERT M19450312001234567819820102BCBS D001001001HYPERTENSION 401.9 19820102 D001001002DIABETES TYPE 2 250.00 19820102 C00100100119820102OV0992001200120 C00100100219820102LAB8100305003050 C00100100319820102RX1150002500250 P001002SMITH MARY F19580624002345678919820115AETNA D001002001PNEUMONIA 486 19820115 C00100200119820115ER0992505002500 C00100200219820115XR7100108001080 C00100200319820115RX1150012501250
- markus_zhang 1y ago
  Thanks Dave. Guess db back then is very different.
  - ChicagoDave 1y ago
    To clarify, that's a text file. We ran batch programs overnight to process claims and create billing reports (this is fake data, but I consulted on insurance and legal systems back in the mid-eighties). That batch program was modular and would run several "passes" over the file (sequentially) to do varying types of work (create new data, create reports). These programs could also change a record if they needed to. A claims record might have a status indicator like "submitted" (S), "billed" (B), "denied" (D), "paid" (P). Everyone that writes code today works on the shoulders of such systems and some of these systems still exist (social security, hotel reservations, flight scheduling, banking, insurance) all original designed by IBM. Most of these have Java and DB2 layers on top of them now, but the underlying data is in many cases still there. The modularization was because 32mb that had to be split up to handle varying functionality (procedural BASIC or C). There would be a MAIN module, then any number of sub-modules and you'd describe how they would swap in and out as needed. (See PDP-11/RSTS-E Task Builder). Relational databases were magic when we started using them in the early nineties. NOSql databases are also magic. Graph databases are pure wizardry.