Initialize / activate SQL prior to GET DIAGNOSTICS

Question

I have two service programs: mySrvPgm and myErr

mySrvPgm has a procedure which contains:

/free
  ...
  exec sql INSERT INTO TABLE VALUES(:RECORD_FMT);
  if sqlError() = *ON;
    //handle error
  endif;
  ...
/end-free

myErr has a procedure sqlError:

/free
  exec sql GET DIAGNOSTICS CONDITION 1 
    :state = RETURNED_SQLSTATE;
  ...
/end-free

Background info: I am using XMLSERVICE to call the given procedure in mySrvPgm from PHP. I am not using a persistent connection. myErr is bound-by-reference via a binding directory used by mySrvPgm. Its activation is set to *IMMED, its activation group is set to *CALLER.

The problem: Assume there is an error on the INSERT statement in mySvrPgm. The first time sqlError() is called it will return SQLSTATE 00000 despite the error. All subsequent calls to sqlError() return the expected SQLSTATE.

A workaround: I added a procedure to myErr called initSQL:

/free
  exec sql SET SCHEMA MYLIB;
/end-free

If I call initSQL() before the INSERT statement in mySrvPgm, sqlError() functions correctly. It doesn't have to be SET SCHEMA, it can be another GET DIAGNOSTICS statement. However, if it does not contain an executable SQL statement it does not help.

The question: I believe the myErr service program is activating properly and has the correct scope, but I am wondering if there is something more I need to do to activate the SQL part of it. Is there some way to set it up so SQL auto-initializes when the service program is activated, or do I have to execute an unneeded SQL statement in order to get it started?

There is some more background information available here.

Thank you for reading.

Answer 1

What version an release of the OS? Are you upto date on PTFs?

Honestly, seems to me that it's possibly a bug. Or the manual(s) need clarification.. I'd open a PMR.