On 1/30/2015 1:28 PM, Dan wrote:
After about a 9 year hiatus from interactive app development, I started a
new job this week where I'm back into this.
Welcome back!
Was given a project for an existing maintenance app that currently loads a
page at a time, adding to the subfile with each page down action, until it
hits the 9999 limit. Problem is, now we're starting to get transaction
data that exceeds 9999 records.
This design paradigm was easy to write, but the thought of a person
pressing the page down key several hundred times to get to the row she
needs to maintain is well past its 'use by' date.
The new design I suggested is to redefine the subfile using SFLSIZ=SFLPAG,
and each paging action performs editing on the entire page of records, then
updates the table when there are no errors. The current app has a
"position-to" entry, and we need to be able to page both up and down from
that position.
I just went through this and I have a serious recommendation: don't do
that. By 'that' I mean 'look through 10k records to eyeball 'errors'.
Have the program present only the errors. But first, have the program
try to automatically correct errors.
My app reads an EDI file and assigns a customer an internal customer
type code based on a job description sent by our business partner. It
used to run an edit report showing all the records 'imported' and on
that report it put *** in the code column when it couldn't find a
matching job description. And someone would then eyeball each of x
hundred lines to find these situations and then go into the job
description maintenance program to update the job descriptions. After
the edit came out clean, they'd 'post' the batch.
Now imagine that there are about a dozen internal codes that get updated
from an equal number of partner-supplied criteria. Each one with its
own edit. Yuck.
The proposed change was to move the whole kit and kaboodle from paper to
5250. Page through hundreds or thousands (depending on the business
partner) of records by eye looking for errors and zipping off to
maintenance to fix them one by one. Paperless yuck.
My proposal was to skip the whole batch idea; update the clean records
straight away and have the maintenance program only show the errors.
And to do it by 'class' - if there were 30 records missing a job
description, they'd be taken to the job description maintenance program
with the known values filled in. All they needed to do is fill in our
internal code and update. Then the program runs the 'errors' back
through validation and posts the clean ones, again presenting only the
errors.
I got some resistance; change is harder for some than for others. But
in the end, the clerks who use this like it a lot better than the
previous system. The machine fixes what it can, updates what it can and
only presents records to the user that only a human could fix.
midrange.com
