Discussion :

[karaz]

Bonjour,

voila mon problème, j'ai une chaîne de caractères W-NOCIN qui contient la valeur suivante "BH 24356 -4-" et je veux la convertir en "BH243564" en enlevant les caractères spéciaux ainsi que les espaces; dans un premier temps j'ai enlevé les caractères spéciaux avec l'instruction :

Code :

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

INSPECT W-NOCIN OF WKS CONVERTING  "(/-²°_%.*+¨?;)" TO "              ".

et donc j'obtiens "BH 24356 4 "

la question est comment remplacer un espace par un vide.

merci d'avance

[el_slapper]

Moi je ferais une mini-boucle avec 2 compteurs, en copiant caractère par caractères de la chaine source vers la chaine cible, et en incrémentant la position en chaine cible seulement si le caractère est valide. Après, les pros de la fonction ont sans doute mieux dans leur besace

Code :

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

1
2
3
4
5
6
7
8
9
10
MOVE ZERO TO P2
MOVE SPACES TO W-NOCIN-BIS
PERFORM VARYING P1 from 1 BY 1 UNTIL P1 > LENGTH OF W-NOCIN
   IF W-NOCIN ( P1 : 1 ) = .........liste de caractères valides
      ADD 1 TO P2
      MOVE W-NOCIN ( P1 : 1 ) TO W-NOCIN ( P2 : 1 )
   END-IF
END-PERFORM
MOVE W-NOCIN-BIS TO W-NOCIN

[JauB]

Tout d'abord bien venu sur le forum

Tu peux procéder comme suit:

Dans la déclaration des variables :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12

           11 W-NOCIN        PIC X(10).
           11 W-NOCIN2       PIC X(10).
           11 W-NOCIN3       PIC X(10).
           11 I              PIC 9(02).
           11 J              PIC 9(02).
           11 W-LONGUEUR     PIC 9(10).

       01 TABCIN.
        03 T-CIN OCCURS 10.
         05 L-CIN PIC X(01).

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
           MOVE LENGTH OF W-NOCIN TO W-LONGUEUR
           COMPUTE W-LONGUEUR = W-LONGUEUR - 1
           MOVE "BH 123 45"     TO W-NOCIN  OF WKS
           MOVE "BH 123 45"     TO W-NOCIN2 OF WKS

           INSPECT W-NOCIN CONVERTING "ABCDEFGHIJKLMNOPQRSTUVWXYZ" TO
                                       "**************************".
           INSPECT W-NOCIN CONVERTING "0123456789" TO "**********".

           MOVE W-NOCIN OF WKS TO TABCIN.

           MOVE 1         TO I OF WKS
           MOVE 1         TO J OF WKS
           PERFORM UNTIL I > W-LONGUEUR
                   IF L-CIN OF TABCIN(I)  = "*"
                      MOVE W-NOCIN2(I:1) TO W-NOCIN3(J:1)
                      COMPUTE J = J + 1
                   END-IF
                   COMPUTE I = I + 1
           END-PERFORM

Ta chaîne finale étant le W-NOCIN3.
Bon courage

[karaz]

je tien à vous remercier pour vos réponses et suggestions... .

je cherchais surtout des fonctions pour faire la conversion, mais apparemment il n'y en a pas. alors je me suis inspiré de vos solutions pour aboutir à au code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
           11 W-NOCIN            PIC  X(15).
           11 W-NOCIN-OUT     PIC  X(15).
           11 W-LENGTH          PIC  9(10).
           11 J                       PIC  9(02).
           11 K                       PIC  9(02).
       01 TABNOCIN.
        03 T-NOCIN OCCURS 15.
         05 L-NOCIN PIC X(01).

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
           INSPECT W-NOCIN OF WKS CONVERTING  "(/-²°_%.*+¨?;)"
                                                               TO "                    ".

           MOVE LENGTH OF W-NOCIN OF WKS TO W-LENGTH.
           COMPUTE W-LENGTH = W-LENGTH - 1.

           MOVE 1 TO J OF WKS.
           MOVE 1 TO K OF WKS.
           MOVE W-NOCIN OF WKS TO TABNOCIN.


           PERFORM UNTIL J > W-LENGTH
                   IF L-NOCIN OF TABNOCIN(J)  NOT = SPACE
                      MOVE W-NOCIN(J:1) TO W-NOCIN-OUT(K:1)
                      COMPUTE K = K + 1
                   END-IF
                   COMPUTE J = J + 1
           END-PERFORM

merci encore pour votre dynamisme

[JauB]

Merci à toi
C'était une bonne occasion pour refaire de l'algorithmique en COBOL

[el_slapper]

Y'a un truc que je ne comprends pas dans ta solution, c'est

Code :

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

1
2
           MOVE LENGTH OF W-NOCIN OF WKS TO W-LENGTH.
           COMPUTE W-LENGTH = W-LENGTH - 1.

D'abord, un simple

Code :

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

SUBTRACT 1 FROM LENGTH OF W-NOCIN OF WKS GIVING W-LENGTH

suffit largement(ADD ou SUBTRACT sont plus performants que COMPUTE, et si tu as beaucoup de chaines à gérer, ça peut compter).

Mais surtout, pourquoi -1? Parcque quand tu arrives au dernier caractère de ta chaine, J = LENGHT OF..... et donc J > W-LENGTH. Donc tu passes outre ton dernier caractère. Sur l'exemple plus haut, c'est pas grave, c'est un blanc. Mais si c'est une valeur significative(une lettre ou un chiffre dans ton cas), alors c'est perdu.

Sinon, j'aime pas les INSPECT, mais comme ça marche.....

[Luc Orient]

...
D'abord, un simple

Code :

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

SUBTRACT 1 FROM LENGTH OF W-NOCIN OF WKS GIVING W-LENGTH

suffit largement(ADD ou SUBTRACT sont plus performants que COMPUTE, et si tu as beaucoup de chaines à gérer, ça peut compter).

Oh la belle légende urbaine que voilà ...

Je me suis amusé à écrire ce petit fragment de code :

Code :

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

1
2
3
4
5
6
7
8
9
10
1  A PIC S9 PACKED-DECIMAL. 
PROCEDURE DIVISION. 

TRAITEMENT SECTION. 
DEBUT. 

    MOVE ZERO TO A 
    SUBTRACT 1 FROM A 
    COMPUTE A = A - 1 
    GOBACK

Et j'ai demandé à mon compilateur préféré ( IBM Enterprise COBOL for z/OS 3.4.1 ) sous z/OS 1.8 de me donner l'assembleur généré ( option LIST ).

Et bien c'est strictement la même chose :

000015 SUBTRACT
0002EA GN=15 EQU *
0002EA FB00 8000 A02C SP 0(1,8),44(1,10)
0002F0 F800 8000 8000 ZAP 0(1,8),0(1,8)
000016 COMPUTE
0002F6 GN=16 EQU *
0002F6 FB00 8000 A02C SP 0(1,8),44(1,10)
0002FC F800 8000 8000 ZAP 0(1,8),0(1,8)

En assembleur z/OS, SP c'est SUBTRACT PACKED et ZAP c'est ZERO AND ADD PACKED.
Le compilateur est suffisamment intelligent pour générer du code identique pour des instructions COBOL de même sémantique.

Mais surtout, pourquoi -1? Parcque quand tu arrives au dernier caractère de ta chaine, J = LENGHT OF..... et donc J > W-LENGTH. Donc tu passes outre ton dernier caractère. Sur l'exemple plus haut, c'est pas grave, c'est un blanc. Mais si c'est une valeur significative(une lettre ou un chiffre dans ton cas), alors c'est perdu ...

Effectivement, là par contre, je crois qu'il y a un vrai problème ...

[JauB]

Parce que le LENGHT me retourne la longueur de la chaîne en question +1. Dans l'exemple cité ça me retourne 10 alors que ça doit retourner 9! je trouve ça bizzard, je me suis contenté de soustaire 1

Mais surtout, pourquoi -1?

[el_slapper]

Euuuh, là je comprends pas. Tu parles de la longuer utile, ou de la longueur totale? Chez moi, LENGTH OF trouve la longueur définie de la chaîne. un PIC X(10) rempli sur 9 caractères renverra 10 quand même.....et le jour ou tu as 10 caractères utiles, ton truc ne marche plus - me semble-t-il. Parceque LENGTH OF te renverra toujours 10.

EDIT : pour les instructions de compil et la différence entre COMPUTE et SUBTRACT, je me réfèrais à une doc interne de "normes de programmation". Pas exacte, semble-t-il.....

[Hédhili Jaïdane]

Bonjour à tous.

Euuuh, là je comprends pas. Tu parles de la longuer utile, ou de la longueur totale? Chez moi, LENGTH OF trouve la longueur définie de la chaîne. un PIC X(10) rempli sur 9 caractères renverra 10 quand même.....et le jour ou tu as 10 caractères utiles, ton truc ne marche plus - me semble-t-il. Parceque LENGTH OF te renverra toujours 10.

+1

EDIT : pour les instructions de compil et la différence entre COMPUTE et SUBTRACT, je me réfèrais à une doc interne de "normes de programmation". Pas exacte, semble-t-il.....

C'est le temps de compilation qui est plus long dans le cas du COMPUTE et non pas le temps d'exécution, ni le code généré non plus.

[JauB]

Beh en fait moi je cherche longueur utile de la chaine. si sa taille dans la déclaration étant X(10) et qu'elle ne contient que 5 caractères alors je veux récupérer le 5 moi, je pense qu'il y a un poblème dans mon code ouais
Est ce que vous connaissez l'instruction qui récupère la longueur utile d'une chaine?

Euuuh, là je comprends pas. Tu parles de la longuer utile, ou de la longueur totale? Chez moi, LENGTH OF trouve la longueur définie de la chaîne. un PIC X(10) rempli sur 9 caractères renverra 10 quand même.....et le jour ou tu as 10 caractères utiles, ton truc ne marche plus - me semble-t-il. Parceque LENGTH OF te renverra toujours 10.

EDIT : pour les instructions de compil et la différence entre COMPUTE et SUBTRACT, je me réfèrais à une doc interne de "normes de programmation". Pas exacte, semble-t-il.....

[el_slapper]

non, mais en fait ça n'est pas grave. Si les derniers caractères sont inusités et que les inits à SPACES on bien été faits, ça ne plombe pas le fonctionnement de l'algo. La "Longueur Utile", ça ne veut rien dire. Les espaces en fin de chaine peuvent être significatifs - ou pas - ça dépend du fonctionnel. Pareil pour les low-value(qu'il faut quand même exterminer d'une manière ou d'une autre).

Par contre, je me vois corrigé sur les compute. Enfin, à force de générer 10 fois par jour les mêmes 25 programmes, ça va quand même finir par compter d'avoir éradiqué les COMPUTE ....en fait, je me suis fait suer pour des prunes . Merci pour l'info messieurs.

[Hédhili Jaïdane]

...
Par contre, je me vois corrigé sur les compute. Enfin, à force de générer 10 fois par jour les mêmes 25 programmes, ça va quand même finir par compter d'avoir éradiqué les COMPUTE ....en fait, je me suis fait suer pour des prunes . Merci pour l'info messieurs.

Fais gaffe, les normes de production, même si elles sont discutables, sont à respecter impérativement jusqu'à nouvel ordre (mises à jour ??).

[Homer-ac]

Sur le sujet du compute, El_Slapper, pas la peine de se taper la tête, il me semble qu'ici encore la lisibilité est la seule règle réellement utile. Si un Compute reste le le plus simple pour autre chose qu'un Add ou un Substract, ces dernières instructions basiques reprendont parfois l'avantage avec Enterprise Cobol z/OS qui avec l'option de compilation Optimize se permettra parfois de remplacer des opérations inutiles par de simples Move, Mais on est d'accord, ça peut dépendre du compilateur et de sa version. Avec un Enterprise Cobol 3.4 c'est vrai qu'il n'y a plus guerre de différence. On découvre d'aures choses, curieusement une opération sur une zone en binaire risquera d'ètre moins performante que sur une zone en Comp-3. Pas important vu les processeurs, alors que l'option Arith(extend) permet de faire des calculs sur 31 digits (chiffres packés uniquement), c'est quand mème mieux non ?
On commence à parler de COBOL 64 bits. Comme il ne sera plus alors question de compatibilité descendante, le binaire redeviendra sans doute le plus performant. Mais que sera la puissance des machines alors (demain). Mieux vaut se préoccuper du plus important : Le source est facile à lire ?

[JauB]

+1

Sur le sujet du compute, El_Slapper, pas la peine de se taper la tête, il me semble qu'ici encore la lisibilité est la seule règle réellement utile. Si un Compute reste le le plus simple pour autre chose qu'un Add ou un Substract, ces dernières instructions basiques reprendont parfois l'avantage avec Enterprise Cobol z/OS qui avec l'option de compilation Optimize se permettra parfois de remplacer des opérations inutiles par de simples Move, Mais on est d'accord, ça peut dépendre du compilateur et de sa version. Avec un Enterprise Cobol 3.4 c'est vrai qu'il n'y a plus guerre de différence. On découvre d'aures choses, curieusement une opération sur une zone en binaire risquera d'ètre moins performante que sur une zone en Comp-3. Pas important vu les processeurs, alors que l'option Arith(extend) permet de faire des calculs sur 31 digits (chiffres packés uniquement), c'est quand mème mieux non ?
On commence à parler de COBOL 64 bits. Comme il ne sera plus alors question de compatibilité descendante, le binaire redeviendra sans doute le plus performant. Mais que sera la puissance des machines alors (demain). Mieux vaut se préoccuper du plus important : Le source est facile à lire ?

[el_slapper]

Dans la plupart des cas, je serais d'accord avec le "le source est-il facile à lire".

Mais mon projet actuel est hyper lourd (générer 2 millions de pages de courrier en une nuit, et des courriers avec plein de choses dedans, des éléments référentiel en pagaille, des calculs comptables, statistiques, etc.....). Je ne peux pas me permettre de faire abstraction de ce genre de considérations - même si sur les projets précédents je ne me suis pas géné(3000 enregs par mois, il est hors de question d'optimiser la performance au dépens de la lisibilité).

Je retiens aussi la remarque sur le COMP-3, même si on est pas encore passés à du Cobol 3 ici - j'ai fait l'étude de faisabilité en mai, puis ça a été enterré.....

[Hédhili Jaïdane]

Bonjour à tous.

Je me suis amusé ce matin à faire une petite simulation avec un vieux cobol, sur une vieille machine et dans les mêmes conditions d'exécution en calculant 1000 fois le prix unitaire toutes taxes selon trois méthodes différentes. Le prix unitaire est calculé à partir d'un prix brut hors taxe soumis à une remise et deux autres taxes avec effets cumulatifs.
- Avec COMPUTE :

Prix TTC = 194,69 -- temps = 1302 ms

- Avec des calculs intermédiares grossièrement comme l'aurait fait le COMPUTE avec 2 décimales supplémentaires :

Prix TTC = 194,67 -- temps = 2080 ms

- Avec des calculs intermédiares sauvegradées et toujours avec 2 décimales supplémentaires :

Prix TTC = 194,66 -- temps = 2138 ms

A vous de juger.