if you run: proc contents data=have (keep=Syndrome_1 Syndrome_2); run; proc freq data=have; tables Syndrome_1 Syndrome_2 ; format Syndrome_1 Syndrome_2 ; *remove any formats attached to the variables; run; What do you see?    It sounds like the variable type is numeric.  If that's the case typically you would have a format which maps each numeric code to a text string, something like: proc format; value Syndrome 1="Weight gain" 2="Other clinical signs" ; run; Do you have a format like that? ... View more

@yabwon wrote: In fact the sorting is very reason why implementing request of adding functions to merging is not "doable" in general case. Sorted data (ready for MERGE) after applying a function can be not MERGEble anymore. Ahh, that makes sense.  Definitely not implementable in MERGE. Thanks again. ... View more

Amazing @yabwon , so creative, as always! ... View more

Thanks @DanH_sas .  I tried again with width=10in height=7in today and it worked.  I'm pretty sure I was testing in a fresh session yesterday, so not sure how I managed to muck it up. ... View more

@sbxkoenk wrote: Try using these options on the panelby statement (behind the forward slash): LAYOUT=panel columns=4 novarname Koen That gives a single row with 4 columns, and uses the whole page correctly:     But I want a single column, with two rows. If I use Layout=panel columns=1, I'm back to having an image half the width of the page:   ... View more

No, you cannot do it in the MERGE step.     The MERGE statement reads the key values from each dataset, then decides which record(s) to read into the PDV.   You cannot use an expression on the BY statement.   Edit:  I was going to write that it's not possible to modify the key value before it is read by the  BY statement, because the data would need to be read into the PDV first.   But the WHERE statement is happy to modify key values before they are read into the PDV, so you can do stuff like: where upcase(category)='FOO'.  So theoretically the BY statement could allow you to manipulate the key values before they are compared.  But I don't think we're likely to see that added as a new feature. ... View more

Thanks for the thought Dan.     When I try e.g. width=10in height=7in  the plot is empty and the log tells me: Cell height -34 is smaller than the minimum cell height 1. All contents are removed from the layout. Cell height -34 is smaller than the minimum cell height 1. All contents are removed from the layout. ... View more

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