retain program formatting in log

[tomrvincent]

I format my code like this:

 create table DischargeForm   
     as

    SELECT

        masd.ENC_IDN,
        masd.MBR_IDN,
        masd.ACTUAL_PLANNED_DISCHARGE_DATE,
        masd.ADDED_DATE,
        masd.UPDATED_DATE
    FROM DISCHARGE masd;

yet it appears in the log as

create table DischargeForm as SELECT masd.ENC_IDN, masd.MBR_IDN, masd.ACTUAL_PLANNED_DISCHARGE_DATE,
masd.ADDED_DATE, masd.UPDATED_DATE FROM DISCHARGE masd;

It would be nice if the log retained the original formatting of the code, especially for code that's a lot more complex than this example.

[paulkaefer]

I strongly suspect this is because the log output is after the code has been tokenized (i.e., parsed by SAS, hence ignoring extra whitespace, etc.). However, this would be a great system option. I agree, it would be much more readable.

[ballardw]

I think you may need to provide a little more detail as to how you are running and your environment.

For instance in the classic display manager when I run code formatted as:

data example;
   do method = 0, 1, 2, 120;
   output;
   end;
run;

The log looks like:

9    data example;
10      do method = 0, 1, 2, 120;
11      output;
12      end;
13   run;

Which is what I see for much longer code.

If you are extracting code from an EG code node or similar I would not be surprised that EG tokenizes code differently when executing. Or if the code is submitted to a server similar tokenization may take place.

So some help as to what environment needs to be addressed may be in order.

[paulkaefer]

Good points, @ballardw. I ran a couple of examples and agree with you. It did look like formatting was slightly off if there were tabs instead of spaces (something I definitely have feelings about). But otherwise, it seemed to match my formatting. Even if the job was run via the command-line, the log retains my formatting.

Yes, using stored processes or other graphical nodes may impact this.

[ballardw]

The tabs issue I sort of fix by setting the editor to replace tabs with the settings "Insert spaces for tabs" and "Replace tabs with spaces on file open" and a small tab size. I probably should have remembered to mention that.

[tomrvincent]

I don't think the environment should matter.  The log should reflect the code as it was defined and not compress it into a less readable format.  My example shows one field per line, not the 3 fields per line shown in the log.

[Tom]

The SAS log already retains the format for code in your SAS program.

656   proc sql;
657   create table want as
658     select name
659          , age
660     from sashelp.class
661   ;
NOTE: Table WORK.WANT created, with 19 rows and 2 columns.

Perhaps you are using some form of code generation? Such as a SAS macro?  Or pass thru SQL?

[tomrvincent]

It doesn't, as my initial example shows.  No code generation...just straight code.

[Tom]

How did you get Enterprise Guide to send that code to SAS to run? 

Was it a simple CODE node?  Or something else?

The problem with EG is that you are not actually directly running SAS. Instead EG is communicating with SAS.

But they should be able to get it to work.  it works in SAS/Studio which also does not directly run SAS code.  

 1          OPTIONS NONOTES NOSTIMER NOSOURCE NOSYNTAXCHECK;
 INFO: Character variables have defaulted to a length of 200 at the places given by: (Line):(Column). Truncation can result.
       40:1     RC
 72         
 73         proc sql;
 74         create table want as
 75           select name
 76                , age
 77           from sashelp.class
 78         ;
 NOTE: Table WORK.WANT created, with 19 rows and 2 columns.

[tomrvincent]

Just a standard 'run', nothing fancy.

I wouldn't say it's a 'problem with EG', just how SAS implemented it. 

I wish it would handshake with Windows correctly, but that's a different request.  This suggestion is simply that the log reflect the original code, nothing more than that.