I am trying to go over set and get the path of a file. Then, I want to open the file and get another set out of it.
My problem is that my script works without any issues when executed via Enterprise Guide, but fails if executed via command line.
WARNING: Apparent invocation of macro GET_DATA not resolved.
Seems like my path variable is not set and my macro is not executed when I run it via command line.
data _null_;
set files_to_parse;
count + 1;
call execute('%get_data('||path||', '||count||')');
run;
Here I am trying to instantiate an excel as a library
%macro get_data(path, cnt);
/* Get current iteration of excel spreadsheet */
libname xl XLSX "&path.";
%mend get_data;
Make sure you have defined the macro before trying to use it. Perhaps with EG your program worked because you had previously compiled the macro.
The error is that %get_data is not compiled, not that it's not resolving the path.
It's hard to say why with the information you gave us, but since you see a difference running in EG vs in command line, I suspect you either have the macro compiled as part of an autoexec process flow in EG, or you have an autocall macro library that's not properly set up through the command line config file. Talk to your SAS Admin if you don't know what these things mean.
Related
I am trying to copy files from one directory to another in SAS EG, but it was not working.
The basic idea in here is to convert .xlsm file to .xlsx file.
%sysexec( copy "&path.\excel1.xlsm"
"&path.\excel1.xlsx" ) ;
I didn't get any error in SAS EG, but nothing happen (no file copied), does anyone know the reason?
Make sure that your SAS session has the XMCD option turned on.
XCMD Enables the X command in SAS.
You can use PROC OPTIONS or GETOPTION() function to see the current setting. This option must be set when the session starts so you might need to modify the server you are connecting to with Enterprise Guide to one with the option turned on (or modify the configuration of the server).
Also make sure that the command and path you are using will work on the server where your SAS code is running. You can look at some of the automatic macro variables like SYSSCP, SYSHOSTNAME and SYSHOSTINFO to see the operating system where SAS is running.
22 %put &=sysscp &=syshostname &=syshostinfolong ;
SYSSCP=WIN SYSHOSTNAME=XXXXXX SYSHOSTINFOLONG=X64_10PRO WIN 10.0.18362 Workstation
If you still have issues you can also use another method to run your command where you will be able to more easily see the messages that the operating system might generate. For example using the PIPE filename engine.
data _null_;
infile %sysfunc(quote(copy "&path.\excel1.xlsm" "&path.\excel1.xlsx" 2>&1)) pipe;
input;
put _infile_;
run;
I'd like to remove/delete/unassign the standard SAS libraries from my SAS 9.3 GUI.
I've tried two solutions to remove a library which haven't worked:
%sysfunc(libname(maps)) results in:
ERROR 180-322: Statement is not valid or it is used out of proper order.
Comment out the offending start up code in the file sasv9.cfg
I don't have permission to modify (C:\Program Files...) files in that directory
Thanks!
The libraries are:
- Maps
Mapsgfk
Mapssas
Sashelp
Sasuser
You can remove the map related libnames, at the cost of not having the map files available to you and possibly losing some functionality.
If you copy your basic config file to some other location, either to one of the predefined locations mentioned in Files Used By SAS for your operating system (I link to the Windows version here, but Unix has a similar page); or to a location specified on the -CONFIG option in your shortcut, like for example:
"C:\Program Files\SAS94\SASFoundation\9.4\sas.exe" -CONFIG "C:\temp\sasv9_nolibs.cfg"
You can do this without having write access to the Program Files directories where the config files are usually stored. If you do that, you can then customize it by removing the -MAPS and related lines. Then those libraries will not be created; in that case, only SASHELP, SASUSER, and WORK are created, as follows:
Removing SASUSER does not seem to be possible, as while you can remove the -SASUSER option in the config file, it will still create the SASUSER folder.
Removing the -SASHELP option will unfortunately cause SAS to crash on initialization; SASHELP contains many core files for SAS functionality and SAS cannot work without it. See the following screenshot.
As such, you can get down to 3 libraries, but not further.
You got the 180-322 because the libname function returns a value and you call it in open code and the code it generated is not valid.
29 %put NOTE: %sysfunc(libname(maps));
NOTE: -630193
Do as above an you will see the value. However it looks like you cannot clear LIBREF MAPS.
Not sure if you can remove them without changing your system wide config.sas file. But you could point the MAPS options to null devices so that they don't find any datasets. Here is output from PROC OPTIONS.
MAPS=!SASROOT/maps
Specifies the location of SAS/GRAPH map data sets.
MAPSGFK=!SASROOT/mapsgfk
Specifies the location of GfK maps.
MAPSSAS=!SASROOT/maps
Specifies the location of SAS map data sets.
You can point these two different locations with command line options.
sas -maps /dev/nul -mapsgfk /dev/nul -mapssas /dev/nul
The libref will still be created but there won't be any members found.
You might do something similar for SASUSER, but then you would probably also want to add -rsasuser option so that SAS would know to create a WORK.PROFILE to use in place of the normal SASUSER.PROFILE catalog.
I don't think you would want to remove SASHELP libref as I think there are a number of things in SAS that would not work without being able to find things that are made available via that libref.
I am just playing around with SAS, writing the following code
options nocenter nonumber;
data vag;
infile "C:\Users\Deborah\Desktop\School\STA 318\book\veggies.txt";
input Name $ Code $ Days Number Price;
CostPerSeed = Price / Number;
run;
The location of the file is correct, but the error I am getting
ERROR: Physical file does not exist, /opt/sasinside/SASConfig/Lev1/SASApp/C:\Users\Deborah\Desktop\School\STA 318\book\veggies.txt.
What can I do to fix this?
You are working on Unix server, not you local PC. While you are running a local client on your PC (like SAS EG), you can't actually access local resources on your local PC because these resources needs to be made available to Unix box itself.
You have four options:
1. Use an import Wizard in SAS EG. It will generate a data step and will use hidden SAS EG methods to convert your text file and move it as a data set to Unix server where you then can create variables that you want.
See if your file system is available to you in SAS EG. Expand your workspace server. You should see "files". Expand to the folder that you are allowed to use and drag&drop your text file into there.
Upload files to the unix server using whatever file transfer method is available. Usually you would have some sort of FTP server running.
Also, as Joe suggested, you can install this custom task http://blogs.sas.com/content/sasdummy/2012/12/06/copy-files-in-sas-eg/
It can do a lot better job that step 2 or 3 because it can be part of your process, resolve macro variables and fix file formatting issues between Windows and Unix. Thanks Joe!!
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.