Grunderna i RPG-free: För gamla och nya PRG-programmerare
By Åke H Olsson
()
About this ebook
RPGLE används för IBM Power Systems och operativsystemet IBM-i.
Från att ha varit ett kryptiskt, kolumnorienterat programspråk skriver man nu program i ett fritt format som gör det lätt att läsa och förstå för utvecklare som kommer från andra miljöer och operativsystem.
Åke H Olsson
Åke H Olsson är IT-konsult med specialisering på systemarkitektur, metoder och standards. Han arbetar förutom med systemutveckling också som utbildare, artikelförfattare samt föreläsare.
Related to Grunderna i RPG-free
Related ebooks
Fortfarande Inte din farfars "AS/400": Varför IBM i är - kanske den bästa - plattformen för moderna affärssystem Rating: 0 out of 5 stars0 ratingsQGIS på Svenska Rating: 0 out of 5 stars0 ratingsInDesign - En grön bok för gröngölingar: Gör en bok! Rating: 0 out of 5 stars0 ratingsTeams - En grön bok för gröngölingar Rating: 0 out of 5 stars0 ratingsMicrosoft Excel - En grön bok för gröngölingar: För version 2019 /Office 365 Rating: 0 out of 5 stars0 ratings
Reviews for Grunderna i RPG-free
0 ratings0 reviews
Book preview
Grunderna i RPG-free - Åke H Olsson
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