, , RSTLIB ou RSTOBJ et APYJRNCHG

Vous connaissez tous la journalisation base de données sur l’IBM i, qui permet d’avoir les images avant et après de vos modifications base de données avec la possibilité de valider (APYJRNCHG) ou de les invalider par RMVJRNCHG.

  • Je ne parle pas ici du contrôle de validation.

Que se passe-t-il quand on restaure une bibliothèque suite à un sinistre ou sur autre système pour des tests par exemple ?

Par défaut quand vous sauvegardez un récepteur attaché vous avez ce message :

  • CPF7080 Récepteur RCV de TSTJRN1 sauvegardé alors qu’il était attaché

Que se passe-t-il quand on restaure la bibliothèque qui contient le récepteur et le journal ?

Le système crée un nouveau récepteur qu’il attache au journal, votre ancien récepteur est là, mais il est à l’état partiel.

Les récepteurs à l’état partiel ne sont pas utilisables, vous pouvez voir ce qu’il y a dedans en indiquant la plage de récepteur sur la commande DSPJRN, mais vous ne pouvez pas les utiliser.

La plus part du temps ce n’est pas grave, mais si vouliez invalider des modifications en appliquant un filtre c’est impossible.

Vous devez lire les données et les reporter à la main.

La solution est, avant de sauvegarder votre bibliothèque, de détacher le récepteur en cours.

==>CHGJRN JRN(votrebib/votreJRN) JRNRCV(*GEN)

A la restauration vous aurez 3 récepteurs
1 sauvegardé
1 partiel
1 attaché

Vous avez toujours le récepteur partiel qui est inutilisable, mais il n’a plus de modification de données à l’intérieur

Si vous choisissez d’invalider une partie des transactions en attente, vous pouvez utiliser le récepteur sauvegardé

RMVJRNCHG JRN(votrebib/votreJRN)
FILE((votrebib/*ALL))
RCVRNG(votrebib/RCVsauvegardé votrebib/RCVsauvegardé)

vous aurez un message de ce type

x postes retirés pour x objets.
Certains postes n’ont pas été appliqués ou retirés pour au moins un objet.

Le deuxième message indique que votre demande a trouvé des postes autres que R (modifications de données)

Conclusion :

Il peut être intéressant de détacher vos récepteurs avant de faire vos opérations de savlib au moins pour vos bibliothèques importantes, on ne sait jamais !

Il est intéressant de regarder si vous avez des récepteurs à l’état partiel, ça peut révéler un vrai problème.

J’ai des outils sur GITHUB qui traitent des journaux :

https://github.com/Plberthoin/PLB/tree/master/GJOURN

, Utiliser SYSLOG sur IBMi

Les nouvelles organisations informatiques imposent parfois la mise en place d’un SIEM.

Chez IBM on vous proposera QRADAR. SPLUNK est aussi une solution très connue.

https://fr.wikipedia.org/wiki/Security_information_management_system

Pour échanger avec votre concentrateur, vous devrez utiliser un format spécifique qui se nomme SYSLOG.

https://fr.wikipedia.org/wiki/Syslog

Comment produire du format syslog sur L’IBMi?

Il y a principalement 3 manières d’en produire.

SQL as a service à prévu des passerelles pour produire ces fichiers.

1) Sur les sorties d’audit journal QAUDJRN

Exemple :

SELECT
SYSLOG_EVENT ,
SYSLOG_FACILITY ,
SYSLOG_SEVERITY ,
SYSLOG_PRIORITY
FROM TABLE(QSYS2.DISPLAY_JOURNAL(‘QSYS’, ‘QAUDJRN’,
STARTING_RECEIVER_NAME => ‘*CURCHAIN’,
JOURNAL_ENTRY_TYPES => ‘PW’,
STARTING_TIMESTAMP => CURRENT TIMESTAMP -24 HOURS,
GENERATE_SYSLOG => ‘RFC5424’
)) AS X

Cette requête produira une liste des erreurs de login sur les dernières 24 heures

2) sur la log du système

SELECT
SYSLOG_EVENT ,
SYSLOG_FACILITY ,
SYSLOG_SEVERITY ,
SYSLOG_PRIORITY
FROM TABLE(QSYS2.HISTORY_LOG_INFO(
START_TIME=> NOW() – 1 HOURS,
GENERATE_SYSLOG => ‘RFC3164’
)) AS X

cette requête extrait la liste des commandes du dsplog sur 1 heure

La fonction table ne prévoit pas de filtre vous serez surement obliger de rajouter une clause WHERE pour, par exemple, choisir des messages.

Il y a 2 formats de sortie :

https://tools.ietf.org/html/rfc3164

https://tools.ietf.org/html/RFC5424

3) En utilisant SYSLOG

Syslog n’est pas qu’un formatage de données c’est aussi un logiciel UNIX de remontée d’alerte.
Ca peut être intéressant si par exemple vous utilisez des logiciels open source sur votre partition.

https://fr.wikipedia.org/wiki/Syslog

l’installation est très classique :

Vous avez un executable qui se trouve ici, /QOpenSys/usr/sbin/syslogd.
Vous devrez avoir un fichier de conf ici, /QOpenSys/etc/syslog.conf
Ce fichier doit être en CCSID819 et avoir *LF comme délimiteur.
Dans ce fichier vous indiquerez votre fichier de sortie.
Vous démarrez SYSLOG
SBMJOB CMD( CALL QP2SHELL PARM(‘/QOpenSys/usr/sbin/syslogd’) ) JOB(SYSLOGD)

Par convention on l’appelle SYSLOGD du nom du deamon UNIX.
Si vous n’avez pas de sous-système dédié à ce type d’opération mettez le dans la jobq QSYSNOMAX, il tournera alors dans le sous système QSYSWRK.

Une fois que vous avez produit vos fichiers, il suffira de les envoyer en CSV par exemple à votre concentrateur SIEM.

Vous devrez faire attention au CCSID à produire

Le logs peuvent prendre beaucoup de place, n’oubliez pas de les extraire pour les consolider et de faire le ménage.

Une fréquence journalière peut être adaptée à ce type de traitement.

Il existe des solutions plus ou moins packagées, que vous pouvez trouver chez des éditeurs.

, , Comment suivre l’évolution des pools mémoire ?

Rappel


Les pools partagés sont des espaces mémoire dans lequel les sous-systèmes place des travaux.
*MACHINE Utilisé par les fonctions internes du pool machine
liste des pools
*BASE Pool système par défaut
*INTERACT Travail interactif
*SPOOL Impression
*SHRPOOL1 à *SHRPOOL60 pools spécifiques
et sur ces pools il y a 2 valeurs importantes à ajuster, la taille et le niveau d’activité.

Ajustement

Il existe une valeur système pour ajuster automatiquement ces pools
La valeur système QPFRADJ à 2 ou à 3 permet de mettre en place cet ajustement automatique la différence étant un ajustement à l’IPL avec la valeur 2.
Ce mécanisme fonctionne très bien …
l’ajustement par défaut est fait toutes les 60 secondes ce qui la plupart temps convient bien.
Si vous voulez ajuster ce temps vous pouvez créer une dtaara :
CRTDTAARA DTAARA(QUSRSYS/QPFRADJWT) TYPE(*DEC) LEN(3 0) VALUE(60) vous pouvez indiquer une valeur en seconde de 20 à 120.

Mais on a aucune visibilité sur l’ajustement sur une période données, exemple mon pool de base une journée.

Voici comment on peut faire :


Il faut créer un récepteur de journal, il peut être dans une bibliothèque privée, et vous pouvez choisir son nom
CRTJRNRCV JRNRCV(QUSRSYS/QPFRADJ)
Il faut créer le journal QPFRADJ qui pointe sur votre récepteur
CRTJRN JRN(QSYS/QPFRADJ) JRNRCV(QUSRSYS/QPFRADJ)
Il vous faut un fichier pour faire votre analyse, le fichier qui contient la structure est QAWCTPJE
CRTDUPOBJ OBJ(QAWCTPJE) FROMLIB(QSYS) OBJTYPE(FILE) TOLIB(votrebib) NEWOBJ(QPFRADJ) récupérer les informations du journal DSPJRN JRN(QSYS/QPFRADJ) ENTTYP(TP) OUTPUT(OUTFILE) OUTFILE(votrebib/votrefic)
Créer un fichier à exporter.
create table qtemp/analyse as(
SELECT TPTIME as heure , TPCSIZ as taille
FROM votrebib/votrefic WHERE
TPPNAM = ‘*BASE ‘ and tpdate = ‘070320’
) with data
dans notre cas le pool de base, le 7 mars 2020
vous devez ensuite exporter ce fichier pour faire un diagramme, par exemple sous excel .

Remarque :

Il ne faut pas utiliser des pools privés qui ne seront pas ajustés.
Vous devez faire le ménage sur les récepteurs de journaux que vous créez.
Et règle fondamentale, si on fait de l’ajustement, on fait une mesure avant et une mesure après sur des périodes significatives !

Comment administrer le démarrage des services TCP/IP ?

Rappel :

Il faut d’abord comprendre comment TCP/IP démarre sur votre partition

Quand votre machine démarre, vous avez les attributs de l’IPL qui sont lus.
Vous pouvez les voir par commande, DSPIPLA .
Dans cette commande vous avez un paramètre STRTCP(YES), il va donc démarrer TCP/IP c’est la commande STRTCP qui est utilisée, elle a un paramètre STRSVR(YES).


Oui, mais quels serveurs va-t-il démarrer ?

La réponse est dans le fichier QATOCSTART de QUSRSYS vous avez en gros une ligne par service et la zone AUTOSTART peut prendre comme valeur *YES ou *NO
le plus souvent vous pouvez changer le paramètre par la commande de paramétrage du logiciel spécifique, exemple CHGFTPA AUTOSTART(*YES ou *NO) pour FTP
Vous pouvez également modifier le fichier
QATOCSTART exemple UPDATE QUSRSYS/QATOCSTART SET AUTOSTART = ‘NO’ ou ‘YES’ WHERE
server = ‘*FTP’ ;

Vous avez aussi les hosts SVR que vous pouvez voir par :

SELECT * FROM QATOCSTART WHERE SERVER like(‘HOST%’)

A ce moment là on connait tous les services qui vont démarrer .

Mais ça ne suffit pas pour la partie WEB / HTTP, il faut connaitre les instances qui sont démarrées.


rappel :

le serveur HTTP sur votre IBM i est un APACHE.
La aussi il va falloir aller regarder dans la bibliothèque QUSRSYS.
Il y a 2 fichiers
QATMHINSTA , pour l’instance apache admin
QATMHINSTC , pour les instances apache customer
Dans ce fichier, vous avez un membre par service
dans chaque membre vous avez des informations
Le nom, le répertoire racine des fichiers, le fichier de conf et un paramètre -AutoStart :
-AutoStartY pour démarrage automatique
-AutoStartN pour démarrage manuel

Pour modifier cette valeur, vous pouvez modifier par l’interface d’administration web, ou par SQL, attention à cause des membres, il vous faudra utiliser des Alias.

Conclusion :


Voila comment démarre TCP/IP et les services qu’il lance.
Le principe est le suivant : pour des questions de ressources et surtout de sécurité ne démarrez que les services que vous utilisez.
Pour vous aider dans cette administration, vous retrouverez une commande (WRKTCPSTR) à compiler à l’adresse suivante : https://github.com/Plberthoin/PLB/tree/master/GTCPIP

, , Comment retrouver le label de bande ?

Vous voulez connaitre le label qui est actuellement monté sur une unité de bande !

Rappel

Pourquoi c’est très important de gérer les noms de labels ?


D’abord pour des questions d’organisation c’est mieux d’avoir LUNDI, MARDI, MERCRE etc.. ou HEBDO1 , MOIS1 que XXXXX1.
Mais l’autre raison est qu’en faisant correspondre le volume à une bande physique, on peut avoir des statistiques qui peuvent par exemple vous indiquer qu’une bande est altérée !
C’est en utilisant la commande PRTERRLOG ou par SST que vous pouvez avoir ces informations

exemple dans un scripte SQL

cl:PRTERRLOG TYPE(VOLSTAT) OUTPUT(OUTFILE)
OUTFILE(QTEMP/ERRLOG)
VOLTYPE(3580) — a trouver sur l’unité
VOLSTATTYP(*SESSION) ;

SELECT SPHMSR, SPSNAM, SPLDAT, SPLTIM, substr(SPKVID, 1, 6) as vol ,
SPVOPR, SPVOPW, SPVOTR, SPVOTW FROM qtemp/ERRLOG

Vous pouvez tester pour savoir si le volume monté est le bon par la commande suivante :

CHKTAP DEV(nomdevice) VOL(nomvolume)
monmsg (CPF6720 CPF6772)

CPF6720 Volume &2 incorrect sur unité &1.
CPF6772 Le volume chargé sur l’unité &1 ne peut pas être traité.

Mais vous ne connaissez pas le volume qui est monté à cet instant

Voici 3 méthodes pour connaitre le volume monté sur une bande

La première méthode, consiste à lire le message envoyé par le chktap

         CHKTAP     DEV(&DEV)                                 
         RCVMSG     MSGTYPE(*COMP) RMV(*YES) MSGDTA(&MSGDTA) +
                      MSGID(&MSGID) 
if cond(&msgid = 'CPC6778') then(do)                              
               chgvar &vol %sst(&msgdta 11 6)  
 enddo                           

C’est la plus simple des méthodes à mettre à en œuvre .

La deuxième méthode, consiste à lire la sortie d’une dsptap

/* declaration du fichier système pour la compile / 
dclf qsys/QATADOF 
/ génération du fichier avec un enreg  /
 DSPTAP DEV(&dev )            + 
        SEQNBR(FIRST ONLY)  + 
        OUTPUT(OUTFILE)      + 

        OUTFILE(QTEMP/WATADOF)  

/*Substitution pour lire le fichier généré */

OVRDBF FILE(QATADOF)          +

       TOFILE(QTEMP/WATADOF)  + 

       LVLCHK(NO)    
/ lecture du fichier /       
RCVF
/ traitement des informations /
 chgvar &vol %sst(&RDVOLL 5 6) 
/Arret de la Substitution  */

DLTOVR FILE(QATADOF)

Cette méthode est un peu plus lourde, à utiliser plutôt si on veut d’autres informations, voir description du fichier qsys/QATADOF

Le DSPTAP peut être également utilisé, pour connaitre le contenu d’une bande, pour effectuer des recherches

La troisième solution c’est par l’api QTARTLBL

/* déclarations nécessaires l’appel de QTARTLBL */

         DCL        VAR(&RCV) TYPE(*CHAR) LEN(220)              
         DCL        VAR(&RCVLEN) TYPE(*CHAR) LEN(4) +           
                      VALUE(X'000000DC')                        
         DCL        VAR(&FORMAT) TYPE(*CHAR) LEN(8) +           
                      VALUE('RLBL0100')                         
         DCL        VAR(&DEV) TYPE(*CHAR) LEN(10)               
         DCL        VAR(&REQQUAL) TYPE(*CHAR) LEN(44) +         
                      VALUE('      *ALL             *FIRST    + 
                      *ONLY     0')                             
         DCL        VAR(&REQQUALLEN) TYPE(*CHAR) LEN(4) +       
                      VALUE(X'0000002C')                        
         DCL        VAR(&ERR) TYPE(*CHAR) LEN(256)              
/* appel de l'api QTARTLBL /
CALL       PGM(QTARTLBL) PARM(&RCV &RCVLEN &FORMAT +
             &DEV    &REQQUAL &REQQUALLEN &ERR)
/ lecture du volume ou en cas d'erreur envoi du message CPFXXXX */
if cond(%sst(&err 09 7) *eq ' ') then(do)
chgvar &vol %sst(&rcv 29 6)
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Le +
volume sur l''unité, ' *BCAT &DEV *BCAT +
'est' BCAT &VOL) MSGTYPE(COMP)
return
enddo
else do
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Erreur +
sur l''unité, ' *BCAT &DEV *BCAT 'MSGID:' +
BCAT %SST(&ERR 09 7)) MSGTYPE(COMP)
chgvar &vol 'ERREUR'
return
enddo

C’est une bonne méthode, mais elle peut être un plus compliquée à mettre en oeuvre dans mon cas j’ai simplifié au maximum

En résumé :

Voila, vous savez maintenant lire le nom du volume monté sur votre bande, après il faut prendre la décision en cas de volume erroné.

La règle restant « il vaut mieux une sauvegarde sur le mauvais volume, que pas de sauvegarde du tout !

La deuxième règle, c’est une bande qui comporte des erreurs doit être automatiquement retirée des bandes actives.

Si vous avez des structures plus grosses vous utiliseriez BRMS qui vous simplifiera votre gestion

, , Migrer les jobs de Job scheduler vers Advanced job scheduler.

Rappel :

Sur l’IBMi il existe un scheduler standard celui qui se cache derrière la commande WRKJOBSCDE.
Il est très rudimentaire, vous n’avez pas d’historique ni de dépendance travaux.
C’est un unique objet, QDFTJOBSCD de type *JOBSCD qui est stocké dans la bibliothèque QUSRSYS.
C’est le travail QSYSSCD qui tourne dans QCTL


QCTL QSYS SBS 0,0
QSYSSCD QPGMR BCH 0,0 PGM-QEZSCNEP


Attention vous devez le sauvegarder par SAVOBJ par exemple, vous pouvez également l’envoyer sur une autre machine et le restaurer par un RSTOBJ

IBM propose un autre produit qui s’appelle job scheduler advanced c’est le produit 5770JS1, il est payant, mais il permet de faire beaucoup plus de choses !
Pour y accéder en mode 5250 ==>GO JS, sinon vous pouvez y accéder par l’interface web de navigator for i
Son paramétrage est composé de fichiers qui sont stockés dans la bibliothèque QUSRIJS

Voici, comment reprendre les travaux de job scheduler vers advanced job scheduler, si vous choisissez de passer du premier vers le deuxième

La première méthode si vous avez peu de commandes dans le scheduler !


Go cmdjs

Option 5

Option 7

Option 8 en face de chaque job à migrer_

Ça produit une commande de ce type
ADDJOBJS JOB(nomjob)               
         SCDCDE(DAILY)                
         TIME(1815)                    
         DAY(MON *TUE *WED THU)      
         TEXT('Votre texte')     
         CMD(CALL PGM(<lib/pgm))
         RCYACN(SBMRLS)               
         JOBD(USRPRF)                 
         JOBQ(QGPL/QS36EVOKE)          
         USER(SYSTEM)                  
         MSGQ(USRPRF)      

Si vous désirez automatiser cette opération.

Attention le job scheduler standard n’est pas composé de fichiers contrairement à advanced job scheduler qui lui en est composé

Par exemple pour AJS :
Job actuellement planifiés : select * from QUSRIJS/QAIJSMST where JMSTS <> ‘*HELD’
Historique : select * from QUSRIJS/QAIJSHST
Mais heureusement SQL as a service a résolu ce problème en créant une vue qui vous permet d’accéder aux job planifiés dans job scheduler !
select * from QSYS2.SCHEDULED_JOB_INFO
pour limiter aux jobs actifs
SELECT * FROM QSYS2.SCHEDULED_JOB_INFO
where status <> ‘HELD’


Il vous suffit donc de lire cette vue et pour chaque ligne de faire un
ADDJOBJS en adaptant les paramètres

Conseil :

Commencer par une ou 2 commandes et n’écrivez pas directement dans les fichiers de JSA. mais faites un ADDJOBJS

, Adoption de droits

Rappel

C’est la possibilité d’avoir accès à une ressource momentanément en passant par un programme qui s’exécutera avec les droits du propriétaire et non celui de l’utilisateur en cours.

Mise en oeuvre

Pour créer un programme adoptant.
C’est le paramètre USRPRF(*OWNER) dans les commandes qui génèrent un programme.
Vous pouvez également utiliser la commande CHGPGM pour modifier ce paramètre.
Dans tous les cas vous devez avoir au minimum le droit *USE sur le profil propriétaire.
Vous héritez également des droits spéciaux, comme *SPLCTL

Exemple :


Un exemple classique c’est le changement de mot de passe par un exploitant qui n’a pas le droit *SECADM dans les paramètres de son profil

Soit le programme suivant chgusrpwd compiler avec propriétaire qsecofr et le paramètre USRPRF(*OWNER)

PGM        PARM(&USR)                                   
DCL VAR(&USR) TYPE(CHAR) LEN(10) CHGUSRPRF USRPRF(&USR) PASSWORD('#password$') + PWDEXP(YES) STATUS(*ENABLED)
MONMSG MSGID(CPF2204) EXEC(SNDUSRMSG MSG('Profil,' +
*BCAT &USER BCAT 'inéxistant') + MSGTYPE(INFO))
ENDPGM

l’utilisateur peut rendre le mot de passe sans avoir le droit *SECADM, en

tapant ==>call chgusrpwd (‘NOMPROFIL’)

Sur un programme, vous avez un deuxième paramètre c’est USEADPAUT(*YES)

c’est est ce qu’on hérite des droits du programme appelant qui lui peut être en adoption de droit (par exemple call qcmd …)

Avantages :


Si vous maîtrisez bien, c’est un moyen de dire, aucun de mes utilisateurs n’a le droit sur ma base de données, mais il obtient le droit en utilisant mon applicatif, on pense aux accès par ODBC par exemple !

Inconvénients :


Ça peut être une « back door » pour des individus mal intentionnés.

Analyse et suivi :
La commande DSPPGMADP permet de mettre dans un fichier les programmes adoptants et ensuite vous pouvez interroger ce fichier.

2 valeurs systèmes influent sur l’adoption de droit.

QALWOBJRST

*ALWSYSSTT
Permet aux programmes, programmes de service et modules ayant un attribut état-hérité d’être restaurés. Lorsque le paramètre de la valeur système

QFRCCVNRST entraîne la conversion de l’objet, celui-ci passe à état-utilisateur.

*ALWPGMADP
Les programmes et programmes de service disposant de l’attribut d’adoption sont restaurés.

Cette valeur contrôle les restaurations d’objets sur votre partition

La deuxiéme valeur système

QUSEADPAUT

Elle indique si vous avez le droit de créer des programmes qui héritent des droits adoptés, c’est le paramètre USEADPAUT(*YES)

*NONE
Tous les utilisateurs du système on le droit de créer des utilisateurs qui héritent des droits du programme appelant.

nom d’une liste d’autorisation par convention souvent, QUSEADPAUT et seul les utilisateurs inscrits à cette liste et disposant de *use sur celle ci auront le droit de créer ou de modifier des programmes pour demander un héritage de droit.

Limites

Attention, vous héritez également des droits spéciaux , *SECADM par exemple

Attention, L’héritage de droit et la valeur par défaut USEADPAUT(*YES)

L’adoption de droit, ne fonctionne pas sur l’IFS qui est régie par un mode unix

Conclusion

Il est important de bien comprendre les mécanismes d’adoption de droit, soit pour les utiliser dans votre application, soit pour les contrôler et les administrer.

, , Utiliser Dynamic compound statement avec SQL

Depuis la version 7.1, vous pouvez composer une instruction SQL dynamique c’est assez similaire à une procédure SQL, sauf qu’elle ne créera pas un objet permanent.
Vous trouverez un fichier source QSQLT00000, SQL COMPOUND DYNAMIC QCMPD00001 dans votre bibliothèque qtemp

Le but :

Vous pouvez l’utiliser pour ajouter une logique aux scripts, mais aussi pour intercepter les erreurs de traitement entre autres.

Par exemple, il n’existe pas d’instruction pour faire un create replace avec la syntaxe create table as(..)with data.

La solution est donc la suivante :

begin
declare continue handler for sqlstate ‘42704’ — fichier existant
begin end ;
drop table qgpl.liste ;
create table qgpl.liste as( select * from qgpl.qauoopt ) with data ;
end ;

42704 étant le sqlstate pour table non trouvée

Voici un deuxième exemple qui permet d’écrire dans un fichier log, si vous avez au moins une PTF à appliquer (CREATE TABLE LOGPTF(TEXT CHAR (132 ) NOT NULL WITH DEFAULT)), le code est placé dans un RUNSQL pour être exécuté dans un CLLE.

Attention aux nombre de quotes ….

DCS peut être utilisé dans tous les environnements :
srcipt SQL par exemple dans ACS
RUNSQLSTM
RUNSQL
SQL embarqué

Il y a plein de possibilités et la limite c’est votre imagination …

lien à connaitre

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/sqlp/rbafydyncompound.htm

Quelques informations sur l’IPL de votre Partition

IPL (initial program load) et en réalité le Reboot dans d’autres environnements.

A quelle fréquence doit on faire un IPL? Voici quelques informations.

Un IPL n’est plus sytématique pour la reconstruction des adresses temporaires.
Un IPL efface le cache SQL ce qui peut être pénalisant pendant la phase de profiling de votre partition
Un IPL est nécessaire pour appliquer les PTF.
Faire un IPL pour appliquer les PTFs tous les mois semble un bon compromis mais …

Vous pouvez planifier un redémarrage de votre machine par l’intermédiaire d’une valeur système, QIPLDATTIM

Vous devez indiquer la date au format QDATFMT de votre machine + l’heure de redémarrage.

Le principe, vous arrêtez votre partition par ==> PWRDWNSYS Restart(*No) et le redémarrage sera effectuée à la date et l’heure planifiée dans la valeur QIPLDATIM.

Vous avez un menu qui peut permettre de gérer votre planning d’arrêt redémarrage ==> Go POWER qui aide à réaliser un planning.

Cette option ne sera pas utilisée sur les partitions de prod, ou il vous faudra jongler entre l’indisponibilité, la présence de votre cache SQL et l’application des PTFs .

Mais vous avez des dizaines de partitions qui tournent en permanence pour rien et qui pourraient être arrêtées, au moins les week-end voir les périodes de vacances ou autres … Pensez à la planète.

Vous avez une valeur système QIPLSTS qui vous donne des informations sur le dernier IPL


0=IPL manuel à partir du panneau opérateur ou de la HMC
1=IPL automatique après rétablissement du courant, la valeur QPWRRSTIPL devant être à OUI
2=IPL relancé par PWRDWNSYS avec restart *yes
3=IPL selon date et heure planifier par la valeur système QIPLDATIM
4=IPL à distance

Remarque
On peut tester également regarder la valeur système QABNORMSW qui indique l’état du précédant IPL
0=Normal
1=Anormal

Vous avez une valeur système QIPLTYPE, qui sert à définir le type d’IPL à effectuer


0=IPL sans contrôle opérateur
1=IPL sous contrôle opérateur avec les outils de maintenance en mode dédié (DST)
2=IPL sous contrôle opérateur, console en mode de débogage
Cette valeur est généralement à 0

Vous avez une valeur système méconnue QPWRDWNLMT,

Elle est réglée par défaut à 900 secondes
C’est la durée maximale de PWRDWNSYS *IMMED , Si vous voulez une vrai arrêt immédiat il faut mettre cette valeur

à 0.
Sauf cas exceptionnel, on ne touche pas à cette valeur sur une partition de prod.

Vous pouvez gérer vos attributs d’IPL par la commande
==> CHGIPLA

voici quelques options interessantes de cette commande

RESTART()

*SYS
Le système d’exploitation est relancé. Le matériel est redémarré uniquement si une PTF requérant un redémarrage matériel doit être appliqué.

*FULL
Tout le système, y compris le matériel, est redémarré, il est préférable d’indiquer cette valeur, si vous avez un PTF firmware à appliquer à partir de votre partition.

HDWDIAG()

*MIN
Les diagnostics de matériel minimaux sont exécutés.

*ALL
Tous les diagnostics de matériel sont exécutés, à mettre suite un probléme …

CPRJOBTBL()

*NONE
Les tables de travaux ne sont pas comprimées à l’IPL.

*NEXT
Les tables de travaux sont comprimées pendant l’IPL suivant. Cette valeur sera réinitialisée avec la valeur *NONE une fois la compression de la table de travaux démarrée.

*NORMAL
Les tables de travaux sont comprimées au cours des IPL normaux uniquement.

*ABNORMAL
Les tables de travaux sont comprimées au cours des IPL anormaux uniquement.

*ALL
Les tables de travaux sont comprimées au cours de tous les IPL

Cette valeur sert à comprimer les tables de travaux que vous vous voyez dans la commande DSPJOBTBL
Il faut de temps en temps mettre *NEXT qui indiquera de compresser au cours du prochain IPL, la valeur repassera à

*NONE après

Sinon vous pouvez mettre *ALL qui peut augmenter le temps d’IPL mais vous assurera une table des travaux à jour.

Compléments

Si vous indiquez un IPL de type normal (QIPLTYPE 0) l’IPL va démarrer un sous système indiqué dans la valeur système QCTLSBSD, le plus souvent QCTL se sous système lancera un programme à démarrage automatique qui est indiqué dans la valeur système QSTRUPPGM, il peut être important de regarder ce programme qui traîne souvent des choses obsolètes.

Pourquoi utiliser un groupe principal sur objet (on parle de PGP) ?

Le principe est le suivant :

Dans un objet vous avez le droit du propriétaire et le droit du public
Les autres droits sont contenus dans les profils.

Si vous sauvegardez un objet, par défaut ces 2 seuls droits sont restaurés
depuis la version 7.1 vous pouvez sauvegarder aussi les droits privés
en ajoutant le paramètre PVTAUT(*YES) dans vos commandes de SAV.

Pour des questions de performance vous pouvez ajouter un groupe principal et lui attribuer un droit sur l’objet.
Dans ce cas le contrôle des droits ne nécessite pas d’accéder au profil.

Et il sera également sauvegardé, pour être cohérent, on doit mettre le groupe le plus utilisé.

Voici les principales manipulations

Sur un Objet

CHGOBJPGP OBJ(PLBTSTSEC/TSTFIC) OBJTYPE(*FILE) NEWPGP(PLBgrp)

Sur l’IFS

CHGPGP OBJ(‘/gsec/test.txt’) NEWPGP(PLBGRP) DTAAUT(*RWX) OBJAUT(*ALL)

une seule commande pour la gestion pour Objets et IFS

WRKOBJPGP PGP(PLBGRP)

Groupe principal . . . . . : PLBGRP

Indiquez vos options, puis appuyez sur ENTREE.
2=Réviser les droits 4=Supprimer 5=Afficher les droits 7=Rebaptiser
8=Afficher la description 9=Changer de groupe principal

Unité
Opt Objet Bibliothèque Type Attribut ASP
/gsec/test.txt *STMF *SYSBAS
TSTFIC PLBTSTSEC *FILE PF *SYSBAS

SQL as a service

C’est la vue QSYS2.OBJECT_PRIVILEGES qui contient la zone PRIMARY_GROUP

Attention requête très longue les index n’existent pas ??
prévoir des informations complémentaires

SELECT *
FROM QSYS2.OBJECT_PRIVILEGES
WHERE PRIMARY_GROUP = ‘PLBGRP’
and AUTHORIZATION_NAME = ‘PLBGRP’

résultat de la requête

PLBTSTSEC TSTFIC PLBTSTSEC TSTFIC *FILE PLBGRP *ALL QSECOFR PLBGRP

Ne donne pas l’IFS

Remarques :

Votre profil PGP doit avoir un GUID (notion fortement Unix)

Le nouveau groupe principal PLBGRP n’a pas de numéro d’ID groupe.
L’opération a échoué pour le fichier TSTFIC de la bibliothèque PLBTSTSEC.
Fonction non exécutée pour le profil utilisateur PLBGRP.

CHGUSRPRF USRPRF(PLBGRP) GID(132)

Sur une restauration, si le groupe principal n’existe pas il indique un avertissement et il génère l’objet avec PGP = *NONE

Conclusion :

L’intérêt du PGP est qu’il est dans l’objet, donc plus rapide pour contrôler et qu’il est sauvegardé dans un SAVOBJ par défaut