Som helhet fungerade målprogrammet bra. Men det finns fortfarande saker att göra för att adminstrationen av tävlingen ska bli snabbare och säkrare. Annars var det tekniska problem som dominerade. Regnväder och +10 grader är heller inte gynnsamt för datorer och folk. Men det kunde varit värre.
Vad som hände och varför.
1. Det började redan på morgonen med att vi inte fick igång nätverket på en dator. Det var minsta Toshiban som inte hittade huvuddatorn. Denna dator kördes annars med exakt samma utrustning på långfredagens tester. Detta problem medförd att vi fick köra på bara två datorer som båda stod i tältet. Dessutom fick skrivaren också stå i det fuktiga tältet. Otroligt nog skrev den ändå snällt ut hela tiden. Inte en enda papperskrach fast pappret närmade sig pappersmasse-stadiet.
2. Sju (7 !) kontroller slutade fungera under tävlingens gång. Detta belastade klagomuren (Marie) som dock skötte sin uppgift med glans. Efter en två-tre felstämplingar med koll av backuplappar plockades koderna bort från bantabellen i access-databasen och därefter blev det inga mer felstämplingar pga just den kontrollen på den banan. Tre banor drabbades av två utslagna kontroller och 10 banor hade en kontroll utslagen. Nio banor drabbades inte alls.
3. Starten ska en eloge för att så gott som ALLA löpare hade backuplapp. Däremot brast det i rapportering av bricknr på de som var sena. Men det gör inte så mycket eftersom vi lade in fejkade bricknr. Det viktiga är att löparna INTE identifieras automatiskt till en annan person. Om en löpare har ett bricknr som inte stämmer så kommer en dialog upp i målprogrammet och man får chansen att mata in korrekt deltagarnr.
4. Likaså ska sektretariatet också ha en eloge att öppna klasser hann registreras innna målgång.
5. Gunnars lastbalansering av löpares målgång fungerade utmärkt. En jämn ström av löpare kom i mål och inga särskilda toppar kunde märkas. Likaså var Stefans idé om att paginera backuplapparna mycket bra. Det gav frihet åt lapphanterandet efter målgång.
6. Ett problem var de felidentifierade. Följande fel fanns i systemet:
"För tidig start " 12 st
"För sen " 4 st
"Sprungit fel bana" 5 st
Alla dessa fel KAN ge upphov till felidentifieringar. Nu gjorde inte alla det men det var lite för många för att hinna rätta till omgående. Speciellt som det saknades en dator att arbeta vid och de trasiga kontrollerna tog en del kapacitet.
"För tidig start" är ändrat till "För tidig nollning" vilket det i själva verket är. När personen startade får man inte veta från elektroniken.
Ovanstående problem fördröjde publiceringen av resultaten med ca 1.5 tim. Nu kom de ut 15.10 i stället för annars ca 13.40. Även 15.10 fanns det saker som inte var helt klarlagda.
Lösningen på detta är att förse fler löpare med bricknr i registren. En riskgrupp som man lätt kommmer åt och kan ge bricknr är de öppna klasserna. Dessa anmäler sig på tävlingsdagen och kan få sin bricka i samband med anmälan. Här är man tämligen säker på att de kommer att använda brickan. Löpare i öppna klasser är ofta orutinerade och tar oftare fel karta mm.
Likaså bör man knappa in de löpare som har egna brickor. Det var allt meningen denna gång också men hanns inte med pga av annat strul.
NY RUTIN FÖR FELIDENTIFIERADE: När det kommer en felidentifierad löpare skall man ta dennes backuplapp och skriva på bricknr:et på lappen och sedan föra in på bricknr:et på deltagaren i access. Därefter läser man in brickan igen. Nu blir det en omidentifiering eftersom den får träff på bricknr:et. När man läser om en bricka tas först ALLA uppgifter bort från den först identifierad deltagaren och därefter sker en omidentiering.
Om denna rutin använts hade man lätt kunnat hinna med de felidentifierade.
Styrkan i programmet är att bricknr INTE är nödvändigt men det är bra om det är med. Om bricknr är angivet är det ej heller nödvändigt att en löpare springer med rätt bricka men det är förvisso önskvärt. Om man springer med fel bricka får man en dialogruta på inläsningsdatorn i målet vilket fördröjer inläsningen.
7. Regeln att inga löpare skulle planeras in att starta på samma minut med samma bana levdes upp till. Gunnar skötte detta mycket bra. Men man får tänka på att INTE använda OAS-programmets automatiska tilldelning av starttider åt efteranmälda löpare utan man måste planera även dessa starttider.
8. I html-listan över sträcktider finns följande fel:
a) Skumma tidsangivelser vid för tidig nollning.
b) Om det är många felst på enstaka löpare kommer starttiden fel, se tex D16.
c) Gunnar J i H60 startade en timma för tidigt, felbehandlad.
9. Resultatutskrifterna för tavlan kom bara ut med första sidan i tex H21L. Sidan 2 osv borde också ha kommit ut etfer det att det blev en ändring på de 10 främsta.
Statistik över de senaste Vikingaträffarna:
antal-anm Ord-anm efteranm öppna Felst Utg Ej-start
970331 Blåsigt ca +8 1400 73 66 125
980413 10-30 cm snö Inställt 1300
990405 Blåsigt +5 Elit 1225 ca990 ca100 ca140 58 9 132
000424 Regn +10 lungt 967 787 79 103 10 34 118
Under rubriken öppna klasser är även inskolning med och talet visar antalet som anmälde sig på tävlingsdagen.
Det kan vara någon skillnad mellan definitionen av "Felst" och "Utgått" på tävlingarna. För 1999 och 2000 har programmet räknat som "Felst" en löpare som saknar högst en kod och resten icke-godkända som "Utgått".
Mycket anmärkningsvärt är de låga talen för fel+utg för årets tävling, totalt 44. Fantastiskt med tanke på vädret och den tuffa terrängen.
Per Ivarsson datansvarig
PS Med anledning av de utslagna kontrollerna har databasen och PIT ändrats så att man under tävlingen kan ange utslagna kontroller i databasen. Man får då en korrekt resulatatutskrift som hanterar löpare som både har och inte har en stämpel från den utslagna enheten. Man behöver inte ens starta om PIT för att tillgodogöra sig de nyinlgda utslagna kontrollerna. Givetvis måsta man läsa in brickorna igen på de som rapporterats som felstämplade när det i själva verket är fråga om en utslagen kontroll.
DS