In article <[EMAIL PROTECTED]>, Ted MacNEIL <[EMAIL PROTECTED]> wrote:
>> controller cannot allow writes to those tracks to happen until the commit >> of Step A's data is complete. Step B's unexpected delay may even lead to >> the job's failure, perhaps with a S522 or S222 abend. > > Huh? I think this is a bit contrived, Certainly; among other things, the "Commit", while slow in computer time, would finish in a second or two in all but pathological cases. But when analyzing system interaction for possible unexpected consequences, contrived scenarios are easier to explain than the longer sequences that actually cause problems in the real world. > and slightly inaccurate. That's more-than-slightly possible. > What happens if STEPA updates the same track/block more than once? If it inserts a "Commit" channel command in between updates, the same thing could happen. But very few programs do that. > This can happen in a Banking App (for example), if somebody does multiple > bill payments (online), or there are multiple posts/debits to the same > account in a batch job. Do they do mass Commits of all the tracks of large data sets? Potentially, the whole of cache could be Committed at once by CLOSE processing, while the applications you are referring to tend to Commit their data one unit of work at a time. > STEPA is going to 522, because of itself? I don't think so! Step B can 522, if it waits longer for its I/O to complete than the time specified in IEFUTL. It can spend that time waiting because the Storage Subsystem cannot serve Step B's Write request until Step A's Asynchronous Commit has ended. -- Randy Hudson ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
