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...
Related
Basically when I do sorting or join table in sas, the sas will use resources / space from local disk C: to process the code, but since I only have 100GB left on local disk C:, It will result in error whenever SAS was out of resources.
My question is how to configure / change the setting in SAS to use resources from Local Disk E: instead, since I have larger space there.
I already looking through the forum, but found no similiar question.
Please Help.
Assuming you are talking about desktop SAS, or a server that you administer, you can control where the work and utility folders are stored in a few ways.
The best way is to use the -work and -utilloc options in your sasv9.cfg file. That file can be in a few places, but often the SAS Shortcut you open SAS with specifies it with the -CONFIG option. You can also set the option in that shortcut with -WORK or -UTILLOC command line options. The article How SAS Finds and Processes Configuration Files can help you decide the location of the sasv9.cfg you want to modify; if you are using a personal copy on your own laptop, you may change the one in the Program Files folder, but if not, or if you don 't have administrative rights, you have other places you can place a config file that will override that one.
A paper that discusses a few of these options is one by Peter Eberhardt and Mengting Wang.
One way is to set up a library named user for projects that will be time intensive and this way you get it to be dynamic as needed. When you have a library called user, that becomes the default workspace instead of work. But, you need to clean up that library manually, it won't delete data sets automatically when you're done with it.
libname user '/folders/myfolders/demo';
As #Tom indicates, you can also set an option to use a library that already exists if desired.
options user = myLib;
An advantage of this method over the config file method as it only does it for projects where it's needed, rather than your full system.
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.
I'm writing procedure for other users to run in Enterprise guide based on SAS 9.3. It logs various bits of information to a table. Is there any way to stop this table appearing in the process flow?
NB This is almost all done using "User written code" steps. Unfortunately the setting in the menu (see vasja's answer below) does not seem to affect UWC steps.
(I've seen this: Tell SAS not to add newly generated tables on the Process Flow but I'm using 9.3 so it doesn't work!)
A colleague (twitter.com/binarytrain) figured out a solution.
Tables are always added to EG projects in 9.3 if, at the end of the code step, the library in which it exists is still assigned(1). So, in the question above, the trick is to clear the libname at the end of the code step.
This can further be used to "discourage" - not stop - users from meddling with temporary tables.
Create a folder in &sasworklocation called _work
Register it as a library
Save any temporary tables in this new library
Clear this library at the end of the code step
At this point the temporary table is inacessible without running a libname statement
Re-registered the library when the table is required again.
(1) Even if it's assigned using a different name, so this won't work for pre-assigned libraries.
In EG 5.1:
go to Tools - Options, select Result General:
deselect Automatically add output to the project tree.
Is there a way to password protect SAS CODE within SAS? Or, if not, what is the easiest / quickest way to apply some kind of password protection?
I am referring to scripts run from local Windows PCs (ie not batch). The scripts are stored on a standard network drive...
(Ideally the solution would not involve a Microsoft product such as Word or Excel!!)
You could try using SCL code copied with the NOSOURCE and NOEDIT options.
This approach of course relies on you having SAS/AF installed.
Like this:
Create a new local SCL Entry. Your INIT section asks for or checks a password. If the password is correct, control is handed to another label with the LINK command, if not, do something else.
Put your SAS code in the label you linked to in step 1, if it's BASE SAS, put it in a submit block, in which case you'll also want to set the NOSOURCE and NOSOURCE2 options to prevent your program to show up in the SAS log.
Compile, save and close your SCL entry.
Copy your SCL to its final destination using PROC COPY with the NOSOURCE and NOEDIT options.
Users can now start a SAS session that calls the SCL. If the correct password is provided, the SCL code runs the embedded SAS code. Users can't snoop the password, nor the program code essentials from the program due to the NOSOURCE option.
Note that this is not state of the art, high security password protection!
It's a quick and dirty way to keep the "wrong" people from running a specific piece of hidden SAS code.
I think the answer to your question is "no".
SAS doesn't have a good solution for this. Windows doesn't have a good solution for this.
3rd party software for password protection may be your only option.
In the enhanced editor, the coloring might give you a hint. However, on the mainframe I don't believe there is anything, in the editor, that will help you.
I use
OPTIONS OBS=0 noreplace;
The obs=0 option specifies that 0 observarions are read in from the input
dataset and NOREPLACE tells SAS not to overwite an existing SAS dataset with one of the
same name. If you are creating a new datastet, it will be created with all the attributes,
but with 0 observations. (Be sure to reset the options, if needed, to Options Obs=max replace ; when no more syntax errors are found).
I'd be interested in any other techniques.
Thanks
Explanation about options came from here.
I use the cancel option on the run statement. It will check the syntax of the data step then terminate it without actually executing it. It's the data step analog to the noexec option in proc sql.
data something;
<stuff here>
run cancel;
Lots more details in this SUGI pdf
I write all of my code on my PC with SAS on my PC and the enhanced, color coded editor. I then use SAS/CONNECT to process it on the mainframe. If the datasets are on DASD, I use SAS/CONNECT and Enterprise Guide to directly run the code onthe mainframe (no JCL!) If there is a data tape involved and therefore must be a batch run, I use SAS/CONNECT and the SAS ftp engine to send the code to the mainframe batch queue. I use the SAS email engine to email me back my output and my log. I put and ODS sandwich aound my code to have the mainframe generate a WORD document for output. I use a PROC download to download the output to my server so I can open it in WORD.
This advice is language agnostic.
I would argue that a preferable technique for catching syntax (and logic) errors is to perform a close read (or inspection) of your own code (which should catch the majority of syntax errors), followed by unit tests on small datasets (which will catch any remaining syntax errors, as well as many logic errors if your tests are well-designed).
I agree there's some worth to syntax checking in isolation, but to read and understand your code thoroughly enough before the first compile so that you know it will compile is a good ideal to strive for. Steve McConnell touches on this idea in Code Complete (see page 827 of the 2nd Edition).
P.S. You mentioned syntax highlighting in your original post; there are other editors (such as VIM) that will perform syntax highlighting on SAS files.