DSN1COPY : Temp Global Variable Workspace is 97.4 % full

Has anyone encountered the error message while performing a copy using the DSN1COPY utility ? You will notice your job sitting idle for a long time and then eventually error out with the message : Temp Global Variable Workspace is 97.4 % full, clearly viewed from the JES messages

Though the error is not DB2 related, I felt it would be better off if I provide some insight even though I am not very much familiar with how MVS works. Let me see if I can find someone from MVS reading my post and adding more points to it.

Here is the complete response from my MVS team and the error message from their logs :

OPS4290O var1 GLOBAL VARIABLE WORKSPACE IS var2 FULL (var3 OF var4 BLOCKS USED).

Explanation on the error message :
The global (or temporary global) variable workspace that contains both global variable and RDF data has met or exceeded the threshold of blocks in use as defined by the GLOBALWARNTHRESH (or GLOBALTEMPWARNTH) product parameter. This message will also be issued every time a new highwater mark is met or exceeded that is at least 5 percent higher than the previous high-water mark. The frequency at which this message is issued is controlled by the GLOBALWARNINTVAL (or GLOBALTEMPWARNIV) product parameter. Note that the check that results in this message is only made when a new global variable is allocated or an existing global variable is expanded. If this condition is detected during an RDF (SQL) operation, then this message cannot be issued. The condition is recorded and the message will be issued on the next reference to a global variable. If no global variable references occur, then you may not be warned of this condition until the database is full.

Action that needs to be taken :
You may need to analyze the contents of the global (or temporary global) variable database using OPSVIEW option 4.8 and delete unused symbols. You may also need to analyze the RDF database using the RDF Table Editor (OPSVIEW option 2.6) and delete any unused tables and table rows. If the global variable data set is too small, then allocate a larger global variable DIV data set and copy the old one over to it using the access method services REPRO command. Modify the Unicenter CA-OPS/MVS GLOBALMAX (or GLOBALTEMPMAX) parameter to indicate the larger maximum number of global variable blocks. The program or ruleset.rule name in the message represents the program running at the time the condition was detected or at the time a deferred message was issued. This program may or may not have caused a significant portion of the global workspace to be used.

So did the MVS team perform the above action(s) ?

They managed to look at some log file which stated that MVS might have tried to clear the contents on its own !!! - Now, I am not in a position to say whether MVS is clever or its a routine task for MVS to clear the temp workspace.

OPS3900O RULE TOD.GVCLEAR  FOR TOD 2013/05/15 19:30:12 SET  
OPS3092O OI GVCLEAR CRITWTOID
OPS3092O OI GVCLEAR CA7DMDREQ
OPS3092O OI GVCLEAR DOMWTOID
+OPS1005O ERROR 5 RUNNING GVCLEAR, LINE 87: MACHINE RESOURCES
EXHAUSTED, CODE=255

But the above indicated the OPS3900O logs, I was more interested in OPS4290O logs as this strange OPS number flashed on my JES messages. Here is the log from OPS429oO :

OPS4290O TEMP GLOBAL VARIABLE WORKSPACE IS  80.8% FULL (16142 OF 20000 BLOCKS USED)

Summary :

Reduction from 97.4 % to 80.8 % automatically - So all I had to do is wait for MVS to clear the temp variable : MVS was testing my patience that's all !! The restart of the job was eventually successful.