Newsgroup: it.comp.os.os2
Titolo: spiegatemi questa please:

Ciao all,
tempo fa si diceva che os2 (prima del fix13) poteva allocare in
totale solo 512 MB per l'arena privata? Ossia da 4 GB a 0.5 GB c'era
l'arena di sistema e sotto sia le arene private che condivise... per
cui la somma di tutti i programmi che vi lavoravano piu' le DLL non
poteva superare i 512 MB?
Ebbene... come mai allora io sto attualmente occupando la bellezza di
934MB di memoria?
Ossia, la cosa non mi convinceva, cosi' ho fatto un programmino cretino
che alloca enormi vettori... ho aperto 8 copie di questo programma
facendo allocare a ciascuna copia 100 MB... il sysinfo mi da
che in effetti c'e' una sbrega di memoria consumata (notare che il
vettore non e' solo allocato, e' anche riempito di caratteri a caso), e
memoria che per forza dovrebbe stare sotto i 512 MB... almeno che la new
del gcc non allochi in arena di sistema, ma dubito...
Ciao 
        /^\
       / - \ntonio
 -+- Internet: 
aarregh-at-libero.it
 -+- Team Os/2 Italia
 -+- PGP Public Key Available on request
 -+- Homepage: 
http://digilander.iol.it/arrex
 -+- The Arrex/2... powered by Os/2 Warp 4... proud to be 100% Micro$oft 
free
--- ProNews/2 1.5 + Os/2 Warp 4
* Origin "Human Disasters: Hiroshima '45, Chernobyl '86, Windows '95


se non erro, e` la memoria per ogni processo che non puo` superare il 
limite dei 512, ma
piu` processi possono. Virtualmente ognuno di quei processi alloca i 
propri 100MB
da qualche parte nel proprio spazio virtuale che dovrebbe andare da 0[*] 
a 512MB.
Ma non mi sono mai documentato come, dove e quando la cosa funzioni.
[*] 0 probabilmente non e` veritiero... non so se OS/2 abbia la propria 
memoria riservata sotto,
sopra o in altri posti... come ti ho gia` detto in precedenza non ho mai 
letto doc tecnica sulla cosa.
-- 
ciao, Mirco.
[ 
http://www.quasarbbs.net/mircomir/
 ] [ Icq#:51640305 ]
[ 
http://www.quasarbbs.net/pido2/
 ]
 ******************************************************
  Important:                               Importante: 
 
  @
msn.com
, @
excite.com
, @
sina.com
, @
dispensa.com
, 
  @
prontomail.com
, @
freeze.com
, @
ieg.com.br
 
  are deleted by mail spam filter           
  vengono cestinati automaticamente         
 ****************************************************** 

 
Io non ne so nulla, ma nella documentazione di XWorkplace c'e' una 
paginetta in cui si parla della cosa, che ti quoto:
 
" Come si sa, i processori 80386 e superiori utilizzano 
 32 bit per tutti gli indirizzi, il che permette di 
 indirizzare fino a 4 GB di memoria. Questo Š 
 generalmente chiamato "spazio di indirizzamento 
 virtuale ("virtual address space"). 
 Si noti che questo spazio di indirizzamento esiste a 
 prescindere dalla quantit… di memoria fisica installata 
 nel sistema. Uno dei vantaggi maggiori del processore 
 80386 (rispetto ai suoi predecessori) Š infatti la 
 capacit… del processore di convertire un indirizzo 
 virtuale in un indirizzo fisico RAM hardware -- con 
 un minimo aiuto da parte del sistema operativo (nel 
 nostro caso OS/2), che deve solo fornire le tabelle 
 processore dove registrare i dati di conversione. 
 Per poter gestire la memoria virtuale rispetto ai vari 
 processi attivi nel sistema, OS/2 divide i 4 GB dello 
 spazio di indirizzamento virtuale in arene. 
  4096 MB -----------------------------------------------------
                 arena di sistema
   512 MB -----------------------------------------------------
                 arena condivisa
   variabile ----------------+------------+---------------
                  arena      | arena      | arena
                  privata    | privata    | privata
                  processo 1 | processo 2 | processo 23
     0 MB -------------------+------------+---------------
 
 L'arena di sistema Š lo spazio riservato al codice 
 che lavora a ring 0, cioŠ i programmi di controllo per 
 i dispositivi e il kernel OS/2 stesso. Le applicazioni 
 normali non possono accedere a quest'area. 
 Al contrario, sia l'arena condivisa che quelle 
 private sono accessibili a tutte le applicazioni. 
 Mentre le arene di sistema e condivisa sono ospitate 
 nelle stesse pagine di memoria fisica, l'arena privata 
 Š differente per ogni processo: ciascuna applicazione 
 ha infatti la sua memoria privata riservata (codice e 
 dati). L'arena condivisa Š invece utilizzata per codice 
 e dati che possono essere condivisi tra le 
 applicazioni: le DLL, per es., vengono tutte caricate in 
 quest'area. 
 Il confine tra l'arena condivisa e quelle private Š 
 variabile e dipende dalla quantit… di memoria 
 condivisa usata dal sistema. E' infatti possibile 
 "esaurire la memoria" del sistema caricando troppe 
 DLL. Nella realt…, in un caso del genere il sistema non 
 ha affatto esaurito la memoria fisica (nel qual caso 
 verrebbe semplicemente allargato il file di appoggio); 
 ha invece esaurito lo spazio di indirizzamento. 
 In tutti i kernel OS/2 dal 2.0 al 4.5 escluso (il kernel 
 Aurora), il limite per la memoria riservata alle 
 applicazioni era fisso a 512 MB, per consentire un 
 facile supporto per le applicazioni 16 bit, che 
 avrebbero avuto difficolt… ad accedere alla memoria al 
 di sopra di quella linea. 
 Questo limite Š stato modificato a partire dal kernel 
 Aurora, che consente alle applicazioni di allocare 
 memoria oltre la linea dei 512 MB, se 
 VIRTUALADDRESSLIMIT in CONFIG.SYS Š 
 impostato ad un valore superiore a 512. In questo 
 caso, lo spazio di indirizzamento appare cos : 
  4096 MB ---------------------------------------------
                 arena di sistema
  VIRTUALADDRESSLIMIT ---------------------------------
                 arena memoria alta (condivisa e privata)
   512 MB ---------------------------------------------
                 arena condivisa
   variabile ----------------+------------+---------------
                  arena      | arena      | arena
                  privata    | privata    | privata
                  processo 1 | processo 2 | processo 23
     0 MB -------------------+------------+---------------
 
 Come si vede chiaramente, lo spazio tra l'arena di 
 sistema e quella condivisa si chiama "memoria alta", 
 ed Š diviso anch'esso tra arena condivisa e arene 
 private. La memoria alta Š assegnata solo alle 
 applicazioni che la richiedono esplicitamente, perci •, 
 anche se abilitata, pu• essere utilizzata solo da quelle 
 applicazioni che ne prevedono l'esistenza. La macchina 
 virtuale Java OS/2, per esempio, usa questa arena 
 "alta" se si specifica SET JAVA_HIGH_MEMORY=1 
 in CONFIG.SYS. 
 Abilitare la memoria alta ha per• anche delle 
 controindicazioni. Come si Š detto, questa regione non 
 Š accessibile dal codice a 16 bit. Per questo motivo, 
 se si usa la memoria alta con Java, bisogna usare 
 un'implementazione a 32 bit del TCP/IP (qualunque 
 versione dalla  4.1 in su). 
 Inoltre, pi— elevato Š il valore 
 VIRTUALADDRESSLIMIT, minore Š lo spazio per 
 l'arena di sistema; Š per questo motivo che aumentare 
 il limite per l'indirizzamento virtuale pu• ridurre il 
 numero di processi disponibili. "
 
(Guida in linea di XWP, sezione "Il Virtual Address, Space")
-- 
ciao
Gabriele

 paginetta in cui si parla della cosa, che ti quoto:
ho letto quella pagina e proprio per questo non mi spiego il fenomeno: la' 
dice che si puo' arrivare solo fino a 512 MB, qui arrivo a 900 e passa... e 
senza usare il kernel aurora (ho warp 4 fix 12). Inoltre sarei arrivato a 
ben di piu' volendo....



prova a fare allocare tutti i 900MB allo stesso processo. Non dovrebbe 
funzionare.


 funzionare.
d'accordo, ma questo non e' il problema in questione... il fatto 
(rompiballe) sarebbe che non puoi avere n processi con 512 MB a testa, ma 
solo 1 con 512 (stando a quelle docs di xwindows). D'altronde quei doc 
parlano esplicitamente di una macchina virtuale con 4GB di cui i primi 512 
condifisi tra tutto quello che serve (dll e applicazioni) e 3.5 GB per 
l'arena di sistema (che ha poca roba + le cache). Per cui sarebbe veramente 
frustrante... ma alla luce di quanto succede, come si spiega questo fatto?



devo rilegere quella doc, ma a me non sembra che dicesse cosi`.
Il fatto e` che ogni processo ha uno spazio di indirizzamento virtuale 
che va da 0 a xxx.
Questo serve per far si che ogni processo creda di avere a disposizione 
tutta la macchina e
possa allocare memoria contigua. E' tutto gestito dall'HW intel, in 
particolare dal gestore di
memoria virtuale. Tutti i dettagli non li ricordo (lo studiai vari anni fa).
Anzi, ho appena tornato a leggere la doc postata da Gabriele ed e` giusta!
Infatti dice che divide lo spazio (4GB) di indirizzamento *virtuale* di 
ogni processo in
512MB e 3.5GB (per dirla in parole povere). Quindi ogni processo ha a 
disposizione 512MB
e quindi torna anche con la prova pratica che hai eseguito col tuo prg.


 
Ma non e' che hai impostato (tu  o qualche programma di installazione)
VIRTUALADDRESSLIMIT a un valore superiore a 512?
-- 
ciao
Gabriele

memoria riservata sotto, sopra o in altri posti... come ti ho gia` detto 
in precedenza non ho mai letto doc tecnica sulla cosa.
E' stato uno dei limiti di OS/2 fino al fix 13 e ad Aurora. Lo spazio di 
indirizzamento dei processi era entro i 512M, e da 512M in su fino a 4G era 
tutto di OS/2. Il perche'? Per motivi di compatibilita' con le vecchie 
versioni per 286! Se non erro. Questo ha portato ad una mancanza cronica di 
applicazioni di alto livello: un uso reale di DB, programmi di editing 
video, grafica avanzata ecc...
Ora questo limite (stupido come: SIQ, GRADD non finiti, DART non finiti, 
config monolitico, compilatore SOM sparito, ecc...) finalmente è sparito. 
Purtroppo ora le aziende che potevano sviluppare ad alto livello per OS/2 
sono di fatto sparite. Speriamo in eComStatio!
Ciao,
 Claudio

 VIRTUALADDRESSLIMIT a un valore superiore a 512?
virtualaddresslimit funziona solo con il kernel Aurora, io ho warp 4 + fix 
12... ossia kernel warp4! E comunque per accedere a virtualaddressspace 
dovrei usare apposite funzioni che non credo sia supportate dal mio vecchio 
gcc 2.8...


 e quindi torna anche con la prova pratica che hai eseguito col tuo prg.
che senso hanno pero' allora gli spazi per la memoria Condivisa?!? Cioe', 
assumento che ogni modulo a ring 0 avesse la sua macchina virtuale da 4GB 
fatta cosi' (cosa che non puo' essere vera, perche' la somma di tutti gli 
indirizzi non puo' superare 2^32), lui dovrebbe scrivere da 512MB in su... 
vabbe', ci puo' stare!
Ma poi mi scrive: a seconda di quante DLL carichi lui parte da 512MB in 
giu'... forse la memoria condivisa ha una macchina virtuale tutta sua per 
cui non carica piu' di 512MB... ma allora perche' dice che i programmi 
possono arrivare ad una dim massima di 512MB - lo spazio indirizzato dalle 
DLL?!??!
Qui c'e' qualcosa che non ha molto senso... e non riesco a saltarne fuori...
non dormo piu' la notte! ;-)))



qua bisognerebbe vedere come e` scritto OS/2 e come funziona (e io non 
lo so).
Ma provo lo stesso a dare una spiegazione (da prendere con le molle):
La tua applicazione deve usare delle parti del sistema operativo che 
quindi devono
essere presenti nel suo indirizzamento virtuale al momento del suo 
avvio. Questo codice
e` quello condiviso dal SO e probabilemnte ogni processo lo vede nella 
stessa locazione
di memoria che per scelta di implementazione e` quella sopra i 512MB.
cmq, il fatto e`: hai provato a lanciare il tuo prg e fargli allocare 
questi benedetti ~512 MB
(in un unico processo)?


Dimenticavo...
Alessandro o Yuri di sicuro lo sanno meglio di me come funziona la cosa, 
prova
a chiedere a loro :-)


 (in un unico processo)?
mi sono fermato a 256... la new non vuole allocarne piu' di 128 per 
vettore... poco male, sembra perfettamente plausibile che si fermi a 512MB 
per processo, ma ripeto non e' questo il problema... :-) E' seccante montare
1 GB di ram e sapere che ne usi solo 512 (+le cache e il ring0 che stanno 
altrove, ma roba da poco)... questo dicono quelle fottute docs.... :-((((((


 a chiedere a loro :-)
avevo scritto qui perche' speravo di trovare qualcuno di passaggio ;-)) 
Provero' a scrivere in posta privata... poi magari posto qui quanto mi 
dicono...


 
Fine del discorso: dovresti essere limitato a 512 Mb di arena 
condivisa e punto.
Non e' che c'e' un errore nel misurare la memoria utilizzata? Usi 
Theseus?
-- 
ciao
Gabriele


ma difatti non e` cosi`!!! se hai 2 processi, gia` e` usata tutta xche` 
una pagina
di un prg  puo` tranquillamente essere allocata ad es. a 700MB di 
memoria fisica.
Quando usi la memoria virtuale, il prg vede memoria contigua, ma le 
varie pagine sono
allocate sparse nella memoria fisica.


 Theseus?
si, theseus... ma anche lo swapfile era a 970 MB... ma mi e' venuta un'altra
idea: forse fantasia... ne sto parlando con Yuri, posto qui il messaggio che
gli ho scritto:
--------------
Potrebnbe essere che la memoria di Os2 e' a L (o a T rovesciata se
preferisci). Gli indirizzi si sviluppano in verticale, ma tutti i
processi hanno gli stessi indirizzi; ossia il processo 1 inizia a 0MB e
termina a 512MB, il processo 2 pure, il 3 pure e cosi' via fino a 1024!
Al momento del context switching os2 vede il PID a cui sta lavorando e
sa che per indirizzo 2F (ad esempio) deve leggere tra tutti i 2F (ogni
applicazione attiva ne ha uno) quello che ha l'identificativo del PID
su cui sta lavorando... La cosa avrebbe senso allora e avrebbe anche
senso non solo il fatto che sono risucito ad allocare 900 MB in totale,
ma anche il fatto che le librerie hanno addressing limitato: l'arena
condivisa ha come limite inferiore IL PIU' ALTO tra gli indirizzi
assegnati. Questo perche' se lavoro proprio su quel programma
l'indirizzo di memoria corrisponderebbe sia a quello della DLL, sia a
quello di un pezzo del programma stesso.
DLL e arena di sistema sono sempre "vedibili" per cui devono avere un
indirizzo univoco, i programmi no, hanno indirizzi condivisi ed e' il
kernel che si occupa di non fare confusione...
Ha senso questa teoria?


processi hanno gli stessi indirizzi; 
Ovvio: altrimenti, perche' la chiamerebbero memoria virtuale?? E a
cosa servirebbe il context-switching??
Piu' o meno a grandi linee: ogni processo ha access all'area di
memoria virtuale, ovvero, *lui* crede di avere *tutta la memoria solo
per lui in realta' il sistema gli crea un'immagine di memoria (che
inzia *sempre* a 0000 ...) all'interno della quale puo' allocare la
sua memoria (che in realta non viene allocata, almeno, secondo quanto
mi ricordo del discorso di Sparse memory...)
Quando la macchina fa lo switch fra due processi, tutti gl indirizzi
virtuali vengono 'mappati' sulla memoria reale...
Obelix

1 GB di ram e sapere che ne usi solo 512
Per processo. Se lanci due processi, usi 1 gb. Se ne lanci tre, usi
anche 1,5 gb. 
Ma chettenefai di 512mb?? Io in ufficio li ho, tengo aperto Notes, tre
sessioni di pc5250, un paio di netscape (settato con 99 mega di Ram
Swap) Dnetc per sfruttare il tempo che passa idle e cane se vado mai
sotto i 380mb di memoria libera..... ah, video 1280x1024 con Object
Desktop, casomai mancasse il riferimento...
...pensa che il 400 che ho in sala macchine regge 150 utenti che
smanettano a tutto spiano e usa si e no la stessa RAM che serve al mio
PC per me solo...
Obelix

 PC per me solo...
400 cosa? MHz?


 virtuali vengono 'mappati' sulla memoria reale...
ok, tutto chiaro allora... arcano risolto... tnx...


beh... a copiare i registri, a sistemare il program counter, ecc.... ;-)
No, il context-switching serve a rimappare gli indirizzi 'virtuali'
della memoria vista dal processo negli indirizzi dellamemoria reale
(e' per questo che il '400 fa dei CS velocisismi: non usa la memoria
virtuale, e quindi non deve ripassare tutti gli indirizzi  :-))
Obelix

400 cosa? MHz?
As400, grosso coso nero che...
Obelix

In article <t0H67KFRKfPp-pn2-dBy9CdPXS09m@elettra>,
aarregh@-AT-libero.it (Antonio Arreghini) wrote:
 >> cmq, il fatto e`: hai provato a lanciare il tuo prg e fargli allocare 
 >> questi benedetti ~512 MB
 >> (in un unico processo)?
 >
 >mi sono fermato a 256... la new non vuole allocarne piu' di 128 per 
 
malloc... o DosAllocMem(&pvoid, size, PAG_READ | PAG_WRITE | PAG_COMMIT);
 >vettore... poco male, sembra perfettamente plausibile che si fermi a 512MB 
 >per processo, ma ripeto non e' questo il problema... :-) E' seccante montare
 >1 GB di ram e sapere che ne usi solo 512 (+le cache e il ring0 che stanno 
 >altrove, ma roba da poco)... questo dicono quelle fottute docs.... :-((((((
ancora non hai capito che non c'e' corrispondenza tra memoria virtuale e
memoria fisica ? Facendo finta che la memoria condivisa sia 0, se hai
10 processi che usano, ciascuno, 128 MB di memoria virtuale, il tuo
GB di memoria fisica verra' utilizzato al 100 %
-- 
bye
Alessandro Cantatore

:
...

Infatti il processo è il seguente. 
Quando viene compiuta la commutazione di contesto, cioè un altro processo 
prende l'uso del processore, vengono salvati (lasciamo perdere dove) tutti 
i dati del processo che viene momentaneamente sospeso e vengono caricati 
quelli necessari al nuovo che viene messo in esecuzione. Ogni processo 
"usa" indirizzi logici per la propria memoria, ovvero esistono strutture 
dati particolari (appartenenti solo al processo in esame) che mappano tutto 
ciò che usa o "userà (mi permetto alcune libertà)" durante la sua vita, 
compreso quello che è necessario per la sua esistenza. Nel sistema 
operativo esistono programmi, chiamati nella teoria dei SO, gestori della 
memoria, che dato un indirizzo logico, lo mappano in un indirizzo fisico; 
questo indirizzo, se non ricordo male,  e trascurando per ora i problemi 
della memoria virtuale (in generale sono indirizzi fisici su disco), non 
può superare i 512M, dovuto alla compatibilità con il passato derivante dal 
formato di alcune strutture dati usate per la citata mappatura. Uno dei 
problemi (ora si parla di OS/2) che ha determinato questa limitazione e che 
alcuni programmi derivati da Windows (ricompilati o eseguiti in emulazione) 
non funzionavano perché usavano indirizzi superiori a 512M.
Posso dire che nel caso di OS/2 non so bene i particolari (conosco solo il 
limite citato), ma gli indirizzi che usa un processo in esecuzione 
(indirizzi logici) non centrano con quelli che usa il SO per eseguirlo e 
sono proprio questi quelli con la limitazione in questione.
Basta, ciao a tutti.
Claudio

:

Detta cosě mi induci a risponderti che allora č un SO primitivo, ma sapendo 
che ciň che hai detto viene fatto per questioni prestazionali....
Ciao,
 Claudio

 As400, grosso coso nero che...
ah... pensavo un K6 400... ;-)) beh, meglio As400... ;-)



grazie, ma non lo so xche` non me ne e` mai fregato nulla... consigliali 
ad Antonio :-)


cosa, sotto certe condizioni 150 utenti li attachi pure a un 386.
150 utenti che fanno HDDE pesante e interrogazioni su DB da 3-4 milini
di record con temi di risposta *medi* sotto gli 0,3 secondi????
Non so perche', ma ho dei dubbi (ah, otto sono *programmatori*...
:-))
Obelix

Detta cosě mi induci a risponderti che allora č un SO primitivo,
Gia'. Non si capisce perche' ma appena uno va fuori dai quello che
potremmo chiamare 'il branco' gli rispondono cosi'. 
Per lo stesos motivo, potrei dirti che e' leggermente idiota ripassare
tutti gli indirizzi da virtual a fisico ad ogni CS. E lo e': se avessi
io dei programmi che fann 'ste cose, li considererei idioti...
Obelix

Obelix
So quanto sia avanzato OS/400, ma il problema è di carattere de tutto 
generale. La mappatura degli indirizzi non viene fatta nella commutazione 
del contesto (qui si cambia solo la struttura dati che descrive il 
processo), ma a tempo di esecuzione: ogni indirizzo usato dal programma 
viene ricodificato in indirizzo fisico, questo può essere sia in RAM che in 
Swap su disco. E' il gestore della memoria si occupperà di individuare le 
informazioni. Il vantaggio è che uno usa tutta la memoria che vuone 
indipendentemente dalla RAM installata, a discapito delle prestazioni.
Ciao,
 Claudio

indipendentemente dalla RAM installata, a discapito delle prestazioni.
Il problema e0 ch elo fa anche AS400, e senza perdere in prestazioni,
anzi guadagnandoci. e di brutto, sulle routine di controllo delle
allocaizoni di memoria..
Obelix

 
Mah, non qui. Devo dire che come browser ormai mi soddisfa piu' del 
4.61.
-- 
ciao
Gabriele


a me dava problemi la 0.9.5 (e solo quella).
Ora uso la 0.9.7 (pure in ITA) e il sistema non fa una piega. Provala.
PS: nemmeno mozilla fa na' piega... se non lo chiudo io lui va felice e 
contento
per ore!!


pazzo con la gestione della memoria.
E perche' mai?? anzi, vai meglio.... una volta che hai un indirizzo
dimemoria questo sara' assoluto, quindi se devi verificare, chesso',
delle contese di memoria fra i programmi, non devi perdertri in
assurdi conteggi.
Obelix

rimediato.
Vacca di una troia, mi devo ricordare di prenderne una borsata in
ufficio...
Obelix

assurdi conteggi.
La "rimappattura" esiste sempre, può essere statica (poco flessible, 
performante nei vecchi sistemi, e ora antiquata) o dinamica.
Consiglio di leggere "Sistemi Operatici" di Maestrini della MCGrallHill, 
dove il solo capitolo della gestione della memoria è di circa 100 pagine (e 
il codice generale in pseudo linguaggio del Gestore della Memoria per 
partizionamento dinamico e gestione dello swap supera le decine di pagine). 
Ormai tutti i SO fanno così tranne quelli che sacrificano la flessibiltà 
per ottenere prestazioni massime. Ma sono proprio pochi.
Ciao,
 Claudio


Io ho Warp 4 con installato il Fixpak di ACP :-)
MPTS8610 (giusto per non esagerare troppo)


Consiglio di leggere "Sistemi Operatici" di Maestrini della MCGrallHill, 
Il punto e' che ho letto *l'analisi di quel tipo di gestione* fatta da
chi ha scritto il 400, e la differente implementazione che ne e'
derivata. E' *tutto il concetto sottostante* che e' radicalmente
diverso. Tu stai cdercando di far stare uan certa visione dentro ai
limit che ti sono nti, mentre in realta' il sistema *cambia il
concetto stesso di limite*
Obelix

vai...
Direi di si, visto che i 400 sono fatti cosi'. Anzi, direi che
*proprio cosi* vai piu' avanti.
Obelix

una borsata? :-|
Ne avremo un 30-40, piu' le 20 che sono in asisstenza...
Obelix


Dico appunto. Il problema è che per questioni prestazionali si fanno tante 
scelte: anche se la rimappattura da indirizzi logici a fisici è 
apparentemente nascosta ed efficiente, questo non vuol dire che non ci sia.
Nei sistemi operativi per dispositivi portabili si usa una allocazione 
"statica". Ti faccio una domanda: se con AS/400 ho 400 utenti e di colpo se 
ne collegano altri 100 (o altri mille, tanto per superare i vari pool), 
dove vengono allocati se gli indirizzi se prima non ce li avevo né su 
memoria né su disco?
Ciao,
 Claudio
PS Non consiglio di leggere il libro da me citato, non perché le nozioni 
riportate siano scorrette o non attuali, ma perché è strutturato affinché 
uno si addormenti e ci si perda!

Obelix
Comunque mi hai fatto incuriosire di più sul OS/400. Vedrò di leggere 
qualche cosa. Anzi se hai documentazione sullo scheduling del citato OS/400 
sarei lieto di leggerla.
Ciao,
 Claudio


Beh, questo non e` fare da beta tester... xche` con una cfg come ho io se
solo provo a mandare un bug report, lo usano per pulirsi il culo!
Non ho una configurazione che IBM da per funzionante, quindi...
PS: il sistema cmq va che e` una meraviglia, l'installazione ha piu` di
2 anni (rifatta solo x cambio di disco fisso).


Un attimo! Io parlavo di schede ethernet per il 400.
AH, io pensavo aprlassi di schedee thernet per pc..
Obelix


beh, io ce l'ho sul computer di mio fratello, che hai ordinato la Ver. ITA?


arrivata la mail?
Direi di no, ma adesso so' a casa con 38,5 di febbre...
Obelix

..col twinax sul comodino, immagino! :-ppp
No, no, ho raggiunto unì'eta' in cui alle 18:00 apro il notes dicendo
'beh, vediamo che casini mi sono schivato oggi"  :-))
Obelix