|
View previous topic :: View next topic
|
| Author |
Message |
ankit saxena
New User
Joined: 06 Oct 2010
Posts: 55
Location: india
|
|
|
|
hi,
i am facing a problem as i am submitting a jcl from cics region using (spool write) but i need to know what is the return code of that jcl in the same program is there any way how to get the return code..
thanks.. |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
NO what You ask cannot be done!
the best thing would be to review the requirement |
|
| Back to top |
|
|
ankit saxena
New User
Joined: 06 Oct 2010
Posts: 55
Location: india
|
|
|
|
hi,
my requrement is to only know if t code was executed successfully or not (RC=0), is there a way to check only this much..
thanks |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
In response to Enrico's
| Quote: |
NO what You ask cannot be done!
the best thing would be to review the requirement
|
you say
| Quote: |
| my requrement is to only know if t code was executed successfully or not (RC=0), is there a way to check only this much |
In what way does this show a review of the requirement? What you want can't be done !
Garry. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
ankit saxena,
this type of request is similar to an interactive ISPF panel waiting on the results of a submitted job.
because the execution of the job can be delayed for a multitude of reasons,
thus resulting in a period of time between SUBMIT and completion.
Nothing should be waiting
not an interactive ISPF Panel
certainly not a module in CICS
people who makes such designs, only display their basic ignorance of mainframe computers
The Mainframe is not a PC
Resolving the status of a submitted job should never be part of the submitting task.
a separate task should be designed to respond to the results of submitted jobs,
however the results are gathered.
a suggestion:
the module in CICS that SUBMITs the job,
also write to a queue (which as a file is accessable by a batch job) the job name
or
an entry to a db2 table
or
a step within the submitted job, write to a batch file with particulars of the job.
a batch task should be designed to access
the queue generated file
or batch file from job submitted
or db2 table
(to determine if jobs have been submitted)
and if so, access the JES system - SDSF, ...
(or the batch job results in the batch generated file)
and then write results to a file (which is defined by cics as a queue)
which fires off a transaction to process the 'results of the job',
whatever process is required of the job results.
Often a db2 row is written/updated by the submitting task in cics
and updated/deleted by the submitted job.
then the 'job results processor' accesses this db2 table for outstanding jobs.
a lot of work for an automated feedback... |
|
| Back to top |
|
|
|
|
