Road Jogger wrote: > Jim, > > I have already done this.... i.e. to build the stats onto a separate > file instead of traversing through the whole TJ logs.... & here we use > 1 single unix login (as recommended by Temenos...) but still my > question remains UN-ANSWERED.... > > 1. How do we find out the list of files updated by a transaction??? Is > there any kind of unique reference which can be used???
I think that that is the TRANS and TRANSID fields. IIRC (and I may not), then the TRANSID is the identifier supplied by TJ itself and is always present, whereas the TRANS field is the user supplied transaction description from TRANSTART. The JBNAME is the JBCLOGNAME setting and the OSNAME is the UNIX level login. If TEMENOS tell you to have everyone login to UNIX with the same id, then you won't be able to audit the transactions unless they set JBCLOGNAME to whatever the T24 login ID is. I imagine that this advice comes from UniVerse days and is really now out of date as I have always recommended that the users have valid individual OS login credentials, which any application should then use. You might find it possible to set up JBCLOGNAME envvar yourself, but remember that environment variables are only inherited by child processes and not by parent processes. Another possibility is to log the tty or PORT or PID against the T24 user name, which is messy but would work (most of those will be reused at some point in the application life cycle :-() > > 2. When I do a selective restore, how does jlogdup know that this > record from TJ LOG is a part of transaction ??? > Each record has a transaction identifier. And the start and commit of the transaction is logged in the journal. The restore process does the reverse of the creation process in that a TRANSTART causes all subsequent writes to files that are flagged as being journaled (true by default) to be cached and they are not sent to the files until the TRANSEND is seen and they are safely in the journal. A restore does the opposite in that it will accumulate records for a transaction id and then commit them to the database once the commit is seen in the log (then it knows that that transaction was complete). I think that you are saying you were trying to selectively restore some items, but that the restore would not let you because they were part of a transaction. This is because the default behavior is to restore complete transactions only. Hence if you tell the restore to ignore boundaries, then it will restore the individual records and if you do not, then it will not. You would have to restore the whole transaction I think, which makes sense :-) So, if you have done the sensible thing, which you have, and done a READNEXT through the TJLOG file and stored the records in a separate stats file, then create indexes on a few things, such as TRANSID. If all your records have the same OSNAME and JBNAME, then there is little point indexing that, but if not then index by the name and the record ID to keep the indexes efficient (same idea with PATH and so on). Then providing you have also copied the DICT definition, you can select and sort your stats file pretty efficiently something like this: SORT MYTJSTATS WITH JBNAME="NARAYAN" BY TRANSID BY DATE BY TIME DATE TIME JBNAME TRANSID TYPENUM I do not remember what details the TYPENUM will show, but I think you should see a START and END event in there and that related transaction records have the same TRANSID. Records that were not bounded by a transaction probably do not have a TRANSID, but a listing of all the fields should show you this. Jim > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
