Space announcements


This space provides the same content as before, but the organization of the home page has changed. The content is now organized based on logical branches instead of legacy book titles. We hope that the new structure will help you quickly find the content that you need.

Logical log files and ongoing processing

During an ongoing log scan, Log Master keeps track of each run of the log scan and any transactions (URIDs) that are still open at the end point of the log scan.

For ongoing log scans, the product ensures that:

  • Any transactions that are open at the end of the current log scan will be included in the next log scan (during the next run of the work ID)

  • Any transactions that were completed within the previous log scan are not processed twice, even though the product might scan part of the same log range again

Similarly, application programs must take similar action when they operate on a logical log file that was generated by an ongoing log scan. In practice, this means that the application program might need to ignore some records from a logical log data file that was generated by an ongoing log scan. The program must ignore these records if they are:

  • Part of a transaction that is incomplete at the end of the ongoing log scan

  • Dependent on a transaction that is incomplete at the end of the ongoing log scan (when the logical log data records reflect changes to the same table rows that are affected by an incomplete transaction)

To determine if the program should ignore a record in the logical log data file, read the logical log control file that was created in conjunction with the data file. The logical log control file has one instance of a Log Information End (DLGE) record. For more information, see Log information end record (DLGE). The DLGE record contains a field named DEPENDENTRBA, which is a twelve-byte character field that contains the externalized hexadecimal representation (using the EBCDIC character set) of a six-byte binary RBA/LRSN value. For more information, see Dependent RBA/LRSN Value.

  • If the value of this field is x'FFFFFFFFFFFF', the logical log data file does not contain any records that should be ignored.

  • If the value of this field is not x'FFFFFFFFFFFF', compare the value of the DEPENDENTRBA field to the value of the UORIDLRSN field in each record in the logical log data file. Remember that UORIDLRSN is a six-byte binary field, so the program must either convert DEPENDENTRBA to a binary number or convert UORIDLRSN to a character string before making the comparison.

    • If the UORIDLRSN field is greater than or equal to the DEPENDENTRBA field, ignore the record. The same record will appear in the logical log data file produced by a subsequent run of the ongoing log scan.

    • If the UORIDLRSN field is less than the DEPENDENTRBA field, process the record.

Dependent RBA/LRSN Value

Log Master stores a dependent RBA/LRSN value when any of the following conditions exist for a transaction (unit of recovery) that is selected by an ongoing log scan:

  • The transaction is committed within the range of the log scan

  • The transaction contains log records that the product does not complete during the log scan

The dependent RBA value is the log address of the Begin UR log record of the earliest transaction within the log scan that meets these conditions. If no transaction in the log scan meets the conditions, the product stores a dependent RBA value of x'FFFFFFFFFFFF'. The following figure shows a dependent RBA value.

The presence of a dependent RBA value affects the open transactions that Log Master includes in the ALPURID table of the Repository for use in subsequent ongoing log scans. Note the following points regarding the above figure:

  • The incomplete transactions INC1 and INC2 cause Log Master to store a dependent RBA value which in turn causes the product to store only the open transaction OPN3 in the Repository (because it starts before the point of the dependent RBA).

  • If transactions INC1 and INC2 were not present, Log Master would store a dependent RBA value of x'FFFFFFFFFFFF' and store the open transactions OPN1, OPN2, and OPN3 in the ALPURID table of the Repository.

Was this page helpful? Yes No Submitting... Thank you