Re: passing Call commands (with parms) from program to program -- MIDRANGE-L

Hi Stephen

Given your statements and responses so far, I think using a server job
or jobs fed by data queues would work much better for you. You can
start/end jobs and tune them as workload dictates. You can use keyed
job queues or other logic in the data queue request to help you
prioritise processing. In the long run this will work much better than
trying to tune individual submitted jobs.

Consider: Setting the parameters of each submitted job for the
processing requirements at the time the job is submitted makes no
sense if the job is queued - the work load will probably have changed
by the time the job actually goes active. Changing the settings on an
active job takes effect immediately to affect what is processing at
the time.

Additionally, you gain the efficiencies of running one or several job
for a long time, rather than the starting and ending of multiple jobs
which has a lot of overhead associated with it, particularly as the
number of jobs increases. If there is only a small number of jobs
involved then tuning the individual jobs would gain you almost nothing
so I'm guessing there are a lot of individual jobs involved. A server
job would gain you a lot more in terms of performance and control.

Food for thought anyway.

On Fri, Oct 22, 2010 at 3:50 AM, Needles,Stephen J
<SNEEDLES@xxxxxxxxxxxxx> wrote:

Thanks everyone for your input...I'm beginning to believe that this is has a higher cost than the expected benefits will save.

I learned a bit, so I hope you all will join me in thanking all of the respondents.

Particularly,

the SPAWN() api Charles Wilt suggested looks like fun and I will be looking into that more in the future. Scott's article was enlightening. And it seems to be very easy to use.

The Environment Variables Loyd Goodbar suggested look interesting.

Thanks Again!

Steve Needles

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

Duane,

We are in a performance intensive environment and need the flexibility to adjust different processes that are submitted over and over again (using different data) so tune them specifically. JOBD's are too vague as they affect everything that uses them...we do not want to put into a situation where we've a JOBD for every individual process.

Management wants more control over the execution of these jobs...for example...

The process may be fine in the morning, but demands on the machine have put a temporary clamp on the available resources...then the values of the parameters used to run these jobs can be tuned so they (hopefully) run faster, thus preserving the response time of our users.

However, given the issues I have uncovered thus far, I may abandon this and tell the manager that the Costs vs. Benefits Ratio is not favorable for continuing this solution.

steve

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

Isn't this what subsystems, job queues and job descriptions et all are for? Controlling the execution environment of a job?

I don't know what your actual needs are, but IMO you are reinventing the wheel.

Why are you going down this path?

Duane Christen

--

Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx

Visit PAETEC.COM

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

Thanks Charles. I'll look at Scott's Spawn (there is a joke in here somewhere :-) ), but I like your comment on using a DS. I'll look into that.

The goal is to tune SBMJOB and CHGJOB parameters by Program to dynamically change the execution environment of Program_B throughout the day, without affecting other processes, and without having to change code at each "tune-up".

Program_A performs tasks that will take less than .15 seconds, but it submits the longer running portion to batch to keep the response time low. So there may be many different Program_A's.

Program_B is the longer running process that is expected to be completed somewhere further down the transaction's process, but takes too long to wait for.

Program_X contains logic to retrieve data from a table that describes the SBMJOB parameters to use when executing Program_B. It is the Submitter and is always called from whatever is representing Program_A at the time.

Program_Y contains more logic to use in a CHGJOB command to further describe the execution environment of Program_B. Program_B is then executed from this program using the call string originally provided by Program_A. This is the Executor.

I hope this makes the roles of each Program easier to understand.

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

This just seems like a very bad idea to me...though I'm a little confused...

You said "Program_A needs to submit a job that will ultimately run Program_B" after going through Program_X and Program_Y.

Yet your code shows Program_X being called directly by Program_A....

I would expect Program_A to be doing the submitting....
Perhaps of Program_C which calls, X,Y, then B...
or maybe Program_B, which before doing anything calls X & Y...

I don't know, but IMO passing a command string down a call stack is a bad idea.

Personally, if I had to pass the call information down, I'd do it as a DS with program name, parameters, ect. and build the command string where I was going to use it.

You might also want to look at the spawn() API instead of using the submit job command...Scott has a nice article..
"Don't Submit, Spawn!" http://systeminetwork.com/node/60939

HTH,
Charles

On Tue, Oct 19, 2010 at 5:44 PM, Needles,Stephen J <SNEEDLES@xxxxxxxxxxxxx> wrote:

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.

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

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

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

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

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

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

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

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

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