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



That is true, I forgot that QCMDEXEC basically works on the same strings
as a command line. Too many things get paged out of memory over time.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx



From: Vern Hamberg <vhamberg@xxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 10/20/2010 06:43 PM
Subject: Re: passing Call commands (with parms) from program to
program
Sent by: midrange-l-bounces@xxxxxxxxxxxx



You can still get garbage using QCMDEXC with the length correctly set.
This will happen when using QCMDEXC to do a CALL when character
parameters in the program are longer than 32. The system only guarantees
padding with blanks out to the first 32, after that you get what's in
memory - maybe the next few parameters, maybe anything.

This is command-line behavior and is applied when using SBMJOB CMD(CALL
...) or when using QCMDEXC to do a CALL (not that you would ever need to
do that in RPG or in CL!). And if you do use variables in a real CALL in
CL or RPG, and those variables are shorter than the parameters as
defined, same problem.

So that's why I asked Stephen what the lengths were of the various
parameters.

This doesn't happen if you put command front-ends on the programs, or if
you put an extra non-blank character beyond the declared parameter
length, etc. RQSDTA can behave differently, as well, but I never use it
and forget the details.

Vern

On 10/20/2010 3:16 PM, Mark Murphy/STAR BASE Consulting Inc. wrote:
No, the answer is in the diagnostic message. There is a null in there.
You need to pass QCMDEXEC the appropriate length because there is
garbage
in the string after the command.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx



From: "Morgan, Paul"<Paul.Morgan@xxxxxxxxxxx>
To: Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx>
Date: 10/20/2010 12:43 PM
Subject: RE: passing Call commands (with parms) from program to
program
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Stephen,

Try coding your SBMJOB command with:

SBMJOB RSQDTA('your command string with double quotes') ....

Instead of

SBMJOB CMD('a command string which can't have double quotes')
RSQDTA(*CMD)
....

Paul

Principal Programmer Analyst
IS Supply Chain/Replenishment


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Needles,Stephen J
Sent: Wednesday, October 20, 2010 12:12 PM
To: Midrange Systems Technical Discussion
Subject: RE: passing Call commands (with parms) from program to program

Tried this before and it didn't work.

'CALL PGM(PROGRAM_B) PARM(''7100110003'')'

When it wends its way through PROGRAM_X, CallString still looks like:

'CALL PGM(PROGRAM_B) PARM(''7100110003'')'

So far, so good.

Now PROGRAM_Y is submitted via QCMDEXC...

SBMJOB cmd(call PROGRAM_Y ('PROGRAM_B ' '41' 'CALL PGM(PROGRAM_B)
PARM(''7100110003'')')) JOB(DUPPR0CE55) JOBD(*USRPRF) JOBQ(*JOBD)
JOBPTY(3) HOLD(*JOBD)'

Job Fails:

Joblog snipett:

*NONE Request 10/20/10 10:49:35.750214
QWTSCSBJ
*N QCMD QSYS 0195
Message . . . . : -CALL PGM(PROGRAM_Y) PARM('PROGRAM_B
'
'41' 'CALL PGM(PROGRAM_B) PARM(''7100110003'')')

CPD0018 Diagnostic 30 10/20/10 10:49:35.828732
QCANPARS
QSYS 0EFA PROGRAM_B SOMPGMLIB *STMT
To module . . . . . . . . . :
PROGRAM_Y
To procedure . . . . . . . :
PROGRAM_Y
Statement . . . . . . . . . :
18200

Message . . . . : String ' '
contains a character that is not valid.
Cause . . . . . : The string
contains a character that is only valid in a quoted string or a comment.
Recovery . . . : Remove the character that is not valid from string
X'00404040404040404040', or if it is a parameter value, make the string
a
quoted string. More information on valid characters can be found in the
CL
Reference manual.

The DUMP for PROGRAM_Y shows the CallString variable to contain:

PCALLSTRING CHAR(32702) 'CALL PGM(WPSDQP2100)PARM('7100110003') '

I've been here before...if I add another pair of quotes...i end up with
the variable name rather than its contents in the CallString.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan Kimmel
Sent: Wednesday, October 20, 2010 9:53 AM
To: Midrange Systems Technical Discussion
Subject: RE: passing Call commands (with parms) from program to program

Double up your apostrophes here and I think you'll find it works:

D p_contract S 10

c eval Process = 'PROGRAM_B '
c eval CallString = 'CALL PGM(PROGRAM_B) -
c PARM(' + Apostrophe +
c Apostrophe +
c P_Contract + Apostrophe +
c Apostrophe +
c ')'

c call 'PROGRAM_X'
c Parm Process 10
c Parm CallString 32702
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Needles,Stephen J
Sent: Tuesday, October 19, 2010 4:44 PM
To: Midrange Systems Technical Discussion
Subject: passing Call commands (with parms) from program to program

Here is the scenario...

Program_A is called by a .net process.

Program_A needs to submit a job that will ultimately run Program_B. But
it needs to go through Program_X and Program_Y to be in position to run.

So Program_A will perform a call to Program_X. The parameters include
the
call string for Program_B. Program_X will configure a SBMJOB Command
String to run Program_Y, which will be executed via QCMDEXC. Program_Y
will tweak the current job's execution variables (TIMESLICE, etc) and
then
will use the call string for Program_B that was passed all of the way
through this chain to call Program_B via QCMDEXC.

So Program_X is called from Program_A using:

D p_contract S 10

c eval Process = 'PROGRAM_B '
c eval CallString = 'CALL PGM(PROGRAM_B) -
c PARM(' + Apostrophe +
c P_Contract + Apostrophe +
c ')'

c call 'PROGRAM_X'
c Parm Process 10
c Parm CallString 32702


Program_X receives the parameters and they look like:

pProcess = 'PROGRAM_B '
pCallString = 'CALL PGM(PROGRAM_B) PARM('7100109958')'

Program_X will now create a SBMJOB Command to trigger Program_Y.

So that the Command to be executed viq QCMDEXC is:

'SBMJOB cmd(call Program_Y ('PROGRAM_B ' '39' 'CALL PGM(PROGRAM_B)
PARM('7100109958')')) JOB(PROGRAM_B) JOBD(*USRPRF) JOBQ(*JOBD) JOBPTY(3)
HOLD(*JOBD)'

Note the number of quote marks for the parameter for the call statement
for Program_B. No matter how I've tweaked the quote count and/or
position...I haven't been able to get PROGRAM_Y to execute.

So I get this error:

Message ID . . . . . . : CPD0020 Severity . . . . . . . : 30
Message type . . . . . : Diagnostic
Date sent . . . . . . : 10/19/10 Time sent . . . . . . :
16:33:22


Message . . . . : Character '7' not valid following string ''CALL
PGM('.

Cause . . . . . : A delimiter is missing between two values or a
delimiter
that is not valid was found.
Recovery . . . : Change the character that is not valid or if a
delimiter
is missing insert one. More information on delimiters can be found in
the CL
Reference manual.


Followed by the escape messages CPF0001& CPF0006.

The whole idea here is to submit jobs to different queues and priorities
based on what they are. And then, once they are running, tweak the job
further by modifying the memory behavior and the timeslice and stuff.

I would be willing to entertain alternative means to my ends.

Thanks for looking!

Steve Needles



==============================================================================
This communication, including attachments, is confidential, may be
subject
to legal privileges, and is intended for the sole use of the addressee.
Any use, duplication, disclosure or dissemination of this communication,
other than by the addressee, is prohibited. If you have received this
communication in error, please notify the sender immediately and delete
or
destroy this communication and all copies.

--




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.