MVSFORUMS.com

tarandeep_singh · Beginner Joined: 07 Mar 2005 Posts: 6 Topics: 3

I have a requirement where a Db2 table needs to be updated every 1 hour across 24 X 7 . (except a weekly 2 hr maintenance).
Apart from a scheduler where a job can be scheduled for this.

Is there any other way , may be thru CICS or anyother DB2 related way.

awaiting a reply
Thanks
Taran

Nic Clouston · Posted: Fri May 18, 2007 4:36 am Post subject:

Why would you not want to use the scheduler - that is what it is there for and what it is good at?

There are other ways - you could sit there and do it yourself but if you want automation then the scheduler is the correct tool to use.
_________________
Utility and Program control cards are NOT, repeat NOT, JCL.

dbzTHEdinosauer · Posted: Fri May 18, 2007 6:51 am Post subject:

tarandeep_singh,

tarandeep_singh · Beginner Joined: 07 Mar 2005 Posts: 6 Topics: 3

The source of trigger is rates from a file or MQ that come every 1 hour

kolusu · Posted: Fri May 18, 2007 8:00 am Post subject:

tarandeep_singh,

Write a CICS transaction that gets invoked from MQ to perform the update.

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

dbzTHEdinosauer · Posted: Fri May 18, 2007 8:15 am Post subject:

tarandeep_singh,

to reduce the amount of 'posting tag' (like phone tag)
i will make the following assumptions:

1 original source of rates are both file and MQ
2 validation/proofing is required before DB2 update

I would consider this is a batch activity; I would not waste CICS resources for this process.

1. MQ message design would include a field to indicate original source
file processed and written to MQ or MQ-msg from outside source.

2. The creation of the file would trigger a job to reformat and write to MQ. DFSORT
can do this, so no need to write a program to write the msgs.

3. Would write a batch run-unit (many modularized COBOL pgms) that would run 24/7.

4. the MQGET would use the option to wait until a msg is available.
The run-unit would be idle when no msgs available.

5. would use RRSAF; really relieves the programming effort on commits and rollbacks.

6. any validation/proofing would be accomplished by the run-unit. rejects would be
written to a second queue, which would be read by another run-unit to provide audit
and reporting.

7. would take advantage of the inherent MQS facilities for additional audit.
_________________
Dick Brenholtz
American living in Varel, Germany