Questa è la terza parte della raccolta di FAQ & Howto sulla gestione del sistema IBM i : puoi vedere le altre raccolte qui da questi due link :
Gestione del sistema IBM i: FAQ & Howto (Parte 1)
Gestione del sistema IBM i: FAQ & Howto (Parte 2)
Index
In seguito ad uno spegnimento errato del sistema, ad esempio un black-out elettrico o un sistema lasciato andare fino al 99% di occupazione del disco, può succedere che riavviando il sistema non vengano correttamente ricostruiti tutti i Logical File / Index in uso in quel momento.
Se sono file logici utilizzati esplicitamente (come nel caso di I/O nativo e il logical file dichiarato nelle specifiche dcl-f (F), il sistema operativo si preoccupa da solo di ricostruire (rebuild) il logical file … ma se sono indici delle tabelle, creati, ad esempio, dai suggerimenti dell’Index-Advisor, non vengono presi in considerazione dai nostri statement SQL con il risultato di arrivare a tempi di risposta osceni.
Lanciando il comando EDTRBDAP possiamo controllare e ricreare tutti gli indici difettosi e far tornare le performance a livello precedente.
https://www.ibm.com/support/pages/using-edtrbdap-command-rebuild-invalid-access-paths
Se vogliamo modificare un gruppo di utenti settando a tutti un certa opzione non possiamo utilizzare un comando tipo CHGUSRPRF (MYFILTER) MYOPTION … non è possibile.
Possiamo però utilizzare SQL per costruire uno script da eseguire sempre all’interno del “Esegui script SQL” di ACS. Ad esempio, se volessimo settare il parametro LMTDEVSSN(*YES) per limitare l’utilizzo di una sola sessione per gli utenti radiofrequenza (che supponiamo siano RFxxxxx) possiamo creare lo script con SQL, salvarlo in un file TXT e rieseguirne il risultato sempre da interfaccia SQL:
SELECT
'CL: CHGUSRPRF USRPRF(' || AUTHORIZATION_NAME|| ') LMTDEVSSN(*YES);'
FROM QSYS2.USER_INFO WHERE AUTHORIZATION_NAME LIKE 'RF%' ;
Un secondo modo, sempre da “Esegui script SQL” di ACS oppure anche da STRSQL è possibile scrivere logica SQL in un SQL-Compound-statement (ne parliamo in questo post di “FAQ SQL per DB2 for i“)
begin
declare cmd varchar(256);
for vl as c1 cursor for
select
*
FROM QSYS2.USER_INFO WHERE AUTHORIZATION_NAME LIKE 'LAB%'
do
set cmd = 'CHGUSRPRF USRPRF('|| AUTHORIZATION_NAME|| ') LMTDEVSSN(*YES)';
call qcmdexc(cmd);
end for;
end;
Con gli IBM i services possiamo recuperare gli IP della partizione IBM i e anche quella del client che sta eseguendo una applicazione in modo molto semplice:
SELECT * FROM QSYS2.NETSTAT_INTERFACE_INFO
WHERE INTERFACE_LINE_TYPE = 'VETH';
or
SELECT LOCAL_BINDING_INTERFACE FROM QSYS2.NETSTAT_ROUTE_INFO where ROUTE_TYPE =
'DFTROUTE';
Se non si hanno a disposizione gli IBM i services (vecchie versioni di sistema operativo), ci si può arrivare anche con RPG via API:
List Network Interfaces (QtocLstNetIfc) API
select sysibm.client_ipaddr
from sysibm.sysdummy1;
Il nome del database (quello che si vede con STRSQL o SQL Script) viene gestito da WRKRDBDIRE e possono essere aggiunti altri ALIAS per puntare al DB *LOCAL … cosa utile, ad esempio, quando si cambia sistema dobbiamo modificare gli accessi ODBC / JDBC da esterno.
Quando si cambiano dei default con CHGCMDDFT, all’aggiornamento del sistema operativo o all’installazione di qualche PTF potremmo avere qualche problema. In questo post su Geeky Ramblings ci viene proposta una alternativa:
Quando si vogliono analizzare le performance di un IBM i (o di una singola partizione), il sistema operativo offre una serie di tools che aiutano ad individuare e migliorare diversi problemi di performance:
Sempre legato ai concetti di Performance c’è un ottimo post, anche se ancora del 2013, di Dawn May: IBM i wait accounting che vale la pena di leggere.
Il comando SAVSECDTA salva tutte le informazioni di sicurezza senza richiedere di essere in restricted mode (condizione limitata) e può essere aggiunto al processo di backup dei dati. Su alcuni sistemi IBM i questo processo risulta essere molto lungo … in tal caso c’è una guida che ne spiega le cause e anche il modo di velocizzare: IBM Support – SAVSECDTA is Taking a Long Time, trucchi come quello di creare un profilo utente di gruppo e assegnare l’autorizzazione degli oggetti a questo utente-di-gruppo invece che ad ogni singolo … con notevoli risparmi di tempo (da ore a minuti!!!).
iAdmin-FAQ-028 Lista degli oggetti di uno UserProfile
Sembra una cosa banale … ma il comando “DSPUSRPRF USRPRF(MYUSER) TYPE(OBJOWN) OUTPUT(PRINT)” si limita a stampare gli oggetti delle varie librerie IBM i (QSYS.LIB/…) ma ignora eventuali oggetti IFS. Se vogliamo anche quelli c’è un tools non supportato ufficialmente da IBM … ma scaricabile dal loro stesso sito che si chiama QMGTOOLS.
Nella libreria QMGTOOLS e anche nella QSPTLIB, tra le altre cose, troviamo il modo per stampare l’elenco completo degli oggetti dell’utente indicato.
Utilizzando i “DB2 for” Services possiamo interrogare e gestire il sistema con pochi e semplici statement SQL. Ad esempio JOBLOG_INFO permette di interrogare con SQL il JOBLOG del job attuale o di uno specifico JOB … ma se volessimo vedere i JOBLOG di tutti i JOB di un certo tipo … ad esempio di tutti i JOB QZDASOINIT:
select a.job_name, b.message_id, b.message_text
from table(qsys2.joblog_info(
JOB_USER_FILTER => 'QUSER')) a,
lateral (select * from table(qsys2.joblog_info(a.job_name)) x) b
where a.job_name like('%QZDASOINIT%');
Altri esempi di utilizzo li trovate in questo post su IBM System Media: Analyzing Joblogs with IBM’s Db2 for i Services
Se attivo l’Audit Journal ( vedi questo post “Modernize your platform with IBM i 7.4 “) possiamo analizzare i tentativi di Logon con password errata interrogando i dati rilevati dallo stesso Audit Journal con le funzioni di controllo:
DSPAUDJRNE ENTTYP(PW) OUTPUT(*PRINT)
oppure
DSPJRN JRN(QAUDJRN) ENTTYP(PW) OUTPUT(*PRINT)
Come indicato in questo ottimo post ITJungle ancora del 2005: “Admin Alert: A Better Technique for Detecting Invalid Log-In Attempts”
Oppure interrogare lo stesso Audit Journal con le funzionalità SQL “Qsys2.Display_Journal ” con uno statement SQL come indicato in questo Gist di Brian Dietz :”Badlogons.sql“
Vedi questo Gist di Brian Dietz : Active Job in MSGW che utilizza un join tra i DB2 for i Service Qsys2.Joblog_Info e Qsys2.Active_Job_Info
Sempre nel repository Gist di Brian Dietz troviamo questo SQL per listare i JOB ODBC :”WRKOBDCJOB in SQL“
--- Roberto De Pedrini Faq400.comApprofitto di una recente discussione su IBM TechXchange per segnalarvi un’ottima guida di Anna Niederschulte: dedicata alla configurazione di SFTP…
Voglio segnalarvi questo secondo post di Massimo Duca nella serie SQL Tips. In questa puntata vediamo come usare SQL per…
Oggi voglio segnalarvi un interessante articolo scritto da Marco Riva sul suo blog Markonetools: “Non è bello far paragoni… ma”🔗…
Voglio segnalarvi questo interessante post di Massimo Duca, il primo di una serie di articoli dedicati a SQL su IBM…
Nell’ultimo mio ultimo articolo “Rimuovere i vecchi spool file per tenere sotto controllo il numero di lavori nel sistema” ho pubblicato…
Il valore di sistema QMAXJOB (intervallo valido: 32.000 - 970.000; valore predefinito = 163.520) definisce il numero massimo di lavori…