Newsgroup: it.comp.retrocomputing
Titolo: Fate un SET TIME ai vostri VAX con VMS!

Se avete dei VAX con VMS fermati o riavviati l'ultima volta nel 2010,
ricordatevi di eseguire entro oggi (11 aprile) il comando SET TIME. :-)
Il motivo è presto detto: l'orologio hardware dell'architettura VAX è un
contatore a 32 bit che dura circa 466 giorni e conta il numero di intervalli
da 10 millesimi di secondo trascorsi a partire dall'inizio di un dato anno,
memorizzato su disco dentro SYS.EXE (parte del kernel VMS). Con 466 giorni
quindi si copre l'intervallo che va dal 1° gennaio di un anno all'11 aprile
dell'anno successivo (sempre che non siano coinvolti anni bisestili).
Il comando SET TIME senza parametri semplicemente aggiorna l'anno di
riferimento in SYS.EXE e reimposta di conseguenza il contatore. 
Finché la macchina è in funzione non ci sono problemi, dato che l'orologio
software è a 63 bit e arriverà fino al 31 luglio 31086 (!), ma se il sistema
dovesse fermarsi senza fare uno shutdown corretto, si presenterebbe un
problema: infatti durante il riavvio successivo VMS calcolerebbe l'orario
corrente basandosi sul contatore ripartito da zero per overflow e sull'anno
di riferimento sbagliato, oppure (grazie a uno meccanismo di sicurezza che
inserisce un margine di circa 31 giorni dopo l'overflow) si fermerebbe e
chiederebbe all'operatore di digitare alla console la data e l'ora corrette.
Ecco il calcolo per i più curiosi.
Il TOY clock (Time Of Year) è un contatore a 32 bit che scatta ogni 10
millesimi di secondo. Essendo a 32 bit può dunque contare da 00000000h a
FFFFFFFFh, ma viene inizializzato a 10000000h per implementare quel
meccanismo di sicurezza di cui ho scritto sopra e che descrivo più avanti.
Dunque avremo:
FFFFFFFFh - 10000000h = EFFFFFFFh possibili tick da 10 ms.
EFFFFFFFh = 4.026.531.839 possibili tick in numerazione decimale.
24 * 3600 * 100 = 8.640.000 tick al giorno.
(ho moltiplicato per 100 perché 10 millesimi sono 1 centesimo.)
365 * 8.640.000 = 3.153.600.000 tick all'anno.
4.026.531.839 - 3.153.600.000 = 872.931.839 tick rimanenti dopo un anno.
872.931.839 / 8.640.000 = 101 giorni (arrotondati) prima dell'overflow.
101 - (31 + 28 + 31) = 11 giorni in aprile prima dell'overflow. :-)
(10 giorni se l'anno corrente o il precedente sono bisestili.)
Per circa 31 giorni dopo l'overflow (o sempre quando ad esempio la batteria
tampone è scarica) il contatore ha un valore minore di 10000000h, condizione
che fa scattare automaticamente la richiesta di inserimento di data e ora
durante il boot di VMS. Per completare il quadro bisogna infine dire che
durante l'elaborazione di 
SHUTDOWN.COM
 viene sempre eseguito SET TIME. :-)
Se poi si avesse una macchina ferma da tempo, per evitare che parta con un
orario completamente sballato (con conseguente confusione nei log e amenità
simili), è sufficente fare un conversational boot e digitare SET SETTIME 1
al prompt SYSBOOT> per forzare la richiesta di data e ora.
Ciao,
G.

 ha scritto nel messaggio 
news:u4l5q6pjv6chlbpjp...@4ax.com...
Se avete dei VAX con VMS fermati o riavviati l'ultima volta nel 2010,
esiste TCPIP$NTPDATE.EXE
ho un cron_daemon che lo fa girare una volta al giorno :P
-- 
%DCL-F-RUIDIOT?
(IV3AIE) 

 ho un cron_daemon che lo fa girare una volta al giorno :P
Sai che non so se quello aggiorna anche il clock hardware? Credo di sì, ma
non ne sono affatto certo. Il cron_daemon dove l'hai trovato? Io me lo sono
scritto in DCL (ma a far bene sarebbe da riscrivere in Fortran). :P
Ti sei fatto anche la procedurina che aggiorna da sola l'UTC offset al
passaggio fra l'ora solare e quella legale (e viceversa) o sei uno di quelli
tutti d'un pezzo che tengono l'ora sempre UTC? No perché nel caso avrei
un'ideuzza su come implementarla... Sempre in DCL. :P
Ciao,
G.

  passaggio fra l'ora solare e quella legale (e viceversa)
si' l'ho fatta ma ogni tanto si inceppa :P
cia'
-- 
%DCL-F-RUIDIOT?
(IV3AIE) 

 credo l'abbia scritta un tale Kent C. Brodie nel lontano '88
Interessante. Ma ha risoluzione di un minuto come quello per Unix? Con
quello che ho fatto io ho riscontrato un certo consumo di CPU, ecco perché
dicevo che sarebbe da riscrivere in Fortran. Controllare via DCL ogni minuto
se l'equivalente di crontab è cambiato pare sia relativamente pesante:
OpenVMS V8.3  on node HOBBIT  11-APR-2011 22:50:30.72  Uptime  91 09:19:40
  Pid    Process Name    State  Pri      I/O       CPU       Page flts
00000127 CRONTAB_MANAGER LEF      6   526545   0 00:12:51.88       467
OpenVMS V7.2  on node ATHENA  11-APR-2011 22:51:15.58  Uptime  53 20:10:15
  Pid    Process Name    State  Pri      I/O       CPU       Page flts
00000055 CRONTAB_MANAGER LEF      5   232668   0 01:56:26.97       782
(Il primo è un Alpha, il secondo un VAX.)
Ciao,
G.

 OpenVMS V8.3
mi servirebbe, non e' che lo metti da qualche parte? :P
Ciao,
L.
-- 
%DCL-F-RUIDIOT?
(IV3AIE)