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



I agree!! Haha!

But I could not see another way to communicate it. Given some of the responses I gotten, it seems the whole idea of manipulating these variables will be of little value anyway. Considering telling management that this idea sounds better in there heads than it truly is in reality.

steve

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, October 20, 2010 11:56 AM
To: Midrange Systems Technical Discussion
Subject: Re: passing Call commands (with parms) from program to program

Every time someone describes a problem this way (Program A calls Program
X, which calls program Y which submits a call to program B) it reminds
me of Rube Goldberg's cartoons.

For example:
http://www.rubegoldberg.com/gallery_02.php

(Why am I posting this? I guess, I just thought someone should know.)



On 10/20/2010 8:31 AM, Needles,Stephen J wrote:
Bump - I have RTFM! I need a second set of eyes on this.

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

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.