- Original Message -
From: "Johnny Luo"
Newsgroups: bit.listserv.ibm-main
Sent: Monday, April 13, 2009 12:21 PM
Subject: QSAM - Blocking logic defect for VB file?
Hi,
One of our customers had a problem in their production batch jobs. One
COBOL
program writes variable length records to a VB PS data set and after
smoothly running for ten years the program begun to generate VB files with
invalid RDWs as reported by DFSORT which is used to copy the files. We
are
at z/OS 1.9.
I first wrote a program to read the physical blocks and parsed each block
using BDW/RDW mechanism. It shows that there are 97 blocks which contain
invalid RDW(RDW<4 or RDW>LRECL)。No problem found in BDW. They just match
the
physical length of corresponding block.
To find the real problem I decided to parse the blocks in a different way.
The COBOL program builds the records as following:
1. After RDW each record contains a 8-byte identifier string 'BGLGLGP ';
2. 120 bytes from identifier string is a two-bytes length field which
contains the length of the variable data of the record;
3. Then comes the variable length part.
So I use the string ''BGLGLGP ' as delimiter to separate each record and
then find its 'real' RDW value in the 4-byte area just before the
identifier
string. I also use the two-byte length field set by user program to
calculate the supposed RDW value.
This time the result is more enlightening. All 97 'bad' blocks are in the
same pattern: (the following is simplified just to illustrate)
-
| BDW | RDW1 | REC1 | RDW2 | REC2 |
-
1. BDW matches the actual length of the block;
2. RDW1 and RDW2 all match the 'should-be' RDW value calculated from
length
field set by application program;
The problem lies in the actual record length. For REC1, its actual length
is shorter or longer than RDW1 indicates!
When DFSORT or other application like ISPF tries to parse the block via
RDW,
it found no problem with record1 cause the value of RDW1 is valid. But it
will get the wrong start address of record2 via RDW1 cause the actual
length
of REC1 is not as RDW1 indicates. That's means it will select the wrong
area as RDW2 and its value is unpredictable. Thus the so-called 'invalid
rdw'.
How does this happen? I can only think of one situation, that is, when
QSAM
is building the block. After moving record1 into the block, record2
should
be placed right after record1. If for some reason QSAM failed to do so,
record2 will overlay part of record1 or be placed far behind record1.
That
will generate a 'bad' block exactly as what we saw in this case.
To make things more complicated, the customer found one of their channel
paths could not be vary online when they tried to re-IPL the system. So
they
temporarily discard the use of that path and then suddenly the problem
disappears.
Now the customer believe the problem is caused by that channel path and
they
have reported the problem to IBM.
For me it's hard to accept it cause I cannot see the relationship. Write
operation does involve the interacion with channel subsystem but from my
limited knowledge after QSAM finished the building of the block all the
left
operations are at block level and will not touch the inner structure of
the
block. It's nearly impossible for them to generate a 'bad' block exactly
as
we saw in this specific case even if truncating or overlay occurs. So I
still believe the cause of the problem is that QSAM somehow failed to
build
the block right.
Any one can give me some hints?
--
Johnny,
If you're getting corrupted RDW's, don't waste time here, open a PMR
immediately.
Regards,
Tom Conley
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
