3 ms·

Those airline reservation systems were built in the 70s and 80s, and had to be extremely efficient, so, evidently they felt assembly was a better option than an

Those airline reservation systems were built in the 70s and 80s, and had to be extremely efficient, so, evidently they felt assembly was a better option than any of the higher level languages available around that time.

bluGill 4y ago
Back then it was the better choice. Not only where CPUs much slower, but optimizing compilers were not nearly as good (if they existed - often they didn't).
davidrupp 4y ago
They also evolved from the original Airline Control Program (ACP), which was written in the 1960's, at which point assembly was pretty much the only way to get the level of performance required. I think there was some incidental "vendor lock-in", given that IBM was so dominant in the mainframe space for so long, but I think the more relevant principle is "conceptual lock-in", kind of like why banks still rely on COBOL. There was such a large investment in assembly that rewrites into higher level languages -- and we did consider them -- were prohibitively expensive.
skissane 4y ago
C wasn't really an option in the 1970s. It wasn't far into C's existence before Bell Labs internally had a C compiler for IBM OS/360 (predecessor of MVS), but it wasn't available as a commercial product (they did agree to share it with external researchers, most significantly the group at Princeton which used it to produce the first port of Unix to IBM mainframes.) C compilers for IBM mainframes running Unix were commercially available by 1980 (as part of Amdahl UTS, which was the productisation of Princeton's port), but it took a few more years before you they were commercially available for non-Unix IBM mainframe operating systems. There was one alternative to assembler which saw some use (albeit never reached assembler's popularity) – SabreTalk (aka PL/TPF) [0]. That was jointly developed by IBM, American Airlines and Eastern Airlines. It was a custom PL/I dialect, rather than just standard PL/I, because (i) standard PL/I includes a lot of facilities which didn't make sense in the TPF environment (such as IO and floating point); (ii) standard PL/I lacked inline assembly, but that made it harder to invoke the TPF API which revolved around assembler macros. IBM has a long history of secret internal dialects of PL/I, which it used to write its mainframe/midrange operating systems (PL/S and its descendants)–SabreTalk belongs to the same tradition, although it is not identical to any of those internal IBM dialects. Eventually, someone developed a SabreTalk to C converter, and SabreTalk sites used that to move to a mainstream language. Most of these airline reservation systems also used COBOL. COBOL was too inefficient for the real-time transaction processing part of the system, but these systems also involved some background batch processing (aggregate reporting, accounting, etc), and that part of the system was generally written in COBOL running under MVS. It was normal for TPF sites to have TPF mainframes to run the transaction processing, and MVS mainframes to run the batch reporting and other business applications, and also to host the development environment – TPF has never been self-hosting, developers would edit/assemble/compile their code under MVS and then transfer it to TPF for testing. (In TPF's contemporary successor z/TPF, the development platform has shifted from MVS to Linux.) [0] See https://en.wikipedia.org/wiki/SabreTalk https://en.wikipedia.org/wiki/SabreTalk and also http://teampli.net/Sabretalk_Reference_Guide.pdf http://teampli.net/Sabretalk_Reference_Guide.pdf

bluGill 4y ago

Back then it was the better choice. Not only where CPUs much slower, but optimizing compilers were not nearly as good (if they existed - often they didn't).

davidrupp 4y ago

They also evolved from the original Airline Control Program (ACP), which was written in the 1960's, at which point assembly was pretty much the only way to get the level of performance required. I think there was some incidental "vendor lock-in", given that IBM was so dominant in the mainframe space for so long, but I think the more relevant principle is "conceptual lock-in", kind of like why banks still rely on COBOL. There was such a large investment in assembly that rewrites into higher level languages -- and we did consider them -- were prohibitively expensive.

skissane 4y ago

C wasn't really an option in the 1970s. It wasn't far into C's existence before Bell Labs internally had a C compiler for IBM OS/360 (predecessor of MVS), but it wasn't available as a commercial product (they did agree to share it with external researchers, most significantly the group at Princeton which used it to produce the first port of Unix to IBM mainframes.) C compilers for IBM mainframes running Unix were commercially available by 1980 (as part of Amdahl UTS, which was the productisation of Princeton's port), but it took a few more years before you they were commercially available for non-Unix IBM mainframe operating systems. There was one alternative to assembler which saw some use (albeit never reached assembler's popularity) – SabreTalk (aka PL/TPF) [0]. That was jointly developed by IBM, American Airlines and Eastern Airlines. It was a custom PL/I dialect, rather than just standard PL/I, because (i) standard PL/I includes a lot of facilities which didn't make sense in the TPF environment (such as IO and floating point); (ii) standard PL/I lacked inline assembly, but that made it harder to invoke the TPF API which revolved around assembler macros. IBM has a long history of secret internal dialects of PL/I, which it used to write its mainframe/midrange operating systems (PL/S and its descendants)–SabreTalk belongs to the same tradition, although it is not identical to any of those internal IBM dialects. Eventually, someone developed a SabreTalk to C converter, and SabreTalk sites used that to move to a mainstream language. Most of these airline reservation systems also used COBOL. COBOL was too inefficient for the real-time transaction processing part of the system, but these systems also involved some background batch processing (aggregate reporting, accounting, etc), and that part of the system was generally written in COBOL running under MVS. It was normal for TPF sites to have TPF mainframes to run the transaction processing, and MVS mainframes to run the batch reporting and other business applications, and also to host the development environment – TPF has never been self-hosting, developers would edit/assemble/compile their code under MVS and then transfer it to TPF for testing. (In TPF's contemporary successor z/TPF, the development platform has shifted from MVS to Linux.) [0] See https://en.wikipedia.org/wiki/SabreTalk https://en.wikipedia.org/wiki/SabreTalk and also http://teampli.net/Sabretalk_Reference_Guide.pdf http://teampli.net/Sabretalk_Reference_Guide.pdf