Discussion :

[apokrif]

Bonjour,

Un des moyens de lire un VSAM KSDS en CICS, pour une clef secondaire qui a plusieurs occurrences dans le fichier, c'est de faire:
- premièrement, un positionnement sur le premier enregistrement correspondant à cette clef (STARTBR)
- ensuite, des lectures séquentielles pour lire chaque enregistrement correspondant à cette clef (READ NEXT).
Problème: on peut, en mode pseudo-conversationnel, quitter (temporairement) le programme mais vouloir reprendre, lors du prochain passage dans le programme, la lecture séquentielle là où elle s'était arrêtée: par exemple, le programme affiche 10 enregistrements à la fois (place limitée sur l'écran) et à chaque pression de éexPF8, il est réexécuté et affiche les enregistrements suivants.

Pour faire ça, on peut avoir un compteur (incrémenté par le programme à chaque READ NEXT, et transmis dans la COMMAREA) qui rappelle au programme à quel numéro d'enregistrement il s'était arrêté à l'exécution précédente: quand il est rappelé, il doit relire les N enregistrements (lus lors des exécutions précédentes) pour se repositionner avant de lire les enregistrements suivants.

Ce n'est pas optimal car (1) on doit gérer l'incrémentation et le passage d'un compteur et (2) on doit faire des lectures superflues. Le READ NEXT a-t-il pour effet de mettre à jour une sorte d'index qu'on pourrait récupérer, qui pointerait vers le dernier enregistrement lu, et qui éviterait de reprendre à chaque fois le browsing au début ?

[xfanx]

sauvegarde la derniere clé de fin de liste dans ta commarea à chaque fois.
ainsi il te suffit de faire un STARTBR sur celle ci a chaque entrée dan sta transaction

[Hédhili Jaïdane]

sauvegarde la derniere clé de fin de liste dans ta commarea à chaque fois.
ainsi il te suffit de faire un STARTBR sur celle ci a chaque entrée dan sta transaction

Bonjour à tous.

Ca ne marche pas s'il y a des synonymes sur lesquels on retombe et si on fait un START >, ça ne marche pas non plus à cause du restant des synonymes non affichés.

@apokrif, j'ai perdu de vue les mains et CICS, ma réponse risque d'être à côté de la plaque. Après un petit parcours de doc, il n'y a rien qui ressemble à ce que tu demandes : à savoir la sauvegarde du pointeur de lecture et le repositionnement sur le fichier avec ce pointeur à une prochaine ouverture.

On peut utiliser les fichiers DIRECT (DAM) et sauvegarder les N° relatifs des enregistrements (des rooms) ou alors éviter les synonymes et utiliser ce que préconise xfanx, mais ce n'est pas toujours le cas.

Pourquoi tu ne fais pas ta lecture du fichier dans le prog. principal et éventuellement quand ta condition d'arrêt est vérifiée (par exemple page à afficher pleine), tu fais les traitements qu'il faut par sous/prog. ou des procédures et tu reviens dans le main, comme ça tu ne perds pas ton pointeur de lecture, quitte à déclarer le même fichier deux fois en interne mais pointant sur le même fichier externe.

Perso, j'utilise cette méthode dépuis longtemps par programmation interne et on a aussi son équivalent sur AS/400 qui sont les sous fichiers écran.

[apokrif]

Pourquoi tu ne fais pas ta lecture du fichier dans le prog. principal et éventuellement quand ta condition d'arrêt est vérifiée (par exemple page à afficher pleine), tu fais les traitements qu'il faut par sous/prog. ou des procédures et tu reviens dans le main, comme ça tu ne perds pas ton pointeur de lecture, quitte à déclarer le même fichier deux fois en interne mais pointant sur le même fichier externe.

Merci pour l'idée mais la contrainte, c'est de programmer en pseudo-conversationnel: le programme exécute la lecture du fichier et le remplissage de l'écran, puis il redonne la main à CICS qui ne le rappelle que quand l'utilisateur le demande (par exemple en faisant PF8 pour avoir la suite de l'affichage). Ce serait plus facile à faire dans un seul programme qui s'exécuterait en une fois pour faire toutes les lectures et tous les affichages, mais alors on serait en mode conversationnel, ce qui n'est pas la même chose.

[Hédhili Jaïdane]

Merci pour l'idée mais la contrainte, c'est de programmer en pseudo-conversationnel: le programme exécute la lecture du fichier et le remplissage de l'écran, puis il redonne la main à CICS qui ne le rappelle que quand l'utilisateur le demande (par exemple en faisant PF8 pour avoir la suite de l'affichage). Ce serait plus facile à faire dans un seul programme qui s'exécuterait en une fois pour faire toutes les lectures et tous les affichages, mais alors on serait en mode conversationnel, ce qui n'est pas la même chose.

Entièrement d'accord avec toi là-dessus. Mais là on a contrainte technique (plutôt une limite). Alors que faire pour répondre à un besoin de gestion. Perso, j'ai inversé le problème et je n'ai pas tout dans le même programme : toutes les options ou les actions que l'utilisateur choisie sont exécutées par l'appel à des transactions (sens module/service/s-programme) et non dans le sens CICS. C'est vrai que je ne bosse plus là-dessus.

En tous cas, bonne continuation et A+.

[Pico-----]

Pas de tag résolu ... pas de réponses depuis 3 jours ...

Bon... je balance quand même mon truc :

La pagination sur cle générique c'est pas techniquement faisable directement à ma connaissance à cause des synonymes comme l'a dit Hédhili Jaïdane.
La solution que j'ai vu me semblant la plus ... "mieux" ... enfin celle que je conseille est la suivante :
Lire entierement le fichier lors du premier passage du programme et le chargé dans une TS, et ensuite paginer sur la TS en conservant les indices de ligne en dfhcommarea (une TS gérant les accès direct par numéro de ligne) sans jamais réaccèder au fichier. Le seul HIC : penser à détruire la TS quand on a finit.

[fremen167]

Bonjour,

J'ai eu à développer ce genre d'accès. Effectivement, il n'y a pas de "bonne" solution.

Ca va dépendre de plusieurs choses :

• Si tu as relativement peu de pages à afficher au total, la solution d'une TS chargée une fois pour toutes est bonne ; dans le cas contraire, ça peut être très pénalisant, et on peut vouloir n'accéder qu'aux enregistrements effectivement affichés.
• D'autre part, il faut savoir si tu as souvent un nombre très important de doublons sur ta clé secondaire. C'est souvent limité, donc l'inconvénient de devoir relire 1 ou deux enregistrements déjà lus n'est pas forcément très problématique. Le plus simple dans ce cas est de stocker la clé primaire du dernier enregistrement lu.

On peut faire un mixe des deux solutions en créant un item de TS par page affichée. De cette manière, quand tu pagines sur des pages déjà affichées précédemment, tu fais juste un accès TS, et dans le cas contraire, tu attaques le fichier et tu ajoute un item à la TS.

Le grand avantage de cette solution est d'éviter les READ PREV car sur index secondaire, c'est galère. En effet, pour la même clé secondaire, la série de READ PREV retourne les enregistrements dans le même sens que la série des READ NEXT.