One way would be to put the new version in a library that is lower in the
LIBL then when you want to use the new version qualify it with the library
name. That way nothing that is currently in your production environment
would be affected, only the new apps you write.
From: "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
Date: 03/30/2012 10:12 AM
Subject: new IBM RUNSQL command
Sent by: midrange-l-bounces@xxxxxxxxxxxx
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
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
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
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
For more information please visit http://www.symanteccloud.com