PK16110 was our APAR. We discovered the error during the 1.7 ESP on a production system after migrating methodically through the enterprise with no problems reported. Turns out it was a single application creating (a few) files that typically had short blocks embedded somewhere. Like any problem, of course, we didn't initially know the cause but discovered that if we made 'our own copy' of a 'bad' file, FTP worked fine. That was actually the answer: any ordinary copy process--name your poison--will produce 'standard' blocks on output, so of course that would FTP just fine.
When the spark of suspicion hit me, I fired up the ancient and venerable TSO ZAP command available on the CBT. It quickly revealed blocks of unequal size. We offered a workaround to the application folks but worried that there might be other files out there. The scary thing was that FTP ended with no complaints but a *corrupted* output file that the application folks noticed only because they tried to use it as input, where it failed some kind of validation. So Tom Brennan wrote a short ASM program like that described in another post. We found no other problems. TSO ZAP is laborious for a large scale scan, but if you suspect a particular file, it's easy to spot. I believe that IDCAMS (DUMP?) will show the problem also; anything that processes by block rather than logical record. . . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> wrote on 03/01/2006 05:12:15 AM: > > -----Original Message----- > > From: IBM Mainframe Discussion List On Behalf Of Gilbert Saint-Flour > > > > On Tuesday 28 February 2006 12:53, Chase, John wrote: > > > > > Is there an "easy" way to find any "short blocks" that might exist > in > > > a FB dataset? We don't have DITTO (IBM File Manager), and I haven't > > > > found a way with File-Aid yet. > > > > The BLKSIZE2 program in file 183 of the CBT tape prints the > > size of each block if finds in a data set. It was written > > eons ago to study the structure of a PDS, but it may just do > > what you want. > > > > May I ask why you need this? > > Sure. We are seeing occasional data corruption when PUTting a file to > an ASCII host using the z/OS FTP client. The symptoms are very similar > to those described in APAR PK16110, which addresses data corruption > using FTP GET, that occurs when z/OS FTP encounters a "short block" that > is not the last block of the FB dataset. > > I suppose I could just create a FB dataset with "known" embedded short > blocks, but initially we want to test using the original dataset that > suffered the corruption to see if the same corruption occurs at the same > record(s). In this instance, two of the 119,613 records suffered > corruption in one field each. I want to see if those records are in > short blocks, and if so, their positions within those blocks. > > -jc- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
