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


  1.  Home
  2. MIDRANGE-L
  3. October 2010

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

Sharon,

I think for the most part, the basics are: Do I have this program run
interactively or do I submit it to batch?

Honestly, I don't consider work management on the i "basic". There's
a heck of a lot too it, especially compare to other platforms and that
fact is a great strength of the platform.

Also, my guess is that in a lot of shops, work management is handle by
ops/admin and the application developers have little to know input.
Job queues, job descriptions, classes and what not were set up once
and basically forgotten about.

Charles

On Wed, Oct 20, 2010 at 2:53 PM, Wintermute, Sharon
<Sharon.Wintermute@xxxxxxx> wrote:
... don't understand work management .....

What?  Then how are they doing their job? If they can't figure out the "basics" ....


Sharon Wintermute


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

Duane,

You have a good point....

I can think of two answers...

1) Developers who don't really understand how work management...uh works.
2) Easier to maintain values in a table, rather than asking ops to
change work management related values

Charles

On Wed, Oct 20, 2010 at 1:59 PM, Christen, Duane
<Duane.Christen@xxxxxxxxxx> wrote:
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 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.



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.