Systemstödsprogram

System Support Program (SSP)
System-36-ssp-main-menu.png
Huvudmeny för SSP 7.5, som visas inuti en TN5250-klient
Utvecklare IBM
Arbetstillstånd Avvecklad
Initial release 1977 ; 46 år sedan ( 1977 )
Plattformar System/34 och System/36 minidator

Standardanvändargränssnitt _
Kommandoradsgränssnitt
Licens Proprietär
Föregås av System/32 System Control Program (SCP)
Efterträdde av OS/400

System Support Program ( SSP ) var operativsystemet för minidatorerna IBM System/34 och System/36 . SSP var ett kommandobaserat operativsystem som släpptes 1977. SSP innehöll ursprungligen ett 60-tal kommandon som implementerades på System/34 från 1977 till 1983 i olika versioner som kallas releaser.

Historia

SSP innehöll ursprungligen ett 60-tal kommandon som implementerades på System/34 från 1977 till 1983 i olika versioner som kallas releaser. Release 1 gavs ut med originalet S/34 1977. Release 9 gavs ut 1981. 1983 packade IBM om SSP på en ny dator kallad IBM System/36 , som inte var objektkodskompatibel med S/34. 1994 packade IBM om SSP på en uppdaterad modell av S/36 kallad Advanced/36 . A/36 var en IBM AS/400 som hade SSP implementerad som en "virtuell maskin".

Viktiga utgåvor av SSP inkluderar:

  • S/34
    • S/34 Release 1.0 – detta var tydligen [ citat behövs ] skickades med den första S/34:an 1977.
    • S/34 Release 8.0 – detta verkar [ citat behövs ] ha utfärdats omkring 1980.
    • S/34 Release 9.0 – detta var den sista releasen för S/34 c.1980.
  • S/36
    • S/36 Release 1.0 – detta var tydligen [ citat behövs ] skickades med den första S/36 1983.
    • S/36 Release 2.0 – den här versionen stödde 8809-bandenheten.
    • S/36 Release 4.0 – detta var releasen där S/36 fick 5 jobbköer. [ citat behövs ]
    • S/36 Release 5.1 – denna version från 1988 var den sista större förändringen på 536X-plattformar.
    • S/36 Release 6.0 – även känd som VASP eller Value-Added Support Product [ citat behövs ] , denna utgåva lade till funktionalitet som möjliggjorde programanrop i RPG, och den tillhandahöll även programvara för att beräkna storleken AS/400 som användaren skulle behöva vid uppgradering. VASP var kontroversiell [ citat behövs ] . Rykten cirkulerade i branschtidningarna [ citat behövs ] att kunden inte kunde gå tillbaka till 5.1 om 6.0 inte fungerade tillfredsställande. Programsamtal med RPG CALL/PARM var sämre än RPGIII-designer och sämre än kundtilläggsprodukter. [ citat behövs ]
    • S/36 Release 7.1 – denna version från 1994 levererades med Advanced/36 (9402-236 modeller). De första A/36-maskinerna skulle inte fungera på en lägre version och var också inkompatibla med 7.5 (medan tekniskt sett, sann, programobjektkod från en 7.1-maskin skulle köras på en 7.5 och vice versa, plus att många 9402-236:or uppgraderades till 9402 -436, som de bytte ut moderkortet och installerade lite ny LIC-kod och du återställde på en kopia av dina filer och voila, allt fungerade). Rykten cirkulerade om att tidigare utgivningskompilatorer inte skulle fungera på Advanced/36, men de visade sig ogrundade. Det fanns anledningar till att en programmerare hellre skulle använda 5.1 RPGII-kompilatorn istället för den förmodligen mer avancerade 7.x-kompilatorn.
    • S/36 Release 7.5 – denna version från 1995 skickades med den andra och sista vågen av Advanced/36 (9402-436). Funktioner som WRKSYSVL gjorde det möjligt för operatören att ändra systemtiden i farten, vilket var intressant eftersom kundtillägg för att göra detta genom assemblersubrutiner inte fungerade på Advanced/36. Men assemblerrutiner för att göra saker som att öppna/stänga filer, hämta VTOC, etc. fungerade bra på 7.1 och 7.5
    • Guest/36 – det här är version 7.5, men du kan ställa in en M36 (en gäst) på en AS/400 (kör OS/400 V3R6 till V4R4), och den skulle fungera precis som 9402-436, förutom att dessutom för att ha denna gäst-"partition" hade du också OS/400 om du ville ha det. Så om 9402-436 som kom i 3 hastigheter 2102, 2104 och 2106 (som den senare var ungefär 2,7 gånger snabbare än basen) inte var tillräckligt snabb, kan du skaffa en 9406-xxx maskin och installera en "gäst/ 36" på en sådan. Och faktiskt kan du installera mer än en gäst/36. Det fanns vissa begränsningar för antalet anslutna arbetsstationer, men att ha två gäst/36:or som körs på en AS/400 och ställa in DDM (distributerad datahantering) mellan dem och även med OS/400 för att vara värd för stora filer, kunde lätt göras. Medan S/36 och A/36 för det mesta bara fungerade med twinax-anslutna terminaler, på en Guest/36 (eller M/36), kunde du ha alla dina terminaler på ett LAN som kör tcp/ip och vara virtuella enheter i gäst/36-miljön.
    • S36EE (S/36 exekveringsmiljö) – detta stöddes inbyggt på AS/400 och dess efterföljare (iSeries, IBM i), vilket gör att en användare kan fortsätta att köra sina s/36-program och procedurer utan att behöva konvertera dem. Många av systemprocarna fungerar också med sådana. Även om det vanligtvis var "långsammare" eftersom det måste gå igenom ytterligare steg, men idag med så snabba maskiner, är hastigheten för en S36EE många gånger snabbare än A/36 exekveringshastigheten. Exempel: ett jobb tog 12 minuter att köra på en Adv/36, tog 20 sekunder att köra i S36EE-läge. Objektkoden är dock INTE kompatibel med tidigare S/36 och A/36, vilket innebär att man var tvungen att kompilera om alla program och menyer. En fördel är dock att du inte bara kan köra S36EE utan även OS/400-applikationer. Du kan komma åt databastabeller i dina S/36-program, du kan anropa RPG/400- och RPGIV-program från med ett S/36-program. Så, även om det tekniskt sett inte är SSP, ser det ut som SSP, det fungerar som SSP, och det kommer att köra dina S/36-program/procs.

Begränsningar för operativsystemen S/36 och A/36 och M/36: Den maximala mängden diskutrymme som ett system kunde använda var 4 gb (per förekomst av operativsystemet, så en maskin som kör två M36 "partitioner" kan ha 4 gb i varje. En annan begränsning var programstorleken, fick inte överstiga 64KB. Om du hade ett program som var större än så var du tvungen att bli kreativ under de senare åren när call/parm kom på plats, eftersom du skulle flytta kod till ett anropat program, för om basprogrammet var t.ex. 63kb kunde du enkelt anropa ett 20kb anropat program. Du kunde inte heller ha mer än runt 8 000+ filer på maskinen. Det fanns också begränsningar för antalet filer du kunde ta med in i ett program (återigen, du kunde ta dig runt genom att lägga in filer i anropade program och skicka tillbaka resultatet. Det maximala antalet poster du initialt kunde ladda var cirka 8 miljoner och det maximala en fil kunde hålla var cirka 16 miljoner. dessa begränsningar finns i S36EE (det finns ett fåtal maximalt antal filer i ett program, men mycket större# än i inbyggt SSP).

Funktioner och komponenter

Med hjälp av SSP kan operatören skapa, ta bort och hantera S/34-36-objekt som bibliotek, datafiler , menyer , procedurer , källmedlemmar och säkerhetsfiler.

SSP innehåller moduler som DFU, SEU, SDA och WSU som tillåter operatörer att bygga bibliotek och filer, mata in information i dessa filer, producera enkla rapporter och upprätthålla en menystruktur som förenklar åtkomsten till informationen. Advanced/36 stöder inte WSU. Lösenords- och resurssäkerhet implementeras också genom SSP, liksom fjärrkommunikation, som idag liknar uppringt nätverk .

SSP är ett diskbaserat operativsystem . Datorprogram kan köras från den fasta disken, men inte från diskett eller band. Komplementet till en System/34 5340 eller System/36 5360/5362 är en fast diskuppsättning av en till fyra fasta diskar, minst en datorterminal och en 8" diskettenhet, valfritt utrustad med två magasinenheter som kan innehålla 10 disketter var och tre diskettplatser. AS/36 5363/5364 har en 5-1/4" diskettenhet. S/36-datorer kan konfigureras med en 8809 rulle-till-rulle-bandenhet (800/1600 bpi) eller en 6157 1/4" kassett (QIC)-bandenhet. A/36-datorer har en QIC-enhet med hög densitet men 5,25" eller 8" diskettenhet (enkel) var valfritt liksom en 9348-001 9-spårs (rulle till rulle) 1600/6250 bpi bandenhet.

Systemverktygsprogram

SSP-procedurer använder hjälpprogram, som i vissa fall kan vara mer användbara för datorprogrammeraren än själva SSP-procedurerna. $MAINT är biblioteksverktyget som används i ALOCLIBR, BLDLIBR, FROMLIBR, LIBRLIBR, REMOVE, CONDENSE, LISTLIBR och TOLIBR . $COPY är filverktyget som används i SAVE, RESTORE, COPYDATA och LISTDATA . Det finns många andra verktyg, inklusive $FBLD , $LABEL , $DUPRD , $INIT , $DELET , $HIST , $CNFIG , #GSORT , $PACK och $PROF , som är mer flexibla på programnivå än associerade SSP-procedurer kan vara.

Konfigurera med CNFIGSSP

CNFIGSSP - proceduren användes för att konfigurera systemet, inklusive enheterna. Varje enhet tilldelas ett ID med två tecken. Den första bokstaven måste vara alfabetisk; den andra måste vara alfamerisk. Systemet reserverade även vissa ID:n; enheten kan till exempel inte heta I1 eller F1. I1 är namnet på diskettenheten; F1 är vad systemet kallar hårddisken (står för "fixed disk", eftersom det inte är ett flyttbart diskpaket.)

För att tillämpa CNFIGSSP måste systemet vara dedikerat (inga andra användare är inloggade eller program som körs). Systemet måste vara IP-led (omstartat.) När IPL är klar visas de nya enheterna på statusdisplayen.

SDA - Skärmdesignhjälp

SDA tillåter operatören att bygga skärmformat eller menyer. Kommandotangenter kan aktiveras/inaktiveras. Inmatningsfält, utdatafält och konstanter kan skapas och konditioneras. Förhållanden (i RPG kallas dessa indikatorer ) kan göra att fält försvinner eller ändrar färg.

SEU - Source Entry Utility

SEU är en textredigerare som tillåter datainmatning rad för rad. Specialformulär används för att hjälpa operatören att skriva RPG-program eller andra typer av formulärbaserade språk (WSU, Sort, SDA, etc.)

SORT - Systemets sorteringsverktyg

SORT har en till åtta indatafiler, som kan ha vilken giltig postlängd som helst. Den har en utdatafil, av valfri angiven längd, som kan innehålla från noll till 8 miljoner plus poster.

En sortering kan innehålla hela poster eller bara 3-byte adresser som pekar på poster i en associerad fil. Detta kallades en adressfil eller ADDROUT . När du använder en Add-rutt läste programmet in dessa 3-byte adresser och hämtade sedan tillhörande poster från masterfilen.

WSU - Work Station Utility

Detta var ett RPG-liknande språk som kördes på SSP. Det var fokuserat på datainmatningsprogram. WSU var gratis, men det togs inte särskilt väl emot eftersom det var så begränsat.

DFU - Data File Utility

Det är en IBM-levererad kostnadsfri artikel som används för att visa och ändra fältvärden i enskilda poster.

DFU kan användas

  • av programmerare för att uppdatera databasfiler i farten utan att skriva program
  • av programmerare för att skapa enkla program för att utföra grundläggande operationer på en databasfil
  • av datainmatningspersonal för att lägga till eller ta bort poster från en fil, eller för att skriva ut poster.

Programmering

Operational Control Language (OCL)

Språkprogram på hög nivå kräver att OCL är aktiverat. OCL används för att ladda program i systemets minne och starta dem (en process som kallas exekvering) och tilldela resurser som diskfiler, skrivare, meddelandemedlemmar, minne och diskutrymme till dessa program. Andra förmågor, som att visa text på skärmen, pausa meddelanden och så vidare, gör OCL mer kraftfullt.

RPG II

RPG II modifierades från System/3 dagar för att ge tillgång till "WORKSTN-filen" för att tillåta ett hålkortbaserat språk att interagera med en person som sitter vid ett tangentbord och en bildskärm. En WORKSTN-fil var en utdatafil (den skrev till monitorn) och även en indatafil (eftersom den accepterade användarens tangentbordsinmatning). Således märktes den som en kombinerad-primär fil eller en kombinerad efterfrågefil.

Kommandotangenter blev RPG-indikatorer KA-KY, och olika former på skärmen kändes igen av olika osynliga kontrolltecken gömda i själva formulären. Eftersom användaren var tvungen att visa ett formulär på skärmen för att skriva, gav RPG II ett sätt för ett program att skriva utdata innan det accepterade inmatning. Många framgångsrika programmerare gick från att använda den kombinerade-primära WORKSTN-filen till att använda en kombinerad efterfrågefil, som hade operationskoder för att läsa och skriva displayen. Det fanns till och med ett sätt att koda för flera WORKSTNs; flera personer kunde logga in på samma kopia av samma program i minnet. Den största programstorleken var 64k.

Programattribut - MRT, SRT, NRT och NEP

MRT = Multiple Requestor Terminal-program. SSP kunde koppla upp till 7 terminaler till ett program samtidigt. Vilken operatör som helst kunde starta programmet på sin terminal, sedan skulle andra operatörers terminaler kopplas till när de valde samma program. Det maximala antalet terminaler som skulle servas var styrbart av programmeraren.

SRT = Single Requestor Terminal-program. Inte en MRT.

NRT = No Requestor Terminal-program. Startad vid en terminal släpper NRT den begärande terminalen och fortsätter. Detta liknar ett MS-DOS TSR-program (Terminate and Stay Resident). Per definition var alla program som framkallades eller skickades till JOBQ en NRT.

NEP = Never Ending Program. Detta var vanligtvis ett interaktivt MRT-program som skulle vänta efter att alla terminaler kopplats bort tills någon terminal återansluts, vilket undviker initieringskostnader. Detta användes vanligen för att tillåta att stora program implementerades som en kedja av små program som skulle skicka terminalerna från den ena till den andra samtidigt som de var redo att fortsätta bearbeta andra terminaler och/eller efterföljande transaktioner. NRT-program kan också vara NEP:er om de skrivs till loop och väntar på något tillstånd som indikerar att det finns arbete att göra. NEP-program slutade normalt inte förrän systemet stängdes av, såvida de inte skrevs för att känna igen något speciellt avslutningstillstånd.

Objektkodformat

Cobol-, Fortran- och RPG-genererad objektkod (typ O). Basic tolkades endast; ett kompileringsverktyg som heter BASICS skapade subrutinkod (typ R). Grundläggande program kunde sparas som källor för kompatibilitet med andra datorer, men projektets text bevarades i subrutinen (såvida inte programmeraren använde parametern LOCK för att hålla den privat.)

Procedurer, som använder OCL för att starta program och tilldela resurser till dem, är typ P.

Källmedlemmar för alla objekt är typ S, med undantag för Basic enligt ovan.

DFU-program genererade subrutinkod (R). Så gjorde WSU-program.

Skärmformat genererad objektkod.

Menyer genererad objektkod. En meny är helt enkelt ett mycket specifikt skärmformat med en medföljande meddelandemedlem med suffixet med två-pund-tecken ("##") för att innehålla åtgärden som ska vidtas när det tillhörande numret valdes.

Populära SSP-applikationer

  • Programmeraren och operatörens produktivitetshjälp (POP) var ett mycket använt utvecklingsprogram. Den ingick i Advanced 36.
  • MAPICS , tillverknings- och produktionsinformationskontrollsystemet.
  • IMAS, ett enkelt bokföringspaket
  • BPCS, ett mer avancerat redovisningssystem
  • IBM Office/36- programsamlingen (DisplayWrite/36, IDDU, Query, och så vidare) var populära i slutet av 1980-talet och buntades senare med Advanced/36. System/34 Text Editor var en föregångare till Office/36.
  • Britz ordbehandlingssystem var en allmän textredigerare som hade e-postsammanfogning, etikett och grundläggande filredigeringsmöjligheter.

Systemsäkerhet

Det finns fyra typer av säkerhet på ett SSP-system:

  • Badge säkerhet.
  • Lösenordssäkerhet.
  • Resurssäkerhet.
  • Menysäkerhet.

Märkets säkerhet implementeras med hjälp av en bandläsare som är ansluten till en terminal i 5250-serien. För att logga in skrev användaren inte bara användar-/lösenordsinformationen utan svepte även märket genom läsaren.

SECEDIT

SECEDIT-proceduren användes för att arbeta med användar-ID och lösenord. Användarprofilen innehåller ett alfanumeriskt användar-ID på 1 till 8 tecken, ett alfanumeriskt lösenord på fyra tecken, en kod för användarens säkerhetsklassificering – M (Master Security Officer), S (Security Officer), O (System Operator), C (Subconsole Operator), eller D (Display Station Operator) – och ett antal andra standardinställningar.

SECEDIT RESOURCE-proceduren användes för att fastställa säkerhetsklassificeringar för fil-, biblioteks-, mapp- och gruppobjekt. Åtkomstnivåerna O (Ägare), C (Ändra), U (Uppdatera), R (Läs), E (Execute) eller N (Ingen) kan beviljas för en användare till en viss resurs. Ett koncernobjekt var ett slags holdingbolag som ägde ett eller flera lägre objekt. Till exempel att bevilja åtkomst till gruppen ACCOUNTG gjorde det lättare att etablera åtkomst till alla redovisningsfiler. Gruppobjekt kan också referera till gruppfiler; gruppen UB refererade till UB.OLD, UB.NEW, UB.01 eller något filnamn med den inbäddade perioden.

SECEDIT USERID användes också för att begränsa en användares operativa behörighet till en specifik meny. Genom att ange ett Y för obligatorisk meny och ange en standardinloggningsmeny, kan säkerhetsansvarig förhindra användaren från någon programåtkomst som inte finns på den inloggningsmenyn. En användare som var så instängd kunde bara köra menyalternativ, skicka meddelanden och logga ut systemet.

Andra procedurer

PROF ("Profil")-proceduren användes för att arbeta med användar-ID och lösenord. Användarprofilen innehåller ett alfanumeriskt användar-ID på 1 till 8 tecken, ett alfanumeriskt lösenord på fyra tecken, en kod för användarens säkerhetsklassificering – M (Master Security Officer), S (Security Officer), O (System Operator), C (Sub Console Operator) eller D (Display Station Operator) -- och ett antal andra standardinställningar.

Proceduren PRSRCID ("Profile Resource Security by User ID") användes för att fastställa säkerhetsklassificeringar för fil- och biblioteksobjekt. Åtkomstnivåerna O (Ägare), G (Ändra), R (Läs), E (Execute) eller N (Ingen) kan beviljas för en användare till en viss resurs.

Den tryckta diskkatalogen (VTOC, volymförteckning) visade alla säkrade objekt med notationen 3 som säkrade.

Filer, bibliotek och mappar

SSP tillhandahåller två olika dataobjekt som kallas filer och bibliotek. Filer innehåller poster, nästan alltid med en fast postlängd. Bibliotek innehåller program som kan referera till och komma åt dessa filer. SSP innehöll mer än 80 olika kommandon som gjorde det möjligt för operatörer att skapa, ta bort, kopiera, redigera/ändra och säkra filer och bibliotek.

Ett bibliotek eller en fil måste finnas i en sammanhängande organisation på en fast disk (ett bibliotek kan dock innehålla en "omfattning" på ungefär 50 block som måste omorganiseras, och det kan inte utökas om det allokeras till andra användare). En fil kan vara organiserad med ett EXTEND-värde eller så kan den allokeras med FILE OCL för att automatiskt utökas. Alla poster lägger till/uppdateringar/tar bort vänta medan filen förlängs. Det är sunt förnuftspolicy att skapa förlängningsvärden som är tillräckligt stora för att minimera frekvensen av förlängningar. Bibliotek kunde ha "omfattningar" som inte var sammanhängande. Ibland, vid sammanställning av ett program, skapades en omfattning och genom att göra en "KODENSERING" togs den bort om det fanns tillräckligt med utrymme i huvudallokeringen för det. Annars gjorde man en ALOCLIBR för att omfördela biblioteket till en större storlek.

Filer på S/36 kan vara sekventiell (S), Direct (D) eller Indexerad (I). En indexerad fil kan ha flera alternativa index (X), och i själva verket kan en sekventiell fil ha alternativa index placerade på sig så det finns inget primärt index. En indexerad fil innehåller en nyckel som måste vara sammanhängande och kan vara upp till 60 tecken lång; dock kan alternativa index ha tredelade nycklar som inte gränsar till varandra. Duplicerade nycklar i indexerade eller alternativa indexfiler kan tillåtas eller förbjudas. En fil med direkt organisation byggs med alla poster tillagda och kan inte utökas automatiskt. En fil med sekventiell eller indexerad organisation byggs utan att några poster har lagts till. Ett alternativt index har alltid lika många poster som dess överordnade, till skillnad från en logisk fil i System/38-stil som är byggd med villkor för att filtrera poster från föräldern.

1986 lades stöd för Distributed Data Management Architecture (DDM) till SSP. Detta gjorde det möjligt för System/36-program att skapa, hantera och komma åt postorienterade filer på fjärrsystem/36, System/38 och IBM stordatorsystem som kör CICS . Det gjorde det också möjligt för program på fjärrsystem/36- och System/38-datorer att skapa, komma åt och hantera filer på en System/36. De initiala postorienterade filmodellerna definierade av DDM var baserade på System/36-filsystemet.

Relaterade operativsystem

System /3 (1969) körde ett diskbaserat batchoperativsystem kallat System Control Program (SCP) (5702-SC1). IBM introducerade senare ett onlineprogram för System/3 med namnet Communications Control Program (CCP) som startades som ett batchprogram. IBM System/32 (1975) körde ett diskbaserat operativsystem även kallat System Control Program. IBM System/38 (1978) körde ett operativsystem som heter Control Program Facility (CPF) som var mycket mer avancerat än SSP och inte särskilt likt.

Källor

  • IBM-publikation SC21-8299, Allmän information för SSP-operativsystem.

externa länkar