Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

delay in mainframe cobol batch program

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
PDB

New User


Joined: 18 Sep 2007
Posts: 7
Location: India

PostPosted: Thu Sep 18, 2008 6:11 am    Post subject: delay in mainframe cobol batch program
Reply with quote

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
View user's profile Send private message

dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Sep 18, 2008 6:23 am    Post subject:
Reply with quote

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
View user's profile Send private message
PDB

New User


Joined: 18 Sep 2007
Posts: 7
Location: India

PostPosted: Thu Sep 18, 2008 6:40 am    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Sep 18, 2008 7:00 am    Post subject:
Reply with quote

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
View user's profile Send private message
PDB

New User


Joined: 18 Sep 2007
Posts: 7
Location: India

PostPosted: Thu Sep 18, 2008 7:06 am    Post subject:
Reply with quote

Thanks but as of now we need to handle this from mainframe side.
Can there be something from mainframe side ??
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8593
Location: Back in jolly old England

PostPosted: Thu Sep 18, 2008 11:23 am    Post subject:
Reply with quote

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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6968
Location: porcelain throne

PostPosted: Fri Sep 19, 2008 2:53 am    Post subject:
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Mainframe Opening in Chennai ( 2 to 4... muralikrishnan_new Mainframe Jobs 0 Tue Jul 18, 2017 2:20 pm
No new posts XML Parse for COBOL 5.2 Bhanu Praveen COBOL Programming 1 Sat Jul 08, 2017 8:58 pm
No new posts Writing a file using online program grvtomar PL/I & Assembler 3 Fri Jun 30, 2017 1:06 pm
No new posts pre-compiler for program in an HFS Pedro DB2 0 Fri Jun 23, 2017 11:13 pm
No new posts Identify top 30 big tables or indexes... ashek15 DB2 0 Fri Jun 16, 2017 10:01 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us