Nobody...changing direction. We've come to believe that the result is not worth the effort.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Christen, Duane
Sent: Friday, October 22, 2010 10:31 AM
To: Midrange Systems Technical Discussion
Subject: RE: passing Call commands (with parms) from program to program
Stephen;
What are you adjusting with the environment? What specific parms etc of the CHGJOB/SBMJOB? Who's going to adjust these parms, when and how?
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: 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.
midrange.com
