As gotcha’s go, this was a good one!

We had a report being generated with dates that were inconsistent with the source file (MMDDYY instead of DDMMYY), but only for certain records.  This was definitely related to the ANYDTDTE. informat, but the strange thing was - this issue only occurred when the report was generated by the Stored Process Server (it was fine in batch).

The ANYDTDTE. informat is driven by the locale setting but as per the chain of sasv9.cfg files we had -LOCALE en_GB defined for both servers.  So I checked the logs, and found something interesting..

One of our STP applications can be triggered from either Excel or a browser.  I could see that the same user had triggered two requests, less than a minute apart, one from excel and one from a browser (as evidenced by the value of the _HTUA variable)

Yet one session had _USERLOCALE=enUS and the other had \USERLOCALE=en_GB!!

As it turns out, the locale for a Stored Process session can change according to the context of the client - as described in this usage note.

So the fix is simply to add the following code (as per your desired locale):

options locale=en_gb;

But where?

I tried fixing this via the autoexec, but this had no effect (likely because the server is running before the request arrives) so instead I added it to the stp init program - which worked a treat. I recommend adding this to your init program, unless you really do want your outputs to change according to the locale setting of the client application!