Garbage collection is triggered by the system if there is not enough space to satisfy an MZWORK or MZLIFT request (hopefully this does not normally occur). Thus the user does not have to worry about initiating garbage collection to win space in the dynamic store. To remove the last event from the store, the user calls MZWIPE which is much more efficient than dropping the banks of the event followed by garbage collection.
He may however occasionally want to force a garbage collection to tidy up his data, particularly during the initialization phase of his program. Again, as in MZWIPE, if there are several divisions to be tidied up, this must be done by one call to MZGARB. Also, if one or several divisions are to be wiped out at the same moment, this should be included into the call to MZGARB; one and the same relocation pass can handle wiping and garbage collection simultaneously.
The calling sequence is:
with
IXGARB index of the divisions where garbage
is to be collected (none if =0)
IXWIPE index of the divisions to be wiped out
= 0: no divisions to be wiped
Both IXGARB or IXWIPE may be any of the three possible forms of a division index:
a) specific division index, as returned by MZDIV
b) generic division index, [ IXSTOR + ] n, where
n = 21: all user short range divisions
22: all user long range divisions
23: all package divisions
c) compound division index, as created by MZIXCO, see there for details.
MZGARB prints a monitor log message at level 2, but if the operation involves a garbage collection a message is given at level 1.