Discussion :

[bob_sapp]

salut,

je dois débuter sur le langage "pro t" qui est un générateur de cobol m'a-t-on dit
pour système Bull / OS "GCOS" (je sais pas si l'orthographe est exacte)

je n'ai rien trouvé sur le net à ce propos, est ce que quelqu'un connais ou pourrai me donner un lien pour en savoir plus ?

Merci.

[Luc Orient]

J'aurais écrit Protée moi ...
Mais vraiment ça me semble très très vieux ...

Et pour GCOS (l'orthographe est bonne) c'est GCOS7 ou GCOS8 ?

[bob_sapp]

exact c'est bien "Protée" c'est un générateur de cobol, je viens de prendre le poste et je ne pense pas l'utiliser très rapidement car je dois d'abord me former un minimum à ces vieilles technos, le manuel de référence de la dernière révision est daté de 1988 !

l'os c'est gcos 8, là aussi je connais pas, on m'a dis que les commandes n'ont rien à voir avec unix

argg ça va être dur d'ingurgiter tout ça mais ça m'intéresse quand même

si vous connaissez ou avez quelques liens...

[Luc Orient]

GCOS 8 c'est l'informatique des années 60-70 dans toute sa splendeur ...

Par contre, Protée je ne pensais pas que ça existait encore ...

[HRS]

60-70 c'était plutôt GCOS 3, GCOS 8 existe toujours chez Bull

nous on avait fait l'acquisition de Protee vers 1977 et je crois qu'on
ne l'utilise plus depuis 15 ans

A moins que vous ayez une version plus récente, les bordereaux de
saisie de l'époque étaient conçus pour resaisie sur cartes perforées

de plus l'outil est associée à la méthode de programmation CORIG,

où il vous faudra vous familiariser avec les booléens de cinématique

E-OCC-x-FIC
PM-n-FIC
DM-n-FIC

bon courage

[Luc Orient]

60-70 c'était plutôt GCOS 3, GCOS 8 existe toujours chez Bull
...

Si je me souviens bien, GCOS8 apparu au début des années 80 était plus une évolution "interne" (certes significative) de GCOS III, surtout au niveau du noyau pour la gestion de la mémoire et des processus.

L'aspect "externe" lui n'évoluait pas ou peu, je fais référence au temps partagé (TSS) et au batch (JCL).

[KJC2907]

À propos de Protée :

Bonjour,
J’ai 75 ans, en retraite depuis 2008. Je vous parle d’un temps que les moins de 50 ans ne peuvent pas connaître…
Ancien Responsable Système CGOS-3 puis GCOS-8, puis Responsable Exploitation, j’ai débuté programmeur aux Études en 1967-68 par l’Assembleur IBM 1401, puis le Cobol puis le langage Protée à partir de 1972.
Ensuite, davantage inspiré par les aspects techniques, j’ai bifurqué vers la filière Système / Sécurité / Backup sur GCOS-8 et matériel DPS8000.
À l’aube du changement de millénaire, je fus nommé responsable Projet An 2000, c’est-à-dire faire évoluer les logiciels et matériels vers l’aptitude à traiter tout particulièrement le nouveau format de date imposé par le passage à l’an 2000.

En effet, nos développements (programmes « maison ») réalisés depuis les années 1969 renseignaient dans leurs fichiers l’année sous forme de 2 caractères (ceux de la dizaine traduisant au fil des années une séquence croissante).
Puis brutalement, l’arrivée de l’an 2000 avec sa dizaine à « 00 » venait rompre cette séquence et casser la cinématique des programmes les plus anciens utilisant les fichiers séquentiels, ainsi que les tris et fusions.
Désormais, la rubrique « année » décrite dans les fichiers doit l’être sur 4 caractères, au lieu de 2 antérieurement à 2000.

Protée étant un générateur de Cobol, intégrant particulièrement un dictionnaire centralisateur descripteur des données communes à tous les programmes (cf Data Division) ainsi qu’un générateur de cinématique associé à ces données, il fut très simple de modifier le descripteur de date en l’étendant à 4 caractères. Donc à portée globale des quelques 2000 programmes / tris qu’il a tout simplement suffit de recompiler les yeux fermés.
Ceci préservant ainsi la cinématique pour les fichiers séquentiels, ainsi que le format des clés d’accès direct pour les fichiers randoms purs ou bases de données intégrées : formats IDS – IDS2, séquentiel indexés.

Puis ultérieurement, avons procédé de la sorte pour le portage d’applications maison sur serveurs Unix dans un contexte de « downsizing » / décentralisation.

La grande force du langage Protée est la totale indépendance de vos développements par rapport à matériel cible.
Ce générateur de Cobol étant lui-même écrit en Cobol, est entièrement personnalisable par son administrateur, assure ainsi la pérennité du capital investissement logiciel de l’entreprise.

C’est un langage procédural très structuré mis en œuvre par écriture sur des formulaires guides de rédaction très simples. Prérequis : maîtrise de la notion de cinématique, particulièrement pour les fichiers séquentiels.

Protée : commercialisé par une société parisienne dont j’ai oublié le nom, mais pas celui de son directeur : Monsieur De la Mazière ainsi que du responsable de son équipe de développement avec qui j’ai travaillé, notamment pour intégrer Protée en natif dans GCOS-8 (patches dans le Système et fichier Q* dans Total Système Tape & Start-up).
Il s’agissait de Monsieur Mathieu, Polytechnicien.

Épilogue : notre choix Protée fut le garant de notre indépendance par rapport aux chants des sirènes des Majors de cette époque : IBM, BULL, fournisseurs d’ERP …
D’autres sociétés avaient franchi le même pas que nous…
N’étant plus dans la boucle, j’ignore leur évolution.
En 2023, dans ce monde qui a changé, il reste encore dans mon ancienne société des applications (rescapées) très spécifiques écrites en Protée, ceci selon des collègues encore en activité.

[Nyrlodas]

Bonjour,

Je n'ai que 46 ans, j'ai encore mon duvet de jeune informaticien.

La seule fois où j'ai vu du Protée, c'est dans une banque du nord de la France.
Il ne restait rien du générateur de code, uniquement le résultat : du COBOL sur Mainframe IBM.
Franchement le résultat n'était pas très simple à manipuler (mais pas pire que de la génération PACBASE).
Il n'y avait aucune doc disponible.

[KJC2907]

Bonjour,

Votre expérience de MCO (M)aintenance en (C)onditions (O)pérationnelles de programmes issus du générateur Protée, sans le générateur, me semble on ne peut plus surprenant, voire incompréhensible, particulièrement s'il y avait de la cinématique mettant en oeuvre des variables de contrôle de l'avancement des fichiers traités générées par Protée aux noms abscons (PM-GEN-fic, DM-GEN-fic, etc ...).
Pour y parvenir, belle gymnastique cérébrale et bravo pour la réussite de cette maintenance.
L'Aspin et le Tourmalet du programmeur dans la même journée avec arrivée sur les Champs-Élysées !

Néanmoins, je me pose une question à propos de cette entreprise : il y avait-il un Directeur de l'Informatique ou en Responsable des Études (aujourd'hui dénommés DSI) compétents pour cautionner une telle (couteuse) galère !

Cordialement.
Signé : KJC2907.

[escartefigue]

J'ai connu 3 générateurs COBOL : Ariane, APS et Pacbase.

Leurs points communs :

• aucune garantie de pérennité, les deux premiers ont déjà disparu, le 3^e est en fin de vie et n'est plus maintenu ;
• une diffusion marginale, ayant pour conséquence des compétences difficiles à trouver sur le marché ;
• un code généré franchement dégueulasse (c'est moins vrai pour APS, le pire étant Ariane qui générait des ordres "ALTER TO PROCEDE" en plus des "GOTO" dans tous les sens) et non optimisé ;
• des utilisateurs prisonniers de ce langage confidentiel, j'ai connu nombre de programmeurs incapables de coder directement en COBOL proprement, ça signifie une employabilité très faible dans le monde du mainframe où règne le COBOL.

Et tout ça pour quoi ? Le COBOL, bien enseigné, est un langage simple et très performant sur mainframe.
J'ai connu des adeptes de Pacbase défendre la facilité avec laquelle on pouvait rapprocher des fichiers séquentiels grâce à ce générateur.
C'est exact, mais c'est également très simple en COBOL natif quand on l'a déjà fait.
Tous les développeurs que j'ai connus et qui défendaient tel ou tel générateur ne connaissaient pas ou alors très mal le COBOL natif.

Bref, il en va des générateurs COBOL comme des générateurs SQL, il mâchent le travail, mais produisent de la m####.
Protée que je ne connais pas fait peut être exception à la règle, mais j'en doute fort.
Plutôt que d'investir dans des générateurs, investissez dans vos collaborateurs, formez-les