Problème d'accès concurrents sur dll

Bonjour,
Nouveau sur ce forum, je poste une demande d'aide.
J'ai une erreur sur mon serveur de production, j'ai un programme A qui utilise un autre programme B.
Lorsque plusieurs utilisateurs utilisent le programme A, j'ai de manière aléatoire une error I/O sur l'utilisation du programme B: File locked (9/065 (ANS74)).

L'appel du programme B se fait comme ça:
CALL "B" USING W-DSD-PARAM
W-DSD-PARAMDSX.

Je ne peux pas "attraper" l'erreur E/S dans mes variables.

Comment pourrais-je tester l'accès au programme B?

Par avance merci.

Bonjour.

D'abord il faut demander à un modérateur de déplacer cette discussion de la rubrique "Contribuez" au forum racine Cobol.

En plus, il nous faudrait un peu plus de détails sur :

- la plateforme ;
- le compilateur ;
- le fichier qui pose problème, son organisation, son mode d'accès, son type d'open et les ordres I/O effectués dessus ;
- Eventuellement des morceaux de code.

Tu peux gérer le FILE STATUS et utiliser USE AFTER STANDARD ERROR dans DECLARATIVES.
Regarder aussi du côté de la conception du programme et du sous-programme pour améliorer l'accès aux fichiers pour éviter ces locks ou en tenir compte de façon plus adaptée à une utilisation multi-user.

Citation:

---

Envoyé par Hédhili Jaïdane

Bonjour.

Tu peux gérer le FILE STATUS et utiliser USE AFTER STANDARD ERROR dans DECLARATIVES.

---

Je suis d'accord, sauf sur le point ci-dessus :

Utiliser des des déclaratives en COBOL batch, ou des Handle conditions en COBOL CICS, signifie qu'on effectue toujours les mêmes actions pour un code retour donné sur un même fichier
Or, un même CR dans un même programme, peut être correct ou non en fonction du contexte.
C'est le contexte fonctionnel qui doit piloter les actions liées à un code retour.

La bonne façon de faire est donc de tester les file status (avantageusement via des niveau 88) après chaque entrée sortie
Exactement comme on le fait (ou devrait le faire) avec des codes retours SQL
Pour le COBOL CICS il faut utiliser les options RESP et RESP2 dans chaque exec-cics et proscrire les handle
(en plus les handle génèrent de vilains GO TO)