× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 7/14/2014 11:27 AM, Steinmetz, Paul wrote:
Rob,

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

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Monday, July 14, 2014 10:30 AM
To: Midrange Systems Technical Discussion
Subject: RE: compiling CLP with RUNSQL statement to previous release V6R1

IBM's RUNSQL command came out with certain PTF's.
It exists in QSYS
DSPCMD RUNSQL
Command . . . . . . . : RUNSQL Library . . . . . . . : QSYS

Program to process command . . . . . . : QSQSCHEM
Library . . . . . . . . . . . . . . : QSYS

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.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 07/14/2014 10:09 AM
Subject: RE: compiling CLP with RUNSQL statement to previous
release V6R1
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



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.

RUNSQL *PGM DCXPGMLIB CLE LANSA runtime object - /PC=
RUNSQL *PGM DPISPLPAL CLP Process SQL commands using
RUNSQL *CMD DPISPLPAL Process SQL commands using
RUNSQL *QMQRY DPISPLPAL QUERY MGR Query Definition for RUNSQL
RUNSQL *PGM IC08XXPGMS CLP Process SQL commands using
RUNSQL *CMD IC08XXPGMS Process SQL commands using
RUNSQL *QMQRY IC08XXPGMS QUERY MGR Query Definition for RUNSQL
RUNSQL *PGM JOBSHOP CLP Process SQL commands using
RUNSQL *CMD JOBSHOP Process SQL commands using
RUNSQL *QMQRY JOBSHOP QUERY MGR Query Definition for RUNSQL
RUNSQL *PGM QMGTOOLS RPGLE Run SQL statements
RUNSQL *CMD QSYS Run SQL Statements
RUNSQL *PGM SYS CLP Process SQL commands using
RUNSQL *CMD SYS Process SQL commands using
RUNSQL *QMQRY SYS QUERY MGR Query Definition for RUNSQL
RUNSQL *CMD VSIMGDSP

Thanks
Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Paul Nelson
Sent: Monday, July 14, 2014 8:51 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: compiling CLP with RUNSQL statement to previous release V6R1

Wait, WHAT??????????? :-)

That was the vendor who would previously remain nameless, but now that
their previous owner decided to abandon the iSeries construction software
space, I can reveal the name:

Computer Guidance Corporation in Phoenix.

How long has RUNSQL been out? They still haven't fixed the issue.

Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Monday, July 14, 2014 7:34 AM
To: Midrange Systems Technical Discussion
Subject: RE: compiling CLP with RUNSQL statement to previous release V6R1

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...

Paul's choice.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Briggs, Trevor (TBriggs2)" <TBriggs2@xxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 07/14/2014 08:14 AM
Subject: RE: compiling CLP with RUNSQL statement to previous
release V6R1
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



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.

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Monday, July 14, 2014 6:36 AM
To: Midrange Systems Technical Discussion
Subject: Re: compling CLP with RUNSQL statement to previous release V6R1

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?


Rob Berendt



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.