Eviter un OJCV

[sam01]

Bonjour,

voilà dans mes JCL, j'ai des SYSIN DD * qui contiennent des variables

Code :

1
2
3
4
5
6
7
8

//S0XX      EXEC &DB2PROC,SYSTEM=DB2                              
//SYSPRINT DD SYSOUT=&SYSOUT$                                          
//SYSIN    DD *                                                        
         DSN '&YYYY$.&DB..&TS.(+1)'                                    
       GDGLIMIT(XX)                                                    
   //*

J'ai un OJCV à cause des ces variables.

J'aimerais savoir comment éviter cet OJCV sans utiliser les ACTION=NOSCAN ?

Est-ce possible ?


Merci d'avance pour votre aide.

Autre info : Les normes de production nous imposent de garder la SYSIN développée dans le JCL. En d'autres termes, on ne peut pas mettre de membre de PDS à la place...

[bernard59139]

Bonjour

en doublant les &, ca devrait fonctionner!

domage de ne pas utiliser les NOSCAN, c'est très pratique.

a+

[sam01]

Bonjour bernard59139 et merci pour ta réponse.

Je t'explique pourquoi j'aimerais me passer du NOSCAN :

Nous avons ce problèmes sur de très nombreux jobs et il faudrait passer une routine, qui mettre NOSCAN en début de job et NOSCAN à la fin. Ce n'est pas trop compliqué.

Mais ce qui risque d'être un peu plus compliquée (pour la routine), c'est de mettre les NOSCAN en plein milieu des JCL (juste avant et juste après les sysin concernée...

Le souci du noscan, c'est qu'OPC ne va pas scanner les vraies variables OPC...

Comment obliger OPC à faire la différence entre les variables non OPC et les variables OPC ?

[bernard59139]

Bonjour

je pensais que ca pouvait fonctionner en doublant les &. Mais OPC ne réagit pas comme les skeletons ISPF.

le truc:

• défini la variable DB et TS
• avec valeur par defaut un " " (blanc)
• et VAL REQ à N

sinon, pas d'autre moyen.

[arneo]

Bonjour,
Il me semble qu'il n'est pas possible pour OPC de faire la différence.
Rien ne t’empêche de relever toutes les variables OPC et dans ta procédure de faire des exclusions.

Après je ne comprend pas trop ton souci. Les JCL sont à modifier une fois! De plus pourquoi les JCL n'ont pas étés codés de cette manière à leur création si OPC est votre ordonnanceur ?

[sam01]

Ben justement, ce sont des JCL livrés qui tournent sur CA 7 et pas sur OPC....

Je vais tenté la technique de bernard59139.

Merci à tous.

[sam01]

Envoyé par bernard59139

Bonjour

je pensais que ca pouvait fonctionner en doublant les &. Mais OPC ne réagit pas comme les skeletons ISPF.

le truc:

• défini la variable DB et TS
• avec valeur par defaut un " " (blanc)
• et VAL REQ à N

sinon, pas d'autre moyen.

Une dernière chose bernard59139,

j'ai pas mal de job DB2 contenant des ? dans les DDL et ça me fait un OJCV.

Je dois aussi mettre le ? dans la table de variable ?

Au fait, si j'ai bien compris, la table de variable, c'est une sorte de zone d'exclusion de variables non reconnues par OPC..

[bernard59139]

Il y a 3 types de variables dans OPC.
extrait de la doc:

1.21.1.4 Ampersand, percent, and question mark variables

The three variable types, ampersand (&), percent sign (%), and question
mark (?), cause Tivoli Workload Scheduler for z/OS to perform variable
substitution in different ways. You can use a variable multiple times with
a different prefix symbol within the same job.

& et % n'ont pas bcp de différences.
? est une variable "tabulée" pour positionner une valeur exactement sur une colonne.

Pour connaitre la différence exacte entre chacune de ces variables, consulte la doc.

Pour ton soucis, avant de faire tout un tas de modif dans OPC; je reprendais l'ensemble des jcl+procédures et j'analyserai le bazard.
C'est un peu dommage de faire de complexifier une planification OPC.
le moyen le plus efficace est d'adapter la réception des jcl ou, peut-être, l'écriture du jcl original (par ex: on limite l'utilisation des ? & % ). je ne vois pas ce que viennent faire les ? dans un ddl.

Code :

une sorte de zone d'exclusion de variables non reconnues par OPC..

ce n'est pas ca, même si ca peut être expliquer comme cela.
Tu définis les variables, DB & TS. tu ne leur affecte aucune valeur , et comme la variable n'est pas renseignée, OPC ne fera rien (VAL REQ à N )
Car si qqun se met à valoriser les variables DB et TS, alors

[sam01]

Bonjour bernard59139,

je resors ce post car il y a une chose qui m'échappe.

Je n'ai pas trop compris comment je dois définir DB et TS afin que TWS ne me les traduise pas...

Je dois créer un table de variable : LAMBDA (par exemple) et dans cette table de mets DB et TS à NO c'est bien ça ?

Mais dans ce cas comment obliger le JCL ou l'application à taper dans cette de variable LAMBDA (sachant que j'ai plein d'autres tables de variable...)

Code :

1
2
'   LAMBDA           TEST              DB TS

puis j'ai

Code :

1
2
3
4
5
6
7
                                                                               
Row Variable Subst.   Setup  Val  Default                                      
cmd Name     Exit            req  Value                                        
'   DB                No     No                                                
'   TS                No     No                                                
******************************* Bottom of data ********************************

Merci pour ton aide.

[bernard59139]

Les jcl soumis par OPC doivent être conforme à ce que OPC peut traiter.

Dans ton cas, en définissant les variables DB & TS avec "SETUP NO", tu indiques à OPC que ces variables seront renseignées d'une autre facon (utilitaire db2 par exemple).

Par contre, pour travailler avec plusieurs tables de variables, je ne connais pas assez.