NUOVO FILE SYSTEM BC_ISAM IN AMBIENTE OLIBCOS
SPECIFICHE FUNZIONALI

 

Cap. 1 - INTRODUZIONE

Il file system di OLIBCOS presenta delle limitazioni dovute al fatto di essere stato concepito molti anni fa. Tali limitazioni possono essere così sintetizzate:

  1. Limite massimo della dimensione del record fissato a 256 bytes.
  2. Necessità di predefinire la dimensione dell'extent del file in fase di creazione dell'etichetta.
  3. Organizzazione dei files con chiave in cui nel file chiavi non è contenuto il link al record del file dati (non si tratta cioè di un'organizzazione indexed_sequential) e quindi si accede al file chiavi in maniera sequenziale per poi fare l'accesso nel file dati in modalità direct, sfruttando il trucco che i records del file dati e quelli del file chiavi hanno la stessa sequenza.
  4. Possibilità di definire nel file una sola chiave, con la conseguenza che gli applicativi sono costretti a ricorrere continuamente all'utility SORT per ottenere ordinamenti dei record su campi diversi dalla chiave definita in fase di creazione del file.
  5. Non riutilizzo dei "buchi" che si vengono a creare nel file per effetto della cancellazione di records.

Il file system di OLIBCOS presenta però delle caratteristiche peculiari che gli consentono di fare cose che difficilmente sono disponibili nei sistemi ben più moderni attualmente sul mercato.

Basti ricordare:

  1. La completa protezione dalla caduta di tensione.
  2. La possibilità di effettuare il restart da programma.
  3. La possibilità di ricercare con lo statement "FIND" un record specificandone le caratteristiche in piena libertà.

La presente implementazione va a risolvere le limitazioni del file system di OLIBCOS, salvaguardandone le caratteristiche positive.

Cap. 2 - OBIETTIVI DI PRODOTTO E SUE CARATTERISTICHE GENERALI.

Il nuovo file system, denominato BC_ISAM, si basa sull'implementazione del C_ISAM effettuata dalla "Byte Designs Ltd. - Canada" denominata D_ISAM, di cui la Progetto Sistemi ha acquistato una licenza d'uso che le consente di utilizzare e modificare il codice sorgente e di distribuire liberamente applicazioni che utilizzano tale codice in formato eseguibile.

L'utilizzo di tale codice è royalty_free per l'utente finale. E' necessario però che le software_houses che acquistano da noi una licenza d'uso illimitata di OLIBCOS con incluso il BC_ISAM ci tengano al corrente del numero totale di installazioni effettuate. Questo perché al superamento di 100 installazioni totali la Progetto Sistemi è tenuta ad acquistare un'estensione della licenza dalla Byte Designs.

Ricordiamo che C-ISAM è un marchio registrato della Informix Software Inc. e che D-ISAM è un marchio registrato della Byte Designs Ltd.

BC_ISAM convive con il file system tradizionale di OLIBCOS. Nel sistema viene automaticamente riconosciuto il tipo di file in fase di OPEN e viene consentito di elaborare contemporaneamente nello stesso programma files di tipo vecchio e files di tipo nuovo.

Non sono stati introdotti nuovi statements del linguaggio BASIC, ma sono solo state ampliate le funzionalità degli statements preesistenti.

Sui nuovi files è consentito:

  1. Definire chiavi composte (formate cioè da pezzi di record non contigui) con un numero di parti massimo per ciascuna chiave fissato ad 8. (Tale limite può essere eventualmente ampliato su richiesta specifica da parte del Cliente alla Progetto Sistemi S.r.l.)
  2. Definire una chiave primaria e fino a 7 ulteriori chiavi secondarie. (Tale limite può essere eventualmente ampliato su richiesta specifica da parte del Cliente alla Progetto Sistemi S.r.l.)
  3. Definire una lunghezza record a piacere compresa tra 1 e 4096 bytes.
  4. Riservare fino ad un massimo di 50 records contemporaneamente da un posto di lavoro per ogni file. (Tale limite può essere eventualmente ampliato su richiesta specifica da parte del Cliente alla Progetto Sistemi S.r.l.)
  5. Accedere ai record in maniera sequenziale, ottenendo i records per valore di chiave crescente o decrescente.
  6. Accedere ai record per valore di chiave.
  7. Accedere ai record per numero d'ordine fisico nell'ambito del file.
  8. Rileggere l'ultimo record letto.
  9. Aggiornare l'ultimo record letto.
  10. Cancellare l'ultimo record letto o quello che soddisfa il match di una particolare chiave.
  11. Aggiungere records nel file, anche in concorrenza (APPEND_APPEND), senza dovere ricorrere a particolari accorgimenti e con la garanzia che il sistema conserva sempre in ordine le chiavi aggiunte e lo fa per tutte le chiavi definite sul file.
  12. Utilizzando lo statement MCP, preservare da caduta di tensione non solo le REWRITE e le DELETE, ma anche le WRITE.
  13. Utilizzando lo statement RTR, rifasare al momento dell'ultimo MCP il contenuto dei files.
  14. Utilizzando lo statement DFIO esteso, cambiare in ogni punto del programma la chiave con la quale si intende accedere al file.

Nei capitoli seguenti vedremo come, in pratica, si utilizza il sistema.

 

Cap. 3 - Statements BASIC

Par. 3.1 - Statement OPEN

Lo statement OPEN è rimasto inalterato.

Par. 3.2 - Statement CLOSE

Lo statement CLOSE è rimasto inalterato.

Par. 3.3 - Statement READ

READ sequenziale legge il record in ordine crescente o decrescente di chiave.

READ OLD rilegge l'ultimo record letto.

READ diretta legge il record il cui numero d'ordine fisico nell'ambito del file e' stato specificato nello statement dopo la parola IND. L'utilizzo di tale modalità di READ lega il programmatore alla sequenza fisica dei record. Trattandosi di una sequenza priva di una logica riteniamo che sia di scarsa utilità pratica. Ad ogni modo l'abbiamo implementata e attendiamo di sapere dai nostri utenti che utilizzo riescono a farne. Se si cerca di leggere un record che risulta cancellato ed il cui "buco" nel file non e' stato ancora riutilizzato da nessuna WRITE, allora viene data la segnalazione di deleted record, testabile sulla variabile ERR. Questo non e' vero per le READ KEY o le READ SEQUENZIALI, per le quali un record cancellato risulta soltanto inesistente.

Read random (con l'utilizzo dell'opzione KEY) legge il record che soddisfa il match della chiave specificata nella variabile che segue la parola KEY con la chiave correntemente selezionata per il file. Nel caso in cui la chiave sia composta da più parti è necessario specificarla nella variabile che segue la parola KEY come se si trattasse di una unica parte e la variabile deve essere una variabile di tipo stringa. Ci spieghiamo meglio con un esempio:

Supponiamo che la terza chiave sia costituita da:

A$

NOMINATIVO CLIENTE

Spiazzamento 6

Lunghezza 40

C

CODICE POSTALE

Spiazzamento 100

Lunghezza 3 (Max 99999)

I

IMPORTO FATTURA

Spiazzamento 120

Lunghezza 5 (Max 999999999)

 

Per accedere ad un record con tale chiave utilizziamo il

seguente programma:

010 DCL 40A$, 5C, 9I

020 DCL 3C$, 5I$, 48K$

030 DFR 1: 6, A$, 60, C, 17, I, 50

040 OPEN :2 FLN "ANAGR" INPUT DEV "HDU"

050 CALL "DFIO" (2, 3)

060 C = 70121

070 I = 1200000

080 A$ = "INDOLFI"

090 CALL "CVNS" (C, 0, C$)

100 CALL "CVNS" (I, 0, I$)

110 K$ = A$ + C$ + I$ /* IN BASIC questo non e' consentito */

120 READ :2 REC 1 KEY K$ EOF 900 LOCK

130 IF ERR = 3....

.......

Si fa presente che ci possono essere più record caratterizzati dalla stessa chiave. La READ KEY fornisce sempre il primo di questi record. Se si vuole accedere agli eventuali record successivi aventi la stessa chiave, l'unico modo è quello di effettuare, dopo la READ KEY che ha trovato il primo record, delle READ sequenziali ed iterare finché il campo chiave non cambia.

E' possibile preparare la chiave mascherando parte dei campi di tipo stringa con il carattere esadecimale FF. In tal caso la ricerca del record darà come risultato il primo record che soddisfa la chiave non considerando i bytes mascherati.

Il mascheramento è consentito anche per i campi di tipo numerico, ma in tal caso l'intero campo numerico viene trascurato nella ricerca del record.

Par. 3.4 - Statement REWRITE.

Il file system consente la rewrite anche se il campo chiave viene modificato.

Par. 3.5 - Statement DELETE.

Lo statement DELETE è rimasto inalterato.

La cancellazione viene effettuata eliminando il record dal file chiavi e rendendo disponibile il "buco" venutosi a creare sul file dati.

Par. 3.6 - Statement FIND.

Lo statement FIND e' rimasto inalterato.

L'attuale implementazione usa un algoritmo che forse potrebbe risultare lento, dato che va ad accedere ai records in maniera sequenziale, confrontandoli ad uno ad uno con la maschera di ricerca.

Se i programmatori ci dimostreranno che l'utilizzo della funzione FIND è indispensabile e ci sono casi in cui non può essere sostituita da una READ KEY su di una opportuna chiave secondaria, provvederemo ad ottimizzare le performances della FIND.

Par. 3.7 - Statement WRITE.

Lo statement WRITE è rimasto inalterato. Evidentemente, anche se continua ad essere accettata l'opzione "EOF linenum", non si verificherà mai la condizione di riempimento del file, dato che i file BC_ISAM non hanno limiti di estensione.

A seguito di una WRITE, il record viene aggiunto nel file dati nella prima posizione disponibile (eventualmente riutilizzando i buchi venutisi a creare per effetto di DELETE precedenti), ma il file indice viene automaticamente aggiornato in modo da tenere in ordine la chiave primaria e tutte le chiavi secondarie.

Un discorso a parte va fatto sull'append concorrente di record sullo stesso file da più posti di lavoro. In ambiente BC_ISAM, se la modalità di OPEN è SHARED+UPDATE vengono accettate anche le WRITE e non solo le REWRITE, senza che ci sia bisogno di lanciare la CALL "DFIO" (file_designator, "C"). Il file non deve essere prefillato ed i record aggiunti sono immediatamente visibili agli altri posti di lavoro, senza che si debba fare ricorso alle REOD/WEOD.

Dato che quando si aggiungono i record non viene aggiornata l'etichetta del file in traccia zero, ma tale informazione risiede sul file ed e' aggiornata in tempo reale ad ogni WRITE, anche le WRITE e non solo le DELETE e le REWRITE vengono protette in ambiente MCP. Questo significa che in caso di RESTART i record aggiunti a partire dall'ultimo MCP vengono cancellati.

Il sistema accetta la scrittura di record che comporti duplicazioni della chiave primaria e/o delle eventuali chiavi secondarie.

Si fa presente che in ambiente BC_ISAM non esiste il concetto di quanti record entrano in un settore e di quanto "sfrido" viene lasciato nel settore se la lunghezza record non e' un sottomultiplo di 256. Queste sono cose dell'antichità che non è il caso di continuare ad emulare.

Par. 3.8 - Statement DFIO.

La modalità' ABILITA APPEND_APPEND è una no_operation su files BC_ISAM.

Viene introdotta la modalità' SELEZIONA CHIAVE, avente la seguente

sintassi:

CALL "DFIO" (file_designator, key_number)

dove key_number è una costante o una variabile numerica, indicante il numero d'ordine della chiave che si vuole selezionare per le successive operazioni di I/O. Tale parametro avrà valore 1 per selezionare la chiave primaria (si ricorda che la chiave primaria viene selezionata automaticamente al momento della OPEN del file), avrà valore 2 per selezionare la prima chiave secondaria creata sul file, ecc. Se si intende accedere al file con le read sequenziali in ordine inverso di chiave (ad esempio partire dalla Z per arrivare alla A) bisogna sommare a key_number il valore 128; ad esempio per selezionare la chiave primaria in ordine discendente key_number deve valere 129. Viene emesso un errore BASIC se si cerca di selezionare una chiave non esistente sul file. A seguito della DFIO viene effettuato un riposizionamento del record corrente sul primo (ultimo in caso di chiave discendente) record del file in ordine logico di chiave.

Par. 3.9 - Statement NREC.

Lo statement NREC restituisce il numero d'ordine fisico dell'ultimo record trattato. Subito dopo la OPEN restituisce il numero totale di records presenti sul file, ma, attenzione, in questo caso il numero è logico, cioè vengono conteggiati solo i records veri e non i buchi eventualmente non ancora riutilizzati.

Par. 3.10 - Statement ROOM

Lo statement ROOM su file BC_ISAM risponde sempre che c'è spazio sul file per altri 999 records.

Par 3.11 - Statement LOCK

La LOCK multipla di records è no_operation sui files BC_ISAM.

Su questa nostra decisione attendiamo eventuali osservazioni e proteste dagli utilizzatori. Al momento attuale, i records vengono bloccati sulle READ e sulle FIND se e' specificata l'opzione LOCK o se è attivo l'MCP e sempre sulla DELETE KEY.

Si fa presente che sui file BC_ISAM viene sempre privatizzato il singolo record e non l'intero settore che lo contiene.

Par. 3.12 - Statement UNLOCK

UNLOCK senza parametri rilascia tutti i records privatizzati dal programma. UNLOCK con specifica del file_designator rilascia l'ultimo record privatizzato del file. In entrambi i casi il rilascio non viene effettuato se MCP attivo.

Par. 3.13 - Statements MCP/RTR

La sintassi degli statements MCP/RTR è rimasta inalterata.

L'esecuzione dello statement MCP ha la funzione di aprire una transazione, che si definisce come un insieme di modifiche al file system che si vuole che vengano effettuate tutte, oppure che non ne deve essere effettuata nessuna.

La transazione viene chiusa e convalidata all'esecuzione del successivo statement MCP, nel quale vengono consolidati tutti gli aggiornamenti effettuati e viene dato lo start alla transazione successiva. Altrimenti lo statement RTR (restart da programma) rifasa il contenuto di tutti i files al momento dell'ultimo MCP.

Per gli utenti BCOS non c'è nulla di originale in tutto ciò, perché avevano a disposizione una prestazione così potente già più di dieci anni orsono, ma vi assicuriamo che il transaction processing è stato introdotto in C_ISAM solo alla Rel. 3.0 e che pochi sistemi in giro fanno cose di questo tipo.

Per non parlare del fatto che il restart può essere effettuato anche a fronte di una caduta di sistema, garantendo sempre l'integrità degli archivi riportando indietro i fotogrammi sino al momento dell'ultimo MCP. Questa è una prestazione che non e' fornita veramente da nessuno (neanche dal C_ISAM) e noi non saremmo riusciti a metterla ancora a disposizione sul nuovo file system se non avessimo avuto il codice sorgente del D_ISAM in modo da aggiungervi delle nostre estensioni proprietary.

Ricordiamo che l'MCP determina il blocco automatico dei record e che i record vengono sbloccati solamente al momento dell'esecuzione dell'MCP successivo: dato che c'è il limite di max 50 per ogni file records bloccati per pdl (in caso di superamento di tale limite viene emesso "SYS ERR 564 isam" abortivo) costituisce una buona regola di programmazione non fare un MCP all'inizio del programma e poi niente più. Si consiglia di posizionare gli MCP in modo da delimitare una serie di operazioni sui files logicamente dipendenti una dall'altra, quella che abbiamo definito essere una "transazione".

I contenuti "before image" dei records cancellati o riscritti dei files tradizionali vengono salvati come sempre sul DRSFLE, insieme all'area variabili ed ai dati di sistema relativi al posto di lavoro. Le operazioni da proteggere che riguardano i files BC_ISAM, che sono non solo REWRITE e DELETE, ma tutte quelle operazioni che fanno cambiare lo stato del file (write, lock /unlock di record, cambio di chiave di riferimento, ecc.) vengono protette su di un file, unico per tutto il sistema, che si chiama il log_file. Tale file per sua natura tenderebbe a crescere a dismisura. OLIBCOS provvede perciò a troncarlo a 0 bytes di lunghezza, quando in fase di inizializzazione del primo posto di lavoro verifica che non ci sono MCP pendenti.

Cap. 4 - Statements OCL

Al file BC_ISAM si accede con i tradizionali statements OCL:

YCS 02 - Ricerca un file

Nella variabile di output LYKYD si trova il valore "999". Tale valore è caratteristico del file BC_ISAM.

YCS 03 - Scratch file dati.

YCS 07 - Prenota file.

YCS 09 - Rilascia file.

YCS 10 - Rename file.

Gli ultimi quattro statements elencati si comportano in modo identico sia su files nuovi che su files vecchi.

Cap. 5 - Localizzazione dei files BC_ISAM.

E' necessario che i files BC_ISAM siano localizzati su data set che non contengano anche files normali o librerie. Questo perché tali data set devono avere la caratteristica di non essere limitati in estensione. L'etichetta del file BC_ISAM risiede normalmente sulla traccia 0 simulata (files 000trk e 000sin) del data set. Essa è in tutto identica a quella di un file sequenziale BCOS, per il quale tutti i dati dell'etichetta (BOE, EOE, EOD, EOS, LCF, lunghezza record, ecc.) non sono significativi, mentre e' significativo il campo che inizia ad offset 112 ed e' lungo 6 (quello che normalmente contiene il nome del flusso indice associato) che deve contenere la stringa "ISidx". Nella directory Hnn corrispondente al data set HDnn si trovano due files aventi come prefisso il nome del file e come suffisso rispettivamente ".dat" per il file dati e ".idx" per il file indice.

Cap. 6 - Comandi per la gestione dei files BC_ISAM.

Abbiamo sviluppato dei comandi unix che consentono all'utente di manipolare i files BC_ISAM. Tali comandi possono essere lanciati dallo shell dopo avere effettuato il login come user root.

Par. 6.1 - bcbuild - Creare file BC_ISAM.

Creare l'etichetta con FLELAB. Scegliere file sequenziale, numero di records 1.

Lanciare sotto Unix il comando bcbuild, che ha la seguente sintassi:

Usage: bcbuild dataset filename reclen keytype_1 keydis_1

keysize_1

[keytype_2 keydis_2

keysize_2 ...

keytype_n keydis_n

keysize_n]

Ad esempio, se si vuole creare un file con le caratteristiche dell'esempio fornito per spiegare l'uso della chiave composta sulle READ KEY, i parametri di bcbuild sono:

bcbuild HD9 ANAGR 256 A 6 40 N 100 3 N 120 5

keytype vale "A" per chiave di tipo stringa e "N" per chiave di tipo numerico. Attenzione che bcbuild crea solo la chiave primaria. Per aggiungere ulteriori chiavi usare bcaddi.

Par. 6.2 - bcaddi - Aggiungere chiave secondaria

Lanciare sotto Unix il comando bcaddi, che ha la seguente sintassi:

Usage: bcaddi dataset filename keytype_1 keydis_1 keysize_1

[keytype_2 keydis_2 keysize_2 ...

keytype_n keydis_n keysize_n]

Par. 6.3 - bcdeli - Eliminare chiave secondaria.

Lanciare sotto Unix il comando bcdeli, che ha la seguente sintassi:

Usage: bcdeli dataset filename keynumber

Dove keynumber e' un numero maggiore di 1, dato che non è consentito eliminare la chiave primaria.

Par. 6.4 - Cancellare file BC_ISAM.

Cancellare l'etichetta con DELLAB o DELFIL.

Lanciare sotto Unix il comando

rm -i /bcos/U1/Hxx/filename.idx /bcos/U1/Hxx/filename.dat

Prossimamente il comando verrà lanciato automaticamente dalla DELFIL.

Par. 6.5 - Trasformare file vecchio in file nuovo.

Dopo avere creato il file nuovo come descritto, lanciare un banale programma basic che legge i records dal file vecchio e li scrive sul file nuovo, eventualmente con DFR differenti.

Par. 6.6 - dcheck - Index Integrity Checker

Vi forniamo anche il programma dcheck che consente di: conoscere la configurazione del file, controllare l'integrità del file, riparare un indice guasto, ricostruire un indice a partire dai dati, visualizzare il contenuto di un indice.

Se dcheck viene eseguita senza parametri, essa visualizza il proprio "usage statement":

USAGE: dcheck [-ilnyqbhxo] isamfile

In altre parole, per eseguire dcheck bisogna chiamare il programma, il primo parametro (opzionale) e' un trattino "-" seguito da una o più delle lettere elencate, e il secondo parametro e' il path name completo del file da controllare.

I parametri funzionano nel seguente modo:

-i - (index)
Controlla solo l'indice SENZA entrare nel merito del file dati.
-l - (list)
Visualizza anche sullo standard output il contenuto dell'indice.
-n - (no)
Non cercare di ricostruire l'indice.
-y - (yes)
Se l'indice non è perfetto, cerca di ricostruirlo.
-q - (quiet)
Non visualizzare se proprio non è necessario.
-b - (build)
Ricostruisci l'indice dal contenuto del file dati, anche se l'indice è buono.
-h - (header)
Visualizza soltanto la struttura del file, senza controllarlo. Questa opzione non richiede l'accesso esclusivo al file.
-x - (hex list)
Come -l, ma l'output del contenuto di ciascuna chiave è visualizzato in hex/ascii (i caratteri stampabili sono visualizzati così come sono, quelli non stampabili in esadecimale)
-o - (order)
Visualizza una lista di numeri che fanno riferimento la numero del record in ordine di chiave. Può essere usato insieme all'opzione -q per creare un filtro per una visualizzazione veloce.
NOTA:

Se dcheck incontra un errore, oppure se è stata specificata l'opzione -b, quello che dcheck fà è cancellare tutti gli indici e poi ricostruirli a partire dal file dati. I dati non vengono mai distrutti dalla riparazione.

Cap. 7 - Utilities per la gestione dei files BC_ISAM.

Insieme con il pacchetto di upgrade BC_ISAM viene fornita la libreria UTISAM contenente programmi di utilità, che consentono di effettuare le operazioni fondamentali di manipolazione dei files in un modo più semplice e sicuro di quello descritto nel capitolo precedente.

Al momento attuale le utilities implementate sono le seguenti:

  1. ISCREA - Crea un file BC_ISAM.
  2. ISADDI - Aggiunge una chiave secondaria.
  3. ISDELI - Elimina una chiave secondaria.
  4. ISCOPY - Copia un file BC_ISAM su di un altro. Se il file di output non esiste lo crea. Non funziona su fdu.

Le seguenti utilities tradizionali funzionano anche su files BC_ISAM:

  1. FILEPT.
  2. DUMPDS.

Sono da implementare le modifiche a:

  1. RENAME
  2. DELFIL
  3. DELLAB.

 

counters