We use RUNSQLSTM in production code. Not often, but we do (and it's generally not critical). We also use STRQM in production code as well (more often than RUNSQLSTM, though again not very often). I'm sure both methods would go away once we get the RUNSQL ability in CL. (Admittedly - I attempted to get the PTF for it and failed. Not sure what I did wrong, but didn't have the time to pursue it.)
We also store SQL Server SQL in members that RPG programs will pick up, parse, and pass down to SQL Server for it to run. In this case, we have a service program that will wrap a try/catch around every statement it sends. Errors get sent to an error log file.
I've recently been adding error handling into our stored procedures that output errors to a log file. You could add error handling to the SQL that RUNSQLSTM runs, having it output to an error file, but then your CL would need to go to that file to check for an error.
I would agree that RUNSQLSTM is probably not the wisest approach. See if you can get RUNSQL on your system.
-Kurt
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Robert Clay
Sent: Thursday, March 28, 2013 2:03 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RunSQLStmt in production
Do you use RunSQLStmt in production environment?
Our team is beginning to use it more and more on a 6.1 system and I am curious as to the intelligence of using it as opposed to SQLRPGLE programs and imbedded/static SQL statements where one can logically trap for errors using SQLSTATE and GET DIAGNOSTICS, etc.
Your thoughts? Can you think of reasons pro or con?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
