Newsgroup: it.comp.retrocomputing
Titolo: AS/400 disks

Apro un nuovo thread per motivi di ... indentazione ;)
Riassumo, così mi schiarisco le idee.
Le unità attuali sono DD001 e DD003.
Ho scoperto che ogni volta si inserisce un'unità non configurata, il
numero aumenta.
DD001, secondo la tabella all'interno del case, ha ID1, mentre
DD003 ha ID3 (SCSI 4). Sì. gli ID non corrispondono agli ID SCSI.
Ho aggiunto un'unità, con ID2 (SCSI 5), con i seguenti risultati.
27H1712 (2GB) visibile, operativo ed aggiungibile all'ASP
27H1711 (4GB) visibile, non operativo, non aggiungibile
27H1711 (4GB) visibile, non operativo, non aggiungibile
Per non operativo, intendo che risulta protetto in lettura e
scrittura, mentre il jumper write protect è assente.
 
Attualmente siamo a DD007.
Devo pensare che sia esistito un DD002, e poi sostituito dal DD003
attuale ?
---------------------------------------------------------------------------------------------
La faccenda si complica e si fa interessante.
Ho montato su di un'altra macchina un 27H1711 nuovo (si fa per dire) e
quello problematico secondo OS/400.
 
Entrambi hanno superato senza problemi il test di verifica (Verify
Media) della scheda Adaptec. Strano. Mi sarei aspettato dei problemi
per il DD003.
Adesso sto riformattando il nuovo a 520bytes/sector (mediante
setblocksize) e riproverò ad inserirlo nel 150.
 
Non ci sono problemi di ID duplicati o altro, visto che il 27H1712 è
visto ed è operativo.
 
Fra l'altro, sto sostituendo un 27H1711 con uno uguale e con seriale
molto vicino, identificativo vendor IBMAS400.
 
E se fosse il connettore del cavo ? Domani, con la luce, lo esamino a
fondo...

Non sono stato chiaro...
Ovviamente ho inserito un disco "nuovo" per volta (aggiungendolo ai
due preesistenti), sono partito con IPL manuale e poi DST ...
I dischi erano sempre ad ID2 (SCSI 5).
Il problema è solo per i due dischi da 4GB.

Mi rispondo da solo, visto che ho risolto...
I dischi 27H1711 hanno provenienza ignota, per cui qualcuno deve averci giocato ;)
Dopo la riformattazione a 520bytes/sector con setblocksize (linux) è stato 
felicemente catalogato come non configurato/operativo dall'AS/400.
Adesso è tardi per tentare l'aggiunta e rimozione dall'ASP.
Una domanda: una volto aggiunto il nuovo e rimosso il vecchio, lascio l'ID 
che c'è oppure al nuovo devo assegnare l'ID del vecchio ?
------------------
Mi rimane sempre il dubbio del perché la verifica di superfice abbia dato 
esito positivo su quello identificato come "errore DASD imminente", fin dal
2008. Non posso aver sbagliato disco in quanto il seriale e l'ID coincidono.
DD003 ha ID3 secondo DST ed SST.
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 


non sarebbe la prima volta che un disco definito malfunzionante,
collegato ad hardware diverso superi dei test (fatti con hw e sw diversi).
 
Certamente lo hai collegato anche con un CAVO diverso,
 
(col 150 il dubbio sul cavo scsi e i connettori c'e' sempre....se ricordi lo 
avevo scritto un
bel po' di post fa)
 
 
ciao
fm 
 
 

attuale ?
 
sicuramente. L'assassino ha lasciato una traccia......:-)
 
ciao
fm
 
 

 fondo...
 
Potresti assicurarti che il connettore non sia ossidato e che sia crimpato
a dovere sul cavo, dubito che fosse semplicemente infilato male in quanto
te ne saresti accorto smontando il disco. Al limite il cavo puoi sempre
sostituirlo se dovesse presentare simili problemi anche col nuovo disco.
 
-- 
member of the italian hobbyist DECnet network - 
decnet.ipv7.net
 
www.unsupported.info
 - 
img.unixantichrist.net
 

La verifica l'ho fatta prima di qualsiasi altra operazione: il BIOS
Adaptec sembra aver gestito sia i 520 che i 512 bytes/sector.
 
Poi ho utilizzato setblocksize sul disco identificato come protetto il
lettura/scrittura ed ho effettuato (di nuovo) la verifica.
 
Non credo che la verifica riallochi settori, per cui o il problema al
disco è saltuario oppure c'è un'altra spiegazione.
 
I messaggi d'errore, "Contattare il servizio assistenza" per l'unità
DD003 risalgono al 2008 (anno della probabile dismissione), mentre il
messaggio "Errore imminente DASD" è capitato a me...

Perché non riesco a cancellare i messaggi da WRKPRB ?
Ho chiuso i problemi, e mi dice che è impossibile rimuovere il record.
 
Ho provato con DLTPRB, e risponde
"Sono stati cancellati 0 record relativi al problema."

news:a1de2cd7-2ca3-4093-9191->ddb591...@a5g2000vbc.googlegroups.com...

spariscono  automaticamente dopo tot giorni.
 
ciao
fm 
 
 


Ah, ecco...
Il primo DLTPRB aveva cancellato solo i files del 2008...
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

Per adesso non effettuo lo spostamento.
Disossido cavi e connettori, e lo uso intensamente.
Al primo messaggio di sistema sposto (tanto ho il backup).
 
-- 
http://www.supervinx.com/Retrocomputer
 


come si farebbe (eventualmente) a disossidare?
forse spruzzando uno spray apposito e poi lasciando
asciugare?
 
ciao
fm
 
 
P.S.
 ho trovato due vecchi dischi di AS/400
uno e' un 27H1711 come il tuo.
IBM DHGS..... 1995...:-(((
e poi un'etichetta strana:
master disk....V4R3M0... 07/23/1999
 
"master disc"... ???
 
L'altro e'  piu' strano perche' non e'  Ibm
ma addirittura un Quantum 4.3 Gb con tanto di
Ibm p/n etichettato sopra...:-)
 
 
 

 4.3 Gb con tanto di Ibm p/n etichettato sopra...:-)
Non mi stupisce... ho una vagonata di HD etichettati IBM di varia natura, 
SCSI e non.
 
Pensa che in garage ho trovato una decina di dischi ottimi candidati per AS/400.
La maggior parte, però, non sembra superare il GB.
Devo provarli adesso, per vedere come si fanno identificare.
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 


 
Non Ibm?...o anche Ibm ma non AS/400?....
...non dovrebbe riconoscerli.
 
O almeno questa e' la voce che e' sempre circolata....
anche fra i tecnici della manutenzione non Ibm ...
 
Prova.
 
ciao
fm 
 
 


Tutti IBM e tutti con la fascia in rame ;)
Dall'aspetto e dai codici sembrano proprio tutti per AS400.
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 messaggio "Errore imminente DASD" è capitato a me...
 
Considerando che hai dei dischi con cui rimpiazzarlo potresti tenerlo 
fuori dal sistema come spare da usare in casi di emergenza, marcandolo 
come "poco affidabile", certo sarebbe piu rassicurante individuare il 
problema.


 4.3 Gb con tanto di Ibm p/n etichettato sopra...:-)
 
Come avevo indicato in un altro post IBM ha usato anche dischi della 
"concorrenza" nei loro sistemi, hanno p/n ibm e si identificano comunque 
come ibmas400, ma sono appunto quantum, seagate, fujitsu, e probabilmente
anche altro, a seconda evidentemente di quella che era la disponibilita' 
al momento.
Nel mio -150 c'e' almeno un quantum, nel -170 un seagate.


 anche fra i tecnici della manutenzione non Ibm ...
 
Lasciamo perdere le voci, abbiamo fatto tutte le prove possibili (e non 
solo con i dischi), i dischi per as/400 (ibm o non) si identificano in 
modo particolare e hanno dati specifici nel vpd (
http://en.wikipedia.org/
 
wiki/Vital_Product_Data ma date anche un occhio alle specifiche scsi dove 
e' previsto un bit apposito per segnalare la presenza di dati nel vpd 
oltre ai soliti parametri di identificazione del disco) che ne permettono 
il riconoscimento.
 
Non e' possibile usare dischi non as/400 in un sistema as/400, inutile 
tentarci perche il sistema se non trova i dati nel vpd, e dati corretti, 
non riconosce il disco come suo.



quindi  se il disco di supervinx ritornera' a funzionare in AS400
significa che forse ci hanno giocato( formattazione etc) ma non
toccato  il vpd ... una EEPROM?..
 
ciao
fm
 
 

 vecchio ? piu recente ? riesci a dirmi la versione del bios ?
2940uw
Per il la versione del BIOS devi aspettare il prossimo riavvio.
Non posso aprire facilmente il PC (è incastrato) ed è impegnato in uno 
scaricamento (patches ;) )

 da 512, 
Ha effettuato la verifica del disco "sospetto" senza lamentarsi.
Ti fornisco i dettagli.
BIOS Adaptec:
Controllo di parità disabilitato (l'HD per AS/400 è così configurato).
Send start unity command.
 
Gli HD 27H1711 impiegano più tempo degli altri per l'identificazione e l'avvio.
Vendor ID: IBMAS400
CTRL-A menu ... etc...
Di solito, quando provo gli HD identici, non riavvio la macchina, ma eseguo una
sostituzione a "caldo", rimuovendo prima l'alimentazione e poi il cavo dati.
A quel punto reinserisco prima il cavo dati e per ultima l'alimentazione.
Bene... dopo il disco sospetto, ho inserito in questo modo uno dei dischi di riserva.
 
Con questa operazione, il disco non si identifica più come
 
IBMAS400 DHFS4W
 
ma
 
IBM DHCS.
 
Il successivo tentativo di verifica fallisce.
Dopo un power cycling del PC (non dell'HD) tutto torna normale, identificazione
e verifica della supericie.
 
Bestie strane...

 il vpd ... una EEPROM?..
 
Il VPD fa' parte dei valori memorizzati nella flash contenente il 
firmware dl disco, non e' possibile modificarli in alcun modo senza 
riflashare il firmware stesso del disco.
In sostanza e' impossibile trovare un disco per as400 a cui sia stato 
rimosso e/o modificato il VPD, quindi e' sempre possibile riutilizzarli
nel 400 (previa impostazione della corretta dimensione dei settori).
Per contro non e' possibile utilizzare un disco standard e modificarlo
per funzionare su un 400, bisognerebbe modificare il firmware con i
giusto valori nel vpd, al piu' potrebbe essere praticabile dumpare un
firmware da un disco as400 e flasharlo sul equivalente non-400.
Non e' una cosetta che si fa' su due piedi (anche perche non mi risultano
tool che permettano il dump del firmware dai dischi, bisogna dissaldare
la flash e leggersela in un programmatore di eprom).


 Bestie strane...
 
Diciamo pure che lo scsi e' standard ma giusto sulla carta, ci sono una
quantita' di situazioni in cui si verificano di questi "problemi" 
misteriosi.



altro problema, da lato AS400, e'  quello dei modelli di disco
riconosciuti.
il 150 ammette 6606 e 6607....avete provato dischi piu' grandi?
ad esempio i dischi  da 8Gb...come il  6713?
 
Se non ci vanno ...la dimensione massima  resta 16Gb ...(4 hd 6607)
 
ciao
fm 
 
 

 attuale ?
 
Sì, probabile. Quello che vedi aumentare ogni volta che fai manovre è il
cosiddetto nome risorsa che lui usa per identificare i vari componenti
hardware e che tu puoi vedere con DSPHDWRSC. I device tipo TAP02 di solito
vengono creati automaticamente, ma se tu li volessi creare a mano, e in
certi casi è necessario, dovresti associare a un nome device un nome
risorsa. Io sul mio P03 ho solo TAP01 che corrisponde all'unità nastri
esterna, ma se vado a vedere, il nome risorsa corrispondente credo che abbia
superato già da un po' TAP010, a forza di fare manovre e di dimenticarmi di
accendere l'unità prima della macchina... :)
 
Ciao,
G.
 

 che c'è oppure al nuovo devo assegnare l'ID del vecchio ?
 
Lascia pure quello che c'è, anzi non vorrei che cambiandogli ID poi faccia
storie e dica che quel disco non fa (più) parte dell'ASP...
 
Ciao,
G.
 

 Il primo DLTPRB aveva cancellato solo i files del 2008...
 
Sě, c'č un intervallo minimo di conservazione che di default č impostato a
30 giorni ed č memorizzato nel valore di sistema QPRBHLDITV (Problem hold
interval). Se proprio vuoi fare piazza pulita, metti quel valore a 0, vai
con DLTPRB e poi rimettilo a 30.
 
Mi sorprende che ci fossero dei problemi del 2008, avrei scommesso che la
pulizia automatica li eliminasse una volta passati i 30 giorni. Mah, forse
mi ricordo male io oppure la pulizia č stata impostata diversamente.
 
Ora non ho voglia di verificare come gira la faccenda... :)
 
Ciao,
G.
 

 ad esempio i dischi  da 8Gb...come il  6713?
 
Uhm, ora non mi ricordo bene, ma da un cliente che gira ancora su 150 hanno
avuto problemi con i dischi e quando si parlava di sostituirli con dischi
piů capienti č venuto fuori che sul 150 non si possono mettere quelli da 17
GB e oltre per problemi di temperatura, quindi il massimo installabile
rimangono quattro dischi della taglia precedente. Ora non ricordo, ma mi
pare che fossero dischi da 8 GB. Non mi sembra ce ne fossero da 10-12.
 
Quindi il massimo sarebbero 32 GB spalmati su quattro dischi da 8. Anzi, ora
che ci penso mi sa che fosse cosě, infatti questo cliente con quattro dischi
arrivava a 16 GB in tutto, dato che li aveva in mirror a coppie.
 
Ciao,
G.
 

 DD003 ha ID3 secondo DST ed SST.
 
Come diceva Sadness, lo SCSI č standard solo sulla carta, e quando poi ci si
addentra nelle cose IBM la situazione si complica ulteriormente. Quindi
rimane un mistero. L'unica cosa che avevo pensato, ma di cui non sono piů
molto sicuro dopo aver letto tutto il botta-e-risposta tra te e lui, č che
forse l'AS/400 č piů "prudente" e segnala problemi in base a certe sue
statistiche che invece non allarmano il resto del mondo.
 
Oppure, ma qui forse si va nella fantascienza, nella flash personalizzata
IBM non ci sono solo le stringhe identificative specifiche per far piacere
il disco a OS/400, ma c'č anche del codice apposta che dialoga con quello
dell'adapter dell'AS/400, il quale codice magari fornisce statistiche
ulteriori e/o routine diagnostiche in grado di rilevare diversamente o con
piů precisione/anticipo i problemi del disco, e trattandosi di roba extra,
fuori da qualunque standard, non viene rilevata dal BIOS Adaptec.
 
Che ne dite?
 
Ciao,
G.
 

 Che ne dite?
 
Che non e' parte del VPD (sono pochi bytes e contengono unicamente 
informazioni di riconoscimento), ma appunto il firmware potrebbe 
implementare il PFA (o una sua variante) quindi il discorso di 
"ulteriori" routine diagnostiche interne al disco e' possibile (il PFA 
questo e' in sostanza).


 Ora non ho voglia di verificare come gira la faccenda... :)
 
I problemi del 2008 erano contrassegnati come OPEN.
Credo sia quello il motivo della loro permanenza.
 
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 Credo sia quello il motivo della loro permanenza.
 
Oppure in GO CLEANUP opzione 1 c'è *KEEP per la voce Giornali di sistema e
registrazioni di sistema...
 
G.

 Nel mio -150 c'e' almeno un quantum, nel -170 un seagate.
 
Ricordo male o l' IBM aveva ceduto l' intero suo settore HD una diecina 
di anni fa ?
 
Saluti,
dott. Piergiorgio.

 
1.23
 
Effettivamente, il disco non gode di ottima salute...
# sginfo -g /dev/sg4
 
INQUIRY response (cmd: 0x12)
----------------------------
Device Type                        0
Vendor:                    IBMAS400
Product:                   DFHSS4W         
Revision level:            5959
 
Defect Lists
------------
 
7 entries (56 bytes) in grown (GLIST) table.
Format (4) is: bytes from index [Cyl:Head:Off]
Offset -1 marks whole track as bad.
 
  1717:  0:   26361|    84:  0:   31059|  1715:  2:   81693|  1717:  0:   28449
   313:  0:   81693|  2009:  0:   78561|  2025:  0:   80127|
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

Ma quello di scorta è ancora peggio !
 
# sginfo -G /dev/sg4
 
INQUIRY response (cmd: 0x12)
----------------------------
Device Type                        0
Vendor:                    IBMAS400
Product:                   DFHSS4W         
Revision level:            5353
 
Defect Lists
------------
 
10 entries (80 bytes) in grown (GLIST) table.
Format (4) is: bytes from index [Cyl:Head:Off]
Offset -1 marks whole track as bad.
 
  3907:  8:   33540|  3907:  8:   34060|  3907:  8:   33020|  3907:  8:   33540
  4096:  8:    4420|  4096:  8:    4940|  3556:  8:   49660|  3556:  8:   50180
  3720:  6:   43940|  3720:  6:   44460|
 
LOL !
 
Non mi resta che analizzare il terzo 
(domani, perché devo smontare il cestello)
 
Dunque l'AS/400 si preoccupa dei settori difettosi con largo anticipo...
A proposito, gli IPL sono sempre più veloci, e sono un paio di volte che è 
sparito il codice A6001730...
 
-- 
http://www.supervinx.com/Retrocomputer
 

 di anni fa ?
 
2001/2002 grossomodo, ma -150 e -170 sono sistemi introdotti molto prima 
della vendita del settore dischi (intorno al 1998, entrambi).


 7 entries (56 bytes) in grown (GLIST) table.
 
Beh sono solo sette, per capire se il disco andra' a peggiorare 
bisognerebbe vedere se tendono ad aumentare con l'utilizzo, potrebbero 
rappresentare un singolo evento "traumatico" nella vita del disco oppure 
essere segno di un deterioramento progressivo di piatti e/o testine.
Nel primo caso potrebbe essere un disco riutilizzabile in caso di 
necessita' (ovviamente per sistemi non critici), nel secondo caso puo' 
venire utile unicamente come fornitore di ricambi.
 
(ed in effetti se tu avessi un disco identico ma non per as400 potresti 
provare a swappare la logica con questo)


Ho controllato entrambi i dischi anche con smartctl, e non segnala nulla di 
anomalo (ad esempio FAILURE PREDICTION THRESHOLD EXCEEDED) in SMART Health Status.
sg_logs restituisce questi valori, per il disco segnalato come "sospetto" da
OS/400:
 
 
Write error counter page
  Total rewrites or rereads = 0
  Total errors corrected = 0
  Total uncorrected errors = 0
  Reserved or vendor specific [0x8000] = 0
  Reserved or vendor specific [0x8001] = 0
 
Read error counter page
  Errors corrected without substantial delay = 0
  Total rewrites or rereads = 1501
  Total errors corrected = 0
  Total uncorrected errors = 0
  Reserved or vendor specific [0x8000] = 0
  Reserved or vendor specific [0x8002] = 0
 
Verify error counter page
  Errors corrected without substantial delay = 0
  Total rewrites or rereads = 0
  Total errors corrected = 0
  Total uncorrected errors = 0
 
Non è certo nuovo, ma non sembra così messo male. Quello che non sappiamo,
è il tasso di crescita dei difetti.
 
Probabilmente OS/400 è conservativo e consiglia *caldamente* la sostituzione.
 
Ho avuto, ed ho, dischi in condizioni peggiori.
 
Poiché i 6607 scaldano molto, perché non è stata prevista una 
ventola sul frontale ?
-- 
http://www.supervinx.com/Retrocomputer
 

Dimenticavo...
Nel cosro della discussione, è stato sostenuto che OS/400 dovrebbe disabilitare
la riallocazione automatica delle aree difettose.
Se così fosse, dal momento che un difetto finisce nella "grown list" solo se
è stato riallocato, lo scenario dovrebbe essere il seguente:
 
OS/400 disabilita la riallocazione automatica
 
OS/400 riceve la notifica dell'errore da parte del disco
 
OS/400 notifica all'operatore di sistema l'errore e/o la necessità di intervento
 
OS/400 rialloca l'area difettosa
 
 
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 sul frontale ?
 
Evidentemente la temperatura dei dischi rimane nel range operativo che 
IBM ritiene accettabile.
Il -150 poi era macchina per sviluppatori (tra le altre cose) e dovrebbe
essere previsto l'impiego dello stesso al di fuori di un ced condizionato.



E' probabile che la cosa vari a seconda della release del os e 
probabilmente anche del hw su cui viene fatto girare (mi aspetto ad 
esempio un comportamento diverso sui sistemi con raid hw in cui 
interviene anche il firmware del controller stesso).
Per esperienza diretta ho verificato che, a questo punto almeno in alcuni 
setup, OS/400 non rialloca i settori danneggiati.
Questo potrebbe anche dipendere dal area in cui i settori si trovano (ad 
esempio la parte critica con il microcode) oppure da particolari 
configurazioni del ASP.
 
E' abbastanza chiaro che sul tuo -150 con la v3r7 qualcuno i settori li 
ha riallocati, e dato che ti sei limitato a querare con sginfo il disco 
direi che questo qualcuno non puo' che essere il 400 stesso.
 
E visto che parliamo di ibm e as400 una spiegazione chiara e definitiva 
sul funzionamento non la avremo mai, proporrei di tirare una monetina per 
stabilire chi rialloca cosa.
 
Certo con i settori riallocati e il disco che non presenta alcun difetto 
non si spiega l'IPL lunghissimo che ti sei dovuto sorbire, o meglio, 
bisognerebbe ricercare la spiegazione lato software (ricostruzione 
indici ?) piuttosto che in un problema hardware come ipotizzato.



Certamente.
Ne sono stati venduti moltissimi a piccole aziende,
e furono  usati come normali server tower  negli uffici.
Con un vantaggio non da poco:
la presenza di una sola ventola posteriore di grossa
dimensione fa  si' che il 150 sia  decisamente
silenzioso. Mai sentito di problemi di temperatura.
 
ciao
fm
 
 

 indici ?) piuttosto che in un problema hardware come ipotizzato.
 
Il famoso IPL lunghissimo è avvenuto in queste condizioni:
 
1) batteria *completamente* scarica
 
2) azzeramento di tutte le code tramite IPL manuale
 
3) sostituzione della batteria
 
4) avvio normale
 
5) attesa lunghissima in corrispondenza di "inizializzazione spool"
 
Al termine di questa fase, ho ricevuto il messaggio "Errore DASD imminente,
*CRITICAL", 
ripetuto una volta durante il salvataggio su DDS-2, insieme ad un paio di 
"contattare l'assistenza *BREAK", ma il backup è avvenuto senza problemi.
 
Da allora, è scomparso il codice A6001730 e gli IPL durano meno di dieci minuti.
La parte più lunga è rappresentata dai test iniziale. 
Dal caricamento effettivo di OS/400 (C6XX) alla comparsa del login screen non
passano più di un paio di minuti.
 
Dato che *non* è un sistema in produzione, mi posso tranquillamente accontentare.
Ad un amico *in produzione* (una banalissima WS HP Intel based)
ho sostituito parti hardware per molto meno.
Io ho un HD Maxtor da 80 GB, con un'area danneggiata piuttosto estesa ed in crescita.
Circa cinque anni fa ho isolato la porzione "guasta" (una partizione nascosta), 
trasformandolo in 60GB, e da allora lavora felicemente :)
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

Ho esaminato un HD di questo lotto "probabili AS/400".
Vendor IBMAS400 DHFS2W, 2GB
La verifica Adaptec inizia, intorno il 30%, a sfornare settori da riallocare.
Lo riformatto un paio di volte.
Ad ogni verifica si aggiungono altri settori.
Ho interrotto al 40%, con già 110 voci nella grown list.
Se assumiamo come limite massimo lo 0.01%, una HD da 2.1GB non 
dovrebbe riallocare più di 440 settori (circa). Considerate che la
defect list del produttore è non vuota...
Questo sì che è inaffidabile :D
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

Esaminato l'ultimo 27H1711.
Non s'avviava neanche.
Dopo qualche "delicata" manovra è partito, ed ha faticato non poco prima
d'esser riconosciuto.
Grown defect list: 4
Dopo la riformattazione ed il successivo setblocksize a  520bytes/sector
i difetti sono saliti a 10.
A conti fatti tengo il disco originale ;)
 
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 A conti fatti tengo il disco originale ;)
 
La tua collezione di dischi spare s'e' drasticamente ridimensionata.
Inizierrai anche tu a dare la caccia ai dischi per 400 come tutti noi
sfigati possessori dei monoliti neri.
Intanto divertiti con l'installazione delle ptf :)


 l'installazione delle ptf :)
 
Non posso lamentarmi troppo.
Ecco i risultati:
2 27H1711 (4GB) con 10 settori riallocati
 
1 27H1712 (2GB) con  0 settori riallocati
 
1    0662 (1GB) con  0 settori riallocati
 
2    0661 (320MB) da provare: mancano del jumper per la terminazione, devo
usare un cavo terminato, e per cambiarlo devo smontare il PC (ho portato dalla 
2940UW due cavi, uno SCSI50 ed uno SCSI68 fuori attraverso uno slot per CD sul frontale,
ma sono cavi non terminati).
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer