Re: new IBM RUNSQL command

Joel,

Command name collision can certainly be a concern though I'm not sure that
I would want IBM to start deviating from their current command naming
approach.

It's been a long standing convention for IBM command names to follow a verb
+ noun (or verb + modifier + noun) convention when coming out with IBM
provided commands, and RUNSQL certainly fits that description (with
precedents for both the verb RUN and the noun SQL). The verbs IBM is likely
to go with can be found
here<http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rbam6/intcmdverb.htm>,
with all the various abbreviations used documented
here<http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rbam6/intcmdab.htm>
.

What makes more sense to me is for non-IBM developers, who are following
the verb-noun approach (which I certainly recommend in order to maintain
the system's look and feel) and therefore exposed to possible conflicts
with future IBM provided commands, to add a name qualifier. For instance
with my Control Language for Files (CLF) product I used command names such
as READRCDCLF, UPDRCDCFL, WRTRCDCLF, and DLTRCDCLF for the functions of
read, update, write, and delete respectively. Likewise my eXtreme CL (XCL)
product uses the command name DSPDTAQXCL to display various *DTAQ entries.
I did this years ago just in case IBM ever added a command to delete a
database record or display a *DTAQ -- in which case I would fully expect
their commands to be along the lines of DLTRCD and DSPDTAQ. And even if the
command provider doesn't provide such a qualifer, you can (at least with
any of the more recent releases) with the Create Proxy Command (CRTPRXCMD).

Alternatively, when someone comes out with a command that is named "just
like IBM would have" (which should be your first warning...) you could,
when using the command, always library qualify the usage to the library
where the command can be found. The approach of library qualifying command
access however is NOT one that I'm very keen on. It's easy enough to do but
has implications that I don't care for -- disabling of command translations
by way of the library list, restrictions in the area of command analyzer
change exits, etc.

Neither of the above suggestions however will do you much good if you
already have a non-IBM RUNSQL command that you are using (and that you
haven't already taken a command proxy and/or library qualified approach
to). In that situation my first thought is to put a user library into the
system library list (prior to QSYS or any QSYS national language version
(NLV) instances) and, in this user library, put the non-IBM RUNSQL command.
This should allow existing applications to continue running, giving you
some breathing room to change current application usage of the non-IBM
RUNSQL command to either a proxy-based approach or a library qualified
approach.

I hope this helps (and I'm glad you enjoyed the article),
Bruce Vining


On Fri, Mar 30, 2012 at 10:15 AM, Stone, Joel <Joel.Stone@xxxxxxxxxx> wrote:

http://www.mcpressonline.com/cl/the-cl-corner-introducing-the-new-run-sql-command.html

Thanks for the great article Bruce!

One question - hundreds of custom RUNSQL type commands have been
custom-built at hundreds of iseries shops over the years.

These commands are used in production.

How can shops ensure old CL runs will continue to call their home-grown
RUNSQL command (instead of the new IBM RUNSQL command?)

This will surely cause havoc in many shop, as parm names will not match
and abends will occur in production jobs, some without source (for
packages, etc).



Many Iseries articles have been published over the years for a home-grown
CL SQL command, and most have used "RUNSQL" as the command name.

Shouldn't IBM pick another name, so as not to cause hardship with so many
users?

I know other vendors were smart enough to name their SQL commands
something different than "RUNSQL", probably to avoid just this scenario.

If IBM introduced this command in the last century like other vendors, I
can understand them grabbing the obvious command name.

But decades late to the party, shouldn't they be cognizant of identical
command names in the iseries user community and name it something else?

EXECSQL, CALLSQL, DOSQL, RUNIBMSQL, INVOKESQL, RUNSQLI, or million other
variations.

Tell me why this is not a concern, please, and I will go "oops". But I
have introduced this command in shops code and don't want stuff to be
croaking because parm names don't match up.



______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs
Skyscan service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
--
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.