Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[z/OS] Inspect replacing low-value
Bonjour,
Pouvez-vous m'indiquer comment puis-je remplacer tous les low-value contenu dans un buffer par des espaces (en Cobol MVS) ?
J'ai essayé
INSPECT mon-buffer REPLACING x'00' by ' '
ou INSPECT mon-buffer REPLACING low-value by space
ou INSPECT mon-buffer REPLACING WS-LV by WS-SPACE (avec en WS: 01 WS-LV PIC X VALUE X'00'. et 01 WS-SPACE PIC X VALUE SPACE.)
Mais rien y fait ... Erreur de compil "It was not allowed in this context" sur x'00' ou low-value ou WS-LV suivant le cas.
Merci bocou
Bonjour.
devrait marcher.
Code : Sélectionner tout - Visualiser dans une fenêtre à part INSPECT data-name REPLACING ALL LOW-VALUE BY SPACE
Merci à Hédhili Jaïdane !
Il suffisait d'ajouter ce "ALL" comme suit:
INSPECT data-name REPLACING ALL LOW-VALUE BY SPACE
Entre temps et après recherches et sachant que les low-value ne sont pas nécessairement les uns à coté des autres, j'ai opté pour une autre solution, plus fastidieuse soit mais, peut-être, plus rapide (voir http://www-personal.umich.edu/~ritterd/technews1.html)
Voilà, si cela peut profiter à d'autres ...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11PERFORM REMPLACE-LV THRU F-REMPLACE-LV VARYING IND FROM 1 BY 1 UNTIL IND > MY-BUFFER-LENGTH. REMPLACE-LV SECTION. IF FREC-RECORD (IND:1) = LOW-VALUE MOVE SPACE TO FREC-RECORD (IND:1) END-IF. F-REMPLACE-LV. EXIT.
Un petit complément d'info.
Un test comparatif sur un AS400 (I5) en V5R4 (un 515) entre lINSPECT et le PERFORM VARYING sans IF sur le contenu du caractère portant sur une zone de 1000.000 de caractères LOW-VALUE à remplacer, dans le même programme : (série de 5 jets)
INSPECT VAR REPLACING ALL LOW-VALUE BY SPACE. --> : 0,02 secondes
PERFORM VARYING I FROM 1 BY 1 UNTIL I > 1000000
MOVE SPACE TO VAR(I:1). ------------------> : 0,11 secondes
Se méfier des allégations trop généralistes.
Je confirme pour MVS, Hédhili Jaïdane à parfaitement raison.
Un Inspect Replacing trivial d'un caractère par un autre sera 50 ou 100 fois plus rapide en MVS qu'une gestion indicielle 'mimine processing' même en choisisant une picture appropriée de son indice.
Les allégations de ce lien m'ont étonné alors j'ai vérifié avant de répondre. Il existe une instruction Assembleur pour faire ça directement : TR (à peine plus long qu'un simple Move) et c'est bien ce que génère Enterprise COBOL.
C'est fait intelligement, un seul TR pour une longueur > ou = 256 (la limite d'une opération simple, 2 pour =< 512 et une boucle de TR sur 256 pour des buffers longs.
Bon, maintenant c'est vrai que dans le cas on remplace une séquence multiple de caractères par une autre, c'est effectivement une fonction Cobol qui sera appelée (pas celle citée mais peu importe).
Cela étant, je doute que l'on puisse faire plus performant si on ne sais pas évaluer le généré assembleur. Bref je suggère d'oublier ce lien et de se rappeler qu'un Inspect replacing a l'avantage de la simplicité, donc de la 'lisibilité' et que c'est le but à rechercher avant tout non ?
Pas toujours. J'ai à générer du XML par dizaines de millions de lignes en un mois(sur MVS), et je dois remplacer certains caractères de mes zones en entrée. Je vais donc faire des tests de performance sur diverses solutions, parceque :
1)Le moteur ne sera pas amené à bouger des masses(contrairement à son alimentation)
2)La performance est cruciale sur ce moteur.
mais si l'inspect est plus rapide, ça fera un moteur plus lisible.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
ou eventuellemnt on préferera une boucle à l'INSPECT c'est si en une seule itération on peut tout réaliser comme changement.
je m'explique :
à mon avis une seule boucle sur la chaine de caracteres avec dans celle ci tous les tests et move sera plus rapide que plusieurs INSPECT replacing à la suite sur la meme chaine de caracteres.
Je n'ai pas de chiffre à dispo mais j'ai réalisé un modules il y a quelques temps du meme genre que ce que tu as à faire el_slappers. j'avoue avoir utilisé très très peu l'INSPECT pour justement la raison que je viens d'évoquer.
en une seule boucle d'analyse du buffer je realisais 80% des opérations ; ça reste plus rapide que d'enchainer 20 INSPECT sur une chaine de caracteres de 15000 octets (dans mon cas).
par contre du point de vu lisibilité, c'est effectivement pas vraiemnt le pied
Le "ALL ... BY ... " après INSPECT REPLACING peut être répété plusieurs fois, je ne sais plus combien maintenant dans le ILE et le II, il était de 50. On peut aussi faire du CONVERTING c'est l'équivalent de la répétition dans le REPLACING avec tous les caractères d'une chaine par les caractères correspondant d'une seconde chaine.
Le problème dès que l'on parle de performances est que tout compilateur génère des instructions en assembleur, dépendant de l'OS ou 'langage machine' si on préfére, et qu'une réponse valable pour un environnement, voire un compilateur, n'est pas forcément appropriée pour un autre. Pour MVS, une CBL NOOFFSET,LIST permet d'avoir la liste des instructions générées en Assembleur. Mais cela suppose des connaissances de l'assembleur pour évaluer les performances induites. Et même dans ce cas, des options de compilations par défaut, la longueur et le format des pictures choisies, ou simplement le fait que l'on remplace un ou plusieurs caractères dans notre INSPECT, ont une influence forte sur le code généré. La logique et la simplicité du code aident souvent beaucoup, pour les cas extrèmes il reste les tests en volumes. Heureusement que les machines actuelles ont une puissance sans commune mesure avec les premiers mainframe. Un exemple pour z/OS ou ou peut à présent adresser la mémoire en 64 bits. Pour le moment COBOL s'en tient aux quasi désuettes instructions générées ASM 390, pour raisons de portabilité, mais ça va changer. Il y des centaines de nouvelles instructions microcodées depuis, qui finiront par être utilisées et les résultats obtenus avec un compilateurs seront à réévaluer. Pas si grave, la puissance machine aura augmentée encore plus vite. Comme cela a été déja noté sur ce forum, on passe plus de temps à maintenir qu'à écrire. C'est donc la simplicité du code qui me semble la plus payante. Ceci dit El Slapper, j'ai débuté avec l'Assembleur à une époque ou on apprenait le temps induit par chaque instruction, alors pour ton problème spécifique de performances MVS, je suis à ta disposition si je peux t'aider. Un conseil pour tes premiers tests, commence par 'verrouiller' par une CBL en tête avec les options de compilation COBOL dont tu aurras pu constater qu'elles génèrent le code le plus performant, surtout OPT, TRUNC pour le binaire et même NUMPROC pour le numérique non binaire qui peut t'éviter pas mal d'instructions inutiles rien que pour la gestion des signes dans les calculs. Pour le binaire ne pas dépasser les pictures S9(8). Au delà, toutes les zones de calcul en comp-3. Pour les tableaux, des index, pas des indices. Un autre truc, regrouper les données les plus longues en fin de working, cela évitera à cobol de recharger ses BLW à tout bout de champ si la WSS est très grande.
mmmh, interessant. Merci.
pour les options de compil, on a du standard maison, mais avec du optimize partout. D'après les grands maîtres, c'est très efficaces - de toutes façons, je n'ai pas la main.
Pour la WSS, je ne connaissais pas ce truc de mettres les gros morceaux à la fin, je verrais. Mais bon, c'est pas énorme, quelques milliers de caractères. A optimiser quand même.
Mon code actuel, pour remplacer les caractères emmerdants :
ça marche, ça me renvoie le positionnement POS dont j'ai besoin pour formatter le bousin(et faire le traitement d'erreur si ça dépasse), ça remplace les caractères indésirables, mais j'ai quand même des doutes sur la performance.....
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
5377 POS PIC S9(003) COMP-3. 77 LON PIC S9(003) COMP-3. 77 COMPTEUR PIC S9(003) COMP-3. AJOUT-DONNEE. * ELIMINATION DES BLANCS NON SIGNIFICATIFS MOVE LONGUEUR-LUE TO LON SET W-SORT-2-KO TO TRUE PERFORM UNTIL W-SORT-2-OK IF LON < 2 SET W-SORT-2-OK TO TRUE ELSE IF CHAINE-ECRITE(LON:1) = SPACE OR LOW-VALUE OR HIGH-VALUE SUBTRACT +01 FROM LON ELSE SET W-SORT-2-OK TO TRUE END-IF END-IF END-PERFORM * ECRITURE DANS LA CHAINE FINALE AVEC TRANSFORMATION * DES CARACTERES SPECIAUX MOVE +01 TO COMPTEUR PERFORM UNTIL COMPTEUR > LON MOVE CHAINE-ECRITE(COMPTEUR:1) TO CARACTERE EVALUATE CARACTERE * LOW-VALUE et HIGH-VALUE SONT IGNORES PAR SECURITE WHEN LOW-VALUE WHEN HIGH-VALUE CONTINUE * LES CARACTERES SPECIAUX SONT CODES EN 3/4 CARACTERES WHEN '&' MOVE '&' TO W-CHAINE-XML (POS:4) ADD +04 TO POS WHEN '<' MOVE '<' TO W-CHAINE-XML (POS:3) ADD +03 TO POS WHEN '>' MOVE '>' TO W-CHAINE-XML (POS:3) ADD +03 TO POS * LES CARACTERES NORMAUX SONT CODES EN 1 CARACTERE WHEN OTHER MOVE CARACTERE TO W-CHAINE-XML (POS:1) ADD +01 TO POS END-EVALUATE ADD +01 TO COMPTEUR END-PERFORM . AJOUT-DONNEE-FIN. EXIT.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Bonjour,Envoyé par el_slapper
Pourquoi n'utilises-tu pas des POS, LON et COMPTEUR en COMP ?
Et le contrôle de dépassement, à mon avis, devrait être fait avant les MOVE présents dans l'EVALUATE, car tu as un risque d'écrasement de données.
Bonjour, et merci
C'est mieux? Dans la doc que j'avais, ils en parlaient comme d'un kifkif. Si comp naturel est mieux, je prends évidemment
Le truc, c'est que je remplace des chaines de 1 par des chaines de 3 ou 4, dans le cas des caractères spéciaux. Je connais ma longueur avant transformation, pas ma longueur après(sinon je me serais pas fait suer). W-CHAINE-XML est assez grande, par contre, la zone cible dans laquelle je la move est limitée à 250(je sais pas pourquoi, mais c'est dans les specs techniques). Donc si j'ai plus, je la coupe en 2(non décrit ici, mais je ne te ferais pas l'insulte de te décrire comment).
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Avant de répondre, j'ai pris le temps zoomer sur le généré en prenant comme hypothèse que la chaine traduite est reçue EN PARM.
Peu importe la longueur, un INSPECT REPLACING simple restera gagnant.
Avant tout, je dois dire que ce code est d'origine performant mais on peut faire mieux.
1) 2 Inspect permettent de gagner une première boucle et des risques d'erreurs éventuels, même au prix d'une copie LS en WSS ajoutée.
2) Fremen167 a raison, on est ici gagnant avec des zones de travail en binaire. De façon générale tant que l'on s'en tient à des PIC S9(4) et S9(8), surtout pas au delà.
Je ne me suis pas occupé de la logique, fonctionnelle. Le généré ne fait après modifs que des opérations registres et des mouvements simples mémoire à mémoire. Idéal en terme de performances.
Nb. Pour le déport des données importantes en fin de working et sans entrer dans trop de détails, noter simplement que COBOL MVS addresse sa working via une table d'adresses consécutives (Base Locator Working) par adresses de 4K.
Ces registres sont mémorisés en +12C de la TGT (cf TGT mémory MAP d'une liste de compilation Enterprise Cobol. A noter le 'drapeau' interne '3TGT', pratique pour retrouver une TGT dans un DUMP et donc pour remonter aux BLW, suivis des BLL(inkage) et/ou BLF(ile).
Le fait de déporter en fin de WSS les données conséquentes revient à rendre adressables par le même BLW (0) les données les plus nombreuses en tête et peu permettre d'éviter des réadressages BLW trop fréquents.
Le généré 'optimisé' donne ceci (peu de modifs in fine).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87CBL NOOFF,LIST Identification Division. PROGRAM-ID. XCOBTSTP. *======================== * pgm de test généré ASM *======================== Environment Division. Data Division. *======================== Working-Storage Section. *======================== 01. 05 Pic x(8) Value '£COBTSTP'. ---- * 05 LON Pic S9(3) comp-3. 05 POS Pic S9(4) binary. UPD 05 COMPTEUR Pic S9(4) binary. 05 W-SORT Pic x. 88 W-SORT-2-OK Value space. 88 W-SORT-2-KO Value high-value. 05 CARACTERE Pic x. UPD 05 CHAINE-ECRITE Pic x(120) Value spaces. 05 W-CHAINE-XML Pic x(480) Value spaces. *================ Linkage Section. *================ * 01 LS-PARM. 05 LONGUEUR-LUE Pic S9(4) Binary. ADD 05 CHAINE-RECUE Pic x(120). *=================== Procedure Division using LS-PARM. *=================== AJOUT-DONNEE. ---- * ---- * ELIMINATION DES BLANCS NON SIGNIFICATIFS ---- * MOVE LONGUEUR-LUE TO LON ---- * SET W-SORT-2-KO TO TRUE ---- * PERFORM UNTIL W-SORT-2-OK ---- * IF LON < 2 ---- * SET W-SORT-2-OK TO TRUE ---- * ELSE ---- * IF CHAINE-ECRITE(LON:1) = SPACE ---- * OR LOW-VALUE ---- * OR HIGH-VALUE ---- * SUBTRACT +01 FROM LON ---- * ELSE ---- * SET W-SORT-2-OK TO TRUE ---- * END-IF ---- * END-IF ---- * END-PERFORM ADD Move CHAINE-RECUE(1:LONGUEUR-LUE) to CHAINE-ECRITE * ECRITURE DANS LA CHAINE FINALE AVEC TRANSFORMATION * DES CARACTERES SPECIAUX ADD Inspect CHAINE-ECRITE Replacing all x'40' by x'00' ADD Inspect CHAINE-ECRITE Replacing all x'FF' by x'00' MOVE +01 TO COMPTEUR UPD PERFORM UNTIL COMPTEUR > length of CHAINE-ECRITE MOVE CHAINE-ECRITE(COMPTEUR:1) TO CARACTERE EVALUATE CARACTERE * LOW-VALUE IGNORE WHEN LOW-VALUE Continue * LES CARACTERES SPECIAUX SONT CODES EN 3/4 CARACTERES WHEN '&' MOVE '&' TO W-CHAINE-XML (POS:4) ADD +04 TO POS WHEN '<' MOVE '<' TO W-CHAINE-XML (POS:3) ADD +03 TO POS WHEN '>' MOVE '>' TO W-CHAINE-XML (POS:3) ADD +03 TO POS * LES CARACTERES NORMAUX SONT CODES EN 1 CARACTERE WHEN OTHER MOVE CARACTERE TO W-CHAINE-XML (POS:1) ADD +01 TO POS END-EVALUATE ADD +01 TO COMPTEUR END-PERFORM . AJOUT-DONNEE-FIN. EXIT. Goback.
Un grand merci.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager