On Sun, 2017-09-10 at 19:43 -0600, Nathan Andelin wrote:
Doesn't all these calls affect performance ?
I'm curious about the performance too. I haven't tested it. But just
reviewing the source code that I referenced in my original post we can see
that you have to pass through:
2 procedure calls.
2 monitor, on-error blocks.
2-3 select blocks.
before an I/O opcode is invoked.
If an error occurs, then you add the overhead pertaining to error
percolation.
Given the additional overhead, one should be able to expect some additional
benefit. What if any might that be?
If nothing else... If an error occurs, you can have an inbuilt and
consistent method of handling the errors such as message percolation or
message substitution or even using the message to perform some automagic
resolution.
A quick example would be replacing a duplicate key error in file
"custmasl4" with something far more humanly readable "cannot add
customer record due to duplicate shipping address". True you could
perform the same tests and replacements within the customer master
maintenance program, but if you then had a batch program that created
new customers from a file that the reps created via an android app...
you'd have to remember to add the same processing/tests/logic.
My take would be that the service program should actually do much, much,
more than just replicate the function of the inbuilt file CRUD (even if
that includes the details in my first paragraph). It should perform the
validation and, if applicable, send diag messages for each error
followed by an exception and so on.
Another advantage would be that the data "object"/parm would not have to
match the underlying file structure. You could pass it a
"CREATE:customer" (as a rough example) that was complete, but the
underlying file I/O could be split out to a customer master file, an
address file, a customer/address link file and if the logic dictated it
could also check to see if the address already existed and if so not
write to the address file and instead just create the link record or if
the address was close (say using a soundex) dump it into another file to
be manually checked later.
You could break the processing down to "CREATE:customer" which calls
ValidateCustomer, and if valid calls the various file I/O Crud
functions, and if any one CRUD function fails it calls the ROLLBACK or
if all ok calls the COMMIT. All the logic in one place, nice and neat
all called by every where else.
If the data changes to such a point as a new version of "customer" is
required (small changes or file organisational changes might be handled
by program logic) then by containing an initialised value within the
"customer" data structure (or have a version/format parameter similar to
IBM API's) the validation and/or CRUD can throw an exception if the
structure is not he expected one. Obviously there is nothing stopping a
programmer faking the initialised identification value in the same way
they can say a format in an API is not actually the format passed, but -
to be honest - that would be a really stupid thing to do(tm).
Jon.
midrange.com
