⟦8d3507e93⟧

TextFile

I_N_T_R_O_D_U_K_T_I_O_N_ _T_I_L_ _R_C_ _M_O_S_A_I_K_

1_._ _ _ _ _ _ _ _ _R_C_ _M_O_S_A_I_K_ _o_g_ _v_i_r_k_s_o_m_h_e_d_e_n_s_ _s_t_y_r_i_n_g_ 1.

RC MOSAIK>s opgave er at forsyne virksomhedens medarbejdere med
relevante informationer til de beslutninger, der løbende skal ta-
ges i det daglige arbejde, og til den løbende kontrol af beslut-
ningernes økonomiske konsekvenser.

Arbejdet med RC MOSAIK kan opdeles således:

Registrering af grundbilag og kartoteksoplysninger
Daglig styring af vare- og pengestrømme
Kontrol af den økonomiske udvikling

R_e_g_i_s_t_r_e_r_i_n_g_ _a_f_ _g_r_u_n_d_b_i_l_a_g_ _o_g_ _k_a_r_t_o_t_e_k_s_o_p_l_y_s_n_i_n_g_e_r_

Registreringsopgavens gennemførelse er en vigtig forudsætning for
anvendeligheden af systemets informationer. Grundbilagene skal
registreres hurtigt, således at systemets oplysninger til stadig-
hed udtrykker de fysiske realiteter for virksomheden.

I selve registreringsprocessen, som foregår ved dataskærme, er
der indbygget både fejlkontroller og styringskontroller.

Fejl optræder, når man behandler systemet forkert. Man bliver
straks gjort opmærksom på fejlen og kan ikke fortsætte, før den
er rettet.

Styringskontroller skal sikre, at uønskede situationer ikke op-
står. F.eks. kommer der en advarsel ved salgsordreregistreringen,
hvis kunden har forfalden saldo, har overskredet kreditgrænsen,
eller hvis disponibelt lager overskrides. De forskellige advars-
ler, der kan fremkomme, skal resultere i, at man undersøger situ-
ationen og lader den ansvarlige tage beslutningen om, hvad der
bør gøres i den aktuelle situation.\f

De forskellige styrekontroller blokerer ikke arbejdet ved skær-
men, og ordren kan registreres, selv om kundens saldo er over
kreditmaksimum. Alle advarsler fra styrekontroller fremkommer
igen ved dagsslut som anmærkninger på de forskellige journaler.

D_a_g_l_i_g_ _s_t_y_r_i_n_g_ _a_f_ _v_a_r_e_-_ _o_g_ _p_e_n_g_e_s_t_r_ø_m_m_e_

Den daglige styring af vare- og pengestrømme tager sit udgangs-
punkt i de aftaler, der indgås med kunden, når salgsordre afta-
les. Det er derfor vigtigt at vide, hvad man kan tilbyde kunden i
form af priser, betalingsfrister, mængder, leveringstider etc.,
og det er vigtigt hurtigt at kontrollere, at de indgåede aftaler
er i overensstemmelse med indkøbs- eller produktionsplaner samt
gældende politikker.

RC MOSAIK udfører disse styrekontroller ved registreringen og kan
desuden producere en række planlægningsoversigter baseret på
salgsordrebeholdningen, planlagt produktion, indkøbsordrebehold-
ningen og de aktuelle varelagre.

Den daglige styring kan opdeles i følgende hovedopgaver:

Kundeordrebehandling
Leveringskontrol og fakturering
Produktion, indkøb og varelagerstyring
Styring af ind- og udbetalinger
\f

K_o_n_t_r_o_l_ _a_f_ _d_e_n_ _ø_k_o_n_o_m_i_s_k_e_ _u_d_v_i_k_l_i_n_g_

Den økonomiske styring af et firma er almindeligvis baseret på
opstilling af nogle m_å_l_ i form af handlingsplaner, budgetter og
en månedlig k_o_n_t_r_o_l_ af handlingernes gennemførelse i form af den
regnskabsmæssige budgetopfølgning og afvigelsesforklaringer. Kon-
trollen kan give anledning til, at handlingsplanerne må ændres
for at kunne nå det opstillede mål.

RC MOSAIK>s opgave er at udføre en del af budgetkontrollen samt
at give forskellige analyser til brug for afvigelsesforklaringer-
ne. Det er så ledelsens opgave at vurdere og forklare afvigelser-
ne som baggrund for ændring i handlingsplaner.

Rapporteringen i forbindelse med den økonomiske styring er opdelt
således:

Resultatrapport
Likviditetsanalyse
Salgsanalyse
Produktions- og lageranalyse
Debitorlister
Kreditorlister
Balancer \f

Systemet er i stand til at behandle flere adskilte firmaer med
fælles registre.

I denne forbindelse er behovet for sikkerhed løst via et bruger-
katalog, hvori hvert firma har et specielt "password", som tilla-
der adgang til firmaets specifikke del af registrene.

Systemet kan logisk opdeles i følgende undersystemer eller modu-
ler:

S_a_l_g_s_f_u_n_k_t_i_o_n_e_n_

salgsordremodul
fakturamodul

K_ø_b_s_f_u_n_k_t_i_o_n_

købsordremodul
registrering af lagertilgang
behandling af leverandørfakturaer

P_r_o_d_u_k_t_i_o_n_ _o_g_ _l_a_g_e_r_s_t_y_r_i_n_g_s_f_u_n_k_t_i_o_n_

Planlægnings- og ordremodul

Ø_k_o_n_o_m_i_f_u_n_k_t_i_o_n_

Debitormodul
Kreditormodul
Finansmodul

I de følgende 2 kapitler er redegjort for:

RC MOSAIK i dagligdagen som løsning på firmaets registreringsbehov.

RC MOSAIK som managementværktøj. \f

(skema)

2_._ _ _ _ _ _ _ _ _R_C_ _M_O_S_A_I_K_ _i_ _d_a_g_l_i_g_d_a_g_e_n_ 2.

Tegningen på den foregående side viser i sammenfattet form firma-
ets registreringsmæssige opgaver.

S_a_l_g_s_f_u_n_k_t_i_o_n_

K_u_n_d_e_o_r_d_r_e_b_e_h_a_n_d_l_i_n_g_

Alle kundeordrer kan registreres i systemet. Ved registreringen
er der kontrol af leveringsevnen for den ønskede vare og af kun-
dens betalingssituation (forfalden saldo, kreditgrænse, overskre-
det). Hvis systemet reagerer på styrekontrollen, kan ordren stop-
pes, og en ansvarlig leder kan vurdere, om den pågældende ordre
skal ændres eller om andre ordrer eller planer skal ændres. Til
brug for disse vurderinger kan systemet på dataskærmen vise ter-
minsopdelte leveringsplaner for kunder og varer, således at man
kan finde frem til de kunder, varer og ordrer, det kunne blive
aktuelt at ændre.

Når salgsordren er registreret, kan den kaldes frem på skærmen,
og den kan udskrives på en formular til brug for ordrebekræfti-
gelse og ekspedition.

Ved dagens slutning udskrives en "ordrebevægelsesliste" og "va-
rers anmærkninger", hvor de ordrer og varer, der har fået signa-
ler ved styrekontrollen er særligt markeret.

Ordreformularerne er typisk:

- ordrebekræftigelse til kunden
- følgeseddel til kunden
- forsendelsesseddel til lager \f

(tegning)

Udover almindelige on-line forespørgsler om kunder, leverandører
og ordrer, er der mulighed for at foretage forespørgsler på et
antal sammenhængende informationer, som gør det muligt for ordre-
administrationen at give øjeblikkelig svar på spørgsmål fra kun-
der og spørgsmål om alternative leveringsbetingelser o.s.v.

Disse forespørgsler er:

1) L_e_v_e_r_i_n_g_s_p_l_a_n_,_ _k_u_n_d_e_
- hvilken ordre har kunden,
hvornår skal ordren leveres,
og hvilke produkter skal
leveres?

2) L_e_v_e_r_i_n_g_s_p_l_a_n_,_ _p_r_o_d_u_k_t_e_r_
- hvilke ordrer, til hvilke
kunder, hvornår skal de leveres?

3) L_a_g_e_r_p_r_o_f_i_l_
- hvordan vil lagerbeholdningen
udvikle sig over en nærmere
specificeret periode, når
mængden af salgsordrer,
købsordrer, vare i produktion
samt planlagt produktion er
taget i betragtning?

F_a_k_t_u_r_e_r_i_n_g_

Inddata til fakturamodulet er ekspeditionspapirer fra lageret
korret for faktiske leveringer m.v.
\f

På baggrund af behandlede ekspeditionspapirer kaldes ordrerne
frem til fakturering

Hvis en ordre ikke kan faktureres fuldt ud, registreres det fak-
tiske antal varer der er leveret. Herefter genererer systemet
automatisk en restordre, medmindre andet ønskes.

Under faktureringen bliver alle relevante lager-, debitor- og fi-
nanskonti automatisk opdateret.

U_d_d_a_t_a_

Uddata fra systemet er:

1) Fakturaer
2) Fakturaliste/journal
3) Varesalgsjournal

(tegning)

I_n_d_k_ø_b_s_f_u_n_k_t_i_o_n_

K_ø_b_s_o_r_d_r_e_m_o_d_u_l_

På basis af EDB-genererede uddata som f.eks. lagerprofil og be-
hovsanalyse kan indkøbsafdelingen udfærdige indkøbsforslag.

De egnede forslag registreres i systemet.

Registreringer i købsordremodulet foretages parallelt til
salgsordremodulet.

Registrerede købsordrer danner basis for senere registrering og
kontrol af lagertilgange samt registrering og kontrol af leveran-
dørfakturaer.

U_d_d_a_t_a_

De daglige uddata er: Ordrebevægelsesliste

On-line forespørgsler fra salgsordremodulet anvendes også i købs-
ordrermodulet.

L_a_g_e_r_t_i_l_g_a_n_g_

Når de fysiske lagertilgange finder sted, anvendes leverandør-
fragtbrevet, leverandørfaktura, o.s.v. til kontrol.

Fragtbrevet registreres i systsemet, hvor de faktiske lagertil-
gange sammenlignes med bestilte kvanta.
\f

Hvis købsordren ikke leveres fuldt ud, genererer systemet
automatisk en restordre medmindre andet ønskes.

Under registreringen bliver lagerregistret opdateret.

K_ø_b_s_f_a_k_t_u_r_a_-_r_e_g_i_s_t_r_e_r_i_n_g_

Når en købsfaktura modtages registrers den i systemet med infor-
mationer om priser og antal. Såfremt antallet på fakturaen varie-
rer fra de registrerede lagertilgange bliver der givet alarm på
terminalen.

Ligeledes gives der alarm, hvis priserne varierer mere end "x%"
fra tidligere registreret kostpris.

De ovennævnte alarmer bliver opsamlet i løbet af dagen i en an-
mærkningsliste.

Under registrering bliver kreditor-, lager- og finanskonti auto-
matisk opdateret af systemet.

U_d_d_a_t_a_

De daglige uddata består af:

Købsfakturaliste/journal
Anmærkningsliste

(tegning)

S_t_y_k_l_i_s_t_e_b_e_h_a_n_d_l_i_n_g_

Planlægning og ledelse af produktionen er baseret på anvendelse
af "styklister".

Til dette formål anvender systemet et styklisteregister, som
indeholder informationer om prisen på komponenter, specificeret på:

1) Råmaterialer og halvfabrikata
2) Lønomkostninger udtrykt i minutter opdelt på funktioner el-
ler afdelinger.
3) Diverse hjælpematerialer.

P_r_o_d_u_k_t_i_o_n_s_-_ _o_g_ _l_a_g_e_r_s_t_y_r_i_n_g_

Datagrundlaget for produktions- og lagerstyringsmodulet hentes
fra

Produktionsplaner
produktionsordrer
Lagertilgange

P_r_o_d_u_k_t_i_o_n_s_p_l_a_n_e_r_

Den overordnede produktionsplanlægning foretages udenfor RC-MOSAIK
og resulterer i en række produktionsplaner.

Produktionsplanerne registreres i systemet til vurdering af frem-
tidig leveringsevne. Produktionsordrer genereres ikke automatisk
og der foretages ingen automatisk reservation af råmaterialer.
Men produktionsplaner kan nedbrydes til standard råmaterialemæng-
der.
\f

P_r_o_d_u_k_t_i_o_n_s_o_r_d_r_e_

Når varerne sættes i produktion, registreres en produktionsordre
i systemet. Herefter kan der genereres et produktionsordredokument.

Hvis der refereres til en produktionsplan, bliver planen tilsva-
rende ændret.

Registreringen reserverer automatisk råmaterialer og halvfabrika-
ta ifølge standardoplysninger (jf. styklisten).

L_a_g_e_r_t_i_l_g_a_n_g_

Når en produktion er afsluttet, returneres ordredokumentet med
relevante lagertilgange til registrering i systemet.

Reservationer af råmaterialer annulleres og lagerbeholdninger
ændres tilsvarende.

Hvis lagertilgange ikke stemmer overens med antallet der er be-
stilt, forbliver resten som en restordre med mindre andet øns-
kes.

Både produktionsplaner og ordrer kan udelades. Hvis et firma væl-
ger ikke at registrere produktionsordrer, f.eks. fordi produktio-
nens udførelsestid kun er nogle få timer, kan lagertilgange hen-
vises til en produktionsplan, som så vil blive reduceret tilsva-
rende.

(tegning)

Ø_k_o_n_o_m_i_f_u_n_k_t_i_o_n_e_n_

D_e_b_i_t_o_r_m_o_d_u_l_

Systemet kan valgfrit arbejde efter åben postmetoden eller saldo-
metoden til debitorstyring.

Fakturaer og kreditnotaer posteres automatisk fra fakturamodulet
til debitorkonti.

Debitorudbetalinger registreres analogt til kreditorudbetalinger,
udgiftsbilag o.s.v. og er yderligere behandlet under finans-
modulet.

Systemet tillader postering af fakturaer og betalinger til kunder
i fremmed valuta. I særlige tilfælde, hvor der anvendes postering
af fakturaer og betalinger i mere end en valuta, åbnes en konto
for hver valuta.

Systemet kan behandle salg gennem kædeforretninger (indkøbsfore-
ninger), hvor betalinger finder sted gennem et centralt beta-
lingskontor, og hvor detailafsætningsmarkedet er individuelle
kunder set ud fra en salgsstatistisk synsvinkel.

K_r_e_d_i_t_o_r_m_o_d_u_l_

Dette modul fungerer principielt analogt til debitormodulet med
følgende nøgleord:
- enten åben post eller saldometode
- betaling i forskellige valuta
- automatisk postering af købsfakturaer

F_i_n_a_n_s_m_o_d_u_l_

Udover automatiske posteringer, der stammer fra andre systemmodu-
ler, består finansmodulet bl.a. af:

- alle former for kontante udgiftsbilag.
- journal bilag
- kontante kvitteringer

Systemet behandler et bilag ad gangen og ingen postering accepte-
res inden der er foretaget bogholderimæssig afstemning.

(tegning)

3_._ _ _ _ _ _ _ _ _R_C_ _M_O_S_A_I_K_ _s_o_m_ _l_e_d_e_l_s_e_s_r_e_d_s_k_a_b_ 3.

R_e_s_u_l_t_a_t_r_a_p_p_o_r_t_

Resultatrapporten bruges til den overordnede kontrol af virksom-
hedens økonomiske resultater og til kontrol af kapacitetsomkost-
ningerne. Resultatrapporten udskrives på grundlag af finanskonto-
planen, og den viser i hovedgrupper tallene for selskabets drift
i perioden og år til dato og både realiserede tal og budgettal.

L_i_k_v_i_d_i_t_e_t_s_a_n_a_l_y_s_e_

Likviditetsanalysen bruges til kontrol af den planlagte lidvidi-
tetsudvikling. Likviditetsanalysen er baseret på driftskontienes
tal for perioden og på statuskontienes saldoforskydninger.

Likviditetsanalysen omfatter også på særlige linier en opfølgning
af de gemmenførte investeringers likviditetsvirkninger og af be-
vægelserne på de forskellige finansieringslån.
\f

S_a_l_g_s_a_n_a_l_y_s_e_r_

Salgsanalyser bruges til budgetopfølgning af omsætning, stk.salg
og dækningsbidrag.

Der findes følgende standard salgsstatistikker i RC MOSAIK.

R_e_n_t_a_b_i_l_i_t_e_t_s_l_i_s_t_e_ - udskrives på anfordring og indeholder pr.
varegruppe: stk.salg, omsætning og dækningsbidrag for salg måned
til dato, ordrer til levering i måneden, i alt månedens forvente-
de salg, budget og difference mellem budget og forventet salg.

Rentabilitetslisten anvendes i den daglige opfølgning og danner
bl.a. grundlag for besvarelse af forespørgsler om månedens for-
ventede omsætning før måneden er slut.

S_a_l_g_s_-_ _o_g_ _d_æ_k_n_i_n_g_s_b_i_d_r_a_g_s_s_t_a_t_i_s_t_i_k_ - udskrives pr. måned. Inde-
holder en hovedopdeling på eksternt og internt salg og inden for
disse pr. varegruppe: stk.salg, omsætning og dækningsbidrag for
måned, år til dato, budget år til dato og sidste år til dato.

Salgs- og dækningsbidragsstatistikken følger en defineret vare-
gruppeopdeling og indgår i månedsrapporteringen. Statistikken kan
danne baggrund for en analyse af budgetafvigelserne og afvigel-
serne i forhold til sidste år, således at afvigelserne pr. vare-
gruppe kan opdeles i:

afvigelse på grund af ændret stk.salg
(til budgetteret salgspris og dækningsbidrag)
\f

afvigelse på grund af ændret gennemsnitlig salgspris
(salgsprisændringer eller mixændringer)

afvigelse på grund af ændret gennemsnitlig dækningsgrad
(kostprisændringer eller mixændringer)

K_u_n_d_e_g_r_u_p_p_e_/_v_a_r_e_g_r_u_p_p_e_s_t_a_t_i_s_t_i_k_ - udskrives almindeligvis pr. må-
ned og indeholder pr. kundegruppe salget fordelt på varegrupper
med følgende oplysninger: stk-salg, omsætning, dækningsbidrag,
månedens tal og år til dato, månedens budget og budget år til
dato.

Som standard statistik findes desuden:

V_a_r_e_s_a_l_g_s_s_t_a_t_i_s_t_i_k_ - udskrives almindeligvis pr. måned. Indehol-
der pr. varenr.: stk,salg, omsætning og dækningsbidrag for måne-
den og år til dato.

Ud over de her nævnte standard statistikker er det muligt at få
udskrevet en række kunde/vare- og vare/kundestatistikker.

Yderligere salgsanalyser på gruppeniveau kan udskrives efter be-
hov.
\f

Hvilke statistikker man ønsker, bør planlægges over en længere
periode, da det ikke er praktisk at ændre det i løbet af perio-
den.

Det samlede kompleks af salgsstatistikker gør det muligt at ana-
lysere salg og dækningsbidragsindtjeningen på mange kriterier,
således at man kan finde frem til de mest lønsomme områder at
sætte ind på.

P_r_o_d_u_k_t_i_o_n_s_-_ _o_g_ _l_a_g_e_r_a_n_a_l_y_s_e_r_

Den nødvendige opfølgning af produktionens gennemførelse og lag-
renes størrelse er baseret på en sammenligning af faktisk forbrug
og standardforbrug ifølge standard kalkulationer.

Principperne for standardomkostningskontrollen kan beskrives så-
ledes:

1. Råvarelager primo til stand.kostpris xxx
(iflg. lagerregnskab/edb)

2. Varekøb til indkøbspriser + xxx
(iflg. kostprisafvigelser/edb)

3. Prisdifference på varekøb-stand.pris/indkøbspris +/- xxx
(iflg. kostprisafvigelsesliste/edb)

4. Udbetalt arbejdsløn + xxx
(iflg. lønbogholderi)

5. Prisdifference på arbejdsløn-stand.timeløn/faktisk +/- xxx
(beregnes) timeløn

6. Standardforbrug månedens produktion +/- xxx
(iflg. stk.omk. producerede varer/edb)

7. Mer/mindre forbrug materialer +/- xxx
(lagerændringer efter optælling af råvarelager/edb) \f

8. Mer/mindre forbrug arbejdsløn +/- xxx
(beregnes af punkt 4, 5 og 6)

9. Råvarelager ultimo til standard/kostpris xxx
(iflg. lagerregnskab/edb) =======

Som det fremgår af henvisningerne i parantes, leverer RC MOSAIK
de fleste af oplysningerne til standardomkostningskontrol

Mer/mindre forbrug af råvarer opgøres efter en fysisk lageroptæl-
ling, da produktionens vareforbrug ikke registreres direkte, men
fratrækkes i råvarebeholdningen i edb-systemet med det standard-
forbrug, der svarer til månedens produktion.

Standardomkostningskontrollen kan opdeles på råvaregrupper.

Færdigvarelagrene afstemmes således:

Færdigvarelager primo til stand.kostpris xxx
(iflg. varelagerliste/edb)

Månedens produktion til stand-omk. + xxx
(iflg. edb)

Månedens salg til stand.omk. - xxx
(iflg. edb) _ _ _ _ _

Færdigvarelager ultimo til stand.kostpris xxx
(iflg. edb) ====== \f

De her nævnte opstillinger og statistikker kan danne grundlag for
en periodisk oversigt over produktionens økonomi.

En meget vigtig del af standardomkostningskontrollen er de kalku-
lerede standardomkostninger, der ligger i systemet på hver enkelt
vare. Disse forbrugssatser og priser er budgettet for produktio-
nens gennemførelse, og det er disse kalkulationer, der kontrolle-
res i standardomkostningskontrollen.
\f

4_._ _ _ _ _ _ _ _ _A_n_d_r_e_ _m_u_l_i_g_h_e_d_e_r_ _i_n_d_e_n_f_o_r_ _R_C_ _M_O_S_A_I_K_ 4.

Ved udviklingen af RC MOSAIK er der lagt vægt på tre hovedfor-
mål:

1) At udvikle et standardsystem, som kan tilfredsstille behov
hos et bredt udsnit af mindre- og mellemstore virksomheder
som producerer og/eller afsætter massevarer/varer.

2) At systemet let skal kunne modificeres. Dette betyder at:
a) Programkomplekset skal kunne forsyne programmøren med et
sæt af værktøjer, som muliggør det for selv relativt uer-
farne programmører at arbejde med systemet.

b) Programmøren skal kunne være overbevist om at modifika-
tioner ikke giver konsekvenser andre steder i programkom-
plekset.

3) At skabe en basis ramme, t_o_t_a_l_t_ _u_a_f_h_æ_n_g_i_g_ af RC MOSAIK, en
struktur, som er i stand til at klare a_l_l_e_ basisbehov for et
edb-system.

G_e_n_e_r_e_l_ _p_r_o_g_r_a_m_s_t_r_u_k_t_u_r_

Den generelle struktur består af:

A_._ _E_t_ _s_æ_t_ _e_k_s_t_e_r_n_e_ _p_r_o_c_e_d_u_r_e_r_

Disse procedurer indeholder beskrivelse af den database, som
skal anvendes.

Strukturen er trimmet til anvendelse af RC database system.
\f

B_._ _S_t_r_u_k_t_u_r_ _i_ _e_t_ _o_n_-_l_i_n_e_ _s_y_s_t_e_m_,_ _i_ _h_v_i_l_k_e_t_ _a_t_ _d_a_t_a_f_a_n_g_s_t_ _o_g_
b_e_h_a_n_d_l_i_n_g_ _k_a_n_ _u_d_f_ø_r_e_s_ _e_n_k_e_l_t_ _o_g_ _s_i_k_k_e_r_t_

Strukturen giver bl.a., følgende karakteristiske træk:

1) Adskillige typer programkørsler
a) Batchmode, som skal bruges ved
- konvertering af registre fra andre systemer
- testning af system.

Denne facilitet er værdifuld for programmøren, fordi det
giver ham en oversigt over programforløbet, men også en
detaljeret forklaring på fremgangsmåderne.

b) On line mode

c) Speciel mode til reetablering efter afbrydelse

d) Speciel mode til at periodisere kontering.

2) Et detaljeret sæt sikkerhedsprocedurer f.eks.:
- back-up i tilfælde af systemsvigt
- kontrol af databasekonsistensen. Det er umuligt at køre
programmet, hvis databasen og back-up registrer er inhomo-
gene
- automatisk udvidelse af registre.
afslag på kørsel af programmer, hvis ressourcer er util-
strækkelige
- alarm, hvis en fil kræver reorganisation
Alarm starter normalt ca. en uge før det kritiske punkt er
nået.
Hvis alarmen vedvarende bliver ignoreret, vil systemet la-
ve en kontrolleret nedlukning.
Eventuel forsøg på at genstarte on-line programmet er \f

således umulig til filen er blevet reorganiseret.
- trappoint faciliteter
I tilfælde af program-fejl vil systemet gøre alt muligt for
at få en kontrolleret nedlukning og desuden bevare databa-
sen konsistent.
- automatisk behandling af hardware fejl på terminaler, prin-
ter etc.
3) Terminal-behandling

4) mulighed for valg af outputmedie

Brugeren kan valgfrit få output på terminalen og/eller
printere
printfil
via PRIMO

5) Automatisk anvendelse af MIPS/TS - operativsystem

6) Faciliteter og back-up register til at klare problemerne med
afbrydelse i bogholderi funktionen.

7) Et generelt sæt af database-access-procedurer.

C_._ _B_a_t_c_h_._p_r_o_g_r_a_m_s_t_r_u_k_t_u_r_

Strukturen har, bl.a. følgende karakteristiske træk:

1) Strukturen tillader at køre batch-programmer, enten på inter-
aktive basis i menneske-maskine dialog, eller ved at trimme
programmet til permanente rutiner.

2) Mulighed for valg af output til
printere eller spoolområde (baggrundsområde)

3) Automatisk anvendelse af MIPS/TS \f

4) Et generelt sæt af database access og fil handling procedu-
rer.
Den generelle struktur ovenfor betyder en betydelig mindskning af
programmeringsopgaverne såvel under udvikling af nye applikatio-
ner som under modificering af de eksisterende.

COROUTINE MONITOR

(ALGOL 8)

1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_._ 1.

With the introduction of the activity concept in algol8 (ref 1)
is available, a set of powerful tools for programming parallel
activities within an algol program.

These fundamental tools are directly accessible from an algol
program. However, there is a need for concepts and functions on
higher levels. The present coroutine monitor is such a set of
high level tools for programming parallel activities.

The coroutine monitor supports coroutines internally synchroni-
zing and communicating via semaphores and externally synchroni-
zing and communicating via the low level send message - wait an-
swer functions and the high level i/o procedures (read, write,
inrec etc.).

The actual implementation is based in the proposal for a reen-
trant coroutine monitor for RC8000 (common to several processes)
as described in ref. 2.

The coroutine and semaphore concepts are outlined below (readers
who are familiar with these concepts may skip the rest of this
chapter):

The use of the term "coroutine" has not yet been standardized in
the technical literature, and consequently appears confusing, as
the word "coroutine" is used about programming tools ranging from
subroutine-like modules calling each other in a highly symmetric
way, to tasks running in a general multiprogrammed system, inter-
acting in a certain simple way.

The name "coroutine" was coined by Conway in 1958. He used it for
subroutines in a system, where each subroutine is written as if
it is the main program and the others simple subroutines called
by it. This is done by merging of call and return, and dynamical-
ly changing entry points in the routine. The mecanism is descri-\f

bed in detail in ref. 3. The concept is found as well in SIMULA
67.

Some of the charateristics of such a system are:

- one coroutine at a time is active (using the CPU). This means
that a coroutine always runs in "disables" mode and consequent-
ly has free and exclusive access to any variable in the sys-
tem.

- protection of data areas shared between coroutines against si-
multaneous access is not critical.

- the scheduling of CPUtime is "primitive" - each coroutine uses
as musch CPUtime as needed. No protection exists against one
coroutine monopolizing the CPU. Implementation of the call me-
chanism is very simple.

- as each coroutine may be written as if it is the main program
calling sunroutines, a certain amount of modularity and inde-
pendence between modules is enforced on the programmer.

An important extension to this simple coroutine system is found
in the book by D.E. Knuth. A coroutine is allowed to activate se-
veral other coorutines before stopping, i.e. in he terminology of
subroutines simultaneously to branch to several entry points. Ac-
tivation of another coroutine and suspending own executing are
thus seperate functions (figure 3). The "current entry point"
(figure 2) is replaced by a "waiting point".

Selection of the coroutine which is allowed to run next (in case
of several activated coroutines), is done by a central logic.

Figure 3. Coroutine System, several acticated coroutines.

A primitive sort of internal event has been added in form of the
activate/wait pair. A coroutine may further wait for a specified
time ("delay 2 secs"), which can be cinsidered as a hidden timing
coroutine activating the caller after the specified interval of
time. Scheduling of the CPU is still "primitive", but the central
logic has decisional abilities and is extended with a timing
function.

The present RC8000 Algol Coded Coroutine Monitor consists of a
central logic and a collection of coroutine monitor procedures.
It has developed from the system mentioned above by emphasizing\f

the role of internal and external events and by making the corou-
tines more independant. These design principles are flund in the
RC4000 operating system BOSS2, too.

An RC8000 c_o_r_o_u_t_i_n_e_ is either active (activated) or waiting for
some internal or external event. An active coroutine is always
placed in the ready queue, i.e. activated and waiting for access
to the CPU. The first coroutine in the ready queue is the singu-
lar coroutine executing instructions.

A waiting coroutine may wait for timer, internal events signalled
by other coroutines (see below) or incomming messages and an-
swers. It is possible to wait for more than one type of event at
a time.

Coroutines can cooperate by sending signals on semaphores to each
other.

A s_e_m_a_p_h_o_r_e_ is a data structure containing a state variable and
some additional information about queues of waiting coroutines
and signalled events. A semaphore is in one of three states:

- neutral: The number of signals equal the number of waits.
The semaphore is initially in this state.

- open: There has been more signals than waits. This means
that a coroutine is not delayed when executing a
wait.

- closed: There has been more waits than signals. Conse-
quently, a signal will activate one waiting
coroutine.
\f

Two types of semaphores are supported:

- simple semaphores: No data is sifnalled. The semaphore only
counts the number of signals/waits.

- chained semaphores: Data (operations) are signalled. A sig-
nal specifies an operation type. A wait
selects the set of operation types,
which should cause an activation of the
coroutine.

A coroutine may be placed in one of the following queues.

- The ready queue: User of or waiting for the CPU
- A semaphore queue: Waiting for a signal
- The timer queue: Waiting for a timer event
- The idle queue: Waiting for an external event or closed

The coroutine concept appears to be very similar to the process
concept. Howeverm there are important differences as illustrated
in the following comparison:

Concept Process Solution Coroutine solution
several processes. several coroutines in
one process.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Module: = process. = coroutine

Communication Other process known by Other coroutines only
between n_a_m_e_. Messages/answers known to a limited
modules: are exchanged. extend. Communication
done by signal/wait
using common semaphores.
\f

Critical Exclusive access to Exclusive access is
region and data areas is ensured ensured between waiting
shared data by associating access point. If exclisive
with exclu- with a certain message/ access is wanted for a
sive access: answer. The current ow- piece of code containing
ner of the message/an- several waiting points,
swer has exclusive ac- signal/wait is used.
cess.

Critical regions, i.e. Critical regions are
non-entrant code shared protected automatically
between several proces- by placing them between
ses may be protected in waiting points.
the same way or by pre-
venting a process shift
by disabling interrupts.

CPU overhead: Low to high depending Very small.
hardware facilities.

CPU Yes, depending on rela- No, a loop in a coroutine
guaranteed: tive priority. A loop will stop the whole sys-
in another process with tem of coroutines.
same or lower priority
can not prevent execu-
tion.

Short Processes with high No.
realtime priority have immidiate
response response.
guaranteed:

CPU usage Any range of CPU load CPU load preferably low.
\f

Core Process descriptor - As shift to another
overhead: contains a save area for coroutine happens at
all hardware and soft- well defined places,
ware registers used by overhead can be kept
the processes, as an small.
interrupt and shift to
other proces may happen
at any instance of the
execution.

Use when: Closely interacting Closely interacting
activities with medium activities, i/o or event
to high CPU usage. bound, low CPU usage.
Dynamic environment. Static environment.

2_._ _ _ _ _ _ _ _ _B_A_S_I_C_ _E_N_T_I_T_I_E_S_._ 2.

The basic entities of the coroutine system are: coroutines, sema-
phores, operations (buffers) and extensions for sending messages
(message extensions) and for receiving messages (process exten-
sions).

In this section are described the use and the formats of these
basic utilities. However, the programmer using the coroutine mo-
nitor does not have to know these things in detail, as they are
all accessed via coroutine monitor functions.

2_._1_ _ _ _ _ _ _ _C_o_r_o_u_t_i_n_e_s_._ 2.1

Each of the parallel activities that may coexist and cooperate
within this system is performed by a coroutine. A coroutine may
communicate with other coroutines within the system and with pro-
cesses outside the system by using the coroutine monitor func-
tions. Each individual coroutine looks very much like a sequen-
tial program eventually forming an endless log, in which there is
at least one waiting point (a program point in which the corou-
tine waits for some event from another coroutine or from some
foreign process).

A coroutine is implemented as an activity (algol 8 activity) ex-
tended with a coroutine description of the following format:

-2
+0 UUUcoroutine chain fieldsDDD
+2
+4 UUUtimer chain fieldsDDD
+6
+8 UUUoperation chain fieldsDDD
+10 time to timeout
+12 coroutine identification
+14 coroutine priority
+16 operation type set, testmask \f

2_._2_ _ _ _ _ _ _ _S_i_m_p_l_e_ _S_e_m_a_p_h_o_r_e_s_._ 2.2

The simple semaphore is mainly a synchronizing primitive. The
format of a simple semaphore is:

-2
+0 UUUchain head for waiting coroutinesDDD
+2 semaphore value

The semaphore value indicates, whether the semaphore is open or
not. Whem the value is negative, it indicates the number of co-
routines waiting for a signal to arrive on the semaphore. When
the value os positive, it indicates the number of signals that
have arrived withour being asked for.

2_._3_ _ _ _ _ _ _ _C_h_a_i_n_e_d_ _S_e_m_a_p_h_o_r_e_s_._ 2.3

The chained semaphore is both a synchronizing and a message ex-
change primitive at the same time. The format of a chained sema-
phore is:

-2
+0 UUUchain for waiting coroutinesDDD
+2
+4 UUUchain for waiting operationsDDD

Messages exchanged via chained semaphores are called operations
(explained below). As operations signalled on a gives semaphore
may be of differnet types and as coroutines may ask (wait) for
operations of specific types to arrive, both coroutine chain and
operation chain may be nonempty at the same time.

2_._4_ _ _ _ _ _ _ _O_p_e_r_a_t_i_o_n_s_._ 2.4

An operation is a programmer defined buffer with a head of this
format:

-6 size of buffer (excluding the head)
-4 operation type
-2
+0 UUUchain fieldsDDD
+2
+4
+6
. UUUmessage or buffer areaDDD
.
.

The programmer never has to worry about the contents of the
head.

An operation is identified by an integer array field value and if
this value resides in an integer array field variable "op", the
programmer may access the message or bugger area as "d.op(1)",
"d.op(2)" etc.

2_._5_ _ _ _ _ _ _ _E_x_t_e_n_s_i_o_n_s_._ 2.5

Extension (message extensions and process extensions) are used by
the coroutine monitor to establish the connections between a mes-
sage and the sending coroutine and between a message receiver (a
pseudo process) and a coroutine, handling messages arrived at
this receiver.
\f

A message extension looks like this:

messref (N) message buffer address
messop (N) coroutine or operation address
messcode (N) state of extension, action to be performed
when the answer arrives.

A process extension is very simular and looks like this:

procref (N) (pseudo) process descriptor address
procop (N) coroutine or operation address
proccode (N) state of extension, action to be performed
when message arrives.

3_._ _ _ _ _ _ _ _ _B_A_S_I_C_ _F_U_N_C_T_I_O_N_S_._ 3.

The present section describes in details the basic functions of-
fered by the coroutine monitor and the exact conventions for u-
sing these functions. The functions are grouped according to
their nature and according to the basic entities on which they
may operate. In this section is only described the functions used
during the very execution of a number of coroutines, while the
resource allocation and initialization functions are described in
later chapters.

3_._1_ _ _ _ _ _ _ _S_c_h_e_d_u_l_i_n_g_ _F_u_n_c_t_i_o_n_s_._ 3.1

A coroutine system as the present one is totally depending on the
behaviour of each individual coroutine, as a running coroutine
will keep running until it reaches a waiting point. The coroutine
monitor contains two procedures, "pass" and "delay", both of
which help coroutines by avoiding monopoly.

3_._1_ _1_ _ _ _ _ _P_a_s_s_._ 3.1.1

THIS IS A WAITING POINT PROCEDURE!

Delcaration:
procedure pass;

Function:
moves the calling coroutine from the head of the ready
queue (the queue of coroutines that are ready for exe-
cution) down below all ready coroutines of equal or
higher priority.

3_._1_._2_ _ _ _ _ _D_e_l_a_y_._ 3.1.2

THIS IS A WAITING POINT PROCEDURE

Declaration:
Procedure delay (timeout);
value timeout; integer timeout;

Function:
delays the coroutine a number of seconds as specified
by "timeout". Please note that the timer function of
the coroutine monitor is controlled by an optional in-
spection interval, which is very much controlling the
accuracy of all timeout functions.

3_._2_ _ _ _ _ _ _ _F_u_n_c_t_i_o_n_s_ _C_o_n_c_e_r_n_i_n_g_ _S_i_m_p_l_e_ _S_e_m_a_p_h_o_r_e_s_._ 3.2

The functions that may be performed on simple semaphores are
"signal", "wait" and "inspect".

3_._2_._1_ _ _ _ _ _S_i_g_n_a_l_._ 3.2.1

Declaration:
procedure signal (semaphore);
value semaphore; integer value;

function:
increases the value of the actual semaphore by 1. In
case one or more coroutines were waiting at the sema-
phore, the first one of them is moved to the ready
queue to be activated.

3_._2_._2_ _ _ _ _ _W_a_i_t_._ 3.2.2

THIS IS A WAITING POINT PROCEDURE

Declaration:
procedure wait (semaphore);
value semaphore; integer semaphore;

Function:
decreases the value of the actual semaphore by 1. In
case the avlue of the semaphore is negative after the
decrease, the calling coroutine is stopped and linked
into the chain of coroutines waiting at this sema-
phore.

3_._2_._3_ _ _ _ _ _I_n_s_p_e_c_t_._ 3.2.3

Declaration:
procedure inspect (semaphore, elements);
value semaphore; integer semaphore, elements;

Function:
delivers the actual value of the semaphore in an
integer variable and leaves the semaphore unchahged.
The interpretation of elements (after the execution of
this procedure) is:
elements =0: elements = 1*no of waiting coroutines
elements '=0: elements = no of signals not waited for

3_._3_ _ _ _ _ _ _ _F_u_n_c_t_i_o_n_s_ _C_o_n_c_e_r_n_i_n_g_ _C_h_a_i_n_e_d_ _S_e_m_a_p_h_o_r_e_s_._ 3.3

The functions that may be performed on chained semaphores are
"signalch", "waitch" and "inspectch".

3_._3_._1_ _ _ _ _ _S_i_g_n_a_l_c_h_._ 3.3.1

Declaration:
procedure signalch (semaphore, operation,
operaitontype);
value semaphore, operation, operationtype;
integer semaphore, operation;
boolean operationtype;

function:
delivers an operation of the specified type at the ac-
tual semaphore. If one or more coroutines are waiting
for an operation of that kind, it is given to he first
one of them and this coroutine is put into the ready
queue (for activation). If no coroutine waits for ope-
ration of the specified kind, the operation is linked
to the semaphore, waiting for a coroutine to take it by
"waitch". The boolean "operationtype" is trated as a
bit mask and the condition for matching types are ex-
plained under "waitch".

3_._3_._2_ _ _ _ _ _W_a_i_t_c_h_._

THIS IS A WAITING POINT PROCEDURE!

Declaration:
procedure waitch (semaphore, operation, operation-
typeset, timeout);
value semaphore, operationtypeset, timeout;
integer semaphore, operation, timeout;
boolean operationtypeset;

function:
fetches an operation of the specified type (or just be-
longing ro the specified set of types) at the actual
semaphore. In case a matching operation has arrived al-\f

ready, this operation is given to the coroutine which
then resumes execution. If no matching operation is
ready, the coroutine is linked to the semaphore, wai-
ting for a matching operation to be delivered by "sig-
nalch".

The m_a_t_c_h_i_n_g_ _c_o_n_d_i_t_i_o_n_ is a bit pettern test, performed
on the boolean "operationtype" (as defined at "signal-
ch") and the boolean "operationtypeset" (as defined at
"waitch"). If these two bitpatterns do overlap an one
or more bit positions, the delivered operation matches
the fetching coroutine.

The timeout function of the coroutine monitor makes it possible
to define a maximum waiting time. If "timeout" is positive, it is
expected to be the maximum number of seconds that the coroutine
will wait. If no matching operation arrives within that period of
time, the coroutine is put into the ready queue with the return
value "operation" set to zero, indicating that the function is
"timed out". If "time out" is not positive, the coroutine will
keep waiting undefinitely until a matching operation arrives.

3_._3_._3_ _ _ _ _ _I_n_s_p_e_c_t_c_h_._ 3.3.3

Declaration:
procedure inspectch (semaphore, operationtypeset,
operations;
value semaphore, operationtypeset;
integer semaphore, operations;
boolean operationtypeset;

Function:
scans the queue of operations at the actual semaphore,
counts the number of matching operation (the matching
condition is explained in section 3.3.2) and delivers
the result in the return variable "operations". The se-
maphore (including the queue of operations) is unchan-
ged. \f

3_._4_ _ _ _ _ _ _ _E_x_t_e_r_n_a_l_ _C_o_m_m_u_n_i_c_a_t_i_o_n_._ 3.4

When a coroutine wants to communicate with foreign processes u-
sing the message communication primitives of the monitor (ref
4.), this may be done in three different ways:

- using the high level zone procedures (read, write, inrec, out-
rec ...)
- using the low level zone procedures (monitor, getzone, setzone
...)
- using the coroutine monitor functions for external communica-
tion

The conventions for activities performing external communication
via zones are described in ref. 1. The present section only deals
with the coroutine monitor functions for external communication.
These functions are: "csendmessage", "cwaitanswer", "cwaitmes-
sage", "cregretmessage", "semsendmessage", "semwaitmessage" and
"semregretmessage". As indicated by the names these functions
fall into two different groups:

1. (names prefixed by "c").
Functions totally separating external and internal communica-
tion. The most important effect is that a coroutine waiting
for an external event may not be activated internally and it
may only wait for one specific event at a time.

2. (names prefixed by "sem").
Functions converting answers and messages from foreign proces-
ses to operations, thus enabling a coroutine to wait for a
number of external and/or internal events at the same time.

3_._4_._1_ _ _ _ _ _C_s_e_n_d_m_e_s_s_a_g_e_._ 3.4.1

Declaration:
procedure csendmessage (receiver, mess, messextension);
real array receiver;
integer array mess;
integer messextension;

Function:
sends a message, specified by "mess", to the process
specified by "receiver". Both arrays are assumed to
s_t_a_r_t_ _a_t_ _e_l_e_m_e_n_t_ _n_o_ _1_. The integer array "mess" should
be of a_t_ _l_e_a_s_t_ _8_ _i_n_t_e_g_e_r_s_. The real array "receiver" is
assumed to contain a process name in element 1 and 2,
and it m_u_s_t_ _c_o_n_t_a_i_n_ _e_l_e_m_e_n_t_ _3_ _t_o_ _h_o_l_d_ _t_h_e_ _n_a_m_e_ _t_a_b_l_e_
a_d_d_r_e_s_s_. At return from the procedure, the variable
"messextension" holds an implicit reference to the
message sent, and this reference must be used when
awaiting the answer by "cwaitanswer" or when regretting
the message by "cregretmessage".

3_._4_._2_ _ _ _ _ _C_w_a_i_t_a_n_s_w_e_r_._ 3.4.2

THIS IS A WAITING POINT PROCEDURE!

Declaration:
procedure cwaitanswer (messextension, answer, result,
timeout);
value messextension, timeout;
integer messextension, result, timeout;
integer array answer;

Function:
awaits an answer to arrive. The message to be answered
was sent by "csendmessage" and "messextension" is the
identification of this message. At return from the pro-\f

cedure, the answer is delivered in the integer array
"answer", which is supposed to s_t_a_r_t_ _a_t_ _e_l_e_m_e_n_t_ _n_o_ _1_
and to be of a_t_ _l_e_a_s_t_ _8_ _i_n_t_e_g_e_r_s_. The result is deli-
vered in the variable "result". If the parameter "time-
out" is positive, the function may be "timed out". If
the answer does not arrive within the number of seconds
specified by timeout, the coroutine will be activated
and "result" will be zero, indicating that the answer
did not arrive. If the function is "timed out", and in
case the actual message was not an i/o message, the
coroutine may perform a "cregretmessage" to unclaim the
message buffer involved.

3_._4_._3_ _ _ _ _ _C_w_a_i_t_m_e_s_s_a_g_e_._ 3.4.3

THIS IS A WAITING POINT PROCEDURE!

Declaration:
cwaitmessage (processextension, mess, messbufferref,
timeout);
value processextension, timeout;
integer processextension, messbufferref, timeout;
integer array mess;

Function:
awaits a message to arrive at the pseudoprocess (or the
internal process in which the whole system runs) poin-
ted out by "processextension" (the value of processex-
tension was defined during initialization (see chapter
5)). At return the integer array "mess" contains the
message arrived, and the integer variable "messbuffer-
ref" is the message buffer address to be used by the
coroutine, when returning an answer to the sender. If
"timeout" is positive, it specifies the maximum number
of seconds that the coroutine will wait for a message
to arrive. If the function is "timed out", the return\f

value of messbufferref is zero, indicating that no mes-
sage arrived. If "timeout" is not positive, the corou-
tine will wait indefinitely until a message arrives.

3_._4_._4_ _ _ _ _ _C_r_e_g_r_e_t_m_e_s_s_a_g_e_._ 3.4.4

Declaration:
procedure cregretmessage (messextension);
value messextension; integer messextension;

Function:
regrets a message sent by "csendmessage". Please note
that i/o messages are not regretable. In case "cwait-
answer" is "timed out", and in case the actual message
was not an i/o message, the resources allocated for
this message (message buffer and message extension)
will be released by calling "cregretmessage".
"messextension" contains the value returned by
"csendmessage" to identify the message.

3_._4_._5_ _ _ _ _ _S_e_m_s_e_n_d_m_e_s_s_a_g_e_._ 3.4.5

Declaration:
procedure semsendmessage (receiver, mess, semaphore,
operation, operationtype);
value semaphore, operation, operationtype;
real array receiver;
integer array mess;
integer semaphore, operation;
boolean operationtype;

Function:
sends a message, specified by "mess", to the process
specified by "receiver" and defines the "signalch"
function to be performed by the coroutine monitor, when\f

The integer array "mess" contains the message to be
sent, and it is assumed to s_t_a_r_t_ _a_t_ _e_l_e_m_e_n_t_ _n_o_ _1_ and to
contain a_t_ _l_e_a_s_t_ _8_ _i_n_t_e_g_e_r_s_.

The real array "receiver" contains the name of the re-
ceiving process. It is assumed to s_t_a_r_t_ _a_t_ _e_l_e_m_e_n_t_ _n_o_ _1_
and to contain a_t_ _l_e_a_s_t_ _3_ _r_e_a_l_s_ (receiver(3) is used
for the name table address).

When the answer arrives, the coroutine monitor will co-
py the answer to the first 8 integers of the operation,
put the result into the 9>th integer and then perform a
"signalch (semaphore, operation, operationtype)". Be-
cause of this mechanism, the coroutine may await its
answer to arrive or some other internal or external e-
vent to arrive by performing a "waitch (semaphore, ope-
ration, operationtypeset, timeout)" where the opera-
tiontype defined at calling "semsendmessage" must match
"operaiontypeset".

Please note that the size of the operation (buffer)
must be at least 18 halfwords (9 integers).

3_._4_._6_ _ _ _ _ _S_e_m_w_a_i_t_m_e_s_s_a_g_e_._ 3.4.6

Declaration:
procedure semwaitmessage (processextension, semaphore,
operation, operationtype);
value processextension, semaphore, operation,
operationtype;
integer processextension, semaphore, operation;
boolean operationtype;
\f

Function:
defines a "signalch" function to be performed by the
coroutine monitor, when a message arrives at the pseudo
process (or the internal process in which the system
runs) specified by "processextension".

When the message arrives, the coroutine monitor will
copy the message into the first 8 integers of the ope-
ration, put the message buffer address into the 9>th
integer and then perform a "signalch (semaphore, opera-
tion, operationtype)". Thus a message is converted to
an operation and it may be awaited by performing a
"waitch(semaphore, operation, operationtypeset, time-
out)" where the operationtype defined at calling
semwaitmessage must match "operationtypeset".

Please note that the size of the operation (buffer)
must be at least 18 halfwords (9 integers).

3_._4_._7_ _ _ _ _ _S_e_m_r_e_g_r_e_t_m_e_s_s_a_g_e_._ 3.4.7

Declaration:
procedure semregretmessage (operation);
value operation;
integer operation;

Function:
regrets the message that has been sent by "semsendmes-
sage" and for whom the answer should be returned in the
operation identified by "operation".
Only messages to whom the answer has not yet arrived
may be regretted by this procedure.

The result field of the operation is set to zero, indi-
cating, that the message was regretted.

This function is primarily intended for releasing re-
sources (message buffers, message extensions and opera-
tions) occupied by unanswered messages. \f

Please note that i/o messages are not regretable.

4_._ _ _ _ _ _ _ _ _A_S_S_O_C_I_A_T_E_D_ _F_U_N_C_T_I_O_N_S_._ 4.

In the former chapter are described the basic functions of the
coroutine monitor. These functions include scheduling,
synchronizing and internal and external communication. In this
section are described some associated functions, some of which
have already been mentioned in the former section. The functions
to be described in this section are:

- event handling strategy
- timeout functions
- types of operations (buffers)
- testoutput facilities

4_._1_ _ _ _ _ _ _ _S_c_h_e_d_u_l_i_n_g_ _S_t_r_a_t_e_g_y_._ 4.1

In this section is described the strategy for handling external
and internal events. The strategy of the coroutine monitor de-
fines the order in which events are handled and coroutines are
served. The strategy is used each time a coroutine enters a wai-
ting point procedure.

4_._1_._1_ _ _ _ _ _C_o_r_o_u_t_i_n_e_ _P_r_i_o_r_i_t_i_e_s_._ 4.1.1

The coroutine monitor includes a straightforward coroutine sche-
duling based on coroutine priorities (defined at initialization).
The scheduling strategy is realized like this:

- whenever a coroutine is linked into a queue, it is placed in
the queue according to its priority (immediately ahead of the
first coroutine of lower priority)
- whenever a coroutine is selected from a queue, the queue is
scanned from the head.

By doing this, the system will always select a coroutine of the\f

highest priority available and if more coroutines are of equal
priority, the one that has spent the longest time on the queue is
selected.

4_._1_._2_ _ _ _ _ _E_x_t_e_r_n_a_l_ _E_v_e_n_t_s_._ 4.1.2

Each time a coroutine enters a waiting point procedure, the co-
routine monitor will scan all external events that have arrived.
For each external event it is checked, whether it is waited for
and if that is the case, the corresponding action will be taken
(put waiting coroutine into ready queue, convert event to
operation and signal semaphore etc.). After scanning the queue of
external events, the first coroutine of the ready queue is
activated.

This strategy implies that external events are handled (schedu-
led) as fast as possible and the priority of the corresponding
coroutine defines the internal scheduling. By doing so, the co-
routine monitor is able to run a system including coroutines with
severe response time demands and coroutines permanently running
background activities.

4_._2_ _ _ _ _ _ _ _T_i_m_e_o_u_t_ _F_u_n_c_t_i_o_n_s_._ 4.2

The coroutine monitor includes a set of timer functions. All
these functions are based on a timer queue into which all corou-
tines currently waiting for a timeout (and eventually some other
kind of event) are linked. At the end of each inspection inter-
val, the timerqueue is scanned. Coroutines for whom the timeout
period has expired are moved to the ready queue with proper indi-
cation of the cause.

The inspection interval is a system option, defining the accuracy
(and the overhead) of the timeout function.

4_._3_ _ _ _ _ _ _ _T_y_p_e_s_ _o_f_ _O_p_e_r_a_t_i_o_n_s_._ 4.3

As explained in section 3, the functions concerning chained sema-
phores are extended to cover the "operation type" concept.

The "operation types" are introduced to enable coroutines to wait
for a selected type or a set of selected types of operations. The
present concept even allows different coroutines to wait for dif-
ferent (maybe overlapping) sets of operation types, thus offering
facilities that it would not be possible to implement even by
using a number of different semaphores.

The condition for an operation to match a waiting coroutine is,
that the type of the operation overlaps the typeset defined by
the coroutine (usually an operationtype is represented by a sin-
gle bit and the condition is that the typeset of the waiting co-
routine includes the type of the operation).

4_._4_ _ _ _ _ _ _ _T_e_s_t_o_u_t_p_u_t_ _F_a_c_i_l_i_t_i_e_s_._ 4.4

The coroutine monitor may currently generate testoutput to be
used for tracing and debugging purposes.

The testoutput mechanism may be switched off totally, as
explained in section 6. Even when included, it is possible to
select different kinds of testoutput for each individual
coroutine.

The testoutput records generated by the coroutine monitor are
grouped like this:
\f

n_a_m_e_ _o_f_ _g_r_o_u_p_:_ _ _ _ _ _ _G_e_n_e_r_a_t_e_s_ _t_e_s_t_o_u_t_p_u_t_ _a_t_:_

semtest signal
wait
inspect

semchtest signalch
waitch
inspectch

ceventtest csendmessage
cwaitanswer
cwaitmessage
cregretmessage

semeventtest semsendmessage
semwaitmessage
semregretmessage

schedulingtest pass
delay
+ each time a coroutine is activated after
a waiting point

The testoutput is controlled by a bit pattern with a bit repre-
senting each of the groups listed above. Each coroutine has its
own bit pattern, which is defined at initialization (see section
5) and stays unchanged during its lifetime.

It is possible for a coroutine to generate its own testrecords by
using the following testoutput procedures (the private testre-
cords will be written into the global testoutput area):
\f

- procedure test _0 (recordid);
value recordid;
integer recordid;

generates a testrecord identified by "recordid"

- procedure test _val (recordid, integervalue);
value recordid, integervalue;
integer recordid, integervalue;

generates a testrecord identified by "recordid" and inclu-
ding the value of "integervalue".

- procedure test _val _val (recordid, ivalue1, ivalue2);
value recordid, ivalue1, ivalue2;
integer recordid, ivalue1, ivalue2;

generates a testrecord identified by "recordid" and inclu-
ding the values of "ivalue1" and "ivalue2".

- procedure test _arr (recordid, iarr, size);
value recordid, size;
integer recordid, size;
integer array iarr;

generates a testrecord identified by "recordid" and
including size/2 integers from the array "iarr" (iarr(1),
iarr(2), ..... iarr(size/2))

- procedure test _arr _val (recordid, iarr, size, ivalue);
value recordid, size, ivalue;
integer recordid, size, ivalue;
integer array iarr;

generates a testrecord identified by "recordid" and inclu-
ding size/2 integers from the array"iarr" (iarr(1),
iarr(2),.... iarr(size/2)) and the value of "ivalue". \f

When generating private testrecords, "recordid" should not be
less than 100 to avoid confusion with records generated by the
coroutine monitor.

The program "ctrace" may print selected parts of the testarea.

Each testrecord contains a record identification, a time stamp
(time relative to startup) and an identification of the coroutine
explicitly or implicitly generating the testrecord. The rest of a
testrecord is printed as a series of integers and the interpreta-
tion is individual to each record type (see chapter 8).

5_._ _ _ _ _ _ _ _ _R_E_S_O_U_R_C_E_ _A_L_L_O_C_A_T_I_O_N_._ 5.

The present algol8 coroutine monitor is implemented as a skeleton
program, establishing the environment of the coroutines. The
coroutine monitor administers the allocation and initialization
of the basic entities (coroutine descriptors, semaphores,
extensions and operations). Because of the scope rules etc. of
algol, the resource allocation has been split into a number of
different steps, concerning:

- claiming of basic entities
- declaration of procedures and common variables
- initialization of basic entities, common variables and activi-
ties (coroutines)
- reserving stackspace for each individual activity (coroutine).

As it is explained in section 6, a dedicated merging program is
capable of merging a number of files into the skeleton program
text. The steps mentioned above are reflected by a number of
points in the skeleton program, at which the individual corouti-
nes may append algol program pieces for claiming, declaration
etc.

5_._1_ _ _ _ _ _ _ _C_l_a_i_m_i_n_g_ _o_f_ _B_a_s_i_c_ _E_n_t_i_t_i_e_s_._ 5.1

The basic entities are claimed simply by adding a number to a
counter. There is a counter for each type of resource. The coun-
ters are:

maxcoru the number of coroutines claimed so far
maxsem the number of simple semaphores claimed so far

maxsemch the number of chained semaphores claimed so far

maxop the number of operations claimed so far
maxnettoop the accumulated number of halfwords claimed for
operation buffers (not including the head of the
operations, which are counted by "maxop"). \f

maxmessext the number of message extensions claimed so
far.
maxprocext the number of process extensions claimed so
far.

The following rules apply when claiming the basic entities for a
coroutine or a set of coroutines (the example discussed in sec-
tion 7 may be helpful as an illustration to these rules):

maxcoru add 1 for each coroutine
maxsem add 1 for each simple semaphore (please note
that even though a semaphore is normally used
by several coroutines, it should only be
claimed once)
maxsemch add 1 for each chained semaphore
maxop add 1 for each operation
maxnettoop add the number of halfwords occupied by each
operation (operations may be of variable
length)
maxmessext add the largest number of messages that may
be in use at a time (a message is in use from
the call of "csensmessage" to the return from
"cwaitanswer" or from the call of "semsend-
message" to the return from the "waitch",
fetching the operation in which the answer is
signalled)
maxprocext add 1 for each pseudoprocess that is used to
receive messages

5_._2_ _ _ _ _ _ _ _I_n_i_t_i_a_l_i_z_a_t_i_o_n_._

At startup, the claimed resources should be initialized. The ba-
sic entities are initialized by means of the following set of i-
nitializing procedures:
\f

- integer procedure nextcoru (ident, prioroty, testmask);
value ident, priority, testmask;
integer ident, priority;
boolean testmask;

this procedure initializes the next descriptor from the pool
of claimed coroutine descriptors.

"ident" should be a number between 0 and 8000. It is used to
identify the testrecords generated by this coroutine. The
identification in the testrecord is "ident"*1000+coroutine
no (coroutine no = activity no).

"priority" may be any integer value, but it is important for
the behaviour of the total system that priorities of all co-
routines are harmonized.

"testmask" defines the kind of testrecords that should be
generated by this coroutine (see section 4.4). "false" means
no testoutput, "true" means full testoutput and selected
testoutput may be defined for instance by stating: "schedu-
lingtest or ceventtest".

The return value "nextcoru" is the coroutine number of the
actual coroutine. T_h_i_s_ _n_u_m_b_e_r_ _n_u_s_t_ _b_e_ _u_s_e_d_,_ _w_h_e_n_ _c_a_l_l_i_n_g_
"_n_e_w_a_c_t_i_v_i_t_y_"_ to start up a coroutine.

- integer procedure nextsem;

this procedure initializes the next simple semaphore in the
pool of claimed semaphores. The semaphore is initialized to
be in neutral state (value = 0).

The return value "nextsem" is the semaphore identification
to be used when performing the basic functions signal, wait
and inspect.
\f

- integer procedure nextsemch;
this procedure initializes the next chained semaphore in the
pool of claimed semaphores. The semaphore is initialized to
be in neutral state (no coroutines waiting, no operations
ready).

- integer procedure nextop (size);
value size;
integer size;

this procedure initializes the next operation in the pool of
operations. It allocates an operationhead, and immidiately
following the head it allocates "size" halfwords for the o-
peration buffer.

The return value "nextop" is an identification of the opera-
tion and at the same time it is a field value to be used
when addressing the buffer area. (If "op" contains the value
returned by "nextop", the buffer may be accessed like this:
d.op(1), d.op(2), d.op(3) ....).

- integer procedure nextprocext (processref);
value processref;
integer processref;

this procedure initializes the next process extension in the
pool of claimed process extensions.

"processref" must be the process description address of a
pseudo process belonging to the internal process, in which
the system runs - or the internal process itself.

The return value "nextprocext" is an identification of the
process extension (and implicitly of the process) to be
used, when calling "cwaitmessage" or "semwaitmessage".
\f

(Message extensions are all automatically initialized by the co-
routine monitor - they are all free at startup).

During and after the initialization phase, the coroutine monitor
checks that no unclaimed entities are initialized and that all
claimed entities are initialized. The check only concerns the to-
tal number of entities of each kind, so the system cannot pin-
point errors (however, it is possible to merge a single file into
the skeleton program at a time and then check resourceconsisten-
cy for each individual coroutine file).

5_._3_ _ _ _ _ _ _ _C_l_a_i_m_i_n_g_ _S_t_a_c_k_s_p_a_c_e_ _f_o_r_ _a_ _C_o_r_o_u_t_i_n_e_._ 5.3

The actual implementation of activities in algol8 (as described
in ref 1.) allows each activity (coroutine) to have its own stack
surviving as a part of the main stack, even when the coroutine is
left (in a waiting point). The local coroutine stack is handled
almost like a usual algol stack, when the coroutine is running.
Entering a procedure or a block will cause the running system to
allocate stack space on top of the coroutine stack. As the
coroutine stack is an inner part of the main stack, the pos-
sibilities for allocating local stack space is limited.

The need for local stack space must be known in advance and the
convention is that a coroutine will get allocated the maximum a-
mount of stack space that is claimed from the startup of the co-
routine, till it reaches a waiting point.

To support this stack reservation mechanism, the coroutine moni-
tor includes the following procedure:

procedure stackclaim (size);
value size;
integer size;
\f

this procedure allocates an array of "size" halfwords and
then returns. The effect is that the running system will set
the limit for maximum available stack space to be approxi-
mately size (halfwords) more than what is in use when the
procedure is called.

6_._ _ _ _ _ _ _ _ _H_O_W_ _T_O_ _M_A_K_E_ _A_ _C_O_R_O_U_T_I_N_E_ _A_N_D_ _I_N_C_O_R_P_O_R_A_T_E_ _I_T_ _I_N_ _A_ _C_O_R_O_U_T_I_N_E_ _S_Y_S_T_E_M_._ 6.

The coroutine monitor is implemented as a skeleton program for-
ming the environment of the coroutines. This concept is directly
reflected by the way of incorporating texts into the skeleton
program text.

The skeleton program contains a set of merging labels (program
points) defining a gap for insertion of coroutine text portions.

In this section is described the text merging program and the
types of coroutine text portions to be inserted at each merging
label.

6_._1_ _ _ _ _ _ _ _T_e_x_t_ _M_e_r_g_i_n_g_ _P_r_o_g_r_a_m_._ 6.1

A text merging program (usually called "cmerge" for "coroutine
merge") is capable of merging a number of source files into a
master file, generating an object file.

The program is called like this:

r obj.file'= cmerge masterfile' source .source file' 0UUU*DDDDDD1UUU5 skip .number'
0UUU*DDDDDD1UUU5

The skeleton program is used as masterfile while the coroutine
files are source files.
\f

The merging procedure may be visualized like this:

(TEGNING)

As it appears from the example, the first part of a source file
is neglected (considered to be a comment, and the first line of
this comment is written on current output during the merging
process). A source file does not have to include all kinds of
program parts. The program parts are identified by their leading
merging label.

A merging label must be the first part of a text line and it must
obey the following syntax:

merging label'::= :digit':
digit'::= 12345

The merging program may skip selected parts of master and source
files depending on the skip parameters of the program call.

Special algol comments of the forms

*+digit'*' and *-digit'*'

are defined to be skip brackets and they are interpreted like
this (they must always be placed on the very first positions of
a text line as it is the case for merging labels):

Whenever an opening bracket is met (*+...*') it is checked,
whether the number of this bracket is included in the skip
numbers from the program call. If this is the case, all text
will be skipped upto the corresponding closing bracket
(*-...*') regardless of other brackets eventually met in
between.

6_._2_ _ _ _ _ _ _ _C_o_r_o_u_t_i_n_e_ _T_e_x_t_ _P_o_r_t_i_o_n_s_._ 6.2

To build up a coroutine system, the programmer will have to write
a number of coroutine text portions, forming one or more source
files and then merge these files with the coroutine monitor text.
The coroutine text portions may belong to these five kinds:
\f

1. declaration of trimming variables (configuration parame-
ters).

2. initialization of trimming variables.

3. claiming of basic entities (as described in section 5.1).

4. declaration of variables and procedures (including common va-
riables and procedures and individual activity procedures).

5. Initialization of basic entities, common variables and activi-
ties (coroutines).

6_._2_._1_ _ _ _ _ _D_e_c_l_a_r_a_t_i_o_n_ _o_f_ _T_r_i_m_m_i_n_g_ _V_a_r_i_a_b_l_e_s_._ 6.2.1

When creating a coroutine system, a number of resources etc. may
be subject to variations when used in different configurations or
for different purposes. So it is of great interest to control re-
source allocation by a small number of configuration (trimming)
parameters.

In this text portion, the programmer may declare that kind of va-
riables.

(For practical purposes, it would be nice to collect all trimming
variables (and their initialization) and put them into a single
source file).

Example:

:1: trimming variables
integer maxcarswaiting, maxcarwashers;

6_._2_._2_ _ _ _ _ _I_n_i_t_i_a_l_i_z_a_t_i_o_n_ _o_f_ _T_r_i_m_m_i_n_g_ _V_a_r_i_a_b_l_e_s_._ 6.2.2

The trimming variables mentioned in the previous section should
be initialized in the source file in which they were declared.

Example:

:2: trimming
maxcarwashers:= 3;
maxcarswaiting:= 25;

6_._2_._3_ _ _ _ _ _C_l_a_i_m_i_n_g_ _o_f_ _B_a_s_i_c_ _E_n_t_i_t_i_e_s_._ 6.2.3

The claiming of basic entites is explained in section 5.1.

Example:

:3: claiming of basic entities
*one coroutine per carwasher*'
maxcoru:= maxcoru+maxcarwashers;
*one simple semaphore (the washers telephone)*'
maxsem:= maxsem+1;

6_._2_._4_ _ _ _ _ _D_e_c_l_a_r_a_t_i_o_n_ _o_f_ _V_a_r_i_a_b_l_e_s_ _a_n_d_ _P_r_o_c_e_d_u_r_e_s_._ 6.2.4

This text portion is used for declaring common variables and pro-
cedures (common to a number of coroutines) and for declaring the
activity (coroutine) procedures.

Typically, the identification of semaphores (used by several com-
municating coroutines) are held in integer variables declared in
this text portion (the variables are initialized during initiali-
zation as shown in section 6.2.5).
\f

The very coroutine code (the activity procedure) is declared in
this text portion, too, and it is up to the programmer to
initialize the activity in the initialization part by calling
"newactivity".

Example:

:4: variables and procedures
* common variable for time measure *'
real timebase;
* common time stamp procedure *'
integer procedure now;
begin real r;
systime (1, timebase, r);
now:= r;
end;

car generator coroutine *'
procedure cargenerator;
begin
real array washingprocess(1:3);
integer array carmessage, caranswer(1:8);
integer messageref, result, i;
for i:= 1 step 1 until 8 do carmessage(i):= 0;
system(6, i, washingprocess);
stackclaim(60);
repeat
delay (random(i)*4);
csendmessage (washingprocess, carmessage, messageref);
cwaitanswer (messageref, caranswer, result, 0);
until false;
end;

6_._2_._5_ _ _ _ _ _I_n_i_t_i_a_l_i_z_a_t_i_o_n_._ 6.2.5

This text portion is used for initializing common variables, ba-
sic entities and activity procedures (coroutines).

The initialization of basic entities is performed by using the
initialization procedures described in section 5.2. After the
claiming are allocated pools of uninitialized entities, and each
call of an initializing procedure will initialize the next
uninitialized entity of the actual type and return an
identification of it to be used when calling basic functions,
operating on this entity.

The programmer declared common variables are initialized by ordi-
nary algol assignments.

The activities are initialized by calling "newactivity" with the
following syntax:

r lcause':= 0UUU1DDDDDD0UUU5 newactivity (act.no', act.proc' ,param'
0UUU*DDDDDD0UUU5 )

lcause' is the result from newactivity. lcause' is a long and
the interpretation of it is described in ref....

act.proc.' is the activity procedure as declared in a coroutine
text portion of type :4:.

param' is some kind of actual parameter corresponding to the
formal parameter of the activity procedure: act.proc'.

Please note that the correspondence is not automatically checked
by the system, so the programmer must check it carefully
himself.
\f

Example:

:5: initialization
j:= nextcoru (3, 10, true);
newactivity (j, j, cargenerator);

Please note that "newactivity" must not be situated in an inner
algol block because of the stack manipulations performed when
initializing an activity.

7_._ _ _ _ _ _ _ _ _A_N_ _E_X_A_M_P_L_E_ _O_F_ _A_ _C_O_R_O_U_T_I_N_E_ _S_Y_S_T_E_M_ _U_S_I_N_G_ _T_H_E_ _A_L_G_O_L_8_ _C_O_R_O_U_T_I_N_E_7.
M_O_N_I_T_O_R_._

In this chapter is shown and explained an example of a coroutine
system using a variety of the facilities of the algol8 coroutine
monitor.

The example is based on a simulation experiment that is slightly
modified to include as many basic functions as possible.

The simulation model and the transformation into a coroutine
system is described, and the actual source files are listed and
commented.

The results from running the simulation model is shown and fi-
nally a printout of some testoutput generated by this model is
shown.

7_._1_ _ _ _ _ _ _ _S_i_m_u_l_a_t_i_o_n_ _M_o_d_e_l_._ 7.1

The simulation concerns a car washing company and the behaviour
of the system is described like this:

- cars arrive with some intensity to the company to get washed.
- to get his car washed the car driver will have to buy a ticket
from the ticket clerk.
- when the driver has got a ticket, the car enters the waiting
line, where it may have to spend some time before getting
served.
- the ticket clerk monitors the waiting line, and in case the
queue of waiting cars is too long, he will call for another
washer (if they are not all busy at the moment).
- cars are washed manually by a number of car washers (one washer
for each car) and all washers may wash simultaneously.
- when some washer has been waiting for some time for a car to
arrive on the waiting line, and no cars arrive, he will enter
the tearoom and stay there until he is called for. \f

- if for some (long) period of time no cars arrive, the company
is closed.

7_._2_ _ _ _ _ _ _ _T_r_a_n_s_f_o_r_m_i_n_g_ _t_h_e_ _S_i_m_u_l_a_t_i_o_n_ _M_o_d_e_l_ _i_n_t_o_ _a_ _C_o_r_o_u_t_i_n_e_ _S_y_s_t_e_m_._ 7.2

When some system is going to be transformed into a coroutine sys-
tem of the kind supported by the algol8 coroutine monitor, the
following rules of thumb will often apply:

- active entities (entities actively operating on objects) should
be transformed into coroutines).
- passive entities manipulated by and/or transferred among a num-
ber of active entities should be transformed into operations or
common objects guarded by access semaphores.
- queues should be transformed into chained semaphores.
- simple communication should be realized via simple semaphores.
- communication including exchange of data should be realized via
chained semaphores and operations.

With these rules in mind, the simultation model would naturally
be transformed like this:

- the active parts of the system are the ticket clerk (putting
cars into the waiting line and calling for washers if neces-
sary) and the car washers (awaiting cars at the waiting line,
washing them and going to the tearoom in free periods).
Therefore each carwasher is represented by a "carwasher corou-
tine" and the ticket clerk is represented by a "ticket clerk
coroutine".

- The passive parts are the cars, manipulated by ticket clerk and
car washers. Cars arrive and cars leave, and there is no
limitation on the number of cars passing the system, so it
would not be reasonable to allocate an operation to each car.
However, there is a maximum number of cars within the system at
any moment (i.e. the maximum number of cars in the waiting\f

line) so an operation representing each car position on the
waiting line will do.
- The waiting line is a queue and it is naturally represented by
a chained semaphore.
- the tearoom in which the car washers are waiting when they are
free, may be thought of as a synchronizing entity (here washers
wait until the ticket clerks call for them - triggers them).
Thus the tearoom is represented by a simple semaphore.

The only thing that is left is to decide, how cars enter the sys-
tem and how they are generated.

There are several possibilities and the one used here is pre-
ferred mainly because it uses some other coroutine functions than
what has been used by the former coroutines.

The ticket clerk receives cars by receiving messages. These mes-
sages may be generated by other processes (for instance by termi-
nals sending attention messages) or they may be generated by a
coroutine within the simulation system.

Consequently a car generator coroutine has been created to send
messages (representing cars) with some intensity. The car genera-
tor awaits an answer to each message which means that cars are
only generated while the ticket clerk is able to put them onto
the waiting line (simulating that cars, arriving when the queue
is full, leave at once).

Now the main decisions have been made, concerning the structure
of the coroutine system. The actual layout of the operations etc.
is not discussed here.

7_._3_ _ _ _ _ _ _ _S_o_u_r_c_e_ _F_i_l_e_s_ _f_o_r_ _C_o_r_o_u_t_i_n_e_ _S_y_s_t_e_m_._7.3

In this section is shown an implementation of the car washing
simulation. \f

The source files are organized according to the following rules:

- all trimming variables (including declaration and initializa-
tion) are put into one source file together with all common
variables and procedures (including claiming, declaration and
initialization).
- all variables and procedures local to a specific c_o_r_o_u_t_i_n_e_ _t_y_p_e_
are put into one source file (including claiming, declaration
and initialization).

When following these rules, the car washing system will contain
the following set of files:

- a trimming file
- a ticket clerk file
- a car washer file
- a car generator file

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

1. INTRODUCTION ....................................... 2

2. BASIC ENTITIES ..................................... 9
2.1 Coroutines ................................... 9
2.2 Simple Semaphores ............................ 10
2.3 Chained Semaphores ........................... 10
2.4 Operations ................................... 11
2.5 Extensions ................................... 11

3. BASIC FUNCTIONS .................................... 13
3.1 Scheduling Functions ......................... 13
3.1.1 Pass ................................. 13
3.1.2 Delay ................................ 14
3.2 Functions Concerning Simple Semaphores ....... 14
3.2.1 Signal ............................... 14
3.2.2 Wait ................................. 15
3.2.3 Inspect .............................. 15
3.3 Functions Concerning Chained Semaphores ...... 15
3.3.1 Signalch ............................. 16
3.2.2 Waitch ............................... 16
3.3.3 Inpsectch ............................ 17
3.4 External Communication ....................... 18
3.4.1 Csendmessage ......................... 19
3.4.2 Cwaitanswer .......................... 19
3.4.3 Cwaitmessage ......................... 20
3.4.4 Cregretmessage ....................... 21
3.4.5 Semsendmessage ....................... 21
3.4.6 Semwaitmessage ....................... 22
3.4.7 Semregretmessage ..................... 23

4. ASSOCIATED FUNCTIONS ............................... 25
4.1 Scheduling Strategy .......................... 25
4.1.1 Coroutine Priorities ................. 25
4.1.2 External Events ...................... 26 \f

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _(_C_O_N_T_>_D_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

4.2 Timeout Functions ............................ 26
4.3 Types of Operations .......................... 27
4.4 Testoutput Facilities ........................ 27

5. RESOURCE ALLOCATION ................................ 31
5.1 Claiming of Basic Entities ................... 31
5.2 Initialization ............................... 32
5.3 Claiming Stackspace for a Coroutine .......... 35

6. HOW TO MAKE A COROUTINE AND INCORPORATE IT IN A
COROUTINE SYSTEM ................................... 37
6.1 Text Merging Program ......................... 37
6.2 Coroutine Text Portions ...................... 39
6.2.1 Declarations of Trimming Variables ... 40
6.2.2 Initialization of Trimming Variables . 41
6.2.3 Claiming of Basic Entities ........... 41
6.2.4 Declaration of Variables and
Procedures ........................... 41
6.2.5 Initialization ....................... 43

7. AN EXAMPLE OF A COROUTINE SYSTEM USING THE ALGOL8
COROUTINE MONITOR .................................. 45
7.1 Simultation Model ............................ 45
7.2 Transforming the Simultation Model into a
Coroutine System ............................. 46
7.3 Source Files for Coroutine System ............ 47
\f

R_C_ _s_y_s_t_e_m_ _F_L_E_X_ _o_g_ _v_i_r_k_s_o_m_h_e_d_e_n_s_ _s_t_y_r_i_n_g_._

RC system FLEX opgave er at forsyne virksomhedens medarbejdere
med relevante informationer til de beslutninger, der løbende skal
tages i det daglige arbejde, og til den opfølgende kontrol af be-
slutningernes økonomiske konsekvenser.

Arbejdet med RC system FLEX kan opdeles således:

Registrering af grundbilag og kartoteksoplysninger
Daglig styring ad vare- og pengestrømme
Kontrol af den økonomiske udvikling

R_e_g_i_s_t_r_e_r_i_n_g_ _a_f_ _g_r_u_n_d_b_i_l_a_g_ _o_g_ _k_a_r_t_o_t_e_k_s_o_p_l_y_s_n_i_n_g_e_r_._

Registreringsopgavens gennemførelse er en meget vigtig forudsæt-
ning for anvendeligheden af systemets informationer. Grundbilage-
ne skal registreres hurtig, således at systemets oplysninger til
stadighed udtrykker de fysiske realiteter for virksomheden.

I selve registreringsprocessen, som foregår ved dataskærme, er
der inbygget både fejlkontroller og styringskontroller.

Fejl optræder, når man behandler systemet forkert. Man bliver
straks gjort opmærksom på fejlen og kan ikke fortsætte, før den
er rettet.

Styringskontroller skal sikre, at uønskede situationer ikke op-
står. F.eks. kommer der en advarsel ved salgsordreregistreringen,
hvis kunden har forfalden saldo, har overskredet kreditgrænsen,
eller hvis varen er under lagerminimum. De forskellige advarsler,
der kan fremkomme, skal resultere i, at man undersøger situatio-
nen og lader den ansvarlige tage beslutningen om, hvad der så
skal ske.
\f

De forskellige styrekontroller blokerer ikke arbejdet ved skær-
men, og ordren kan registreres, selv om kundens saldo er over
kreditmaksimum. Alle advarsler fra styrekontroller, der ikke er
blevet taget hensyn til, fremkommer igen ved dagsslut som anmærk-
ninger på de forskellige journaler.

D_a_g_l_i_g_ _s_t_y_r_i_n_g_ _a_f_ _v_a_r_e_-_ _o_g_ _p_e_n_g_e_s_t_r_ø_m_m_e_._

RC system FLEX udfører disse styrekontroller ved registreringen
og kan desuden producere en række planlægningsoversigter baseret
på salgsordrebeholdningen, planlagt produktion, indkøbsordrebe-
holdningen og de aktuelle varelagre.

Den daglige styring kan opdeles i følgende hovedopgaver:

Kundeordrebehandling
Leveringskontrol od fakturering
Produktion, indkøb og varelagerstyring
Styring af ind- og udbetalinger

K_o_n_t_r_o_l_ _a_f_ _d_e_n_ _ø_k_o_n_o_m_i_s_k_e_ _u_d_v_i_k_l_i_n_g_._

Den økonomiske styring af et firma er almindeligvis baseret på
opstilling af nogle m_å_l_ i form af handlingsplaner, budgetter og
en månedlig k_o_n_t_r_o_l_ af handlingernes gennemførelse i form af den
regnskabsmæssige budgetopfølgning og afvigelsesforklaringer.
Kontrollen kan give anledning til, at handlingsplanerne må ændres
for at kunne nå det opstillede mål. \f

RC System FLEX opgave er at udføre en del af budgetkontrollen
samt at give forskellige analyser til brug for afvigelsesforkla-
ringerne. Det er så ledelsens opgave at vurdere og forklare afvi-
gelserne og eventuelt at beslutte at ændre i handlingsplanerne.

Rapporteringen i forbindelse med den økonomiske styring er opdelt
således:

Resultatrapport
Likviditetsanaluse
Salgsanalyse
Produktions- og lageranalyse

Systemet er i stand til at behandle flere adskildte firmaer med
fælles registre.

I denne forbindelse er behovet for sikkerhed løst via et bru-
gerkatalog, hvori hvert firma har et specielt "password", som
tillader adgang til firmaets specifikke del af registrene.

Systemet kan logisk opdeles i følgende undersystemer eller
moduler:

S_a_l_g_s_f_u_n_k_t_i_o_n_e_n_

salgsordremodul
fakturamodul

K_ø_b_s_f_u_n_k_t_i_o_n_

købsordremodul
registrering af lagertilgang
behandling af leverandørfakturaer
\f

P_r_o_d_u_k_t_i_o_n_ _o_g_ _l_a_g_e_r_s_t_y_r_i_n_g_s_f_u_n_k_t_i_o_n_

Planlægnings- og ordremodul

Ø_k_o_n_o_m_i_f_u_n_k_t_i_o_n_

Debitormodul
Kreditormodul
Finansmodul

I de følgende 2 kapitler er redegjort for:

1) RC System FLEX som løsning på firmaets registreringsbehov.

2) RC System FLEX managementværktøj.

R_C_ _S_Y_S_T_E_M_ _F_L_E_X_ _S_O_M_ _L_Ø_S_N_I_N_G_ _P_Å_ _F_I_R_M_A_E_T_S_ _R_E_G_I_S_T_R_E_R_I_N_G_S_B_E_H_O_V_._

Tegningen på den foregående side viser i sammenfattet form firma-
ets registreringsmæssige opgaver.

S_a_l_g_s_f_u_n_k_t_i_o_n_._

K_u_n_d_e_o_r_d_r_e_b_e_h_a_n_d_l_i_n_g_._

Alle kundeordrer kan registreres i systemet. Ved registreringen
er der kontrol af leveringsevnen for den ønskede vare og af
kundens betalingssituation (forfalden saldo, kreditgrænse,
overskredet). Hvis systemet reagerer på styrekontrollen, kan
ordren stoppes, og en ansvarlig leder kan vurdere, om den på-
gældende ordre skal ændres eller om andre ordrer eller planer
skal ændres. Til brug for disse vurderinger kan systemet på
dataskærmen vise terminsopdelte leveringsplaner for kunder og
varer, således at man kan finde frem til de kunder, varer og
ordrer, det kunne blive aktuelt at ændre.

Når salgsordren er registreret, kan den kaldes frem på skærmen,
og den kan udskrives på en formular til brug for ordrebekræfti-
gelse og ekspedition.
\f

Ved dagens slutning udskrives en "ordrebevægelsesliste" og
"varers anmærkninger", hvor de ordrer og varer, der har fået
signaler ved styrekontrollen er særligt markeret.

Ordreformularerne er typisk:

- ordrebekræftigelse til kunden
- følgeseddel til kunden
- forsendelsesseddel til lager

Udover almindelige on-line forespørglser om kunder, leverandører
og ordrer, er der muligheden for at foretage forespørgsler på et
antal sammenhængende informationer, som gør det muligt for
ordreadministrationen at give øjeblikkelig svar på spørgsmål fra
kunder og spørgsmål om alternative leveringsbetingelser o.s.v.

Disse forespørgsler er:

1) L_e_v_e_r_i_n_g_s_p_l_a_n_,_ _k_u_n_d_e_
- hvilken ordrer har kunden,
hvornår er ordren blevet le-
veret, og hvilken produkter
skal leveres?

2) L_e_v_e_r_i_n_g_s_p_l_a_n_,_ _p_r_o_d_u_k_t_e_r_
- hvilke ordrer, til hvilke
kunder, hvor skal de leveres?

F_a_k_t_u_r_e_r_i_n_g_.

Input til fakturamodulet er ekspiditionspapirer fra lageret
korrigeret for faktiske leveringer m.v.

På baggrund af behandlede ekspiditionspapirerne kaldes ordrerne
frem til fakturering \f

P_r_o_d_u_k_t_i_o_n_s_-_ _o_g_ _l_a_g_e_r_s_t_y_r_i_n_g_.

Datagrundlaget for produktions- og lagerstyringsmodulet hentes
fra

Produktionsplaner
produktionsordrer
Lagertilgange

P_r_o_d_u_k_t_i_o_n_s_p_l_a_n_e_r_.

Den overordnede produktionsplanlægning foretages udenfor
RC-system FLEX og resulterer i en række produktionsplaner.

Produktionsplanerne retistreres i systemet til vurdering af
fremtidig leveringsevne. Produktionsordrer genereres ikke
automatisk og der foretages ingen automatisk reservation af
råmaterialer. Men produktionsplaner kan nedbrydes til standard
råmaterialemængder.

P_r_o_d_u_k_t_i_o_n_s_o_r_d_r_e_.

Når varerne sættes i produktion, registreres en produktionsordre
i systemet. Herefter genereres et produktionsordredokument
systemet.

Hvis der referes til en produktionsplan, bliver planen
tilsvarende reduceret.

Registreringen reserverer automatisk råmaterialer og
halvfabrikata ifølge standardoplysninger.

L_a_g_e_r_t_i_l_g_a_n_g_. \f

Når en produktion er afsluttet returneres ordredokumentet med
relevante lagertilgange til registrering i systemet.

Reservationer af råmaterialer annuleres og lagerbeholdning
reduceres tilsvarende.

Hvis lagertilgange ikke stemmer overens med antallet der er
bestilt forbliver resten som en restordre med mindre andet ønskes

Både produktionsplaner og ordrer kan udelades. Hvis et firma
vælger ikke at registrere produktionsordrer, f.eks. fordi
produktionens udførelsestid kun er nogle på timer, kan
lagertilgange henvises til en produktionsplan, som så vil blive
reduceret tilsvarende.

SHI System for handels- og industrivirksomheder

RC = HIS (Handels- og industrisystem)

N_F_ _A_p_p_l_i_c_a_t_i_o_n_._

Indhold:

1) Kort om A/S xxxxxxxx

2) Applikationen som løsning på firmaets registrerings-
behov.

3) Applikationen som ledelsesværltøj.
\f

4) Andre applikationelle muligheder udenfor NF-syste-
met.

afvigelse på grund af ændret gennemsnitlig salgspris
(salgsprisændringer eller mixændringer)

afvigelse på grund af ændret gennemsnitlig dækningsgrad
(kostprisændringer eller mixændringer)

K_u_n_d_e_g_r_u_p_p_e_/_v_a_r_e_g_r_u_p_p_e_s_t_a_t_i_s_t_i_k_ - udskrives almindeligvis pr.
måned. indeholder pr kundegruppe salget fordelt på varegrupper
med følgende oplysninger: stk-salg, omsætning, dækningsbidrag,
månedens tal og år til dato, månedens budget og budget år til
dato. Denne salgsstatistik skal også indgå i x månedsrapport-
ering.

De foran nævnte salgsstatistikker er komprimerede informationer
til brug for selskabets ledelse og til brug for koncernledelsen.

Som standard statistik findes desuden:

V_a_r_e_s_a_l_g_s_s_t_a_t_i_s_t_i_k_ - udskrives almindeligvis pr. måned.
Indeholder pr. varenr.: stk,salg, omsætning og dækningsbidrag for
måneden og år til dato.

Ud over de her nævnte standard statistikker er det muligt
at få udskrevet en række kunde/vare- og vare/kundestatistikker.

Yderligere salgsanalyser på gruppeniveau kan udskrives efter
behov.

Hvilke statistikker man ønsker, bør planlægges over en længere
periode, da det ikke er praktisk at ændre det i løbet af
perioden. \f

P_r_o_d_u_k_t_i_o_n_s_-_ _o_g_ _l_a_g_e_r_a_n_a_l_y_s_e_r_._

Den nødvendige opfølgning af produktionens gennemførelse og lag-
renes størrelse er baseret på en sammenligning af faktisk forbrug
og standardforbrug ifølge standard kalkulationer.

Principperne for standardomkostningskontrollen kan beskrives så-
ledes:

1. Råvarelager primo til stand.kostpris xxx
(iflg. varelagerliste/edb)

2. Varekøb til indkøbspriser + xxx
(iflg. varekøbsstatistik/edb)

3. Prisdifference på varekøb-stand.pris/indkøbspris +/- xxx
(iflg. kostprisafvigelsesliste/edb)

4. Udbetalt arbejdsløn + xxx
(iflg. lønbogholderi)

5. Prisdifference på arbejdsløn-stand.timeløn/faktisk +/- xxx
(beregnes) timeløn

6. Standardforbrug månedens produktion +/- xxx
(iflg. stk.omk. producerede varer/edb)

7. Mer/mindre forbrug materialer +/- xxx
(lagerændringer efter optælling af råvarelager/edb) \f

8. Mer/mindre forbrug arbejdsløn +/- xxx
(beregnes af punkt 4, 5 og 6)

9. Råvarelager ultimo til standard/kostpris xxx
(iflg. varelagerliste/edb) =======

Som det fremgår af henvisningerne i parantes, leverer RC System
FLEX de fleste af oplysningerne til standardomkostningskontrol

Mer/mindre forbrug af råvarer opgøres efter en fysisk
lageroptælling, da produktionens vareforbrug ikke registreres
direkte, men fratrækkes i råvarebeholdningen i edb-systemet med
det standardforbrug, der svarer til månedens produktion.

Standardomkostningskontrollen kan opdeles på råvaregrupper.

Færdigvarelagrene afstemmes således:

Færdigvarelager primo til stand.kostpris xxx
(iflg. varelagerliste/edb)

Månedens produktion til stand-omk. + xxx
(iflg. edb)

Månedens salg til stand.omk. - xxx
(iflg. edb) _ _ _ _ _

Færdigvarelager ultimo til stand.kostpris xxx
(iflg. edb) ======

De her nævnte opstillinger og statistikker kan danne grundlag for
en periodisk oversigt over produktionens økonomi.
\f

En meget vigtig del af standardomkostningskontrollen er de kalku-
lerede standardomkostninger, der ligger i systemet på hver enkelt
vare. Disse forbrugssatser og priser er budgettet for
produktionens gennemførelse, og det er disse kalkulationer, der
kontrolleres i standardomkostningskontrollen.

De foran nævnte tilpasninger er indregnet i prisaftalerne med A/S
Regnecentralen.

A_n_d_r_e_ _m_u_l_i_g_h_e_d_e_r_ _i_n_d_e_n_f_o_r_ _R_C_ _s_y_s_t_e_m_ _F_L_E_X_.

Ved udviklingen af RC system FLEX er der lagt vægt på tre
hovedformål:

1) At udvikle et standardsystem, som kan tilfredsstille behov
hos et bredt udsnit af middelstore fabrikanter som producerer
og afsætter massevarer.

b) Programmøren skal kunne være overbevist om at
modifikationer ikke giver konsekvenser andre steder i
programkomplekset.

3) At skabe en basis ramme, t_o_t_a_l_t_ _u_a_f_h_æ_n_g_i_g_ af
RC system FLEX, en struktur, som er i stand til at klare a_l_l_e_
basisbehov for et edb-system.

Det 4. formår er genstand for yderligere diskussion i dette
kapitel.

G_e_n_e_r_e_l_ _p_r_o_g_r_a_m_s_t_r_u_k_t_u_r_.

Den generelle struktur består af:

A_._ _E_t_ _s_æ_t_ _e_k_s_t_e_r_n_e_ _p_r_o_c_e_d_u_r_e_r_

Disse procedurer indeholder beskrivelse af den database, som
skal anvendes.

Strukturen er trimmet til anvendelse af RC database system.

Strukturen giver bl.a., følgende karakteristiske træk:

1) Adskillige typer programkørsler
a) Batchmode, som skal bruges ved
- reorganisering af registre
- konvertering af registre fra andre systemer
- testning af system.

Denne facilitet er værdifuld for programmøren, fordi det
uden xxxx giver ham en xxxxx copy af programforløbet, men
også en detaljeret forklaring på fremgangsmåderne.

b) On line mode

c) Speciel mode til reetablering efter afbrydelse

d) Speciel mode til at afbryde kontering

2) Et detaljeret sæt sikkerhedsprocedurer f.eks.:
- back-up til i tilfælde af systemsvigt \f

«eof»

DataMuseum.dk

CP/M

⟦8d3507e93⟧ TextFile

Derivation

TextFile