Hallo Hans,   das würde ich ggf. mit dem SAS Support durchgehen. Aus der Erfahrung bei unseren Systemen kann ich sagen, dass hier durchaus die generelle Systemauslastung durch parallele Prozesse, SAN-Anbindung, etc. eine Rolle spielen können. Hier kann es immer mal zu einem Bottleneck kommen und die Zeiten schnellen dann teilweise stark nach oben.   Ein guter Indikator ist die Differenz von "real time" zu "cpu time", um zu sehen, ob die Verarbeitung an sich einfach viel Rechenzeit benötigt (Differenz ist klein) oder ob z.B. viel auf I/O gewartet wird => real time deutlich höher als cpu time. Mit der Option "fullstimer" lassen sich da auch noch weitere Faktoren betrachten.   Ich wünsche viel Erfolg und ich bin mal gespannt, was letztendlich das Ergebnis sein wird 🙂   Schönes Wochenende! Michael ... View more

Hallo Hans,   also das kann ich nicht nachvollziehen. Wenn ich mit PROC PRINT 3 Zeilen aus einer sehr großen Tabelle im EG anzeigen lasse, geht das sehr schnell und es wird nur eine sehr geringe Menge an Daten übertragen.   Mein Punkt ist, dass ich statt z.B. proc print   data=in (obs=3); run; ein data work.tmp; set in (obs=3); run; schreibe. Zugegeben, das mag nicht nötig sein, aber wie gesagt, ich arbeite meist mit den Daten weiter oder mache z.B. im EG ein "senden an Excel". Bei mir (und das sollte meines Wissens Standard im EG sein) werden die Ergebnisse auch sofort geöffnet. Also muss ich nicht zuerst den DataStep ausführen und dann das Ergebnis öffnen. Ich führe nur den DataStep aus und bekomme das Ergebnis angezeigt. (Oder alternativ kann ich die Ausgangstabelle auch direkt per Doppelklick öffnen und ansehen oder dort z.B. mit einem "Where" arbeiten, um die Tabelle zu filtern.   Dass das SELECT (ohne CREATE) im PROC SQL das komplette Ergebnis übertragen muss ist einfach der Funktionsweise "geschuldet". Man kann im EG einstellen, welche Ergebnisse erzeugt werden sollen. Im Standard wird ein SAS Report erzeugt. Das lässt sich z.B. auch auf PDF umstellen. Das PROC SQL; SELECT... erzeugt also das im EG eingestellte Ergebnis und überträgt dies anschließend auf das System, wo der EG läuft, damit es angezeigt werden kann. Das ist meines Erachtens ein ganz normales Vorgehen, wobei man freilich darüber diskutieren kann, wie groß das Ergebnis jeweils wird. Aus meiner Sicht wird das Ergebnis als SAS Report immer unverhältnismäßig groß im Vergleich zu den anderen Varianten. Dafür wird es eben direkt im EG angezeigt, wohingegen z.B. für PDF ein separates Tool benötigt wird.   Nochmal: ich denke, es ist einfach eine Frage der Vorgehensweise. Mir ist ein PROC PRINT viel zu unpraktisch, da ich im Ergebnis z.B. nicht mit den Pfeiltasten navigieren und auch keine Zellinhalte kopieren kann. Wahrscheinlich gibt es auch Verfechter des PROC PRINT, sicherlich auch zurecht, je nach Einsatzzweck. Mein Punkt ist, dass jedes Tool eine gewisse Vorgehensweise begünstigt, das habe ich versucht darzustellen.   Vielleicht kommt Euch das SAS Studio eher entgegen?   Beste Grüße Michael ... View more

Hallo Hans,   ich verstehe den Hintergrund. Es ist immer etwas schwierig neue Tools einzuführen, wenn gewohnte Abläufe dafür verändert werden müssen.   Da ich kaum mit dem Display Manager würde ich jetzt keinen Vergleich wagen. Allerdings würde ich es mal so ausdrücken, dass man beim Display Manager eine direkte SAS-Session hat, während der eGuide zwar natürlich auch mit einer SAS-Session arbeitet, jedoch das ganze noch etwas netter verpackt und verschiedene Hilfsmittel bietet. Das fängt ja schon damit an, dass das Log entsprechend gestaltet wird. Man bekommt eine Log-Zusammenfassung und kann aus dieser direkt in die entsprechende Stelle springen. Man kann Abläufe grafisch zusammenklicken, Projekte erstellen, ganze Projekte durchsuchen, Ergebnisse nach Excel senden etc. Grundsätzlich also ein deutlich mächtigeres Tool als der DM, dafür braucht der EG vielleicht an der einen oder anderen Stelle auch manchmal ein paar Sekunden länger.   Was die Ergebnisse angeht, so kann man in den Optionen auch einstellen, dass z.B. direkt ein HTML oder PDF erzeugt wird, wenn man dies denn benötigt. Auch die Warnung bei großen Ergebnissen kann man dort anpassen, aber ich denke, das hat schon auch seine Berechtigung, dass da ein Hinweis kommt. Die Warnung sagt ja nichts anderes, als "Achtung, hier werden jetzt ein paar hundert MB übertragen und müssen anschließend auch angezeigt werden". Im eGuide führe ich praktisch nie ein PROC PRINT aus, weil ich die Tabelle immer per Doppelklick öffnen kann. Oder das Ergebnis, z.B. eines Data-Steps wird direkt als Tabelle angezeigt. Diese Tabellenansicht war für mich schon immer praktischer und schneller als eine PROC PRINT Ausgabe zu betrachten, da man auch mit den Pfeiltasten navigieren kann. Bei der Ansicht der Tabelle werden auch immer nur Teile der Tabelle an den eGuide übertragen wodurch nicht von vorneherein die gesamte Tabelle, bzw. das Ergebnis des PROC PRINT übertragen werden muss.   Ganz deutlich wird das z.B. auch bei einem PROC SQL; SELECT ... bei einer großen Tabelle hat man auch hier das Problem, dass das gesamte Ergebnis übertragen werden muss. Wir führen hier bei uns daher ausschließlich PROC SQL; CREATE TABLE work.x AS SELECT ... aus. Somit wird eine Tabelle erzeugt, die wiederum nicht komplett an den eGuide (Client) übertragen werden muss. Schlau wäre an der Stelle wahrscheinlich auch das Erstellen einer View, aber da wir keine Performanceprobleme haben und meist mit der Tabelle weiterarbeiten nehmen wir oft das Create-Statement.   Ich denke, da sind einfach ein paar Anpassungen in der Arbeitsweise angebracht und ehrlich gesagt glaube ich, dass die Arbeit mit dem eGuide durchaus (mehr) Spaß macht und viele sinnvolle Features bietet 😉 Das mit dem direkten Anzeigen von Tabelleneigenschaften mag jetzt etwas sein, wo der EG wirklich nicht glänzt, bzw. was der DM besser macht... ich hoffe, Ihr findet aber noch viele Punkte, die Ihr braucht und die der EG wirklich gut macht.   Beste Grüße Michael ... View more

Vielleicht wäre es auch eine Überlegung wert, den Code für die Nutzer vorzufertigen und für alle zugänglich in den Metadaten abzulegen - ggf. als Stored Process.   Dabei könnte man auch mit Prompts arbeiten (z.B. Anzahl Tage für "liste alle Tabellen älter als &anzahl_tage. Tage auf", etc.).   Alternativ kann auch ein ganzes eGuide-Projekt in den Metadaten hinterlegt werden - auch mit entsprechenden Prompts (Eingabeaufforderungen). ... View more

Tatsächlich nehme ich für solche Abfragen auch immer "sashelp" bzw. "dictionary".   Interessant finde ich in dem Zusammenhang allerdings, dass auch die Anwendungsroutine "Dateien und Formate löschen ..." zwar eine Spalte "Modifiziert" anbietet, diese allerdings leider nicht befüllt ist. Dies würde die eigentliche Anforderung (Manuelle Prüfung und ggf. Löschen anhand letztem Änderungsdatum) genau erfüllen - wäre denn die Spalte "Modifiziert" befüllt... (eGuide 7.13) ... View more

I do understand this desired usage of proc compare might be quite rare. However, there was a need and I still do not understand how the documented behaviour, leads to a warning that can not be turned off by some option. Even when everything is working as documented and as expected.     Just leaving some code here, in case anyone will run into the same situation:   proc compare base=day1 comp=day2 outnoequal outcomp out=work.compout (/*keep=_type_ _obs_*/); by idfield; /* changed "id" to "by" so now the procedure does not produce a warning; however this omits some results - hence another step is needed */ var valuefield; run; proc sql; create table restoftheresults as select "COMPARE" as _TYPE_, b.idfield, b.valuefield from day1 a right outer join day2 b on a.idfield eq b.idfield where a.idfield is missing ;quit; data want; set compout restoftheresults; run; Since the proc compare does complain about duplicate ID-values, I changed the procedure to by-processing. This however does not deliver all the desired results, therefore another step is needed. Unfortunately the solution does not provide _OBS_ for all the results. This could be added with another step in between, if needed.   My next approach was to scratch the proc compare alltogether and use my own code to determine the results. Albeit the quick coding style, this should still be easier to understand and better readable than the proc compare logic. Here it goes:   data day1; set day1; by idfield; if first.idfield then groupseq = 1; else groupseq +1; run; data day2; set day2; by idfield; if first.idfield then groupseq = 1; else groupseq +1; _OBS_ = _n_; run; proc sql; create table want as select "COMPARE" as _TYPE_, b._OBS_, b.idfield, b.valuefield from day1 a full outer join day2 b on a.idfield = b.idfield and a.valuefield = b.valuefield and a.groupseq = b.groupseq where a.idfield is missing ;quit; The first steps simply enumerate the by groups (variable groupseq) to that the following SQL-Join can execute the needed comparisons. This provides all the observations from day2 that are not in day1. Due to the comparison on the valuefield, we also get the observations that have changed from day1 to day2. Again, this might be an odd piece of data processing, however this requirement came up and could not be changed.   Cheers to all and happy coding! Michael ... View more

Hallo zusammen,   klasse, wenn so viele konstruktive Vorschläge kommen und schön zu sehen, wie unterschiedlich teilweise ein Thema gehandhabt wird. Herzlichen Dank!    Ich habe mich jetzt für eine Abwandlung der Lösung von Grischa und Reinhard entschieden. Die anderen Ansätze finde ich spannend, jedoch möchte ich mich nicht weiter mit der Prüfung des Zeileninhalts beschäftigen. Daher: data c; length readfile datei $150.; infile "&root./a*.csv" /* firstobs = 2 -- nicht nötig, da unten bei _n_ = 1 newFile gesetzt wird */ dlm=';' eov = newFile filename = readfile ; input @; if _n_ = 1 then newFile = 1; datei = readfile; put newFile= datei=; If ( newFile ) Then Do; newFile=0 ; Input; Input; End; input a : best. b : $char3. ; run; Damit man nicht für das erste File und nachfolgende Files eine unterschiedliche Bearbeitung hat, habe ich firstobs nun ganz weggelassen und setze newFile einfach selbst auch für die erste Datei (die nach meinem Verständnis auch ein "newFile" ist).   Somit dürfte es auch einfach sein später Änderungen im Programm einzupflegen (falls die Logik mal nicht firstobs = n sondern firstobs = m sein soll, etc.).   Mir ist zwar noch nicht klar, weshalb SAS zwar erkennt, dass es sich um ein neues File handelt, aber dann nicht automatisch die Firstobs-Logik auf das neue File anwendet, aber das wird wohl auch niemand mehr ändern.    Besten Dank an Alle und herzliche Grüße Michael ... View more

Das ist schonmal ein guter Hinweis! 🙂 Ich vermute die Verarbeitung ist wie hier gemeint: support.sas.com - Holding a Record in the Input Buffer   Nun stellt sich mir die Frage, wie ich die Daten erkennen kann. Folgendes Beispiel: 1: Hier steht etwas 2: 3: 4: nach zwei leeren Zeilen steht wieder etwas. 5: Hier kommt noch ein weiterer String; sogar mit ; getrennt; 6: Artikel1;2038;VariableXY 7: Artikel2;2453;VariableXY 8: Artikel1;2342;VariableXY In der Datei stehen verschiede Kopfzeilen, die ggf. leer sind oder auch mal Sonderzeichen und Semicolon enthalten können. Ich weiß, dass ich immer ab einer bestimmten Zeilennummer lesen muss, daher war mein Ansatz "Firstobs".   Wenn ich nun alles einlese, wie kann ich denn dann unterscheiden, ob die Daten korrekt sind oder nicht? In Zeile 5 könnte ja der erste String bis zum Semicolon auch ein String sein, den ich in Zeile 6 als "Artikel" erwarte. Hier würde ja erst nach dem ersten Semicolon auffallen, dass ein String geliefert wird, obwohl ich dort einen numerischen Wert erwarte. Somit müsste ich ja jeweils alle Variablen prüfen oder prüfst Du auf _error_ ? ... View more

Hallo Frank,   ich würde auch schauen, dass die Verarbeitung mit einem BY-Statement alle Datensätze abarbeiten kann.     Alternativ kann z.B. mit einem Hash immer ein entsprechendes Dataset erzeugt werden und mit Call-Execute in einem Macro verarbeitet werden. Dabei könnten sogar die Ergebnisse anschließend im gleichen Data Step wieder eingelesen und an die Original-Daten angefügt werden. (Hier findet sich unter "Splitting A SAS File Dynamically Using The .OUTPUT() Method" ein Ansatz dafür)   Ein anderer Ansatz wäre die Ausgangsdaten (mit einem Hash) dynamisch in einzelne Datasets zu zerlegen und in einem Macro alle erzeugten Datasets zu verarbeiten.   Das hängt natürlich davon ab, wie mit den Ergebnissen weiter verfahren werden soll. Werden einzelne Datasets gebraucht oder wieder ein großes Dataset, etc...   Herzliche Grüße Michael ... View more

Hello @sonikm24,   could you please provide an example that is describing the problem? Your excel-file seems to contain no information and your dataset 'sonik' is missing. It would be best, if you could provide some sample dataset, so that we can work on the problem without having to crawl the websites.   From what I understand, you want to output certain rows of a dataset. For instance row 50, because some condition applies and then you also want row 49 and row 51, because they surround row 50?!   There are a number of ways, you could achieve that. Possibly a retain statement (with optional by-processing) could do the trick. Another option would be to use a hash and hash-iterator.   Cheers, Michael ... View more

Hello @madhatter,   unfortunately I am not sure, what your exact requirements are. The fields coho, cohoterm and enr were not explained so I did not use them any further. I understand that you have 15 semesters of data?   Here would be my code that does give you per ssn (ssn is the student number?) and per semester: If a student is enrolled at your home college and enrolled at a foreign college. Plus the first occasion, when a student is enrolled only at a foreign college and no more lines for that student afterwards.   Given the numbers in your fields indicate the semesters and are in correct order (i.e. enrterm1 means enrolment in semester 1).   /* transpose data */ DATA have_1 (keep = ssn coho cohoterm semester enrol_home enrol_abroad); SET have; ARRAY TRFSEM (15) TRFSEM1-TRFSEM15;/*TERMS STU ENROLLED OTHER COLLEGES*/ ARRAY ENRTERM(15) ENRTERM1-ENRTERM15;/*TERMS STU ENROLLED HOME COLLEGE*/ DO I=1 TO 15; if trfsem(I) = 1 then enrol_abroad = 1; else enrol_abroad = 0; if enrterm(I) = 1 then enrol_home = 1; else enrol_home = 0; semester = I; output; END; RUN; /* sort data for by-processing in next step */ proc sort data = have_1; by ssn semester; run; data want; set have_1; by ssn semester; retain outputline; /* set "outputline" to make sure there is no more output after a transfer student has been found and is in output once */ if first.ssn then outputline = 1; /* criteria to find */ if enrol_home and enrol_abroad and outputline then output; /* student enrolled home and abroad */ else if not enrol_home and enrol_abroad and outputline /* transfer student */ then do; output; outputline = 0; end; drop outputline; /* no need to output that */ run; Not sure, if this meets your requirements. Let me know if you had something else in mind.   If you need more information, you can always edit the logic in the last data step. For instance, create new columns like 'transfer_student', 'fist_semester_abroad', etc. By using the retain statement, you can determine further information per student, as desired.   Cheers, Michael ... View more

Sure you can.   It depends, though, on what you want to achieve, what steps you do besides the proc sql and how clean you want your code to be.   Here is one quick'n'dirty example: data have; a = 'emil, Nordpole, richard, Theo'; b = 'something, somethingelse'; output; a = 'sandman, emil, peter'; b = 'whatever'; output; a = 'samuel'; b = 'anoterexample'; output; a = 'stephany'; b = 'lookingforwordshere'; output; run; %macro quickndirty(varlist); %let varlist = %upcase(&varlist.); proc sql; create table want as select * from have where 1=0 %do i=1 %to %sysfunc(countw(&varlist.)); %let next_name = %scan(&varlist., &i.); or upcase(a) contains "&next_name." or upcase(b) contains "&next_name." %end; ;quit; %mend; %let list = nordpole pet lookingforwords; %quickndirty(&list.) I think you will be able to apply this to your example. The "1=0" is necessary, because the first "or" would lead to an error otherwise. As I said, this is just a quick'n'dirty example to get you started. Notice, however, that this does not search for complete words, but rather for the part that you enter. In my example I wrote "pet" instead of "peter", yet it still finds "peter". So unclear identifiers and typos might lead to unexpected results!   More sophisticated solutions might be found, but then again, it depends on your requirements.   You might also consider using ID's instead of names and follow the example procided here.   Cheers, Michael ... View more

@collinelliot: it seems, I have fallen for the pits in format usage again. your modification of my example will work, if you not only change the format start to character, but also change the values to which you apply the format to character:     data a; retain fmtname 'test_fm' type 'I'; start = '1'; label = 10; hlo = 'I';output; start = '2'; label = 20; hlo = 'I';output; start = '3'; label = 30; hlo = 'I';output; start = '4'; label = 40; hlo = 'I';output; start = '5'; label = 50; hlo = 'I';output; start = '6'; label = 60; hlo = 'I';output; start = ' '; label = 99; hlo = 'O'; output; run; proc format cntlin=work.a library=work; run; /* notice the quotation around the numbers. So we don't have numbers here, but characters. Just the same as in the format that was created above */ data b; b = input('3', test_fm.); output; b = input('5', test_fm.); output; b = input('7', test_fm.); output; run;   In fact, INPUT always requires a character value. That is why you would not want to input a number there. SAS will then do a type converison by itself.   My apologies for not reading your code thoroughly, and giving it enough thought at first.   As a matter of fact, I never had the use case when I would need to apply a format to create a numerical value from a given numerical value. It has always been either character to character, numeric to character or vice versa. I would suggest you change your holiday flag to a character value (which also uses less space when you use length 1 compared to length 8 of a numerical field).   By the way: This paper provides pretty good descriptions for creating formats from datasets.   Hope this helps. Cheers, Michael ... View more

Hi @collinelliot,   thanks for sharing! If only I had read this a few weeks ago, when I stumbled upon the topic myself.   For me, however, the hlo = 'O' in the 'OTHER' row does suffice. The proc format cntlin takes care of the rest and does fill the other rows with hlo = 'I'   I am wondering, why it does not do that for you?!   The following code works without problems for me: data a; retain fmtname 'test_fm' type 'I'; start = 1; label = 10; output; start = 2; label = 20; output; start = 3; label = 30; output; start = 4; label = 40; output; start = 5; label = 50; output; start = 6; label = 60; output; start = .; label = 99; hlo = 'O'; output; /* hlo is set only in the 'OTHER' row. Previous rows have hlo missing */ run; proc format cntlin=work.a library=work; run; /* the cntlin does set the hlo for all rows */ proc format cntlout = work.compareInfmts; select @test_fm; run; /* applying the format works with no problems */ data b; b = input(3, test_fm.); output; b = input(5, test_fm.); output; b = input(7, test_fm.); output; run; Cheers, Michael ... View more