System Support Program


System Support Program is the operating system of the IBM System/34 and System/36 minicomputers. SSP was released in 1977.

History

SSP originally contained 60 or so commands that were implemented on the System/34 from 1977 to 1983 in different versions called releases. Release 1 was issued with the original S/34 in 1977. Release 9 was issued in 1981. In 1983, IBM repackaged SSP on a new computer called the IBM System/36, which was not object-code compatible with the S/34. In 1994, IBM repackaged SSP on an updated model of the S/36 called the Advanced/36. The A/36 was an IBM AS/400 which had the SSP implemented as a "virtual machine".
Major releases of SSP include:
  • S/34
  • * S/34 Release 1.0 – this was shipped with the first S/34 in 1977.
  • * S/34 Release 8.0 – this seems to have been issued about 1980.
  • * S/34 Release 9.0 – this was the last release for the S/34 c.1980.
  • S/36
  • * S/36 Release 1.0 – this was apparently shipped with the first S/36 in 1983.
  • * S/36 Release 2.0 – this release supported the 8809-tape drive.
  • * S/36 Release 4.0 – this was the release where S/36 was given 5 job queues.
  • * S/36 Release 5.1 – this 1988 release was the last major change on 536X platforms.
  • * S/36 Release 6.0 – also known as the VASP or Value-Added Support Product, this release added functionality that allowed program calls in RPG, and it also provided software to calculate the size AS/400 that the user would need when upgrading. The VASP was controversial. Rumours circulated in the industry papers that the customer could not go back to 5.1 if 6.0 did not function adequately. Program calls with RPG CALL/PARM were inferior to RPGIII designs and inferior to customer add-on products.
  • * S/36 Release 7.1 – this 1994 release was shipped with the Advanced/36. The first A/36 machines would not function on a lower release and were also incompatible with 7.5. Rumours circulated that stated prior release compilers would not function on the Advanced/36, but they proved unfounded. There were reasons a programmer would rather use the 5.1 RPGII compiler instead of the presumably more advanced 7.x compiler.
  • * S/36 Release 7.5 – this 1995 release was shipped with the second and final wave of the Advanced/36. Functions like WRKSYSVL allowed the operator to change the system time on the fly, which was interesting because customer add-ons to do this through assembler subroutines did not function on the Advanced/36. However, assembler routines to do things like open/close files, retrieve the VTOC, etc. functioned just fine on 7.1 and 7.5
  • * Guest/36 – this is Release 7.5, but you could set up an M36 on an AS/400, and it would function just like the 9402-436, except that in addition to having this guest "partition", you also had OS/400 if you wanted it. So, if the 9402-436 which came in 3 speeds 2102, 2104 and 2106 wasn't fast enough, you could get a 9406-xxx machine and install a "guest/36" on such. And actually, you could install more than one guest/36. There were some limitations of number of attached workstations but having two guest/36's running on an AS/400 and setting up DDM between them and even with OS/400 to host large files, could easily be done. While the S/36 and A/36 for the most part worked only with twinax attached terminals, on a Guest/36, you could have all your terminals be on a LAN running tcp/ip and be virtual devices in the Guest/36 environment.
  • * S36EE – this was supported native on the AS/400 and its follow on, which allows a user to continue to run their s/36 programs and procedures without having to convert them. Many of the system procs also work with such. While it was typically "slower" since it has to go through additional steps, however today with such fast machines, the speed of an S36EE is many times faster than the A/36 execution speed. Example, one job took 12 minutes to run on an Adv/36, took 20 seconds to run in S36EE mode. The object code however is NOT compatible with the previous S/36 and A/36, meaning that one had to recompile all programs and menus. However, one advantage is that you can not only run S36EE but also OS/400 applications. You can access database tables in your S/36 programs, you can call RPG/400 and RPGIV programs from with a S/36 program. So, while technically not SSP, it looks like SSP, it acts like SSP, and it will run your S/36 programs/procs.
Limitations on S/36 and A/36 and M/36 operating system: The maximum amount of disk space that a system could utilize was 4 gb.

Functions and components

Using SSP, the operator can create, delete, and manage S/34-36 objects such as libraries, data files, menus, procedures, source members, and security files.
SSP contains modules such as DFU, SEU, SDA, and WSU that permit operators to build libraries and files, enter information into those files, produce simple reports, and maintain a menu structure that simplifies access to the information. The Advanced/36 does not support WSU. Password and resource security are also implemented through SSP, as are remote communications, which today is similar to dial-up networking.
SSP is a disk-based operating system. Computer programs can be run from the fixed disk, but not from diskette or tape. The complement of a System/34 5340, or System/36 5360/5362 is a fixed disk array of one to four fixed disks, at least one computer terminal, and an 8" diskette drive, optionally fitted with two magazine units that can contain 10 diskettes each and three diskette slots. A S/36 5363/5364 has a 5-1/4" diskette drive. S/36 computers can be configured with an 8809 reel-to-reel tape drive or a 6157 1/4" cartridge tape drive. A/36 computers have a high-density QIC drive but the 5.25" or 8" diskette drive was optional as was a 9348-001 9 track 1600/6250 bpi tape drive.

System utility programs

SSP procedures utilize utility programs, which can in some cases be more useful to the computer programmer than the SSP procedures themselves. is the library utility, used in, and. is the file utility used in, and. There are many other utilities, including,,,,,,,,, and, which are more flexible at the program level than associated SSP procedures can be.

Configuring using CNFIGSSP

The procedure was used to configure the system, including the devices. Each device is assigned a two-character ID. The first letter must be alphabetic; the second must be alphameric. The system also reserved certain IDs; the device can't be called I1 or F1, for example. I1 is the name of the diskette drive; F1 is what the system calls the hard drive
To apply, the system must be dedicated. The system must be IP Led When IPL finished, the new devices would appear on the status display.

SDA - Screen Design Aid

SDA allows the operator to build screen formats or menus. Command keys can be enabled/disabled. Input fields, output fields, and constants can be created and conditioned. Conditions can cause fields to disappear or change colours.

SORT - The system Sort utility

SORT has one to eight input files, which may be of any valid record length. It has one output file, of any stated length, which may contain from zero to 8 million-plus records.
A sort can contain entire records or just 3-byte addresses which point to records in an associated file. This was called an address-out file or. When using an Add rout, the program read in these 3-byte addresses and then fetched associated records from the master file.

WSU - Work Station Utility

This was an RPG-like language that ran on SSP. It was focused on data entry type programs. WSU was free, but it wasn't particularly well-received because it was so limited.

DFU - Data File Utility

It is an IBM-supplied no-charge item which is used to view and change field values in individual records.
DFU can be used
  • by programmers to update data base files on the fly without writing programs
  • by programmers to create simple programs to do carry out basic operations on a data base file
  • by data entry personnel to add or remove records from a file, or to print records.

    Programming

Operational Control Language (OCL)

High-level language programs require OCL to be activated. OCL is used to load programs into the system's memory and start them and assign resources such as disk files, printers, message members, memory, and disk space to those programs. Other abilities, such as displaying text on the screen, pause messages, and so forth, make OCL more powerful.

RPG II

RPG II was modified from the System/3 days to allow access to the "WORKSTN file" to allow a punched card-based language to interact with a person sitting at a keyboard and monitor. A WORKSTN file was an output file and also an input file. Thus, it was labelled a combined-primary file or a combined-demand file.
Command keys became RPG indicators KA-KY, and different on-screen forms were recognized by different invisible control characters hidden in the forms themselves. Since the user had to display a form on the screen in order to type, RPG II provided a way for a program to write output before accepting input. Many successful programmers moved from using the combined-primary WORKSTN file to using a combined-demand file, which had operation codes to read and write the display. There was even a way to code for multiple WORKSTNs; several people could sign on to the same copy of the same program in memory. The largest program size was 64k.

Program attributes - MRTs, SRTs, NRTs and NEPs

MRT = Multiple Requestor Terminal program. SSP could attach up to 7 terminals to a program at once. Any operator could start the program at their terminal, then other operators' terminals would be attached when they selected the same program. The maximum number of terminals to be serviced was controllable by the programmer.
SRT = Single Requestor Terminal program. Not an MRT.
NRT = No Requestor Terminal program. Started at a terminal, the NRT releases the requesting terminal and continues. This is similar to an MS-DOS TSR program. By definition, any program that was evoked or submitted to the JOBQ was an NRT.
NEP = Never Ending Program. This was typically an interactive MRT program that would wait after all terminals disconnected until some terminal reconnected, avoiding initiation overhead. This was commonly used to allow large programs to be implemented as a chain of small programs that would pass the terminals from one to another while remaining ready to continue processing for other terminals and/or subsequent transactions. NRT programs could also be NEPs if written to loop and wait for some condition indicating there was work to be done. NEP programs normally did not end until system shutdown, unless written to recognize some special terminate condition.