It is not clear what you are asking for.
Are you asking how to capture the status of an HTTP request and then use that result to control what happens afterwards?
Or are you asking how to prevent HTTP errors from ever happening? That sounds much more problematic. Why would you want to prevent the error? How would you know if it worked or not?
The tcperror condition -- when it happens -- is at a lower level than what PROC HTTP can catch/detect and report in the status macro variables. As a very frequent user of PROC HTTP, I see it only when there are network glitches or issues that might be triggered by a firewall or other environmental conditions.
My only advice is to make sure you are up-to-date on SAS maintenance/hotfix releases, and ensure your network environment is stable/available during your SAS job run.
@VIU wrote:
Hello Chris,
thats exactly the problem but sadly your solutions cannot be "applied".
Is there not one option avaible, where some workaround might be possible? The error triggers some jobs to fail constantly...
Is the problem the job failure, rather than the error message in the log? Often job failure is determined by one of the automatic macro variables that stores error codes. If the job is aborting early due to the error, there are error handling options to prevent that. But I don't think there is the equivalent of a 'CATCH' statement like in an object-oriented language, where you could catch all exceptions to prevent them being raised.
Here's some logic lifted from one of my processes that I had to guard against network issues like this. It does not produce a clean log but it does allow the process to continue gracefully. The first trick is to check for the existence of the SYS_PROCHTTP_STATUS_CODE macro before checking for a value. In my case I built in some retry logic, but if it fails again then I fall through and give up.
%if %symexist(SYS_PROCHTTP_STATUS_CODE) %then
%do;
%if &SYS_PROCHTTP_STATUS_CODE. ne 200 or &syserr. ne 0 %then
%do;
%put WARNING: Expected 200, but received &SYS_PROCHTTP_STATUS_CODE., SYSERR = &syserr.;
%put Waiting 20 seconds to retry...;
%if &SYS_PROCHTTP_STATUS_CODE. eq 403 %then
%do;
%put Refreshing auth token;
%refreshAuthToken; /* special case where I might need to reauth */
%end;
data _null_;
rc=sleep(20,1);
run;
/* call macro that retries here */
%if &SYS_PROCHTTP_STATUS_CODE. ne 200 or &syserr. ne 0 %then
%do;
%put WARNING: Failed again. Expected 200, but received &SYS_PROCHTTP_STATUS_CODE., SYSERR = &syserr.;
%let msgerr = Process stopped after 2 consecutive failures: &SYS_PROCHTTP_STATUS_CODE., see log;
%end;
%end;
%else
%do;
%put HTTP result: &SYS_PROCHTTP_STATUS_CODE. &SYS_PROCHTTP_STATUS_PHRASE.;
%end;
%if &syserr. = 0 %then
%do;
/* Process Result Here */
%end;
%end; /* SYMEXIST SYS_PROCHTTP_STATUS_CODE */
%else
%do;
%put ERROR: PROC HTTP failed! %superq(syserrortext);
%let msgerr = Errors in fetching data - see log.;
%end;
If your goal is to avoid writing any messages to the log, you can redirect the log somewhere else (or to a bit-bucket). On Windows you can do:
proc printto log='nul' ;
run ;
%put Look Ma no log! ;
proc printto log=log ;
run ;
But I've never (?) seen a good reason for doing that. I know some companies have a 'no errors in the log' rule, but I don't think that is a reason to turn off the log (and miss all the other important messages you get). In a case like this, I think it's better to add an exception to your log checker, to allow an expected error message.
I don't even like turning off MPRINT. The idea of turning off the log completely terrifies me.
Save $250 on SAS Innovate and get a free advance copy of the new SAS For Dummies book! Use the code "SASforDummies" to register. Don't miss out, May 6-9, in Orlando, Florida.
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.
Ready to level-up your skills? Choose your own adventure.