EG8, options NOFMTERR, and submission status errors

[PhilC]

I found out that EG creates an error status in the submission status if the log shows a : "NOTE 484-185: Format XXXX was not found or could not be loaded."  despite option NOFMTERR was in effect.

1. Is this because the format is underlined as if it is when an error occurs?

2. Is this behavior broken and can we expect it to be changed?

--EDITED--

I believed the EG was designed to report "Errors" when the SAS log designated SAS "Errors". If someone wants the put statement to not present an error, then they use option NOFMTERR, but if they are also using EG, then the use of option NOFMTERR is insufficient because they will still have to deal with their code being interrupted in EG because it interprets errors differently. This realization was counter intuitive to me. A "Note" can be an "Error". It seems that EG designers have a different philosophy of what a SAS error is. And so, if that's ok with everybody, its ok with me.

It does, in a way, force people to stop using NOFMTERR which is good coding practice, and in my case I recently found this format related error in code I didn't expect to, which enforced this lesson to not use NOFMTERR. So I'm thankful for this difference in philosophy, for the moment.

I'm not thankful because now I have to remember that they are not equivalent; I think I'd prefer the simplicity of EG calling an "Error" an "Error" if and only if SAS says explicitly there's an "Error".

[unison]

Not seeing an error in my E.G.8

Just to be sure, verify the options are set as expected

%macro show(opt=);
%put Current setting for &opt : %sysfunc(getoption(&opt));
%mend;

options nofmterr;
%show(opt=nofmterr);
%show(opt=fmterr);

/*...your procedure/data step...*/

options fmterr;
%show(opt=fmterr);
%show(opt=nofmterr);

[PhilC]

you're right @unison 

Its good that I illustrate this.

/*options  FMTERR;*/
options  noFMTERR;

data _Null_;
  x= put (y,gobble_dee_guk.);
  stop;
run;

This code becomes an error to Enterprise Guide's Submission status despite the use of FMTERR or NoFMTERR:

29         options  NoFMTERR;
30         
31         data _Null_;
32           x= put (y,gobble_dee_guk.);
                       _______________
                       484
NOTE 484-185: Format GOBBLE_DEE_GUK was not found or could not be loaded.

33           stop;
34         run;

NOTE: Variable y is uninitialized.
NOTE: DATA statement used (Total process time):
      real time           1.11 seconds
      cpu time            0.03 seconds

29         options  FMTERR;
30         
31         data _Null_;
32           x= put (y,gobble_dee_guk.);
                       _______________
                       48
ERROR 48-59: The format GOBBLE_DEE_GUK was not found or could not be loaded.

33           stop;
34         run;

NOTE: The SAS System stopped processing this step because of errors.
NOTE: DATA statement used (Total process time):
      real time           1.01 seconds
      cpu time            0.04 seconds

[SASKiwi]

@PhilC  - My understanding is that this option is primarily designed to deal with processing of datasets that contain a non-existent format permanently assigned to a variable. It isn't designed to prevent errors when you explicitly try to apply a non-existent format in a PUT statement. I can't find any mention of this distinction in the documentation though:

https://documentation.sas.com/?docsetId=lesysoptsref&docsetTarget=p1djbl02hfnoe3n0zh2i3uu2aqrf.htm&d...

[ballardw]

---

@PhilC wrote:

I found out that EG creates an error status in the submission status if the log shows a : "NOTE 484-185: Format XXXX was not found or could not be loaded."  despite option NOFMTERR was in effect.

1. Is this because the format is underlined as if it is when an error occurs?

2. Is this behavior broken and can we expect it to be changed?

---

That is not an error. It is informational that you have something attempting to use a format that the current session can't find. If it were an error you would see ERROR:

This note is similar to the

NOTE: Character values have been converted to numeric values at the places given by:

that results from SAS doing the best it can by converting a character variable for some purpose where you requested a numeric operation.

If the main issue is not having a clean log then you either need to make sure that a format of that name is in the current format search path, remove the reference to the format, remove the format from variables with that default format or more drastically remove the variables.

[PhilC]

@ballardw 

My EG submission status is "successful" for this code.   

data _Null_;
  length x 8;
  x= "5";
  stop;
run;

31         data _Null_;
32           length x 8;
33           x= "5";
34           stop;
35         run;

NOTE: Character values have been converted to numeric values at the places given by: (Line):(Column).
      33:6   
NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.00 seconds
      

[ballardw]

---

@PhilC wrote:

@ballardw 

My EG submission status is "successful" for this code.   

data _Null_;
  length x 8;
  x= "5";
  stop;
run;

31         data _Null_;
32           length x 8;
33           x= "5";
34           stop;
35         run;

NOTE: Character values have been converted to numeric values at the places given by: (Line):(Column).
      33:6   
NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.00 seconds
      

---

Exactly my point about your original post. Your subject line says "submission status errors" but the text of your original post says you are getting a Note. Notes allow the data to run but warn you that the result may not be as expected. Errors will stop the procedure or data step from executing.

Further example:

1111  options nofmterr;
1112  data _Null_;
1113    x= "5";
1114    put x $notaformat.;
              ------------
              484
NOTE 484-185: Format $NOTAFORMAT was not found or could not be loaded.

1115  run;

5
NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.01 seconds


1116  options fmterr;
1117  data _Null_;
1118    x= "5";
1119    put x $notaformat.;
              ------------
              48
ERROR 48-59: The format $NOTAFORMAT was not found or could not be loaded.

1120  run;

NOTE: The SAS System stopped processing this step because of errors.
NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.00 seconds


1121  options nofmterr;

My thoughts is that format errors should receive a WARNING instead of Note, but that's just me.

[Patrick]

@PhilC 

What you get in the SAS log is what the SAS Server returns. That's independent of the client. You'll get the same SAS Log message whether you run the code out of SAS EG 7 or 8 or SAS Studio or "PC SAS" or whatever.

I believe SAS EG somehow scans the SAS Log the SAS Server returns and if it finds anything in the SAS log that looks like an error message it sets the Program Icon to "Error".

EG 7: 

EG 8: 

Looking at the SAS Log generated even when using option NOFMTERR which causes SAS to not raise an error condition and to only write a Note and not an Error message to the log, you still get below bit:

Above code ended with no error condition and no Error message has been written to the SAS log. But the EG UI (version 7 and 😎 still uses a job icon of error. It appears EG somehow scans the SAS log for patterns like the 484 entry and uses the error job icon if it finds one. That's not perfect but also nothing which changed with EG 8.

All the rest shows the correct outcome. The server side generated SAS log gives you the right message and also the SAS EG Error pane doesn't report an Error if NOFMTERR is set (both in EG 7 and 8).

 

[PhilC]

I believed the EG was designed to report "Errors" when the SAS log designated SAS "Errors".  If someone wants the put statement to not present an error, then they use option NOFMTERR, but if they are also using EG,  then the use of option NOFMTERR is insufficient because they will still have to deal with their code being interrupted in EG because it interprets errors differently.  This realization was counter intuitive to me.  A "Note" can be an "Error".  It seems that EG designers have a different philosophy of what a SAS error is.  if that's ok with everybody, its ok with me.

It does force people to stop using NOFMTERR which is good coding practice, and in my case I recently found this format related error in code I didn't expect to, which enforced this lesson to not use NOFMTERR.  So I'm thankful for this difference in philosophy, for the moment. 

I'm not thankful because now I have to remember that they are not equivalent; I think I'd prefer the simplicity of EG calling an "Error" an "Error" if and only if SAS says explicitly there's an "Error".

[Tom]

It would be helpful to know exactly what EG is using to set that error status.  Are they really scanning the log? Or is there some macro variable (or other status indicator) that it is checking?

[ChrisHemedinger]

Copying my response from the related SASWare Ballot suggestion:

If you run this same program in SAS for Windows, you'll get a similarly formatted log -- that is, the underscore and "484" lines will be colored red, indicating that SAS has applied the "error" treatment to this information in the SAS log.

EG picks up on that cue when it shows whether the SAS log has errors.  SAS actually "decorates" each log line with a 2-byte prefix (which you don't see) to indicate how to color the line.  It's not relying on the word "ERROR" nor automatic macro variables -- neither of those are reliable in all cases.

So, I think this is maybe a bug (or just the way it works) for this condition in SAS.  Using an undefined format is considered an error...unless you have the option NOFMTERR set, in which case SAS "gives it a pass."  But....apparently it's still going to be passive aggressive about it and mutter "still an error though" under its breath.

In summary, EG isn't "making up" rules about what it considers an error.  If the SAS log contains lines that are tagged/prefixed as error lines, then EG indicates that there were errors in the log summary and process flow. That's a step beyond traditional SAS, where the text of the log would have been the only indicator -- and so this situation wouldn't have drawn attention.

[PhilC]

@ChrisHemedinger ,

You are suggesting that this is a SAS issue where we should ask for the 484 error code not to be colored red only, or both change the color of error code 484 and the behavior of EG?

[ChrisHemedinger · Accepted solution]

Not exactly.  We don't need EG or other clients to make a change, just the SAS process that generates the log content.

When NOFMTERR is in place, these lines in the SAS log should be prefixed with the NOTE code (a 2-byte prefix) instead of the ERROR code.  Then EG (and other clients) would color as a NOTE and not trigger as an ERROR.

In fact, I see that this problem has also been tracked internally as a bug for DATA step -- so it's already known.  However, no fix is planned as it was found internally and no customers have reported it.  The behavior has likely been like this for a long time.

If you would like to report it as a customer, I suggest that you reference this thread so we have the discussion.  I'll update the case in our tracking system.

[Tom]

I suspect that no end user has reported it as I cannot even think of a way that an end user could get access to that special two byte prefix on the lines of text in the SAS log that EG is checking.

[ChrisHemedinger]

@Tom Oh, yes, of course.  What I mean is I can't find a customer bug or case on file...outside of this discussion topic...that reports the symptom of seeing a flagged error when there was no true ERROR present, specifically around this case with NOFMTERR.  The root cause is the log cues that SAS generates, but I wouldn't expect end users to ferret that out.

I've updated the tracked bug that was reported internally.  If customers also report the issue to Tech Support and request it to be prioritized, I know that the teams will look at it again -- but of course I cannot promise a fix or a time frame for it.