Newsgroup: it.lavoro.informatica
Titolo: Secondo voi i jadisti europei (sono laureati mica picio picio)

conosceranno il cobol e il mainframe?
No perchè hanno detto che faranno saltare i sistemi informatici europei.
Per bucare un mainframe OCCORRONO 2 PALLE GROSSE COME UN GRATATCIELO.
Io dubito che in europa esista un allevamento per bambocciopni che sia 
in grado di insegnare come bucare un mainframe......anche se questi 
dovessoro montare websphere(java).
Mah! Chissa quali sistemi intendono far saltare!
-- 
(..) la rivoluzione non è un pranzo di gala, non è una festa letteraria, 
non è un disegno o un ricamo; non si può
fare con tanta eleganza, con tanta serenità e delicatezza, con tanta 
grazia e cortesia. La rivoluzione è un atto
di violenza, è l'azione implacabile di una classe che abbatte il potere 
di un'altra classe. (Mao Tze-tung)

 in grado di insegnare come bucare un mainframe......
 
Secondo me questo basta e avanza
 
http://upload.wikimedia.org/wikipedia/commons/a/a7/Cannone149G.jpg
 

 conosceranno il cobol e il mainframe?
 
Per fortuna no. Considerato che per calcolare una semplice sequenza di numeri di fibonacci devi scrivere un programma da 200.000 righe e che il numero di bug di un'applicazione dipende anche dal numero di righe di codice...

 Per fortuna no. Considerato che per calcolare una semplice sequenza di numeri di fibonacci devi scrivere un programma da 200.000 righe e che il numero di bug di un'applicazione dipende anche dal numero di righe di codice...
 
in realtà non avrebbero bisogno di conoscere cobol e mainframe. e a dirla
tutta non avrebbero bisogno nemmeno di bucare alcunché. 
 
quando si tratta di dialogare con altri sistemi ho visto soluzioni 
che voi umani non potete immaginare. pensa solo a cosa ti potrebbe 
architettare un personaggio come l'op se gli chiedessi "devo passarti
delle disposizioni di bonifico, come facciamo?". il massimo che può
arrivare è farti mettere un file di testo in una directory che poi
carica con un batch, ma ho visto anche di peggio.
 
in fondo al jadista non serve bucare nulla, basta infiltrare una persona
e affiancarla mezza giornata a delta11. di solito si dice che in sicurezza
il fattore umano è l'anello debole della catena, ma nel caso di questi
mammuth siamo di fronte ad un anello aperto. 
 
 
 

 Mah! Chissa quali sistemi intendono far saltare!
 
Non c'è nemmeno bisogno di farlo saltare. Stiamo parlando di un sistema 
che zompa da solo una volta a settimana: 
http://community.spiceworks.com/topic/193821-iseries-ipl-frequency
 
 
Gran bel sistema e complimenti a IBM: sono riusciti nella difficile 
operazione di superare in peggio persino windoze. 
 
-- 
Massimiliano Adamo


Muahuahuahuah:
 
I believe the "recommended" IPL for a system is monthly. Really it is a 
good practice because IPLing a system does more than just restart it does 
the following
 
    Resets disk storage. This results in increasing available disk storage
    Recognizes new licensed-program products
    Optionally applies delayed Program Temporary Fixes (PTFs)
    Recognizes some changes in system values
    Unused addresses are returned to the system
 
 
 
 
 
-- 
Massimiliano Adamo

Il 28/02/15 20:02, Max_Adamo ha scritto:

ma anche no.
 
quelle che hai postato non sono direttive di ibm e sono comunque 
retaggio di un vecchio modo di operare (è verissimo, nelle prime 
versioni dell'OS si consigliava IPL settimanali, pensa che anche oggi 
c'è chi fa IPL giornalmente :) )
 
IPL si fa solo giusto in occasione di installazione di fix (diciamo 
almeno una volta ogni sei mesi) e mi sembra ragionevole.
 
Ciao
 
-- 
http://www.linkedin.com/in/stefanotassi
 
 
 
Programming  today is  a race between software engineers  striving to
build  bigger and better idiotproof programs, and the Universe trying
to produce  bigger and better idiots. So far the Universe is winning.
(Rick Cook)

 almeno una volta ogni sei mesi) e mi sembra ragionevole.
 
caspita, dopo 30 anni hanno finalmente risolto :) 
 
-- 
Massimiliano Adamo

 ha scritto nel messaggio 
news:mcurib$8ge$1...@dont-email.me...

non c'e' nulla da risolvere.
 
As usual,  parli di cose che non conosci
e fai la figura del babbeo...:-)
 
ciao
fm 
 
 

Il 01/03/15 12:01, Max_Adamo ha scritto:

come ti ho detto, non è un problema della piattaforma, è un problema di 
utenti della piattaforma. Non so da dove salti fuori il "30 anni".


 Ciao
 
 
Il problema che io ricordo in particolare era il seguente: 
"Resets disk storage. This results in increasing available disk storage"
 
In seguito a IPL venica rilasciato spazio, pertanto anche noi facevano un 
IPL a settimana. 
 
-- 
Massimiliano Adamo

 babbeo...:-)
 
non sono un grande esperto su questi sistemi, ma ho un paio di esperienze 
sistemistiche su AS400. 
 
-- 
Massimiliano Adamo

Il Sun, 01 Mar 2015 13:31:20 +0100, fm ha scritto:
 

comunque non ci sto a farmi insultare da un cretino. Ignorami please. 
 
-- 
Massimiliano Adamo


 
Io direi, invece, che hai sviluppato una frustrazione notevole
nell'ambiente di lavoro precedente, nel quale avevano un AS/400.
E appena puoi  spari ca22ate sull'argomento.
 
Problema tuo .
 
Non  e' colpa ne' di Ibm ne' della piattaforma.
 
ciao
fm
 
 

 ha scritto nel messaggio 
news:md00jb$33r$3...@dont-email.me...

Finche' vieni qui a  sparare  ca22ate e le leggo stai tranquillo che ti 
tengo informato.
 
Il fatto che ti rifugi negli insulti conferma che ti si addicono
le discussioni di "livello basso" come ti ho gia' detto un'altra volta.
 
ciao
fm
 
 

 Io direi, invece, 
 
ma cosa devi dire? Sei palesemente un cretino e quel che vorresti dire e' 
assolutamente irrilevante e ininfluente. 
 

assolutamente irrilevante e ininfluente.
 
 
Vedi? Non sai argomentare.
Hai scritto una cazzata, tentando di  sfottere  IBM e l'AS/400,
 sperando che qualcuno si unisse a te nello sghizzazzare.
Non e' stato cosi'.
 
Stefano Tassi, nella maniera piu' professionale e cortese possibile,
 ti ha spiegato che  come stanno le cose, ma hai voluto insistere.
 
Poi non ti offendere se ti danno del babbeo ... :-)
 
ciao
fm
 
 
 
 


io voglio insistere con piacere nel dire che: 
A: sei un cretino. 
B: AS400 non rilascia lo spazio sullo storage e per questo e' necessario IPL. 
C: cretino, smettila di fare il cretino e argomenta. 
 
 
Se non sei troppo stupido leggi quanto riportato di seguito: 
"Until now when I read an IBM material that said, it does close open files and reinitializes variables but does not release the storage for system's further use (unless the activation group ends or the sub system is brought down or IPL is done). " 
 
E' un fatto palese e non lo sanno solo i cretini come te.

IPL.
 
Stavi cercando di sfottere,
il discorso (peraltro sbagliato) sull' IPL era solo un pretesto.
E continui ad insistere.
 
Rileggiti la risposta del Tassi.
Che ti dobbiam fare?
L'elenco delle macchine accese 7x24 dove l' IPL si fa una volta  all'anno?
 
Babbeo ... :-)
 
ciao
fm
 
 

Il 02/03/15 17:35, fm ha scritto:

questa è una... UP'N'RUN dal 9.2.2014 coi suoi bei 1000 e passa 
utenti... (è male perchè nel frattempo di fix non ne hanno installate ma 
tant'è)
 
 
http://imgur.com/lKMdjiO
 


 E continui ad insistere.
 
lo ribadisco: sei un cretino. 
 
http://www-01.ibm.com/support/docview.wss?uid=nas8N1019466
 
 
To free up all temporary space by jobs currently on the system, IPL the 
system.
 
To free up: IPL the system, IPL the system, IPL the system, IPL the 
system, IPL the system, IPL the system, IPL the system, IPL the system, 
IPL the system. 
 
 
-- 
Massimiliano Adamo

 tant'è)
 
Ma non è quello il problema.... 15 anni fa lavoravo su quei cosi e mi 
ricordo che non li spegnevamo mai. Per stare in piedi, stavano in piedi, 
il problema è che le prestazioni degradavano e quindi abbiamo cominciato 
con gli IPL. 
L'altro problema è che tu stai contestando ciò che non è contestabile. 
Ovvero che l'IPL non si fa, laddove persino nella documentazione IBM è una 
procedura lecita, che viene suggerita come soluzione *ufficiale* per 
liberare spazio. 
 
-- 
Massimiliano Adamo

Il 02/03/15 19:05, Max_Adamo ha scritto:

IL documento si riferisce alla diminuzione del temporary-storage per 
problemi di memory leak (spesso causati da processi utente).
Ti dice di cercare quali sono i job che hanno "troopo" temp-stg 
(wrksysact) e di killarli (endsbs, endjob) o, se preferisci fare IPL.
 
Lavoro su system-i da un po' di anni e non mi è ancora successo di dover 
fare IPL per temp.stg.
 
Mia esperienza personale.


Il 02/03/15 19:12, Max_Adamo ha scritto:

Mi spiace contraddirti.
Le linee guida vanno nel senso opposto: se vuoi prestazioni del DB 
(eliminazione del warm-up del lunedi' mattina - per chi faceva IPL nel 
weekend) il sistema lo tieni acceso.
Poi, ripeto, se ci sono memory-leak qualcosa lo devi fare, magari senza 
arrivare drasticamente al bootstrap (ci sono imprese che non se lo 
possono permettere e deve essere pianificato per tempo (=mesi) ).


 (wrksysact) e di killarli (endsbs, endjob) o, se preferisci fare IPL.
 
 
perdonami, ma dove lo hai letto quel "se preferisci"? :) 
Non ci voleva la documentazione ufficiale per stabilire che un riavvio del 
sistema "killa" i processi. E non ha senso suggerire un IPL se endjob 
sortisce sempre gli stessi risultati. 
Evidentemente è l'ultima spiaggia dopo aver eseguito "endjob". 
 
 
-- 
Massimiliano Adamo

 weekend) il sistema lo tieni acceso. 
 
hai il DB senza valvola termostatica :) 
il warm up del DB non penalizza la prestazioni del DB, ma in definitiva 
rallenta il suo avvio e le fasi immediatamente successive. 
Ma comunque:
1. non parliamo più di OS400, ma di una tecnologia afferente e di un 
problema legato al funzionamento dei DBMS. 
2. questo problema è ovviabile con DB engine molto meno sofisticati... non 
dirmi che con DB2 non si può ovviare. 
 
-- 
Massimiliano Adamo


e perdonami di nuovo, ma non ho mai letto su nessuna documentazione Unix 
che puoi killare o eventualmente fare un reboot, perché il reboot sui 
sistemi unix non è contemplato in nessun caso. 
Pensa che tramite kexec puoi saltare il POST, e caricare un nuovo kernel 
direttamente in una manciata di secondi. 
Ma mai nessun doc ufficiale ti direbbe: prova X, se non va fai reboot :) 
 
 
-- 
Massimiliano Adamo

 dirmi che con DB2 non si può ovviare.
no, la plan cache si distrugge (contiene le ottimizzazioni già pronte 
all'uso degli statement già utilizzati)
non so poi se su altri db esistono autonomic-indexes; sono generati su 
richiesta del dbmanager e vengono eliminati al boot.


Il 02/03/15 19:39, Max_Adamo ha scritto:

non l'ho letto, ovviamente.
solo esperienza personale di oltre 30 anni di esperienza :)
 
chiaro che è l'ultima spiaggia. mai successo pero'. (almeno a me e ai 
clienti che seguo).


Il 02/03/15 19:52, Max_Adamo ha scritto:

non ti so rispondere sul mondo x (sicuramente iper-stabile)
mi fido di te.


 
 
allora è una doppia fregatura. O ti tieni i processi in leak, o aspetti il 
tempo necessario affinché il DB precarichi quello che deve caricare :)
 

 ha scritto nel messaggio 
news:md296u$q80$2...@dont-email.me...

C.V.D. non hai capito granche'  del link che hai postato,
lo hai riporato solo per cercare di difendere la stupidaggine che avevi 
scritto  prima.
 
Sei un frustrato ed hai un complesso di inferiorità nei confronti dei 
sistemi Ibm.
 
Domanda: Non ti hanno fatto fare il sistemista su AS/400 perche' a loro non 
serviva.
perche' chiedevi troppo soldi , oppure perche', mio dubbio, non sei portato 
per farlo?
 
Certo il fatto che ti incaponisci su un concetto sbagliato
non depone molto a tuo favore....:-(.
 
ciao
fm
 
 
 

 solo esperienza personale di oltre 30 anni di esperienza :)
 
 
devo ammettere che hai elencato in modo preciso i passi descritti :)
 
-- 
Massimiliano Adamo

Il 02/03/15 20:52, Max_Adamo ha scritto:

piu' di dirti che non mi è ancora successo in oltre 30 anni...
 
Ognuno per la sua strada; non mi hai convinto con le tue asserzioni: 
penso, senza peccare di presunzione, di saperne un po' di più di te sul 
mondo 400.
 
Ciao


 portato per farlo?
 
Tu lo sai che esiste un'altra opzione, ovvero che non me ne è mai fregato 
nulla di lavorare su questi sistemi? 
 
-- 
Massimiliano Adamo

Il Mon, 02 Mar 2015 21:04:24 +0100, stefano[dot]tassi[at]dedagroup[dot]it

Stefano, posso solo pensare che tu sei il genio della lampada e tutti gli 
altri amministratori OS400 sono degli stupidi figuranti. 
l'IPL degli OS400 è una pratica abbastanza diffusa che che non mi sto 
inventando io di sana pianta. E lo sai bene anche tu. 
 
-- 
Massimiliano Adamo

 Mah! Chissa quali sistemi intendono far saltare!
 
 
mi fai ridere però devi perfezionarti. meno post, magari più mirati e 
potresti diventare il trollone dell'anno :-)
 
 
Ciao
 
 

 inventando io di sana pianta. E lo sai bene anche tu.
Su quali/quanti numeri basi questa asserzione?
Anche qualora fosse pratica diffusa, ti rammento che "pratica diffusa" 
!= "comportamento da seguire" e qui torniamo sul discorso 
persone/formazione.
 
Se devo essere sincero fino in fondo il fatto che as400 non sia appetito 
da diverse imprese è proprio dovuto a certe persone che finora l'hanno 
visto e fatto vedere come sistema chiuso, solo interfaccia carattere 
(5250), solo RPG e COBOL, zero conoscenza (se non timore/odio) di sql e 
di tutto ciò che puo' essere innovativo, tutto in difesa (!) di 
posizioni ormai insostenibili.



Che non ti sia inventato niente, ci credo, ma che tu sappia cosa stai 
dicendo esattamente, no. Sarebbe stato diverso se avessi chiesto come mai.
Non so quanto sia diffusa la pratica che dici tu, ma ti posso assicurare 
che la pratica di non amministrare tout-court e' molto piu' diffusa, nel 
senso che in aziende con as400 di piccole dimensioni, qualche decina di 
utenti, non c'e' mai nessuno che si occupa di amministrare il sistema, 
men che meno il db. E tu sai, o almeno dovresti sapere, quanto in Italia 
siano diffuse le PMI.
Ti segnalo anche che la pratica di spegnere il sistema appena possible, 
risale ai tempi in cui la potenza dell'as400 piu' piccolo era grosso 
modo 2KW e piu' da sommare alla potenza del condizionatore, quindi tale 
comportamento era anche dovuta ad una sorta di sensibilita' verso il 
risparmio energetico. Oggi as400 di medie dimensioni (5000 volte piu' 
potenti in termini di benchmark) consumano meno di un PC desktop. Ma 
l'abitudine puo' essere che sia rimasta.
La "best practice" a cui ti riferisci, risale ai tempi in cui 
l'ottimizzatore del DB non faceva alcuna cache degli access-plan, 
quindi, dal punto di vista della performance del DB, la riaccensione era 
ininfluente, e serviva unicamente per rigenerare la tabella degli 
indirizzi temporanei. Posso assicurarti che non ricordo di aver mai 
visto un consumo di indirizzi temporanei superiore all'1%, anche dopo 
mesi di funzionamento ininterrotto, ma visto che l'IPL non costava 
nulla, mentre l'esaurimento degli indirizzi temporanei comportava un 
crash di sistema, puo' essere che prudenzialmente qualcuno abbia 
adottato una politica prudenziale in assenza di qualcuno capace di 
amministrare il sistema.
Si aggiunga il fatto che gran parte di queste aziende, utilizzano 
applicazioni la cui base dati e' preconfigurata, quindi semplicemente in 
seguito ad un restore, il db e' già configurato ed ottimizzato. Inoltre 
difficilmente gli utenti si mettono ad assemblare query che non siano 
già pre-masticate nel software. Questo rende quasi ininfluente, quello 
che Stefano chiama "warm-up", evidentemente influenzato da termini 
automobilistici!
 
Bene, ora che sai genesi e storia, ogni altra illazione sara' da 
attribuirsi a disonesta' intellettuale. Che di per se' non e' un reato, 
ma di certo non fa bene alla discussione.
 
 

 liberare spazio.
 
Anche questo fatto forse risente dei 15 anni di cui e' antiquata la tua 
esperienza, mentre Stefano sta parlando di *oggi*.
In ogni caso dovresti proprio citarla la fonte *ufficiale* a cui ti 
riferisci. Ho cercato "IPL" nell'information center dell'as400, gli 
unici topic risultanti riguardano operazioni eccezionali, (come il 
cambio dell'os, installazione di fix che lo richiedono, etc.) ma niente 
che riguardi operazioni ricorrenti.
 

 system.
Forse non ci hai fatto caso, ma penso invece che tu stia scivolando 
sugli specchi che pretendi di scalare.
Il link che tu stesso hai citato, mostra un sistema con 27GB di dischi 
(ASP: Auxiliary storage pool).
Oggi la pezzatura minima dei dischi direi che sia almeno 20 volte tanto. 
Ma sai perche'? Perche' il pannello mostarto riporta una data di 14 anni 
fa.
Inoltre mostra che i dischi sono pieni al 99.82%. Ti sembra un fatto che 
possa accadere tutti i giorni, tale per cui sia consigliabile un IPL 
quotidiano?
Io lo valuterei come fatto eccezionale, comunque un fatto che pretende 
una soluzione un po' piu' drastica di un mero IPL. Ti sforno una 
soluzione geniale: aggiungere un disco! (che e' un'operazione che puoi 
fare anche senza IPL, il bus dei dischi dell'as400 e' hot-swap)

 fa.
 
sai cosa.... rispondevo a qualcun che scriveva che in 30 anni di carriera 
non ha mai dovuto fare un solo IPL. 
Si vede che gia' 30 anni fa lui aveva dischi da 1/2 TB ciascuno. 
 
State difendendo il vostro orticello e non ci vedo niente di male. 
Non esagerate comunque. 

 Evidentemente è l'ultima spiaggia dopo aver eseguito "endjob".
Non e' scritto esplicitamente, mi sembra pero' una lecita 
interpretazione, infatti e' elencato assieme ad altre opzioni. Dice che 
se vuoi chiudere tutti i lavori, fai un IPL. Questo fatto indica una 
sola cosa, ci sono activity di sistema (ad esempio il db) che non puoi 
interrompere con un comando ENDJOB, se *preferisci* killare anche quelle 
devi fare un IPL.
Ovviamente non c'e' scritto, ma non e' neanche sottointeso, che 
periodicamente, abbastanza di frequente, ti sia richiesto di killare 
tutti i job. Esiste l'IPL esattamente come in tutti i sistemi, unix 
incluso. Se lo vuoi fare e ne hai l'autorita' lo fai, altrimenti no.
 


No, la cosa e' un po' diversa. Sei tu che difendi un orticello non si sa 
neanche quale. Lo fai denigrando gli orticelli degli altri per far 
risaltare la pochezza del tuo?
Stefano, che ho conosciuto quando aveva appena imparato a fare la pipi' 
nel vasino, 30 anni fa' amministrava il sistema dell'azienda dove lui 
era EDP manager, da circa 10 anni (forse piu') lavora per una societa' 
di consulenza. Se dice che non ha mai dovuto fare un IPL (che non fosse 
pianificato e propedeutico a qualcosa che lo richiedesse), e' perche' ha 
sempre saputo amministrare con la dovuta lungimiranza, ad esempio 
aggiungere i dischi in tempo.
Ma evidentemente, nonostante la "geniale soluzione" che ti ho citato e 
che hai proditoriamente tagliato, non ti e' sovvenuto.
 
 


sia chiaro che non sono qui per denigrare la professionalita' di nessuno (a
parte quelli che insultano, come l'amico FM di cui sopra) e non sto parlando di
pochezza di qualcuno in nessun modo. 
Cio' detto, non si puo' contestare cio' che non e' contestabile, poiche' anche 
i sassi sanno che AS400 ha sempre avuto questa sorta di "feature", 
"inconveniente", "peculiarita'", "particolarita'". 
Adesso tu spunti fuori con il fatto che i dischi sono cresciuti... e va bene. 
In alternativa ve ne uscite fuori con la storia che "tizio lavora su quei 
sistemi dal mesozoico" e gli tramando' la conoscenza suo papa' austrolopiteco. 
No. C'e' una documentazione ufficiale ed idiot-proof che supporta quel che io 
sto dicendo e che elenca una serie di tentativi da esperire, terminati i quali 
mi pare che ci sia una sola unica soluzione (che non cito pie' perche' mi 
sono un po' scocciato). 
 
Ok... da qui a dire "il sistema zompa" come ho detto io ce ne corre.... anche
se voglio insistere che sui sistemi di Milano ricordo grossi problemi quando
non facevamo IPL.

 non facevamo IPL.
Ma quali?
Milano e' la capitale della moda, sara' stata una moda anche quella. :-)