PM98022: REWIND OF A GDG WHEN OPENED AS A DATASET (VS DD) CAUSES THE POSITIONING TO RESULT IN THE WRONG PLACE WITHIN THE GDG MEMBERS

APAR status

• Closed as unreproducible in next release.

Error description

• When a GDG is referenced by its base name in a DD statement,
  z/OS essentially concatenates all of the individual existing
  generations in that GDG under the same DDNAME.  If a program
  issues a rewind at any point while reading such a file, the
  next record to be read will be the first record of the most
  recent generation.  This is how things work for fopen by
  DDNAME.
  
  But when using fopen by DSNAME.... if a program issues
  a rewind while reading such a file, the next
  record to be read is not the first record of the most recent
  generation but rather the first record of the generation in
  which the rewind was issued.
  

Local fix

• Open GDG using DDNAME vs dataset
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: C/C++ applications that use fopen()          *
  *                 specifying a GDG base name for the dsname    *
  *                 without using a specific generation,         *
  *                 and later using rewind() to reposition       *
  *                 within the implicit concatenation.           *
  ****************************************************************
  * PROBLEM DESCRIPTION: C/C++ applications that use fopen()     *
  *                      specifying a GDG base name for the      *
  *                      dsname without using a specific         *
  *                      generation, and later using rewind()    *
  *                      to reposition within the implicit       *
  *                      concatenation, may not be positioned    *
  *                      to the first record of the most         *
  *                      recent generation.                      *
  ****************************************************************
  * RECOMMENDATION: Change the fopen() to use ddname instead     *
  *                 of dsname.                                   *
  ****************************************************************
  See problem description.
  

Problem conclusion

Temporary fix

Comments

• This APAR is being closed UR1 with concurrence from the
  submitting customer. This means that a fix to this APAR is
  expected to be delivered from IBM in a release (if any) to be
  available within the next 36 months.
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  LE C LIBRARY

• Fixed component ID

  568819805

Applicable component levels

• R780 PSN

     UP

• R790 PSN

     UP