Newsgroup: it.comp.retrocomputing
Titolo: [OT] tapedd

Vi risulta che tapedd abbia un limite/bug a 2.0 GB ?
Stavo archiviando il backup dell'AS/400 quando ho notato che la dimensione del 
file non aumentava più, ma il drive continuava a leggere.
Il file s'era fermato esattamente a (2*1024*1024*1024 - 1) bytes.
Non è un problema di filesystem... è un ext3, 119GB liberi, e contiene immagini 
disco anche di 4GB.
L'unico candidato è tapedd :P
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 Il file s'era fermato esattamente a (2*1024*1024*1024 - 1) bytes.
 
...:-(
 
 
il backup e' quello famoso del 150  fatto di notte
sul nastro esterno ?
 
Se no, ignora pure le righe che seguono.
 
Se si....forse si potrebbe leggere
il file di log dell'AS/400 per vedere
se ci sono stati oggetti non salvati?
Oppure rimettere il nastro nel lettore
e fare un DSPTAP....per verificare
che veramente  il backup sia andato a buon fine.
Purtroppo sara' operazione lunghissima...:-\
 
Se ti sembrano scrupoli e pignoleria eccessivi, ignora tutto lo stesso, non 
mi offendo...:-)
 
ciao
fm
 
 
 
 
 
 
 


Ho trovato l'arcano ...
Secondo il 150, il backup è andato a buon fine. Niente errori o oggetti non 
salvati.
Il problema giace proprio in tapedd o tapecopy e nel tipo di dati usati.
Adesso ho modificato gli unsigned long in unsigned long long, ed i semplici 
long in long long. Dovremmo venirne a capo...
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 


ok
 
ciao
fm 
 
 

Più complesso del previsto...
Ai tipi di dati, s'è aggiunto il filesystem.
Il mio sistema operativo è a 32bit, per cui le funzioni standard come
write ed fwrite sono limitate a 2GB-1.
Ho forzato la compilazione con D_FILE_OFFSET_BITS=64, vediamo se si risolve...
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 


credo di capire che stai "copiando" il nastro
con questo programma tapedd che purtroppo
non conosco...
Immagino pero' che ci siano, eventualmente,
anche altri prodotti che svolgono la stessa
funzione.....magari anche free????
 
 
ciao
fm 
 
 


Terminato !
Ho "messo mani" al codice di tapecopy (più facile)... tapedd è molto più 
complesso e meno commentato :(
Ha copiato senza errori, mi ha dato il messaggio EOT ed alla fine del
file immagine ho trovato i due tapemarks. La copia dovrebb'esser stata eseguita
correttamente.
Un dubbio m'è rimasto: la dimensione del file immagine è
4940929076
 
comprensiva delle informazioni di controllo.
L'asp del 150 è di 8339 MB, occupata al 70%, che ammontano a 5837.3 MB
 
GO SAVE (opzione 21) effettua una compressione dei dati oppure non tutto 
è salvato, come aree di spool o di swap (se esistono) ?
 
 
-- 
http://www.supervinx.com/Retrocomputer
 


i)Compressione dati:
se lasci i parametri del nastro ai valori di default, con le cassette SLR, i 
nastri risultano sempre  compressi...
con le librerie programmi e files direi circa ( molto all'incirca)  un  30%.
(dipende anche dall'unità nastro).
Hai salvato tutto il sistema, hai usato un nastro diverso....
cmq che sia un po' piu' piccolo direi ci puo' stare.
 
ii)Tutti gli oggetti:
diciamo che con l'opzione 21 salvi il 99,9% di quello che serve,
rimane fuori qualcosa...forse qualche informazione relativa alla 
sicurezza(?).
Nel tuo caso dovrebbe essere trascurabile.
 
In una delle prime schermate del comando, se non ricordo male,
 ci dovrebbe anche essere scritto
cosa viene salvato e cosa non viene salvato.
 
Lo spool viene salvato.
C'erano clienti che tenevano gli spool files per mesi/anni,
quindi sono dati del sistema a tutti gli effetti.
 
Mi scuso se ho scritto qualche scemenza...:-)
 
ciao
fm
 
 
 
 


 
Opsss...
 
Prima scemenza:
per default lo spool NON viene salvato.
 
Viene salvato o SOLO SE si imposta a *ALL l'opportuno
parametro che ha per default *NONE.
 
(Sto leggendo la guida Backup & Recovery
di un release successivo al tuo,
ma le cose non dovrebbero essere cambiate).
 
 
ciao
 fm
 
 


 Quando ho scelto l'opzione 21, m'ha detto che lo spool non sarebbe stato salvato.
Non mi sono preoccupato, perché avevo già fatto pulizia ...
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 


Quindi nel salvataggio non manca nulla.
 
Resterbbe da spulciare un  la documentazione per vedere
se realmente il salvataggio dell'opzione 21 viene fatto compresso.
(come diceva gerry non e' nulla di che....una serie di comandi
savsys, savobj,  sav...etc)
Se l'unità lo consente, essendo un salvataggio che occupa sempre
molto spazio, perche' non dovrebbe comprimere?
 
ciao
fm
 
 

 Ho forzato la compilazione con D_FILE_OFFSET_BITS=64, vediamo se si risolve...
 
Piů che il filesystem, saranno le routine che stai utilizzando ad avere
problemi. Del resto prima hai scritto che č un ext3 con file che superano i
4 GB, quindi il problema non č lě e comunque quel filesystem ha dei limiti
che arrivano allegramente nell'ambito dei terabyte. :)
 
Ciao,
G.

 mesi/anni, quindi sono dati del sistema a tutti gli effetti.
 
Escludo che _non_ venga salvato qualcosa di relativo alla sicurezza. Quel
che non viene salvato (parliamo di V3R7) č il contenuto delle code, ma
siccome gli utenti hanno sempre avuto la brutta abitudine di conservare le
stampe per anni, alla fine l'IBM si č decisa e ha introdotto l'opzione per
salvare il contenuto delle code (direi V5R3 o giů di lě).
 
Nelle vecchie macchine CISC non veniva salvato il MULIC/FULIC.
 
Ciao,
G.
 

 long in long long. Dovremmo venirne a capo...
 
Hai provato con i vari tipi di nastro che puň generare tapedd? Il tipo raw
potrebbe essere il migliore candidato per un'immagine cosě grande. Del resto
si tratta di strumenti fatti per copiare nastri molto vecchi, che spesso non
superavano i 100 MB. Chissŕ, forse Sadness ha qualche immagine che supera i
2 GB di dimensioni e che sia stata verificata come funzionante. Tu con le
immagini per Apollo a quanto eri arrivato?
 
Il formato usuale per le immagini č quello nato con Simh, e non dovrebbe
avere limitazioni sulla lunghezza dei nastri, ma al massimo sulla lunghezza
dei singoli blocchi che comunque non dovrebbero arrivare oltre i 500 kB.
OS/400 per i nastri QIC usa solitamente un blocco da 32760 byte, forse per
il DDS ha usato circa 200 kB per blocco, ma comunque roba entro i limiti.
Piů facile che sia un problema interno al programma e a qualche variabile
utilizzata per tenere traccia di quel che sta facendo. Insomma, non credo
che il problema risieda nel formato delle immagini...
 
Ciao,
G.
 

 salvato, come aree di spool o di swap (se esistono) ?
 
L'opzione 21 del menu SAVE richiama un "semplice" programma CL che esegue in
sequenza dei comandi standard (SAVSYS, SAVLIB, SAVDLO, SAV) con relativi
parametri di default, i quali specificano la compressione hardware del drive
(se c'è) e la compressione hardware dell'adapter SCSI (se c'è), altrimenti
nulla. Volendo si può richiedere la compressione software, ma non è una cosa
attiva di default. Il drive che hai usato ha la compressione hardware?
 
Lo swap come lo si intende comunemente è un concetto che non esiste in
OS/400, quindi non viene salvato nulla di quel genere. Per quanto riguarda i
dati in spool, vengono salvate le code ma non il loro contenuto. Ma comunque
a te non dovrebbe fare molta differenza, dato che hai da poco fatto fuori
tutto quanto. Al massimo avrai un po' di log (vedi con WRKOUTQ), ma nulla di
molto ingombrante.
 
Ciao,
G.
 

 molto spazio, perche' non dovrebbe comprimere?
 
L'accoppiata DTACPR(*DEV) + COMPACT(*DEV) attiva la compressione hardware
del drive, se c'è, altrimenti niente. Un tempo c'erano IOP che avevano una
loro compressione harware indipendente, e questa era controllata dal
parametro DTACPR; ora che questa cosa non esiste praticamente più, quel
parametro in pratica controlla la sola compressione software e il valore
*DEV è diventato equivalente a *NO.
 
DTACPR(*DEV)	Compressione IOP, se c'è
DTACPR(*NO)	Niente compressione IOP
DTACPR(*YES)	Compressione IOP oppure (in mancanza) software
 
COMPACT(*DEV)	Compressione del drive, se c'è
COMPACT(*NO)	Niente compressione del drive
 
Quando esisteva la compressione IOP, *DEV + *DEV attivava solo quella del
drive per evitare la doppia compressione che è (quasi) sempre svantaggiosa.
Se invece il drive non aveva la compressione, ma c'era quella IOP, allora
veniva utilizzata quest'ultima.
 
Pare ci fosse un caso particolare in cui una 3490 attaccata a un ben preciso
IOP dava le prestazioni migliori con *YES + *DEV, ma era un'eccezione.
 
Poi ci sarebbe da dire anche su USEOPTBLK...
 
Ciao,
G.
 


 
il suo dubbio era sul file che risultava piu' piccolo
dello spazio occupato su disco.
 
Credo che il motivo  sia appunto la compressione
Anche se non sappiamo che tipo unità sia stata creata
con il name TAP02.
 
Inoltre dice di aver fatto pulizia dello spool....se
avesse solo cancellato le stampe, ci sarebbe ancora
un po' di spazio rimasto allocato (se non ha  lanciato
il RCLSPLSTG)....
 
Inoltre non si tratta di un'immagine disco (per dirla con il linguaggio 
pc )...
ma di un salvataggio....mi aspetterei il numero dei byte
significativamente diverso  anche a compressione zero.
 
ciao
fm
 
 
 
 
 

 
In tapecopy.c ho modificato:
 
unsigned long --> unsigned long long
 
long --> long long (in quanto potevano assumere valori negativi)
 
Poi ho compilato forzando le routine a 64bit per la gestione dei files.
Tapecopy mi ha informato che era andato tutto bene e la fine del nastro 
era stata raggiunta "felicemente".
 
Guarderò DSPLOG e controllerò con DSPTAP.
Dici che non devo fidarmi del solo messaggio di GO SAVE il quale
affermava che il salvataggio era stata effettuato con successo ?
 
Nel frattempo ho "imparato" a scrivere/compilare ed eseguire un 
programma/procedura in CLP.
Son dovuto entrare nell'ottica che eventuali errori di sintassi non sono
mostrati direttamente a video, ma finiscono nel solito posto ;)
 
http://www.supervinx.com/Retrocomputer
 

 mostrati direttamente a video, ma finiscono nel solito posto ;)
 
Se crei un membro di tipo CLP, il controllo sintattico del SEU č automatico.
Tra l'altro (non so se l'hai giŕ visto), se dentro l'editor scrivi un
comando e poi fai F4, ti chiede i parametri come quando lo vuoi eseguire e
quando premi Invio ti compone la riga tutta formattata come si deve.
 
Se ti riferisci invece alla compilazione, sě: bisogna abituarsi all'idea che
i messaggi del compilatore e l'elenco degli errori finiscano in un listato
in spool e non direttamente a video come in altri OS. :)
 
Ciao,
G.
 

 significativamente diverso  anche a compressione zero.
 
Be' oddio, un po' diverso sì. Significativamente diverso no. È vero che il
formato di salvataggio di OS/400 è abbastanza prolisso, specialmente per i
SAVF, ma se sul disco ci sono tot gigabyte di roba, mi aspetto di avere
circa tot gigabyte di roba anche sul nastro. Escludendo la compressione,
ovviamente. Un'immagine disco sarebbe comunque grande come il disco, non
come i dati, visto che comprenderebbe anche le zone vuote.
 
Ciao,
G.
 


io mi fiderei...
Pero'....trattandosi di materia delicata come i salvataggi....
la prudenza non e' mai troppa.
 
Sia ben chiaro che questa e' solo una discussione accademica..:-)
 
Non raccontero' storie recenti  visto il ng,
ma un  caso di tanti anni fa, col S/34 di un'azienda grossa.
 
Il file anagrafico clienti aveva creato dei dubbi....al che 
l'operatore/programmatore
del sistema disse: "nessun problema, abbiamo i salvataggi".
Effettivamente nei due mariner ( 10 floppy da 8" ciascuno)  c'erano i 
salvataggi
 eseguiti qualche giorno prima.
 
Peccato mancasse un unico file ... che era appunto ANAGRA...:-)
 
 
ciao
fm
 
 
 
 
 


Convertito da EBCDIC ad ASCII, l'immagine termina così.
È plausibile ?
 
26809770   00 BA 00 00  00 00 00 00  26 00 00 00  45 4F 46 31  ........&...EOF1
 
26809780   53 41 56 32  30 31 32 30  35 30 34 20  20 20 20 20  SAV20120504
 
26809790   20 54 41 50  30 30 31 30  30 30 31 30  31 30 31 30   TAP001000101010
 
268097A0   30 30 31 30  30 30 31 32  31 32 35 39  39 39 39 39  0010001212599999
 
268097B0   39 30 30 30  31 39 36 31  49 42 4D 4F  53 34 30 30  90001961IBMOS400
 
268097C0   20 20 20 20  20 20 20 20  20 20 20 20  26 00 00 00              &...
 
268097D0   26 00 00 00  45 4F 46 32  55 33 32 37  36 30 30 30  &...EOF2U3276000
 
268097E0   30 30 30 20  30 20 20 20  20 20 20 20  20 20 20 20  000 0
 
268097F0   20 20 20 20  20 20 20 20  20 20 20 20  20 20 20 20
 
26809800   20 20 20 20  20 20 20 20  20 20 20 20  20 20 20 20
 
26809810   20 20 20 20  20 20 20 20  20 20 30 30  30 30 30 33            000003
 
26809820   32 37 36 30  26 00 00 00  00 00 00 00  00 00 00 00  2760&...........
 
26809830   00 00 00 00                                         ....
 


oggi si puo' ovviare con le meraviglie del  Rational Developer  ...
all'epoca del 150 non c'era..:-)
 
ciao
fm 
 
 

 funzionante. Tu con le immagini per Apollo a quanto eri arrivato?
 
Macche, tutti i nastri che ho avuto necessita' di dumpare con tapecopy e/
o tapedd in pratica non superano il giga, il piu' grosso credo sia il
famoso nastro della v3r2 con ptf etc che ben conosci.
 
-- 
member of the italian hobbyist DECnet network - 
decnet.ipv7.net
 
www.unsupported.info
 - 
img.unixantichrist.net
 

Tapedd/tapecopy sono pensati per nastri QIC, al più qualche centinaio di MB...
Una "pezza" a tapecopy [er il momento l'ho messa... 
Adesso sto controllando tapedd...
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 È plausibile ?
 
Assolutamente sì, e ci dà molte informazioni interessanti. Intanto si vede
che l'immagine termina correttamente con la fine del nastro, poi dal nome
dell'ultimo dataset deduco che la procedura di salvataggio è effettivamente
arrivata in fondo, che il nastro ha i blocchi standard da 32760 byte e che
si compone di 101 dataset. Se non ho interpretato male i label, pare che i
dataset non siano compressi.
 
Bisognerebbe verificare con precisione che siano corretti anche i metadati
specifici del formato immagine utilizzato, e per farlo dovresti riproporre
qui lo stesso pezzo di dump senza conversione in ASCII, perché quella
ovviamente converte anche i metadati, che invece non vanno toccati.
 
Ciao,
G.
 

 questa dovrebbe essere nel menu LICPGM
 
Ah s', vero. Mi sono confuso perché varie volte ho usato le opzioni 40 e 41
di LICPGM per salvare il sistema, e poi davo un'occhiata con l'opzione 50.
 
G.

 Tapedd/tapecopy sono pensati per nastri QIC, al più qualche centinaio di MB...
 
Be' insomma... Ci sono QIC da 70/140 GB (vedi gli SLR140) :)
 
Ciao,
G.
 

 Be' insomma... Ci sono QIC da 70/140 GB (vedi gli SLR140) :)
 
Che dici, doniamo un MLR-1 (16Gb) agli autori di tapedd e tapecopy ? :)


Donatene uno all'autore delle patches per filesystems a 32bit ;)


101 dataset e' numero ragionevole.
Pero', secondo i ns ragionamenti precedenti, dovrebbero essere compressi.
(a meno che il TAP02 non ammetta la compressione).
Se non sono compressi, perche' manca quasi 1Gb ...???
 
OK, non abbiamo detto che OS/400 non salva gli indici dei files
(altro risparmio di tempo e spazio su nastro)
pero' da 5.8 Gb a 4.9Gb solo per gli indici mi sembra tanto.
Tutto dipende da quanto grandi sono gli indici rispetto all'area dati.
 
ciao
fm
 
 
 


Per curiosità ho provato a salvare su nastro una libreria ... SENZA 
compressione.
 
9401 150 V4R4,  nastro 6382, con cassetta formattata *QIC150.
 
Ampiezza libreria  TEST su disco: 78.602.240  (contiene circa 50  PF e LF 
relativi)
 
1)  SAVLIB LIB(TEST)    DEV(TAP01)
 
2) SAVLIB LIB(TEST)
       DEV(TAP01)
       USEOPTBLK(*NO)
       DTACPR(*NO)
       COMPACT(*NO)
 
3) SAVLIB LIB(TEST)
       DEV(TAP01)
       USEOPTBLK(*NO)
       DTACPR(*YES)
       COMPACT(*DEV)
 
Risultato?
tutti e tre i comandi producono un file su nastro di identica ampiezza:
 
 Lungh.  Lungh.  Lungh.
 record  blocco  file
 00000   032760  001462
 
ossia: 32760*1462=47.895.120
 
... comprime sempre  ! ... :-)))
 
ciao
fm
 
 
 

 compressione). Se non sono compressi, perche' manca quasi 1Gb ...???
 
Io mi sono basato su quel che ho visto nei label, e la documentazione IBM
specifica che la compressione venga indicata da una P in una certa
posizione, e nei label riportati da Supervinx quella P non c'era. In effetti
mi ricordo che c'è una certa combinazione di parametri dei vari comandi SAV
la quale causa l'apparizione di una P in DSPTAP. In caso di output in spool
mi pare che sia la colonna subito dopo quella del numero di sequenza.
 
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzatb/volum.htm
 
 
Mah...
G.
 

        COMPACT(*DEV)
 
Considerato quanto detto sopra, i comandi (1) e (2) sono equivalenti, il (3)
dovrebbe essere diverso perché con DTACPR(*YES) si attiva la compressione
software. Quel che hai ottenuto mi sorprende...
 
Stasera se ho tempo provo io con una 6380 a V4R3. Le combinazioni dei tre
parametri USEOPTBLK, DTACPR e COMPACT danno ben 12 possibilità diverse.
 
Ciao,
G.


Grazie.
Potrei aver sbagliato qualcosa....
 
In verità credo di aver sempre fatto il 99% dei salvataggi con i parametri
standard e la compressione e' piu' che ben accetta, visto che
fino a pochi anni fa le cassette erano relativamente troppo piccole e
troppo costose ...
 
ciao
fm
 
 

 troppo costose ...
 
Dunque, ho fatto un po' di prove anch'io e devo dire che non capisco bene i
risultati ottenuti. O meglio, non so che senso dargli.
 
I tre parametri che influenzano le dimensioni dei salvataggi sono USEOPTBLK
(use optimal block), DTACPR (data compression) e COMPACT (data compaction),
per un totale di 12 combinazioni possibili fra i valori che possono avere.
 
Ho fatto un programmino che salva gli stessi dati più volte, con tutte le
possibili combinazioni di parametri, e ho fatto in modo che i valori assunti
di volta in volta dai vari parametri siano indicati direttamente nel nome
del dataset su nastro, così risulta più facile interpretare i dati.
 
Primo esperimento: unità 5619 (DAT160) su V5R4. Salvati 1.683.456 byte.
 
                              Formato                             
                   Seq.       blocco  Tec.  Lungh.  Lungh.  Lungh.
File dati          file       record  rec.  record  blocco  file  
U*YES D*DEV C*DEV  0000000118 *U      P     00000   262144  0000000006
U*YES D*DEV C*NO   0000000119 *U            00000   262144  0000000006
U*YES D*YES C*DEV  0000000120 *U      P     00000   262144  0000000006
U*YES D*YES C*NO   0000000121 *U            00000   262144  0000000006
U*YES D*NO  C*DEV  0000000122 *U      P     00000   262144  0000000006
U*YES D*NO  C*NO   0000000123 *U            00000   262144  0000000006
U*NO  D*DEV C*DEV  0000000124 *U      P     00000   032760  0000000048
U*NO  D*DEV C*NO   0000000125 *U            00000   032760  0000000048
U*NO  D*YES C*DEV  0000000126 *U      P     00000   032760  0000000048
U*NO  D*YES C*NO   0000000127 *U            00000   032760  0000000048
U*NO  D*NO  C*DEV  0000000128 *U      P     00000   032760  0000000048
U*NO  D*NO  C*NO   0000000129 *U            00000   032760  0000000048
 
(U sta per USEOPTBLK, D sta per DTACPR, C sta per COMPACT)
 
L'unità è nuova e supporta la compressione hardware a livello di drive,
tant'è vero che quando COMPACT è *DEV (C*DEV) compare la P nell'apposita
colonna, però bisogna anche dire che in combinazione con USEOPTBLK(*YES)
viene emesso un messaggio che informa che la compressione non verrà
effettuata. Invece con U*NO non compare alcun avvertimento, quindi devo
pensare che la compressione venga fatta. Ad ogni modo, la P compare sempre.
 
Come si vede, il blocco ottimizzato è più grande del blocco standard, ma se
andiamo a moltiplicare la dimensione del singolo blocco per il numero di
blocchi utilizzati, otteniamo lo stesso totale (al netto di pochi byte di
arrotondamento). La cosa soprendente è che nonostante tutte le combinazioni,
il risultato è sempre uguale: cambia la dimensione dei blocchi e a volte c'è
la P (a volte ignorata e a volte no), ma il totale finale è sempre identico.
 
Secondo esperimento: unità 6380 (QIC2GB) su V4R3. Salvati 63.168.512 byte.
 
                         Formato                             
                   Seq.  blocco  Tec.  Lungh.  Lungh.  Lungh.
File dati          file  record  rec.  record  blocco  file  
U*YES D*DEV C*DEV  00001 *U            00000   032760  002133
U*YES D*DEV C*NO   00002 *U            00000   032760  002133
U*YES D*YES C*DEV  00003 *U            00000   032760  002133
U*YES D*YES C*NO   00004 *U            00000   032760  002133
U*YES D*NO  C*DEV  00005 *U            00000   032760  002133
U*YES D*NO  C*NO   00006 *U            00000   032760  002133
U*NO  D*DEV C*DEV  00007 *U            00000   032760  002133
U*NO  D*DEV C*NO   00008 *U            00000   032760  002133
U*NO  D*YES C*DEV  00009 *U            00000   032760  002133
U*NO  D*YES C*NO   00010 *U            00000   032760  002133
U*NO  D*NO  C*DEV  00011 *U            00000   032760  002133
U*NO  D*NO  C*NO   00012 *U            00000   032760  002133
 
L'unità non supporta la compressione hardware a livello di device (cosa che
sapevo) e infatti la P non compare mai. Non vengono fatte segnalazioni di
alcun tipo per nessuna combinazione di parametri. Qui il risultato è sempre
identico, e non si smuove in alcun modo. È così, è così, è così. Punto.
 
In entrambi i casi mi sarei aspettato di vedere qualche differenza almeno
richiedendo la compressione software (D*YES), ma evidentemente c'è qualcosa
che mi sfugge. L'unica cosa che posso ipotizzare è che le differenze si
possano apprezzare solo salvando molta roba. Purtroppo non ho potuto salvare
la stessa quantità di dati su entrambe le macchine perché su una delle due
non avevo a disposizione né tempo né librerie di misure adatte. Però devo
dire che i 60 MB del secondo esperimento mi sembravano una misura già
abbastanza significativa, specialmente con dei blocchi da 32 kB. E invece...
 
In entrambi i casi, lo spazio utilizzato su nastro è leggermente minore di
quello su disco (tra 6,5% e 10,5% in meno), ma non penso sia effetto di
alcun tipo di compressione, anche perché il calo avviene sempre. Piuttosto
penso che sia dovuto al fatto che mentre su disco gli oggetti devono essere
allineati a un "page boundary", su nastro sono invece tutti consequenziali e
senza spazio sprecato fra uno e l'altro e all'interno di ciascuno (credo).
 
Siamo mostruosamente off topic... :P
 
Ciao,
G.
 

 
Per quanto mi riguarda è interessantissimo, ma sono di parte ;)
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 


E' nato tutto da un dubbio di supervinx...:-)))
 
 
ciao
fm
 
 
 

 
E se non ci fosse qualcuno a sollevare dubbi, sai che noia !
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 In conclusione: NON COMPRIME MAI !
 
... Che è poi la cosa che ho detto pure io.
 
Il fatto che escludendo il blocco ottimizzato aumenti un po' l'occupazione
non mi soprende più di tanto, soprattutto considerando che certe strutture
interne magari non potranno essere a cavallo di due blocchi e/o che ogni
blocco avrà una specie di header all'inizio, quindi più blocchi, più header,
più spazio consumato. Se poi tieni conto anche di quanto spazio viene
sprecato nelle pagine che formano i descrittori di un salvataggio su nastro
(i quali hanno la stessa struttura di quelli di un SAVF, esclusi gli ultimi
16 byte che se non ricordo male sono un progressivo e un checksum), ecco che
si capisce come mai i dati salvati su nastro possano addirittura essere più
abbondanti della controparte su disco. In altri casi invece possono essere
leggermente inferiori. Insomma, ho l'impresssione che molto dipenda da come
si allineano contenuto e contenitore. E ho anche l'impressione che più
aumenta la quantità di dati salvati, più nel complesso aumenti lo scarto tra
occupazione su nastro e su disco, col nastro via via sempre più abbondante.
 
Questo per singole librerie. Salvando l'intero sistema la questione si
complica, perché nella percentuale di spazio occupato di un ASP ci sono
anche aree allocate ma vuote, tipo certe zone occupate dal LIC, che all'atto
del salvataggio non vengono considerate e generano un buon risparmio. :)
 
E poi comunque non siamo ancora sicuri al 100% che il dump del nastro fatto
da Supervinx sia corretto: magari è troncato o mancano dei pezzi. Per avere
qualche dato in più bisognerebbe vedere il DSPTAP di quel nastro e fare i
conteggi con quello.
 
Se avrò voglia e tempo, uno di questi giorni provo a porre la questione su
it.comp.as400 perché sono curioso di capire qualcosa di più di questo fatto.
 
Ciao,
G.
 

 G.
 
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 GO SAVE
 
Ma sì, alla fine sarà andato tutto bene, anche perché sbagliare un GO SAVE è
impossibile. Non c'è rischio di salvare meno di tutto. Però visto che ora è
nata questa disquisizione sui nastri e visto che i dati contenuti nel tuo
nastro sembrano ben meno di quanto occupato su disco, si potrebbe fare, con
molta calma, un DSPTAP con output in spool per vedere un po' quanta roba c'è
secondo OS/400 e confrontare il risultato con le dimensioni dell'immagine.
 
Nei prossimi giorni farò altri esperimenti. Vorrei capire come mai a noi lo
spazio occupato su nastro viene simile a quello su disco, mentre a te è
venuto ben diverso. Può anche darsi che la mia idea che ipotizza che un
salvataggio totale del sistema dia risultati così differenti a causa di aree
del disco preallocate ma vuote e quindi non salvate (ma conteggiate
nell'occupazione ASP) si riveli corretta. Del resto non si sa nulla di
ufficiale circa la gestione dello spazio riservato dal LIC per le sue cose.
 
Ciao,
G.
 

 venuto ben diverso.
 
IMVVHO...
 
Il parametro ACCPTH al release V5R4 e V6R1 ha come
default *SYSVAL ed il valore di default per il parametro
di sistema relativo e' "salvare".
Ovvero, a V5R4 e V6R1, se non specifichi diversamente,
nei comandi SAVLIB, SAVOBJ, etc ...
tutto va come se fosse ACCPTH(*YES).
 
Sul 150 V4R4,  presumibilmente anche sul V3R7,
invece il default e' ACCPTH(*NO).
Questo cambia radicalmente le cose.
 
Nel mio test  sul 150 (savlib di una libreria contenente  PF e LF)
 ho *erroneamente* considerato che lo spazio risparmiato
nel file su nastro fosse dovuto alla compressione,
invece era dovuto agli indici  non salvati.
 
La documentazione Ibm  non lascia dubbi:
la  cassetta DC6150 non ammette  compressione
nella 6382.
 
Nel salvataggio di supervinx, analogamente, ci sara'
una parte dello spazio "risparmiato" (circa 1Gb)
 che e' dovuta agli indici non salvati.
Si potrebbe verificare sul suo disco quanti LF
ci sono e di quale ampiezza.
 
Cmq, come te ho il dubbio che ci possano essere
altre entita' in gioco, oltre le code.
 
Resta poi da capire  come si possa comprimere
sulla DAT160, visto che, apparentemente,
 ne' io ne' te  ci siamo riusciti.
 
La domanda potrebbe esser posta nell'altro ng,
pero' con  grandissima cautela, diplomazia,  umiltà e deferenza ...:-)
 
ciao
fm
 
 
 
 
 
 
 


 
Questa della P e' la cosa meno chiara ....
Sto osservando un vecchio DSPTAP fatto a V4R4, nella 6382,
cassetta SLR5 formattata *QIC4DC...ci sono tre librerie,
una contenente files di dati,  le altre programmi etc.
Salvate con il solito SAVLIB ...nome libreria, TAP01 e tutto il resto di 
default.
Nemmeno una P....-)))
 
ciao
fm


 cautela, diplomazia,  umiltà e deferenza ...:-)
Per questo non mi azzardo a scrivere lì :P
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 
Abbi pazienza ... il disco contenente l'immagine del nastro è attualmente 
non collegabile, vedo se più tardi libero un box esterno...

 Questo cambia radicalmente le cose.
 
Vero, perņ nel CLP QMNSAVE č specificato ACCPTH(*YES), quindi nel caso
specifico del GO SAVE 21, anche il 150 con la V3R7 salva tutto. Quindi non
si spiega bene il calo, a meno che come ho ipotizzato (ma č tutto da
verificare), quando si fa un SAVSYS non entrino in gioco altre variabili.
 
Ciao,
G.

 Nemmeno una P....-)))
 
Secondo me la P compare quando l'unità supporta seriamente la compressione
hardware e accetta dal sistema operativo l'apposito comando SCSI, invece qui
parliamo di un'unità che NON supporta il parametro COMPACT, ma che fa una
compressione per conto suo se il nastro è inizializzato in un certo modo.
Peccato che i label non siano "inventati" dall'unità nastro, ma inviati dal
sistema operativo, il quale evidentemente decide di mettere quella P solo
quando gli risulta che l'unità accetti il parametro COMPACT.
 
In altre parole, cercare di capire come funziona tutta la faccenda basandosi
sui risultati ottenuti con uno degli unici due device che fanno eccezione,
cioè 6381 e 6382, non credo sia una pratica prudente. :PPP
 
Ciao,
G.
 


Abbiamo usato entrambi anche le  "moderne" unità DAT160
(quella che ho testato io e'  una 5619, con l'apposita cassettina Ibm) .
 
Si rifiutano pervicacemente di comprimere,  esattamente come l'anziana 
6382...???
 
Aspetto i tuoi esperimenti...:-).
 
ciao
fm 
 
 

 Aspetto i tuoi esperimenti...:-).
 
Stasera ho messo "a bollire" un SAVF non compresso da diversi GB, domani
sera vediamo. :)
 
G.