OA27391: DSI297E INVALID INCLUDE CARD IN MEMBER DSIOPF, RC36

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Error is issued when using %LOGIC Rexx instead of %DATA Rexx.
  The difference is that the logic rexx member must contain at
  least one valid operator statement. A member with no Operator
  statement is rejected with message: DSI297E INVALID INCLUDE
  CARD IN MEMBER DSIOPF.  RC = 36
  User circumvented this by defining a dummy operator statement
  in case the cglobal is empty.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All Tivoli NetView for z/OS users.           *
  ****************************************************************
  * PROBLEM DESCRIPTION: When using the NetView %INCLUDE         *
  *                      statement to imbed null members (i.e.   *
  *                      valid members with no records) in a PDS *
  *                      file, the %INCLUDE processing converts  *
  *                      the end-of-data return code (4) set by  *
  *                      NetView's DSIDKS (disk read service)    *
  *                      into a invalid-member-name return code  *
  *                      (36) which is returned to the NetView   *
  *                      application/command issuing the DSIDKS  *
  *                      macro. Various applications/commands    *
  *                      handle this return code differently.    *
  *                      For example the NetView BROWSE command  *
  *                      displays the %INCLUDE statement with no *
  *                      error messages. The NetView PIPE input  *
  *                      stage '<' handles this the same way.    *
  *                      The NetView REFRESH command however     *
  *                      issues message DSI297E with return code *
  *                      36 and echoes the %INCLUDE statement in *
  *                      error. Other NetView commands as well   *
  *                      as OEM and user applications may handle *
  *                      this error in other ways.               *
  *                      Also, %INCLUDEd members written in      *
  *                      NetView dataREXX which generate no data *
  *                      result in the same errors as            *
  *                      non-dataREXX null members.              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  NetView %INCLUDE processor (DSIINCL) unconditionally converts
  the DSIDKS FIND return code 4 into a 36 return code for its
  caller DSIDKS which eventually gets returned to the originating
  DSIDKS call by an NetView application or command. DSIDKS FIND
  processing issues both a z/OS FIND and READ/CHECK for the first
  record of the member. If the member doesn't exist, DSIDKS
  returns a 4 return code indicating the error. But if the member
  is found but is empty, DSIDKS also returns a 4 return code which
  also means end-of-data on a read. Most applications (including
  the NetView %INCLUDE processor) don't make any distinction
  between member-not-found and end-of-data on DSIDKS FIND
  requests. So this results in a member not found error for most
  applications.
  When a member is written in dataREXX, the z/OS FIND is
  successful as is the READ of the first record. But before DSIDKS
  returns to the caller of the FIND request, it checks to see if
  the member is dataREXX. If it is dataREXX, control is passed to
  dataREXX processing which then loads the rest of the member and
  executes the dataREXX. When dataREXX returns to the calling
  DSIDKS FIND service, it either returns the first record with a
  return code of 0 or, if no data is returned, it returns a 4
  return code indicating end-or-data the same as the z/OS READ.
  Then DSIDKS FIND returns to its caller with either a 0 or an
  ambiguous 4 return code. But DSIDKS also sets a flag in the DSB
  passed on the DSIDKS macro call which indicates whether the 4
  return code means end-of-data or member-not-found on a FIND
  request.
  

Problem conclusion

• DSIINCL is being changed to recognize the difference between an
  end-of-data and a member-not-found return code on a DSIDKS FIND
  request.
  After making the change to DSIINCL it was also determined that
  the DSIDRS is not unstacking the null member's DSB. So DSIDRS is
  being changed to properly unstack the %INCLUDEd DSB for a null
  member on a DSIDKS FIND request.
  

Temporary fix

Comments

APAR Information

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

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

  UA45438

Modules/Macros

• DSIDRS   DSIINCL
  

Fix information

• Fixed component name

  NETVIEW FOR Z/O

• Fixed component ID

  5697ENV00

Applicable component levels

• R53B PSY UA45438

     UP09/01/27 P F901

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.