Most everyone knows that when running a field edit, file edit, or sort edit, the output verb puts data in the filelog for the current batch. Changes to make this output more logical ran into conflict with what has historically worked. The historically correct way won out over what appears to be good logic.

The problem arises when two different workstation sessions are accessing the same batch. Where did the output go? Probably no one noticed, but this output went to the filelog for the current batch. In the past, if each session actually output to the filelog then the outputs were commingled.

FileLogs Fixed Not To Overwrite

An enhancement in Unibase checked for this case and delayed output from one session until the first session finished. Users familiar with the historical way objected. They want to run two sorts on the same batch at the same time -- regardless of what this does to the filelog. "Besides," they said, "who outputs to a filelog in a sort program?"

Process Now Checks Best Solution

Ok, so be it. Again, two sessions can output to the same filelog at the same time. If a user ever finds a filelog which looks weird, perhaps two sessions were accessing the batch at the same time.

No One Here Wanted Logical Way

No one put forth the case for doing it the other way; so unless we hear differently, an environment
variable was not created to make logic win over historic.

Thus, another page is written in the saga of bringing an environment which has existed for over twenty years into today's computers, implementations, and ideas. We are there for our clients; we preserve the historically correct; but with environment variables we can override history for better logic if users need a more logical approach.