Juha Puranen kertoi taannoin aineistojen aggregoinnin tuottavan
joillekin data-analyysin opiskelijoille kohtuuttomia hankaluuksia ja
toivoi, että tehtävää voitaisiin jollain tavoin helpottaa. Survossahan
on aggregointiin kaksikin operaatiota, FILE AGGRE
ja FILE AGGR
.
FILE AGGRE
on vanhempaa perua. Sen avulla havaintoja yhdistellään
laskemalla keskiarvoja tai summia. Aggregoidun tiedoston rakenne on
täsmälleen sama kuin alkuperäisen. Tämä tietää aloittelijalle
vaikeuksia, mikäli esimerkiksi lasketaan keskiarvoja yhden tai kahden
tavun muuttujista. Myös se, että kaikki muuttujat kopioidaan vaikka vain
aktiiviset aggregoidaan, aiheuttaa päänvaivaa: varsinaiset aggregoidut
tulokset voivat jäädä jonnekin epäoleellisen muuttujajoukon keskelle.
Puuttuvat havainnot tuovat FILE AGGRE
:n käyttöön vielä omat ongelmansa.
Kokenut Survo-käyttäjä väistää tietysti nämä karikot, mutta aloittelija
voi aikaansaannoksistaan hämmentyä.
Uudempi, vasta vuodesta 1993 mukana kulkenut FILE AGGR
tarjoaa
aggregointiin aivan erilaisen lähestymistavan. Siinä jokainen valittu
muuttuja voidaan aggregoida eri tavalla, vaikka useammallakin tavalla
samaan aikaan, ja jopa valita lähtöaineiston havaintoja ehdollisesti
jokaista aggregointia kohden. Missään muussa Survon toiminnossa ei ole
käytettävissä niin paljon erilaisia aineiston valintaa koskevia
vaihtoehtoja kuin FILE AGGR
:issa.
Runsaan tarjonnan vuoksi FILE AGGR
-operaation syntaksikin on
vaativampi. Aggregointisäännöt kuvataan erityisellä VARIABLES
-kaaviolla,
johon on rivejä kirjattava vähintään niin monta kuin halutaan muuttujia
uuteen tiedostoon. Myös tulosmuuttujien tyypit voidaan säätää
muuttujakohtaisesti, joskin operaatio osaa myös itse tehdä järkeviä
päätelmiä, esimerkiksi valita keskiarvoille soveltuvan neljän tavun
muuttujatyypin.
FILE AGGR
:in varsinainen runsaudensarvi on kuitenkin sen tuntemien
aggregointifunktioiden valikoima. Summien ja keskiarvojen lisäksi
voidaan laskea ja käsitellä havaintojen lukumääriä, keskihajontoja,
minimejä, maksimeja, aggregaatin ensimmäisiä ja viimeisiä arvoja,
puuttuvia havaintoja, mediaaneja tai yleisemmin fraktiileja,
järjestysnumeroita, muiden muuttujien arvoja, trimmattuja keskiarvoja,
korrelaatioita ja jopa yhden muuttujan regressiomalleja!
Järjestystunnuslukujen käsittelystä johtuen aineisto täytyy järjestää
ennen aggregointia. Tämä täytyy käyttäjän tehdä FILE SORT
-operaatiolla.
Pienenä miinuksena FILE AGGR
:in kohdalla voidaan pitää sitä, että se ei
millään tavoin ota kantaa muuttujakuvauksiin; uudet muuttujat esiintyvät
paljaina, vaikka niitä voisi kommentoida esimerkiksi tiedolla mistä
muuttujasta ne on saatu ja millä funktiolla.
Molemmissa aggregointiohjelmissa on puolensa, mutta aloittelijan
kannalta olisi mukavaa, jos aggregointi sujuisi yhtä helposti kuin
FILE AGGRE
:lla ja toimisi yhtä hyvin kuin FILE AGGR
:illa. Missään
tapauksessa ei kannata alkaa pohtia kummankaan operaation kohentamista,
sillä Survon perusperiaatteiden mukaisesti olemassaolevia moduleita ei
muuteta; ainoastaan voidaan lisätä täsmennyksiä, joilla voidaan vanha
moduli ohjata tarvittaessa uusille urille. Se ei tässä kuitenkaan auta
mitään, sillä aloittelijaa ei paljoa helpota, jos täytyy lisäksi muistaa
kirjoittaa jotain lisätäsmennyksiä.
Onneksi ratkaisu on yhtä lähellä kuin lähin toimituskenttä:
tämänkaltaiset ongelmat ovat omiaan sukrokielellä ratkaistaviksi. Idea
on yksinkertaisesti "liimata" olemassaolevia operaatioita toisiinsa ja
tarjota tällä tavoin käyttäjälle helpotusta. Tällaisten sukrojen
tekeminen ei ole edes kovin vaikeaa. Kokeneena Survo-käyttäjänä ja
sukrojen tekijänä oheisen /AGGRE
-sukron laatiminen ei kestänyt paria
tuntia kauempaa. Enemmän aikaa kului sen jälkeen käyttöohjeen
viimeistelemiseen, sukron testaamiseen ja pieneen viilaamiseen.
Sukrolle kannattaa tekovaiheessa varata oma hakemisto ja toimituskenttä,
kuten alla D:\S\AGGRE\AGGRE.EDT
. Se selkiyttää työskentelyä, testausta
ja varmuuskopioiden tekoa. Kun vielä laittaa kentän viitelistaan tai
työvalikkoon, niin pääsee nopeasti työn ääreen. Sukronhan voi tallettaa
muuallekin, kuten tässäkin esimerkissä tehdään. Testitilanteita
kannattaa kerätä talteen, joko kentän loppuun tai erilliseen
testauskenttään. Kun tekee muutoksia sukrokoodiin, kannattaa aina ajaa
testit läpi, vaikka olisikin "varma", että koodi nyt toimii. Testien
ajaksi on usein hyödyllistä säätää sukro askeltavaan moodiin, jolloin
ehtii varmasti nähdä missä mennään kiville. Toiminnan näkymisen
piilottavaa {disp off}
-koodia ei tietenkään kannata käyttää niin kauan
kuin sukro on työn alla. Lopuksi sitä voi {disp reset}
-parinsa kanssa
lisäillä harkinnan mukaan, jos haluaa rauhoittaa ajonaikaista näkymää.
Koodia {disp on}
tulee käyttää vain grafiikkatilasta poistumiseen, joten
sitä ei tässä tarvita lainkaan.
Toimituskenttä, jossa sukrokoodia kehitetään, on muistettava tallettaa.
Sukrokoodin talletus (TUTSAVE
-komennolla) on sekin tärkeää, mutta vasta
kun alkaa testata sukron toimintaa. Toimituskentän ominaisuuksia
kannattaa hyödyntää, esimerkiksi värjätä tärkeitä kohtia koodista
varjomerkkien avulla. Tässä FORM
-nappi (F5
) ja etenkin sukro /S
ovat
hyödyksi kuten yleensäkin. Varjomerkit ovat vain omaksi hyödyksi,
TUTSAVE
ei niistä piittaa.
Tämän lyhyen johdannon jälkeen voinemme yrittää siirtyä sukrokoodin
tarkasteluun. Usein kannattaa ottaa jokin olemassaoleva sukro pohjaksi
ennemmin kuin alkaa kirjoittaa koodia tyhjästä. Tyypillisesti otan
lähtökohdakseni jonkin viimeaikaisen sukroni, tällä kertaa päädyin
keväällä tekemääni /LOGREG
-sukroon. Ei siitä paljoa tainnut jäädä
loppujen lopuksi jäljelle, mutta tietyt perusrakenteet kyllä. Niiden
kirjoittaminen joka kerta uudelleen on turhauttavaa ja virhealtista.
Sukrokoodi alkaa parametrien tarkistuksilla. Koska päädyin valitsemaan
komennon syntaksin FILE AGGR
:in perusteella, sain varautua tutkimaan
hieman BY
- ja TO
-sanoja. Kuten huomataan, sukro on riveillä 16 ja 20
sallivainen kelpuuttaessaan myös pienellä kirjoitetut välisanat.
Sekamuotoja ei kuitenkaan suvaita (ei pidä mennä liiallisuuksiin).
|
|
Jos kyseessä on paluu väliaikaisesta kentästä (parametrina Return
),
kenttää ei aleta uudelleen tallettaa (tällöin menetettäisiin
mahdollisuus palata aiempaan työhön) vaan suoritetaan nöyrästi paluu
Back
-kohdan kautta. Muissa tapauksissa talletetaan nykyinen kenttä
väliaikaisten tiedostojen levylle nimellä AGGRE
. Rivi 11 toistuu
useimmissa sukroissa kentän nimeä lukuunottamatta täsmälleen
samanlaisena. Aivan alussa, rivillä 9 ehdittiin tätä ennen jo nopeuttaa
vauhti äärimmilleen ja varmistaa sukrolle jatkon kannalta järkevät
olosuhteet.
Mikäli parametreja ei ole annettu riittävästi tai laisinkaan, tai on
annettu kysymysmerkki, johdatetaan käyttäjä avustustekstin äärelle. Jos
sen sijaan em. BY
- tai TO
-sanoissa on jotain vialla, mennään
virheilmoitusten puolelle. Jos kaikki näyttää olevan kunnossa, päästään
aloittamaan varsinainen työ kohdasta Start
.
Avustustekstiä varten pohjustetaan riittävän kokoinen toimituskenttä,
johon teksti sitten kirjoitetaan. Riveistä ei kannata tehdä liian
pitkiä, jotta ne TUTLOAD
-komennolla tai DD
:lläkin näyttäisivät hyvältä.
Sivua vaihtaessaan sukro ottaa talteen tekstiblokkina komennon mallin
kentän toiselta riviltä. Sitä se tulee hyödyntämään lopuksi
End1
-kohdassa.
|
|
Sellaisilla kommenttiriveillä, jotka alkavat def
-sanalla, on erityinen
merkitys: ne määrittelevät sukromuistipaikoille nimet. Vain erittäin
harvoin on syytä käyttää raakoja nimiä W1
, W2
, jne. Kunnon nimet
kertovat selvästi mistä on kysymys missäkin tilanteessa. /AGGRE
:n
parametrit varaavat ensimmäiset viisi muistipaikkaa, joista on tässä
nimetty joka toinen. Sanoja BY
ja TO
vastaavat paikat on jätetty
käyttämättä, vaikka ne olisi voinut ottaakin mihin tahansa käyttöön.
Seuraavat kolme (Wx
, Wy
ja Wz
) ovat muistipaikkoja, joita /AGGRE
käyttää
moniin erilaisiin tehtäviin.
Tyylinäni on nimetä sukron tuntemien täsmennysten tarvitsemat
muistipaikat ao. täsmennyssanoilla, isoilla kirjoitettuina, tosin
tyylini näyttää horjuvan MASK
- ja VARS
-täsmennysten osalta. Joka
tapauksessa täsmennysten mahdolliset arvot talletetaan heti aluksi
{save spec}
-koodeilla ennen kuin ne häviävät kentän tyhjennyksen
yhteydessä. Väliaikaisten tiedostojen hakemisto otetaan talteen omalla
koodillaan. Sitä tullaan tarvitsemaan, kun tiedostoja aletaan käsitellä.
Koskaan ei saisi väliaikaisia tiedostoja tehdä käyttäjän hakemistoihin,
poikkeuksena ehkä matriisitiedostot, jotka kuitenkin pitäisi nimetä niin
että ne voi lopuksi tuhota.
Koska /AGGRE
-sukro toimii sekä SURVO 84C:ssä että SURVO 98:ssa (muttei
kuitenkaan SURVOS-versiossa), tutkitaan missä Survossa ollaan ja
toimitaan sen mukaisesti. Pyritään tekemään riittävän suuri kenttä;
leveyssuunnassa vaatimuksen asettavat mahdolliset VARS
ja
MASK
-täsmennykset - pituussuunnassa aktiivisten muuttujien lukumäärä.
Niitä ei kuitenkaan tässä mittailla vaan kentän haluttu koko on pelkkä
arvio. Yleensä tällaisissa sukroissa ei pidä luottaa käyttäjän nykyiseen
kenttään vaan kannattaa tehdä INIT
-komennolla uusi.
Kun uusi kenttä on luotu, sen alkuun kirjoitetaan paluukomento siltä varalta, että jotain menee pieleen ajon aikana ja käyttäjä jää työkenttään. Paluumahdollisuus aiempaan pitää varmistaa, sillä käyttäjä ei ole välttämättä edes tallettanut kenttäänsä vaan lähtenyt uhkarohkeasti kokeilemaan hänelle ennestään tuntematonta sukroa. Näin ei tietysti kannattaisi tehdä vaan aina pitäisi ensin laittaa työ talteen ja sitten vasta antautua seikkailemaan. Tämä on se tapa, jolla Survossa ns. undo- eli eiku-toiminto on aina käytettävissä.
|
|
Jos muuttujat oli aktivoitu täsmennyksillä VARS
tai MASK
, niin niistä
jompikumpi (ensisijaisesti VARS
) kirjoitetaan työkenttään. Muussa
tapauksessa käsitellään jatkossa kaikkia aktiivisia muuttujia
(valintahan voidaan tehdä myös FILE ACTIVATE
-toiminnolla).
Työtiedostojen nimet talletetaan sukromuistipaikkoihin Wtmp1
ja Wtmp2
.
Nykyinen kursorin sijainti laitetaan muistiin. Tällaisia numeroin
merkittyjä muistipaikkoja sukroilla on käytössään kahdeksan. Harvoin
tarvitaan niin monta. Jos luulee tarvitsevansa enemmän, pitää ehkä
suunnitella sukronsa paremmin.
Tiedoston rakennekuvaus aktiivisten muuttujien osalta otetaan esiin
FILE STATUS
-komennolla. Parametri 1
tuo kenttään vain ensimmäisen
sarakkeen aktivoinnit. Se ei olisi välttämätöntä tässä. Ensin etsitään
varsinaisen muuttujalistan alku rivien 91-92 silmukalla. Tekstiblokin
määrittely aloitetaan heti kun avainsana FIELDS:
on löydetty ja
siirrytty ensimmäisen muuttujan kuvauksen alkuun. Sen jälkeen vain
kuljetaan listaa alaspäin, kunnes saavutetaan sen loppu (rivin alussa
sana END
). Matkalla tarkkaillaan, onko aggregointimuuttuja (se, jonka
suhteen aineisto halutaan aggregoida) aktiivisena eli onko se mukana
listassa. Jos on, Wz
saa arvon yksi (se nollattiin alussa rivillä 90).
Blokki saadaan valmiiksi ja se tuhotaan, jolloin se on käytettävissä
neljällä block-napin painalluksella myöhemmin. Sukro palaa talletettuun
paikkaan ja tyhjentää kentän siitä alaspäin. Jos Wz
edelleen on nolla,
eli aggregointimuuttujaa ei löytynyt aktiivisten muuttujien joukosta, on
virheilmoituksen aika.
|
|
Seuraavaksi tarkistetaan täsmennykset AGGRE
, TYPE
ja FREQ
. Yhtäkään
niistä ei tarvitse antaa, siispä kaikille tarvitaan oletukset.
Sukrokoodi {save spec}
tallettaa tyhjää ({}
), jos ao. täsmennystä eli
spesifikaatiota ei ole lainkaan annettu. Näillä ehdoilla asetetaan
oletusarvot täsmennyksille riveillä 104, 117, 118, 125 ja 128.
TYPE
-täsmennyksen oletusarvo riippuu täsmennyksestä AGGRE
: jos lasketaan
puuttuvien arvojen lukumääriä arvolla NMISS
, varataan vain kahden tavun
muuttujat - muissa tapauksissa oletuksena on muuttujatyyppi N4
.
AGGRE
-täsmennyksen muista kuin alla näkyvistä arvoista annetaan
virheilmoitus. TYPE
saa aina jonkin arvoista 1
, 2
, 4
tai 8
.
FREQ
-täsmennyksellä kerrotaan lukumäärämuuttujan nimi. Nimittäminen jää
käyttäjän vastuulle, mikäli oletusarvo FREQ
ei kelpaa. /AGGRE
ei
vaivaudu tarkistamaan, onko annettu muuttujanimi millään tavoin
kelvollinen.
|
|
Useimmiten sukrot pysyvät työkentässään, kun ovat sellaisen saaneet
tehtyä. Toisinaan on kuitenkin perusteltua palata hetkeksi alkuperäiseen
kenttään ja tehdä joitakin toimintoja siellä. Paluu tapahtuu kutsumalla
apusukroa SUR-RESTORE
, kun ensimmäiseen sukromuistipaikkaan on asetettu
nimi, jolla on aiemmin kutsuttu SUR-SAVE
-sukroa.
Riveillä 139-147 tapahtuu kaksi jatkon kannalta oleellisen tärkeää asiaa: aineiston aktiiviset muuttujat kopioidaan uudeksi aineistoksi, joka puolestaan lajitellaan vielä uudeksi aineistoksi. Keksitkö syyn alkuperäiseen kenttään palaamiseen? Aktiiviset muuttujathan olivat tiedossa työkentässäkin, joten mitä alkuperäisessä on sellaista mitä työkentästä puuttuu?
|
|
Kuten varmaan keksitkin, alkuperäinen kenttä saattaa sisältää n kpl
täsmennyksiä, joilla halutaan rajata aineistosta aggregoitavaksi vain
osa havainnoista. Rajaaminen voidaan tehdä IND
-, CASES
- ja
SELECT
-täsmennysten avulla, joista viimeksi mainittu tuottaa sukroille
eniten päänvaivaa, se kun voi koostua vaikka kuinka monen IND
- tai
CASES
-tyyppisen alkeisehdon yhdistelmästä. Nämä kaikki erilliset
täsmennykset tarvitsisi raahata {save spec}
-tekniikalla työkenttään.
Yksinkertaisinta on palata hetkeksi alkuperäiseen kenttään, joka alussa
talletettiin ja toimia siellä.
Kenttähän on tallessa, joten sitä voi sotkea vapaasti. Kannattaa
kuitenkin olla tarkkana eikä suinpäin rynnätä tekemään esimerkiksi
lisärivejä tarvittavia komentoja varten. Pitää muistaa, millä logiikalla
täsmennykset käsitellään. Ensimmäisellä sijalla on aktivoitavan rivin
perässä oleva kommenttialue. Sen sukro tässä tallettaa
sukromuistipaikkaan Wline
, mikäli kommenttia ilmaiseva kauttaviiva
riviltä löytyy.
Rivillä 137 näkyy eräs sukrokoodin idiomi: rivin lisäystä edeltää
koodipari {d}{u}
. Kannattaa miettiä mitä tapahtuu, jos painaa nappia
alt-F9
näkyvän ikkunan viimeisellä rivillä. Seuraavaksi kannattaa
miettiä mitä sitten tapahtuisi, jos Survon editorin toimintaa
muutettaisiin niin ettei ylimääräistä {d}{u}
-koodia tarvittaisi. Eli
kirjoittamaton sääntö oli: kirjoita aina {ins line}
-koodin eteen {d}{u}
(tähän asti se oli kirjoittamaton, nyt kirjoitettu). Sattumoisin samalla
lyhyellä rivillä on toinenkin huomionarvoinen kohta. Nimittäin koodia
{home}
ei pidä käyttää, ellei ole ehdottoman varma mitä tekee. Jos ei
ole varma, pitää käyttää sen sijaan koodia {line start}
, vaikka se onkin
pidempi kirjoittaa.
Lisää idiomeja: mitä ihmettä tehdään riveillä 139-142? Pyrkimys on
luonnollisesti varmistaa, että rivin 143 FILE COPY
tekee todella uuden
tiedoston eikä yritä lisätä tietueita johonkin vanhaan. Tätä varten on
tuhottava kohdetiedosto. No, miksei sitten vain tuhota kuten tehdään
riveillä 141-142? Vaan entäpä jos tuhottavaa tiedostoa ei ole? Tulee
rumia File not found -ilmoituksia, hyi. Siispä voitaisiin tarkistaa,
onko tiedosto olemassa. Siihen on käytettävissä mainio CHECK
-komento,
joka on aikanaan aivan sukroja varten tehty. Mutta tarkistamistakin
yksinkertaisempaa on tässä varmistaminen: kopioidaan nykyinen rivi (CUR
)
ao. tiedoston perään. COPY
-komento toimii niin, että se tarvittaessa luo
tiedoston, muussa tapauksessa lisää tietoja sen perään. Näin päästään
etenemään suoraviivaisesti ilman turhia tarkistuksia: tiedosto on
olemassa, joten se voidaan tuhota. Tuntuu tuhlaukselta, mutta on aika
näppärää tällaisessa tilanteessa, eikä tunnu missään. COPY
on nopea,
eikä se välitä, vaikka vastassa olisi millainen tiedosto tahansa.
Tästä kaikesta jää henkiin vain Wtmp2
:lla osoitettu datatiedosto, joka
on lajiteltu aggregointimuuttujan suhteen ja sisältää vain aktiivisen
osan alkuperäisestä aineistosta. Tyhjennetään kenttä jälleen samalla
INIT
-komennolla kuin alussa. Komennon parametrit otettiin silloin
talteen Winit
-paikkaan ja paluukomento paikkaan Wback
, joten niitä ei
tarvitse kirjoittaa useampaan kohtaan sukrokoodissa.
Mystinen PRIND=0
, joka kummittelee joka puolella, on täsmennys, joka saa
useimmat Survon operaatiot vaikenemaan, ts. jättämään sinipohjaisen
väliaikaistulostuksen väliin. Koska tämän sukron aikana tapahtuu useita
aineiston läpikäyntejä, niin tulostuksen jättäminen pois nopeuttaa
selvästi toimintaa. Näkymä käyttäjän suuntaan on myös hieman
rauhallisempi.
Lopulta saavumme asian ytimeen: havaintoaineiston aggregointiin! Sen
sukro tekee tietenkin FILE AGGR
-operaatiolla. Se kirjoittaa jo
toiveikkaasti rivillä 150 komennon, mutta ei aktivoi sitä vielä.
Aggregoinnin kuvauskaavio on vielä saatava aikaiseksi. Se syntyy
mukavasti tiedoston rakennekuvauksen pohjalta. Siispä FILE STATUS
-komento saa jälleen käyttöä.
Listan alkuun sukro laittaa lukumäärämuuttujan, joka kiilaa siis
lopullisen tiedoston ensimmäiseksi muuttujaksi. Aggregointifunktiona on
N
ja miinus tarkoittaa sitä, ettei sen arvoja lasketa minkään muun
muuttujan avulla. Kirjaimella g
merkityssä silmukassa tarkkaillaan
jälleen kuvauslistan loppua. Lukumäärä- ja aggregointimuuttujille on
omat erikoiskäsittelynsä: edellisen yli hypätään ja jälkimmäiselle
tehdään FIRST
-funktiolla uuteen tiedostoon sellainen vastine, jossa ovat
sen arvot kertaalleen (esim. KUNNAT
-tiedoston läänikohtaisessa
aggregoinnissa läänien lyhenteet). Muita muuttujia tulee vastaamaan yksi
rivi kutakin. Se muodostetaan rivillä 161. Wx
:ään on rivillä 158
talletettu ao. muuttujan nimi. Kun loppu saavutetaan ja kuvauskaavio on
valmis, aktivoidaan FILE AGGR
-komento, tyhjennetään kenttä ja tuhotaan
Wtmp2
:lla osoitettu datatiedosto. Nyt aggregoitu aineisto on käyttäjän
haluamassa paikassa, mutta se ei vielä riitä pedantille sukrollemme.
|
|
Vielä kerran käytetään FILE STATUS
-toimintoa, nyt uudella tiedostolla.
FILE AGGR
:in luomaa kommenttia siistitään hieman, sehän ei voinut
tietää, mistä datasta alunperin oli kysymys. Lukumäärämuuttujalle
lisätään kuvaus, ja lopulta täräytetään tallessa ollut tekstiblokki
näkyville niin että muutkin muuttujat saavat kuvauksensa. Kuvaukset
sukro käy nuuskimassa siltä varalta, että ne sisältäisivät
formaattimäärityksiä. Se ei poista niitä, mutta amputoi ne sutaisemalla
alkusulun pois. Rivin 175 tyhjät aaltosulut ovat todella tarpeen, sillä
niitä edeltää välilyönti, jolla sukro alkusulun poistaa.
Kuvaus päivitetään FILE STATUS
-operaation työparilla FILE UPDATE
.
Samalla valmistellaan FILE SHOW
-komentoa luovutettavaksi käyttäjälle,
kunhan palataan alkuperäiseen kenttään. Blokki on taas oiva siirtomuoto
työkentästä varsinaiseen. Loppukohtaus tullaan näyttelemään kohdassa
End1
.
|
|
Lopun edellä ovat virheilmoitukset, jotka kaikki päättyvät yhteiseen
uomaan ERR0
. Siinä pyydetään käyttäjältä ENTER
in painallusta ja palataan
sitten lähtötilanteeseen Back
-kohdan kautta. ERRS
-kohdan ilmoitukseen
ajaudutaan, jos yritetään käyttää tätä sukroa SURVOS-version alta. Sukro
on ankara ja ilmoittaa vaativansa SURVO 98:n, vaikka SURVO 84C:kin
kävisi. En kuitenkaan ole edes testannut sukroa SURVO 84C:n puolella,
joten antaa olla.
Rivin 193 {goto Back}
on turha tavallaan mutta mukana tahallaan. Jos
vaikka tulisi lisättyä jotain koodia sen ja 194:n väliin, olisi
turhauttavaa haeskella virhettä, joka joissain tilanteissa esiintyisi ja
johtuisi vain siitä, että ERR0
:n kaverit pääsisivät mukaan uuteen
koodiin vaikka ne kuuluisivat jo siinä vaiheessa muualle. Sama koskee
esimerkiksi rivin 188 goto
-koodia.
Kohdat Back
ja End1
ovat muuten samanlaisia - ne palauttavat
alkuperäisen kentän ja näkymän mutta End1
lisää yhden rivin ja siirtää
kursorin siihen. Tälle riville tulee FILE SHOW
-komento silloin kun
suoritus loppuu normaalisti tai /AGGRE
-komennon malli, jos tullaan
avustustekstin kautta.
Viimeisen rivin End
on loppujen loppu, jonne vievät kaikki tiet. Jos
{disp}
-koodeja on käytetty, on parasta laittaa {disp reset}
loppuun.
Samoin jos {message}
-koodeja on käytetty, kannattaa loppuun panna yksi
{message}@
. Vihonviimeisenä on kuitattu sukron ensimmäisellä
koodirivillä asetettu nopeus. Ainoana pakollisena koodina on lopussa
lakoninen {end}
.
|
|