On 12/19/2013 4:18 PM, D*B wrote:
<Buck>
So I gave an example of an
old program I actually work with to start the discussion.
</Buck>
Thatt's a very interesting point of view, and we could continue the discussion (just ignoring that some people don't want to understand...). Might be far away from my todays work, but I'm interested too. I see two aproaches: first is to leverage modularisation, to try to use the ability of using diffrent connections (= ACTGRP in this context), or to try to use transaction control in an animal like this with cycle and Level break functionality; latter was a little bit strange to me, but I'm getting warm, let's continue, if you want!
Well, I want this to be far away from my work today too, but this stuff
is doing an old, boring job which has not needed to change for decades.
In many cases there isn't even an end-user! No display screens, no
data entry, no dashboard - just time cards coming in and payroll reports
and checks going out. This stuff is static - no real changes for 10 or
20 or 30 years.
The only chance we get to make real and useful changes is when the
company gets a new security system and changes from time clocks to swipe
cards in order to allocate worker hours to individual tasks. Now the
whole payroll system gets an upgrade. At this moment, one hopes to be
able to upgrade the database, but many times that is a big struggle with
management because they want all the same reports as always, PLUS the
new ones (hours by task).
So what gets changed? The database stays mostly the same - employee
master, payroll time cards, many work files and some EOM, EOQ, EOY
accumulators. A column gets added for task, and a few new reports are
written. A new program is written to convert the new swipe card data
format into the old time card file layout, with the new task column
being updated too. In this way, a new business function is added with
very little change to the payroll application as a whole.
This happens pretty much every time the business needs something new
from the payroll application. Small, incremental changes with the core
remaining as unchanged as possible. This is how we end up with this
sort of application in 2013. It wasn't a design choice, as much as that
is how it slowly grew.
The big problem with commitment control is that the life of a
'transaction' can be very long - multiple programs over multiple days.
We wouldn't design a system like this today, but we aren't free to alter
it much either.
The parts that have a UI (employee update display) can go under CC
pretty easily, but how many rows are in one transaction? Usually one -
the employee master. All the really transactional stuff is spread out
over several days (edit, edit, update P/R master, update P/R checks,
update P/R totals) and it's really difficult to cover this sort of
'transaction' with commitment control.
Once one gets started, it isn't that scary. It is always that first
step that is the hardest.
--buck
midrange.com
