[rescue] Perverse Question

[Charles Shannon Hendrix]

On Thu, Jun 19, 2003 at 11:53:24PM -0400, Sheldon T. Hall wrote:

> Heh.  My "first job in computers" was in a bank, as a computer operator, in
> the days before disks were the ultimate in on-line random access storage.
> It was my job to do the overnight batch runs that applied the day's
> transactions to the master accounts, produced reports, and generated the
> next day's master accounts.

We had TSYS records coming in as EDI files, which were fed to an Oracle
database. Our output was EDI files, to government agencies, so they
could pay their bills.

> It was not at all unusual for things to come up "out of balance" because of
> transactions that got made-cancelled-remade and where one of the steps got
> bollixed up, or because of storage read/write problems.  When that happened,
> we were supposed to find the transaction (easy if it as an odd amount like
> $136.47, but near impossible if it was $100.00), _edit_the_transaction_ to
> make things balance, and re-run all the batches.

Well, in that case, I suppose I can see doing it, and maybe you didn't
have the resources needed to re-run faulty programs.  

But for us it also violates the rules of account processing we were
given. Basically you never alter a file without first figuring out the
error. If it is a program error, you are supposed to recreate the file,
not edit it.

Even if the file was not ours, the first step was to get a good file,
not edit it. You contacted the producer of that file, who was often
greatful that you notified them of the error. This kind of thing is
essential when working with EDI files, as sometimes "errors" are changes
in field layout that have yet to propagate.

If we corrected the file, it was very possible we would be entirely
wrong in your correction. Was it an error of $46, or two errors of $23,
or some other combination? There are classes of errors you cannot figure
out by looking at the data.

But, we had MBAs who didn't understand double-entry or credit card
accounting, and they thought all the files should balance.  This was not
true of course.  First of all, a record was actually a group of 2-N
records of various types.  Second, not all of the records in the group
arrived in the same period.

Basically, "balancing" a file was not a straightforward column
summation, but they often edited the files to force this to happen.

> I expect things are a bit different now, but, to judge from the number of
> corrections and notations in the various monthly statements I get, the main
> difference is that it takes today's operators multiple tries to get it
> right.

I don't doubt it.  There are a lot of stupid things going on.


-- 
UNIX/Perl/C/Pizza____________________s h a n n o n at wido !SPAM maker.com