System Support Program

System Support Program (SSP)

Main Menu of SSP 7.5, shown inside a TN5250 client
Developer	IBM
Working state	Discontinued
Initial release	1977;47 years ago (1977)
Platforms	System/34 and System/36 minicomputer
Default user interface	Command-line interface
License	Proprietary
Preceded by	System/32 System Control Program (SCP)
Succeeded by	OS/400

System Support Program (SSP) was the operating system of the IBM System/34 and System/36 minicomputers. SSP was a command-based operating system released in 1977. ^[1]

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. ^[1]
  • S/34 Release 8.0 – this seems^{[ citation needed ]} 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^{[ citation needed ]} 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.^{[ citation needed ]}
  • 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^{[ citation needed ]}, 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^{[ citation needed ]}. Rumours circulated in the industry papers^{[ citation needed ]} 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.^{[ citation needed ]}
  • S/36 Release 7.1 – this 1994 release was shipped with the Advanced/36 (9402-236 models). The first A/36 machines would not function on a lower release and were also incompatible with 7.5 (while technically, true, program object code from a 7.1 machine would run on a 7.5 and vice versa, plus many 9402-236's were upgraded to 9402-436, which they changed out the motherboard and installed some new LIC code and you restored on a copy of your files and voila, it all worked). 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 (9402-436). 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 (a guest) on an AS/400 (running OS/400 V3R6 thru V4R4), 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 (which the latter was about 2.7X faster than the base) 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 (distributed data management) 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 (or M/36), you could have all your terminals be on a LAN running tcp/ip and be virtual devices in the Guest/36 environment.
  • S36EE (S/36 execution environment) – this was supported native on the AS/400 and its follow on (iSeries, IBM i), 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 (per occurrence of the operating system, so a machine running two M36 "partitions" could have 4 gb in each. Another limitation was the program size, could not exceed 64KB. If you had a program that was larger than that, you had to become creative in the later years when call/parm came into place, as you would move code into a called program, because if the base program was 63kb for example, you could easily call a 20kb called program. You also could not have more than around 8,000+ files on the machine. There were also restrictions on the number of files you could bring into a program (again, you could get around by putting files in called programs and passing the result back in. The maximum number of records you could initially load was about 8 million and the maximum a file could hold was about 16 million. None of these limitations exist in S36EE (there are a few maximum numbers of files in a program, but much larger than in native SSP).

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 (800/1600 bpi) or a 6157 1/4" cartridge (QIC) tape drive. A/36 computers have a high-density QIC drive but the 5.25" or 8" diskette drive (single) was optional as was a 9348-001 9 track (reel to reel) 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. $MAINT is the library utility, used in ALOCLIBR, BLDLIBR, FROMLIBR, LIBRLIBR, REMOVE, CONDENSE, LISTLIBR, and TOLIBR. $COPY is the file utility used in SAVE, RESTORE, COPYDATA, and LISTDATA. There are many other utilities, including $FBLD, $LABEL, $DUPRD, $INIT, $DELET, $HIST, $CNFIG, #GSORT, $PACK, and $PROF, which are more flexible at the program level than associated SSP procedures can be.

Configuring using CNFIGSSP

The CNFIGSSP 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 (stands for "fixed disk," since it is not a removable disk pack.)

To apply CNFIGSSP, the system must be dedicated (no other users logged on or programs running). The system must be IP Led (rebooted.) When IPL finished, the new devices would appear on the status display.

SDA - Screen Design Aid

Main article: 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 (in RPG these are called indicators) can cause fields to disappear or change colours.

SEU - Source Entry Utility

SEU is a text editor which allows data entry on a line-by-line basis. Special forms are used to assist the operator in keying RPG programs or other types of form-based languages (WSU, Sort, SDA, etc.)

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 ADDROUT. 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 (a process called execution) 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 (it wrote to the monitor) and also an input file (because it accepted the user's keyboard input). 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 (Terminate and Stay Resident) 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.

Object code formats

Cobol, Fortran, and RPG generated object code (type O). Basic was interpreted only; a compilation utility called BASICS created subroutine code (type R). Basic programs could be saved as sources for compatibility with other computers, but the project's text was preserved in the subroutine (unless the programmer used the LOCK parameter to keep it private.)

Procedures, which use OCL to start programs and assign resources to them, are type P.

Source members for all objects are type S, with the exception of Basic as above specified.

DFU programs generated subroutine (R) code. So did WSU programs.

Screen formats generated object code.

Menus generated object code. A menu is simply a very specific screen format with a companion message member suffixed with two-pound signs ("##") to contain the action to be taken when the associated number was chosen.

Popular SSP applications

• The Programmer and Operator Productivity Aid (POP) was a widely used development program. It was included with the Advanced 36.
• MAPICS, the Manufacturing and Production Information Control System.
• IMAS, a simple accounting package
• BPCS, a more advanced accounting system
• IBM Office/36 collection of programs (DisplayWrite/36, IDDU, Query, and so forth) were popular in the late 1980s and were later bundled with the Advanced/36. The System/34 Text Editor was a precursor to Office/36.
• The Britz Word Processing System was a general-purpose text editor that had mailmerge, label, and basic file editing capabilities.

System security

There are four types of security on an SSP system:

• Badge security.
• Password security.
• Resource security.
• Menu security.

Badge security is implemented using a stripe reader device attached to a 5250-series terminal. In order to log on, the user not only typed the user/password information but also swiped the badge through the reader.

SECEDIT

The SECEDIT procedure was used to work with User IDs and passwords. The user profile contains a 1-to-8-character alphanumeric User ID, a 4-character alphanumeric password, a code for the user's security rating – M (Master Security Officer), S (Security Officer), O (System Operator), C (Subconsole Operator), or D (Display Station Operator) – and a number of other default settings.

The SECEDIT RESOURCE procedure was used to establish security ratings for file, library, folder, and group objects. Access levels of O (Owner), C (Change), U (Update), R (Read), E (Execute) or N (None) could be granted for a user to a particular resource. A group object was a sort of holding company that owned one or more lower objects. For example, granting access to the group ACCOUNTG made it easier to establish access to all of the accounting files. Group objects could also reference group files; the group UB referenced UB.OLD, UB.NEW, UB.01, or any filename with the embedded period.

SECEDIT USERID was also used to confine a user's operational authority to a specific menu. By entering a Y for Mandatory Menu and specifying a default sign-on menu, the security officer could prevent the user from any program access not found on that sign-on menu. A user so confined could only run menu options, send messages, and sign off the system.

Other procedures

The PROF ("Profile") procedure was used to work with User IDs and passwords. The user profile contains a 1-to-8-character alphanumeric User ID, a 4-character alphanumeric password, a code for the user's security rating—M (Master Security Officer), S (Security Officer), O (System Operator), C (Sub Console Operator), or D (Display Station Operator) -- and a number of other default settings.

The PRSRCID ("Profile Resource Security by User ID") procedure was used to establish security ratings for file and library objects. Access levels of O (Owner), G (Change), R (Read), E (Execute) or N (None) could be granted for a user to a particular resource.

The printed disk catalogue (VTOC, Volume Table of Contents) displayed all secured objects with the notation 3 as being secured.

Files, libraries, and folders

SSP provides for two different data objects called files and libraries. Files contain records, almost always with a fixed record length. Libraries contain programs which can reference and access these files. SSP contained more than 80 different commands that allowed operators to create, delete, copy, edit/change, and secure files and libraries.

A library or a file must exist in a contiguous organization on one fixed disk (however, a library may contain one "extent" of roughly 50 blocks which must be reorganized, and it cannot be extended if allocated to other users). A file may be organized with an EXTEND value or it may be allocated with FILE OCL to automatically extend. All record adds/updates/deletes wait while the file is being extended. It is good sense policy to create extend values large enough to minimize the frequency of extends. Libraries could have "extents" that were not contiguous. At times, when compiling a program, an extent would be created and by doing a "CONDENSE", it was removed if there was enough room in the main allocation for it. Otherwise, one did an ALOCLIBR to reallocate the library to a bigger size.

Files on the S/36 may be Sequential (S), Direct (D), or Indexed (I). An indexed file can have multiple alternate indexes (X), and in fact, a sequential file may have alternate indexes placed on it so there is no primary index. An indexed file contains a key, which must be contiguous and may be up to 60 characters long; however, alternate indexes may have three-part keys which are not contiguous with one another. Duplicate keys in indexed or alternate index files may be allowed or disallowed. A file with direct organization is built with all records added and cannot auto-extend. A file with sequential or indexed organization is built with no records added. An alternate index always has as many records as its parent, as opposed to a System/38-style logical file which is built with conditions to filter records from the parent.

In 1986, support for Distributed Data Management Architecture (DDM) was added to SSP. This enabled System/36 programs to create, manage, and access record-oriented files on remote System/36, System/38, and IBM mainframe systems running CICS. It also enabled programs on remote System/36 and System/38 computers to create, access, and manage files on a System/36. The initial record-oriented file models defined by DDM were based on the System/36 file system.

Related operating systems

The System/3 (1969) ran a disk-based batch operating system called the System Control Program (SCP) (5702-SC1). IBM later introduced an online program for the System/3 named the Communications Control Program (CCP) which was started as a batch program. The IBM System/32 (1975) ran a disk-based operating system also called the System Control Program. The IBM System/38 (1978) ran an operating system named the Control Program Facility (CPF) that was much more advanced than SSP and not particularly similar.

Sources

• IBM Publication SC21-8299, General Information for SSP Operating System.

References

1. "IBM March - April 1977 Announcements: Operating System" (PDF). HP computer systems newsletter. June 1, 1977. p. 15.

External links

• Bitsavers Archive of System/34 Documentation - Including documentation on SSP
• Bitsavers Archive of System/36 Documentation - Including documentation on SSP