Newsgroup: it.comp.retrocomputing
Titolo: Esperimenti con DBMS-10

Ciao a tutti,
probabilmente interesserŕ a pochi, e forse ancora meno saranno quelli che
leggeranno questo resoconto — visto il periodo in cui sto scrivendo — ma ho
deciso di scrivere ugualmente, per il gusto di farlo.
Varie sere fa sono riuscito a installare e provare DBMS-10, mitico gestore
Digital per database reticolari, all'epoca uno dei piů noti e fedeli alle
specifiche CODASYL sull'argomento. Ovviamente, dato il nome, si tratta di un
prodotto per TOPS-10, il sistema operativo Digital per sistemi DECsystem-10,
cioč macchine di classe mainframe della famiglia PDP-10 (casomai non si
fosse capito, con tutti questi 10). Altrettanto ovviamente in emulazione.
Mi riferisco alla versione 5A, edit 422, i cui file sono datati fra marzo
1976 e gennaio 1980, apparentemente l'ultima release disponibile per
TOPS-10, che ho faticosamente portato all'edit 612 applicando a mano una
quarantina di fix, il piů recente dei quali risale al settembre 1983 (!).
Finita tutta la preparazione, copiati i binari eseguibili in SYS:, i binari
rilocabili in REL: e i testi di aiuto in HLP:, ho creato (copiato) dentro un
file con estensione DDL (Data Definition Language) il testo sorgente della
definizione di un database di esempio — trovato nell'immagine di un nastro —
e con l'utility SCHEMA ho creato il database e tutti i file connessi.
Il file DTORD.DDL che ho utilizzato č cosě (i puntini sono tagli miei):
| RECORDS-PER-PAGE 128.
| INTERCEPT SYSTEM BIND UPDATE EXCEPTIONS.
| 
| ASSIGN CUSAREA TO DTORD1
| 	BACKUP BEFORE AFTER IMAGES
| 	FIRST PAGE IS 1
| 	LAST PAGE IS 20
| 	PAGE SIZE IS 255 WORDS.
| .
| .
| .
| SCHEMA NAME IS DTORD PRIVACY LOCK ADMINISTRATION DTKEY.
| 
| AREA NAME IS CUSAREA.
| .
| .
| .
| RECORD NAME IS CUSTOM
| 	LOCATION MODE IS CALC USING CUST-NAME
| 	WITHIN CUSAREA,ORDAREA AREA-ID IDAREA.
| 
| 02	CUST-NAME%CUSNAM	PIC X(30) USAGE DISPLAY-7.
| 02	CUST-KEY%CUSKEY		TYPE FIXED BIN.
| 02	CUST-ADDRESS%CUSADR	SIZE 90 USAGE DISPLAY-7.
| .
| .
| .
| SET NAME IS CUSORD-SET
| 	MODE IS CHAIN LINKED TO PRIOR
| 	ORDER IS ALWAYS FIRST
| 	OWNER IS CUSTOM
| 	MEMBER IS PURORD
| 	MANDATORY, AUTOMATIC LINKED TO OWNER
| 	SET SELECTION CURRENT.
| .
| .
| .
| END-SCHEMA.
Insomma, un file .DDL contiene la descrizione di tutto il database, dei file
che andranno a contenerlo, dei suoi tipi record e delle relative relazioni.
L'esecuzione di SCHEMA produce la rappresentazione binaria (.SCH) dello
schema del database specificato nel .DDL, il giornale delle transazioni e i
vari file .DBS che conterranno i dati effettivi del database. Una cosa cosě:
| DTORD   DDL    10  <057>   10-Aug-10    DSKB:   [1,2]
| DTORD   SCH    12  <057>   10-Aug-10
| DTORD   JRN    88  <057>   10-Aug-10
| DTORD1  DBS    34  <057>   10-Aug-10
| DTORD2  DBS     9  <057>   10-Aug-10
| DTORD3  DBS     4  <057>   10-Aug-10
| DTORD4  DBS     1  <057>   10-Aug-10
Il file binario .SCH viene poi incorporato dai compilatori (Cobol e Fortran)
all'interno dei programmi compilati, per fornire ai programmi medesimi la
struttura del database a cui dovranno accedere e per mantenerli allineati
con il database vero e proprio: se si facessero certe modifiche al .DDL e si
rigenerasse lo schema, il nuovo .SCH conterrebbe un numero di generazione
diverso (una specie di checksum) che non sarebbe piů quello inserito nei
programmi al momento della compilazione, i quali dunque si rifiuterebbero di
partire per evitare danneggiamenti ai dati o risultati imprevedibili. I
manuali di DBMS-10 elencano quali modifiche del .DDL cambiano il numero di
generazione e quali no, ed elenca le varie strategie per ciascuna ipotesi.
L'accesso vero e proprio ai dati si fa per mezzo di vari statement che nel
loro insieme sono detti DML, cioč Data Manipulation Language. Per quanto
riguarda il Cobol, sono direttamente inseribili nei sorgenti e vengono
direttamente compilati insieme al resto, ed č abbastanza logico considerando
che sia questo tipo di database sia il Cobol sono emanazioni dello stesso
comitato di standardizzazione (e si nota ad esempio nella sintassi DDL). Per
quanto riguarda il Fortran invece, c'č un precompilatore che sostituisce gli
statement con le corrispondenti chiamate a routine esterne: legge un file
con estensione FML e genera un file .FOR bello e pronto per la compilazione.
Alla fine, l'installazione di DBMS-10 (se si esclude l'applicazione delle
patch) si riduce al restore da nastro di alcuni programmi (SCHEMA, DBINFO,
DBMEND e FORDML) e all'inserimento nelle librerie di runtime di Cobol e
Fortran dei moduli che rispondono agli statement DML scritti nei sorgenti.
A differenza di database piů recenti, non c'č nessun "monitor" sempre in
funzione a supervisionare l'accesso ai file dati. I programmi serializzano
autonomamente l'accesso per mezzo del giornale e delle funzioni enqueue e
dequeue offerte direttamente dal sistema operativo. Minimale, ma funzionale.
In un database reticolare non c'č il concetto di tabella, semplicemente ci
sono i vari tipi di record e delle relazioni predefinite dette set che
legano i record in relazioni uno-a-molti: un capo e i suoi dipendenti, una
fattura e le sue righe, un rappresentante e i suoi clienti etc. Il record
"padre" č detto owner del set e i "figli" sono detti members. Un record che
č member in un set puň essere allo stesso tempo owner in un altro set e
questo piů volte, cioč un record puň essere simultaneamente owner o member
in piů di un set. Ovvero un record figlio puň avere piů padri nello stesso
momento, a differenza di quanto avviene in un database gerarchico. Inoltre,
un set puň avere come members anche piů tipi di record insieme.
Un set č implementato come una catena chiusa di record, collegati fra loro
con dei puntatori, quindi partendo dall'owner si passano in sequenza tutti i
members fino a ritornare all'owner. Di default i set sono percorribili solo
in avanti, ma si puň indicare nello schema la clausola "linked to prior" per
attivare la creazione anche dei puntatori nella direzione opposta. In modo
analogo si puň indicare la clausola "linked to owner" per avere un puntatore
diretto da ogni member all'owner del set, molto utile quando si arriva a un
set da un altro e si vuole sapere subito chi č l'owner del set di arrivo.
Ad esempio: posto che in un database gestionale ci sia un set che abbia come
owner la testata di una fattura e come members le relative righe, e un altro
set con owner la descrizione di un articolo e members le righe di fattura
che quell'articolo lo contengono, partendo da una qualunque testata si
possono facilmente ottenere tutte le singole righe e poi da quelle si arriva
alla descrizione di ogni articolo grazie al puntatore diretto verso l'owner.
Ovviamente, tanto per fare un altro esempio, quella riga potrebbe anche
essere member di un set che raggruppa tutti gli esemplari di un certo lotto
di produzione di quell'articolo. Le casistiche possono essere tantissime.
Un nuovo record memorizzato nel database viene inserito automaticamente in
tutti i set in cui č definito come membro "automatic" e se č definito anche
"mandatory" non puň piů essere rimosso (se non cancellandolo). In mancanza
di queste specifiche un record puň essere inserito e rimosso a piacimento
dai vari set in cui č definito (un cliente potrebbe essere rimosso dal set
il cui owner č un certo venditore e inserito nel set di un altro).
In ogni caso, la posizione di inserimento di un record in un set dipende
dalle specifiche dello schema: il set puň essere mantenuto in ordine
(sorted) e quindi il record inserito in modo da mantenere l'ordinamento,
oppure puň essere inserito all'inizio o alla fine della "catena" oppure
ancora nella posizione subito precedente o successiva quella corrente.
La modifica di un record giŕ presente nel database causa la rivalutazione
della sua posizione in tutti i set in cui č implicato ed eventualmente la
sua rimozione o inserimento in set diversi da quelli in cui si trovava. In
modo analogo, la cancellazione di un record puň causare (dipende da com'č
scritto lo statement) la cancellazione a catena di tutti i members per i
quali quel record č owner, oppure solo di quelli opzionali, oppure ancora
generare un'eccezione se il record ha ancora members collegati, e cosě via.
Gli statements DML principali sono: FIND per trovare un record, GET per
trasferirlo nel programma, MODIFY per sostituirlo nel database con una copia
modificata, STORE per aggiungerne uno nuovo, DELETE per cancellarlo, INSERT
per inserire in un set opzionale un record giŕ presente nel database e
REMOVE per rimuoverlo da un set senza perň cancellarlo del tutto. Poi, solo
per il linguaggio Cobol, ci sono alcuni test integrati nella sintassi dello
statement IF standard. In Fortran le stesse cose si fanno chiamando delle
apposite routine esterne che fanno i medesimi test e ritornano un valore.
Un po' di esempi:
	FIND FIRST record-name RECORD OF set-name SET.
	FIND OWNER RECORD OF set-name SET.
	GET record-name.
	MODIFY record-name.
	STORE record-name.
	DELETE record-name SELECTIVE.
	INSERT record-name INTO set-name.
	REMOVE record-name FROM ALL SETS.
	IF set-name SET EMPTY statement ELSE statement.
Insieme allo schema di esempio, sul nastro c'erano anche alcuni programmi di
prova. Ho compilato e provato uno di quelli in Cobol (non l'equivalente in
Fortran perché non sono riuscito a compilarlo) e devo dire che nonostante
sia tutto in emulazione e nonostante la macchina che ospita l'emulatore sia
un antico Pentium 166 con 64 MB di RAM (cosa che dovrebbe offrire velocitŕ
finali non troppo diverse dall'originale), il programma č incredibilmente
rapido ed efficiente in tutti i tipi di accesso al database.
In effetti i piů grandi vantaggi dei database reticolari sono sempre stati
la velocitŕ e la prevedibilitŕ dei tempi di esecuzione delle letture, che
direi siano una diretta conseguenza della struttura a puntatori, in cui le
relazioni fra i dati sono in un certo senso precalcolate, a differenza dei
database relazionali in cui le query vengono analizzate ed eseguite "al
volo". Certo, i database relazionali sono piů comodi, non essendo necessario
progettare e prevedere in anticipo quali potranno essere le query piů utili
durante l'uso del database, e perché l'aggiunta di una tabella (ma anche di
una colonna a una tabella giŕ esistente) solitamente non comporta problemi
che non siano la ricompilazione del programma che necessita della nuova
colonna o tabella, senza dover fermare tutto quanto. Il relazionale deve
parte della sua fama alla praticitŕ e alla potenza di calcolo dell'hardware
moderno che permette di fare cose che un tempo erano computazionalmente
inaffrontabili. Oltre naturalmente a una maggior semplicitŕ e fedeltŕ nella
rappresentazione di certi tipi di fenomeni "naturali" (ma non tutti, tanto
che su Internet si trovano varie discussioni su quali possano essere le
migliori strategie per rappresentare e gestire in un mondo quasi del tutto
relazionale dati per loro natura fortemente gerarchizzati).
Č probabile che database reticolari piů recenti, tipo Oracle CODASYL DBMS,
permettano di fare (alcune) modifiche alla struttura del database in maniera
dinamica, invece DBMS-10 č piuttosto rigido su questo punto: come scrivevo
sopra, se si modifica lo schema č necessario scaricare il database, ricreare
i file .DBS e poi ricaricare tutto, eventualmente convertendo i dati al
nuovo formato. Non era comodo, ma certamente costringeva a progettare meglio
di come spesso si fa oggi, alla faccia della programmazione strutturata.
Un'ultima cosa: c'č chi dice che i modelli diversi dal relazionale siano
morti, ma in realtŕ non č vero: ci sono almeno due casi, o se vogliamo due
classi di casi, in cui database non relazionali sono correntemente usati e
anzi stanno avendo pure un grosso revival. XML (!) non č altro che la faccia
moderna del paradigma gerarchico e i mini-database presenti in tanti sistemi
embedded, per esempio i player di MP3, sono intrinsecamente reticolari e non
relazionali, dato che č molto piů semplice e leggero strutturare lo storage
di un player con dei puntatori piuttosto che con un vero e proprio motore di
database, tantopiů che le "query" sono previste e prevedibili a priori...
Direi che ho finito ed č veramente tutto, almeno per questa volta. :-P
Ciao,
G.


Grazie per la passione e la pazienza che ci metti.
E' sempre un piacere istruttivo leggere i tuoi "articoli"
Ciao e alla prossima!
Giorgio
Apple II and Apple III forever !!!


-- 
Elia Bellussi
Museo Piemontese dell'Informatica
http://www.mupin.altervista.org

 deciso di scrivere ugualmente, per il gusto di farlo.
forse pochi leggeranno l'ottimo resoconto, però resterà in rete per un bel 
po', vista anche l'immarcescenza delle nozioni contenute.
Posso solo dire una cosa: continua così! ^_^
saluti e complimenti,
max.speed 


L'ho letto molto volentieri anche se non amo i DB reticolari (ho
cominciato con i gerarchici e sicuramente la mia vita lavorativa è
diventata più semplice dopo l'introduzione dei relazionali).
Grazie per la descrizione di DBMS-10 che non conoscevo).
Mauro

Ho iniziato la mia carriera lavorariva su un DB reticolare installato su
un sistema Siemens BS2000, utilizzando Cobol/74 e parzialmente
assembler/370. (1989-1990)
Non mi ricordo quasi più nulla e per me è un piacere leggere il tuo
articolo.
Dopo un passaggio al DB gerarchico (DL/1, IMS) oramai sono stabilmente su
relazionale. (DB2)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 rapido ed efficiente in tutti i tipi di accesso al database.
Ecco, quando a penso a queste cose continuo a stupirmi di come sia possibile 
che i sistemi hardware attuali siano dei MOSTRI che ci permettono di fare 
più o meno le stesse cose che 25 anni fa si facevano con risorse hardware 
incredibilmente minori (anche se incredibilmente più costose), e più o meno 
con gli stessi tempi di risposta... :-)
Ma forse è questione di abitudine ed in realtà oggi si fanno molte più cose, 
ma non ce ne rendiamo conto.
Ciao.
Roberto

 farlo.
č veramente un piacere leggere i vari post che tu ed altri frequentatori 
di ICR state inviando
oltretutto avrai notato che a leggerli non sono poi cosě pochi
p.s. spero tanto di ritrovarti ad una prossima Marzaglia per ascoltare 
altri racconti a fine fiera ;-)
-- 
_________
Simone DG
_________ 

> probabilmente interesserà a pochi
si, davvero a molto pochi, basta cercare DBMS-10 su google, e vedere
qual'e' 
il primo risultato! :)
a parte questo, splendido post, e se a marzaglia ci sarai e racconterai
altre 
chicche simili, io di sicuro saro' li' ad ascoltare.
-- 
Spolvera la mia email per rispondermi
"Storia del Mondo. I vulcani eruttarono. Gli oceani ribollirono.
L'universo era in tumulto. Poi venne il cane."
Snoopy
maxy04.splinder.com


bell'articolo!
che voi sappiate, esistono db reticolari free?
ho provato a guglare, ma non sembra esistano.
-- 


 ho provato a guglare, ma non sembra esistano.
Ho provato anch'io, ma pare che non ci sia nulla di nulla. A dire il vero
anche i DB reticolari a pagamento sono veramente pochissimi e per nulla
pubblicizzati. Insomma, li trova e li conosce quasi solo chi già li usa.
Ciao,
G.

 ha scritto nel messaggio 
news:pod366p5vccm7live...@4ax.com...
chapeau, come al solito... pero' vacci in vacanza ogni tanto!!! :PPP
mi accoderei qui (tanto per rovinarti il 3ad) con una richiesta ai pochi 
superstiti dei bei tempi andati
chi va a marzaglia l'11/09?
potrebbe essere una occasione per andare a pranzo o a cena, io mi fermerei 
solo una mezza giornata (non c'ho piu' l'eta' )
mettere una croce sotto :P
-- 
X-No-Archive: Yes
%DCL-F-RUIDIOT?
(IV3AIE) 

 mettere una croce sotto :P
Vedo che noi hai riscosso molto successo. :P Io francamente non so proprio
cosa farò: tutta la giornata non mi va, potrei fare come una delle ultime
volte, cioè mi presento alle sei e mezza di sera, quando il sole è già
calato e c'è meno caldo, giusto per fare un po' di chiacchiere e poi andare
a cena. :P Qualcun'altro offre di più? Io cmq per ora non confermo...
Ciao,
G.

 a cena. :P Qualcun'altro offre di piů? Io cmq per ora non confermo...
avevo gia' riscontrato il mio poco successo, confermatomi tra l'altro da un 
noto alfista locale.
lasciamo perdere, facciamo che quando ho da passare per BO la prossima volta 
ti chiamo e se sei libero ci facciamo due tortelli in uno di quei posti che 
sai tu...
L.
-- 
%DCL-F-RUIDIOT?
(IV3AIE)