"Ich könnte mir allerdings vorstellen, dass es noch sehr viele DM-Anwender gibt, die einfach aus Bequemlichkeit oder mangels Zeit den Umstieg noch nicht vollzogen haben. Für die bräuchte es m.E. ein paar Tips, um die letzten (niedrigen) Hürden wegzuräumen."

Es würde mich wirklich überraschen, wenn mich jemand davon überzeugen könnte, den EG bei der Auswertung von klinischen Studien statt dem DM + Makrosystem einzusetzen. Wenn ich funktionierende Makros habe, brauche ich keinen Codegenerator mehr. Oder sehe ich da was falsch ???

Hallo Herr Weist,

erstmal: mit dem "aus Bequemlichkeit oder mangels Zeit" sprach ich schwerpunktmäßig aus eigener Erfahrung; nicht dass als Kritik an (noch dazu unbekannten) SAS-Anwendern verstanden wird ;-)

Allerdings würde ich den EG nicht primär oder gar ausschließlich als Code-Generator bezeichnen. Für mich persönlich implementiert er zwei Aspekte, nicht mehr aber auch nicht weniger als state-of-the-art sind:

1. den Gedanken der verteilten Verarbeitung - transparent Plattform-und Rechner übergreifend. EG verwaltet eben entfernte Rechner und ich kann aus EG heraus auf den konfigurierten Rechnern meine Programme starten.

2. den Repository-Gedanken: Man kann mit dem EG neben der Installationsvariante mit lokalem SAS Foundation eben auch Repository-basiert arbeiten.

Wie gut oder noch verbesserungswürdig beide Konzepte implementiert sind sei dahingestellt; sie sind m.E. halt einfach zeitgemäß.

Und zum Code-generieren: Auch dieses Feature könnte man in die Reihe der zeitgemäßen Features einreihen - wenngleich Sie und ich das auf den ersten Blick vielleicht eher als Gimmik einordnen. Aber: Freuen wir uns doch einfach, dass EG in diesem Punkt den SAS-Einsteigern das Leben leichter macht.

Gruß´
S.Frenzel

Hallo Hr. Frenzel,

ich stimme Ihnen ja auch zu, daß ein Codegenerator ein gutes und zeitgemäßes Tool speziell für Einsteiger ist.
Allerdings fand ich die pauschale Aussage, daß es (für welche Branche eigentlich) kaum Gründe gibt, beim DM zu bleiben, aus meiner Sicht absolut nicht zutreffend.
Vielleicht sollte ich Ihnen die Situation in meiner Firma kurz schildern:
Wir machen mit SAS ausschließlich Auswertungen klinischer Studien. Hierzu gibt es ein Makrosystem, was wir im Laufe vieler Jahre erstellt und weiterentwickelt haben. Zum Start der Macros muß man jeweils für eine Studie nur wenige Parameter ändern oder die Funktionalität der Makros an der einen oder anderen Stelle erweitern.
Hierbei geht es in erster Linie um die Nutzung neuer SAS-Features wie z.B. ODS OO oder das Einbinden spezieller statistischer Tests (z.B. selbst programmiert mit SAS/IML). Die SAS-Erfahrung unserer Mitarbeiter ist so gut wie durchweg 10+ Jahre.
Ich denke, die Situation ist mit der in z.B. im Bereich Banken und Versicherungen überhaupt nicht vergleichbar. Für den einen ist EG vielleicht ein gutes Tool, für den anderen ist es so gut wie wertlos ...

Viele Grüße

G. Weist

Hallo Herr Frentzel,

Man kann mit EG beide Welten kombinieren EG Funktionalitäteten und Kodierung, auch wenn man 10 oder mehr Entwicklungsjahre mit SAS hat.

Ich würde es nicht nur u.a. auf Banken und Versicherungen beschrenken, EG ist ein qualitativer effizienter Sprung bei SAS, auch wenn man Anfangs etwas ins schwitzen gerät um die Anforderungen neu anpassen. So ist nun mal das Leben, jeder Anfang ist schwer, nach einer Weile läuft es wie am Schnürchen.

Ich bin SAS für EG sehr dankbar, besonders wenn man an die nur Mainframe und an die nur D.O.S Zeiten denkt. EG ist das Produkt!!

Viele Grüße,

Pablo Orosco Joerger

PS: Meine Kommentare sind eine Überlegung die sich mit den Konzepten von Herrn Weist beschäftigen

Noch einen schönen Abend,

Pablo Orosco Joerger

Der erste Satz hätte im Prinzip auch von uns (Schäfer Shop) kommen können, also volle Zustimmung (ausser dass wir Versandhandel sind ... aber Auswertung ist Auswertung, egal für welche Branche).
Zum zweiten Satz denke ich: JNEIN, denn die funktionierenden Makros ersetzen den Codegenerator nur bei Wiederholungsläufen von vorhandenen Auswertungen.
Der EG-Codegenerator könnte nützlich sein beim Erstellen neuer Auswertungen ....
Ich schreibe "könnte", denn wir haben mittlerweile viele Makro-Bausteine und verwenden diese um neue Auswertungen zu erstellen. Also würde uns der EG-Codegenerator auch nicht viel nützen.
Gruß Hans Kneilmann, Schäfer Shop GmbH, OIA-DWH

Man kann auch mit einem kleinen Programm auf Basis von Visual Basic selbst einen Dialog schreiben, der unter SEG läuft und der beim Schließen durch den Anwender einen Codegenerator startet, der dann SAS-Anweisungen generiert und ausführt.

Hallo zusammen,
zu "Und es gibt im Grunde keine (oder wenige? - kennt jemand welche?)
Gründe beim Display Manager (DM) zu bleiben" kann ich von uns (Schäfer Shop, abgekürzt: SSI) berichten:

1. Der EG ist sehr teuer wenn man Client/Server hat, denn man hat SAS-Connect und muss zusätzlich/alternativ SAS-IT bezahlen. Und zwar mit dem Erstjahrespreis! Obwohl für mich SAS-IT so eine Art Weiterentwicklung des SAS-Connect ist. Und der Erstjahrespreis kostet in unserer Masch-Klasse (ich glaube "E" für seine SUN V880) so richtig viel Geld!
2. Der EG frisst auf dem PC dermassen viel CPU bzw. RAM, dass mein PC erstmal aufgerüstet werden musste, um den Test-Zeitraum lebend zu überstehen. Und Aufrüstung kostet wieder Geld
3. Trotz Aufrüstung ist der EG so furchtbar lahm, dass das Starten schon sooo lange dauert, das ich schon gar keine Lust mehr hatte ihn zu benutzen.
4. Der EG kann seine egp-Projekt-Dateien auf dem Server nicht gegen Mehrfach-Zugriff schützen (wie es bei den normalen Data Sets selbstverständlich ist. Das ist bei arbeiten im Team (wie z.B. bei SSI) aber ein k.o.-Kriterium!!

Hallo,

ein Web-Server wie Apache reicht doch aus, um User-Eingaben aus einem Form zu verarbeiten. Mit Hilfe eines CGI-Skripts lässt sich SAS Code generieren. Hierbei haben wir ebenfalls eine Client/Server Infrastruktur. Kann mir jemand erklären, wo der grosse Vorteil liegt in der Nutzung weiterer SAS-Software wie EG im Vgl. zu einem Gespann wie Apache, PHP und HTML?

Schöne Grüsse
Dirk

Hallo,
zu dem Vorschlag mit dem Gespann aus Apache, PHP und HTML würden mich ein paar Details interessieren. Aber ich denke das führt hier in dieser Diskusion zu weit weg vom ursprünglichen Thema.
Könnten Sie sich bitte bei mir direkt melden? Danke! (Email-Adresse ist in meinen Kontaktdaten)
Gruß Hans Kneilmann, Schäfer Shop GmbH

Hallo Herr Kneilmann,

zu dem beliebten Thema des Pricings von SAS-Software will ich an dieser Stelle nicht mehr beitragen als die (sicher konsensfähige) Erkenntnis:

"Wahr ist: Die kostbaren Dienste, die uns SAS-Software leistet, kosten Bares!"

Allerdings meinte ich in meiner Frage nach den Gründen beim DM zu bleiben nur den EG als Tool und nicht als Produkt.

"Produkt = Tool * (Preis le Budget)" ;-)

Wg. der EGP-Dateien, die man nicht sperren kann: Diese Problematik wäre (ohne dass ich das getestet hätte) ggf. durch Repository-basiertes Arbeiten zu lösen.

Gruß
S. Frenzel

Hallo Herr Frenzel,
die Definition von "Produkt" und die Abgrenzung von "Tool": Toll !!!
Habe ich noch nie gehört/gelesen, werde ich ab sofort in meinen Zitate-/Gescheite-Sprüche-Vorrat aufnehmen :-))
Zum "Pricing" noch eine Anmerkung: Wir sind bereit für den EG zu zahlen. Diesen Preis finden wir OK, aber das SAS-IT voll zahlen zu müssen, wenn man SAS-Connect schon hat, das tut weh! Das ist das Problem. Wenn beim Wechsel von SAS-Connect zu SAS-IT schon im ersten Jahr nur der Folgejahrespreis anfallen würde, dann sähe es schon weniger schlimm aus .....
Als Tool finde ich den EG auch toll, zumindest das Konzept. Die konkrete Realisierung konnte ich nicht intensiv genug testen, da die Installation und das Customizing (wie SAP es nennen würde) sehr lern-/zeitaufwändig waren und darüber die 4-Wochen-Test-Lizenz abgelaufen war ... (man hat ja auch noch "richtige" Arbeit, ausser der netten Aufgabe "Test von neuen Tools").
Danke für Ihre Anregung ("Repository-basiertes Arbeiten"), leider ist die Test-Zeit (schon lange) vorbei.
Das Problem "EGP-Dateien sperren" im Sinne von "Exklusiver Zugriff" hatte ich sogar an die SAS-Hotline als Fehler bzw. Funktionsmangel gemeldet, es kam aber nur: Das ist halt so, also "works as designed".
Aber das Thema "EG" ist, wegen dem hohen Preis, bei uns z.Zt. gestorben, denn die Frage "wo ist der 'echte' Mehr-Wert" lies sich für den Buchhalter/Controller nur schwer beantworten.
Gruß
Hans Kneilmann