Over time, when new features are added to CU*BASE that require new flags on membership and account records, we sometimes elect to implement those without doing corresponding database floods to set all of the new flags on all existing accounts.  Instead, we instruct maintenance programs (like Tool #15 Update Membership Information or Tool #20 Update Account Information, as examples) to simply input any missing flags to the default value automatically, on the fly, any time the maintenance program is accessed for any other reason and Enter is used to proceed through the screens.  (This doesn't happen if you enter the program then immediately use Cancel to back out, without ever using Enter.)

Other programs that use membership data are instructed to treat a blank value the same as N (in most cases, that's the default for a Y/N flag), or 0, or whatever other default value is appropriate under the circumstances.  This greatly reduces the amount of upheaval required every time we expand the functionality in these key files.

So in the situation you're describing, there is a "Deny membership" flag (DENYYN) on the MASTER membership table, which for the membership you accessed was sitting at a value of blank because it had never been flooded with the default N.  When you entered through the screens, the program ran its usual cleanup routines for any new data elements that hadn't yet been filled in for that account, setting that flag to N.  

Because these are still changes being made to the data, these events are still recorded in the file maintenance log as an official record that the database was altered, even though it was done as part of the program's normal routine and not necessarily the result of an employee's specific action.  

As a rule of thumb, research should be done using inquiry tools and not maintenance tools, wherever possible.