IDMS: The need for ERUS FETCH PROTECT IS OFF

Products

• IDMS
• IDMS - Database

Issue/Introduction

As of z/OS 2.4, IBM will be removing the option of AllowUserKeyCSA(YES) in future, enforcing it to be NO.

A very small number of sites have custom code in an external address space (e.g. CICS) accessing EREs. Although this is most unusual, sites doing this will require the EREs to be in a non fetch-protected sub-pool.

Environment

CA IDMS, r19.0 and over.

Cause

This may be a problem because by default, CA-IDMS uses z/OS sub-pool 231 for the ERE and ESE areas and that is fetch-protected.
S0C4/AKEA abends may result.

Resolution

IDMS r19.0 APAR SO07073 was created to implement new functionality so that EREs will be allocated in a non fetch-protected sub-pool.

This will allow sites accessing EREs from custom code running in a CICS address space to continue to function, even with AllowUserKeyCSA(NO).

With SO07073 applied, this setting can be implemented with the SysGen SYSTEM statement clause ERUS FETCH PROTECT IS OFF or the SYSIDMS parameter ERUS_FETCH_PROTECT_OFF.