As this is T24 it is controlled by T24 utilities. Always use a call to F.WRITE / F.MATWRITE - never the native functions - in online this caches the write to the end of the transaction when you call JOURNAL.UPDATE which wraps the transaction in boundaries.
In COB it is the main batch job management routine that controls transaction boundaries as an F.WRITE with RUB is not cached and is immediate. Never call JOURNAL.UPDATE in a version routine as you will flush any cached writes from T24 as well as the ones you intend. The final processing of the application will deal with the cached writes for you. Depending on T24 you can set INFO.JOURNAL on the SPF to see a post transaction image of all records updated by a transaction - if you get two F.JOURNAL records for one transaction then you have an ACID non- comnpliant transaction... On May 26, 8:15 pm, "Anar S.V." <[email protected]> wrote: > Hi. > > As is just regular practice in rdbms systems to set transaction > boundaries with means provided in corresponding rdbms's, I wonder > whether there are means to force locally developed routine to stay > within Transaction Boundaries in T24. > Some financial transactions in the current system doesn update all the > tables its supposed to, and we got some balance issues at the end. > Any clue or guidance appreciated. > > Thanks in advance. > Regards. --~--~---------~--~----~------------~-------~--~----~ Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -~----------~----~----~----~------~----~------~--~---
