Discussion :

[Au pays des stats]

Bonjour,

j'ai lu que l'on pouvait faire du SAS dans SEG. Peut-on faire les mêmes choses en faisant du SAS dans le logiciel SEG qu'en utilisant le logiciel SAS? S'il y a des différences, quelles sont-elles? Où puis-je trouver de l'information à ce sujet?

Je vous remercie par avance pour votre réponse.

Cordialement,

[MDsas]

Oui c'est possible à travers les programmes.
Cela fait à peine 2 semaines que je travaille avec EG et c'est pas si terrible que cela on s'adapte facilement. Franchement je m'attendais à pire.
Soit tu exploite EG avec les procedures préfabriquées soit tu les crée toi-même dans un programme (code) et là tu es comme dans sas base.
Concernant la documentation l'aide en ligne me semble bien fournit :
http://support.sas.com/documentation...uide/tut43/fr/

[s_a_m]

EG, n'est rien qu'une surcouche Java , toutes les procédures EG génére un programme SAS derrière et c'est le moteur SAS qui l'exécute.

99,99% des programmes SAS n'ont pas besoin de modifications quand il s'agit de les migrer de SAS vers EG. Après EG il travail en mode projet (tables, code, procédures préfabriquée,...).
quand t'exécutes un programme SAS sous EG il te crée un projet.

[datametric]

EG, n'est rien qu'une surcouche Java

.net

c'est de moins en moins vrai que EG soit une surcouche car nombre d'API Windows sont utilisés sans te le dire.
Jette un oeil sur le § IV-E. Utiliser SAS Enterprise Guide de mon document.

99,99% des programmes SAS n'ont pas besoin de modifications quand il s'agit de les migrer de SAS vers EG.

tout dépend du nouvel environnement.

j'ai lu que l'on pouvait faire du SAS dans SEG. Peut-on faire les mêmes choses en faisant du SAS dans le logiciel SEG qu'en utilisant le logiciel SAS? S'il y a des différences, quelles sont-elles? Où puis-je trouver de l'information à ce sujet?

Dès que la phase de relecture sera passée, je publierai un article sur ce sujet. j'espère que vous me remonterez vos remarques et les manques pour un développeur SAS qui passe sur EG.

[Manoutz]

Citation:
99,99% des programmes SAS n'ont pas besoin de modifications quand il s'agit de les migrer de SAS vers EG.

tout dépend du nouvel environnement.

y a-t-il un listing des cas ou la programmation sous EG necessite un ajustement? Ou en tout cas des situations ou le traitement doit etre different?

Datametric, dans l'attente de ton article (tu penses le publier qd en gros? )

Manoutz

[xav2229]

listing des cas ou la programmation sous EG nécessite un ajustement?

On peut déjà lister:

• Les appels DDE/VBA ne peuvent être faits.
• Les écrans AF ne peuvent être portés.

Si l'on change d'OS / Machine:

• Les chemins en dur (C:\)
• Les séparateurs de chemins (\ pour / ou le contraire)
• Les appels système (DOS pour UNIX)
• Vérifier la casse des fichiers (casse importante sous UNIX)

A noter que quand on passe sur un serveur, la politique de sécurité peut changer et interdire par exemple les appels systèmes.
X

[s_a_m]

Code :

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

1
2
3
4
5
6
 
 
Citation:
99,99% des programmes SAS n'ont pas besoin de modifications quand il s'agit de les migrer de SAS vers EG. 
 
tout dépend du nouvel environnement.

Je parlais des cas où on est sur le même environnement (si bien sûre Datametric parlait bien d’environnement Windows, Unix, MVS,…). Sinon quand il s’agit de changer d’environnement c’est claire ,il faut apporter des modifications sur les programmes.

Quelques exemples tirés de mes différentes expériences de migrations chez des clients :

-MVS à Windows , le Length des numériques sous MVS est de 2 Octet à 8octet , il est de 3 à 8 sous Windows et Unix donc à en tenir compte.

-Les chemins des Libnames qui changent bien sûre.

-Les DDE ne fonctionnent que sous Windows (c’est une technologie propre à Microsoft).

-La version EG4.1( je ne sais pas si c’est toujours la même techno pour la 4.2,4.3), utilise Microsoft JET quand à l’importation et l’exportation des fichiers vers les Excel, Access,… ( le Microsoft Jet n’intervient uniquement quand on passe par les menu import/export de la barre des tâches EG). Sinon avec du code c’est le moteur SAS qui intervient grâce au module SAS ACCESS TO PC FILE.

-Quant à la migration des données SAS d’un environnement à un autre c’est une autre histoire, il faut surtout changer l’ENCODING.
Je trouve la version 4.3 est formidable, cette version permet le reverse engineering, la validation du code avant exécution, un assistant de saisie du code un peu comme VB … sans oublier les nouveaux graphiques,…

Merci aux habitués de SEG de me corriger si je me suis trompé.

[olivier.decourt]

J'ajouterai que le passage par SEG "automatise" (en fait, cache) la relation client/serveur, donc probablement il n'y aura plus besoin de :

• SIGNON, SIGNOFF
• RSUBMIT, ENDRSUBMIT
• PROC UPLOAD, PROC DOWNLOAD
• %SYSLPUT, %SYSRPUT

Evidemment, ça ne veut pas dire que les relations inter-sessions SAS avec CONNECT sont interdites dans SEG. C'est juste que chez pas mal de boîtes, SEG+serveur SAS remplace SAS PC + serveur SAS.

J'ajoute aussi que l'absence de session SAS interactive interdit aussi le recours aux immondes fenêtres de dialogue (WINDOW/DISPLAY en étape DATA, %WINDOW/%DISPLAY en macro-langage) qui sont avantageusement remplacées par les fenêtres d'invites.

[datametric]

Datametric, dans l'attente de ton article (tu penses le publier qd en gros? )

ca ne dépend plus de moi... (je ne peux rien dire il surveille le site et je ne veux pas lui mettre la pression)

J'ajouterai que le passage par SEG "automatise" (en fait, cache) la relation client/serveur, donc probablement il n'y aura plus besoin de...

siii

Evidemment, ça ne veut pas dire que les relations inter-sessions SAS avec CONNECT sont interdites dans SEG. C'est juste que chez pas mal de boîtes, SEG+serveur SAS remplace SAS PC + serveur SAS.

voilà. Mais pas forcément quand même

-La version EG4.1( je ne sais pas si c’est toujours la même techno pour la 4.2,4.3), utilise Microsoft JET quand à l’importation et l’exportation des fichiers vers les Excel, Access,… ( le Microsoft Jet n’intervient uniquement quand on passe par les menu import/export de la barre des tâches EG). Sinon avec du code c’est le moteur SAS qui intervient grâce au module SAS ACCESS TO PC FILE.

EN 4.2+ les API sont encore utilisés et plus massivement car une API monte la table dans la WORK du serveur distant lorsque tu demandes à travailler sur une table ... en local.
Si le moteur SAS est une plate-forme 32 bits alors l'assistant d'import export peut te permettre d'utiliser les proc IMPORT et EXPORT.
C'est ce que tu as du voir dans mon doc précédemment mentionné.

-Quand à la migration des données SAS d’un environnement à un autre c’est une autre histoire, il faut surtout changer l’ENCODING.
Je trouve la version 4.3 est formidable, cette version permet le reverse engineering, la validation du code avant exécution, un assistant de saisie du code un peu comme VB … sans oublié les nouveaux graphiques,…

C'est pour moi aussi la première version que je recommande.

Merci aux habitués de SEG de me corriger si je me suis trompé

Nous sommes là pour échanger, apprendre et donc partager nos expériences. Plus nous échangerons, meilleurs nous serons.

[MDsas]

Nous sommes là pour échanger, apprendre et donc partager nos expériences. Plus nous échangerons, meilleurs nous serons.

En partant de ce principe c'est quoi une API?

ca ne dépend plus de moi... (je ne peux rien dire il surveille le site et je ne veux pas lui mettre la pression)

Que ce fameux document est attendu!!!! Juste histoire de mettre les pieds dans le plat!

[s_a_m]

En partant de ce principe c'est quoi une API?

Application Programming Interface. WIKI

[datametric]

Que ce fameux document est attendu!!!! Juste histoire de mettre les pieds dans le plat!

Oui enfin ce n'est pas un livre non plus. C'est orienté pour que des programmeurs arrivent sereinement sur EG, donc je n'ai pas tout traiter. C'est pour clarifier comment gérer les accès aux serveurs, aux données et gérer les programmes.