System Support Program

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

System Support Program (SSP) is the operating system of the IBM System/34 and System/36 minicomputers. SSP was released in 1977. ==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 numeric. 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 , 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=== 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 . 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. ==Sources== IBM Publication SC21-8299, General Information for SSP Operating System. ==External links== Bitsavers Archive of System/34 Documentation - Including documentation on SSP Bitsavers Archive of System/36 Documentation - Including documentation on SSP

Text derived from https://en.wikipedia.org/w/index.php?oldid=1375165893 under CC BY-SA 4.0; modifications have been made.