CSV017I LOAD TO GLOBAL OF MODULE OPSYSSYM FAILED, ATTRIBUTE CONFLICT

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

Not sure if this is something that needs to be looked at. As far as I can tell, it isn’t causing an issue but thought I would mention it in case something should be changed or a case opened with Broadcom/CA.

 SDV54

15NOV 08:23:53 CSV017I LOAD TO GLOBAL OF MODULE OPSYSSYM FAILED, ATTRIBUTE CONFLICT

15NOV 08:23:53 CSV017I LOAD TO GLOBAL OF MODULE OPSLIKE  FAILED, ATTRIBUTE CONFLICT

15NOV 08:23:53 CSV017I LOAD TO GLOBAL OF MODULE OPSSETV  FAILED, ATTRIBUTE CONFLICT

 Noticed on SDV27 last night also:

14NOV 22:24:01 CSV017I LOAD TO GLOBAL OF MODULE OPSYSSYM FAILED, ATTRIBUTE CONFLICT

14NOV 22:24:01 CSV017I LOAD TO GLOBAL OF MODULE OPSLIKE  FAILED, ATTRIBUTE CONFLICT

14NOV 22:24:01 CSV017I LOAD TO GLOBAL OF MODULE OPSSETV  FAILED, ATTRIBUTE CONFLICT

 

Explanation:   A LOAD macro was issued, specifying GLOBAL=YES, for module mod.

A task control block (TCB) within the same job step task structure has already

loaded mod, but with different attributes. This situation could arise if a

program attempts to load the same module into both a fixed and a pageable

subpool, or into both local and global storage.

Programmer response:  Recode the LOAD macros to eliminate the conflict between

load usages.

Environment

Release : 13.5

Component : OPS/MVS

Resolution

We were able to recreate the problem in the lab. Here's a summary of what happens:

- LPARINIT is called from the AOFINIT program and invokes the OPSYSSYM.
- Programs invoked from a Rexx program are loaded into private storage, so now a copy of OPSYSSYM resides in private storage.
- Upon retun, AOFINIT invokes AOFGLOB, which I believe auto enables a rule or rules that invoke OPSYSSYM in the init section of the rule. Programs invoked in this manner are loaded into common storage to allow rules firing in different address space to access to them. The load fails because of the copy in private and a CSV017I message is issued followed by an SD06 abend.
- An OPS recovery routine intercepts the abend and deletes the module from private storage and reloads it into common thus allowing OPS to continue to function normally.

So, in effect things are working as designed.