I'm trying to play around with reseting syntax check more, so that SAS will continue normal processing.
It's related to a hierachical set of processes.
One program uses remote submittal to run other processes on a remote SAS server, there's not a problem here.
That remote process determines day's of missing data, and attempts to fill in these days. This generally works when something stupid happens, the process doesn't run for a day or two, and then when it does, as long as the underlying data is still available, it fills in the days its missed, bringing itself up to date.
The problem is if the underlying data for a day is missing, and can not be provided. SAS picks up the error that the underlying datafile is missing and sets itself into SYNTAX CHECK MODE:
ERROR: Physical file does not exist, extract_all_best1_data.May-03-2008/file_system_statistics.txt.
NOTE: The SAS System stopped processing this step because of errors.
NOTE: SAS set option OBS=0 and will continue to check statements. This may cause NOTE: No observations in data set.
The middle process is simply a loop that creates an include file that calls a macro and then uses "call execute" to bring in the include file(s).
file dummy filevar=file_name;
put 'options nosyntaxcheck obs=max replace;';
put 'data _dummy; dummy=1; run; proc delete data=dummy;';
put 'options syntaxcheck;';
put macro_call $;
call execute('%include "' || trim(file_name) || '";');
The options and data step "put" statements are part of my playing with trying to turn off SYNTAX CHECK MODE.
Let's say we have underlying data for 4/29, 4/30, 5/1, 5/2; missing data for 5/3, 5/4; have a partial day for 5/5; and then pick up again with full data sets for 5/6 onwards.
A problem that occurred on 4/30 caused the data processing program to not run until 5/6, so it recognizes that it has missed 5/1 through 5/5. It backfills 5/1 and 5/2 ok, but then it errors on 5/3 and essentially stops processing. On 5/7, it finds it is missing 5/3 through 5/6, but doesn't fill in the gap for 5/5 and 5/6 because SAS errors on 5/3's missing data.
What I want to happen is for the error to be detected and noted, for SAS to continue in its syntax check mode through the end of the included section for that day. But, then I want to reset SAS back to normal, as if it didn't detect an error, and normally process the next day (5/4) error out, skip along, get reset and pick up again processing 5/5 and 5/6 normally.
Message was edited by: Chuck
Can't do that.
The file is ftp'd via SAS, it is on a remote server.
filename metrics ftp "&sourcepath/&metric_group..txt";
so the test
if fileexist("//remote_server/home/dummy.txt") then put "OK;
else put "not OK";
will always fail.
So, I'm back to needing/wanting to reset the Syntax Check thing.
The documentation looks like you are SOL. So we must trick it! with convoluted code.
I assume that you are reading the file directly from the ftp site and not copying it into a "staging" location on your network. Can you copy the file from the ftp site to your network then try fileexist?
I also found this on the web
This guy gets a directory listing of the ftp site and checks for the existance of a Bloomberg file.
I know this will be lots of code just to "turn off" an option.
When using a master SAS program to select and submit worker programs, I got to the point where a problem in a "called worker" program would get an error and the subsequent submits would not happen. This was a real issue where at the end of the master program there was something to generate output or report completion.
On return from the worker, I was able to test the options, and where Obs had become 0, I could reset the error condition with explicit option statements. As I recall, it took 3:
Options No$SyntaxCheck Obs = Max;
These are the two I remember. I am sure there was a third, but it eludes me at this hour. I'll check my black books later and add the third if I can find it. I seem to recall I identified it my using the OptSave procedure to save options to a table, ran some known erroneous code, and reran the OptSave to get another table. Then I used Proc Compare to find the changes.
Once the changes are identified, make the OptReset line into a macro with the option check for your trigger (such as "If Obs = 0"), and a line indicating a reset was performed. Then call the macro after each file.