Bonjour,
Je ne comprends pas pourquoi tes variables 'CUR-TYPE-ACCT' et suivantes sont en niveau 88. Il ne s'agit pas de booleens. Du coup, pour le SEARCH je ne sais pas quelles en sont les conséquences.
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
Bonjour,
Je ne comprends pas pourquoi tes variables 'CUR-TYPE-ACCT' et suivantes sont en niveau 88. Il ne s'agit pas de booleens. Du coup, pour le SEARCH je ne sais pas quelles en sont les conséquences.
Exact...
En passant les variables à :
Ca me vire pleins d'erreurs...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
801 TABLE-RATE. 07 TABLE-RATE-RECORD OCCURS 9 TIMES ASCENDING KEY CUR-TYPE-ACCT INDEXED BY MY-INDEX. 10 CUR-TYPE-ACCT PIC X(4). 10 CUR-RATE PIC 999V99. 10 CUR-MAX-SAVING PIC 9(5). 10 CUR-DESCRIPTION PIC X(32).
J'étais convaincu que les 88 étaient des "valeurs"... sans être spécialement booléennes.
Il ne me reste que celle du WRITE qui devient plus simple du coup.
EDIT : je me doutais que c'était soit le RECORD, soit le nom du FD pour la partie WRITE... mais j'utilise les erreurs à la compilation pour m'en rendre compte.
Mes difficultés étaient fortement liées au compilateur même, et à l'utilisation du SEARCH.
Le WRITE doit porter sur le nom du format du fichier (son niveau 01) et non sur le nom du fichier :Envoyé par Metalman
PS : Je met permets d'insister sur l'utilisation de la documentation
Code : Sélectionner tout - Visualiser dans une fenêtre à part WRITE ACCT-DATA-OUT-RECORD ....
Encore une légende urbaine qui traîne chez les "vieux" programmeurs COBOL ...
Le SEARCH "simple" correspond à une recherche séquentielle dans une table (au sens COBOL et pas au sens SGBDR) et le SEARCH ALL correspond à une recherche dichotomique dans une table triée (forcément ...).
L'instruction est puissante et nécessite quelques précautions pour être utilisée correctement, mais une fois bien codée, elle donne un code machine très efficace généré par les compilateurs COBOL modernes.
Bonjour mon cher Luc Orient.
Nous devons être des ruraux ou des montagnards alorsparce qu'on utilisait bien le SEARCH binaire avec les bonnes perfs qu'il donnait. On l'utilisait aussi souvent que la taille maximale des tables dans le programme nous le permettait et à chaque fois que cela s'avérait nécessaire de charger une table en mémoire quitte à lui donner un petit coup de tri par la méthode des permutations quand la table est très sollicitée dans le programme. J'ai connu le SEARCH ALL dans tous les compilateurs qu'il m'a été donné d'utiliser.
Je suis tout à fait d'accord, le SEARCH est bien pratique, et plus "élégant" qu'une boucle en perform varying.
Bonjour,
Je me permets de faire revivre cette discussion car j'ai une question sur le même sujet.
J'ai un tableau indexé défini en working.
En gros voici la tête de mon tableau (dans le sous-programme appelé) :
Je vais y ajouter un ASCENDING KEY GIN-TBINS-TYINS GIN-TBINS-NOINS.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
1401 ... * DONNEES EN ENTREE DU SERVICE 05 GEN-GRDONENT. [...] *-- TABLEAU DES INSTITUTIONS 10 GIN-TBINS. 15 FILLER PIC 9(04). 15 GIN-NBINS PIC S9(4) COMP. 15 GIN-GRTABINS OCCURS 100 INDEXED BY GIN-IXINS. 20 GIN-TBINS-TYINS PIC X(001). 20 GIN-TBINS-NOINS PIC X(004). 20 GIN-TBINS-TYINSGRO PIC X(001). 20 GIN-TBINS-NOINSGRO PIC X(004).
Ci-dessous le chargement (qui se fait dans un programme appelant, ne vous étonnez donc pas que les préfixes des noms des champs du tableau ne soient pas les mêmes) :
Dans le sous-programme, je veux chercher des postes de ce tableau avec la commande SEARCH ALL sur les 2 arguments alphanumériques :
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*-- BOUCLE SUR LES LIENS INSTITUTION/GROUPE PERFORM VARYING WOR-IX001 FROM 1 BY 1 UNTIL CC1RAL07-NON-TROUVE OR CC1RAL07-FIN-CURSEUR OR WOR-IX001 > WOR-NBINSMAX *-- ALIMENTATION TABLEAU DES INSTITUTIONS MOVE GOU-ING-TYINS OF GEN-GRCC1RAL07 TO TBINS-TYINS(WOR-IX001) MOVE GOU-ING-NOINS OF GEN-GRCC1RAL07 TO TBINS-NOINS(WOR-IX001) MOVE GOU-ING-TYINSGRO OF GEN-GRCC1RAL07 TO TBINS-TYINSGRO(WOR-IX001) MOVE GOU-ING-NOINSGRO OF GEN-GRCC1RAL07 TO TBINS-NOINSGRO(WOR-IX001) *-- LECTURE SUIVANTE PERFORM 80000-APPELER-PC1RAL07 END-PERFORM
Mais pour faire cela, j'ai lu qu'il fallait que le tableau soit préalablement trié.
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
25SEARCH ALL GIN-GRTABINS AT END *-- SI NON-TROUVEE : PAIEMENT DE NIVEAU GROUPE MOVE GIN-TYINS OF GEN-GRCC17SV05 TO WOR-GPE-TYINS MOVE GIN-NOINS OF GEN-GRCC17SV05 TO WOR-GPE-NOINS WHEN GIN-IXINS > GIN-NBINS *-- SI NON-TROUVEE : PAIEMENT DE NIVEAU GROUPE MOVE GIN-TYINS OF GEN-GRCC17SV05 TO WOR-GPE-TYINS MOVE GIN-NOINS OF GEN-GRCC17SV05 TO WOR-GPE-NOINS WHEN GIN-TBINS-TYINS = GIN-TYINS OF GEN-GRCC17SV05 AND GIN-TBINS-NOINS = GIN-NOINS OF GEN-GRCC17SV05 MOVE GIN-TYINS OF GEN-GRCC17SV05 TO WOR-INS-TYINS MOVE GIN-NOINS OF GEN-GRCC17SV05 TO WOR-INS-NOINS MOVE GIN-TBINS-TYINSGRO TO WOR-GPE-TYINS MOVE GIN-TBINS-NOINSGRO TO WOR-GPE-NOINS END-SEARCH
Sauf qu'au chargement, le tableau n'est clairement pas trié, à moins de faire en sorte que la requête utilisée pour chargée le tableau soit triée sur les 2 arguments en question.
Bon en écrivant je viens de trouver une solution pour l'un de mes tableaux a priori.
Mais j'ai 4 tableaux du même genre à charger, et je ne pense pas pouvoir changer les autres requêtes.
Le fait de mettre ASCENDING KEY ne va pas non plus automatiquement trier le tableau après le chargement je suppose, si ? Je ne vois pas trop comment.
Donc ce que j'aimerais savoir c'est comment fait-on pour trier un tableau déclaré trié ?
Parce que si je dois le trier avec des PERFORM VARYING (ça je sais faire), je ne vois pas du tout l'intérêt de la clause ASCENDING KEY ??
Et par la même occasion, j'en profite pour rectifier ceci :Le SEARCH "simple" correspond à une recherche séquentielle dans une table (au sens COBOL et pas au sens SGBDR) et le SEARCH ALL correspond à une recherche dichotomique dans une table triée (forcément ...).En vérité, que ce soit le SEARCH ou le SEARCH ALL, il s'agit dans les 2 cas d'une recherche dichotomique.Dans un cas il faut alimenter l'index principal avec un SET avant d'effectuer le SEARCH pour dire à partir de quel poste la recherche séquentielledichotomiquedoit être effectuée, alors qu'avec un SEARCH ALL on fait la recherche dichotomique sur la table entière et donc inutile d'initialiser l'index principal au préalable. Bon je n'ai encore jamais utilisé ni l'un ni l'autre à l'exécution, mais c'est ce que j'ai lu dans une documentation qui m'a eu l'air très sérieuse.
EDIT : le SEARCH effectue bien une recherche séquentielle, et le SEARCH ALL effectue une recherche dichotomique.
Non, en effet, c'est à vous de trier les données ASCENDING KEY ne permet que de définir la clef utilisée, pas d'organiser les données
Le tableau est généralement trié en amont.
Si toutefois vous faites un très grand nombre de recherches dans le tableau, investir dans un tri en début de traitement peut être rentable
A vous de voir si le coût engendré par le tri de vos données en vaut la peine.
Absolument pas, la doc de référence en la matière est la doc officielle du COBOL de votre plate forme.
Pour la version Z/OS (je doute que les autres divergent sur ce point), voici ce qu'on peut lire :
"RELATED TASKS
“Doing a serial search (SEARCH)”
“Doing a binary search (SEARCH ALL)” on page 89
Doing a serial search (SEARCH)
Use the SEARCH statement to do a serial (sequential) search beginning at the current
index setting. To modify the index setting, use the SET statement.
[. . .]
Doing a binary search (SEARCH ALL)
If you use SEARCH ALL to do a binary search, you do not need to set the index
before you begin. The index is always the one that is associated with the first
index-name in the OCCURS clause. The index varies during execution to maximize
the search efficiency.
La documentation complète ici : http://publibfp.boulder.ibm.com/epubs/pdf/igy6pg10.pdf
Merci escartefigue.
Je m'excuse, j'étais persuadée d'avoir bien lu, d'autant que je n'arrête pas de lire et relire cette doc depuis quelques jours.
La doc que j'utilise est ici
C'est bien écrit que le SEARCH fait une recherche séquentielle, vraiment désolée (si je peux, je vais essayer de ré-éditer mon post précédent).
Donc si c'est une recherche séquentielle, c'est pareil que si je fait un PERFORM VARYING en fait, je suppose que je n'ai pas besoin de trier préalablement le tableau pour pouvoir utiliser le SEARCH ?
C'est bien ça ?
Et en relisant, je comprends que le SEARCH ALL ne peut se faire que si une clause ASCENDING (ou DESCENDING) KEY a été déclarée sur le tableau.
Bonjour,
Attention, pour vous éviter les ennuis, assurez vous que la doc que vous publiez peut l'être sans autorisation préalable de l'organisme émetteur, dans le doute, supprimez le lien dans votre post précédent ;-)
Effectivement, en mode séquentiel, inutile de trier le tableau
Encore merci.
(Je n'y ai pas pensé pour le droit de diffusion. C'était une doc que j'ai trouvée sur internet en cherchant sur google, c'est dommage, elle est pas mal faite, et en français).
Comme ce n'est pas moi qui ai ouvert la discussion, je ne peux pas dire qu'elle est résolue, mais moi j'ai eu les réponses dont j'avais besoin, merci !
Répondre avec citation
Partager