Documentazione velocizzazione calendario veloce

La lettura del calendario VELOCE (memorizzato in CALGIO0F) risulta alquanto lenta, in quanto le schiere di 999 elementi vengono, ogni volta, passate al chiamante, poiché risiedono sia nel programma che le calcola (B£DIR9) sia in quello che le utilizza lanciando la £LC8.

La /copy £LC8 dovrebbe essere oramai una funzione privata della £G79, ma vi sono parecchi programmi che la chiamano direttamente, precedenti alla realizzazione della £G79, per cui una ristrutturazione generale risulterebbe delicata, in quanto si sarebbe dovuto intervenire in tutti questi chiamanti.

La struttura dei richiami è la seguente:

La £G79 lancia B£G79G che decide se chiamare la £LC8 in modalità veloce o normale in base alle date di calcolo.
A sua volta la £LC8 lancia, in base al metodo:
- B£DIR9 (veloce)
- B£DIR8 (normale)

Revisione TST

Come prima cosa abbiamo analizzato la routine £LC8. Ha la funzione CAL, valore assunto in quanto B£DIR8 e B£DIR9 non la testano. Anche il metodo MEM non è testato in questi programmi.
Inoltre in TSTLC8 c'è la funzione VIS, che in realtà è una funzione interna del TST che mostra il risultato del calcolo con un £G08.
È stata qundi fatta pulizia in TSTLC8.
- È stata mantenuta la sola funzione CAL, perché molti programmi la riempiono, anche se inutilmente.
- È stato tolto il metodo MEM, dato che nessun programma lo riempie.
- È stato inserito un flag di I/O per presentare l'output, che ha lo stesso effetto della funzione VIS.

NB: nella funzione VELOCE viene ritornato tutto il calendario (da oggi - 6 mesi a oggi + 18 mesi) indipendentemente dagli estremi richiesti, e quindi nella visualizzazione lo si vede tutto.

Descrizione implemento

È stata poi realizzata la velocizzazione del calendario veloce, facendo risiedere le schiere nel programma che le utilizza e non in quello che le costruisce, evitando il passaggio di dati.
Purtroppo, come già detto, non è stato possibile generalizzare questo comportamento, in quanto i dati memorizzati su CALGIO0F differiscono nei due casi: quando sono locali e quando risiedono nel chiamante.
Abbiamo quindi ritenuto più opportuno una modifica locale, per permettere alla £G79 di usufruire della velocizzazione, lasciando la £LC8 allo stato attuale di velocità.
In tal modo si sono ottenuti notevoli benefici: Il miglioramento (alternando la risorsa su cui viene eseguito il calcolo, per evitare l'ottimizzazioine), è indipendente dal numero di chiamate, e si aggira attorno all'80%..

In CALGIO0F (file usato in pochissimi programmi) , dopo tipo e codice risorsa è stato aggiunto un flag (che completa la chiave) che vale:
'V' - se memorizzazione da B£DIR9
'T' - se memorizzazione dal B£G79

Il B£DIR9 originale è stato modificato in modo che consideri il flag 'V'.
È stato realizzato un nuovo programma, B£DIR10, sulla falsariga di B£DIR9, che considera il flag 'T' e assume che le schiere siano possedute da chi lo chiama.

È stato aggiunto il metodo privato TURBO a £LC8, con cui lancia il B£DIR10.
È stato modificato B£G79G per far sì che sia lui il possessore delle schiere, oltre a essere l'unico programma che lancia la £LC8 con il metodo TURBO.

In questo modo sono presenti due strade parallele:
- £LC8 - > VELOCE -> B£DIR9 (percorso vecchio, inalterato)
- £G79 (B£G79G) -> TURBO - B£DIR10 (percorso nuovo velocizzato)

Modifica a gestione manulale calendario memorizzato (B£DIR9A)

È stato inoltre modificato B£DIR9A (attenzione: non è una replica di B£DIR9), la guida per aggiornare manualmente i dati di CALGIO0F.
Sono presentate le ultime date di aggiornamento del metodo VELOCE (quello precedente) e di quello TURBO (il nuovo), in quanto potrebbero essere state calcolate in giorni diversi, il base all'ultima data di esecuzione rispettivamente della £LC8 e della £G79.
Tuttavia, quando in questo programma si chiede il ricalcolo, vengono eseguiti entrambi i metodi.
Analogamente la cancellazione viene eseguita per entrambi i calendari.