This is one that comes up frequently with new Enterprise Guide users. A key concept in EG is that although you are running EG on your windows desktop, the SAS software that is actually executing the SAS code may or may not be running on your desktop. Enterprise Guide is designed to work with SAS instances both on your desktop and on remote servers. In your case, because you're receiving diagnostics with directory names that look like "/sas/sas94/config/Lev3/SASApp", I can tell you that your SAS code is running on a Unix server. That means that i) you'll need to provide library and file references using Unix syntax instead of Windows and ii) you'll need to know what directory locations you can write to. There should be a SAS administrator at your organization (who installed and supports all this stuff), and they should be able to provide advice about how the environment is set up. Tom ... View more

: FWIW, I would leave the commas in.  Your error message appears to be a sybase error and, according to its documentation, commas are supposed to be used.  In SAS, itself, they don't have to be there in either the data step or proc sql, but will work either way. What it looks like you are missing, though (from the code you posted), are the parentheses. I don't have access to sybase, but the following runs correctly on sas: %LET Amantadi = '17520','17521','17530'; %LET Rimantad = '00730'; %LET Tamiflu = '98980','98981','26729','73441'; %LET Relenza = '92221'; data have;   input CGNs $;   cards; 26729 15217 00731 00730 26000 26729 ; data want;   set have;   where CGNs in (&Amantadi,&Rimantad,&Tamiflu,&Relenza); run; proc sql;   create table want as     select *       from have         where CGNs in (&Amantadi,&Rimantad,&Tamiflu,&Relenza)   ; quit; ... View more

Hi:   Did you look at the screenshot that I attached to my other post? https://communities.sas.com/message/139542#139542   I used TAGSETS.EXCELXP in that posting example. And you can see that my justification worked in those outputs. So somehow I believe the interaction of absolute_column_width that you have and width_fudge are probably preventing the justification from being what you want. If you run my very simplified code, do you see justification changes? If so, then you need to add suboptions very carefully.   Also, in my response to your other posting, I put (at the top), a Tech Support note that explained the TITLE behavior. I believe the fix is to use PAGEBY, but my suggestion is that you read the Tech Support note that I posted and these other notes, too: http://support.sas.com/kb/43/559.html http://support.sas.com/kb/46/621.html http://support.sas.com/kb/45/204.html http://support.sas.com/kb/38/198.html If you continue to have problems with TAGSETS.EXCELXP and you can't get it working, your sub-options may be at fault -- they could be specifying incompatible settings. I generally recommend starting over with no sub-options (such as I showed in my screen shot) and then add sub-options until they either work or a sub-option "breaks" -- then you have 1 specific thing to ask of Tech Support. cynthia ... View more

Hi:   ODS LISTING, if you use SAS Display Manager in interactive mode, is the same thing as the Output Window. If you use SAS Enterprise Guide, then LISTING is the choice for Text Output. The LISTING destination is the original way that SAS output was delivered.   In the old mainframe days, we used to call it SYSOUT, because it was the way we referred to "system output". And so in Job Control Language (really the old dinosaur era of SAS), the statement to send your output directly to a printer was something like: //SYSOUT   DD    SYSOUT=A   In those old days, there was no ODS. So the only way your output could be produced was on a printer, where every character used the same amount of space on a page (which was a physical piece of paper) -- that's why LISTING controls for DATA _NULL_ like PUT @1 name @32 department @54 salary; were first invented - -because in the printer world there weren't any proportional spaced fonts.   The LISTING destination is useful when you want to test code before you send it to ODS -- let's say you have some complex logic to work out and simple, (ugly) PROC PRINTs will verify that you have the correct logic working, but won't have the overhead of needing any additional ODS statements to answer the "is my logic correct" question. Or, your boss calls up and says "Quick, how many vendors do we have in Spain?" You don't need to create an ODS file to answer that question.   Depending on your version of SAS, the LISTING window could be turned on automaticall (9.1.3, 9.2) or could be turned off (9.3). Also, if you use SAS Enterprise Guide, then LISTING is off, by default and either HTML or SASReport XML is turned on by default.   When I write ODS code, I generally put housekeeping statements: ODS LISTING CLOSE; <all my other code> ODS LISTING; around my program because I want to turn off the LISTING window before I start and turn it back on when I'm done. And I do that because I do a lot of complex program development where I am testing logic and I use LISTING for that. Then when my logic is "cooked" I send my output to ODS HTML, ODS RTF or ODS PDF.   So, I can't really say that LISTING is an option. Using the LISTING destination is just one way of working with SAS. Now that you understand what it means and how it's used, you can experiment (or not). Most folks these days of SAS 9.3 and Enterprise Guide take all the defaults and they are happy that they never have to deal with the LISTING output or the LISTING window (plain text output is very plain and not as nice looking as ODS output). But you should at least understand what the control statements are and that you don't, usually, need to worry about them.   cynthia ... View more

Hi:   I recommend that you change your invocation as shown below. With 2 ODS PDF statements, as you show, the NOTOC option in the FIRST statement was essentially begin ignored or NOT being used by the second invocation where you had FILE=. So it's better to put ALL the options on the  same invocation for the FILE=. cynthia ODS PDF FILE="C:\TEMP\WIDE CLAIMS.PDF" style=custom notoc;     TITLE "WIDE  CLAIMS  RECORD  TOTALS  FOR  &CKDATE  CHECKWRITE"; FOOTNOTE "REPORT  ON  &SYSDATE9."; PROC PRINT DATA = RWORK.WIDECLAIM NOOBS LABEL; RUN; ODS PDF CLOSE; ... View more

Hi:   Look at the attached screenshot. It is quite colorful and I made the cells all a bit wider so you could see the exact impact of the various JUST= and some of the other options and style overrides that I used. And then I made the DESC column smaller so you could see the justification happened for the entire cell. The code in the second screenshot (for PROC PRINT) is what I used to produce this output, since you did not say what procedure you were using. I only put a few obs into the dataset because I didn't have much time.   At any rate, PROC REPORT can put STYLE= overrides in the PROC REPORT statement, the DEFINE statement, the BREAK and RBREAK statements, the COMPUTE statement. There are a lot of previous forum postings about using STYLE= overrides. These techniques work with PROC PRINT, PROC REPORT and PROC TABULATE. The doc on each procedure has good information on using STYLE= overrides. There are a few differences between PRINT and REPORT. PROC REPORT uses STYLE(COLUMN) instead of STYLE(DATA) and since PROC REPORT doesn't have a VAR statement, you would use your style override in a DEFINE statement for each variable or report item.   The PROC REPORT doc is very good and there are a lot of good examples on how to write PROC REPORT code and use STYLE= overrides. cynthia ... View more