Newsgroup: it.comp.retrocomputing
Titolo: Come leggere le immagini dei nastri Domain/OS

Ho avuto successo nella non scontata impresa di leggere il contenuto di uno
degli archivi contenuti in uno dei famosi nastri di Domain/OS di cui si è
parlato negli ultimi giorni in questo NG.
Per farlo mi sono servito di due utility disponibili in rete, tapedd e rbak.
La prima fa parte di KLH10, l'ottimo emulatore PDP-10 di Ken Harrenstien ed
è un molto migliore sostituto del povero tapecopy che fa sì il suo servizio,
ma è certamente più grezzo e meno versatile di tapedd; la seconda viene da
un repository di vecchio materiale Domain trovato in ete quasi per caso.
Al contrario di tapecopy, tapedd consente anche la conversione da un formato
di immagine all'altro, nonché l'estrazione di singoli tapefile, quindi mi è
servito per estrarre dall'immagine uno degli archivi in formato wbak/rbak
che poi ho letto con l'apposita utility che mima l'originale HP.
In questo caso dd non è sufficiente, perché anche riuscendo con un po' di
pazienza a isolare dall'immagine un singolo tapefile (che è poi abbastanza
facile), c'è però il problema degli header e trailer di blocco presenti e
inframmezzati ai dati estratti: in situazioni di emergenza si potrebbe fare
anche questa operazione con dd, ma diventa quasi impossibile spezzettare un
file magari di decine di megabyte in blocchi da 32768 byte (se va bene).
A essere precisi bisogna dire che tapecopy non estrae singoli tapefile da un
nastro, ma permette "solo" la conversione da un formato immagine all'altro,
permettendo di scegliere quali file copiare da sorgente a destinazione. Però
se gli si dice di copiare un solo tapefile e di utilizzare come formato di
output quello raw, ecco che di fatto si è estratto un singolo tapefile. :-)
Naturalmente tapecopy opera non solo con immagini ma anche con device reali.
Fatto questo, e dopo aver lottato un po' per compilare rbak (niente di che:
bisogna mettere a posto ansitape.h in corrispondenza di XXX e YYY) e visto
che fortunatamente prevede anche l'input da file e non solo da nastro, come
del resto era l'originale accoppiata wbak/rbak di Domain, sono riuscito a
ottenere l'elenco (index) di tutti gli archivi che ho provato, ad eccezione
di quello danneggiato, che infatti viene segnalato come poco sano sia da
tapedd durante l'estrazione sia ancora di più da rbak durante la lettura.
Ecco un esempio:
| $ tapedd itve=domainos-sr10.3-2of9.tap otvr=install fskip=1 fcnt=1 verbose
| ;  Input tape spec "domainos-sr10.3-2of9.tap" (Type: virtual format: tpe)
| ; Output tape spec "install" (Type: virtual format: raw)
| ; Max tapemarks (files) to process: 1
| ; Copying from "domainos-sr10.3-2of9.tap" to "install"...
| ;  In: 0+0 errs, 2 files, 365 recs, 11909120 bytes
| ; Out: 0+0 errs, 1 files, 364 recs, 11906560 bytes
|
| $ rbak -512 -index -all -from install.tpr
| Starting index:
| 
| (file) install/toc/toc.apollo.ST0157.c
| (file) install/doc/apollo/os.v.10.3__bind4.8_operations_guide
| (file) install/doc/apollo/os.v.10.3__notes
| (file) install/doc/apollo/os.v.10.3__posix
| (file) install/doc/apollo/os.v.10.3__transition_guide
| (dir)  install/help
| (file) install/help/cfgsa.hlp
| (file) install/help/config.hlp
|   .
|   .
|   .
| (file) install/tools_sr9/minst
| (file) install/tools_sr9/mrgcfg
| (file) install/tools_sr9/rbak_sr9
| (file) install/tools_sr9/rgy_create
| (file) install/tools_sr9/uctnode
| 
| Index complete.
| $
N.B. l'output raw di tapedd è composto di due file, uno con estensione tpr
che contiene i dati effettivi e puliti e l'altro con estensione tpk che è un
indice scritto in un formato preciso, ad uso di certi emulatori. Così:
| $ cat install.tpk
| ; Tape directory for install.tpr
| ; Bytes: 11906560, Records: 364, Files(EOF marks): 1
| TF-Format: raw install.tpr
| 0: 32768*363 11776 EOF
| EOT:
| $
Naturalmente ho anche provato a estrarre il contenuto di uno di quegli
archivi e il risultato è molto incoraggiante (e pure i testi si leggono):
| $ file *
| acl:                   apollo a88k COFF executable
| cfgsa:                 apollo a88k COFF executable not stripped
| config:                apollo a88k COFF executable not stripped
| config_info_file:      ASCII English text
Per finire, le utility si trovano ai seguenti URL:
 - rbak: 
http://www.umich.edu/~archive/apollo/
 - tapedd: 
http://klh10.trailing-edge.com/
 (ma c'è di meglio, chiedete!)
e inoltre si ringrazia Vampire per le sue CPU più potenti delle mie. :-)
Ciao,
G.
-- 
  «Al tavolo di comando e' connessa una Telescrivente, che ha l'ufficio di
prelevare il contenuto delle posizioni di Memoria che si desidera indagare
dandone la trascrizione a stampa su di un foglio di carta».
            Olivetti ELEA 9003 — Manuale base di programmazione — ca. 1955

Ho avuto successo nella non scontata impresa di leggere il contenuto di uno
degli archivi contenuti in uno dei famosi nastri di Domain/OS di cui si è
parlato negli ultimi giorni in questo NG.
Per farlo mi sono servito di due utility disponibili in rete, tapedd e rbak.
La prima fa parte di KLH10, l'ottimo emulatore PDP-10 di Ken Harrenstien ed
è un molto migliore sostituto del povero tapecopy che fa sì il suo servizio,
ma è certamente più grezzo e meno versatile di tapedd; la seconda viene da
un repository di vecchio materiale Domain trovato in ete quasi per caso.
Al contrario di tapecopy, tapedd consente anche la conversione da un formato
di immagine all'altro, nonché l'estrazione di singoli tapefile, quindi mi è
servito per estrarre dall'immagine uno degli archivi in formato wbak/rbak
che poi ho letto con l'apposita utility che mima l'originale HP.
In questo caso dd non è sufficiente, perché anche riuscendo con un po' di
pazienza a isolare dall'immagine un singolo tapefile (che è poi abbastanza
facile), c'è però il problema degli header e trailer di blocco presenti e
inframmezzati ai dati estratti: in situazioni di emergenza si potrebbe fare
anche questa operazione con dd, ma diventa quasi impossibile spezzettare un
file magari di decine di megabyte in blocchi da 32768 byte (se va bene).
A essere precisi bisogna dire che tapedd non estrae singoli tapefile da un
nastro, ma permette "solo" la conversione da un formato immagine all'altro,
permettendo di scegliere quali file copiare da sorgente a destinazione. Però
se gli si dice di copiare un solo tapefile e di utilizzare come formato di
output quello raw, ecco che di fatto si è estratto un singolo tapefile. :-)
Naturalmente tapedd opera non solo con immagini ma anche con device reali.


 G.
Fai capire ad un povero mortale :)
Tapedd dev'essere usato all'interno dell'emulatore klh10 ? (Cho ho 
installato tempo fa e mai utilizzato...)
Oppure è compilabile anche in altri ambienti (leggasi Linux) ?
Dopodiché, l'output di tapedd lo si dà in pasto a rbak (e questo si può 
fare in ambiente Linux).
A proposito ... sul forum Nekochan sostengono che DomainOS sr10.3 era 
composto in tutto da 5 nastri, uno di boot e quattro di sistema, da 
scrivere su di un QIC-24 (60MB), il che mi manderebbe ... ramengo :)
Secondo loro niente QIC-150 (6150).
Non mi resta che curiosare con tapedd e rbak negli altri nastri (6-9)...

Ovviamente, abbiate pazienza ...
Dal lunedì al mercoledì sono realmente fuori ... incamero informazioni da 
applicare dal giovedì alla domenica (sabato notte compresa).
Forse potrei avere anche dei tape drive QIC-24, in garage (ce ne sono una 
decina non identificati, senza contare quelli inclusi in un paio di 
Olivetti, che non ho mai analizzato a fondo).
Ma nastri DC600A sono compatibili con un QIC-24 ?
Ricordatevi che di nastri ne so pochino ... 

 Non mi resta che curiosare con tapedd e rbak negli altri nastri (6-9)...
Ricordati che sono nastri con label ANSI, quindi con tapedd quando estrai il
contenuto dalle immagini devi prendere il secondo, quinto, ottavo etc. file
e saltare gli altri perché sono label, i quali — lo ripeto ancora — da un
punto di vista pratico sono file su nastro, ma da un punto di vista logico
sono informazioni di servizio per l'OS e non per il programma in lettura.
Il fatto è che tapedd conta i tape mark, e secondo lui (giustamente) tutto
Il resto sono dati. Per esempio, uno dei nastri di backup conteneva un solo
file dati, ma per tapedd ce n'erano cinque:
- label di testa, tm, dati, tm, label di coda, tm, tm, tm.
Cinque tape mark e dunque per lui cinque file. In realtà in fondo ci sono
tre tape mark perché uno chiude i label di coda e gli altri due indicano la
fine logica del nastro. Io per sapere quanti file c'erano sul nastro ho
detto a tapedd di estrarmi un file dopo averne saltati mille (fskip=1000
fcnt=1) in verbose mode: ovviamente non c'erano mille file, quindi non mi ha
estratto nulla, però mi ha detto il totale di tape mark saltati e quindi ho
saputo quanti ce n'erano e mi sono regolato.
Se ci fosse più di un file dati (tape file), sarebbe così:
- testa, tm, dati, tm, coda, tm, testa, tm, dati, tm, coda, tm, testa, tm...
quindi appunto secondo, quinto, ottavo e così via.


 Ricordatevi che di nastri ne so pochino ... 
Dai un'occhiata qui: 
http://www.qic.org/html/qicmatr.html#datacart


 | config:                apollo a88k COFF executable not stripped
File per DN10000?
Nuzzler

 File per DN10000?
cosi pare, in origine mentre gerry me li elencava pensavo alla
famiglia motorola 88000 ma di norma sono identificati come m88k, 
pare che l'a88k sia propio il Prism usato nelle DN10000.
-- 
member of the italian hobbyist DECnet network - 
decnet.ipv7.net
www.unsupported.info
 - 
img.unixantichrist.net