Disk backup job consume 10 cpu times more in Z/OS 3.1 rather than in Z/OS 2.4.

Products

• Disk Backup and Restore - MVS

Issue/Introduction

On z/Os 3.1 the delay seems to be approximately around 3 seconds for most of the datasets being backup up.

This delay between 2.4 and 3.1 are delays from DFDSS in executing the native DUMP command.

z/Os 2.4:

ADR109I (R/I)-RI01 (01), 2024.094 17:50:38 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED 
0ADR012I (SCH)-DSSU (01), 2024.094 17:50:39 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0000

z/Os 3.1:

ADR109I (R/I)-RI01 (01), 2024.094 17:52:33 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED
0ADR012I (SCH)-DSSU (01), 2024.094 17:52:35 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0000

Environment

Release 14.0

Cause

On z/OS 3.1, IBM has implemented the OA63645 which was closed FIN in z/OS 2.3.0.
The change is incorrect because in ADRFCCHK, a delay was imposed for API
invoked DSS calls but not all API invoked DSS calls run in cross memory mode.
The 2 second wait in z/OS 3.1 in between those two messages:
ADR109I (R/I)-RI01 (01), 2024.102 14:43:44 INITIAL SCAN OF USER CONTROL
STATEMENTS COMPLETED
0ADR006I (001)-STEND(01), 2024.102 14:43:46 EXECUTION BEGINS
is the result of the OA63645 implementation in z/OS 3.1.
An APAR is opened to correct the problem.

Resolution

Get APAR OA66423 from IBM