Record compression

[mike.olmstead]

This is what the documentation has for area recommendations when using compression on a record statement.

 

Area procedures needed for IDMSCOMP compression

If any record in the area uses IDMSCOMP and IDMSDCOM for compression and decompression, the area should have the following database procedure specifications:

CALL IDMSCOMP BEFORE FINISH.

CALL IDMSCOMP BEFORE ROLLBACK.

CALL IDMSDCOM BEFORE FINISH.

CALL IDMSDCOM BEFORE ROLLBACK.

This ensures that the work areas used by the compression and decompression routines are freed when a rununit terminates.

 

This is what we have:

DIS AREA OVDIST-REGION.             

*+   ADD                            

*+   AREA NAME IS OVDIST-REGION     

*+       ESTIMATED PAGES ARE 0      

*+       CALL IDMSCOMP BEFORE FINISH

*+       CALL IDMSDCOM BEFORE FINISH

*+       .  

 

Are there any ramifications for not having what the manual states?  We’ve run this way for years and years.

thx.                      

[Lynn DeLong]

It looks like  IDMSCOMP/IDMSDCOM would not free its working storage if the run unit ended with a Rollback instead of a finish.   But since this is non-kept user storage, I believe that it will get freed anyway when the task ends.   So normally no ramifications.   However if the task never ended and started and ended run units throughout the day, each new run unit should result in another piece or two of storage getting allocated, which would get freed on finish, but not on rollback, so it could build up in that scenario.

[StephenFranzon]

I'd say it's highly unlikely to cause any problems.

The call on FINISH and ROLLBACK is to explicitly free the routines work areas. They get freed on task termination anyway and as most tasks terminate soon after finishing the run unit, even the call on FINISH is not really needed most of the time. I've seen sites that haven't coded even the FINISH call and have not had any issues.

Failure to code the call on FINISH/ROLLBACK only causes problems where you have a single task that starts and ends many runs units. As the storage is not being freed on run unit termination and  a new block  of storage is obtained for each new run unit that is started, it can eventually cause storage issues. I've seen it happen, but it takes a lot of run units.

However for it to be a problem for you, you would have to have a single task starting many run units and terminating them with a ROLLBACK. That would be highly unlikely to occur.