Discussion :

[walacouper]

Bonjour,

Pouvez vous me donner plus de renseignements ou une définition de la ligne code :

Code :

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

1
2
OBJECT-COMPUTER. IBM-370

sous MVS.

Merci par avance.
Cordialement

[a_karim_fr]

Bonjour,

L’ENVIRONMENT DIVISION
Cette division définit le type d’ordinateur pour lequel le programme sera écrit, ainsi que les périphériques nécessaires pour supporter les fichiers

OBJECT-COMPUTER
Ce paragraphe précise l’ordinateur sur lequel le programme sera compilé.

[Homer-ac]

Object-Computer, avec juste un un nom de machine ne sert à rien en COBOL MVS. de toutes façons le nom que l'on met ensuite n'est évidemment pas controlé alors puisque le matériel peut changer, autant s'en passer.
Par contre, tout comme Source-Computer permet d'activer le debugging mode, on peut associer à Object-Computer des clauses utiles (encore que je n'ai jamais eu à faire).
Surtout :

PROGRAM COLLATING SEQUENCE IS alphabet-name
The collating sequence used in this program is the collating sequence
associated with the specified alphabet-name.

[xfanx]

je peux juste te répéter ce que m'avais raconté mon prof de Cobol il y a quelques années.

A l'origine, les concepteurs des spécificités du cobol avaient imaginé un système portable et externe.
Donc avaient imaginé un compilateur pouvant avoir en input n'importe quel source cobol quelque soit ses spécificités de language lié à la machine, et ce même compilateur capable de sortir un fichier Objet en fonction de la machine vers laquelle le programme sera Linké et exécuté.

en d'autre terme : SOURCE COMPUTER indiquerait de quel système le source est issu et OBJECT COMPUTER indiquerait vers quel système en gros le programme sera exécuté sachant qu'à ce moment ci le language objet généré serait lié à la machine cible.

c'etait une bonne idée je trouve que de dire :
un programme cobol n'a qu'un seul source mais en jouant sur Object Computer on est capable de produire un exécutable multi plateforme en tout cas l'objet.
je ne crois pas que ça ait vu le jour au final, ce qui est parfaitement compréhensible aux vu des difficultés et de la complexité que ceci pourrait engendrer au niveau du compilateur.

[Hédhili Jaïdane]

Bonjour.

J'ai travaillé sur plusieurs compilateurs Cobol, je ne me rappelle pas avoir rencontré de cas où ces notions d'Object et de Source Computer avaient une importance, sauf sur quelques plateformes où elles sont vérifiées syntaxiquement et généraient des Warnings en cas d'erreur sur les valeurs indiquées et même pas sur leur validité par rapport à la plateforme.

Oui cette idée de portabilité des sources et des codes générés en fonction des plateformes cibles était une belle chimère : quel dommage

[Jean GVE]

Ton Prof avait raison, xfanx !
Ce genre de précision n'est plus utile aujourd'hui car peu de programme Cobol tourne dans un environnement autre que les grands systèmes.
Cela pouvait servir :

À créer des optimisations pour des fonctionnements dégradés sur des machines non équipées d'opérateur décimal (équivalent du coprocesseur mathématique, 286 avec copro 287 par ex.), cet opérateur permet d'effectuer des calculs sur des chaines de caractères numériques (PIC 9(n) avec ou sans signe et en COMP-3 ou non) et cela sans conversion intermédiaire en binaire ;
À pré-structurer le code généré pour la segmentation et les overlay ;
À coder les chaines de caractères en EBCDIC ou en ASCII en fonction de la machine cible... etc.

Aujourd'hui, la tendance et de récupérer le code Cobol et de le convertir en C ou autre pour le compiler sous Unix/Linux par exemple... Ce qui ne donne généralement pas des résultats très satisfaisants.
A+
Jean-M

PS: pour a_karim_fr
SOURCE-COMPUTER. est le bécane ou l'on compile et...
OBJECT-COMPUTER. la bécane cible où le programme va tourner !