Fichier de l’IFS verrouillé

Suite à une sauvegarde, vous avez tous eu un message du genre
CPF3837 Message . . . . : 678999 objets sauvegardés.
4 non sauvegardés.

Faisons une expérience !

1 session sous QSECOFR
verrouillage d’un fichier
chkout ‘/home/QSECOFR/VERSIONODE.TXT’

2 session sous plb
edtf ‘/home/QSECOFR/VERSIONODE.TXT’
on peut éditer mais pas enregistrer
CPFB620 Resource busy.

3 session sous QSECOFR
edtf ‘/home/QSECOFR/VERSIONODE.TXT’
On peut éditer et enregistrer sans problème
Donc le verrouillage est lié à l’utilisateur, le même utilisateur sur une autre session peut accéder au fichier sans restriction

Pour voir ce verrouillage vous pouvez utiliser sur la session 2 par exemple

WRKLNK ‘/home/QSECOFR/VERSIONODE.TXT’
8=Afficher les attributs
Vous constatez que le fichier est bien verrouillé
Verrouillage par . . . . . . . . . . . : QSECOFR Date/heure de verrouillage . . . . . . : 27/07/20 13:58:23

Vous pouvez également utiliser la table fonction QSYS2.IFS_OBJECT_STATISTICS zone CHECKED_OUT

Vous sortez par signoff de la session qui vérouille ce fichier

Vous refaites la commande sur la session 2

Conclusion contrairement à un ALCOBJ, le fichier reste verrouillé, même quand le travail est arrêté, le verrouillage est lié uniquement à l’utilisateur

vous pouvez, si vous avez les droits sur le fichier, faire
chkin ‘/home/QSECOFR/VERSIONODE.TXT’ qui déverrouillera le fichier

Attention ce n’est pas ce verrouillage que vous trouvez par la nouvelle vue ifs_object_lock_info

Puisque quand vous faites la requête suivante, vous avez 0 enregistrement

select i.*
from table (
qsys2.ifs_object_lock_info(
path_name => ‘/home/QSECOFR/VERSIONODE.TXT’)
) i;

Prenons maintenant un fichier dont on est sûr qu’il est verrouillé applicativement, ici une log apache

select i.*
from table (
qsys2.ifs_object_lock_info(‘/www/ws_demo/logs/error_log.Q120072700’)) i;

On obtient bien une ligne avec un travail exemple :
778168/QTMHHTTP/WS_DEMO, et des informations sur les différents types et modes de verrouillage

Par contre si vous faites wrklnk ‘/www/ws_demo/logs/error_log.Q120072700’
puis option 8
vous ne voyez pas de verouillage pour ce fichier

et si vous essayez d’éditer ce fichier vous avez le même problème que tout a l’heure, vous ne pourrez pas enregistrer votre modification
CPFB620 Resource busy.

Si vous arrêtez l’instance apache qui verrouille le fichier votre fichier est déverrouillé, vous pouvez le mettre à jour.

En résumé

il y a 2 verouillages:

Un plutôt système, par les commandes CHKIN et CHKOUT que vous voyez dans les attributs du fichier.

Vous pouvez également le voir par la fonction table QSYS2.IFS_OBJECT_STATISTICS

Exemple dans notre cas

SELECT PATH_NAME, OBJECT_OWNER, CHECKED_OUT
FROM TABLE (QSYS2.IFS_OBJECT_STATISTICS(START_PATH_NAME => ‘/home/QSECOFR/VERSIONODE.TXT’) )

Un plutôt applicatif, c’est l’api d’ouverture généralement qui fixera ce verrouillage vous pouvez voir ces verrouillages par l’API QP0LROR ou par la fonction table, qsys2.ifs_object_lock_info

Remarque :

Pour mettre à jour un fichier vous n’êtes pas obligé de verrouiller le fichier, exemple si vous avez 2 EDTF sur le même fichier c’est le dernier qui a raison.
Il est donc conseillé de verrouiller votre fichier, si vous faites des mises à jours dans vos applicatifs.

Conclusion :

Si, suite à une sauvegarde, vous avez un verrouillage sur un fichier commencer par vérifier s’il y a un verrouillage système par WRKLNK ou par la fonction table QSYS2.IFS_OBJECT_STATISTICS c’est la zone CHECKED_OUT
Si c’est le cas faites un CHKIN sur votre fichier pour le libérer !
Si il n’y a pas de verrouillage regardez par la fonction table qsys2.ifs_object_lock_info ou l’api QP0LROR
Si vous trouvez le travail, vous devrez l’arrêter avant votre prochaine sauvegarde.
Mais il est aussi possible que le job ne soit plus actif …

Vous avez intérêt à monitorer votre commande SAV et à analyser les erreurs pour les corriger