On 12/18/2013 5:14 PM, D*B wrote:
@OT youn or old: I'm old enough (62) to do things as I want and not to do things I ' don't wanna do...
It is good to be able to understand the context of someone's replies.
<Buck>
But does this add any business functionality? It
seems to me that a COMMIT cycle that holds exactly one master row is
meaningless. Isn't a 'normal' COMMIT cycle a master row and some rows
in child tables?
</Buck>
No, I don't think so! you've taken the first barrier, your progarmms are compiled with commit, your files are journaled and nothing evildid happen - and maybe you've got a benefit: your tables are journaled. And if you would normalize your tables, a single table might be split in two (or more) and you would take the corrrespondet updates in one transaction, and it' done.
Yes, for this specific case of being able to compile with COMMIT(*CHG),
but what benefit does a program have when it does:
000 (READ) from input primary
100 WRITE
110 COMMIT
Isn't the normal reason for commitment control to group database changes
from multiple tables as one atomic unit:
000 (READ) from input primary
100 WRITE SALESDETL
110 UPDATE CUSTOMER
120 UPDATE EOMHISTORY
130 WRITE GLJOURNAL
150 COMMIT
The COMMIT has benefits (a beginner might think of the pending database
changes as 'queued up') but it is the ROLLBACK that really catches a
beginner's interest.
<Buck>
But how would we correct the error and re-process the undone
transaction?
</Buck>
The report could be produced as today and the customer would not see any difference. The diffrence to you (behind the curtain) would be: no data to repair, but the transaction would to be restarted again. Maybe your batch process is designed to process all unprocessed records, the next run will to this anyway (one example, I'm thinking of, we did speed up processes by parallelisation and some transactions died, caused by lock conflicts and simply making three retries did solve this all. In other cases a transaction dies, because a needed information was missing (the sales information arrived before the article information), this could not work this night, but maybe next.
Now we are moving from simple compiler defaults into application
re-design. As a programmer, re-work is what I do for a living, so this
idea is not scary :-) However, part of my job is to estimate how long a
given change will take and weigh that against the benefit to the
business: easier to maintain, fewer hard errors, easier to change in the
future and so on. The old application (for this example) is a very
simple input primary RPG cycle program. It reads all of the work file
records, totals up sales figures and writes sales transaction file
records. Actually, it's worse: if U1 is off, the program is an 'edit'
report. If U1 is on, it updates. The updates are assumed to always
work - in 1980 we weren't using WRITE(e), we were doing EXCEPT... O ADD.
Error handling was unknown and more or less impossible. When we got a
duplicate key error, we added a CHAIN and conditioned the EXCEPT on a
'not found' indicator... problem solved. Well, problem moved elsewhere
- hard error avoided anyway.
So now we are faced with the need to recognise when an input row was
COMMITted or ROLLBACKed. It's actually a pretty easy problem - the same
indicator that would abort the O...ADD can be used for the ROLLBACK.
But the input table needs a new column - an error flag - to indicate
that we need to re-process this row. In a more perfect world, maybe we
could delete the input row as part of the COMMIT, but here, we need that
row to exist for the next 3 programs in the series.
The point of this comment is to note that adding real CC requires some
small application changes in order to work. It's not just journalling
the files and adding a COMMIT after every I/O update.
<Buck>
When a ROLLBACK happens, subtract out
the 'details' from the total?
</Buck>
I would increment/decremet within the corresponding transaction and so the rollback would do it's work. In some important scenarios, we did some redundandent work, summing up what came in and showing the diffrence to what we could bring consistent to the database.
So imagine out input primary cycle RPG program. It looks a lot like this:
FSALESTRAN IPE
FSALESDETL UF A
FCUSTOMER UF
FQSYSPRT O F 132
QTY MULT PRICE EXTN 72
ADD EXTN L1EXTN 72
ADD EXTN LREXTN 92
CUST CHAIN RDETL 80
N80 ROLLBACK
80 DO
WRITE RDETL
UPDATE RCUST
ENDDO
L1 COMMIT
This was written when the IPE file was device type MFCM, so the code
isn't what we'd like to see in 2013. In fact, this example is
modernised: usually I see EXCEPTs, with the O specs showing either ADD
or update based on the indicators. But let's use more modern op-codes
to be clearer about the sample in a small space.
The problem with the ROLLBACK is that I don't know how many previous
cycles ADD EXTN L1EXTN occurred in. So I can undo the database
operations, but the calculations aren't part of the COMMIT cycle, so I
need a way to back out the ROLLBACKed details from my totals.
Again, this is easy enough now that we're thinking about ROLLBACK. Add
a 'transaction level' total and roll up to LREXTN only when COMMIT
happens. The thing that beginners to CC need to remember is that
calculations are not part of the 'pending' COMMIT boundary.
The most important goal of all this is: get rid of the effort to cleanup "the mess" happeneing by applications without transaction safety. Here you will get the time for redesign activities - it's the only chance!!!
This is also true enough. Every minute I spend fixing data is a minute
taken away from adding new business functionality. My managers want to
know the time it will take me to re-do the app to use CC vs the time it
takes me to run the cleanup programs (which are already written...) and
run the queries to check that the database is back together. Remember,
from management's perspective, this is about the cost to avoid say an
hour of cleanup twice a year. If it's going to take 2 weeks to re-work
the application, the ROI is something like 40 years. I might be able to
convince my manager that there are intangible benefits (making CC more
'normal' in our shop, teaching colleagues about CC and journalling,
better auditing because of journalling, etc.) but I _will_ need to argue
for it. Because every minute I spend re-working this old beast is a
minute I'm not spending on adding new business functionality...
<Buck>
You might be pleasantly surprised at how many of us have
journalling turned on even if commitment control isn't retrofitted to
every program.
</Buck>
That's good news, primarly for you - and a liitle bit for me.
BTW; I have a little tool to format journal entries (generating a table with the record layout of the journal image, adding the most important joural data) and i recognized, that I didn't publish it at my open source site - I should change this. Be patient, at the moment I'm busy with my CommandGate activities, and sometimes I have to work for money...
I have a tool I use here already. It is a very nice thing to be able to
map the JOESD field back to the original database columns.
Dieter
PS: did we meet together at Vienna in the Hotel Bar???
I've never been to Wien, but I would love to.
--buck
midrange.com
