|
View previous topic :: View next topic
|
| Author |
Message |
PDB
New User
.jpg)
Joined: 18 Sep 2007
Posts: 7
Location: India
|
|
|
|
Hi,
My requirement is : if a particular column in the db2 table is not having some value ( lets say 'Y') then cause a 2 minutes delay in the batch program and then check again that column. If it is stil not updated then wait for another 2 minutes and then check again. I wants to wait for maximum 10 minutes and if it is not updated in 10 minutes then i wants to skip further processing. Can anybody provide me any idea of doing this thru cobol or jcl???/ |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
This has been asked many times. The answer from the more experienced people is "don't do that".
There is no good reason to implement such code. The only reason to do so is poor design.
You need to determine a better approach. Using the scheduling software would probably be a good place to start. |
|
| Back to top |
|
|
PDB
New User
Joined: 18 Sep 2007
Posts: 7
Location: India
|
|
|
|
Agreed... But we do not have much options
let me provide the exact scenario: inbetween two existing programs:
step 1. I wants to insert this batch program which will send some
accounts to Java thru mq
step 2. Java will update the table for those accounts and update one
column in specific table (some ind)
step 3. cobol batch program Need to check that ind; if that is updated
then go ahead with further processing otherwise wait again.
Now this requirement needs to be fullfilled thru cobol batch process without much changes in the scheduling.
What we thought was to make this new program as successor for existing 2nd program. Please suggest if you guys have better option... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
You could modify the java to submit a job* when the step2 update was complete. Step3 could be defined as a successor to the job that the java process submitted.
So, Step1 would run as it is; step2 would update the table and submit a new job when the update was complete; step3 would be dependent on the job that was submitted by java.
This way you would need no delay and it would all run automatically.
* this could be a simple as an IEFBR14 - just anything that would be a job.
Actually, you could have the java submit the "step3" batch job directly and not even need to use the schedule. |
|
| Back to top |
|
|
PDB
New User
Joined: 18 Sep 2007
Posts: 7
Location: India
|
|
|
|
Thanks but as of now we need to handle this from mainframe side.
Can there be something from mainframe side ?? |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| PDB wrote: |
Thanks but as of now we need to handle this from mainframe side.
Can there be something from mainframe side ?? |
Yes, please read, reread and read again the solutions suggested by Dick.
Unfortunately his comments regarding a lack of design capability are becoming more and more into play due to the fact that people want to do things the easy way rather than the correct way.
Have you considered the impact that you may have by hogging an initiator and preventing other production workload from processing. Have you considered the wasted use of resource because you would rather adopt a lazy solution than a correct solution.
Please, take this opportunity and think again. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
you really have not described what needs to be done.
I don't mean to be cruel or rude, but your description of the process
really sucks.
there are a lot of things that you can do without changing the java.
It would help it you described the flow of logic with a little more clarity.
you have a java front end,
communicating via mqs to a cobol backend with both doing db2.
now I have no real idea of your processing flow, but- you have mqs
- you have db2
- you have cobol
instead of trying to put a wait into a cobol program,
try to make your process a little more event driven - e.g.- put a db2 trigger on the insert/update
- put a trigger on the mq event created by the java front-end.
you don't want a cobol program continually doing db2 access
contention issues -locks etc..
you do a dirty read (WITH UR) to avoid the contention and
you are screwed if the Java update is backed out.
I would not use a cobol program to see if something has happened.
I would use a db2 or mqs trigger, that would be invoked as/when it happens - which means committed work
and let the trigger do something or start another task to complete the transaction.
Waiting means time elapse.
You are spinning your wells trying to apply human concepts of time to
what is going on in a computer.
you guess wrong on the wait period and you miss out
when things are so badly queued that it takes longer than you thought it should
and a process actually occurs yet you have decided because it took too long not to process it.
Then you are forced into a kind of time-out roll back.
event driven is exactly that. reaction to an event.
coding cobol to check for an event is employing batch processing mentality
to what actually is a real-time process created by the mqs communications. |
|
| Back to top |
|
|
|
|
