is there a simple option that will cause SAS to stop running when it encounters an error. Something similar to the option ERRORABEND, except without quitting SAS?
I have seen other questions - e.g. Stop SAS Program on Error, and Stop SAS macro execution on error however those questions seemed somewhat different in that either dealing with remote server / handling expected errors at known places. I find it hard to believe/understand that there is no simple way of stopping at errors except by placing macros throughout the code to look for errors.
I believe the thing you are looking for is the break button on the application toolbar. It is the exclamation mark with the circle around it.
Note: make sure not to hit the clear all button (which is the stylized 'X')!! It will clear all your program editor code and cannot be undone.
You can use options syntaxcheck ; to enable syntax-checking mode after an error.
So, to enable what I think you want to achieve :
options noerrorabend syntaxcheck ;
https://support.sas.com/documentation/cdl/en/lrdict/64316/HTML/default/viewer.htm#base-sysop-syntaxcheck.htm
Related
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...
My SAS code contains multipledata steps and proc sql --> unrelated to one another . Some of them might throw an error . When this happens the rest of the code will terminate .
I need my code to keep on executing . Even if an error is thrown , just put it to the log ERROR : ... but still keep on executing . How can I do that ?
I tried some of the options from here
options noerrorabend;
But I could not find anything useful
I'd be careful doing this in production, but it appears that you can get back into normal processing mode by putting this line after every one of your data steps and procs that are prone to error. It basically undoes the usual mode that SAS switches into when it encounters an error.
options obs=max nosyntaxcheck;
Seems like a design problem.
Put each of your unrelated steps into different .sas files. If they're not related they shouldn't be in the same file anyway.
Call each .sas file individually from a UNIX script, or windows batch file, or SAS scheduler, or whatever it is you happen to be using.
If one of them has issues, it will not impact the next one in any way.
EDIT : Do NOT try to call them one after another by using a SAS %include statement, as this will use the same SAS session, and the problems from one will impact the next.
Quick question
Is there a one-liner (or something rather short) method of cancelling the execution of further SAS statements from withing the windowing environement.
These are the methods I know of but they get tiresome, espeacially in huge programs with a lot of comments.
I tried the ABORT and STOP statements but they close the windowing enviroment yet all I want is to stop execution at a certain point and go on my merry way.
Thanks
This is something that comes up on SAS-L every so often. The answer is that it depends on what you're doing, largely.
The run cancel method is probably best if you are hoping to stop execution because of an error. At the top of your program you do:
%let cancel =; *or any macro variable name, but cancel is most logical;
Then in every run step you have:
data whatever;
... do stuff ...;
run &cancel;
And each time you have some potential error, you check the error condition and then if it hits,%let cancel=cancel; and you're good.
If you are using macros, you can exit a macro smoothly with %abort as long as you either use no options or only use cancel. Depending on what you're doing, you might set up your code to run in a macro (or macros) and use this option (although with the disadvantage of losing some log clarity).
Finally, if you're just interesting in being able to run a subset of your code, I recommend writing the code in multiple SAS programs for the bits you might want to run separately, then using %include from a master program to group them all together along with any macro variables you might want set that are shared. This is similar to how in EG you would construct many smaller programs and then group them using the process flow diagram.
I have used the following
%abort cancel;
i've been searching for this too - documentation is not good on this one. Trial and error (sigh...). This, amazingly, undocumented feature worked for me:
data _null_ ;
ABORT CANCEL ;
run ;
Pretty simple! Nothing after that executed, and yet the SAS application remained open.
Every time I run a project in debug mode, I get 4 consecutive breaks at the start that I have to hit continue for each time. They are in the same file at the same point.
It would be great if I could say to simply ignore these since they don't impact functionality.
The obviously better route would be to try to resolve it so it doesn't cause a break/continue prompt but I think that's more effort that it's worth at the moment.
It would be great if the solution related only to my specific environment so I wouldn't have to undo/do it each time I pull/push a build.
Try to use break point condition or break point filer.
I am using PC-Lint for my C++ project.
Is there a way to switch off all error and warning messages by default, so I can then reintroduce the required messages explicitly?
I have read the chapter of the PC-Lint manual entitled "Error Inhibition Options" and the best I could find was setting the wLevel to -w0 No messages (except for fatal errors)
Yes, it is possible, you can simply use -e* or -w0. However, the manual truly states (Chapter 16. Living with Lint):
DO NOT simply suppress all warnings with something
like: -e* or -w0 as this can disguise hard errors and make subsequent diagnosis very difficult.
So, yes, you can use it if your code is basically cleaned, and you want to review recent changes for a certain set of messages. But if you want to start cleaning your code, and are swamped with messages because of the default warning level -w3, I suggest to start using -w1, and resolve all issues there; most of the warnings/errors given at level one indicate problems with finding all header files, having al implicit macros set properly, and/or mimicking the compiler you use normally in a sufficiently precise way.
As always, I hesitate to advertise my own work, but if you want, take a look at my "How to wield PC Lint" PDF, where I have documented detailed instructions to handle the initial deployment of PC Lint and tackling the many warnings/errors/infos/notes you may be buried under.
When I started introducing PC-Lint to a new project I did the following:
As suggested by Johan Bezem, ran a -w1 level check over the whole thing. This doesn't actually find any new problems, but checks that your program is syntactically valid and finds any configuration issues. Nothing major, assuming your project compiles already.
Run the test again with -w2 level. This found 53,000 issues, which was a bit much to tackle in one go.
Pick a typical bad file, then suppress any errors that seem
irrelevant or non-urgent (eg. error 525: (Warning -- Negative indentation from line xxx)
adding -e525 to the command line or config file, until you find one that seems serious.
In my case this was
error 442: (Warning -- for clause irregularity: testing direction inconsistent with increment direction), i.e. a 'for' loop
that looked like it should be counting up was actually counting
down.
Reset the test level back to -w1 but added in the critical problem by number, -w1 +e442 in this case. Re-run it over the whole project then fix all the instances of that problem.
Back to stage 2 and try again.
This combination of fixing actual problems and suppressing likely false alarms soon gets your numbers under control.
So that everything gets better over time we also implement a script that does a thorough (full -w2 or -w3) check on any files that are created or modified.
I also found the tool LintProject very helpful as it can do an entire Visual Studio solution in one go, with tables with numbers of errors and worst offenders!