Grunderna i RPG-free: För gamla och nya PRG-programmerare

förstå.

Några grunder

Program är en av många typer av objekt i IBM-i. Det är den enda typ av objekt som kan exekveras (köras) och program kan bara skapas av systemfunktioner i IBM-i.

Som alla andra typer av objekt så lagras program rent logiskt sätt i mappar - eller som det kallas i IBM-i Libraries (bibliotek eller Collections). Detta är en en-nivå struktur där varje system i princip kan ha så många libraries som man kan hitta på namn för.

Som alla andra typer av objekt så namnsätts program också med maximalt tio tecken varav det första måste vara en bokstav och då övriga bokstäver eller siffror. (Stora eller små bokstäver gör ingen skillnad).

Program skapas på följande sätt:

Man skapar källkod och sparar någonstans - det kan vara i så kallade källkodsfiler eller i PC-format i den så kallade IFS:en (integrated file system). Man kan skriva källkod i vilken textredigerare som helst men RDI är den som rekommenderas starkt! I RDI kan man köra hela utvecklings och testprocessen direkt i verktyget.

Man kompilerar källkoden och om kompileringen går igenom OK är i vart fall programkoden utan uppenbara syntaxfel. Finns det fel visas de lätt sökbara om man använder RDI i annat fall skapas en kompileringslistan som man kan ögna igenom på skärmen eller (om man inte bryr sig om ifall några träd stryker med) skriva ut. Finns det inga fel skapas ett objekt av typ modul.

Genom ett kommando kan systemet skapa ett program av en eller flera moduler. Modulerna kan vara skrivna i olika programmeringsspråk (CL, C, COBOL, RPG...). Det är däremot alltid en av dessa som man pekar ut som innehavare av den procedur (den programkod) som först får kontrollen när programmet så småningom körs.

Något kort om källkodsfiler

Dessa skapas genom kommando CRTSRCPF (Create Source Physical File) och man anger då:

Vad filen ska heta. Jag rekommenderar följande för RPG-kod:

QRPGLESRC – för sådan källkod som ska kompileras till program

QRPGLEMOD – för sådan källkod som ska kompileras till moduler,d.v.s. hjälpfunktioner och procedurer som ska länkas samman med program.

Var (vilket bibliotek) filen ska hamna rent logiskt

Record (rad)-längd. Här är defaultvärdet 92 vilket är alldeles för litet. Eftersom vi inte ska jobba med programkoden i grönskärm – varför inte dra till med litet mer för att kunna få mer utrymme att skriva kod på. Ta mins 112 tecken här.

Text – en beskrivande text som talar om vad filen har för syfte.

Det finns fler parametrar men normalt sett klarar man sig bra med dessa.

Källkodstyper

När man skapar sin källkod anger man en av följande källkodstyper:

RPGLEFör kod som inte innehåller SQL

SQLRPGLEFör kod som har med 𔄢embedded SQL detta gör att en preprocessor" kallas in vid kompileringen.

Vad är en modul???

En modul innehåller kompilerad kod i något programspråk. Program innehåller också kompilerad kod men det finns en grundläggande skillnad.

Det handlar om referenser, adresser och sådant. I modulen är de delarna inte riktigt klara ännu - om vi till exempel har i vår programkod ett anrop till en procedur X så kommer man inte i modulkoden att se exakt var den här proceduren finns någonstans - om den finns i någon annan modul som bakas in i programmet, om den finns i ett så kallat service program eller på annat sätt. Allt sådant fixas till när programmet skapas senare och då läggs adressen till proceduren in på rätt ställe.

Det är på liknande sätt med mycket annat. Modulen är liksom ett halvfabrikat i programskapandet.

Strukturen på en modul kodad i RPG

Options för hela modulen. Definitioner som styr på en övergripande nivå.

Globala definitioner. Beskrivning av filer, variabler och strukturer som gäller för hela modulen.

Entry procedure det vill säga programkod som körs när ett program startar. OBS detta gäller enbart om den aktuella modulen är startmodul för programmet (eller till och med enda modul för programmet).

Ett godtyckligt antal sub-procedurer (eller sub-funktioner) som var och en kan innehålla lokala variabler och filer samt alltid innehåller en del kod. Får och returnerar värden via parametrar.

Ett litet exempel

Ctl-opt dftactgrp(*no); // Gör att programmet får innehålla procedurer och funktioner

Dcl-s talet zoned(5:0); // Definierar ett fem siffror långt heltal

Dcl-s roten zoned(15:5); // Definierar ett tal med femton siffror varav fem decimaler

For talet = 1 to 99999; // Skapa en loop som körs ett antal gånger och där en variabel får olika värden

Roten=Kvadratrot(talet);

// Anropa proceduren Kvadratrot med talet som parameter och få svar i variabel roten

EndFor; // Slut på loopen

Return; // Avsluta programmet

Dcl-proc Kvadratrot; // Börja definiera proceduren

Dcl-pi Kvadratrot zoned(15:5); // Definiera hur svaret ser ut

In_Tal zoned(5:0) const; // Definiera hur parametern in ser ut

End-pi; // Klar med gränssnitts beskrivning

Return(In_tal ** 0,5); // Ge svaret som talet upphöjt med en halv vilket är kvadratroten.

End-proc Kvadratrot; // Slutparentesen

Här kan man sedan lägga in (nästan) så många procedurer och funktioner som man vill eller behöver.

Det som kan hända är däremot att just den funktion som utförs i Kvadratrot behövs i fler program. Kanske i riktigt många. Av den anledningen skapar man därför gärna procedurbibliotek där man samlar olika sådana gångbara funktioner. På det sättet kan man göra det enklare och enklare att skapa program om man kan använda sådant som redan är gjort (och då gärna av någon annan).

Aktiveringsgrupper???

Fundera inte så mycket på det just nu. Det är tills vidare bara ett sätt att hantera det minnesutrymme som en process använder. Detta med aktiveringsgrupper är ett av många begrepp som ingår i konceptet ILE. Låt oss stanna där för tillfället.

Strukturen på källkoden till ett program

Om man skriver kompletta program (till skillnad mot samlingar med hjälpprocedurer) är det här (i princip) hur man strukturerar källkoden:

Sedan kommer all vanlig programkod för programmets huvudslinga. Här läser, skriver, bearbetar och uppdaterar vi data från olika källor. Presenterar kanske för användare via något gränssnitt eller skickar meddelanden till andra system. Allt beror liksom på...

Sedan kommer programkoden för proceduren. Allt avslutas med ett RETURN (eventuellt med ett variabelnamn om proceduren returnerar ett värde om i exemplet med Kvadratrot).

CTL-OPT nyckelord och parametrar

Först litet grand allmänt om Control Options:

Man behöver inte alltid ha med denna spec. överhuvudtaget. Ofta kan det dessutom vara så att man har ställt in på en övergripande nivå så att det finns en default variant som alltid kommer med.

Man kan också ha skapat en Copy Source som man instrueras att alltid lägga in och som innehåller de specifikationer som gäller för den aktuella installationen.

Här nedan följer vad man ska göra om man ska skriva control options själv - och sanningen att säga är det i allmänhet inte så mycket som man behöver ha med i de flesta fall.

Jag rekommenderar att vi börjar med en ensam rad som bara innehåller:

CTL-OPT

Och inget mer. Det blir enklare att underhålla