CP/67 CMS Operating System Source Code | Hacker News Reader

CP/67 CMS Operating System Source Code

github.com

65 pointsrbanffy6 comments

That's... spooky. I was working on this exact project a few weeks ago for the VM/370 source distribution tapes (and WOW the VMFPLC2 format is a pain). Shame OP didn't preserve the on-tape file structure, it would have been interesting to see how things had evolved.

Anyway, if you're looking for more info about CP/CMS and VM/370 or the systems they ran on, bitsavers has an absolute treasure trove of manuals: http://bitsavers.org/pdf/ibm/360 http://bitsavers.org/pdf/ibm/370

It is somewhat striking how high level the 360 assembler is. It's not that difficult to read the code snippet below.

So there are assembler instructions (not macros I believe) that are equivalent to "strcmp", "strcpy". Well I guess they're more sub routine calls for micro code.

Equivalent C code probably wouldn't be that much shorter, while modern assembler languages would expand to much more and harder to read code. Even x86 which has strcmp/strcpy instructions requires much more boilerplate, and also they're generally not used anymore because they're too slow.

Now of course with all the gotos (jumps) it is still quite spaghetti code. But if the assembler had some structured programming features (and maybe types) it probably wouldn't be that bad.

Of course it helps that everything was much simpler then.

(sorry for the screwy formatting)

SEARCH LA R9,LENGTH LIMIT FOR BXLE

         LA    R8,12          INCREMENT FOR BXLE                      
  
         LA    R1,SMLIST      POINT TO STATE PLIST  
                    
         MVC   8(8,R1),8(R7)  MOVE IN FILENAME  
                        
         MVI   24(R1),C'P'    SEARCH PERMANENT DISK FIRST

LOOP2 LA R2,TYPES SET BXLE INDEX AT 1ST FILETYPE

LOOP MVC 16(8,R1),0(R2) CHECK FOR VARIOUS FILE TYPES

         SVC   X'CA'          CALL STATE

         DC    AL4(ERH)       GO CHECK R15 ERROR CODES
                 
         BC    15,8(0,R2)     RETURN CODE WAS 0.  FILE FOUND, SO BRANCHERH
         C     R15,AONE       WAS RETURNED ERROR CODE A 1?

         BE    BIX            IF SO, FILE NOT FOUND. TRY AG

         LA    R9,4           STATE ERROR CODE OF 4                   
 
         BC    15,CLOSUP

> permanent read errors

I wonder if you read the tape in, say, 51 times and the tape might read a bit a certain way more or less than half the time, if it would fix such errors. E.g. if we have five reads of the same byte on tape:

01010110

01010111

01010110

01001111

01010111

The byte is most likely 01010111.

There could be software to calculate most probable bits over a certain number of reads.

Permanent errors are often just that, permanent. Imagine a bit of tape that's fully demagnetized or magnetized, has a hole in it or a bit of the magnetic material simply unglued and came off, etc.

Some errors you can correct probabilistically, like this on■. Others are harder, for instance ■

z/VM can't read a 1970s format? Oh dear, but at least the hardware was available.

Brings back not so happy memories of coping with other labs' random tape formats and the lack of 7-track drives for historical data that was of interest.

> z/VM can't read a 1970s format?

Personally, I think it's outrageous. OTOH, it's been a while since I last saw a modern computer with an 8" floppy too, so I'd guess it's understandable.

Reply on news.ycombinator.com