If I tried running IBM's version of RUNSQL, from our apps, will something probably fail?

Yes, probably. The chances that the 3rd party RUNSQL parameters exactly
match the IBM RUNSQL parameters is vanishingly small.

Based on your PTF comment, is this one of those mid release commands, V6R1 and V7R1 only.
That could be why it's failing for compile previous release.
I don't think IBM supports previous release for commands that come out mid release.

Exactly.

I found and read your article.http://www.itjungle.com/fhg/fhg053012-story01.html
I hate when I run into these situations, they are scary, it reminds me of the CPYTOIMPF issues.
I think it broke when we upgraded from V5R4 to V6R1 back in 2011.
That's when we copied our version in front of IBM's version.
I really don't want to touch this right now. Everything is working, but there is mess that needs attention.

I think there are several options:
1) Rename the IBM command
2) Put the 3rd party command above the IBM command - does not handle
qualified calls and requires diligence during 3rd party upgrades.
3) Rename the 3rd party commands and all the instances in your CL -
requires diligence during 3rd party upgrades.
4) Qualify all the 3rd party commands in all the instances of your CL
5) Write a wrapper command for the 3rd party command. Call it something
like RS and have it make a qualified call to the 3rd party command.

I chose option 5. I didn't have to make copies (easier on future
upgrades), tinker the system library list or worry that the 3rd party
vendor will rename their command on me. If they do, I make one change
in one program and I'm done.
--buck

There's two major issues with it, and the third party products that came out.
The first being the parameter names have changed. This is the #1 killer with imbedded versions of RUNSQL. The first parameter in the IBM version is SQL. The first parameter in other versions may be REQUEST or some such thing.
The second major issue is that the IBM one will not let you do a simple SELECT.
RUNSQL SQL('select * from routines/dskdtl') SQL statement not allowed.

Another issue is that the IBM version defaults to running under some sort of commitment control so you often have to RUNSQL SQL(...) COMMIT(*NONE) If you're not journalling, or you do not want to forget to 'commit' your changes.

I'd like confirmation on RUNSQL cmd.
We have many versions of the RUNSQL command, many 3rd party apps include
it with their software.
I remember years back something broke with RUNSQL during some upgrade.
I don't remember the details, but I think that is why we have a version in
our SYS library (System Override commands)
The current version is being called is from our SYS library, which calls
CLP PGM RUNSQL, and QMQRY.
IBM's version calls QSYS/QSQSCHEM, not ever used.

Maybe not in this case, but they can be relevant, even with a different
target release. Think about it.
If the 6.1 machine never had the ptf installed that gave them RUNSQL, or
If the 6.1 machine was ran by Paul Nelson who didn't want to rewrite his
code to use IBM's RUNSQL options...

All valid points, Rob, but surely these don't affect the compiling of a
program with a different target release? After all, when compiling a
program on System A which is eventually to be run on System B, the two
systems don't even have to be connected.

There's always a lot of "if's" when compiling for a different system:
- Is the target system current on PTFs?
- Does the target system have that option? (not germane to this exact
issue)
- Does the target system have a persnickety admin who keeps deleting or
renaming the IBM issued RUNSQL so that his code will continue to use a
home grown one? Thus discouraging all his customers to keep current on
PTF's?

This mailing list archive is Copyright 1997-2016 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact