Discussion :

[ptit.homm]

Bonjour,

Je voudrais savoir les tailles en octets des compressions en Cobol.
Je m'explique.
J'ai des champs en X que je voudrais mettre sous le nombre d'octets des compression possible.

Ex :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
01 w-variable     pic x(4) .
01 w-var-comp   pix S9(4) comp .
01 w-var-comp3 pix S9(4) comp -3 .

Je voudrais donc savoir la place en octets d'un comp pour me permettre de faire un MOVE directement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

move w-varaible   to w-var-comp3

Autre question.
Est ce possible de faire un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

move w-variable(1:w-lng) to w-toto

avec w-lng = 2.5 ?

Merci.

[Hédhili Jaïdane]

Bonjour.

- comp : display ou zoned decimal (décimal étendu)
- comp-4 : binaire
2 Bytes si 1 à 4 digits
4 Bytes si 5 à 9 digits
8 Bytes si 10 à 18 digits
16 Bytes si 19 à 31/36 digits (si admis)

- comp-3 : condensé ou packé (paqué)
E(n/2)+1 : partie netière du nombre des digits + 1
ex : 4 digits ==> e(4/2)+1=2+1=3 octets
5 digits ==> e(5/2)+1=2+1=3 octets

dans tous cas le signe ne prend pas de place sauf si TRAILING/LEADING SEPARATE est indiqué.

pour certains compilateurs comp et comp-3 sont équivalents, pour d'autres comp et comp-4 sont équivalents.

En ce qui concerne le MOVE, normalement la conversion se fait automatiquement entre champs numériques. Pour des champs numériques et alphanum, les règles peuvent différer d'un compilateur à un autre, mais en règle général, on ne peut faire de l'alphnum vers du compxxx et inversement. Les champs doivent être en usage display et de préférence de même longueur et à condition que le contenu soit valide. On utilise généralement le REDEFINES pour faire certaines opérations (de bricolage).

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
         01 REPRO-C4  pic 99 comp-4 value 28.
         01 REPRO-XX redefines REPRO-C4.
	03 filler  pic x.
	03 DUPKEY  pic x.
        *	REPRO-XX est un groupe alphanum.de longueur 2 dont la
        *		zone DUPKEY contient le caractère de reproduction.

- move w-variable(1:w-lng) to w-toto avec w-lng = 2.5 ?
A ma connaissance, c'est NON : w-lng doit être un entier positif.

[Hédhili Jaïdane]

En fait, tu travailles avec quel compilateur et quel OS et quelle version ?

[el_slapper]

pour préciser la dernière partie de la réponse : un comp-3 a toujours une longueur en octets entière, même si un demi octet peut être perdu. D'une manière générale, les données sont toujours sous forme d'un octet complet.

donc travailler sur une longueur non entière n'est pas prévu dans les compilateurs.

en outre, le demi-octet perdu en comp-3 sur un nombre de chiffres codés pair se situe au début. En d'autres termes, un PIC9(4) COMP-3 et un PIC9(5) COMP-3 apparaitront exactement de la même manière en mémoire. la seule différence étant que les dizaines de milliers seront toujours à 0 dans le premier cas.

[ptit.homm]

merci pour vos réponses.
Ce qui me perturbait le plus etait de savoir si les 1/2 octets été perdu pour le comp -3, d'ou ma question du move toto(0.5:1.5).

Oui j'utilise bien des redefines et je viens de retrouver la regles de calcul du nombre d'octets qui est la même que Hédhili Jaïdane.
si lng impaire : nb-octet = (lng + 1 ) / 2
si lng paire : nb-octet = (lng / 2 ) +1

Si les 1/2 octects sont vraiment perdu cela veux dire que le S9(4) COMP-3 et équivalent au S9(5) COMP - 3.

car S9(4) COMP-3 : nb-octet = (4 / 2 ) + 1 = 3
car S9(5) COMP-3 : nb-octet = (5 + 1 ) / 2 = 3

non?

[Hédhili Jaïdane]

En comp-3, les 1/2 octets ne sont pas perdus, ils sont occupés par les digits de ton nombre, sauf le 1er de gauche. C'est pour cela, quand on utilise le comp-3, on préfère profiter de cette possibilité et déclarer les variables avec une longueur impaire.
le nombre 1234, au lieu d'être représenté en étendu sous la forme F1F2F3F4 (en EBCDIC), va occuper 3 octets au lieu de 4 et sera représenté comme suit : 01234F.
La formule de calcul de la taille du comp-3 est la suivante : E(n/2)+1, tu n'as pas à te casser la tête pour tester pair et impair, tu divises par 2 avec troncature (sans arrondi) et tu ajoutes 1 sans te soucier de la parité.

Et effectivement un nombre pair occupe la même place que le nombre impair qui le suit. Le signe occupe le 1/2 octet le plus à droite et est représenté par F ou par D.

[Homer-ac]

Je peux essayer de compléter spécifiquement pour COBOL z/OS.
1) COMP-3 représente du décimal condensé - packé (COMP-3 ou packed-decimal)
2) COMP ou COMP-4 équivalant, représente du binaire, conversion sans rapport avec celle de COMP-3

Rien à ajouter pour les longueurs. C’est COBOL qui se chargera de la conversion. Il faut juste s’assurer que la longueur indiquée dans le pic 9 de la zone cible est >= à la longueur de la zone d’origine sinon risque de troncation.
Exception toutefois, pour le binaire, la valeur maximale pouvant être stockée dépend d'une option de compilation de COBOL (TRUNC(STD) ou TRUNC(BIN)). C’est pourquoi IBM a ajouté un COMP-5 pour du binaire éventuellement externe pour éviter un risque de troncation sur le nombre de chiffres indiqués en Pic 9 de la zone cible, si TRUNC(BIN) n’est pas positionné (alors valeur binaire maximum possible pour le nbre d’octets réservés 2, 4 ou 8).


Pour la question du MOVE en utilisant les référence modifiers, Il faut noter que COBOL fait un MOVE d'une zone en pic X implicite vers une autre. Donc :
- Pas de changement de format et surtout pas un MOVE du format Display vers du COMP-3
- La longueur doit être un entier positif représentatif du nombre de caractères effectivement réservés par COBOL.

[fremen167]

- comp-4 : binaire
2 Bytes si 1 à 4 digits
4 Bytes si 5 à 9 digits
8 Bytes si 10 à 18 digits
16 Bytes si 19 à 31/36 digits (si admis)

Une précision pour mieux comprendre les limites de valeurs en binaire:

• 2 octets = 16 bits ==> 2**16 = 65 536 valeurs (ou -32768/+32767). En représentation décimale, seuls 4 chiffres peuvent être complètement utilisés (c'est-à-dire avec valeur de 0 à 9), d'où le S9(4) COMP - "4" indique le nombre de chifres de la représentation décimale.
• 4 octets = 32 bits ==> 2**32 = 4 294 967 296 valeurs, d'où S9(9) COMP.
• 8 octets = 64 bits ==> 2**64 18 446 744 073 709 551 616 (donc -9 223 372 036 854 808/+9 223 372 036 854 807) d'où S9(18) COMP.

Il est inutile de définir une zone en 9(5) COMP par exemple, elle sera physiquement en 9(9) COMP.

A noter enfin que sur z/OS, le compilateur interdit de définir une variable comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

01 VAR-NUM         PIC S9(4) COMP VALUE +12000.

Par contre, une zone en S9(4) COMP peut tout-à-fait contenir la valeur 12000, elle est bornée par -32768/+32767 !

[fremen167]

Je peux essayer de compléter spécifiquement pour COBOL z/OS.
1) COMP-3 représente du décimal condensé - packé (COMP-3 ou packed-decimal)
2) COMP ou COMP-4 équivalant, représente du binaire, conversion sans rapport avec celle de COMP-3

Le type BINAIRY existe également, équivalent à COMP.

[valmi32]

réflexion:
en 1970, je compilais en COBOL avec 12 ko... y avait intérêt à segmenter sec, intégrer des séquences assembleur pour économiser de l' octet...

aujourdhui on a de la place, on peut s' étendre voire même se vautrer ...


:

valmi32

[Homer-ac]

Les formats Binary ou packed-decimal ne sont effectivement pas ou plus faits pour gagner de la place mémoire. Cependant, pour gagner de la conso CPU c'est certain. J'ai vu des gains significatifs de performances rien qu'en changeant le format d'indices et de zones de calculs 'honteusement' utilisées.
C'est évident, cela dépend du compilateur et de l'OS. Pour MVS je connais un peu. Le langage machine ne sait faire des opérations arithmétiques que sur du binaire (opérations registres) ou du packé (opérations mémoires, en gros) et COBOL génère plus de la moitié des instructions rien que pour changer le format et forcer les signes des données numériques.
Il fut un temps ou on demandait d'abuser des COMP, le binaire, simplement parce que COBOL1 passait le plus possible par des opérations binaires, 3 X plus rapides que des opérations packées. Cobol II et Enterprise Cobol en particulier, généralise les convertions en packé (COMP-3). C'est à l'évidence moins performant mais après tout IBM vend de la CPU. Moins de risques de plantage S0C7 aussi (ABC risque de devenir 123). Ce peut être un argument, mais je préfère qu'un pgm plante et soit corrigé plutôt que de restituer des résultats erronnés, pas nécessairement détectés.
Oui, c'est une évidence, on dispose à présent de mémoire et de MIPS sans commune mesure avec les machines d'il y a (seulement?) 10 ans, et il serait plus coûteux de payer des spécialistes en performances que d'ajouter du MIPS. Pour autant, il me semble un peu abusif d'aller jusqu'à rejeter tout intérêt à l'optimisation 'at minima' du code.
NB. Pour ceux un peu curieux qui 'cobolisent' en z/OS, faites le test de compiler un pgm de calcul indiciel avec une CBL LIST et de comparer le généré avec le même source après avoir généralisé les PIC 9 COMP-3. (pas besoin de connaître l'assembleur, le simple compte des instructions ASM générées pour 1 instruction COBOL numérique donne déjà une idée).

[xfanx]

je plussoie à ton post Homer-ac; d'autant que non, il n'est largement pas inutile de payer une équipe de spécialiste dans l'optimisation d'un SI plutot que d'acheter des mips. Une équipe support technique dont le role est de faire ce genre de regle de bonne conduite et de les faire respecter ne peut qu'apporter un gros plus à une société.
Le MIPS coute cher, à l'achat et souvent aussi à cause des progiciels installés sur les LPAR dont les cout de licence pour certain sont liés à la puissance machine.


Comme tu le dis, il y a des manieres, des règles très simples à respecter qui font gagner énormément. Dans ton exemple, merci d'ailleur, j'en étais resté aux indices en Pic s9(4) comp... si le comp-3 est meilleurs, tu peux etre sure que cela deviendra une norme dans la moe de ma boite. ^^ Il en est de même avec l'usage abusif de l'ordre INITIALIZE que font beaucoup de programmeurs.. des niveau 01 xx PIC X alors qu'on perd 3 octets d'alignements à chaque fois..Etc...

il y a quelques années nous étions encore en AMODE/RMODE24 et avions du mal à tourner certaines de nos applications, faire cet effort de gain de place nous a souvent rendu service. C'est toujours vrai aujourd'hui. on nous dit AMODE31/RMODEANY soit.. l'adressage 31bit reste quand meme quelque chose d'assez "virtuel" ; dans la réalité on s'apercoit que nos traitements sont toujours limités en taille de mémoire; personne n'aurait l'idée de mettre le paramatres REGION=2G dans son JCL! et d'ailleurs Z/OS ne l'accepterait certainement pas...

[el_slapper]

autre exemple vu récemment d'INITIALIZE mal utilisé : on INITIALIZE une zone complète de description de fichier, puis on en remplit l'intégralité par des données variées.....

[xfanx]

Il fut un temps ou on demandait d'abuser des COMP, le binaire, simplement parce que COBOL1 passait le plus possible par des opérations binaires, 3 X plus rapides que des opérations packées. Cobol II et Enterprise Cobol en particulier, généralise les convertions en packé (COMP-3). C'est à l'évidence moins performant mais après tout IBM vend de la CPU. .

ça m'a "travaillé" tu n'imagines meme pas combien ce que tu as écrit.. du coup j'ai fouillé les programming Guide et tuning Cobol enterprise et fait quelques essais de compilation. En fait, en ce qui concerne la favorisation du Packé par le compilateur, ce n'est pas tout à fait vrai.. Si la zone binaire que tu définies est alignée sur un mot (S9(8) comp=4 octets), alors le binaire sera gardé; par contre si tu dépasses le mot, il y aura conversion en packé .
ce qui est en fait logique puisqu'en assembleur, dès qu'une opération binaire dépasse le mot, il est obligé de travaillé en double registre, donc un autre jeu d'instruction. je suppose alors qu'il est plus rapide de travailler packé dans ce cas que de travailler en double registre.
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
I PIC S9(8) COMP.
ADD 1 TO I

LH    2,18(0,10)
A     2,296(0,8)
ST    2,296(0,8)

I PIC S9(9) COMP

PACK  312(5,13),280(9,8)   
AP    312(5,13),139(1,10)  
ZAP   312(5,13),312(5,13)  
UNPK  280(9,8),312(5,13)

d'ou l'interret de TOUJOURS définir ses données binaires en multiples de 4
s9(4) comp ou s9(8) comp

[Homer-ac]

Pour compléter les remarques précédentes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
non, il n'est largement pas inutile de payer une équipe de spécialiste dans l'optimisation d'un SI plutot que d'acheter des mips.

L'impasse sur l'optimisation, on ajoute du mips, n'est pas une préconisation mais un constat de tendance que j'ai parfois constaté et déplore. J'ai vu des sociétés ou on a tenté de réduire des compétences de type bureau techniques, certaines ont vérifié ensuite que ce n'était pas tj une bonne idée et remettent en place des structures équivalentes.

Pour les performances liées à l'abus de certaines instructions, il faut être prudent et s'attacher à la simple logique. Oui INITIALIZE est pratique mais à consommer avec modération. Rien à dire dans un perform initialisation de début mais dans une boucle, surtout si pour réalimenter ensuite !
Mais oui aussi, INITIALIZE est la méthode la plus rapide pour initialiser un tableau plutôt qu'une boucle de RAB/RAZ, même si on passe par des index, plus rapides que via des indices.
Dans la même logique, d'autres ordres comme STRING/UNSTRING étaient déconseillés en COBOL1. Ils sont à présent moins coûteux et reconnaissons le, parfois bien pratiques.

Pour les AMODE/RMODE 24, c'est surtout l'option DATA 31 qui compte, donc forcément AMODE ANY, dont l'intérêt s'il est quasi nul pour un Batch qui exécute un COBOL raisonnable ressort mieux pour des COBOL CICS qui peuvent cohabiter en mémoire haute ou des applications COBOL qui se complexifient. Les diverses contraintes de limitations de taille (cf Enterprise COBOL Migration Guide) explosent en DATA 31, et plus encore avec la dernière version 4.1 d'Enterprise COBOL, pour récupérer par exemple des données fichiers USS ou provenant d'appli externes.

Il n'y a pas si longtemps le batch s'exécutaient avec une Région de 2M puis 4M avec la généralisation de language Environment (près de 1M rien que pour lui), maintenant souvent plus, c'est un constat de tendance, c'est vrai que la mémoire réelle est moins onéreuse, encore une fois ce n'est pas une excuse pour renoncer à toute logique élémentaire.

Enfin pour les préconisations binaire/packé ce n'est surtout important que pour les tableaux et implications d'occurrences multiples. A ce titre la gestion par index reste la plus économique et en plus on ne risque pas de se planter dans une définition d'indice que l'on n'a plus à faire. Sinon il est périlleux de donner des rêgles trop générales sachant qu'il faut aussi tenir compte des longueurs, alignements et options de compilation COBOL. NUMPROC par exemple a un impact sur le généré pour les zones en COMP-3, TRUNC pour le binaire. SSRANGE par contre, rien à voir, en voilà une option qui peut aider mais qui coûte un max ! Pour autant ce que j'ai indiqué reste vérifié. Le généré COBOL II fait une part plus importante aux opérations packées que COBOL 1 qui privilégiait plus systématiquement les opérations registres.

[Homer-ac]

Pic S9(5), s9(9) ou S9(8) Comp c'est un mot = 4 octets dans tous les cas et IBM documente largement la généralisation des Pic S9(9).
Le généré pouvait passer par des opérations registres. Ton exemple met en évidence le fait que ça peut rester vrai si on peut passer par un demi-mot

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
LH 2,18(0,10) -> Load Half Word / L : LOAD WORD
A 2,296(0,8)
ST 2,296(0,8) ->               ST : STORE WORD

Un Load pouvait marcher, mais c'est vrai, Cobol II doit se préoccuper de l'AMODE 31 qui obligerait dans un Load, contrairement à LH, à tenir compte du bit de gauche en plus, alors que COBOL 1 ne connaissait que l'AMODE 24. C'est donc aussi quelque part des solutions de facilité qui s'appliquent pour le compilateur par rapport à COBOL1.

[Homer-ac]

Voici un petit COBOL pour tester les différentes façons d'initialiser un tableau volontairement avec un nombre d'occurs presque aussi grand que possible. On fait un display de l'heure avant et après chaque méthode. Je sais, pas réellement significatif surtout sur une machine puissante. C'est de l'elapse pas de la CPU et à moins de passer par CEELOCT (milièmes) on ne mesure en COBOL que des centièmes de secondes. Mais ça donne déjà une idée, on peut par ailleurs jouer sur la longueur des indices binaires et vérifier le code généré par l'option LIST.
Il y a aussi une initialisation par propagation de la gauche vers la droite, C'est une méthode assez connues des programmeurs Assembleur qui a fait ces preuves mais assez risquée si on ne comprend pas bien le mécanisme. Ce n'est pourtant guerre plus performant qu'un simple INITIALIZE.
Ce qu'on peut en déduire: l'INITIALIZE est devenu assez performant (pas une raison pour en coder inutilement), sinon l'indexation d'un tableau est au moins 2X plus rapide qu'une gestion indicielle même si on se débrouille pour que les longueurs dans les PIC BINARY permettent de générer des opérations binaires.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
       CBL LIST,NOOFF
       Identification Division.
        PROGRAM-ID. COBTST.
      *------------------------------------------ TEST COBOL
      * TESTER LES PERFORMANCES COBOL SUR LES DIFFERENTES MANIERES
      * D'INITIALISE UN TABLEAU : INDICES DISPLAY/PACKE/BINAIRE
      *                         : INITIALIZE
      *                         : PROPAGATION GAUCHE VERS DROITE
       Environment Division.
       Configuration Section.
       Source-computer. IBM-ES9000.
       Input-Output Section.
       Data Division.
 
       Working-Storage Section.
       01.
          02                          pic x(12) Value 'WSS-COBTST'.
          02  DATE-HEURE.
              05                      Pic x(12).
              05 DATE-HEURE-SSCT      Pic 9(4).
          02  SSCT                    Pic Z9/99.
      *                            Alignement des zones binaires
       01     INDICE-PERFORM          pic s9(9) Binary Value 0.
       01     LG1                     pic s9(9) binary.
       01     LG2                     pic s9(9) binary.
       01.
          02  LG1P                    pic s9(9) Comp-3.
          02  LG1D                    pic s9(9).
      *                            Reservation d'un poste à initialiser
          02  TAB1P.
              10                     pic XX   value 'AB'.
              10                     pic 9(4) value 0.
              10                     pic X(4) value ALL '*'.
       01.
      *                     OCCURS quasi au maxi pour relevé temps
          02  LGI                     pic s9(9) binary value 1677000.
          02  LGIP                    pic s9(9) Comp-3 value 1677000.
          02  LGID                    pic s9(9)        value 1677000.
       01.
      *                     TABLEAU : OCCURS à mettre à jour avec LGI
          02  TAB1.
          03    TAB1-P1 OCCURS      1677000 times
                                    indexed by TAB1-I1.
              05  DATA1              pic XX.
              05  DATA2              pic 9(4).
              05  DATA3              pic X(4).
      *                     DRAPEAU pour vérif non écrasement / fin PGM
          02  FINI                   pic x(10) value 'FINIFINIFI'.
 
       Linkage Section.
       Procedure Division.

       MAIN Section.
       DEBUT-PGM.
      *
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
 
           display '1:AVANT INITIALIZE A ' SSCT ' Centièmes sec.'
           INITIALIZE TAB1
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '1:APRES INITIALIZE A ' SSCT ' Centièmes sec.'
 
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '2:AVANT PERFORM D9 A ' SSCT ' Centièmes sec.'
           PERFORM Varying LG1D from 1 by 1
             UNTIL LG1D > LGID
                Move TAB1P   to TAB1-P1(LG1D)
           End-Perform
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '2:APRES PERFORM D9 A ' SSCT ' Centièmes sec.'
 
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '3:AVANT PERFORM PK A ' SSCT ' Centièmes sec.'
           PERFORM Varying LG1P from 1 by 1
             UNTIL LG1P > LGIP
                Move TAB1P   to TAB1-P1(LG1P)
           End-Perform
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '3:APRES PERFORM PK A ' SSCT ' Centièmes sec.'
 
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '4:AVANT PERFORM BI A ' SSCT ' Centièmes sec.'
           PERFORM Varying LG1 from 1 by 1
             UNTIL LG1 > LGI
                Move TAB1P   to TAB1-P1(LG1)
           End-Perform
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '4:APRES PERFORM BI A ' SSCT ' Centièmes sec.'
 
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '5:AVANT PERFORM IX A ' SSCT ' Centièmes sec.'
           PERFORM Varying TAB1-I1    from 1 by 1
             UNTIL TAB1-I1 > LGI
                Move TAB1P   to TAB1-P1(TAB1-I1)
           End-Perform
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '5:APRES PERFORM IX A ' SSCT ' Centièmes sec.'
 
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '6:AVANT INITIALIZE A ' SSCT ' Centièmes sec.'
           INITIALIZE TAB1
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '6:APRES INITIALIZE A ' SSCT ' Centièmes sec.'
 
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '7:AVANT MOVE GLOBAL: ' SSCT ' LG1 = ' LG1

           Add      1                 to   Length of TAB1-P1 Giving LG1
           Subtract Length of TAB1-P1 from Length of TAB1    Giving LG2
           Move TAB1P       to TAB1-P1(1)
           MOVE TAB1(1:LG2) to TAB1(LG1:LG2)
           Move function current-date to DATE-HEURE
           Move DATE-HEURE-SSCT       to SSCT
           display '7:APRES MOVE GLOBAL: ' SSCT ' LG1 = ' LG1
                                                ' LG2 = ' LG2
 
           Display TAB1(1:10)
           Subtract 1 from LGI
           Display TAB1-P1(LGI) '!' FINI ' (LGI = ' LGI ' )'
           goback
                 .
       End Program COBTST.

[xfanx]

mmmmmm à mon avis, Cobol traite le PIC S9(9) comp comme un double mot..
cf le généré assembleur..il le traite sur une longueur de 8.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
I PIC S9(9) COMP

PACK 312(5,13),280(9,8)
AP 312(5,13),139(1,10)
ZAP 312(5,13),312(5,13)
UNPK 280(9,8),312(5,13)

Cela dit, tout cela devient faux dès qu'on passe en option OPTIMIZE du compilateur; la, le code généré est vraiment "optimisé" . d'ou l'interret de mettre systématiquement en oeuvre cette option en production.. avec les probleme posé avec l'incompatibilité des produit telqu'ABend Aid et Xpeditor.
surtout AbendAid si on veut un Dump 'détricotté' avec le source...


en ce qui concerne l'initialize, je reste quant à moi très prudente sur son utilisation.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
01 tx.
    05  t1  pic x.
    05  t2  pic x.
    05  t3  pic x.
INITIALIZE TX.

le code généré sera :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MVC   272(2,8),44(10)
MVC   274(2,8),44(10)
MVC   276(2,8),44(10)

un équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MOVE SPACES to T1.
MOVE SPACES TO T2.
MOVE SPACES TO T3.

Pas très genant quand la structure TX à peu de sous champs, mais problématique dans le cas contraire.

Alors que dans ce cas, faire un MOVE SPACES TO TX est beaucoup mieux.


contrairement à toi, mes procaunisations sur initialize sont de franchement les limiter. avec la regle suivante :

Si pas de zone numérique -> un move space dans le level 01 suffit.

Si zones numériques ->
move spaces dans le level 01
move 0 dans toutes les zones numériques.


fait quelques essais , non pas en displayant le time, ( pas grand interret puisque tu generes un interrupt machine à chaque fois et que le time que tu recuperes tient compte de ce wait assez variable ma fois) mais en faisant une grosse boucle.

tu verras en résultat d'exécution du job une grosse différence sur le LAPS et surtout la conso CPU en fonction des choix..

sachant que le calcul de MIPS est une autre forme de calcul de la consommation CPU necessaire pour une machine, c'est celle ci qui est à retenir.

à mon humble avis

juste pour finir, reprend ton programme et refait le même test en mettant tes indices à S9(8) comp. bien sur Index sera toujours plus rapide qu'indice. mais pour l'initialize à mon avis les résultats de tes tests vont changer

[Homer-ac]

Pour clore ce débat qui prend des proportions disons disproportionnées, je veux juste ajouter quelque remarques.
J'ai évoqué des tendances générales de COBOL1 à COBOL2. Ma remarque sur IBM fournisseur de MIPS qui ne voulait être qu'une boutade, était en fait une bétise si elle a pu être prise autrement. IBM devait assurer le passage en 31 bits en utilisant des instructions assembleur 390 pour des impératifs de portabilité (instructions 370 + opérations longues). C'est du microcode à présent largement plus performant qui bosse derrière et le problème est plus la compatibilité que le temps par instructions. Continuer à privilégier les instructions registres en 31 bits reste possible quand on programme assembleur mais plus difficile et périlleux pour un compilateur qui doit tenir compte de contextes multiples. Il en résulte et ça me semble logique alors que l'on peux a présent travailler en 64 bits que les anciens 'canons de bonne conduite' COBOL1 sont ou seront rapidement dépassés. On peut juste parler de tendance, d'ou plus de recours au packé. En contrepartie et un peu grace à Langage Environnement, certaines instructions coûteuses qui nécessitaient de l'acquisition mémoire perdent leurs restrictions simplement parce qu'un contexte chargé au premier appel est accessible.

Concernant la remarque sur INITIALIZE il faut juste parler de la même chose. Entre un move groupe et un initialize il n'y a pas photo, ni dans le sens contraire quand on gère une table indicée, entre des MOVE via un indice ou index et un INITIALIZE, et je parlais uniquement de gestion indicielle très génératrice d'instructions de changements de formats.

Concernant les tests que j'ai pu faire pour vérifier, je l'ai dit c'est de l'elapse, ça donne juste une idée. Même si je dois tenir compte d'interruptions machines, comme j'ai la chance de disposer d'une partition système que je peux me réserver un temps, si j'exécute plusieurs fois le même batch seul et sans autre TSO connecté et que je constate des ratios du même ordre (le temps effectivement ne veut rien dire), je peux considérer que les résultats ont un niveau de validité raisonnable.

Concernant le généré, il faut donner tout

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
I PIC S9(9) COMP

PACK 312(5,13),280(9,8)
AP 312(5,13),139(1,10)
ZAP 312(5,13),312(5,13)

Un S9(9) COMP génère un MOT binaire (cf option MAP). Un pack ne travaille pas avec du binaire, c'est de la conversion étendu vers du packé.
NB. le 8 que vous faites ressortir n'est pas une longueur mais un registre général d'adressage mémoire, la longueur de la zone émétrice est 10 (9+1 ; 0=1), celle de la zone réceptrice est 6 (5+1), adressée via le registre 13.
L'option OPT peut améliorer mais il ne faut pas tout lui demander. Ici, tout ce passe comme si la zone COMP avait été pré-convertie en DISPLAY. Ca devient à la limite plus rapide d'enlever COMP et de toutes façons COBOL ne peut faire ceci que dans des contextes ponctuels ou une donnée est 'fixée', non résultante de calculs. Sinon la bonne séquence serait un CVD avant un AP et les 2 cas restent moins rapides qu'un LOAD suivi d'un AR comme l'aurait fait COBOL1. Bon je ne veux pas donner de leçon technique, mais on est dans un domaine que je connais un peu et je vous suggère de vérifier le généré du même programme en enlevant COMP, ça surprend.

Quant à un comparatif en S9(8) Comp, ça fera mieux mais bien moins bien qu'un INITIALIZE, j'avais déjà vérifié. Encore une fois pour une gestion indicielle.

Ce qui me semble utile de retenir, les index à privilégier pour les tableaux, certaines opérations qui restent coûteuses donc à modérer si on peut éviter de faire plusieurs fois les mêmes opérations : / et surtout **
Le DISPLAY va générer des PACK puis UNPACK, le binaire n'est plus une recette systématique, le COMP-3 devient un bon compromis sur MAINFRAME IBM.
Un intérêt certain quant au choix des options de compilation et surtout une bonne structuration qui évitera bien des répétitions inutiles (autre débat !)

[Homer-ac]

Pour ceux qui veulent approfondir et vérifier de plus près les instructions Assembleur 370 IBM générées via l'option LIST, j'ai trouvé un lien qui donne le format de chaque instruction. Bon ça ne donne qu'une idée, un cours Assembleur de base se donne sur 15j minimum, mais c'est déjà une base intéressante après avoir posé que le premier caractère représente toujours le code opération hexa, que la suite dépend du type d'instruction et que le gros des instructions de mouvements/opérations peut se classer en instructions registres à registres (RR, les + rapides, longueur instruction de 2), registres/mémoire (lg 4, avec intervention possible d'un registre index X) et mémoire à mémoire (lg 6, notation déplacement de 0 à 4095 (0-FFF) par rapport à un registre de base adressant un segment mémoire pour 4K donc). Dans ce cas, les opérations décimales ne peuvent se faire que sur du packé (intructions dont le premier caractère commence en général par F.) Le premier digit du second octet donne alors la longueur -1 de la zone récéptrice et le suivant la longueur -1 de la zone émétrice. Suivent les adresses déplacement/registre de la zone réceptrice sur 2 octets, puis de la zone émétrice.
Pour mieux comprendre, exemple de généré : F25F 3010 4FFF : Pack des 16 octets de la zone en étendu adressée par le registre 4, déplacement 4095, sur la zone packée sur 6 octets adressée par le registre 3, déplacement 16. Ce qui s'écrit en Assembleur : PACK 16(6,3),4095(16,4). On peut bien entendu citer des noms de données déclarées, l'Assemblage traduira ainsi.

http://www.simotime.com/asmins01.htm#InstructionList

Nb. Ces éléments peuvent aussi aider à retrouver un problème dans un Dump COBOL (bon, il y a qd même des produits pour ça mais ça peut parfois servir), étant précisé que dans le cas d'un S0C7, Un Move ne va pas planter. Le PACK ou UNPK se fiche de la validité de ce qui est packé ou dépacké, c'est le test qui suit qui va planter (opérations CP ou ZAP le plus souvent). Il suffit alors de regarder ce qui est en mémoire pour les registres/déplacements des zones impliquées par l'opération.
Re Nb. Se rappeler que le PSW donne alors l'instruction qui SUIT l'instruction en erreur (noter l'instruction puis faire -2,4 ou 6 en fonction de son format).