IBM 5363: manuali e sistema operativo?
shadoooo
Come già scrivevo, ho recuerato questa macchina, purtroppo senza
terminale.
Sono alla ricerca anche di manuali e sistema operativo, purtroppo non
trovo molto in giro.
Qualuno ne sa qualcosa?
Grazie
Andrea
Englishman
> Qualuno ne sa qualcosa?
Io ci ho lavorato, ma parliamo di 27 anni fa, e non mi ricordo un belino.
Ti serve comunque uno dei suoi terminali e un utente/password per
entrare, oppure i dischi del sistema operativo (SSP).
Se ti interessa ho qualche cavo Twinax gia' intestato, una interfaccia
Twinax-parallela e forse qualcosa altro.
Ah! Ho visto adesso qui' (
http://en.wikipedia.org/wiki/IBM_System/34,_36_System_Support_Program ),
con mia grossa sorpresa, che c'e' qualcosa, e anche sul sito della
IBM... purtroppo non c'e' la documentazione :-(
supervinx
Appena riesumo la scatola dei floppy, pubblico la lista.
A proposito, cerco sempre qualcuno con un 5364 funzionante. Ho bisogno di
alcune misure di tensione per riparare il mio :P
In alternativa, un "riparatore esperto" che mi aiuti (on-line) nell'arduo
tentativo di sistemare il VRM.
In quel settore sono un pochino carente :( O che non ho proprio il tempo
di studiarmi l'argomento :P :P
ger...@no.spam.mail.com
wrote:
> Come già scrivevo, ho recuerato questa macchina, purtroppo senza terminale.
> Sono alla ricerca anche di manuali e sistema operativo, purtroppo non trovo
> molto in giro. Qualuno ne sa qualcosa?
Dubito che in rete troverai qualcosa di sostanzioso e interessante. Come
saprai (lo sai, vero?), quello è un sistema della famiglia S/36, diciamo non
troppo ambìto da chi si interessa di retrocomputing perché non ci si può
fare molto di più che accenderlo e giocherellare un po' con i comandi ed
eventualmente con i programmi contabili e gestionali di chi lo usava per il
suo scopo originale, visto che nasce specificatamente come sistema per la
gestione aziendale (ordini, bolle, fatture, pagamenti, magazzino ecc.).
Ho visto un altro messaggio in cui chiedi informazioni sui terminali e ti
rispondo qui: un terminale Twinax ti serve per forza, almeno per la console,
e le porte seriali servono solo per funzioni di telecomunicazione tipo SNA
su SDLC. Su macchine più vecchie le seriali potevano addirittura non essere
collegate: erano montate sul telaio, ma poi era necessario acquistare a
parte le schede di interfaccia verso il resto del sistema. Il TCP/IP su quel
genere di host non è mai esistito, quindi non pensare a cose tipo SLIP.
Quello che noi oggi chiameremmo sistema operativo, lì è suddiviso in due
parti distinte: un microcodice che svolge tutte le funzioni di basso livello
(ma non è dato sapere se è effettivamente un microcodice in senso stretto) e
un sistema operativo formato da una miriade di programmi più o meno piccoli
che svolgono le varie funzioni di alto livello, compresa l'interfaccia verso
l'utente. Il microcodice non ha nome, il sistema operativo (nell'accezione
IBM appena detta) si chiama SSP, cioè System Support Program.
Non ho mai avuto occasione di lavorare su un vero S/36, ma ho trafficato
parecchio sia con l'ambiente 36 di OS/400, cioè in pratica un'estensione
dell'interprete dei comandi di OS/400 che quindi accetta anche buona parte
dei comandi SSP (ma sempre OS/400 è), sia con la c.d. "Macchina 36" che
invece è una vera e propria macchina virtuale ospitata da OS/400 in cui si
installa un'apposita versione di SSP: la macchina virtuale fa le veci del
microcodice detto sopra che infatti non esiste e non va installato.
Quindi eventualmente ti saprò dire come si installa SSP (è tutto automatico,
basta caricare i supporti e avviare), invece non sono mai riuscito a trovare
documentazione chiara ed esaustiva su come si carichi il microcodice, cosa
che non ho mai avuto bisogno di fare perché in emulazione appunto non c'è.
Dato che ci sono e non ho niente da fare, aggiungo un po' di informazioni.
Secondo gli standard attuali SSP è abbastanza rudimentale e poco lineare.
Presenta un'interfaccia utente facilitata a menù numerati che attivano le
varie funzioni, richiamabili più velocemente anche da linea comandi. I veri
comandi sono abbastanza pochi e riguardano soprattutto funzioni hardware di
sistema come disconnettere una sessione bloccata o avviare una stampante,
invece la maggior parte delle altre operazioni sono svolte da procedure in
linguaggio OCL (Operator Control Language) che verificano i vari parametri
specificati dall'utente e poi li passano ad appositi programmi di utilità
che fanno parte di SSP, programmi che in alcuni casi è anche previsto che
possano essere richiamati direttamente dagli utenti esperti a mo' di API.
Per esempio, per creare un file si utilizza la procedura BLDFILE (Build
File) che richiama il programma $MAINT utilizzabile direttamente anche dagli
utenti e quindi in buona parte documentato nei manuali.
Tutto lo spazio disponibile sui vari dischi viene aggregato in un unico pool
(quindi se si guasta un disco si perde tutto) e viene gestito in modo non
gerarchico, quindi non esiste un vero e proprio concetto di subdirectory.
All'interno di questo spazio è possibile creare dei file formati da record a
larghezza fissa eventualmente indicizzati (BLDFILE), indici aggiuntivi per i
medesimi (BLDINDEX) e speciali file partizionabili detti librerie (BLDLIBR).
Le librerie sono suddivise in entità dette membri di libreria che possono
essere di quattro tipi: sorgenti (S), oggetti compilati (O), procedure OCL
(P) e subroutine binarie linkabili (R). SSP è tutto contenuto in una grossa
libreria di nome #LIBRARY contenente diverse centinaia di membri O e P.
Eventuali prodotti aggiuntivi sono contenuti in altre librerie, per esempio
il compilatore RPG è contenuto in #RPGLIB, oppure #COBLIB per il Cobol.
In altre parole, i file veri e propri possono contenere solo dati, mentre i
sorgenti letti dai compilatori e i programmi risultanti dalla compilazione
vengono conservati dentro i membri di una libreria, che non è altro che uno
speciale tipo di file (idea abbastanza comune fra i sistemi IBM dell'epoca).
Il microcodice invece è in una zona del disco invisibile, inaccessibile ed
esterna allo spazio disponibile per SSP e i dati degli utenti.
Quando si digita qualcosa sulla linea di comando, prima viene verificato che
non si tratti di un comando vero e proprio, poi viene cercata nella libreria
corrente una procedura (membro tipo P) con nome corrispondente a quanto si è
digitato. Se non viene trovata si riceve un errore. Da qui si capisce che
per avviare un programma occorre sempre la relativa procedura OCL che lo
carichi e lo esegua, a meno che non si voglia digitare a mano ogni volta la
corretta sequenza di specifiche OCL (// LOAD, // FILE, // RUN). La libreria
corrente può essere una sola e per comodità è quasi sempre la #LIBRARY che
quindi col tempo tende a riempirsi di "sporcizia". Volendo, le procedure si
possono sottomettere per l'esecuzione batch senza che l'utente sia costretto
a rimanere collegato in attesa della fine dell'elaborazione.
File e librerie non sono ad estensione automatica, quindi quando sono pieni
occorre fare varie manovre. Per i file si deve creare una nuova copia più
grande e poi travasare i dati, per le librerie invece bisogna compattare
tutti i membri con la procedura CONDENSE e poi se c'è spazio contiguo sul
disco si può estendere. Una cosa poco pratica. I nomi di file, librerie e
membri sono al massimo di otto caratteri senza estensioni, ma è possibile
sacrificare un carattere del nome per metterci un punto per poi filtrare in
base alla parte di nome prima del punto: X.AAA, X.BBB, X.CCC, ...
La configurazione è abbastanza rigida: si fa per mezzo di apposita procedura
interattiva CNFIGSSP che crea un cosiddetto membro di configurazione (tipo
O), di solito salvato nella libreria #CNFGLIB, poi copiato in una specifica
locazione del disco, nella zona del microcodice. Quindi si deve riavviare.
Tutto questo anche per operazioni banali come aggiungere un terminale o una
stampante. Nelle ultimissime versioni c'era il riconoscimento automatico dei
device Twinax, ma aveva comunque alcune limitazioni che potevano essere
evitate solo configurando i device a mano in modo permanente con CNFIGSSP.
Il controllo degli accessi mediante password (tipo PIN di quattro caratteri
al massimo) e la protezione dei dati sono facoltative e non attivate di
default. Non mi ricordo più come si chiamava la procedura per attivare il
tutto, forse SECDEF, però mi ricordo che quella di gestione era SECEDIT.
Non c'è molto altro da dire, si tratta di un sistema abbastanza semplice e
anche parecchio noioso per chi non è addetto ai lavori. Io qualche manualone
ce l'ho, se serve qualcosa posso spulciare e riferire su singole questioni.
HTH,
G.
supervinx
Ho un amico con in cantina un S/36 completo: per completo, intendo il
corpo macchina (non so il modello esatto, ma abbastanza grande: non il
modello lavatrice/comodino, però), due o tre terminali twinax, cavetteria
varia, e due cartoni fra manuali (tutto originale, raccoglitori ad
anelli) e software: programmi, aggiornamenti, un "mare di roba"...
Dismesso funzionante da un suo ex cliente.
È lì ad arrugginirsi, ma non me lo darà mai :P
Potrei, però, farmi prestare tutta la documentazione e tentare una copia.
Vi faccio sapere :)
Corrado Roberto
>Quello che noi oggi chiameremmo sistema operativo, lì è suddiviso in due
>parti distinte: un microcodice che svolge tutte le funzioni di basso
>livello
>(ma non è dato sapere se è effettivamente un microcodice in senso stretto)
>e
>un sistema operativo formato da una miriade di programmi più o meno piccoli
>che svolgono le varie funzioni di alto livello, compresa l'interfaccia
>verso
>l'utente. Il microcodice non ha nome, il sistema operativo (nell'accezione
>IBM appena detta) si chiama SSP, cioè System Support Program.
Ciao,
grazie per la condivisione del tuo "sapere", mi permetto solo di farti
notare, che anche i sistemi operativi moderni sono suddivisi
{grossolanamente se ci limitassimo solo a questa suddivisione} in due parti,
kernel space e user space.
grazie ancora per il messaggio, è stata una lettura interessantissima^^
Renaissance
> Ciao,
> grazie per la condivisione del tuo "sapere", mi permetto solo di farti
> notare, che anche i sistemi operativi moderni sono suddivisi
> {grossolanamente se ci limitassimo solo a questa suddivisione} in due parti,
> kernel space e user space.
> grazie ancora per il messaggio, è stata una lettura interessantissima^^
Eh, pur non avendo nessuna esperienza in merito, mica e' cosi' semplice:
son sistemi ibm, le consuete accezioni accademiche sulla struttura dei
sistemi operativi moderni (magari unix-centriche) *possono* essere in
buona parte divergenti.
Prendi, in ambito mainframe ibm, cp-67/VM, e dimmi che ne pensi,
rispetto alle controparti. ;-) (Hint: strategie storicamente
completamente differenti per raggiungere concretamente l'obiettivo
del timesharing/multiutenza).
bye G.L.
--
Da i.d.c.tutela:
P.S. Quando ci sarà lo switch-off, avrò problemi anche col
monitor del PC? Ho visto che è collegato in modalità analogica.
Corrado Roberto
"Renaissance"
> Eh, pur non avendo nessuna esperienza in merito, mica e' cosi' semplice:
> son sistemi ibm, le consuete accezioni accademiche sulla struttura dei
> sistemi operativi moderni (magari unix-centriche) *possono* essere in
> buona parte divergenti.
> Prendi, in ambito mainframe ibm, cp-67/VM, e dimmi che ne pensi,
> rispetto alle controparti. ;-) (Hint: strategie storicamente
> completamente differenti per raggiungere concretamente l'obiettivo
> del timesharing/multiutenza).
ottima risposta verso un *qualcosa* che non ho ben capito: lo scopo.
la mia precisazione prende spunto sulla suddivisione (x2) a prescindere
dalle origini del sistema operativo, ciň che intendevo dire era (ed č):
anche ora nel 2011, i sistemi operativi possono essere suddivisi in due
segmenti; user space e kernel space: non intendevo fare nessun paragone! ma
semplicemente far notare il *dettaglio* a chi non si occupa di
programmazione anche saltuariamente.
ger...@no.spam.mail.com
> varia, e due cartoni fra manuali (tutto originale, raccoglitori ad
> anelli) e software: programmi, aggiornamenti, un "mare di roba"...
> [...]
> Potrei, però, farmi prestare tutta la documentazione e tentare una copia.
Bravo bravo! Io di manuali software interessanti ho solo l'immenso "Manuale
di riferimento del sistema", SC13-5078-03 (03, ovvero terza edizione).
G.
ger...@no.spam.mail.com
> Dovrei avere qualcosa, software, a corredo del mio S/36 5634 (il Baby/36).
Quello in verità dovrebbe essere l'S/36 PC. Il Baby/36 era una imitazione
software, credo tedesca, che girava in ambiente MS-DOS e non era compatibile
a livello binario con il Sistema/36 IBM. Curiosità: il Baby/36 è salito
all'onore (?) delle cronache non molti anni fa, quando venne fuori che il
compagno di Wanna Marchi (!) ne usava una vecchissima versione per tenere la
contabilità delle truffe della sua degna compare! :-)))
G.
ger...@no.spam.mail.com
wrote:
> Eh, pur non avendo nessuna esperienza in merito, mica e' cosi' semplice:
> son sistemi ibm, le consuete accezioni accademiche sulla struttura dei
> sistemi operativi moderni (magari unix-centriche) *possono* essere in
> buona parte divergenti.
Forse io non ho espresso chiaramente quel che intendevo, ma tu hai colto
comunque la mia idea. Non volevo dire che c'è la "solita" suddivisione fra
kernel space e user space, che oltretutto non è scontata neppure in altri
sistemi operativi moderni, bensì volevo sottolineare la particolare
architettura fisica e concettuale del Sistema/36. Per il resto mi auguro che
chi legge questo NG sappia com'è fatto e come funziona un OS mainstream
moderno, almeno uno tipo Unix, multiuser e multitasking.
Piccola digressione: VMS utilizza ben quattro modi differenti (kernel,
executive, supervisor, user), non ha il concetto di processo come lo si
intende in ambito Unix — tanto che non viene creato un nuovo processo per
ogni binario eseguito — e se vogliamo parlare di cose semplici, rispetto a
Unix non ha neppure il medesimo concetto di filesystem, infatti lo
spostamento fra le directory è differente teoricamente e operativamente. In
pratica le differenze sono così tante che si fa prima a elencare le (poche)
somiglianze. Se qualcuno vuole sapere i dettagli, suggerisco di dare
un'occhiata al cosiddetto IDSM, cioè "Internals and Data Structures Manual",
disponibile pure su Bitsavers. (Multics, se non sbaglio, di ring ne aveva
addirittura diciotto!)
Tornando al Sistema/36, quel che volevo dire è che ci sono due "cose" del
tutto distinte, residenti in due zone del disco diverse (oggi potremmo
chiamarle partizioni), organizzate e forse formattate diversamente, con
compiti diversi e addirittura in esecuzione su processori diversi! Tra
l'altro solitamente il microcodice era considerato parte dell'hardware e
compreso nel prezzo, mentre SSP era a parte e licenziato come software.
Addirittura, il comando di salvataggio generale del sistema (SAVE ALL) non
fa il backup del microcodice, che si può fare (credo) avviando la macchina
con apposito floppy diagnostico. Volendolo rapportare a qualcosa di moderno,
lo metterei a metà strada tra un BIOS troppo cresciuto e un kernel ridotto.
IBM non è mai stata prodiga di dettagli sul funzionamento interno delle
proprie macchine, specialmente quando si tratta di sistemi proprietari e/o
che fruttano un sacco di soldi, ma mettendo insieme vari indizi raccolti
negli anni si è capito che il cosiddetto microcodice (che è poi tutto da
dimostrare che sia veramente un microcodice come lo intendiamo oggi) risiede
in una porzione riservata del disco e va in esecuzione su quello che si
chiama CSP, cioè Control Storage Processor, con un clock di circa 4 MHz.
Viceversa SSP, cioè quello che IBM chiama sistema operativo, viene eseguito
insieme ai programmi utente su un altro processore (MSP, cioè Main Storage
Processor) con un clock di circa 1 MHz, in rapporto fisso di 1/4 sull'altro.
Non si sa con precisione se c'era separazione e protezione hardware tra le
due "entità", cioè fra microcodice e SSP. Per certi versi sì — anche perché
parte del microcodice dovrebbe risiedere in una memoria separata — ma per
certi altri versi no, tanto che erano disponibili vari programmini che
permettevano anche a utenti non privilegiati di fare cose potenzialmente
pericolose o addirittura di bloccare la macchina (se usati in modo non
corretto). Anzi, a ben vedere non c'era neppure il concetto di utente
privilegiato o meno, considerando che di default la sicurezza non era attiva
e che per entrare si poteva inventare un qualunque nome utente sul momento.
Non si sa neppure quale tipo di multitasking ci fosse e fino a che punto
fosse spinto, né se ci fosse memoria virtuale, e quanta. L'idea IBM era
quella di fornire una "black box" ai programmatori applicativi, senza che
dovessero preoccuparsi della macchina a basso livello, al punto da mantenere
riservati i dettagli tecnici sul funzionamento interno di quasi tutto. Non è
mai esistito un sistemista vero e proprio per queste macchine: si passava
dal programmatore applicativo che si occupava dei soliti progammi gestionali
direttamente al tecnico hardware IBM che si occupava di tutto il resto.
L'unica cosa "privilegiata" era il terminale identificato come console, cioè
il terminale Twinax con indirizzo zero sulla porta zero, ma solo per il
microcodice e non per il resto di SSP e solo se la sicurezza non era attiva.
In caso contrario le operazioni privilegiate erano possibili da qualunque
terminale presso il quale si fosse collegato un utente SSP con i permessi
adatti. Su OS/400 è molto più chiaro quel che si può fare solo sulla console
e c'è il concetto di sistema dedicato, in SSP è tutto molto più aleatorio,
eppure durante l'IPL il conto alla rovescia (con numeri enormi a pieno
schermo, molto scenografico) viene visualizzato solo sulla console. Si può
ipotizzare che fosse soprattutto una console hardware che si poteva spostare
da un terminale all'altro con i comandi CONSOLE GIVE e CONSOLE TAKE.
Se mi viene in mente qualcos'altro, aggiungo.
Ciao,
G.
supervinx
Il Baby/36 è un software per PC di interfaccia con il 5364 (me lo trovo
in originale, per vie traverse) ed il 5364 ha preso il soprannome dal
software :)
System/36 RPG fpr your PC
California Software Products
Recita l'etichetta sui dischi...
supervinx
Parlo del mio 5364 in coma.
1) Dev'essere collegato ad un altro PC per l'IPL iniziale, con un cavo
adatto a rimorchiare le navi nel porto :D
2) Collegato ad ingombranti terminali twinax con cavi traino per
automobili :)
3) Di una pesantezza (fisica) indescrivibile.
4) Arcana e criptica.
Insomma, la solita roba IBM ?
Vuoi mettere con l'eleganza di altri produttori ?
ger...@no.spam.mail.com
> 1) Dev'essere collegato ad un altro PC per l'IPL iniziale, con un cavo
> adatto a rimorchiare le navi nel porto :D
Questa definizione m'è piaciuta tantissimo! :D
> 2) Collegato ad ingombranti terminali twinax con cavi traino per
> automobili :)
Ma no dai. A parte le battute, sappi che il PC companion fa anche da
terminale una volta avviata la macchina, quindi non ti serve un ulteriore
terminale Twinax per giocarci un po'.
Domanda: a parte l'alimentatore problematico, tutto il resto ce l'hai? Negli
anni qui sul NG è passata diversa gente con i vari pezzi di un 5364, ma mai
nessuno che avesse tutto: o mancava il cavo, o mancava l'apposita scheda nel
PC (o mancava tutto il PC), o mancava il software... Un disastro.
> 4) Arcana e criptica.
>
> Insomma, la solita roba IBM ?
>
> Vuoi mettere con l'eleganza di altri produttori ?
Bello o brutto che sia, ha fatto la storia dell'informatica aziendale. In
realtà il 36 non doveva neanche esistere, fu creato come temporaneo rimedio
per sostituire il 34 di chi con quello non ce la faceva più, ma che ancora
per vari motivi non si decideva a passare al 38 (il papà dell'AS/400), e
divenne un best seller contro ogni aspettativa e previsione. Ha avuto un
successo tale che tuttora l'ambiente 36 di OS/400 è vivo e vegeto.
Indubbiamente è un tipico sistema IBM anni 70 (anche se è nato nell'83, di
fatto è una replica velocizzata del 34 del 1977), con tutte le sue stranezze
e limitazioni, anche in considerazione del fatto che doveva funzionare con
pochissima (e costosissima) memoria. Idem per i dischi.
Non erano molti i concorrenti che potevano offrire qualcosa di simile. Forse
giusto la Digital, ma non certo con un VAX, perché non era paragonabile né
come prezzo di acquisto né come costi di gestione. Forse il 34 si potrebbe
paragonare con un PDP-8 o un piccolo PDP-11, ma poi verrebbero a mancare
diverse funzionalità tipicamente utili alle aziende, che seppur a suo modo e
in modo limitato il 34 invece riusciva ad offrire. E poi era IBM, e sappiamo
che la penetrazione di IBM nel mercato aziendale italiano era imbattibile
per via della posizione acquisita già decenni prima con le schede perforate.
È arcano, è criptico, è la "solita" roba IBM convoluta, è tutt'altro che
elegante, però è un mulo, un trattore il cui retaggio ancora oggi tiene
banco. Insomma, non si può ignorare, anche solo per conoscere il rischio. :)
Ciao,
G.
ger...@no.spam.mail.com
> System/36 RPG fpr your PC
> California Software Products
Proprio lui. C'era sia il compilatore RPG per PC, che credo potesse accedere
in qualche modo ai dati memorizzati sul 36, sia un ambiente completo nato
per sostituire del tutto il 36 quando nella seconda metà degli anni 80 ci fu
il boom dei gestionali per MS-DOS su PC, spesso scritti in Clipper e/o con i
dati gestiti da dBASEIII della Ashton-Tate.
Ciao,
G.
ger...@no.spam.mail.com
> Se mi viene in mente qualcos'altro, aggiungo.
Mi è venuta in mente un'altra particolarità che accomuna il 36 con altri
sistemi IBM più o meno dello stesso genere e più o meno della stessa epoca.
Non c'è modo di formattare i dischi rigidi dal sistema operativo. I floppy
sì, i nastri sì, ma lo storage interno no. Forse è una forma di sicurezza,
forse è un'esigenza dovuta al particolare modo in cui viene gestito lo
spazio, sta di fatto che l'unico modo per inizializzare un disco consiste
nell'avviare la macchina in modo particolare, eventualmente anche facendo
IPL da floppy, e poi dialogare direttamente col microcodice prima della
partenza del sistema operativo, cioè senza SSP nel caso del Sistema/36.
Curiosità: in SSP esiste la procedura FORMAT, ma fa tutt'altro, infatti
serve per "compilare" in formato binario le mappe utilizzate dai programmi
per visualizzare i dati sui terminali, i cosiddetti formati video.
Ciao,
G.
supervinx
> Domanda: a parte l'alimentatore problematico, tutto il resto ce l'hai?
> Negli anni qui sul NG è passata diversa gente con i vari pezzi di un
> 5364, ma mai nessuno che avesse tutto: o mancava il cavo, o mancava
> l'apposita scheda nel PC (o mancava tutto il PC), o mancava il
> software... Un disastro.
>
Perché ?
1) Il 5634 è in ottime condizioni, espansione di memoria e due dischi
rigidi ESDI !
2) Ho il cavo da rimorchio per le navi (parlo a ragion veduta :) )
3) Ho la scheda lato 5364 e la scheda lato PC.
4) Ho il software di comunicazione
5) Ho il sw Baby/36 originale
6) Ho un compilatore RPG con tanto di chiave hardware parallela (la
saponetta)
7) Ho un terminale Twinax con tastiera, funzionante e tutta la cavetteria
8) Una scatola di cavi twinax, adattatori a T (DB15), uno switch twinax
(manuale, come quello per le porte seriali/parallela/VGA)
Lo accendo: il sw mi dice che non è possibile comunicare.
Guarda di qua, guarda di là ... niente.
Poi vedo sulla MB dei test points per le tensioni.
Bene, cominciamo da lì.
Tutte le tensioni provenienti dall'alimentatore sono a posto, ma quella
+1.75 (o giù di lì) è zero.
Cerca cerca, non la fornisce l'alimentatore.
C'è uno scatolotto metallico, che riceve una strana tensione (vado a
memoria, dovrei riprenderlo): è presente sia la componente alternata che
quella in continua, circa 375V: ma perché passare da 220V a 375V per poi
scendere ad 1.75V ?
Il modulo VRM (alla fine ho visto, cercando, che è proprio tale), riceve
sia la tensione "strana" dalla PSU che +5 e +12 dalla MB (almeno così
sembra, visto che +5, +12 esistono anche in assenza di detto modulo). Ma
dai pins marcati 1.75 non esce nulla.
Tempo fa trovai un VRM a 75$, ma contattata la ditta non rispose.
Un paio di settimane fa è passato su eBay un 5364, am oltre 100€, un po'
troppo per un VRM ... :(
Per adesso, il cassettone è alle mie spalle, terzo ripiano. Devo fare
attenzione quando mi distendo sulla sedia ... certe zuccate :)
shadoooo
Se saltano fuori i manuali, e se è possibile trasportarli, mi propongo
per aiutare a fare la scansione.
Per la riparazione del 5364, credo che potrei aiutare, ma dovrei avere
la macchina da me...
Ciao
Andrea
ger...@no.spam.mail.com
> 2) Ho il cavo da rimorchio per le navi (parlo a ragion veduta :) )
Quante storie! Pensa se fosse stato un cavo Channel, sempre IBM ovviamente
(un pitone del diametro di un polso, formato da 48 cavi coassiali, con due
connettori per lato, ciascuno grande come un pacchetto di sigarette). :-)
> Per adesso, il cassettone è alle mie spalle, terzo ripiano. Devo fare
> attenzione quando mi distendo sulla sedia ... certe zuccate :)
Pensa se fosse stato un 5360: http://www.corestore.org/36.htm :-)
Ciao,
G.
fm
<ger...@no.spam.mail.com> ha scritto nel messaggio
news:6andk69uummtojkd1...@4ax.com...
On Mon, 31 Jan 2011 00:06:12 GMT, ger...@no.spam.mail.com wrote:
> Se mi viene in mente qualcos'altro, aggiungo.
>Mi � venuta in mente un'altra particolarit� che accomuna il 36 con altri
>sistemi IBM pi� o meno dello stesso genere e pi� o meno della stessa epoca.
>Non c'� modo di formattare i dischi rigidi dal sistema operativo. I floppy
>s�, i nastri s�, ma lo storage interno no. Forse � una forma di sicurezza,
>forse � un'esigenza dovuta al particolare modo in cui viene gestito lo
>spazio, sta di fatto che l'unico modo per inizializzare un disco consiste
>nell'avviare la macchina in modo particolare, eventualmente anche facendo
>IPL da floppy, e poi dialogare direttamente col microcodice prima della
>partenza del sistema operativo, cio� senza SSP nel caso del Sistema/36.
>Curiosit�: in SSP esiste la procedura FORMAT, ma fa tutt'altro, infatti
>serve per "compilare" in formato binario le mappe utilizzate dai programmi
>per visualizzare i dati sui terminali, i cosiddetti formati video.
Premesso che il Sistema 36 dell'Ibm e' per me un vecchio amico, con cui
ho lavorato
dal momento in cui e' stato annunciato sul mercato italiano fino a pochi
anni fa,
(non lo crederete ma esisteva ancora un'azienda che utilizzava un 5363,
peraltro perfettamente funzionante)
Dico subito che mi ha fatto molto piacere leggere di questi argomenti, e che
voglio aggiungere qualche mia considerazione, sperando di chiarire alcune
inesattezze:
1) Il 5364 non e' un modello significativo all'interno della famiglia dei
Sistemi 36.
Il 36 "vero" e' stato il modello 5360.
2) Il 5364 al momento del suo lancio era solo il modello piu' economico,
parecchio disprezzato dagli tecnici addetti ai lavori (ma non dai
commerciali!)
perche molto ma molto piu' lento non solo del 5360 ma anche del 5362.
Avendo come console non un terminale twinax ma un Pc Ibm XT
(collegato all'unit� centrale 5364 tramite una particolare scheda da
inserire nel pc stesso)
si pensava che fosse la macchina ideale per "attirare" verso
il mondo del S/36 i clienti che avevano un pc Ibm.
Commercialmente parlando, un cliente
che possedeva un PC XT poteva passare al mondo del S/36 comprando
solo il 5364 , mantenendo il suo pc e la stampante e quindi
" l'investimento". (Non va dimenticato che all'epoca del 5364 un
Ibm PC XT + stampante Ibm arrivava a costare quasi dieci milioni di lire)
In realt�, moltissimi di coloro che acquistarono un 5364 sono poi stati
fatti migrare a S/36 piu' performanti, come gli ultimi modelli del 5363
che avevano molta ram e dischi veloci.
Il Pc XT veniva dismesso o comunque riutilizzato come terminale (ma
con una scheda diversa, un' emulazione twinax)
3) Il System/36 mod. 5360 non era *solo* un S/34 piu' veloce,
ma aveva importanti migliorie hardware e software.
Faccio un esempio hardware:
Per esperienza diretta, i primi 5360 con due dischi da 200 Mb e 256Kb di
Ram
erano straordinariamente piu' performanti dei S/34, diciamo di un ordine di
grandezza.
Faccio un esempio software:
I file ad indice ad accesso immediato del S/36 permettevano sia
letture/scritture
random che letture sequenziali IN TEMPO REALE, caratteristica poi migrata
anche negli ultimi release del S/34 (attributo IFILE-YES nella // FILE
NAME).
4) Non e' vero che i files avevano dimensione (numero di record) fisso.
il files potevano essere dichiarati nei programmi che li utilizzavano con
la parola chiave EXTEND....
// FILE NAME-ANARTI,DISP-SHR,EXTEND-1000
significava che l'ampiezza (in records) del file ANARTI sarebbe stata
estesa (se necessario)
di altri 1000 records.
Come pure si poteva usare l'estensione col SORT e nella BLDFILE.
5) Baby/36 (come gia' BABY/34?) non e' un prodotto Ibm e non e' giusto
associarlo al 5364.
Si tratta di un software di emulazione che permetteva di migrare i files
e ricompilare i programmi in RPG in un ambiente ben diverso...ossia in una
macchina DOS.
In realt� tutti questi "emulatori" (potrei citare anche l'ottimo e piu'
economico
RPG della Lattice, basato sui files DBIII) hanno vissuto poco a lungo.
Il vero emulatore "vincente" del S/36 e' stato il S/36 Enviroment di quella
macchina
incredibile che si chiamava Ibm AS/400.
6) Non mi sembra giusto definire l'SSP un sistema operativo semplificato,
per l'epoca aveva caratteristiche non banali, fra le quali la grande
stabilit� ed affidabilit�.
I files del S/34 e del S/36 erano contigui sul disco....a garantire la
deframmentazione del disco (quando ancora questo termine era praticamente
sconosciuto ai piu')
ci pensava la procedura COMPRESS.
Un'altra sofisticata procedura, la BUILD si occupava di ricostruire (se
necessario) gli errori sul disco.
Gli errori sul disco erano *estremamente* rari sui System /36.
Credo di aver visto una o due volte un record errato su S/36 e
di aver usato la BUILD una volta in un quarto di secolo.
7) il libro nero del 36 era il "S/36 Data Areas and Diagnostics Aids"
(su cui ahime' non ho mai potuto mettere le mani)
con esso si potevano fare cose magiche, come, ad. es, impostare
con la procedura PATCH quell'unico byte che sul S/34 (e temo anche sul 36)
disattivava TUTTE le password !!!
8) con il prodotto programma Ibm IDDU si potrevano
anche sul S/36, creare dei files con DEFINIZIONE ESTERNA,
forse utilizzabili solo col DFU (?)...ma l'idea c'era.
9) Non e' vero che l'AS/400 e' figlio solo del 38...se il 38 e' suo padre e'
indubbio
l'enorme contributo portato dal S/36 (vedi ad esempio la POPLIB e il comando
STRPDM)
Scusate per la lunghezza di quanto sopra, l'incompletezza e per gli
eventuali errori.
Purtroppo "la mente e' porosa all'oblio" ... ma quella del 36
e' stata veramente una storia straordinaria.
ciao
fm
P.S. Ho buone speranze di recuperare fra qualche giorno
un AS/400 mod. Y10, fermo ormai da molti anni,
non fatevi ingannare dal nome...e' ancora una volta un S/36 !!!
supervinx
> <ger...@no.spam.mail.com> ha scritto nel messaggio
> news:6andk69uummtojkd1...@4ax.com... On Mon, 31 Jan 2011
> 00:06:12 GMT, ger...@no.spam.mail.com wrote:
>
>> Se mi viene in mente qualcos'altro, aggiungo.
>
>>Mi è venuta in mente un'altra particolarità che accomuna il 36 con altri
>>sistemi IBM più o meno dello stesso genere e più o meno della stessa
>>epoca.
>
>>Non c'è modo di formattare i dischi rigidi dal sistema operativo. I
>>floppy sì, i nastri sì, ma lo storage interno no. Forse è una forma di
>>sicurezza, forse è un'esigenza dovuta al particolare modo in cui viene
>>gestito lo spazio, sta di fatto che l'unico modo per inizializzare un
>>disco consiste nell'avviare la macchina in modo particolare,
>>eventualmente anche facendo IPL da floppy, e poi dialogare direttamente
>>col microcodice prima della partenza del sistema operativo, cioè senza
>>SSP nel caso del Sistema/36.
>
>>Curiosità: in SSP esiste la procedura FORMAT, ma fa tutt'altro, infatti
>>serve per "compilare" in formato binario le mappe utilizzate dai
>>programmi per visualizzare i dati sui terminali, i cosiddetti formati
>>video.
>
>
> Premesso che il Sistema 36 dell'Ibm e' per me un vecchio amico, con
> cui ho lavorato
> dal momento in cui e' stato annunciato sul mercato italiano fino a
> pochi anni fa,
> (non lo crederete ma esisteva ancora un'azienda che utilizzava un
> 5363, peraltro perfettamente funzionante)
> Dico subito che mi ha fatto molto piacere leggere di questi argomenti, e
> che voglio aggiungere qualche mia considerazione, sperando di chiarire
> alcune inesattezze:
>
> 1) Il 5364 non e' un modello significativo all'interno della famiglia
> dei Sistemi 36.
> Il 36 "vero" e' stato il modello 5360.
>
> 2) Il 5364 al momento del suo lancio era solo il modello piu' economico,
> parecchio disprezzato dagli tecnici addetti ai lavori (ma non dai
> commerciali!)
> perche molto ma molto piu' lento non solo del 5360 ma anche del 5362.
> Avendo come console non un terminale twinax ma un Pc Ibm XT (collegato
> all'unità centrale 5364 tramite una particolare scheda da inserire nel
> pc stesso)
> si pensava che fosse la macchina ideale per "attirare" verso il mondo
> del S/36 i clienti che avevano un pc Ibm. Commercialmente parlando, un
> cliente
> che possedeva un PC XT poteva passare al mondo del S/36 comprando solo
> il 5364 , mantenendo il suo pc e la stampante e quindi "
> l'investimento". (Non va dimenticato che all'epoca del 5364 un Ibm PC XT
> + stampante Ibm arrivava a costare quasi dieci milioni di lire) In
> realtà, moltissimi di coloro che acquistarono un 5364 sono poi stati
> In realtà tutti questi "emulatori" (potrei citare anche l'ottimo e piu'
> economico
> RPG della Lattice, basato sui files DBIII) hanno vissuto poco a
> lungo.
>
Eccolo ... Lattice RPG + parallel dongle ! Ce l'ho,originale :)
Insieme al Baby/36.
Comunque, da quel che mi risulta, il tanto vituperato 5364 gestiva, oltre
ad un XT/AT come terminale, anche un vero e proprio terminale Twinax (c'è
una porta posteriore nel mio), ed opzionalmente due.
Chissà se riuscirò a riesumarlo :)
fm
>>
> Eccolo ... Lattice RPG + parallel dongle ! Ce l'ho,originale :)
> Insieme al Baby/36.
> Comunque, da quel che mi risulta, il tanto vituperato 5364 gestiva, oltre
> ad un XT/AT come terminale, anche un vero e proprio terminale Twinax (c'è
> una porta posteriore nel mio), ed opzionalmente due.
> Chissà se riuscirò a riesumarlo :)
Speriamo di si !...:-)
ciao
fm
ger...@no.spam.mail.com
> Premesso che il Sistema 36 dell'Ibm e' per me un vecchio amico, con cui
> ho lavorato dal momento in cui e' stato annunciato sul mercato italiano
> fino a pochi anni fa, (non lo crederete ma esisteva ancora un'azienda che
> utilizzava un 5363, peraltro perfettamente funzionante) Dico subito che mi
> ha fatto molto piacere leggere di questi argomenti, e che voglio aggiungere
> qualche mia considerazione, sperando di chiarire alcune inesattezze:
Ciao fm, ogni tanto ti leggo di là su it.comp.as400 e mi fa piacere trovarti
anche qui a raccontare aneddoti. :-) Io su un vero 36 stavo per lavorarci,
ma alla fine non se n'è fatto nulla, peccato perché mi sarebbe piaciuto. Si
trattava di un cliente che due o tre anni fa aveva pure lui ancora un 5363
in produzione. Sempre un paio di anni fa mi capitò di andare per un lavoro
presso una nota società di Bologna che si occupa di assistenza hardware a
prodotti IBM (cioè: se serve un pezzo introvabile o ce l'hanno loro o non ce
l'ha più nessuno) e parlando con uno dei soci venne fuori che nella regione
Emilia-Romagna al momento c'erano ancora innumerevoli 36 in uso, due 34 e
addirittura un 38. Io ho sempre faticato a crederci, considerando l'anno
2000 e l'euro, ma loro hanno confermato convinti...
Mi dicevano che su macchine così vecchie i problemi più frequenti erano
sull'alimentazione, io invece avrei scommesso sui dischi, ma forse quelli
sono stati rimpiazzati in qualche modo con qualcosa di compatibile. Chissà.
> 1) Il 5364 non e' un modello significativo all'interno della famiglia dei
> Sistemi 36. Il 36 "vero" e' stato il modello 5360.
Il 5362 non era significativo? Un ex frequentatore di questo NG (Hkz, dove
sei finito?) ne aveva recuperato uno funzionante ed era uno spettacolo. :-)
> 2) Il 5364 al momento del suo lancio era solo il modello piu' economico,
> parecchio disprezzato dagli tecnici addetti ai lavori (ma non dai
> commerciali!)
Ho sempre sospettato che fosse un po' la stessa cosa dei P01/P03 in ambito
AS/400. Per quanto pure quelli il loro lavoro l'hanno fatto: quello che ho
io viene da uno studio di commercialisti (classico software Zucchetti) e
pare gestisse cinque o sei utenti interattivi senza troppa fatica.
> perche molto ma molto piu' lento non solo del 5360 ma anche del 5362.
Non oso pensare alla velocità. Una mia collega mi raccontava di compilazioni
che duravano mezzi pomeriggi su un 5360, chissà sul 5364... Ma secondo te un
5363 era più veloce anche del 5360 più potente?
> 3) Il System/36 mod. 5360 non era *solo* un S/34 piu' veloce, ma aveva
> importanti migliorie hardware e software.
Sì, ho semplificato. :-PP
> I file ad indice ad accesso immediato del S/36 permettevano sia
> letture/scritture random che letture sequenziali IN TEMPO REALE,
> caratteristica poi migrata anche negli ultimi release del S/34 (attributo
> IFILE-YES nella // FILE NAME).
Sul 34 se non sbaglio invece si doveva fare una KEYSORT dopo la chisura del
file per vedere i nuovi record, no? Cosa non faceva il 34 senza IFILE-YES?
> 4) Non e' vero che i files avevano dimensione (numero di record) fisso.
> il files potevano essere dichiarati nei programmi che li utilizzavano con
> la parola chiave EXTEND....
Questo l'ho scritto perché lo ricordavo così da miei ex colleghi che avevano
lavorato anche sul 32, però sono (ero) quasi sicuro che si riferissero al 36
quando raccontavano di manovre a base di COPYDATA per allargare un file in
cui non ci stava più nulla. Chissà, forse dipendeva solo dai programmi: a me
è capitato un software in Cobol migrato da mainframe su OS/400 in cui molti
file erano trattati come relative, senza incrementi e con lo spazio per i
record creato in anticipo con INZPFM. Avevo proprio fatto io un CL che tutte
le notti controllasse quanto spazio mancava per evitare di trovarsi bloccati
durante il giorno perché il file era pieno e non si riusciva ad estendere
dato che era allocato da decine di utenti (questo su una V5Rx di OS/400...)!
> 6) Non mi sembra giusto definire l'SSP un sistema operativo semplificato,
> per l'epoca aveva caratteristiche non banali, fra le quali la grande
> stabilità ed affidabilità.
Semplificato no, rudimentale rispetto agli standard odierni, oserei dire sì.
Che poi facesse bene il suo lavoro è un altro paio di maniche, però anche
giocando con SSP 7.5 nella M/36 ho avuto un'impressione strana, sarà forse
per certi pannelli con un aspetto un po' "artigianale" rispetto a quelli di
OS/400, magari con qualche campo non proprio allineato con gli altri, o cose
del genere, però mi è sembrato un po' poco rifinito nell'interfaccia utente,
e più in generale un po' grezzo. Ma è anche vero che stiamo parlando di un
sistema operativo di un'altra epoca, che faceva quel che faceva con risorse
relativamente piuttosto limitate. L'abito non fa il monaco. :-)
> I files del S/34 e del S/36 erano contigui sul disco....a garantire la
Ma quindi se un file era pieno e non c'era spazio contiguo, l'estensione di
cui si diceva sopra falliva? O riusciva a farla altrove sul disco?
> deframmentazione del disco (quando ancora questo termine era praticamente
> sconosciuto ai piu') ci pensava la procedura COMPRESS.
Be', nel mondo Digital, anche solo parlando di VAX/VMS, il concetto era già
conosciuto, studiato e risolto in vari modi. Ecco, se faccio un paragone tra
l'impressione di primo acchito data da un VMS — anche molto vecchio, più o
meno coevo di SSP — e da SSP rilevo che VMS trasmette un'immagine secondo me
molto più ingegnerizzata, industrializzata e standardizzata rispetto a SSP.
Questo intendevo dire con le definizioni "artigianale" e "grezzo" per SSP.
> 7) il libro nero del 36 era il "S/36 Data Areas and Diagnostics Aids"
> (su cui ahime' non ho mai potuto mettere le mani) con esso si potevano fare
> cose magiche, come, ad. es, impostare con la procedura PATCH quell'unico
> byte che sul S/34 (e temo anche sul 36) disattivava TUTTE le password !!!
Se ti interessa ho della documentazione interessante in proposito, raccolta
parecchi anni e fa e se non sbaglio anche testata con successo su SSP 7.5
(per M/36): è spiegato come interpretare certi settori bassi del disco e
decodificare le password degli utenti. :-P
> 8) con il prodotto programma Ibm IDDU si potrevano anche sul S/36, creare
> dei files con DEFINIZIONE ESTERNA, forse utilizzabili solo col DFU (?)...ma
> l'idea c'era.
Quasi certamente le definizioni IDDU servivano anche per il Query/36 e per
le funzioni del Displaywrite/36 similari alla stampa unione di Word.
> 9) Non e' vero che l'AS/400 e' figlio solo del 38...se il 38 e' suo padre e'
> indubbio l'enorme contributo portato dal S/36 (vedi ad esempio la POPLIB e
> il comando STRPDM)
Sì, d'accordo, però alla fine stiamo parlando di uno strumento che se non
avesse preso spunto dalla POP, magari si sarebbe ispirato a ISPF di MVS. Tra
l'altro mi risulta che il SEU di OS/400 sia in pratica una versione ridotta
di XEDIT per MVS. Dal 36 in fondo non ha ereditato molto di più, dal 38 ha
ereditato tutta la filosofia a oggetti, il database integrato, le DDS, i
giornali, il commitment control etc. etc. etc.
Dato che ci siamo ne approfitto per una domanda: sai mica sul 38 cosa c'era
al posto del PDM? Solo il menù del programmatore?
Un paio di screen-shot di ISPF e XEDIT:
http://www.ibm.com/developerworks/university/images/mf_2010/screen7.PNG
http://www.tombrennansoftware.com/edit.gif
> P.S. Ho buone speranze di recuperare fra qualche giorno
> un AS/400 mod. Y10, fermo ormai da molti anni,
> non fatevi ingannare dal nome...e' ancora una volta un S/36 !!!
Se hai un AS/400 con la V4 e ti interessa, ho qui il CD con SSP R7.5 per
M/36 (vedi WRKM36) e relative PTF...
Ciao, :-)
G.
DG
> Pensa se fosse stato un 5360: http://www.corestore.org/36.htm :-)
> Ciao,
> G.
doh.. grazie ad una foto del sito segnalato, ho forse capito la
provenienza di 4 schede, salvate da una brutta fine a Marzaglia, qualche
anno fa
http://www.corestore.org/5360-9.jpg
:-)
--
_________
Simone DG
_________
Dino.Baldi
Vi ricordo che a Pavia, in una zona purtroppo non riscaldata della
nostra sede, giace in attesa di una giornata dedicata (magari un
weekend di primavera?)
questo gingillo:
http://compvter.it/IBM_5360-System-36
...ho appena recuperato il suo terminale da un sottoscala...
Dino
comPVter
supervinx
Potrei sempre chiederti qualcosa per corrispondenza :)
Non è che sono completamente neofita sulle riparazioni ... la schede (2)
sono piccole, magari per uno più esperto di me è più semplice
identificare le funzioni.
Quando lo aprii, il problema principale era capire cosa facesse, perchè
ricevesse sia una tensione elevata in alternata sia la +5 e +12.
Magari, se mostro qualche foto ci capiamo meglio.
Il tempo di sgombrare il piano di lavoro dalle macchine in lista
d'attesa :P
fm
CUT
Ciao fm, ogni tanto ti leggo di là su it.comp.as400 e mi fa piacere trovarti
anche qui a raccontare aneddoti. :-)
ciao..:-)
>Io su un vero 36 stavo per lavorarci,
>ma alla fine non se n'è fatto nulla, peccato perché mi sarebbe piaciuto. Si
>trattava di un cliente che due o tre anni fa aveva pure lui ancora un 5363
>in produzione. Sempre un paio di anni fa mi capitò di andare per un lavoro
>presso una nota società di Bologna che si occupa di assistenza hardware a
>prodotti IBM (cioè: se serve un pezzo introvabile o ce l'hanno loro o non
>ce
l>'ha più nessuno)
di questa società mi piacerebbe sapere il nome, visto che ho un 5362
da riparare....:-)
CUT
>Il 5362 non era significativo? Un ex frequentatore di questo NG (Hkz, dove
>sei finito?) ne aveva recuperato uno funzionante ed era uno spettacolo. :-)
il 5362 aveva meno prestazioni ma un formato compatto (per l'epoca!)
quindi era possibile posizionarlo in un ufficio, cosa che per il 5360,
molto
piu' rumoroso, era abbastanza improponibile...
> 2) Il 5364 al momento del suo lancio era solo il modello piu' economico,
> parecchio disprezzato dagli tecnici addetti ai lavori (ma non dai
> commerciali!)
Ho sempre sospettato che fosse un po' la stessa cosa dei P01/P03 in ambito
AS/400. Per quanto pure quelli il loro lavoro l'hanno fatto: quello che ho
io viene da uno studio di commercialisti (classico software Zucchetti) e
pare gestisse cinque o sei utenti interattivi senza troppa fatica.
Il P01/P03 lo conosco bene, li ho avuti presso clienti per vari anni,
pero' ...quando alla fine uno di essi e' passato al mod.
150....quest'ultimo
in confronto gli sembrava velocissimo.
Ovviamente il poter far lavorare 5 o 6 utenti "senza fatica" dipendeva
molto anche dal software applicativo usato...
> perche molto ma molto piu' lento non solo del 5360 ma anche del 5362.
Non oso pensare alla velocità. Una mia collega mi raccontava di compilazioni
che duravano mezzi pomeriggi su un 5360, chissà sul 5364... Ma secondo te un
5363 era più veloce anche del 5360 più potente?
No, erano comunque di fascia "entry"....i grandi 36
avevano anche loro 512 Kb di Ram (1024 ?) e 2 o 4 unità a disco,
da 200Mb , forse anche da 400Mb (?)....
CUT
>> I file ad indice ad accesso immediato del S/36 permettevano sia
> letture/scritture random che letture sequenziali IN TEMPO REALE,
> caratteristica poi migrata anche negli ultimi release del S/34 (attributo
> IFILE-YES nella // FILE NAME).
>Sul 34 se non sbaglio invece si doveva fare una KEYSORT dopo la chisura del
>file per vedere i nuovi record, no? Cosa non faceva il 34 senza IFILE-YES?
i record aggiunti fuori senquenza potevano essere letti con accesso
random per chiave (CHAIN) ma non venivano trovati in lettura sequenziale...
> 4) Non e' vero che i files avevano dimensione (numero di record) fisso.
> il files potevano essere dichiarati nei programmi che li utilizzavano con
> la parola chiave EXTEND....
CUT
>Semplificato no, rudimentale rispetto agli standard odierni, oserei dire
>sì.
>Che poi facesse bene il suo lavoro è un altro paio di maniche, però anche
>giocando con SSP 7.5 nella M/36 ho avuto un'impressione strana, sarà forse
>per certi pannelli con un aspetto un po' "artigianale" rispetto a quelli di
>OS/400, magari con qualche campo non proprio allineato con gli altri, o
>cose
>del genere, però mi è sembrato un po' poco rifinito nell'interfaccia
>utente,
>e più in generale un po' grezzo. Ma è anche vero che stiamo parlando di un
>sistema operativo di un'altra epoca, che faceva quel che faceva con risorse
>relativamente piuttosto limitate. L'abito non fa il monaco. :-)
diciamo che fino al 1995 circa per le applicazioni gestionali si usava
ancora l'interfaccia a caratteri e piu' che era semplice e facile da usare
e piu' veniva apprezzata (concezione "militare").
Successivamente si sono diffuse (soprattutto nel mondo pc) schede grafiche
sempre piu' avanzate e gli schermi a colori, mentre parte della clientela
"militare"
e' stata sostituita da aziende dello spettacolo, musica, cinema,tv...che
volevano
un'interfaccia utente diversa.
> I files del S/34 e del S/36 erano contigui sul disco....a garantire la
Ma quindi se un file era pieno e non c'era spazio contiguo, l'estensione di
cui si diceva sopra falliva? O riusciva a farla altrove sul disco?
> deframmentazione del disco (quando ancora questo termine era praticamente
> sconosciuto ai piu') ci pensava la procedura COMPRESS.
Be', nel mondo Digital, anche solo parlando di VAX/VMS, il concetto era già
conosciuto, studiato e risolto in vari modi. Ecco, se faccio un paragone tra
l'impressione di primo acchito data da un VMS - anche molto vecchio, più o
meno coevo di SSP - e da SSP rilevo che VMS trasmette un'immagine secondo me
molto più ingegnerizzata, industrializzata e standardizzata rispetto a SSP.
Questo intendevo dire con le definizioni "artigianale" e "grezzo" per SSP.
Beh ovviamente il S/34 ai primi anni '80 era la macchina "per il vasto
pubblico"..
mentre il clou della tecnologia Ibm era ancora nei mainframe.
> 7) il libro nero del 36 era il "S/36 Data Areas and Diagnostics Aids"
> (su cui ahime' non ho mai potuto mettere le mani) con esso si potevano
> fare
> cose magiche, come, ad. es, impostare con la procedura PATCH quell'unico
> byte che sul S/34 (e temo anche sul 36) disattivava TUTTE le password !!!
>Se ti interessa ho della documentazione interessante in proposito, raccolta
>parecchi anni e fa e se non sbaglio anche testata con successo su SSP 7.5
>(per M/36): è spiegato come interpretare certi settori bassi del disco e
>decodificare le password degli utenti. :-P
Interessa Interessa....:-)
> 8) con il prodotto programma Ibm IDDU si potrevano anche sul S/36, creare
> dei files con DEFINIZIONE ESTERNA, forse utilizzabili solo col DFU
> (?)...ma
> l'idea c'era.
>Quasi certamente le definizioni IDDU servivano anche per il Query/36 e per
>le funzioni del Displaywrite/36 similari alla stampa unione di Word.
Giusto, mi ero dimenticato della TEXTLIB....
CUT
>Dato che ci siamo ne approfitto per una domanda: sai mica sul 38 cosa c'era
>al posto del PDM? Solo il menù del programmatore?
non saprei....ci vorrebbero i 38isti...:-)
>Un paio di screen-shot di ISPF e XEDIT:
>http://www.ibm.com/developerworks/university/images/mf_2010/screen7.PNG
http://www.tombrennansoftware.com/edit.gif
> P.S. Ho buone speranze di recuperare fra qualche giorno
> un AS/400 mod. Y10, fermo ormai da molti anni,
> non fatevi ingannare dal nome...e' ancora una volta un S/36 !!!
>Se hai un AS/400 con la V4 e ti interessa, ho qui il CD con SSP R7.5 per
>M/36 (vedi WRKM36) e relative PTF...
Ce l'ho !...e tu hai un'email da poter indicare qui sul NG?
>Ciao, :-)
G.
Ciao
fm
shadoooo
Avete fatto le copie dei dischi prima di metterli all'umido nel
sottoscala vero?
Ciao
ger...@no.spam.mail.com
<dino....@gmail.com> wrote:
> Vi ricordo che a Pavia, in una zona purtroppo non riscaldata della
> nostra sede, giace in attesa di una giornata dedicata (magari un
> weekend di primavera?) questo gingillo: http://compvter.it/IBM_5360-System-36
> ...ho appena recuperato il suo terminale da un sottoscala...
Infatti ci pensavo proprio qualche sera fa. Io sono disponibilissimo per
fare un "5360 day", basta trovare un po' di gente interessata e organizzare,
però sarebbe meglio sapere prima se la macchina almeno si accende: sarebbe
un peccato farsi il viaggio per poi scoprire che non dà neppure segni di
vita! Poi se ci sono problemi software, si prova a risolverli insieme. :)
Una cosa: nella scheda sul vostro sito c'è scritto che ha un processore Z80
con 64 kB di RAM... Be', non è vero: il processore era del tutto custom e la
RAM di solito viaggiava almeno sui 512 kB (vero fm?).
Ciao,
G.
ger...@no.spam.mail.com
> di questa società mi piacerebbe sapere il nome, visto che ho un 5362
> da riparare....:-)
Scrivimi che te lo dico (vedi più avanti).
> Non oso pensare alla velocità. Una mia collega mi raccontava di compilazioni
> che duravano mezzi pomeriggi su un 5360, chissà sul 5364... Ma secondo te un
> 5363 era più veloce anche del 5360 più potente?
>
> No, erano comunque di fascia "entry"....i grandi 36
> avevano anche loro 512 Kb di Ram (1024 ?) e 2 o 4 unità a disco,
> da 200Mb , forse anche da 400Mb (?)....
Il 5362 di quell'ex frequentatore del NG di cui dicevo aveva una scheda di
memoria con scritto "1024", che chiaramente era un Megabyte di RAM.
> diciamo che fino al 1995 circa per le applicazioni gestionali si usava
> ancora l'interfaccia a caratteri e piu' che era semplice e facile da usare
> e piu' veniva apprezzata (concezione "militare").
Anche oggi. Senza considerare tutte le aziende che continuano imperterrite a
vivere di ambiente 36 e QS36F. :P
> Interessa Interessa....:-)
Scrivimi... :P
> Ce l'ho !...e tu hai un'email da poter indicare qui sul NG?
La mail con cui scrivo è valida, basta levare l'ovvio "no.spam" e quindi
lasciare dopo la chiocciola solo "mail.com". :)
Ciao,
G.
ger...@no.spam.mail.com
> doh.. grazie ad una foto del sito segnalato, ho forse capito la
> provenienza di 4 schede, salvate da una brutta fine a Marzaglia, qualche
> anno fa
Non è detto: quel formato fu molto usato negli anni 70-80 dall'IBM, anche
per sistemi molto diversi. Magari è roba di un 36, magari no... Se lo trovi
sulla scheda, prova a cercare il part number con Google: potresti scoprire
qualcosa di interessante. :)
Ciao,
G.
fm
> Vi ricordo che a Pavia, in una zona purtroppo non riscaldata della
> nostra sede, giace in attesa di una giornata dedicata (magari un
> weekend di primavera?) questo gingillo:
> http://compvter.it/IBM_5360-System-36
> ...ho appena recuperato il suo terminale da un sottoscala...
>Infatti ci pensavo proprio qualche sera fa. Io sono disponibilissimo per
>fare un "5360 day", basta trovare un po' di gente interessata e
>organizzare,
>per� sarebbe meglio sapere prima se la macchina almeno si accende: sarebbe
>un peccato farsi il viaggio per poi scoprire che non d� neppure segni di
>vita! Poi se ci sono problemi software, si prova a risolverli insieme. :)
>Una cosa: nella scheda sul vostro sito c'� scritto che ha un processore Z80
>con 64 kB di RAM... Be', non � vero: il processore era del tutto custom e
>la
>RAM di solito viaggiava almeno sui 512 kB (vero fm?).
il "case" esterno del 5360 (vedi foto sopra) era lo stesso per varie
configurazioni,
mi ricordo che un modello entry con solo 60Mb di disco
(forse accettava anche solo un disco da 30)....idem per la ram:
probabilmente
le configurazioni piu' diffuse erano quelle con 256 o 512, pero' non
escluderei anche
un valore minimo di 64 o 128
ciao
fm
Ciao,
G.
DG
> Se lo trovi sulla scheda, prova a cercare il part number con Google:
> potresti scoprire qualcosa di interessante. :)
messo nella To do list, non appena le riesumerò darò un altra
occhiata... al tempo però non mi pare di aver trovato codici utili a
riconoscerle