It appears that SAS sets SYSCC=1012 when the ODS file is locked by another process. Is examination of SYSCC after ODS RTF statement as show below considered the acceptable way to trap this error. This is the most common reason my BATCH job with ODS RTF fails is because I have the FILE= open in WORD. I wan't to trap this error early in my program yada yada yada.
2363 %let SYSCC=0;
2364 %put NOTE: SYSERR=&syserr SYSRC=&sysrc SYSCC=&syscc;
NOTE: SYSERR=0 SYSRC=0 SYSCC=0
2365
2366 ods rtf file='<path to file>';
ERROR: File is in use, <path to file>.
ERROR: Fatal ODS error has occurred. Unable to continue processing this output destination.
WARNING: No body file. RTF output will not be created.
2367 %put NOTE: SYSERR=&syserr SYSRC=&sysrc SYSCC=&syscc;
NOTE: SYSERR=0 SYSRC=0 SYSCC=1012
disappointing quietness on this
I checked - and have same result in 9.2 and 9.3
Two additional macro variables (introduced in SAS9.2) offer the latest ERROR and WARNING messages
37 %put NOTE: SYSERR=&syserr SYSRC=&sysrc SYSCC=&syscc ;
NOTE: SYSERR=0 SYSRC=0 SYSCC=1012
38 %put NOTE: syswarningtext=&syswarningtext ;
NOTE: syswarningtext= No body file. RTF output will not be created
39 %put NOTE: syserrortext=&syserrortext ;
NOTE: syserrortext= Fatal ODS error has occurred. Unable to continue processing this output destination
The first of the two ERROR messages (which named the file "in use") is lost. Although not too important in this situation, future "situations" are unknown.
peter
Yes I was hoping to get confirmation from those in the know if my technique as accepted practice.
I have a program that produces an RTF report after doing enough computing to "send a man to the moon".
I would like to check if the report RTF file can be written, with the assumption that if the file is available when I check it will still be available after circling the moon.
I think checking SYSCC as describe will suffice. In my program I don't need SYSERRORTEXT as those errors are printed in the log. I check SYSCC write a message to the user to "look at the log", I probably should send them an email too, jump to "tidy up and exit with error".
the situation is now much better than earlier: when it seemed nothing flagged that the submitter didn't have rights to write in the ODS destination.
(once bitten, it was easy enough to model and verify write privilege in a data step, but took a while to recognise the issue )
The real issue is that you want to create a report that overwrites the existing file. If there are many users then there is a good liklihood that one of them will leave the file open and it can't be updated.
A possible solution is to create a filename that includes a date tag, example rtf_report_20111031.rtf.
If you are stuck with using the same file name then I might suggest creating the report locally using the name with the date and then, upon completion, copying the file onto the old filename.Here is a sample code within a macro.
systask command "copy ""&pdf_filename"" &pdf_copy" status=copypdf WAIT;
%if ©pdf ne 0 %then %do;
%put ERROR: Copy of Report &pdf_filename not completed;
%end;
Advantage here is that if the copy fails the report already exists and can then be manually copied without the need to rerun the analysis.
SAS Innovate 2025 is scheduled for May 6-9 in Orlando, FL. Sign up to be first to learn about the agenda and registration!
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.