AS/400 disks

[supervinx]

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...

[supervinx]

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.

[supervinx]

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

[fm]

"supervinx" <nes...@libero.it> ha scritto nel messaggio
news:jo4dtu$am4$1...@tdi.cu.mi.it...

> 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 ?

non c'e' necessita' di farlo.

> ------------------
> 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.
>

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

[fm]

>Attualmente siamo a DD007.
>Devo pensare che sia esistito un DD002, e poi sostituito dal DD003
>attuale ?

sicuramente. L'assassino ha lasciato una traccia......:-)

ciao
fm

[sadness]

On Sat, 05 May 2012 16:01:38 -0700, supervinx wrote:

> Entrambi hanno superato senza problemi il test di verifica (Verify
> Media) della scheda Adaptec. Strano. Mi sarei aspettato dei problemi per
> il DD003.

Per fare la scansione della superfice avrai dovuto riformattare il disco
con b/s=512, lo hai fatto dal bios del adaptec stesso ? se si la
soluzione al mistero e' semplice, quando formatti il disco il bios del
adaptec provvede automaticamente a rimappare eventuali settori
danneggiati (senza avvisare), di conseguenza la successiva scansione
della superfice non rilevera' alcun tipo di problema.
E' anche possibile che la stessa cosa (la rimappatura dei settori
danneggiati) sia stata effettuata durante la conversione 520-512 fatta
con altri tool, come dicevo e' il 400 che pare disabilitare appositamente
questa funzione dei dischi.

Dovresti chiedere al disco di mostrarti l'elenco dei settori rimappati
(sginfo -G, display grown defect list).
Se propio non rilevi nulla di anomalo rimane un possibile problema al
cavo e/o al alimentazione dei dischi.

> E se fosse il connettore del cavo ? Domani, con la luce, lo esamino a
> 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

[supervinx]

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...

[supervinx]

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."

[fm]

>"supervinx" <supe...@libero.it> ha scritto nel >messaggio
>news:a1de2cd7-2ca3-4093-9191->ddb591...@a5g2000vbc.googlegroups.com...

spariscono automaticamente dopo tot giorni.

ciao
fm

[supervinx]

Ah, ecco...
Il primo DLTPRB aveva cancellato solo i files del 2008...



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

[supervinx]

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

[fm]

"supervinx" <nes...@libero.it> ha scritto nel messaggio
news:jo5pnv$hus$3...@tdi.cu.mi.it...

> Per adesso non effettuo lo spostamento.
> Disossido cavi e connettori, e lo uso intensamente.
> Al primo messaggio di sistema sposto (tanto ho il backup).
>

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...:-)

[supervinx]

Il Sun, 06 May 2012 14:21:33 +0200, fm ha scritto:

> "supervinx" <nes...@libero.it> ha scritto nel messaggio
> news:jo5pnv$hus$3...@tdi.cu.mi.it...
>> Per adesso non effettuo lo spostamento. Disossido cavi e connettori, e
>> lo uso intensamente. Al primo messaggio di sistema sposto (tanto ho il
>> backup).
>>
> 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...:-(((

Tutti i 27H1711 miei (tre) sono targati 1995...

> e poi un'etichetta strana:
> master disk....V4R3M0... 07/23/1999
>
> "master disc"... ???
>

Forse perché c'era installato OS/400 ?

> L'altro e' piu' strano perche' non e' Ibm ma addirittura un Quantum
> 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

[fm]

CUT

> Forse perché c'era installato OS/400 ?

penso proprio di si, visto che sono nelle slitte tipiche delle macchine
come il 170 ed il 600...

>
>> L'altro e' piu' strano perche' non e' Ibm ma addirittura un Quantum
>> 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.
>

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

[supervinx]

>
> Non Ibm?...o anche Ibm ma non AS/400?.... ...non dovrebbe riconoscerli.
>
>

Tutti IBM e tutti con la fascia in rame ;)
Dall'aspetto e dai codici sembrano proprio tutti per AS400.



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

[sadness]

On Sun, 06 May 2012 03:41:02 -0700, supervinx wrote:

> La verifica l'ho fatta prima di qualsiasi altra operazione: il BIOS
> Adaptec sembra aver gestito sia i 520 che i 512 bytes/sector.

Questo e' abbastanza strano, ricordo per certo che il bios degli adaptec
non sono in grado di fare la verifica dei dischi con blocksize diverso
da 512, per curiosita', quale controller hai utilizzato ? 2940uw ? piu
vecchio ? piu recente ? riesci a dirmi la versione del bios ?

> 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.

La verifica ti chiede se vuoi riallocare i settori man mano che rileva
settori danneggiati, quindi te ne saresti accorto (dato che non procede
finche non confermi cosa vuoi fare)

Effettivamente e' abbastanza singolare, dato il messaggio di errore (e
considerando anche alcuni degli ipl lunghissimi del sistema) mi sarei
aspettato almeno qualche settore danneggiato.
E' anche vero che su qualche disco mi sono capitati dei settori che
probabilmente avevano dei problemi "soft", avevo errori di lettura ma a
tutti gli effetti i settori, a disco riformattato, non avevano problemi.
(ho anche incrociato un paio di dischi completamente inutilizzabili che
risultano in perfetto ordine ad una scansione della superfice e che dopo
una riformattazione dal solito 2940uw sono tornati in perfetta efficenza,
ne ho uno dentro la Octane, preso per morto, che ormai funziona da anni
con un utilizzo anche molto pesante, senza il minimo problema, nessun
errore smart, nessun settore danneggiato o riallocato)

> 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...

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.

[sadness]

On Sun, 06 May 2012 14:21:33 +0200, fm wrote:

> come si farebbe (eventualmente) a disossidare?
> forse spruzzando uno spray apposito e poi lasciando asciugare?

Per i connettori in questione dove e' impossibile usare qualche tipo di
azione meccanica per rimuovere l'ossido l'unica via e' l'uso di un
disossidante secco (spray) per rimuovere l'ossido. Ottimo il Philips (mi
sembra il 390dcs) o anche i prodotti della due-ci eletronics.

> L'altro e' piu' strano perche' non e' Ibm ma addirittura un Quantum
> 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.

[sadness]

On Sun, 06 May 2012 15:21:13 +0200, fm wrote:

> 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 ...

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.

[fm]

"sadness" <tr...@unsupported.info> ha scritto nel messaggio
news:jo5v49$ak9$4...@tdi.cu.mi.it...

> On Sun, 06 May 2012 15:21:13 +0200, fm wrote:
>
>> 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 ...
>
> 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

[supervinx]

Il Sun, 06 May 2012 13:35:01 +0000, sadness ha scritto:

> On Sun, 06 May 2012 03:41:02 -0700, supervinx wrote:
>
>> La verifica l'ho fatta prima di qualsiasi altra operazione: il BIOS
>> Adaptec sembra aver gestito sia i 520 che i 512 bytes/sector.
>
> Questo e' abbastanza strano, ricordo per certo che il bios degli adaptec
> non sono in grado di fare la verifica dei dischi con blocksize diverso
> da 512, per curiosita', quale controller hai utilizzato ? 2940uw ? piu
> 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 ;) )

[supervinx]

>Questo e' abbastanza strano, ricordo per certo che il bios degli adaptec
> non sono in grado di fare la verifica dei dischi con blocksize diverso
> 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...

[sadness]

On Sun, 06 May 2012 16:14:22 +0200, fm wrote:

> 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?..

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).

[sadness]

On Sun, 06 May 2012 14:41:56 +0000, supervinx wrote:


> Ha effettuato la verifica del disco "sospetto" senza lamentarsi.
> Ti fornisco i dettagli.
> BIOS Adaptec:

Fammi sapere la versione.

> Controllo di parità disabilitato (l'HD per AS/400 è così configurato).
> Send start unity command.

Ininfluente per quel che riguarda la questione sector size.

> Gli HD 27H1711 impiegano più tempo degli altri per l'identificazione e
> l'avvio. Vendor ID: IBMAS400 CTRL-A menu ... etc...

Sono decisamente piu' lenti a rispondere ai comandi dopo il reset e
successiva scansione del bus scsi, lo avevo gia' sperimentato (come loro
anche molti altri dischi).

> 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.

E' un operazione che eseguo anche io, e anche con dischi diversi, swappo
il disco ed eseguo una nuova scansione del bus scsi dal bios del
controller (se esce dalle utility di scansione/formattazione e rientri
lui rifa' la scansione del bus), nel 99% dei casi non ci sono problemi.

> 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.

Ricadra' in in quel 1% di casi in cui il controller non riesce a
identificare correttamente il disco senza essere resettato, potrebbe
anche essere un bug del bios ma e' un dettaglio.

> Dopo un power cycling del PC (non dell'HD) tutto torna normale,
> identificazione e verifica della supericie.
>
> 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.

[fm]

"sadness" <tr...@unsupported.info> ha scritto nel messaggio

news:jo65if$ak9$5...@tdi.cu.mi.it...

> On Sun, 06 May 2012 16:14:22 +0200, fm wrote:
>
>> 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?..
>
> 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.

cut
>
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

[ger...@no.spam.mail.com]

On Sat, 5 May 2012 16:01:38 -0700 (PDT), supervinx <supe...@libero.it>
wrote:

> Ho scoperto che ogni volta si inserisce un'unità non configurata, il
> numero aumenta.

> [...]

> Attualmente siamo a DD007.
> Devo pensare che sia esistito un DD002, e poi sostituito dal DD003
> 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.

[ger...@no.spam.mail.com]

On Sat, 5 May 2012 23:42:55 +0000 (UTC), supervinx <nes...@libero.it>
wrote:

> 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 ?

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.

[ger...@no.spam.mail.com]

On Sun, 6 May 2012 12:09:25 +0000 (UTC), supervinx <nes...@libero.it>
wrote:

> 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.

[ger...@no.spam.mail.com]

On Sun, 6 May 2012 17:56:03 +0200, "fm" <f...@tin.it> wrote:

> 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?

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.

[ger...@no.spam.mail.com]

On Sat, 5 May 2012 23:42:55 +0000 (UTC), supervinx <nes...@libero.it>
wrote:

> 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.

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.

[sadness]

On Sun, 06 May 2012 20:30:11 +0200, gerry77 wrote:

> 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.

Senza che ci addentriamo in cose troppo fantasiose, una cosa che non ho
scritto precedentemente ma a cui stavo pensando, e' che IBM e' stata
forse la prima ad implementare un sistema simil-smart nei loro dischi
scsi, a cominciare dai vecchi 0662, tecnologia chiamata PFA (predictive
failure analysis), non mi risulta sia particolarmente documentata e al
contrario dello smart non forniva una serie di parametri ma semplicemente
un allert "generico" al sistema.
Non so quali parametri monitorasse il disco, non so nemmeno se poi sia
stata implementata su tutti i dischi a seguire dopo i vecchi 0662, ma
potrebbe essere la spiegazione del problema in questione, potrebbe aver
rilevato una quantita eccessiva di retry del disco in lettura o scrittura
o altri tipi di errori e quindi aver alzato l'allert al sistema.

> 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?

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).

[supervinx]

> 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... :)

I problemi del 2008 erano contrassegnati come OPEN.
Credo sia quello il motivo della loro permanenza.





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

[ger...@no.spam.mail.com]

On Sun, 6 May 2012 20:03:26 +0000 (UTC), supervinx <nes...@libero.it>
wrote:

> I problemi del 2008 erano contrassegnati come OPEN.
> 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.

[dott.Piergiorgio]

Il 06/05/2012 15:39, sadness ha scritto:

>> L'altro e' piu' strano perche' non e' Ibm ma addirittura un Quantum
>> 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.

Ricordo male o l' IBM aveva ceduto l' intero suo settore HD una diecina
di anni fa ?

Saluti,
dott. Piergiorgio.

[supervinx]

>> BIOS Adaptec:
>
> Fammi sapere la versione.
>

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

[supervinx]

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

[sadness]

On Mon, 07 May 2012 00:38:23 +0200, dott.Piergiorgio wrote:

>> 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 ?

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

[sadness]

On Sun, 06 May 2012 22:48:37 +0000, supervinx wrote:

>>> BIOS Adaptec:
>>
>> Fammi sapere la versione.
>>
> 1.23

Interessante, se non erro la primissima release del bios dei 2940uw, non
credo di aver mai sperimentato l'accoppiata dischi da 520b/s e bios 1.23,
dato che aveva molte rogne aggiorno sempre tutti i 2940uw di casa (e
tanti ne ho / ho avuto) al ultimissima release.

> Effettivamente, il disco non gode di ottima salute...

[...]

> 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)

[supervinx]

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

[supervinx]

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

[sadness]

On Sun, 06 May 2012 23:29:28 +0000, supervinx wrote:

[snip]

> Non è certo nuovo, ma non sembra così messo male. Quello che non
> sappiamo,
> è il tasso di crescita dei difetti.

Considera che lo smart e' la cosa meno affidabile del mondo per la
predizioni degli errori sui dischi, fatta eccezione per l'indicazione
dei settori riallocati che e' ovviamente indicativa di un problema.
Puoi leggerti il papiro di google sul efficacia dello smart, in
particolare la considerazione fatta sul elevata quantita' di dischi
danneggiati/non funzionanti sui quali lo smart non aveva rilevato
alcuna anomalia.

Sui 6607 poi mi pare che i parametri che il disco fornisce tramite
lo smart siano davvero ridotti al osso, quindi smartcl fatica
decisamente a capire lo stato del disco.

> Probabilmente OS/400 è conservativo e consiglia *caldamente* la
> sostituzione.

Beh sai in ambito di produzione basta UN settore danneggiato per dover
sostituire un disco rigido, ed os/400 non e' pensato per un ambito home.
Os/400 direi che fa' il suo lavoro come qualunque altro os in ambito
pro.

> Ho avuto, ed ho, dischi in condizioni peggiori.

Come ho sottolineato piu' di una volta, nel utilizzo in ambito casalingo
quei dischi potrebbero avere una vita residua ancora molto lunga.

> Poiché i 6607 scaldano molto, perché non è stata prevista una ventola
> 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.

[sadness]

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.

[fm]

>
>> Poiché i 6607 scaldano molto, perché non è stata prevista una ventola
>> 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.
>

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

[supervinx]

> 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.

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

[supervinx]

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

[supervinx]

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

[sadness]

On Mon, 07 May 2012 17:22:38 +0000, supervinx wrote:

> 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 ;)

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 :)

[supervinx]

Il Mon, 07 May 2012 17:54:03 +0000, sadness ha scritto:

> On Mon, 07 May 2012 17:22:38 +0000, supervinx wrote:
>
>> 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 ;)
>
> 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 :)

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