View previous topic :: View next topic
|
Author |
Message |
dineshjyrm
New User
Joined: 07 May 2015 Posts: 1 Location: USA
|
|
|
|
Hi,
I have a job with programs executing in the same and one of the programs is abending with an User abend. The record causing the abend has been identified by performing a dump analysis (Looking at current record read and available in memory).
But it took a long time to identify the DSN in which the record was available since the DD name on in which the faulty record was available had 20+ DSNs concatenated together.
Is there a quick way to identify the DSN in which such faulty record/current record is available??
Thanks,
DJ |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1205 Location: Dublin, Ireland
|
|
|
|
If you know the offset, length and content of the 'faulty' field(s), you could run a DFSORT job against each of the separate DSNs in the concatenation....
Garry. |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1248 Location: Richfield, MN, USA
|
|
|
|
Was there an input record count in the program? If so, you could use the record counts of the 20+ files to find the DSN in question. If there is a unique character string or key, you could SRCHFOR it and it would tell you which relative dataset the record was found in. |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
dineshjyrm wrote: |
... it took a long time to identify the DSN in which the record was available since the DD name on in which the faulty record was available had 20+ DSNs concatenated together. ... |
There are two somewhat different ways a concatenated data set can be used: PDS concatenation, and sequential concatenation. Most likely, though, you are using sequential concatenation.- Locate the DCB you are using the read the data set. This is fairly easy for an Assembler program, it is harder for other languages.
- Find the DCBTIOT data area in the DCB. DCBTIOT is located at offset X'0028' in the DCB. It is a two byte binary data area. The value in DCBTIOT is the offset of the current TIOT DD entry in the TIOT for the data set currently being processed by the DCB. There is one DD entry in the TIOT for each DD statement.
In a SYSUDUMP type dump, the TIOT is partially formatted, like this -
Code: |
TIOT: 009BFFE8
JOB...... XXXXXXX STEP..... C
LN-STA DDNAME TTR-STC STB-UCB
+0018 14010100 PGM=*.DD 9D2A9800 80F48EA0
+002C 14010102 SYSUDUMP 9D2D9800 80000000 |
The +0018 or +002C is the offset of the DD entry. From there you go to your JCL to get the data set. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
What are you using to format your abend? |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
One TIOT entry per DD or one per DSN? |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
Bill Woodger wrote: |
One TIOT entry per DD or one per DSN? |
The TIOT has one DD entry for each DD statement.
TIOT in SYSABEND or SYSUDUMP -
Code: |
TIOT: 009BFFE8
JOB...... BCT188J STEP..... B
LN-STA DDNAME TTR-STC STB-UCB
+0018 14010102 SYSLOUT 9D26D800 80000000
+002C 14010102 SNAP 9D2A9800 80000000
+0040 14010102 SYSPRINT 9D2C1800 80000000
+0054 14010100 SYSLIN 9D2D9800 80F48D90
+0068 14010100 APDS 9D2F1800 80F475A8
+007C 14010100 9D309800 80F475A8 |
DCB -
Code: |
015074 0000 0 00000000 00000000 00000000 00000000 *................*
015084 0010 16 00020000 00000001 00004000 00006AC0 *.......... .....*
015094 0020 32 02000001 54000000 002C0020 009CB038 *................*
0150A4 0030 48 92DF105A 00DF1078 00000001 08000660 *................*
0150B4 0040 64 00000000 00006960 00000001 00000001 *................*
0150C4 0050 80 0000007D 00000001 *........ * |
JCL -
Code: |
//B EXEC PGM=LOADER,PARM='MAP'
//SYSLOUT DD SYSOUT=*
//SNAP DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSLIN DD DISP=(OLD,DELETE),DSN=*.A.SYSLIN
//APDS DD DISP=(SHR,PASS),DSN=SYS1.MODGEN
// DD DISP=(SHR,PASS),DSN=SYS1.MACLIB |
The value in DCBTIOT is 002C, so the DD statement is the SNAP DD statement.
In -
Code: |
015094 0020 32 02000001 54000000 002C0020 009CB038 *................* |
015094 is the storage address, 0020 is the hexadecimal offset of the address in the block of storage in the dump, 32 is the decimal offset. The TIOT was produced by an Assembler SNAP macro rather than an ABEND dump, but the format is the same, and the storage dump was produced by a custom dump program written for another project. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
The TIOT will have one entry for each DD statement, but it will also have an entry for each concatenated dataset on a DD statement. In your example, if X'007C' had been located at that position in the DCB, then it would have indicated the second DSN for the DD APDS, which is what the TS/OP wants to know. They know the DD, but want to know which of 20+ DSNs on that DD contain the current (bad) record.
I think Abend-Aid tells you flat out, if you just find the right place, but I don't know if TS/OP is using Abend-Aid. |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
Bill Woodger wrote: |
... it will also have an entry for each concatenated dataset on a DD statement ... |
Well, it's a DD statement, isn't it?
APDS was a poor example, since it represents PDS concatenation rather than sequential concatenation. In PDS concatenation, once the data sets are opened they operate together; a program using BPAM can quickly and easily switch between the data sets; the currently active data set will not be reflected in DCBTIOT, as is true with sequential concatenation. I put in APDS simply to illustrate what a TIOT with concatenation looks like. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
The TS/OP is talking about locating the current dataset in a concatenation of datasets that contains the faulting record.
So all the talk about PDS concatenation is of nil value.
Taking a SNAP dump of areas will always show the SNAP DCB as active, because that is where the output goes.
Real abends caused by faulty records and going to SYSUDUMP will give quite
different results concerning control blocks, pointers etc.
So all this is a bit an after the fact situation. The TS/OP has to take care that his input is valid or the processing program can handle rotten input. |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
PeterHolland wrote: |
... So all the talk about PDS concatenation is of nil value. ... |
Yes and no. My only goal was to show the method is not universally applicable.
PeterHolland wrote: |
... Taking a SNAP dump of areas will always show the SNAP DCB as active, because that is where the output goes. ... |
I just needed an open DCB - and SNAP was the only open DCB. Be reasonable. I needed something quick and one off for the exposition. I was not about to write something where I read part way through a concatenated data set and then took my dump. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Ah.
|
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
Quote: |
Well, it's a DD statement, isn't it? |
That was a stupid reaction.
Quote: |
yes and no. My only goal was to show the method is not universally applicable. |
Ok, so don't come up with a crap story about PDS concatenation. The same nonsense last time with using Idcams to copy a PDS.
And i'm reasonable, but don't come up with SNAP dumps. Give a real live example, where you find the dataset in a concatenation with the culprit record. That will be a tough job.
So i repeat it once more :
Quote: |
So all this is a bit an after the fact situation. The TS/OP has to take care that his input is valid or the processing program can handle rotten input. |
|
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
TIOT --
Code: |
TIOT: 009BFFE8
JOB...... XXXXXXX STEP..... B
LN-STA DDNAME TTR-STC STB-UCB
+0018 14010100 SYSLIN 9D26D800 80F48E18
+002C 14010100 INPUT 9D2A9800 80F48E18
+0040 14010100 9D2C1800 80F48E18
+0054 14010102 SYSLOUT 9D2D9800 80000000
+0068 14010102 SNAP 9D2F1800 80000000
+007C 14010102 SYSPRINT 9D309800 80000000 |
DCB -
Code: |
0150EC 0000 0 00000000 00000000 0094000B 00F3B03C
0150FC 0010 16 002FE5A2 0501EE68 00004000 00006760
01510C 0020 32 02015074 90000000 00404800 009C958C
01511C 0030 48 12CE90B8 00D30D10 0A000001 02090050
01512C 0040 64 30013030 00006820 0001EF10 0001EEC0
01513C 0050 80 00000050 00000000 00000000 00DE16F8 |
JCL -
Code: |
//B EXEC PGM=LOADER,PARM='MAP'
//SYSLIN DD DISP=(OLD,DELETE),DSN=*.A.SYSLIN
//INPUT DD DISP=(OLD,PASS),VOL=REF=*.SYSLIN,DSN=*.A.SYSLIN
// DD DISP=(OLD,PASS),VOL=REF=*.SYSLIN,DSN=*.A.SYSLIN
//SYSLOUT DD SYSOUT=*
//SNAP DD SYSOUT=*
//SYSPRINT DD SYSOUT=* |
Happy? |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
Back to top |
|
|
|