IBM Mainframe Forum

[mandor]

Hello.

What we do is, insert a record in a batch program and we call existing CICS transaction which is part of a CICS application. The CICS transaction then wants to update this record inserted in batch. We thought the solution was to control the unit-of-work from batch.
We get the -911 (deadlock) sqlcode. Is there something missing or those DB managars don't communicate.

I read this, not sure what should i try.
http://publib.boulder.ibm.com/infocente ... c0063.html

This is the call

Select all

CALL 'DFHXCIS' USING VERSION-1
      EXCI-RETURN-CODE
      BLINE-USER-TOKEN
      DPL-REQUEST
      BLINE-PIPE-TOKEN
      BLINE-TARGET-PROGRAM
      BLINE-DFHCOMMAREA
      BLINE-COMM-LENGTH
      BLINE-DATA-LENGTH
      BLINE-TARGET-TRANSID
      NULL-PTR
      NULL-PTR
      EXCI-DPL-RETAREA
      NOSYNCONRETURN

[dick scherrer]

Hello,

Suggest you re-visit the design. . . .

Why has someone decided that inserting a row and then immediately calling other code to use that row was a good design (or even acceptable)?

[mandor]

Well, it's a complicated online application with interoperability with other apps (also online). Shop is a bank and it has alot of older apps covering account management. We are tapping into them to provide central forced payments system.
Is it a good design? Well, it's imperative to have results asap and we can't wait for nightly batches.
The question is if this is possible or someone knows it is not. If it's not, we'll just copy some code, and reorganize things. Now, i think that would be a bad design as it copies parts of code to other programs.

[dick scherrer]

Hello,

Rather than deal with this situation, several of my clients add the new data to a "most current" table and then reconcile in the nightly batch run.

One disadvantage to this is that the code that needs the data has to be changed to look in 2 places. But is does allow immediate access to the new entries. Hopefully, this new data is only needed to read by the online . . .

[mandor]

Yeah, it's a work around. We agreed to make a copy as this case mainly serves as a data migrating tool and shouldn't run for years to come.

I would still like to hear from someone is it at all possible to link the systems so that the update would be allowed for future reference. If I find out soething, I'll post it here for sure.

[dick scherrer]

Hello,

is it at all possible to link the systems so that the update would be allowed

Nothing to do with "linking the systems" . . .

When Thing1 holds a resource, Thing2 should Not be able to also hold that resource.

As i mentioned eralier, this is a design problem.

[mandor]

Thing2 is part of thing1 and is the same unit of work which is controlled by batch. If it is infact the same unit of work with commit on the batch side this shouldn't be a problem.