Your program must be able to handle cases when VLF is inactive.
For example:
- VLF might be inactive when you issue a VLF macro.
- The operator might cancel or stop VLF, thus making it inactive,
while VLF is processing your request and your application's address
is swapped out.
If your program issues a VLF macro when VLF is inactive, the system
returns a return code of X‘28’. Your program should then
use an alternate method of retrieving data.
To avoid an abnormal termination that might occur if VLF becomes
inactive while processing your request, your program should:
- Establish a recovery routine before issuing any VLF macro.
- Set flags before and after issuing any VLF macro. If an error
causes your recovery routine to get control, the recovery routine
can use the flags to determine whether the program issued a VLF macro,
but had not yet regained control, when the problem occurred.
- If the flags indicate the application was in a VLF macro when
the failure occurred, the recovery routine can, in nearly all cases,
assume that the failure occurred because VLF is inactive. The recovery
routine can then take the same action that your application does for
a return code of X'28'. Generally, the recovery routine should
not request a dump or write a record to the logrec data set for this
failure. The routine can assume that the system has collected serviceability
data for this unexpected failure.