Je me demande une chose avec le langage REXX, comment il gère les verrous de jeu de données. La situation: - J'ai l'ensemble de données séquentielles ouvertes dans mon éditeur ISPF - Je démarre REXX-programme quelles mises à jour (apporte des modifications) cet ensemble de données - ça fonctionne bien, mais comment est-ce possible? Normalement, si vous avez un jeu de données ouvert dans votre éditeur et que vous essayez d'utiliser celui d'un autre programme (par exemple si vous soumettez un travail), vous recevrez le message "Jeu de données en cours d'utilisation". Pourquoi cela fonctionne avec REXX ici. Peut-être même espace d'adresse ou ...? Quelqu'un peut-il me le dire? REXX ne gère pas le verrouillage du jeu de données.Verrous de l'ensemble de données REXX/z/OS
Répondre
REXX appelle les modules de service à pour allouer des ensembles de données et y effectuer des E/S. La routine de service d'E/S sous TSO s'appelle EXECIO. Avant que EXECIO puisse fonctionner sur un ensemble de données, il doit être affecté sous TSO à un certain nom DD. Ce DDName est ensuite référencé dans la requête EXECIO.
Les jeux de données peuvent être attribués directement à partir de l'invite de commande TSO ou à partir de dans votre exec REXX. Le niveau de verrouillage du jeu de données est déterminé par le paramètre DISPosition fourni lors de l'allocation du jeu de données.
Le point important à prendre dans votre exemple particulier est que vous exécutez une ISPF Modifier session et l'exécutif REXX sous la même session de TSO. Les allocations de jeu de données au sein de la même session TSO ne se bloquent pas mutuellement. Le paramètre DISP spécifie comment verrouiller avec en ce qui concerne autres processus, pas le processus lui-même. Par conséquent, il n'y aura jamais de problème de verrouillage de jeu de données entre différents programmes s'exécutant sous la même session TSO. Le message 'Jeu de données en cours d'utilisation' affiché par l'éditeur ISPF est une fonction de l'éditeur vérifiant lui-même les allocations précédentes sous la même session TSO.
Tentez l'expérience suivante:
Répétez ce que vous avez décrit: Ouvrez une session ISPF Modifier sur un ensemble de données. Puis exécutez votre proc REXX sous la même session TSO pour le mettre à jour. Devrait travailler sans plainte.
Suivant: Demandez à un ami d'ouvrir une session de modification ISPF sur l'ensemble de données. Cette fois, votre proc REXX va exploser à cause de "dataset in use". Vous pouvez faire la même chose vous-même en éditant l'ensemble de données dans TSO et en soumettant l'exec REXX en tant que travail par lots sous votre compte. La session TSO interactive est un processus, la session TSO par lots est un deuxième processus et le jeu de données se produit entre eux (votre travail par lots va soit exploser, soit se bloquer jusqu'à l'abandon de la session TSO Edit).
Les conflits d'accès au jeu de données n'apparaissent que lorsque différents processus tentent d'attribuer le même jeu de données à des paramètres DISP incompatibles.
Merci NealB, "Les allocations de jeu de données dans la même session TSO ne se bloquent pas mutuellement." Cela explique tout! Meilleures salutations, Timo – Timo