If you search here (and/or lexjansen.com for user group papers) for "CONSORT Diagram," you'll find some approaches.   e.g. https://communities.sas.com/t5/SAS-Global-Forum-Proceedings/Methods-of-a-Fully-Automated-CONSORT-Diagram-Macro-CONSORT/ta-p/726358 https://support.sas.com/resources/papers/proceedings19/3149-2019.pdf   ... View more

If I had the shell scripting skills, I might use a similar approach.     For errors that might effectively kill the session, I wouldn't get an email from my job.  But I also have a separate nightly summary job that looks to see that all expected jobs completed successfully.  If one of my jobs doesn't succeed, the summary job will detect it.  The only down side is I won't be notified immediately. ... View more

I would look on lexjansen.com for papers with examples.   My approach: SAS job starts by using PROC PRINTTO to send the log to a file. At the end of the job, scan the the log file to look for any errors, warnings, or bad notes.  Save those messages.  (Note before the step that scans the log, set options obs=max replace NoSyntaxCheck  in order to recover from syntaxcheck mode.  Without that, if SAS has entered sytaxcheck mode your log scan will not run.) If any bad log messages were found, send an email, with the name of the program, the messages found, link to the log file, etc.   I also append the data to a job history table, so I can see the full history of job runs, when they errored, number of obs written, etc.  Also I run a nightly job that checks to make sure all expected jobs have run in the past 24 hours.    If you start with getting the log scanning working, then sending the email is pretty straight forward.   So you could start by looking on lexjansen.com for log scanning papers, then look for emailing papers.   The other option is to use your scheduler software, and pick up job return codes.  The only down side of that is that bad log notes may not trigger a non-zero return code.  But there are system options that allow you to turn most bad log notes into warnings or errors, so this may not be much of an issue. ... View more

I think Tom is correct.   If you view the file in Notepad++, you can see some of what look like control characters: I see that you are using macro quoting:   202 %createcheck(chk=11, whr=%str(bmdtc>today()), keepvars=siteid subjid questid visit lbnam When you do that, SAS will temporarily convert the > sign into non-printable characters.  It looks like MLOGIC does not automatically unquote the value, so you are ending up with non-printable characters in your log file, and one of them gets interpreted as and end-of-file character.  That's quite a gotcha. ... View more

Glad you got it working.   I suspect the problem was actually in your SAS dataset, not in the process of exporting the data to Excel.  Can you share how you exported the data to Excel?     My understanding is the yearcutoff option only has an effect when SAS encounters a two-digit value and is asked to interpret it as a four-digit year.   Once you have a date variable (or date-time variable), the data is stored as a number (number of days or seconds since 01Jan1960).  So yearcutoff should not have any impact, as I understand it.   When I run below, the date-time is correctly exported to Excel, as I would expect: options yearcutoff=1926 ; data have ; mydate="01Jan2026:12:54"dt ; format mydate datetime. ; run ; proc export data=have outfile="Q:\junk\want.xlsx" dbms=xlsx replace; run ; My guess is if changing yearcutoff fixed the problem, that means somewhere in your code or data you have a two-digit year and you asked SAS to calculate a date-time from that value.   @ChrisHemedinger , is there really a case where the YEARCUTOFF value would effect the export process itself (assuming the exported data is a SAS date or date-time)? ... View more

I suggest using a log scanner program.  This can be a SAS program, or a shell script or whatever.  If you search on lexjansen.com, you'll find plenty of papers on log scanning.    Many will search for ERROR, WARNING and have a list of NOTES they consider bad. I like the approach in Li & Troxell (https://www.lexjansen.com/nesug/nesug01/cc/cc4008.pdf) who recommend passing a list of good NOTES and treating any NOTE that is not in the good list as bad.     ... View more

If you have a date-time variable in a SAS dataset, and you're exporting the data to Excel, I don't see how Excel could end up with a value that is 100 years off.    But it's hard to guess at what might be going wrong without more info.  Can you show the code for how you export the data to Excel?   Can you post example data that replicates the problem?  For example, if you export the below dataset, do you see the problem?   data have ; mydate="01Jan2026:12:54"dt ; format mydate datetime19. ; run ; I think it's most likely that the date-time value in your SAS dataset is actually 1/1/1926 12:54, due to a problem earlier in your code.   ... View more

I tested on local Windows with PC SAS. With the Excel file open, I could copy it using Windows file explorer and could copy it using copy(). But could be different for Windows server. ... View more

One part of the answer (definitely not the whole answer) is that there is a documented list of formats that are not supported by the Graphics Template Language, and e8601da is on the list of unsupported formats.  https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/grstatgraph/n0o4b33j6ue5bkn1viojbbvwzkba.htm   No clue what about the iso8601 formats would make them difficult to support in GTL.   I'd be curious to see the full code for an example of your third problem.  If adding the xaxis statement with type=time fixed the problem, then it's a good bet that without that, SGPLOT guessed that the axis type was linear.  You can end up with some weird looking plots if SGPLOT guesses the wrong axis type. In below example SGPLOT guesses the axis should be linear, because there is no format attached to the variable.  Using valuesformat will format the xaxis as dates, but note they repeat because it's a linear axis:   data a; input x y; datalines; 1 1 2 2 3 3 4 4 ; run; proc sGPlot data = a; scatter x = x y = y; xaxis valuesformat=date9. ; run;     ... View more

Looks like fcopy() is happy to copy an Excel file while the file is open.  Also copies fine if the file is open and there are unsaved changes to the file.  But it would make sense that when you hit SAVE in Excel, at some point in that process when it writes the file to disk, Excel is going to get an exclusive lock on the file.   If your timing is occasionally unlucky enough that you are trying to copy the file while someone is writing to the file, I think the best you can do is detect the problem and try again. ... View more

Here's an example of the refline hack I mentioned.  Looks like SGPLOT is happy to draw a 0 thickness refline.   proc sort data=sashelp.class out=class ; by age ; run ; proc sgplot data=class ; series x=age y=height ; series x=age y=weight /y2axis; refline 0 /axis=y2 lineattrs=(thickness=0) noclip; *force y2 axis to extend to 0 ; run ; ... View more

I agree with Paige, I would calculate the minimum Y2 value in the data, and if that value is greater than 0, add the y2axis min=0 statement.   If you really don't want to do that, a possible hack would be to add an invisible (meaning 0 weight, or white) refline on the Y2axis at 0.  You would use the /noclip option on the refline to force the y2axis to extend to show the refline.  But that would feel like more work, and more obfuscated code, than conditionally generating the axis statement. ... View more

Can you make a little example, showing the data you have, and the desired output.   Your SQL code will error because you have the option NOSQLREMERGE but the select * will trigger a remerge.  If you change the SELECT statement to select only ID and aggregated variables, your code looks reasonable to me.     Are you trying to create a new variable that is not shown in your code?     data have ; input ID cause_any_inj nat_any_inj; cards ; 1 0 1 1 1 1 2 0 1 2 0 1 ; proc sql noremerge; create table want as select ID ,sum(cause_any_inj) as cause_inj_cnt ,sum(nat_any_inj) as nat_inj_cnt from have group by ID ; quit ; proc print data=want ; run ; ... View more