You can store your queries in a source member (length of source area=79, total record length 91). Then use the command CRTQMQRY to generate the executable query object (*QMQRY).

To work with QMQRY, use the menu STRQM, then option 1 to get into generating a query. Option 10 to change your user options.

Once a query is defined, you can execute it from a CLP using the command STRQMQRY. The command has options to pass in variables to make it a little more dynamic.

So, you would probably have two QMQRY’s. The first would define the procedure. That one would contain the CREATE PROCEDURE statement you used to generate the *PGM object. That would only need to be done to save the source of the procedure better than your options with STRSQL.

The second would contain the CALL PROCEDURE statement that would be equivalent to executing the procedure from within STRSQL.

Tried strmqmqry, however was able to find how to store the output of the sql.

Can you give us a sample QMQRY.

Await your reply.
Johnson

When I originally replied to that forum a couple years ago, it was about a slightly different problem. However, that thread does indeed contain a possible useful item — using a QM query to issue the CALL.

Since a QM query provides a mostly valid SQL environment, it might help in returning and recording SQL status info as messages in the joblog.

And that’s apparently the crux of this question.

Calling the proc directly from CL potentially loses SQL status info. But issuing STRQMQRY to CALL the proc might be a nicely valid answer here.

Nice catch!

Tom

If your procedures need to return SQL status information, there is no active SQL environment to receive it. Status info would simply be lost in my view of things.

Wrap your SQL procedures inside of SQL CLI calls or call them from programs compiled with embedded SQL. I can’t think of any other possibilities for tracking whatever is happening. If you don’t have the SQL Development Kit to allow compiling HLL SQL programs, you can still code for SQL CLI or issue SQL CALL statements in REXX. (But REXX SQL CALL statements don’t support host variables.)

I’d love to see someone else provide a better answer. Only thing I can suggest is to call the procedures properly if you want proper results.

Tom

From what i understand from you if i call the CLE pgm from an RPG pgm and if there is an error in the CLE pgm i should be able to get a joblog informing of the error.?

Please confirm.

This program object is then called by a CL program.

AFAIK, the resulting CLE program object cannot be directly called successfully from a CL program. It could only be called from a SQL program that was compiled with embedded SQL to run the SQL CALL statement.

You can’t use the CL CALL command for this. There are parts that need to be built into the program by the SQL pre-compiler in order to support the SQL CALL statement properly. There is no SQL pre-compiler for CL.

Your CLE procedure will need to be called from RPG, COBOL, C or another HLL that has SQL compiler support.

Tom

The procedure is saved as a program object with CLE attribute.

This program object is then called by a CL program. I guess you are right the programmer who has written the sql commands needs to log the errors if any within the sql procedure.

CL can’t “submit” procedures. CL can only submit programs. And CL has no support for SQL procedures, even interactively — a HLL program must be called to execute SQL procedures (with exceptions for complex SQL CLI coding in V5R4 and above). Maybe there is confusion over some of the terms.

Therefore, the only reasonable interpretation is that your CL is calling (or submitting) a program that has embedded SQL. The embedded SQL may issue a SQL CALL to a SQL stored procedure.

If the CL calls the program, then any errors should be shown in the joblog of the job that runs the CL. If the CL submits the call to the program, then any errors should be shown in the joblog of the submitted job.

If no errors are found in the job that runs the program, then you need to ask the programmer why he or she did not log errors in the joblog. The programmer is the only one who can explain why there was no coding to log errors. It seems that you are simply calling a program that needs to be changed to include better logging.

Tom