Newsgroup: it.comp.retrocomputing
Titolo: IBM 5363: manuali e sistema operativo?

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

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

Dovrei avere qualcosa, software, a corredo del mio S/36 5634 (il Baby/36).
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

 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.

M'avete fatto ricordare una cosa :)
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 :)

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

 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.

 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.

 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.

 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.

 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.

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

Ne viene fuori la descrizione di un sistema "pesante", in tutti i sensi.
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 ?

 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.

 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.

 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.

 
Sono arrabbiato nero sull'argomento :)
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 :)

A me sembra piuttosto interessante questo macchinone...
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

 attenzione quando mi distendo sulla sedia ... certe zuccate :)
Pensa se fosse stato un 5360: 
http://www.corestore.org/36.htm
 :-)
Ciao,
G.

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


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

 Chissà se riuscirò a riesumarlo :)
Speriamo di si !...:-)
ciao
fm

 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.

 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
_________ 

Il discorso è articolato e molto interessante.
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

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

Ciao, :-)
G.
Ciao
fm 

Fico.
Avete fatto le copie dei dischi prima di metterli all'umido nel
sottoscala vero?
Ciao


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

 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.

 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.

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.

 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
