Discussion :

[laurent747474]

Bonjour,
Pouvez vous me dire si cela est compliqué à apprendre si je n'ai fait que du cobol /db2.
Je doute de pouvoir reussir....
De plus, je suis à la recherche d'un echantillon de programme.
Qui aurait des cours sur ideal et datacom ou tout autre document?
merci à tous

[vttman]

Hello Laurent747474,
Il faut partir vainqueur, courage !

Voici ce que j'ai trouvé, à voir si ça correspond bien ?
En tapant "ideal datacom + exemples" sous Goo*Gle, j'obtiens un pdf de 336 pages (CA Ideal for CA Datacom Programming Guide - CA Support)

Laurent

[laurent747474]

Bonjour Vttman,

Merci pour votre reponse maisje cherche encore d'autre cours sur ce sujet...
Qui a déjà programmé avec ideal datacom??? est ce compliquer??? Je connais tres bien le cobol....

[CobolProgrammator]

Bonjour, c'est pour aller travailler où ? ideal datacom a été inventé après cobol, est de niveau "plus élevé", c'est à dire du cobol en plus simple et encore davantage orienté productivité. Il est associé à datacom qui est une base relationnelle très rapide; les requêtes s'écrivent directement dans les programmes, et il n'y a pas besoin d'ouvrir des curseurs, faire des fetchs. A puissance machine égale, datacom est 2 à 3 fois plus rapide que db2. Datacom peut fonctionner avec sql mais certains clients préfèrent rester avec le langage de base. La syntaxe des requêtes n'étant pas du sql, les jointures sont peu utilisées, mais on peut très facilement les remplacer par des requêtes imbriquées, donc ce n'est pas pénalisant. Datacom travaille différemment de db2, et est plus performant. Là où db2 remplit un curseur et attend la fin pour restituer les données, datacom se positionne dans la base de données et itère successivement jusqu' à ce qu'on lui dise d'arrêter; bref ça va plus vite.
En résumé ideal datacom c'est encore plus simple, rapide et orienté productivité que cobol et db2.
Exemple de pgm ideal:

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
<<main>>
list "hello world"
i = 0
<<label>>
for each ma_vue where ma_vue.colonne1 > "toto"
	add 1 to i
	if ma_vue.colonne2 = "titi"
		list "salut " i
	endif
	if i> 4     
		quit label
	endif
endfor

endproc

[Luc Orient]

Pour moi sur un marché Mainframe lui même sur la défensive, c'est le genre d'outils dont l'avenir est plutôt derrière lui ...

[escartefigue]

Bonjour, c'est pour aller travailler où ? ideal datacom a été inventé après cobol, est de niveau "plus élevé", c'est à dire du cobol en plus simple et encore davantage orienté productivité. Il est associé à datacom qui est une base relationnelle très rapide; les requêtes s'écrivent directement dans les programmes, et il n'y a pas besoin d'ouvrir des curseurs, faire des fetchs. A puissance machine égale, datacom est 2 à 3 fois plus rapide que db2.

Je suis très surpris par cette affirmation, mais peut être comparez vous avec un DB2 autre que la vesrions Z/OS ? ou à des cas d'usage très particuliers ? à préciser

Datacom peut fonctionner avec sql mais certains clients préfèrent rester avec le langage de base. La syntaxe des requêtes n'étant pas du sql, les jointures sont peu utilisées, mais on peut très facilement les remplacer par des requêtes imbriquées, donc ce n'est pas pénalisant. Datacom travaille différemment de db2, et est plus performant. Là où db2 remplit un curseur et attend la fin pour restituer les données, datacom se positionne dans la base de données et itère successivement jusqu' à ce qu'on lui dise d'arrêter; bref ça va plus vite.

Sauf que Datacom n'est pas un vrai SGBD relationnel, il ne respecte pas les 12 règles de CODD
cf. ce sujet (il date un peu, mais reste d'actualité) https://sgbd.developpez.com/actu/873...el-de-donnees/

Pour ce qui concerne les curseurs, ce n'est qu'une option de traitement à ne retenir que s'il est nécessaire de traiter ligne à ligne.
Dans tous les cas, il est préférable d'avoir une démarche ensembliste avec un SGBD relationnel (DB2 ou autre), c'est à dire éviter l'utilisation des curseurs quand ce n'est pas strictement nécessaire

[CobolProgrammator]

Je suis très surpris par cette affirmation, mais peut être comparez vous avec un DB2 autre que la vesrions Z/OS ? ou à des cas d'usage très particuliers ? à préciser

Non, j'ai pu comparer ayant travaillé sur 2 sites Z/OS ayant Datacom et DB2. Pour ce qui concerne les traitements batchs et même le online, ce qu'on peut faire avec Datacom est souvent beaucoup plus compliqué avec Db2; en général pour passer à Db2 il faut tout revoir. Et dans le meilleur des cas Db2 sera aussi rapide à l'exécution, en général avec des fonctionnalités en moins. Le seul avantage de Db2, c'est qu'il est fort pour faire des requêtes sophistiquées, la je reconnais. Mais Datacom n'est pas fait pour ça (il faut laisser ça à un datawarehouse).

Sauf que Datacom n'est pas un vrai SGBD relationnel, il ne respecte pas les 12 règles de CODD
cf. ce sujet (il date un peu, mais reste d'actualité) https://sgbd.developpez.com/actu/873...el-de-donnees/

Je reconnais que je ne suis pas un "puriste", peut être qu'il répond pas à 100% des critères (que je ne comprends pas tous d'ailleurs). Il faut signaler à Wikipedia qu'ils se trompent aussi, ils le classent relationnel.

Pour ce qui concerne les curseurs, ce n'est qu'une option de traitement à ne retenir que s'il est nécessaire de traiter ligne à ligne.
Dans tous les cas, il est préférable d'avoir une démarche ensembliste avec un SGBD relationnel (DB2 ou autre), c'est à dire éviter l'utilisation des curseurs quand ce n'est pas strictement nécessaire

Oui ben évidemment on est d'accord; mais en informatique de gestion, on est vite limité si on veut faire sans curseur, il faut passer par des unloads, bosser sur des fichiers, recharger, c'est lourd. Datacom permet d'éviter tout ça sans problème, ça le gène pas de parcourir ses vues et de mettre à jour en direct (que les colonnes souhaitées) en quelques lignes de code. Ideal datacom est un outil orienté productivité de développement et exécution, c'est ce que je veux dire.
En conclusion je veux dire que db2 c'est pas la panacée comme on veut nous le faire croire; c'est un très bon outil, mais sur certains points il y en a de meilleurs.Il faut essayer pour se faire une idée. Les avantages que je reconnais à Db2, c'est qu'il est plus ouvert, permet de faire des requêtes plus évoluées (et encore Datacom a un module permettant de faire du SQL), mais c'est bien mince.
ps - Datacom, c'est Computer Associates, des américains, et en général ils n'ont pas la réputation d'être des arriérés question business ou industrie (-:

[CobolProgrammator]

Pour moi sur un marché Mainframe lui même sur la défensive, c'est le genre d'outils dont l'avenir est plutôt derrière lui ...

oui on peut pas le nier, mais bon, quand il est remplacé par du cobol unix, les codeurs peuvent continuer à travailler sans trop de problème; et puis c'est une question de gôut aussi, moi j'ai travaillé sur les 2 et j'ai eu plus de plaisir sur mainframe. Mainframe gardera peut être un avantage sur les sites qui gèrent de très gros volumes de traitements, ou qui veulent la simplicité ?

[escartefigue]

Non, j'ai pu comparer ayant travaillé sur 2 sites Z/OS ayant Datacom et DB2. Pour ce qui concerne les traitements batchs et même le online, ce qu'on peut faire avec Datacom est souvent beaucoup plus compliqué avec Db2;

Ce qui n'est pas ou mal maitrisé parait toujours compliqué, c'est tout à fait normal en phase d'apprentissage, mais dans les faits ça ne l'est pas

en général pour passer à Db2 il faut tout revoir.

C'est une évidence : passer d'un SGBD non relationnel à un SGBD relationnel est une remise en question complète de l'ensemble des traitements, c'est une refonte complète du SI
Ce serait pareil si vous deviez passer à un autre SGBD-R. Par contre passer d'un SGBD-R à un autre est beaucoup plus simple, car ils partagent les mêmes fondamentaux et le même langage SQL (à quelques variantes près mais l'essentiel est commun)

Et dans le meilleur des cas Db2 sera aussi rapide à l'exécution, en général avec des fonctionnalités en moins.

Donnez des exemples de ce que vous ne savez pas faire avec DB2, je serai très surpris de ne pas trouver une solution DB2 simple et rapide

Je reconnais que je ne suis pas un "puriste", peut être qu'il répond pas à 100% des critères (que je ne comprends pas tous d'ailleurs).

C'est parceque vous n'avez pas compris l'intérêt des règles de Codd que vous voyez des avantages à Datacom, les règles de Codd sont fondamentales, elles présentent des avantages énormes par rapport aux SGBD non relationnels !

En conclusion je veux dire que db2 c'est pas la panacée comme on veut nous le faire croire; c'est un très bon outil, mais sur certains points il y en a de meilleurs.

Aucun SGBD n'est la panacée, tous ont leurs défauts, mais d'une part DB2 (en tout cas la version Z/OS) est l'un des plus robustes et d'autre part, n'importe quel SGBD-R sera toujours nettement préférable à un SGBD qui ne respecte pas les règles de CODD
La gestion de l'intégrité référentielle, des concurrences d'accès, de la taille et du type de verrous, du partitionnement, l'indépendance logique/physique, l'utilisation du langage SQL universel etc, sont tellement d'avantages par rapport à un SGBD non relationnel, que toute autre considération n'a que peu de poids

ps - Datacom, c'est Computer Associates, des américains, et en général ils n'ont pas la réputation d'être des arriérés question business ou industrie (-:

Ah bon, et DB2 ça vient d'où d'après vous ?

[CobolProgrammator]

Ah bon, et DB2 ça vient d'où d'après vous ?

Oui là mon argument n'a pas de poids c'est vrai
Je précise que je parle ici de l'avantage niveau purement performance / efficacité d'ideal datacom.
Une (assez grosse) banque en Suisse est en train (depuis quelques années) de migrer de Z/Os Datacom à Db2 Unix Aix, au début pour faire des économies et s'ouvrir de nouveaux horizons, accélérer les temps de traitements pour pas cher, quitter un SGBD qui allait disparaître (la date n'est toujours pas fixée ), s'affranchir de la difficulté de trouver des développeurs etc ... Le blabla habituel qui fait vendre, c'est vieux comme le monde.
Au début du projet, les gens ne connaissant que l'un ou l'autre des 2 SGBD disaient exactement comme vous et on allait voir ce qu'on allait voir. Les gens qui connaissaient vraiment passaient pour des cons. En 2019/20 en langage diplomatique disons que les premiers sont dans une phase d'étonnement (mais préfèrent que la boite aille dans le mur plutôt que de reconnaitre leur erreur). Je reconnais que faire du DB2 Host aurait "limité" les dégâts, mais les problèmes de lenteur (batch et online) et de mise en place de l'architecture sont tels que les coûts de ce projet ne seront jamais amortis. Les promesses de migrer sur un SGBD plus rapides sont complètement passées aux oubliettes, les nouveaux objectifs étant de s'approcher peut être un jour de la performance de datacom (évidemment on y arrivera en décrétant "inutiles" les fonctionnalités où datacom est supérieur).
Le seul vrai gain db2 est d'avoir un système plus ouvert (avec aussi ses nouveaux problèmes bien sûr), mais à quel prix !
Une bonne refonte de l'architecture existante menée par des gens compétents aurait fait gagner quelques dizaines de millions d'euros aux actionnaires et employés, et permis de réellement améliorer la qualité du service.

Wikipedia insiste bien sur le côté performance de Datacom (rien de tel pour db2 qui a certes d'autres qualités). C'est vieux certes, mais db2 existait déjà (début des années 80) et depuis rien de nouveau sous le soleil

This relational version of Datacom served as the foundation for a continuing stream of industry-leading enhancements that have preserved its position as an extremely cost-effective and high-performing DBMS for the IBM mainframe.
Insyte Datacom became well known throughout the marketplace for the outstanding speed and efficiency of its Datacom/DB and Datacom/DC applications.
Datacom/DB and IDEAL remain major CA products today and are the data processing backbones of many Fortune 500 companies as well as many U.S. federal agencies.

Ce que j'ai appris récemment c'est que Computer Associates (qui détenait datacom) dans les années 90, incitait ses clients à migrer vers DB2 (gratos), ce qui

• lui faisait vendre de nouveaux services
• avantageait IBM car DB2 ayant besoin de beaucoup plus de CPU, ça faisait plus de revenus dans le tiroir caisse. Trop forts ces américains ! ).

[escartefigue]

Tout ceci est trop général pour avoir valeur d'exemple.
Tout SGBD relationnel ou pas, quand il est utilisé en dépit du bon sens, peine à la charge.

J'ai souvenir chez certains clients de traitements batchs qui n'arrivaient pas à se terminer en une nuit (c'est à dire dans la plage 20h00 7h00) simplement parce qu’ils étaient mal conçus (traitement non ensemblistes, prédicats non sargables, pléthores d'index, verrouillage inaqéquat...). Ces mêmes traitement ne durent que quelques secondes au maximum après optimisation.

Le malheur est que de nombreux sites ont migré vers des SGBD-R sans former les équipes de dev, ni parfois même les DBA (serieux !) et ont du coup mis en place des modèles de données catastrophiques et des traitements du même tonneau faute de connaître les fondamentaux.

Le seul argument de DATACOM, c'était justement de permettre à des béotiens d'avoir l'impression d'utiliser un SGBD-R sans besoin d'en avoir la culture.

Argument de peu de poids