Partiamo dal caso più semplice in assoluto: il salvataggio di una libreria vuota.
CRTLIB LIB(EMPTY)
È stata creata la libreria EMPTY.
CRTSAVF FILE(EMPTY)
File EMPTY creato nella libreria QGPL.
SAVLIB LIB(EMPTY) DEV(*SAVF) SAVF(EMPTY)
1 oggetti salvati dalla libreria EMPTY.
Una volta trasferito la dimensione risultante del savefile è 16896 byte.
Come detto in precedenza la lunghezza record di un savefile è 528.
Una prima conferma sulla correttezza delle nostre ipotesi è che 528 * 32 = 16896.
Verifichiamo anche che 8 * 4 = 32: il nostro savefile è di fatto il backup di sole 4 pagine di memoria.
La prima di queste quattro pagine contiene una intestazione che impiega una porzione risibile dei 4KB utilizzati. Stiamo parlando dei soli primi 64 byte (64 su 4096… meno dell’1.6%):
a6 d7 2f 42 b7 82 70 00 00 00 00 20 30 00 30 00
f4 f1 c7 40 f9 f0 f0 f9 40 40 40 40 40 40 40 40
40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
00 00 46 00 00 00 10 00 00 00 00 00 00 00 00 20 Nel prosieguo indicheremo il primo byte con 1 e gli altri di conseguenza.
I byte dal 17 al 48 sono in EBCDIC e descrivono il tipo macchina e il modello su cui è stato effettuato il backup: nel caso mostrato vale 41G 9009 seguito da 24 blank (0x40).
I byte da 1 a 16 e da 49 a 64 sono composti di unsigned (big endian) di dimensioni diverse; rispettivamente:
- (8, 4, 2, 2) e
- (2, 2, 4, 8).
Faremo dunque riferimento a 9 campi:
- da 1 a 8
- da 9 a 12
- da 13 a 14
- da 15 a 16
- da 17 a 48: tipo macchina e modello
- da 49 a 50
- da 51 a 52
- da 53 a 56
- da 57a 64
Con un poco di osservazioni su svariati savefile si verifica facilmente che 0x00000020 (byte 9-12) della prima riga e 0x0000000000000020 della quarta (byte 57-64) altro non sono che la lunghezza del savefile espressa in numero di record. Infatti 0x20 = 32 corrisponde a 16896/528 come rilevato in precedenza.
Generando nuovi savefile i primi 8 byte sono sempre diversi ma crescenti e sono grosso modo sincronizzati tra macchine diverse… sono infatti un timestamp nel formato interno di sistema. Tale formato è documentato come *DTS nelle Usage Notes della API QWCCVTDT.
Il campo 53-56 sembra specificare la dimensione in byte di una pagina di memoria: 0x00001000 = 4096 (ai tempi della architettura CISC il valore era infatti 0x00000200).
- 1-8 timestamp nel formato *DTS (uint64_t)
- 9-12 lunghezza savefile in numero record (uint32_t)
- 13-14
- 15-16
- 17-48 tipo macchina e modello
- 49-50
- 51-52
- 53-56 dimensione pagina di memoria in byte (uint32_t)
- 57-64 lunghezza savefile in numero record (uint64_t)
I campi rimanenti hanno a che fare con la versione del formato savefile utilizzata e con la versione del sistema operativo abilitato al ripristino.
Per ora tuttavia ignoreremo i qualificatori per i formati del savefile (non cambiano dai tempi della introduzione RISC: X’3000′) e ci limitiamo ad una piccola precisazione circa il valore registrato nei byte 51-52.
Se salvassimo con valori diversi per l’opzione TGTRLS:
- TGTRLS(V7R2M0)
- TGTRLS(V7R3M0)
- TGTRLS(V7R4M0)
otterremmo rispettivamente i valori X’4400′, X’4500′ e X’4600′.
In punti successivi nel savefile troveremo le sequenze X’46004400′, X’46004500′ e X’46004600′ rispettivamente. E’ il secondo di tali valori che -ove non rispettato- fa generare al sistema l’errore CPF3743.
Tale campo specifica a partire da quale versione sia possibile effettuare il ripristino o la visualizzazione del savefile.
Se un savefile è stato generato su un sistema a versione V7R4M0 senza specificare un diverso target release (TGTRLS) non sarà possibile effettuarne il ripristino in un sistema a V7R3M0 o V7R2M0 (come tristemente noto agli utenti principianti!).