Passage de paramêtre dans un CLP

RPG (3 et 4, free), CL, SQL, etc...
Répondre
coli
Messages : 2
Enregistré le : mar. 06 nov. 2012, 09:01:06

Passage de paramêtre dans un CLP

Message par coli »

Bonjour,
J'ai un souci lors du passage de longs paramêtres.
J'ai un 1er programme PGM1 qui appelle un 2nd programme PGM2 avec 3 paramêtres :
PARM 1 (100 A)
PARM 2 (2 A)
PARM 3 (2 A)

PARM 1 = ' '
PARM 2 = 'TT'
PARM 3 = 'SS'

Lorsque j'appelles PGM 1 en soumettant PGM2, le paramêtre PARM1 récupéré contient en fin TT (Alors qu'il a été initialisé à blanc). PARM2 contient bien TT
Lorsque j'appelles PGM 1 en ne soumettant pas PGM2, les paramêtres reçus sont bien corrects.
Si quelqu'un a une explication et une solution pour éviter ce probl^me.

Merci d'avance

cmasse
Site Admin
Messages : 764
Enregistré le : mer. 14 févr. 2007, 18:00:03
Localisation : Nantes
Contact :

passage de paramètres

Message par cmasse »

Le problème est le suivant :

le passage de paramètre se fait sur nos langages par adresse et non par valeur (sauf à mettre VALUE dans un prototype RPG4)

c.a.d que le pgm transmet un pointeur sur la varibale et non la variable elle même.

par exemple PGMA fait un CALL de PGMB en lui passant deux paramètres

1/ p1 CHAR(4)
2/ p2 DEC(2,0)

PGMb recoit un pointeur sur p1 et un pointeur sur p2. SI les paramètres sont déclarés correctement tout va bien, mais si PGMB déclare que P2 fait 15 de long, les 4 premiers octets sont corrects, les 11 suivants sont des données "en mémoire" (sans doute d'autres paramètres ou des valeurs temporaires, etc.)


bref entre programmes (bien écrits) tout va bien !!!


Mais il y a problème quand on appel le pgm depuis la ligne de commande, en effet on est pas dans un pgm, donc il n'y a pas de variable ==> pas d'adresse mémoire à transmettre.

Le CL sachant cela, fonctionne de la manière suivante

1/ je stock les paramètres en mémoire temporaire (sur quelle longueur ?)

2/je transmet l'adresse ou je les ai stockés (je n'ai pas le choix PGMB attend un pointeur !)

et c'est là qu'est le prb, le CL a un fonctionnement PAR DEFAUT (non modifiable), les variables CHAR sont stockées sur 32 (ou plus) , le numérique sur 15 dt 5.

les données étant stockées sur 32, si vous transmettez 'AAA' et que le pgm appellé attend 10 c., tout se passe bien, s'il attend sur 40, les caractères de 33 à 40 sont probablement d'autres données en mémoire....


ET Faire un SBMJOB c'est retrouver une ligne de commande déportée, en effet quand le batch deviendra actif, PGMA sera sans doute terminé depuis longtemps, pour cela lors d'un SBMJOB on ne transmet pas les paramètres mais leur CONTENU.


bref, qu'est qu'on fait ?

dans le pgm appelant vous déclarez PARM1 (101 A) et vous mettez qqchose (* par exemple) en position 101, obligeant le système à stocker cette valeur sur 101 octets.

ne changez rien au pgm appelé, qui lui continue de traiter le paramètre sur 100 de long, donc ne verra pas le *.

j'espère avoir été clair....

bonne modif.
Christian Massé (Volubis.fr)

coli
Messages : 2
Enregistré le : mar. 06 nov. 2012, 09:01:06

(sans texte)

Message par coli »

Ok merci pour l'info

Répondre