La fonte pubblica principale di informazioni sui dettagli implementativi relativi alla memorizzazione di oggetti nel sistema operativo IBM i resta -per quanto io sia a conoscenza- il testo di Frank Soltis intitolato FORTRESS ROCHESTER
la cui pubblicazione risale al 2001.
Nell’ottavo capitolo -dedicato agli oggetti- esistono preziose considerazioni per guidarci alla scoperta dei savefile. Non che si faccia alcuna menzione ad essi nel testo ma semplicemente perché la System Object Strutture descritta a partire dalla pagina 125 è illuminante per capire il tracciato dei savefile stessi.
Le informazioni relative ad un singolo oggetto una volta trasferito su un savefile risiedono in punti diversi. Il fatto stesso che un oggetto venga salvato introduce alcune entità intermedie che servono a legare il dump dell’oggetto al nuovo contesto in cui esso viene ad essere incastonato.
A tal fine concorre l’esistenza di un particolare oggetto avente come tipo e sottotipo i valori esadecimali X’19DB’ e che, nella documentazione pubblicata online da IBM, corrisponde al tipo *SRDS definito come Save/restore descriptor space.
In funzione della numerosità e del contenuto di informazioni relative agli oggetti coinvolti in uno specifico salvataggio, un savefile potrà attivare il dump di più oggetti *SRDS. Nella serializzazione risultante avremo quindi la sequenza dei dump degli oggetti formalmente salvati aperta ed eventualmente intervallata dai dump degli oggetti *SRDS necessari a veicolare le informazioni descrittive più generali che li riguardano.
Per correttezza dobbiamo osservare che alcuni oggetti non hanno necessità di un dump dedicato in quanto le informazioni che li riguardano rientrano completamente nel contenuto dell’oggetto *SRDS che li menziona. Il caso più classico di questa situazione è l’oggetto *LIB.
Un altro aspetto macroscopico interessante è che la lunghezza record “utile” di un savefile è di 512 byte: questi diventano 528 “effettivi” concatenando 4 byte per il numero sequenza e 12 per un particolare CRC di controllo.
Ai tempi della architettura CISC, 512 era anche la dimensione di una pagina del sistema operativo: col passaggio alla architettura RISC la pagina è diventata di 4KB ma la lunghezza record del savefile non è stata modificata.
La conseguenza è che (senza compressione) alcuni record di un savefile contengono semplicemente zeri esadecimali fino al raggiungimento dei 4KB utili.
Questa “espansione” nella occupazione di memoria -tra l’altro- era oggetto di indagini preliminari ai tempi delle migrazioni CISC-RISC perché le stime precedentemente utilizzate per dimensionare un nuovo server non erano più valide.
Riassumendo, ci muoveremo all’interno di un savefile (non compresso) spostandoci di 8 record per volta per ricostruire le pagine di memoria come 512 * 8 = 4096 byte contigui.