NOSS
NAS Operational Support System
The IBM 9020 ran the National Airspace System (NAS) program operationally. NAS consisted of a Monitor (derived from OS/360 and written in BAL) and the ATC Application programs (written in JOVIAL). NAS is still used today, though the S/360s are long gone!
This page is about NOSS – the NAS Operational Support System. NOSS was developed in the 1960s and consists of a Monitor and various utility subprograms, the two main ones being a JOVIAL complier and a BAL assembler, called BALASM. This is regular BAL with the addition of the special 9020 instructions.
The original NAS program ran on a tape-only S/360 Model 50 complex. The Model 50s were selected by the FAA before the new S/360 family was announced to the public in 1964. Development of NOSS ran in parallel to the development of IBM’s mainstream Operating Systems. As the first 9020s were tape-only, NOSS is probably very similar to TOS/360 (Tape Operating System/360).
Disks were later added to all 9020s and many Model 50 complexes were upgraded to use Model 65s as the main processor. With the advent of disks, the support OS evolved into OS/9020, almost identical to OS/360, but NOSS was retained as it could run in a tape-only subsystem. This was important because an offline sub-system without disks could be configured out of an operational triplex system.
NAS software development took place at the FAA's NAFEC facility, where there were three separate 9020 systems. As NAFEC was non-operational a whole system could be scheduled to run the OS/9020 support system without any regard to redundancy, etc. However, certain NAS support functions had to be run at the operational centres. An example is the Prefiled Flight Plan Assembly utility, which created a tape of repetitive flight plans for subsequent input to the operational system. The tape-only NOSS was used for this as it didn't require disks.
NAS needed disks to run, as they hosted the necessary swap files (memory paging) for the system. However, it could run happily without tapes, though access to system analysis recording, etc., would be temporarily lost. To maximise redundancy, a disk sub-system (there were three) were not 'configured-out' of the operational system unless really necessary. There were also three tape sub-systems, any one of which could be configured into the offline system without significantly impacting the operational system’s redundancy. [This is a slight over-simplification as an offline sub-system only had access to two tape channels - see below. Exactly which two channels depended on which one of the three I/O Control Element was configured into the offline system. Note that only one of the two accessible tape controllers would be actually configured offline via the special 9020 hardware Configuration Control Register that every element contained.]
NOSS will run on a standard S/360 as well as a 9020. The Monitor determines it is running on a standard S/360 if it takes a program interrupt when executing the special 9020 instruction Load Identity (LI) and proceeds accordingly. (As 9020 was a multiprocessor system each Model 65 Compute Element (CE) was physically jumpered with a different identity. The LI instruction reads that identity.)
NOSS went through several iterations as the 9020 system itself evolved, but was stable by 1974 and there were no further changes until the 9020 was replaced in the early 1990s.
NOSS Documents
NOSS BALASM Subprogram Design Document
NOSS Executable Tape Dump
When the UK 9020 system was decommissioned, I saved about forty tapes that I thought would be useful in the future. In 2012 I started to dump these tapes using a Kennedy 9600 tape drive attached to a PC with a Pertec interface. This tape drive could read the 800 BPI NRZI format the tapes were written in on the 9020’s IBM 2401 tape drives.
Unfortunately, about a third of the way through the forty tapes the Kennedy tape drive developed a fault which prevented further tape reading. However, I had already dumped an IPL’able (“bootable” in non-S/360 language) executable NOSS tape before the failure. This is a picture of the tape:
Before dumping the binary contents of the tape, the PC program reads through the tape to analyse the format. The output of this analysis pass is a log file (in plain text) showing the details of the files on tape and the blocks within the files. In the case of the NOSS tape there are 29 files, with various quantities (up to 16) and sizes of blocks within each file. Here is the log file:
Then the PC program dumps each binary file as a single file containing all that file’s blocks. These are contiguous files with no indication of the start or finish of individual file blocks. The analysis pass log file has to be used to derive that information. I have archived the 29 binary NOSS files into a single zip file. Here is the archive file:
Here (thanks to the good offices of Tony Lawrence) is a tape image of the NOSS tape in a format suitable for use with the SIMH S/360 simulator:
In 1998 I downloaded the archived NOSS source code from our VM/370 bureau system. This was onto a PC running terminal emulation, and the files were converted from EBCDIC to ASCII in the process. I then ZIP’ed them into two separate ZIP files (why I split them into two files I don’t now recall). The source files are in Symbolic Program Tape (SPT) format, which is just plain text. Here are these ZIP files: