I have a bit of a problem trying to code up what I want to do in SAS and I was hoping to get some advice from someone. I was wondering if it is possible to write code that will examine another piece of existing SAS code and bring up a list of the required input datasets and variables. I am wanting to invoke other SAS code in an automated process using the %include function and a prompt for the user to define the exact name/ location of the code as this will be different every time. But before this I want to somehow check this code, rename an existing dataset to be the input dataset and check that I have all the required variables before running the %include.
I was hoping someone might be able to tell me if this is at all possible and if so what function I would use. I am using EG 5.1 if that makes any difference.
Thanks for your help.
Steph.
P.S. Thanks for your help guys. Sorry if this question is outside the scope of this site, I thought there might be a simple function to achieve this, similar to %include. Also, I have never posted on this site before so apologies if I did stuff wrong.
Related
I've moved to a larger organization where there's lots of existing code(mainly SAS - the WPS version).
This is the first time I'm using the language, and I'm having trouble understanding the code, I'm not able to figure out how to approach understanding the large codebase.
P.S : Existing questions were not SAS-specific, I posted so people with SAS experience could help
I have converted 1000's of line of code from SAS to Teradata SQL and this are my learnings. if you have basic SAS knowledge, you should be fine.
It can be complex too, once I had issue with very complex regex code, which was difficult for me at that point of time. following two steps helped me out.
Read the code step by step and if you are not clear than run the code step by step in
development area, make sure you are not overwriting permanent tables. This will help understand what is happening in each step. Write comments for yourselves at each step, so that you can understand better.
If you are assigned for rewrite then run original code(step by step) and rewritten code step by step and compare results (do not overwrite permanent datasets). Also compare final resultant sets too.
I have inherited a large base of SAS code. I need to reverse engineer to create some mapping document, so that given a field in the final output dataset, we can easily trace it all the way back to one of the inputs.
I can create it by hand, but can SAS automatically generate something like this?
No, I don't think there is any ready-made automated way of doing this.
Bear in mind that it is possible to create variables and pass them through a whole series of procs and data steps without mentioning them by name anywhere in the source code. Some sort of run-time analysis is therefore unavoidable.
Reeza's suggestion of using proc scaproc will yield some useful information for code executed within a single self-contained job running in a single SAS session, and the ATTR option in the record statement might be of some help to you when tracing the lineage of variables, but I'm afraid that however you approach this, it's going to take quite a lot of work.
I was given the task to convert great amount of RTF tables into XML ones (around or way more than 100.000), but I have no idea how to even start it and i cannot get help from the lead developer, because ironically he had never written a line of code.
I was thinking about c++ as I need t to be fast, but I'm open to any ideas.
What I need is some information I can start the project with or any library/program I could use for my help, thank you.
EDIT: I have XSD schemas to work with.
Found the solution after looking for a while. I can use LibreOffice to save it as html or other various forms that will keep the table as it is and also give a clear code i can pull an XSD on to make it valid also.
z/OS 1.11, MXG 32.10, SAS 9.3, Batch
I'm working on upgrading MXG to 32.10 with SAS 9.3. While running a CICS report today, I received the message that MXG was taking 20x to 30x CPU processing to decompress messages because the decompression exit was not enabled. To do so, I have to set the macro variable &SMFEXIT to CICS in each run, as follows (I had already assembled and linked the exit and had it available in STEPLIB):
%LET SMFEXIT=CICS
Other options are available but they are more complex and still need set every time I want to access the CICS data. I used it in my program and it worked fine and ran much, much faster.
I figured I'd put this into AUTOEXEC. It didn't work there. AUTOEXEC seemed to process normally with no errors, meaning there was no output at all... It may have had a warning, but that wouldn't show. Only errors display from AUTOEXEC.
I found that I could specify global option ECHOAUTO, along with SOURCE, to display AUTOEXEC processing. That has to be done either in CONFIG or as an invocation parameter. I tried both options and neither worked. I purposefully misspelled it in CONFIG and that threw an error, so I know it was being found. SAS lists the invocation parameters in SASLOG, so ECHOAUTO and SOURCE were both listed there. I received no indication that those options were working and AUTOEXEC processing just didn't go to SASLOG.
I ran PROC OPTIONS RESTRICT and nothing was restricted.
All the messages kept telling me to talk to the System Administrator. I found nothing that told me who that was, what they were supposed to do or how to find out... I sit by our System Administrator and he was no help with this because I'm the one that knows SAS. Or, I thought I did...
So, how do I set &SMFEXIT to CICS globally? Bonus for information as to why ECHOAUTO totally ignored me and information about the System Administrator. Also, where can I find information about the limitations of AUTOEXEC as in what can or cannot be there. Better yet, tell me in what guide I can find this information myself. I searched for a long time and couldn't find any of that. SAS documents are many. SAS information about these questions is either scarce or just impossible to find.
Thanks...
UPDATE: I am considering setting up my MXG proc so that it has a concatenation that throws in this control card ahead of the MXG/SAS programs. Seems like an awful hack... Still would like other options and answers to the ancillary issues IAAP. Thanks again.
Ah yes, the head slap... Every issue above is easily explained by the fact that AUTOEXEC is not being called! Variables aren't set. Logic isn't added to the SASLOG.
We use Windows SAS, too. We use AUTOEXEC.SAS to extensively initialize that environment. On the other hand, on z/OS, we use JCL and parameters to initialize SAS without using AUTOEXEC, so it has never been implemented.
On z/OS, the AUTOEXEC global option defaults to the SASEXEC ddname. I added the appropriate JCL to my MXG PROC to point to my AUTOEXEC member. Voila. My variable is set. The logic is available in SASLOG. Everything appears to be working, all with one simple root cause.
Thanks...
Are there any generic suggestions for identifying the SAS code / program that is being executed?
My code will execute within a generic macro, so could be called within a Stored Process, another macro, a client SAS program, or even SAS code generated via the mid-tier using IOM. I'd like the highest level identifier possible.. (something that will return the same result if the same program is run again - so process id would not be helpful).
The environment is not windows, so this code is not helpful:
%put %sysget(SAS_EXECFILENAME);
Also, the macro is not necessarily the first program that is called (if it is even a program) - so neither is this code helpful:
proc sql noprint;
select xpath into :progname
from sashelp.vextfl where upcase(xpath) like '%.SAS';
%put &progname;
It sounds to me like you may need to think through how this is to be be used a little more. What if the same user has two sessions open running the same code? Should that use the same file name?
Can you simply make it a requirement of your piece of code that a certain variable must have been specified before your code will run? Otherwise return an error / abort further processing?
To answer your original question though I don't think this is possible.