R A M P / FM Ram Program For File Management Inhoudsopgave Dokumentatie 1. Inleiding............................................... 1 2. Toepassingsgebied - mogelijkheden & beperkingen......... 2 3. Generatieproces & voorbeeldsessie....................... 3 4. Menukeuzen in het programma............................. 4 5. Kombineren van RAMP-bestanden........................... 6 Appendix A) Hardware-konfiguratie: SCREENDF................ 7 , , B-1) Remarks-bestand.............................. 8 , , B-2) Variabelen-beschrijving...................... 8 , , B-3) Struktuurbeschrijving RAMP/FM................ 9 , , C) Uitbreidingsmogelijkheden binnen RAMP.......... 10 Š RAMP/FM D O K U M E N T A T I E 1. Inleiding File management, bestandsbeheer dus, is een alom bekend toepassingsgebied van een mikro. Omdat bestanden het beste op schijfjes opgeslagen worden, en CP/M hiervoor een goede standaard is, bestaan er honderden CP/M-programma's voor "Data (base) management", gewoon een elektronisch kaartsysteem dus. Ook in het public domain zijn er een aantal. Door de aard van de (hobby-) gebruikers zijn ze veelal wel aanpasbaar voor vele toepassingen, maar dat moet de hobbyist zelf doen in de programmasource. Dat is een groot verschil met kommerciee"ele 'DBMS'-programma's; daarbij is de aanpassing (parametrisering) op hoger, gebruikersvriende- lijker, nivo geplaatst. RAMP/FM is volledig gericht op hobbygebruikers, maar moet toch zonder veel programmeerkennis te installeren zijn. Het pakket is namelijk, net als professionele File Managers, volledig geparame- triseerd. Oftewel: door (met een generator-programma) een 'blok' velddefinities aan te maken, kan een RAMP/FM -programma een aantal bewerkingen op het gedefinieerde recordtype/bestand uit- voeren. Dit bestand is echter niet bedoeld om voor de gebruiker een "lossstaande" kaartenbak te automatiseren. (Dit zou een pro- gramma met alle professionele mogelijkheden vergen.) Nee, RAMP/FM werkt met "hulpbestanden": bestanden die een onderdeel vormen van een totale applikatie. Dit soort bestanden vergt vaak minder bewerkingen dan een komplete kaartenbak, omdat hun informatie deels alleen relevant is via opname in andere rapporten. Hierdoor kan b.v. het RAMP-programma zonder sorteermo- gelijkheid; in de zeldzame gevallen dat die nodig is, kan een losse utility of een (trage) extra module hulp bieden. Ook de afdrukmogelijkheden van RAMP zijn beperkt tot een recht-toe- recht-aan lijst. De kracht van RAMP/FM is dat het voor deze stukken van een programmasysteem de ontwikkeltijd sterk bekort. Het pakket is als het ware een bibliotheekje van standaardroutines, die alle basisfunkties uitvoeren. De routines zijn zo sterk "geparametriseerd" als in MBASIC maar mogelijk is; hierdoor wordt de kracht van routine-bibliotheken die je in Compilers kent benaderd. Ook de komputer-onafhankelijkheid binnen de CP/M (en MS-DOS) wereld is zo groot mogelijk: elke terminal met Š kursoradressering en "Clear Screen" moet aanstuurbaar zijn. RAMP/FM is ontwikkeld vanuit de behoefte van de auteur aan standaardroutines voor hulpprogramma's. De eerste aanzet werd gegeven toen binnen enige tientallen uren "quick and dirty" een komplexe batchverwerking, met twee sterk gelijkvormige hulpbe- standen, gemaakt moest worden. In een tweede applikatie werden de fundamenten nader uitgewerkt; toen er nog meer toepassingen aankwamen, is RAMP/FM ontwikkeld. Dit proces, en het zenden naar public domain, is versneld door een 'programmeerwedstrijd' van de Nederlandse CP/M- user group. Geen van de afzonderlijke subroutines en idee"en in het pakket is echt nieuw. De samensmelting van het geheel in deze onderlinge verhoudingen, en de gehele programmastruktuur, is wel "origineel". Idee"en over de parametrisering, de schermopbouw en 1 de invoer komen uit verschillende kommerciee"le generatoren. De zoekroutines behoren tot de standaard komputerliteratuur. Variabelen-namen en struktuur zijn, zoals gezegd, 'eigen'; er is dan ook veel Hollands in terug te vinden. Een vertaling van de schermteksten, en misschien ook de variabelen, behoort tot de mogelijkheden. De ontwikkeling van RAMP/FM vond plaats op een ITT 2020 onder Apple CP/M. Dit verklaart mede de orie"ntatie op RAM inplaats van op (i.c. kleine en trage) diskettes. Zoals gezegd moet het systeem echter op alle CP/M-systemen, en zelf op vele MS-DOSsers, kunnen draaien. Alle MBASIC-varianten, en evenzeer Personal Basic, moeten mogelijk zijn; ook een compiler moet suksesvol zijn (en de snelheid fors verhogen). De diskettekapaciteit mag klein zijn, aangezien de bestandsgrootte door het RAM gelimiteerd wordt. Veel sukses met de installatie en werking! Amsterdam, december 1983 Erik de Ruijter 2. Toepassingsgebied - Mogelijkheden en Beperkingen RAMP/FM is gebaseerd op het komputer- R(andom) A(ccess) M(emory). Oftewel: weliswaar wordt een bestand op schijf opgeborgen, maar elke mutatie en opvragen gaat pas na inlezing van de hele inhoud in RAM. Bij de start van RAMP wordt het bestand ingelezen, en bij het einde vervangt de nieuwe inhoud het oude bestand. Deze werkwijze is ongunstig bij een enkele mutatie, en voordelig bij grote updates. Qua integriteitsbewaking is het systeem erg gunstig: zowel een diskette-crash tijdens schrijven als stroomuitval tijdens de RAM-update hebben beperkte schade. De bestandsstruktuur op schijf is erg belangrijk, aangezien de Š "hulp"bestanden makkelijk in andere (b.v. rapport-) programma's moeten passen. Vandaar dat RAMP/FM een "hybride" struktuur kent: de records hebben een vaste lengte, maar zijn toch ook (snel!) sequentieel in te lezen. Dit wordt gerealiseerd door de records een 'inhouds-lengte' te geven gelijk aan de som der veldlengten; achter elk record staan bovendien nog een en -karakter. De lengte van het direkte bestand is zodoende (recordlengte+2). Het eerste fysieke record bevat uitsluitend de bestandsgrootte (aantal inhouds-records); een getal, gevolgd door zoveel spaties dat de recordlengte juist is. RAMP/FM kent vele "voorgekookte" onderdelen, waarin geen keuzen meer gemaakt hoeven te worden; er is bijvoorbeeld geen eigen scherm-ontwerp mogelijk. Een essentiee"ele beperking, die programmatechnisch veel voordelen inhoudt, is dat RAMP geen andere sortering kent dan de volgorde op hoofdsleutel. Ook een zoek gaat alleen "gei"ndexeerd" met de sleutel; andere zoekmogelijkheden zijn aanwezig, maar hiervoor moet (snel, weliswaar) het hele bestand worden doorlopen. Die sleutel is simpelweg het eerste veld in het record (en op het scherm). Een record bevat maximaal 97 velden; hun theoretische maximumlengte is 50, maar voor de key is 20 (!) veiliger. Van de velden kun je de volgende gegevens specificeren; in het volgende hoofdstuk volgt hiervan een voorbeeldsessie. * Veldnaam (max. 20 tekens) * Afdrukpositie op de lijst; eventueel 0 - niet afdrukken 2 * Numeriek / alfanumeriek; indien numeriek, dan maximale absolute waarde * voor numerieke velden: opslag / afdruk kan 'right-justified', met nullen aan de linkerkant opgevuld, zijn. Nu zal onderhand duidelijk worden dat RAMP zich het beste leent voor vrij kleine records; door de standaard-schermindeling wordt bij grote records (scrollen) het overzicht lastig. Bovendien is het nodig dat de sleutel voor de gebruiker "logisch" is, en niet steeds moet worden afgeleid uit andere velden; RAMP zelf kan immers geen op die velden gesorteerde lijst aanmaken. Zoeken op andere velden kan hij wel, dus "kunstmatig gekree"erde sleutels" zijn, bij kleinere bestanden, nog werkbaar. Wat desondanks zeker niet zal slagen is het aloude "NAW-etikettenpro- gramma". Juist bij adressen is namelijk het afdrukken en sorteren in meerdere volgorden essentieel. Kleine bestanden zijn zeker ni'et vereist, ondanks de begrenzing van het RAM. Nu is die begrenzing bij een 64 K - machine toch al ruim, juist omdat kleine records het soepelste werkt. Maar mocht het bestand niet passen, dan kan een opsplit- sing in twee of meer deelbestanden ook werkbaar zijn. In dat Š geval moeten die bestanden namelijk onderling verdeeld zijn in gebieden "sleutel-1 t.m. sleutel-2", "sleutel-2 t.m. sleutel-3", enz. Het hoofdprogramma dat deze hulptabellen hanteert, moet dan van deze verdeling 'op de hoogte zijn'. Het bereiken van deze taakverdeling bij de aanmaak van de bestanden, en het handhaven bij bestandsgroei, is moeilijk. Daarom wordt bij RAMP/FM een hulpprogramma meegeleverd, "Joinramp", dat meerdere RAMP-bestan- den samenvoegt en in nieuwe ordent. Dit wordt in een eigen hoofd- stuk beschreven. 3. De programmageneratie: een voorbeeldsessie RAMP/FM pretendeert minder programmeursgericht te zijn dan Public "Databaseprogramma's"; juist het generatordeel heeft dan ook een transparante kijk op de programma's. Het is mogelijk om een RAMP-programma te genereren zonder de principes van MBASIC en het 'mergen' te kennen. Voor wie ze wel kent, is het anderzijds mogelijk om efficie"nter te genereren. Vandaar dat in deze handleiding, aan het eind, beide wijzen behandeld worden. Voor de dialoog is geen programmakennis nodig; die beschrijven we dan ook algemeen. De generatie start met MBASIC RAMPGEN. (Even aangenomen dat het programma RAMPGEN al voor je komputer gei"nstalleerd is - zie bijlage A.). Dit vraagt ten eerste om de programmanaam. Dit wordt niet alleen de naam die (voorlopig) aan je programma op schijf gegeven wordt, maar ook de naam die het hoofdmenu hanteert. In ons voorbeeld moet je een tarieventabel gaan verwerken. Vandaar dat dit programma TARIEVEN heten gaat. Vervolgens mag je de auteursnaam invoeren. Voordat we de velden gaan definiee"ren, nu eerst een over- zichtje van wat de gebruiker in ons voorbeeld wil. Hij heeft de tarieftabel nodig bij een faktureringssysteem, en wenst de volgende velden: * Tariefkode - 10 alfanumeriek * Tariefnaam - 25 , , * Omzetgroep - 15 , , * Prijs - 5 numeriek (centen) 3 In dit geval antwoordt je dus bij de vraag "aantal velden" 4. De vragen die je dan per veld krijgt zijn niet al te moeilijk. Om de kode, de sleutel, te nemen: Lengte 10, Naam "Tariefkode", Printpositie 3 (voor de anderen 14, 41 en 60 - uitgaande van mooie kolommen), Numeriek 0. Er komt nu geen vraag over opvullen met nullen. De overige velden beantwoord je analoog. Alleen bij de Prijs, die numeriek is, komt er een 5e vraag: "Opvullen met 000 ?". In Š dit geval antwoord je met J, omdat bedragen op een lijst beter keurig aangelijnd kunnen staan. Voor volgnummers o.i.d. kan het betere antwoord echter best N luiden. Na de velddefinitie berekent RAMPGEN voor je het aantal records wat er maximaal in RAM past. Handig voor als je echt verkeerd uitkomt, maar dat zal niet snel gebeuren; zeker niet als je vantevoren alles doorrekende (bijlage A.). Dan vraagt het programma om de kop voor de lijst in te vullen. Daarvoor heb je een regel van 80 posities; boven die regel wordt met kruisjes aangegeven op welke kolommen je velden beginnen. Bij TARIEVEN is dat op 3, 14, 41 en 60. De kop die je zou invoeren wordt dan ook iets als " Tariefkode Tariefnaam Omzetgroep Prijs". Na deze informatie start de aanmaak van het parameterbestand. Wanneer je niets te maken wilt hebben met Basic-regels, kun je zometeen als volgt aan de slag: SYSTEM SUBMIT RAMPMERG MBASIC TARIEVEN.ASC . Voor de kenner nu een wat soepeler manier: met RAMPGEN heb je aangemaakt een bestand TARIEVEN.PAR. Dit bestand nu is het "parameterblok" wat gemerged moet worden met RAMP/FM.ASC, en waarschijnlijk ook nog met RAMPARAM.ASC (systeemparameters). Vervolgens kun je dit geheel in tokenized vorm saven als "TARIEVEN", zodat je later kunt volstaan met "MBASIC TARIEVEN". Een soortgelijke koppeling kun je zonodig aanbrengen met JOINRAMP.ASC. Dit alles kun je samengevat ook zien in de file RAMPMERG.SUB, die bedoeld is voor de niet-experts. 4. Menukeuzen Nu alle koncepten duidelijk zijn en je een proefprogramma hebt gegenereerd, kan het RAMP-programma besproken worden. Dit start met de vraag naar de bestandsnaam. Gewoonlijk voer je hier een reeds bestaande naam in. Deze wordt dan geladen; na alle verwerking wordt onder dezelfde naam teruggeschreven. Nu echter zul je moeten starten zonder een bestand te laden, want dat ga je juist maken. Daartoe kun je NO! intypen. Nu kom je in het hoofdmenu, dat je gewoonlijk pas na de laadtijd bereikt. Dit menu bevat bovenaan en onderaan twee "informatiebalken". De bovenste geeft slechts je programmanaam, TARIEVEN; om te oderscheiden van andere RAMPen. Onderaan staat zinnige informatie: hoeveel van de maximaal hoeveel records er in gebruik zijn (nu dus 0), en in welk bestand (nu, voorlopig, NIEUW.DAT). De keuzen zullen we nu stuk voor stuk doornemen. Het PRINTEN betreft een recht-toe recht-aan uitdraaien, op sleutelvolgorde, van je bestand. Hierbij wordt de kop aangehouden 4 Š die je zelf gedefinieerd hebt, en staan ook de kolomposities reeds vanuit de generatie vast. De enige vragen nu betreft het afdruk-bereik. Je mag de eerste en de laatste af te drukken sleutel opgeven; betekent gewoon 'vanaf 1' en 'tot maximum'. Het is niet mogelijk om absolute volgnummers van de records op te geven; deze worden in het hele programma 'afge- schermd', omdat ze veranderlijk zijn. (Bij het afdrukken kun je misschien merken dat de bladzij-scheurlijnen niet overeenkomen met de koppen. Dit is te verhelpen; zie appendix B-2.) Keuze 2 van het hoofdmenu omvat de meeste taken. Deze UPDATE - keuze vraagt je (steeds) om een sleutelwaarde. Deze waarde wordt opgezocht; wanneer hij niet bestaat, neemt RAMP/FM aan dat je deze sleutel wilde TOEVOEGEN. (Of je dat nu wilde of niet; zo nee, dan troep invoeren en direkt erna killen.) Je kunt nu veld voor veld de waarden gaan invoeren. Daarbij wordt gelet op lengte en, bij numerieke velden, op grootte. Daarnaast mag een numeriek veld (natuurlijk, bij Basic) geen komma bevatten; om precies te zijn alleen maar cijfers, de punt en eventueel vooraan een minnetje en spatie. Het eventuele opvullen met 0 zie je pas na alle invoer gebeuren. Dan krijg je onderaan dezelfde vragen als bij wijzigen; zie zometeen. RAMP neemt aan dat je opvraagt, en eventueel wilt WIJZIGEN, wanneer de sleutel bestaat. Hij toont nu alle velden, met onderaan een aantal keuzen. De keus 'S' - scroll wordt altijd getoond, ook wanneer er minder dan 10 velden zijn; hij heeft echter alleen een, logische, betekenis bij grote records. De keus 'K' - kill is ook vrij logisch; hiermee kun je dit record volledig uit het bestand verwijderen. Hiervoor wordt nog even bevestiging gevraagd, want weg is weg... Links van de velden staan hun veldnummers getoond. Wanneer je e'e'n van deze nummers ingeeft, wordt de veldwaarde gewist. Je kunt dan een nieuwe invoeren, op dezelfde manier als bij komplete invoer. Bij deze veldnummers staat ook de 1; oftewel, het is mogelijk om de sleutelwaarde te wijzigen. Het gevolg hiervan zou zijn dat de 'relatieve plaats' van het record in het bestand wijzigt; de sortering wordt dus aangepast. Twee keuzen vragen om toelichting, omdat het onderscheid wat moeilijk is. Keus 99 betekent 'gereed met wijzigen - ga direkt terug naar hoofdmenu'. Keus 98 daarentegen stuurt je terug naar de aktiviteit waar je vandaan kwam. In de nu besproken gevallen is dat gewoon de vraag naar de sleutel (i.c. tariefkode), en van daaruit kun je met 999.. ook naar het hoofdmenu. De keus is echter ook bruikbaar bij zoek-operaties; dan is het effekt afwijkend. Op naar de volgende hoofdmenu-keuze: 3 - ZOEKEN. De keuze is zowel simpel als krachtig. De eerste vervolgvraag betreft het aantal zoek-velden. Het moet wel raar lopen als je drie of meer nodig hebt om een record uniek te identificeren, maar het kan. Voor al deze velden moet je de exakte waarde opgeven zoals je die wilt vinden. Deze mag dus niet korter of langer zijn dan de gezochte, en ook geen onderdeel. ('t Is een harnas - appendix B-4 Š geeft programmeurs uitwegen.) Na alle zoekwaarden gaat RAMP op zoek naar het record; hij begint gewoon bij de eerste (laagste sleutel), en vergelijkt stuk-voor-stuk. Wanneer hij wat vindt, 5 toont hij dit record alsof je het via de sleutelwaarde had opge- vraagd. Je kunt dan ook wijzigingen aanbrengen e.d. Daarna kun je in dit wijzig-menu aangeven wat je wilt: verder zoeken (98) of stoppen(99). In het eerste geval wordt de zoek voortgezet vanaf het gevonden record, en kunnen er dus meerdere getoond worden. Vangt hij bot, dan krijg je dit net zo te horen als wanneer er helemaal niets bestond. De laatste keuze van het hoofdmenu is 4: OPBERGEN. Je werkbestand wordt nu opgeborgen onder dezelfde naam als je laadde. Dit gebeurt middels een "tijdelijk bestand": er wordt weggeschreven in een hulpbestand, dat dus extra disketteruimte vergt. Pas als alles voltooid is, wordt je oude bestand gewist en vervangen door het werkbestand. Dan stopt het programma. Had je desondanks verder gewild met een ander werkbestand, dan is het krachtige woordje RUN voldoende... 5. Kombineren van RAMP-bestanden Onderaan paragraaf 2 is het principe van de "merge" reeds uiteengezet. Om te rekapituleren: - een aantal invoerbestanden, alle natuurlijk op sleutel gesorteerd, wordt gelezen; - een (even groot of kleiner, naargelang de invoergrootten) aantal uitvoerbestanden wordt aangemaakt. Deze heten RAMPOUTA.DAT, RAMPOUTB.DAT, enz. - aan het uitvoerbestand wordt steeds toegevoegd het laagste record op dat moment uit alle gelezen invoerbestanden; - zodoende kan uiteindelijk worden gezegd dat de uitvoerbestanden geen 'overlappende gebieden' meer hebben, maar juist aansluitende gebieden. De werking van het programma (in het voorbeeld TARIEVEN.JOY geheten; zelf te maken met JOINRAMP.ASC) wijst zich vanzelf: het vraagt alleen om het aantal invoerbestanden en de namen daarvan. Vervolgens gaat het hard aan de slag (uitgaande van voldoende schijfruimte..), en toont op het scherm waarmee het bezig is. Het geeft geen informatie op het scherm waar precies de bestandsgren- zen liggen, omdat die weer gewist wordt. Noch doet het dit op papier, want niet iedere gebruiker heeft een printer en heeft deze informatie hard nodig. Een module hiervoor is echter simpel toe te voegen. Vreemd genoeg zal dit programma niet veel gebruikt worden in het soort applikaties waar RAMP/FM voor gemaakt is. Hulpbestanden Š plegen namelijk zelden enorm groot te worden. Het is echter, door zijn strukturering, misschien ook best in te passen in applikaties met andere bestanden: de 'echte' grote kaartenbakken, en/of adresbestanden. Wanneer deze (vanwege sorteervoordelen o.i.d.) met een in RAM muterend programma werken, kennen ze dezelfde begrenzingen als RAMP/FM-bestanden. Deze zijn te overwinnen met een programma dat sterke gelijkenis vertoont met, en eventueel te ontwikkelen is vanuit, JOINRAMP. Zodoende ontstijgt het RAMP/FM File Management - systeem toch de 'enge begrenzingen' waarvoor het bedoeld is... 6 Appendix A) Hardware-konfiguratie: SCREENDF RAMP/FM is binnen CP/M hardware-onafhankelijk. Althans, de claim is dat het kan werken op elk systeem met 64 K RAM, MBASIC en een terminal met mogelijkheid tot scherm wissen (opdracht) en kursoradressering. Hiertoe kent RAMP/FM een parameterblok, de regels 60 t.m. 90. Dit blok is konstant voor een bepaald type komputer en terminal. Oftewel: het blok kan bij veel distributiekanalen voor Public Domain - software het beste door de distributeur aangeleverd worden. Vandaar dat deze appendix voor veel gebruikers niet interessant is: wanneer op de diskette een bestand RAMPARAM.ASC is meegeleverd, zal ook RAMPGEN wel goed zijn en kun je de installatiefase overslaan. Die installatiefase vraagt vanzelfsprekend om de nodige kennis over schermkarakteristieken. Teneinde niet perse' ook foutloze invoer- en leesvaardigheid te vragen, is er een SCREENDF - programma; dit doet echter niet veel meer dan vragen om character- en functiespecificaties. Daarom zullen we stuk voor stuk de vereiste specificaties doorlopen; het invoeren hiervan kan vervolgens eventueel met SCREENDF gebeuren. * Clear screen (regel 60). De variabele CLS$ moet in de opdracht PRINT CLS$ zorgen voor scherm wissen en 'home cursor'. Op veel terminals is dit in een opdracht (escape + ..) verenigd. Het kan soms echter ook nodig zijn om twee keer escape met een volgkarakter "aaneen te plakken". (Het extreem voor lastige terminals, 24 X line feed, gaat zeker niet; dan zou het programma op veel plaatsen wijziging vereisen.) * Cursor-adressering (regel 70). De funktie FNADR$ met als argumenten (Y-coo"rdinaat, X-coo"rdinaat) moet de cursor positioneren. Deze funktie wordt altijd gebruikt in vormen als PRINT FNADR$(5,10);"Geef keus: ". Š * Tweede lettertype (regel 80). Voor terminals die een tweede tekstsoort kennen (bright, dim, inverse) maakt RAMP daar gebruik van om het scherm duidelijker te vullen. Hiertoe dienen de kodes SSI$ (scherm-shift-in) en SSO$ (shift-off). De naam suggereert dat ze gelijk moeten zijn aan de ASCII-kodes shift-in en shift- off (resp. 15 en 14), maar dat zal niet eens zo vaak opgaan. De SSI$ is bedoeld om tekst "er uit te laten springen", inverse o.i.d., en de SSO$ om de mode terug te zetten. Gek genoeg hebben sommige terminals een "bright" start-up manier, en een stuurkarakter voor "dim" tekst. In dit geval is het fraaier om een extra regel (50 o.i.d.) toe te voegen die op 'dim' instelt; de SSI$ wordt dan de 'bright'-kode, en de shift-off de 'dim'. * Geheugen-maximum (regel 90). De variabele SMM (storage MaximuM) geeft aan hoeveel RAM er door MBASIC wordt vrijgegeven voor programma en data; dit is het gegeven "xx bytes free" dat na het opstarten vrijkomt. (Te vergroten door de optie /F:1 te geven; RAMP gebruikt maar een enkel file-kanaal.) Dit getal wordt gebruikt door RAMPGEN om de vrije bestandsruimte te bepalen; wetende dat RAMP/FM voor zichzelf en voor hulptabellen plm. 13500 bytes (zonder REM - zie appendix B-1 !) vraagt, wordt het maximale aantal records bepaald. Appendix B-1 Remark-bestand 7 In de drie B-appendices komt de technische opbouw van RAMP/FM tot uitdrukking. Een generator die zulke 'open-ended' programmatuur oplevert, moet immers goed dokumenteren hoe er wijzigingen en aanvullingen mogelijk zijn. Na deze overzichten van de struktuur geeft appendix C) uiteindelijk enige suggesties voor vaak benodigde wijzigingen. Wat vrij snel zal opvallen, is dat het RAMP-programma zelf geen enkel REM-statement bevat. Dit is een bewuste keus, gemotiveerd door de RAM-beperkingen. Om e'n een uitgebreid menu te bieden, e'n de variabelen "zelfdokumenterend" te houden, e'n een redelijk RAM voor bestanden vrij te houden, moesten REM's worden weggelaten. Aangezien dit "redelijke RAM" altijd nog 13 a' 14 K is, zullen er echter genoeg applikaties zijn die hier alle ruimte aan hebben. Wanneer een RAMprogramma nog plm 6 K kan 'missen', wordt het zinnig om REM's toe te voegen. Hiervoor wordt op diskette een apart bestand meegeleverd, RAMP/FM.REM. Deze ASCII-file kan gewoon in Basic gemerged worden met het RAMpro- gramma. Deze REMarks zijn er voornamelijk op gericht om tijdens Š bestudering van de listing toelichting te geven. Door de versnippering van opmerkingen over het bestand is het moeilijk om hiermee een totaaloverzicht te krijgen, ook wanneer je de REM- file 'los' leest. Dat totaaloverzicht moet je dan ook kunnen verkrijgen vanuit de volgende twee appendices. Appendix B-2 Variabelen-beschrijving Aangezien op moment van schrijven geen cross-reference utility (op het juiste disketteformaat) beschikbaar was, kan hier slechts een "globale" variabelenbeschrijving volgen. Veel velden worden niet individueel genoemd, maar hun taak is "gekenschetst" door de eerste letter van hun naam. Individuele uitleg is vaak nog te vinden in de REMarks. C - weinig gebruikt. Haast alleen CLS$ (clear screen) komt voor F - gereserveerd voor funkties. De 3 gebruikte funkties staan in regel 70 (zie ook appendix A), 1150 en 1160 I - Invoerparameter. Worden overal gebruikt om de subroutine op 15000 aan te sturen. L - lokale variabelen. Mogen geen langere 'levensduur' hebben dan een paar regels (lus-teller), of binnen een algemene subroutine. N - duidt op "generatie-parameters". Staat voor number of gewoon naam. P - printparameter. PLEN geeft de Page Length in regels; de overige P's komen, logisch, vooral in de subroutine op 5000 voor. R - alleen gebruikt bij REC$ - de tabel met bestandsinhoud S - scherm; alleen in R. 90 ook "storage". SSI$ en SSO$ komen veel voor (appendix A); ook SBAS (scherm-scroll-basis) en SNR (scherm-invoernr) worden veelvuldig gebruikt. V - veld-parameters, opgegeven bij de generatie. Alleen VINH$ en VZOEK$ (R. 1120) hebben een 'dynamische' invulling. W - variabelen i.v.m. werkbestand. Alleen nuttig rond 1250 en in de subroutines van 3000 en 4000 ; alleen WERKREC is "globaler", omdat die de RAM-vulling aangeeft Z - Zoekvariabelen. ZVIND$ en ZTAR geven de resultaten van de binaire zoek op R. 14300. De overigen blijven binnen de "subroutines" (zowel de echte zoek op 14300 als de zoek-hulp op 8 10000, met 14600). Appendix B-3 Struktuurbeschrijving RAMP/FM kent een geplande regelstruktuur. Zonder nu een komplete regelnummer-crossing te willen geven, is het toch nuttig om de hoofdlijnen daaruit te dokumenteren. Daarbij moet onderscheid gemaakt worden tussen drie soorten programma- onderdelen: Š - Hoofdmenu en hoofd-routines voor de menukeuzen - Initialisatie- en eindigroutines - Veelvuldig gebruikte subroutines. De subroutines zullen straks opgesomd worden met hun "gebruikers". Nu eerst de initialisatie en beeindiging. Deze gebeurt in het begin. 60 Tot en met 90 zijn de apparatuur- parameters; 110 t.m. (uiterlijk) 1110 de generatie-parameters. 1120-1200 Betreft de initialisatie zoals die alleen voor RAMP/FM, en niet voor JOINRAMP e.d., geldt. Dan gebeurt tussen 1250 en 1350 de opstart; de subroutine op 3000 helpt hierbij. Na het hoofdmenu gebeurt op 4000 de afsluiting; dit is een subroutine, die echter een "END" bevat... Het hoofdmenu zelf op 1500 is duidelijk genoeg. De hoofdkeuzen, waarnaar het verwijst, zijn als volgt: * Afdrukken - Regel 5000-5270. Deze gebruiken een kopafdruk- subroutine op 14500. * Opvragen/toevoegen: primair op 7500. Het toevoegen gebeurt op 8500, terwijl daarbij op 8900 "ruimte wordt gemaakt". Daarna kom je weer terecht in het update-blok, op 8000. Wanneer hierbij om vernietiging gevraagd wordt, kom je terecht op 9000 en 9200. Wanneer je de sleutel wilt wijzigen, en zodoende de sortering overhoop gooit, is de routine op 9500 nodig. * Zoeken: Regel 10000 - 10320 reiken hiervoor de hulpmiddelen aan. Ze hebben eigen subroutines op 14400 en 14600. De subroutines vanaf 14000 zijn als volgt te kenschetsen: 14000 = Display 10 velden. Nodig bij wijzigen (8000) en invoer (8500) 14100 = Opsplitsing gevonden record in werk-tabel VINH$. Wordt gebruikt in 8000 en 5000. 14200 = Samenvoeging gewijzigd record tot REC$-element. Nodig in 8500 en 8000. 14300 = Binaire zoek. In alle werkroutines nodig. 14400 = Vertoning zoekvelden - nodig in 10000 . 14500 = Afdrukken kop - nodig in 5000. 14600 = Zoekroutine speciaal voor 10000 . 14700 = Veld-invoer (met 'supervisie' op 15000) - nodig voor 8500 en 8000 (invoer nieuwe waarden) 15000 - 16250 : De algemene invoerroutine waar vrijwel elk veld geINPUT wordt. Deze valideert op lengte, cijfers en control- karakter. Alleen voor Ctrl-C is hij kwetsbaar door de INPUT$ op 15250. Er bestaan MBASIC-varianten, of POKE's, die een karakter lezen zonder zich in Ctrl-C te verslikken. 9 Š Appendix C) UITBREIDINGSMOGELIJKHEDEN binnen RAMP Deze appendix is slechts bedoeld voor enige suggesties. Idee"en over op welke plaatsen een RAMP/FM-programma nogal eens aanpas- sing zal behoeven, en waar dat vrij simpel kan. Dit zonder de basisstruktuur, en de beperkingen zoals in de inleiding genoemd, wezenlijk aan te tasten c.q. te overschrijden. En zonder zoveel toe te voegen dat de N.REC omlaag moet, omdat het programma meer RAM opeet. Een eerste "customization" is mogelijk binnen de zoekroutine op 10000. Deze biedt namelijk veel 'wijdere' mogelijkheden dan het gemiddelde RAMprodukt nodig heeft. Is daardoor dus ook vrij "traag" (nog bliksemsnel in vergelijking met floppy!) in de zoek; dit komt vooral doordat de vergelijking per karakter via de MID$-funktie moet gebeuren, i.p.v. een gewone Basic = . Wanneer de zoekvelden altijd gelijk zijn, moet de subroutine op 14600 te missen zijn. Dan kan gewoon door op 10110 de LV in het programma vast te leggen; 10190-10220 kan vervallen, en rond 10260 moeten een paar vergelijkingen met MID$ komen. In het lijstformaat zijn natuurlijk ook vele wijzigingen mogelijk. Hiervoor moet eventueel de kop op 14500 vervangen worden; verder kan de 'kern' op 5200-5220 nogal versleuteld worden. Een mogelijkheid is b.v. een vulling van de array VPR.POS met "koo"rdinaten" voor horizontale en vertikale plaats, i.p.v. de tabulaties van nu. (Een extra array kan ook, natuurlijk.) Daarnaast is er een programmaprodukt van dezelfde auteur op deze Public Domain-diskette aanwezig: 'Republic', een rapportgenerator. Deze kan ook met RAMP/FM-bestanden werken, dus is bruikbaar als aanvulling hierop. Een laatste suggestie gaat eigenlijk de grenzen van RAMP/FM te buiten, maar zal wel eens nodig zijn. Sorteren op nevenvelden kan dan wel niet binnen RAMP, maar niemand verbiedt je om buiten het systeem om met een utility te werken. De vaste recordlengte vergemakkelijkt dat, en een goede utility kan de "teller" wel ongewijzigd terugschrijven. Vervolgens kan RAMP dienen voor uitsluitend het afdrukken; dan moet je bij de afdruk twee keer geven (van begin tot eind). Wat ook kan, is alleen het regelblok 5000-5100 wijzigen zodat je geen sleutels, maar abso- lute volgnummers opgeeft. Dat is dan een permanente wijziging in je RAMprogramma, die niet altijd een verslechtering zal zijn. En in extremo kun je natuurlijk ook een RAMP-versie maken die direkt na inlezen een RAM-sort (bubble o.i.d.) uitvoert. Deze versie is dan ook uitsluitend tot afdrukken in staat; of je moet een indextabel opbouwen, maar dan ruil je de extra gebruiksmogelijkheid in voor een decimering van de snelheid die in RAMP/FM zo voorop staat...