IBM Support

OA41741: GLD1221E UNABLE TO WRITE TO FILE //'DATASET': EITHER EDC5113I BAD FILE DESC, ELSE EDC5024I CANT CLOSE FILE ON THD

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Customer is using GDGs for their configured logfile:
    
     logfile: //'GDG.base.datasetname'
     logfileFilter: ibm-filterIP=*
     logfileRolloverDirectory: //'GDG.base.daatasetname'
     logfileRolloverSize: 0
     logfileRolloverTOD: 23:58
    
    Customer's log shows errors writing to the log. Either EDC5113I
    when a bad file descriptor was passed on fwrite from rtn
    srv_log_string, else EDC5024I when trying to close(write) from a
    thread that didnt open the file.
     ANALYSIS:
     Internal testing has recreated the EDC5113I bad file descriptor
     error. The activity log support spans multiple threads running
     in the server. There is a timing window where main thread 0
     created the TODlog thread 1. In the case of a GDG only (not
     dataset nor HFS) the actual open of the file does not take
     place during activity log initialization (thread 0) but later
     in the TODlog thread 1. The timing issue occurs when thread 1
     has not yet opened the activity log file before thread 0 tries
     to write a record. The fact that the file is not opened is the
     cause of the 'bad file descriptor' problem. Activity log
     processing in srv_log_string should not try to fwrite without
     assuring that the GDG logfile was first successfully opened.
     In this case what caused the thread 0 main to write to the
     activity log so early was because the customer was also using
     SMF auditing, so was trying to write this message to the
     activity log: GLD1187I LDAP server SMF auditing ON.
     KNOWN IMPACT:
     The server continues to run but activity log functions fail to
     complete
     VERIFICATION STEPS:
     1. Activity log configured for GDG's
    

Local fix

  • BYPASS/CIRCUMVENTION:
     Use USS files or non-GDG datasets for activity logs
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: Users of IBM Tivoli Directory Server for     *
    *                 z/OS and using activity logging.             *
    ****************************************************************
    * PROBLEM DESCRIPTION: 1. Activity Log fails with EBADF on     *
    *                      write of message when using GDG.        *
    *                                                              *
    *                      2. Activity log can't rollover on GDG   *
    *                      dataset.                                *
    ****************************************************************
    * RECOMMENDATION: APPLY PTF                                    *
    ****************************************************************
    1. This is a time pace problem, the SMF setting information is
    written into activity log file in srv_console_exit function,
    but the file handle of activity log is opened in a separate
    thread, it is possible that the GDG has not been opened when we
    use file handle to trace.
    
    2. When an activity log record is written to the log file, the
    server will call stat() to get the size of log file and compare
    it with logFileRolloverSize to decide if rollover is needed.
    However, stat() cannot support GDG dataset and the file size
    returned is incorrect. This causes rollover failure.
    

Problem conclusion

  • 1. The activity log code was modified with adding a wait loop
    for this situation.
    
    2. The activity log code was modified to avoid calling stat().
    
    This APAR support was provided through internal defects D4527,
    D4530.
    
    FMIDs affected:
       HRSL3C0 - IBM TDS on z/OS V1.12
       HRSL3D0 - IBM TDS on z/OS V1.13
       HRSL410 - IBM TDS on z/OS V2.1
    
    This APAR updates the following parts:
       GLDSRV31
       GLDSRV64
    

Temporary fix

Comments

APAR Information

  • APAR number

    OA41741

  • Reported component name

    SECURITY SERVR

  • Reported component ID

    565506803

  • Reported release

    3D0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2013-03-19

  • Closed date

    2013-06-25

  • Last modified date

    2016-12-08

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

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

    UA69673 UA69674 UA69675

Modules/Macros

  • GLDSRV31 GLDSRV64
    

Fix information

  • Fixed component name

    SECURITY SERVR

  • Fixed component ID

    565506803

Applicable component levels

  • R3C0 PSY UA69673

       UP13/06/29 P F306

  • R3D0 PSY UA69674

       UP13/06/29 P F306

  • R410 PSY UA69675

       UP13/06/29 P F306

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.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3D0","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3D0","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
08 December 2016