OA27537: TSO/E RECEIVE COMMAND ALLOCATES DATASET USING AVGREC WHICH CAUSES ISPF TO DISPLAY ITS SIZE IN BYTES

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • With z/OS V1R9 (HTE7740), TSO/E now allocates a data set in
    RECEIVE command processing using the AVGREC option.  As a
    result, the ISPF data set information panel (OPT 3.4) displays
    the size of the data set in bytes instead of blocks or tracks.
    
    This processing should revert to allocating the data set without
    using the AVGREC option, unless the data set is too large to
    allocate without it.  Then ISPF will display the size in blocks,
    tracks, or cylinders, not bytes, like it did before z/OS V1R9.
    

Local fix

  • To avoid the changed behavior of data set sizes being displayed
    in bytes (as an alternative to preallocating data sets before
    RECEIVE), first enter "?" in reply to the prompt from RECEIVE
    to see the size and blocksize, and then specify your own SPACE
    and BLOCKS, TRACKS, or CYLINDERS parameters.
    
    For details about specifying the SPACE, BLOCKS, TRACKS, or
    CYLINDERS parameters of the TSO/E RECEIVE command, see z/OS
    TSO/E Command Reference.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of z/OS V1R9 TSO/E or higher using *
    *                 the TRANSMIT or RECEIVE commands.            *
    ****************************************************************
    * PROBLEM DESCRIPTION: In z/OS V1R9 or higher, TSO/E TRANSMIT  *
    *                      or RECEIVE specifies AVGREC when it     *
    *                      allocates a new data set.  As a result, *
    *                      ISPF could display the size in bytes    *
    *                      instead of blocks, tracks, or cylinders *
    *                      as the TSO/E user expects.              *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    
    In z/OS V1R9, TSO/E began specifying the AVGREC option when it
    allocates a new data set during RECEIVE command processing.  The
    same is true for TRANSMIT OUTDSN processing.  While AVGREC will
    allow data sets with 16777216 blocks or more to be allocated in
    multiples of 1000 or 1000000 blocks, it could also cause the
    DS1SCAVB or '80'x bit in the DS1SCXTF of the Format 1 or 8 DSCB
    to be turned off instead of on.  As a result the secondary space
    extension value in DS1SCXTV could be in bytes, kilobytes, or
    megabytes not blocks.  If the DS1EXT or '10'x bit in DS1SCAL1 is
    on, ISPF uses the units indicated in DS1SCXTF, and the current
    allocation and current utilization could be displayed in bytes.
    
    For example, if the data set information utility used to show:
    
      Current Allocation
       Allocated cylinders : 1
       Allocated extents . : 1
    
      Current Utilization
       Used cylinders . . : 1
       Used extents . . . : 1
    
    It could show the following after a RECEIVE command, instead:
    
      Current Allocation
       Allocated bytes . . : 111,680
       Allocated extents . : 1
    
      Current Utilization
       Used bytes . . . . : 27,920
       Used extents . . . : 1
    
    In addition, TSO/E TRANSMIT and RECEIVE specify DSNTYPE BASIC
    for sequential data sets which previously specified no DSNTYPE
    at all.  While DSNTYPE BASIC is the default value, this could
    still lead to unexpected results.  For example, when a DSNTYPE
    BASIC is specified for a temporary data set on VIO it can fail.
    

Problem conclusion

  • TSO/E TRANSMIT and RECEIVE have both been updated to only pass
    an average record size or AVGREC text unit during allocation if
    16,777,216 blocks or more are needed.  This will restore the
    behavior prior to z/OS V1R9.  Similarly, the DSNTYPE text unit
    will only be specified if the data set transmitted had a DSNTYPE
    specified or more than 65,535 tracks are needed to receive it.
    
    In addition, update both z/OS V1R9 Migration (GA22-7499-12) and
    z/OS V1R10 Migration (GA22-7499-13) to delete the section titled
    "Accommodate TSO/E changes for data sets allocated from the
    RECEIVE command" from the chapter "TSO/E migration actions".
    The migration action is not needed if this APAR is applied.
    

Temporary fix

Comments

APAR Information

  • APAR number

    OA27537

  • Reported component name

    TSO/E SCHEDULAR

  • Reported component ID

    566528502

  • Reported release

    740

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2009-01-08

  • Closed date

    2009-08-20

  • Last modified date

    2009-10-02

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

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

    UA49617 UA49618 UA49619

Modules/Macros

  • INMALLOC INMRALLO INMRM    INMXASYS INMXCODE
    INMXPDS
    

Publications Referenced
GA22749912 GA22749913      

Fix information

  • Fixed component name

    TSO/E IDTF

  • Fixed component ID

    566528504

Applicable component levels

  • R740 PSY UA49617

       UP09/09/02 P F909

  • R750 PSY UA49618

       UP09/09/02 P F909

  • R760 PSY UA49619

       UP09/09/02 P F909

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.



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

z/OS family

Software version:

740

Operating system(s):

MVS, z/OS

Reference #:

OA27537

Modified date:

2009-10-02

Translate my page

Machine Translation

Content navigation