View previous topic :: View next topic
|
Author |
Message |
Abhi Nature
New User
Joined: 14 Dec 2011 Posts: 17 Location: India
|
|
|
|
Hi!
I'm writing a code in Cobol that will retrieve some information from the MVS Control Block. I'm able to extract some information, but not all.
The Cobol program is executed only when there’s an abend in some previous step of the JCL (COND=ONLY).
The information that I'm not able to retrieve is;
1) The step name that abended.
2) The PGM that abended.
3) Abend code (I'm thinking of taking it from ABENDCC)
In general, I'm not able to retrieve any information of the step that ran previously (successfully or unsuccessfully)
Would like to know;
1) What Control Block stores this information?
2) How to reach that Control Block (say from PSA)?
OR
Any other method to retrieve above information.
Thanks! |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
If a step abends, there is nothing left in memory. So control blocks dont exist anymore. Try to write an abend exit for the program, or if this construct has to be used for a lot of programs use SMF to get abended programs info. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
The information you have named is in the JES output for the job. Why not look at getting it from there? |
|
Back to top |
|
|
Abhi Nature
New User
Joined: 14 Dec 2011 Posts: 17 Location: India
|
|
|
|
Bill, if JES output is retrieved that will be great, but any method to copy (not divert) the JES output? I don't have SDSF utility.
Peter, I'm not very comfortable with SMF. So that's not an option for me, but thanks for your advice! |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
What are you trying to end up with? Do you have a Scheduler? Does that give you anything.
Have you looked at the Data Areas manual? If everything you need is Job-related there might be something for you.
If you don't have SDSF have you googled for other methods? I haven't, but you never know. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
Bill & Bill,
the TS is talking about abended programs. So there are a few possibilities :
if its 1 abending program let the program call an abend exit.
if its multiple different programs it is or using SMF or using SYS/JES2 log
reading utilities.
If it was me i would go for SMF (IIRC type 30), probably DFSORT Smart Tricks can help the TS.
Beside before mentioned, any self respecting site will have already reporting tools on abended jobs. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Peter,
Yes, I agree, I jumped on this too soon....
Mr. Bill |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
If you have a dump formatting product there may be utility programs that you can use to extract this information. If I recall correctly, Fault Analyzer has a reporting utility that will list the contents of the dump repository. No doubt other products have similar facilities. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
We need something clearer from TS (that's you, Abhi Nature).
What it looks like is a Cobol program sitting at the bottom of a multi-step job and which only runs if one of the steps abends. It would then like to identify some information.
What information, we don't really know (we do know what they want but can't get, but not what they can get). To do what with it, we don't know at all.
What does the Cobol program want to achieve? I guessed inform somebody in some way.
When the Cobol program is running, the job still exists and I think the information not yet found should be available (given that we don't know what is actually meant by "program") in a job-related control block.
A Scheduler is good at spotting jobs failing and then doing something, so might be of use depending upon what the actual aim is.
Perhaps all the information required is already on the output by that point.
From the description it is unlikely to be one program involved, steps are indicated in what has been said.
TS is happy (apparently) with the idea of getting something from the job output. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
Bill Woodger,
once again this is such a b.s.. The TS wants info about a previous abended step. Except for the the different logs and SMF there is no way to get info about the abended program/step via control blocks.
Schedulers have nothing to do with that.
The TS wants only this :
The information that I'm not able to retrieve is;
1) The step name that abended.
2) The PGM that abended.
3) Abend code (I'm thinking of taking it from ABENDCC)
Or are you not reading previous posts/comments, in stead rambling about cobol. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
Peter,
you are soo snarky tonight.
nomally i ignore Bill's rants and just 'cherry pick' the stuff he says for the good info that is often/usually there.
normally, the TS deserves this.
anyone who thinks MVS control blocks would still exist for a previous job step,
does not know enough to be writing this kind of 'info extractor' anyway.
that there supposedly does not exist any sdsf,
means either: 1. ignorance or 2. another spool system
that would have the same interfaces as sdsf.
personally, i feel this kind of stuff should not be in a production jcl.
that this kind of thing is being written means:
1. the shop is verrrrrrrryy cheap
or
2. the TS is not a syspgmr with any experience
or an application programmer who bit off more than he could chew
because he did not know anything about/undersand what mvs control blocks actually are and how they are used,
but found a code snippet in the internet and decided to use it.
i would write a 'COBOL' program,
invoked on cond code of abend,
that would get the basic stuff about the job
and write a record, message on a que,
with enough info for another program which would access the spool file
or archive, or whatever they have,
and strip the job messages for the necessary info....
in a production job cycle, you don't want to double up business processing
and abend info collection
at the same time.
actually, the people handling the abends,
should know enough about job output to read it themselves.
this job fell-over should be enough of a message.
there is always something that is not contained in these little
built at home event messaging systems,
that is needed to solve the problem.
so why waste effort on this kind of task...................... |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Peter,
Unlike you I don't know the requirement.
What the TS wantetd to do is needed to be known before how they might go about doing it. In this case the program is written before the data is discovered to be not available. The requrement is the business/technical object to be achieved, not an insistance that regardless of what the requirement is it has to be done in a particular way.
What I thought when I read the orinal post about his Cobol program was that "here is someone who has seen Gilbert Saint-Flour's Cobol program and thought it would be cool to find something to do with it. Let's use it to send an e-mail to say which program/step/job has failed". If it is something like sending a message, or that sort of flavour of thing I think there are more straightforward ways of doing it than they attempted in Cobol, or would have attempted in Cobol for the SMF records or in Cobol for reading the system logs.
Of course the TS might be after a completely different sort of beast.
Until we know I'm not particularly set on one course or another. I freely admit to having missed that they had found some useful information in the control blocks. I didn't miss the multiple steps. If this is more than the jobname then maybe the job output won't do it for them.
I freely admit I can be completely wrong in my guess. You could be wrong. We both could be wrong. There may even be a way where someone remotely concerned about it will later be able to reveal we were both right.
Up to this point I know nothing, because we don't know what the TS wants to do. |
|
Back to top |
|
|
Abhi Nature
New User
Joined: 14 Dec 2011 Posts: 17 Location: India
|
|
|
|
Thank you all. The problem is solved. I used Control Block. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
Abhi Nature wrote: |
Thank you all. The problem is solved. I used Control Block. |
he showed us, huh? |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
Abhi Nature wrote: |
Thank you all. The problem is solved. I used Control Block. |
And would you like to post the solution so that any others may benefit from this. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
Abhi Nature wrote: |
Thank you all. The problem is solved. I used Control Block. |
|
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2593 Location: Silicon Valley
|
|
|
|
Quote: |
Any other method to retrieve above information. |
I think SDSF is the preferred method. But if you do not have SDSF...
You can use FTP to access JES spool files. From FTP, issue:
then your DIR commands will list your jobs and GET commands will copy job output to your file. PUT will submit jobs.
The notes I have show this example of a DIR response:
Code: |
MYUSRIDA JOB05444 OUTPUT 3 spool Files
MYUSRIDB JOB05766 OUTPUT 6 spool Files
MYUSRIDC JOB05832 OUTPUT 6 spool Files
MYUSRIDD JOB05946 ACTIVE
MYUSRIDE JOB06021 INPUT -HELD- |
and knowing the jobid, you can issue GET commands:
Code: |
GET JOB05444.1 JOB05444.FILE1 (REPLACE
GET JOB05766.6 ASSEMBLY.FILE6
GET JOB06235.2 (REPLACE
GET JOB00275.4
GET J7438.3 |
In the GET examples, the '.3', for example, is the third file of the job. Or you can issue GET J7438.X to get all files of the job.
See the chapter on 'Interfacing with JES' of "z/OS V1R11.0 Communications Server IP User's Guide and Commands z/OS V1R10.0-V1R11.0 SC31-8780-09 "
Through the job control blocks, you should be able to get the job id of the executing job. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Whilst this is continuing then (without much more information from the TS) I'd like to say the Mr Bill's comments were always appropriate.
TS started off with his Cobol program. Just because you can do it in Cobol, does not mean it should be done in Cobol. My advice "If everything you need is Job-related there might be something for you" was not good advice. That fact that a Cobol program already existed should not influence the fact that it is much better to do it in Assembler than Cobol.
Irrespective of the requirement, someone else googling might find the information suppllied by the TS about a Cobol program doing it, so Mr Bill's comment should always be there to indicate a better method.
Pedro's solution looks fun. I hope it doesn't get used for all those "I need to know when JOBA has finished before I do the next step of my REXX Panel" requirements. |
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2593 Location: Silicon Valley
|
|
|
|
Quote: |
Pedro's solution looks fun. I hope it doesn't get used for all those... |
On a personal note, it looked fun when I first found out about it about 18 years ago, but I have not yet found a practical use for it. Your mileage may vary. |
|
Back to top |
|
|
|