BPXF137E RETURN CODE 00000072, REASON CODE 058801AB unmounting a DCI filesystem
search cancel

BPXF137E RETURN CODE 00000072, REASON CODE 058801AB unmounting a DCI filesystem

book

Article ID: 453330

calendar_today

Updated On:

Products

Dynamic Capacity Intelligence

Issue/Introduction

Dynamic Capacity Intelligence (DCI) is running on two LPARs: LPAR1 and LPAR2

The production DCI Controller (started in ACTIVE MODE) is running on LPAR1, with agents running on LPAR1 and LPAR2.

A test DCI Controller (running in SIMULATION MODE) is started from time to time, for example to test new PTFs before applying them on production, on LPAR2 with their own agents on LPAR1 and LPAR2.

The two LPARs are not connected in SYSPLEX, each one has its own USS file system.

The zFS files for the two DCI environments are separate too:

  • hlq.DCI.PROD.ZFS for the DCI production environment
  • DCI.TEST.ZFS for the DCI test environment

Since the USS file systems are separate too, the same mountpoint name is used for production and test, for example /####/dci

However, when the production agent is active on LPAR2, the test DCI filesystem cannot be unmounted, since the UNMOUNT command receives the following error message:

BPXF137E RETURN CODE 00000072, REASON CODE 058801AB.  THE UNMOUNT FAILED FOR FILE SYSTEM hlq.DCI.TEST.ZFS.

If the production agent on LPAR2 is shut down, the test DCI filesystem can be successfully unmounted.

Environment

DCI 2.0 systems running on the same LPARs

Cause

Per IBM documentation:

  • RETURN CODE 00000072: Hexadecimal 72 translates to the decimal error number 114, which represents the standard UNIX error EBUSY (Device or resource busy).
  • REASON CODE 058801AB: This code contains two parts:
    • 0588: Represents the module ID or component ID within the z/OS kernel initiating the code.
    • 01AB: Represents the specific reason ID JRFsInUse, which explicitly means: “The requested file system is still in use. A normal unmount was requested, but there is at least one process still using the file system.”

Resolution

A DCI agent does not access directly any USS directory, so the problem is not related to DCI but seems to be on IBM side.

A quick workaround is to use different mountpoint directories:

  • Do not change the mountpoint name for the production DCI (i.e. /####/dci)
  • Rename the test DCI mountpoint (for example to /####/dci_test)