|
View previous topic :: View next topic
|
| Author |
Message |
asnagara
New User
Joined: 29 Dec 2010
Posts: 6
Location: India
|
|
|
|
Is there any way to get the return code of a job which was submitted by COBOL program?
I want to get the return code of job to cobol program which just submitted the job through internal reader.
ie: Sending retrun code to the cobol program which submitted the job.
or
Can we instruct a job to use particular register for its return code ( something like Notify in job card)??
Thx- Gkl. |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
| Basically no, |
|
| Back to top |
|
|
asnagara
New User
Joined: 29 Dec 2010
Posts: 6
Location: India
|
|
|
|
thanks!
Any more information about register? beyond its usuage to set Return code?
any material about register?
Thx-Gkl. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Once the job is submitted into the internal reader, depending upon the site, the Workload Manager rules, the run time of the program, and so forth -- it could be seconds to hours to days between the time the job is submitted and the time the job completes. So how do you think you could possibly get a return code of any sort back from that job? |
|
| Back to top |
|
|
asnagara
New User
Joined: 29 Dec 2010
Posts: 6
Location: India
|
|
|
|
| well, if a cobol pgm is able to move a return code to register, why cant a cobol pgm until a register get a value by cobol program? |
|
| Back to top |
|
|
asnagara
New User
Joined: 29 Dec 2010
Posts: 6
Location: India
|
|
|
|
sorry typo
well, if a cobol pgm is able to move a return code to register, why cant a cobol pgm wait until a register get a value by cobol program? |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| asnagara wrote: |
| well, if a cobol pgm is able to move a return code to register, why cant a cobol pgm wait until a register get a value by cobol program? |
Because you will be tying up an initiator with a job that is doing no processing, but rather waiting idly until the second job is finished.
Why not have the last step of the second job send notification of its status when it completes? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
In addition to wasting resources as Akatsukami mentions, you are adding unneeded complexity. . .
Suggest you re-consider the design to make this process run serially. |
|
| Back to top |
|
|
asnagara
New User
Joined: 29 Dec 2010
Posts: 6
Location: India
|
|
|
|
Thanks all!
The problem is
My job has to find status of many batches. Once a status of a batch A is found, cobol pgm will write the status in a card, then the card will be given to another job which will send a email.
Once email is send( ie: RC=0 of the second job) my cobol pgm will start calculating status for batch B.
Note: we can’t assume about number of batches per day. I’m okay with all design related stuffs, but struggling find a way to receive return code from second job. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| well, if a cobol pgm is able to move a return code to register, why cant a cobol pgm wait until a register get a value by cobol program? |
Because one register is in the address space of the first job, and the other register (entirely unrelated to the first even if they are the same memory location) is in the address space of the second job. While data can be transferred across address spaces, this is a highly complex and very advanced thing to do, well beyond the expertise of most application programmers.
There are other, simple approaches (using a job scheduler, having one job submit another job, etc) that will accomplish such goals without requiring advanced programming or resources being tied up unnecessarily. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
| Quote: |
| I’m okay with all design related stuffs |
You may need to reconsider this statement.
Why do you care about the return code of the second Job?
If it is just sending email, what could go wrong?
If you get a bad condition code from Job Two, do you want to stop Job One? Why?
Process a Batch
Send an email
Repeat until no more batches
Can the sending of the email be a called subroutine in Job One?
Sometimes discussing the design may improve the process. |
|
| Back to top |
|
|
asnagara
New User
Joined: 29 Dec 2010
Posts: 6
Location: India
|
|
|
|
Dave,
Cob pgm will find status of batchA then place them in card, then the card will be used to send an email to sender A, once email job is done successfully, the same card will be used to find batchB, agin email will be ...
all i need is to make the cobol pgm to wait until email job is done and will use the card again.
any help?
Thx-Gkl. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
| Quote: |
all i need is to make the cobol pgm to wait until email job is done and will use the card again.
|
This is a very poor design. All you need is to CHANGE YOUR DESIGN.
What does the email job look like? What does this 'card' look like?
You may want to consider writing all you email correspondence to a single file (card in your words?), then submit the email job once at the end to send all the emails.
Having a Job wait in the middle (mid program in our case), should never be considered. |
|
| Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
| Robert Sample wrote: |
| There are other, simple approaches (using a job scheduler, having one job submit another job, etc) that will accomplish such goals without requiring advanced programming or resources being tied up unnecessarily. |
Like Robert says, you should examine if your job scheduler can be used to send notifications for failed jobs, or even issue automatic problem tickets.
Also, some JES log archiving systems (like $AVRS) can parse condition codes and other job info from spool queues and could possibly also be used as source for a notification application.
It is not always feasible or even possible to implement application programs to perform tasks that infrastructure tools are supposed to handle. |
|
| Back to top |
|
|
|
|
