User options is one of those great ChangeMan ZMF features (in the product since the beginning), which typically allows any ChangeMan ZMF administrators to fine-tune any staging procedure (which is like a checkin of a source component that needs to be compiled by ChangeMan ZMF also). The actual procedures to compiling components (or variations of compilations) is typically something that differs from any ChangeMan ZMF customer to any other ChangeMan ZMF customers (everybody has their own unique needs and requirements).

That's where user options are used for: you get 20 fields, each of them 1 byte long, and the content of each of them can be any value you like/invent (e.g.: 1 such field can be a yes/no flag). Because of all the possible combinations, the imagination of a ChangeMan ZMF admin is the only limit to implement any unique requirements. In a more recent ChangeMan ZMF release, the concept of these 20 fields was expanded to many more similar fields, even with length of 2, 4, 8, ... up to 72 bytes each. But the original 20 fields are still used a lot (and they work great).

However, at some point requirements change. And therefor also the usage of these 20 bytes may change. Using any of the remaining 20 bytes is an easy solution to extend the implementation. Or adding extra possible values to any of the already used user options is another (easy) solution. But sooner or later, some of the allowed values turns out to no longer be used. Or even worse: one or more of those 20 bytes become obsolete entirely.

In that case, the easy solution (a matter of a few minutes work) is to just add some extra validation to no longer accept some of these values, or just block some of the 20 bytes so that nobody can enter any value anymore. So far no problem. But what about all existing components for which ChangeMan ZMF's meta data contain some value for these obsolete values or bytes? Even that at first is not a problem. But the problem will start if somebody (e.g. the successor of a retired ChangeMan ZMF admin) in the future will want to reuse that same value or same set of bytes. ChangeMan ZMF will then (still!) remember those outdated values and/or bytes. And depending what the new ChangeMan ZMF admin's goal was, very strange things may happen in compile procedures then. To prevent all this from happening, any user options (bytes) or any specific values that are no longer used, have to be reset back to some initial state (like blank or 'N').

Reminder: if you're in a hurry (anxious) to get Dr.Chgman to deliver this item faster, consider contributing via the Z-Bounties program.