db2 batch - mq

Michael McMorrow

db2 batch - mq
Hi,

We're currently developing a new category of application region and I'd
like to get your opinions on the best option.
The application reads an MQ message, performs DB2 for OS/390 V4 stuff, and
writes back an MQ message.
Technically this is a batch process (ie. not TSO,CICS,IMS transactional)
but it acts like an online process (handling approx 5,000 messages per
day).

Options seem to be:
1) Run as TSO Batch (but our MVS systems programmers say that they won't
guarantee any level of performance as they treat the IKJEFT01 program as
swappable and degradable at CPU busy).
2) Run as IMS DL/I or BMP (treated as non-swappable and high priority by
our MVS systems programmers but it seems odd to have to run as an IMS
program even when there's no IMS processing involved).
3) Run using CAF (we've no experience on this and it looks
cumbersome/complicated).

We plan on having many such MQ-Service-Applications (fits neatly with
Component Based Development) so I'd like to know what ye would recommend as
the best run-time environment. I'd prefer Option 1 for simplicity but the
MVS team are strongly negative and are saying that they have no way to
treat such applications differently to the rest of the low-priority TSO
address spaces.

Thanks,
Michael.
**********************************************************************
This document is strictly confidential and is intended for use by
the addressee unless otherwise indicated.

Allied Irish Banks
**********************************************************************



Jim (C) Chie

Re: db2 batch - mq
(in response to Michael McMorrow)
Lots of people run IMS as a transaction processor, but use DB2 for the
database. Its a good option if you have IMS already there, doing other
things. You can use a BMP for the queue listeners, and MPPs for the
transactions that process the messages. Just make sure specify the correct
COMMIT options, or you may lose messages.

-----Original Message-----
From: Michael McMorrow [mailto:[login to unmask email]
Sent: Tuesday, October 12, 1999 7:53 AM
To: [login to unmask email]
Subject: db2 batch - mq


Hi,

We're currently developing a new category of application region and I'd
like to get your opinions on the best option.
The application reads an MQ message, performs DB2 for OS/390 V4 stuff, and
writes back an MQ message.
Technically this is a batch process (ie. not TSO,CICS,IMS transactional)
but it acts like an online process (handling approx 5,000 messages per
day).

Options seem to be:
1) Run as TSO Batch (but our MVS systems programmers say that they won't
guarantee any level of performance as they treat the IKJEFT01 program as
swappable and degradable at CPU busy).
2) Run as IMS DL/I or BMP (treated as non-swappable and high priority by
our MVS systems programmers but it seems odd to have to run as an IMS
program even when there's no IMS processing involved).
3) Run using CAF (we've no experience on this and it looks
cumbersome/complicated).

We plan on having many such MQ-Service-Applications (fits neatly with
Component Based Development) so I'd like to know what ye would recommend as
the best run-time environment. I'd prefer Option 1 for simplicity but the
MVS team are strongly negative and are saying that they have no way to
treat such applications differently to the rest of the low-priority TSO
address spaces.

Thanks,
Michael.
**********************************************************************
This document is strictly confidential and is intended for use by
the addressee unless otherwise indicated.

Allied Irish Banks
**********************************************************************








John Wynton

Re: db2 batch - mq
(in response to Jim (C) Chie)
Michael,

This reply is from our Senior Instructor and MQ Guru, Tom Dunlap. He is not
subscribed to the DB2 list so I have forwarded them on. He has embedded
replies within an eddited version of your message in appropriate places.

John Wynton
Marketing Director, PathPoint Software
Themis, Inc.
Specialists in DB2, MQ and CICS Training
1-800-756-3000; 908-233-8900 (Int'l); 908-233-7401 (Fax)
http://www.themisinc.com

Tom Dunlap's comments follow:

Just a few random thoughts:

> > We're currently developing a new category of application region and I'd
> > like to get your opinions on the best option.
> > The application reads an MQ message, performs DB2 for OS/390 V4 stuff,
and
> > writes back an MQ message.
> > Technically this is a batch process (ie. not TSO,CICS,IMS transactional)
> > but it acts like an online process (handling approx 5,000 messages per
> > day).
> >
> > Options seem to be:
> > 1) Run as TSO Batch (but our MVS systems programmers say that they won't
> > guarantee any level of performance as they treat the IKJEFT01 program as
> > swappable and degradable at CPU busy).

The main reason for IKJEFT01 is to access the DB2 sub-system. One
possible
alternative is to do an SQL CONNECT and run as if processing from another
system
but no network is involved. Second, run as a started task as opposed to
a
batch job and have them process in a different performance group.

> > 2) Run as IMS DL/I or BMP (treated as non-swappable and high priority by
> > our MVS systems programmers but it seems odd to have to run as an IMS
> > program even when there's no IMS processing involved).

This may be the next logical choice if the started task can not be placed
into a
better performance group.


> > 3) Run using CAF (we've no experience on this and it looks
> > cumbersome/complicated).

I agree that this can get somewhat messy but may be a possible way to
eliminate
the need for IKJTEF01.

> > We plan on having many such MQ-Service-Applications (fits neatly with
> > Component Based Development) so I'd like to know what ye would recommend
> > as
> > the best run-time environment. I'd prefer Option 1 for simplicity but
the
> > MVS team are strongly negative and are saying that they have no way to
> > treat such applications differently to the rest of the low-priority TSO
> > address spaces.

A forth possibilty (long term) may be to use DB2 stored procedures and WLM
goal
mode processing implemented in DB2 V5 or later.

--
Regards,
Thomas Dunlap Senior Systems Advisor [login to unmask email]
Themis, Inc. http://www.themisinc.com 1 (800) 756-3000
"My opinions are my own, no one else is responsible.
No warrantees given (implicit or explicit)."



Isaac Yassin

Re: db2 batch - mq
(in response to John Wynton)
Hi,
I would use the IMS option (we do it and it works fine).
Using CAF is not as bad as you fear. You should sit ones to build yourself a
small program example and afterwards it'll be much easier. If you plan to use
"C" then beware of the syntax in the books as both V4 and V5 books has errors in
the syntax, but if you read the other languages examples then you get it right.
CAF performance is better then TSO.
--
Isaac Yassin

DBMS & IT Consultant

Tel: +972 9 9505172
Cel: +972 54 452793
Fax: +972 9 9560803


Michael McMorrow wrote:
>
> Hi,
>
> We're currently developing a new category of application region and I'd
> like to get your opinions on the best option.
> The application reads an MQ message, performs DB2 for OS/390 V4 stuff, and
> writes back an MQ message.
> Technically this is a batch process (ie. not TSO,CICS,IMS transactional)
> but it acts like an online process (handling approx 5,000 messages per
> day).
>
> Options seem to be:
> 1) Run as TSO Batch (but our MVS systems programmers say that they won't
> guarantee any level of performance as they treat the IKJEFT01 program as
> swappable and degradable at CPU busy).
> 2) Run as IMS DL/I or BMP (treated as non-swappable and high priority by
> our MVS systems programmers but it seems odd to have to run as an IMS
> program even when there's no IMS processing involved).
> 3) Run using CAF (we've no experience on this and it looks
> cumbersome/complicated).
>
> We plan on having many such MQ-Service-Applications (fits neatly with
> Component Based Development) so I'd like to know what ye would recommend as
> the best run-time environment. I'd prefer Option 1 for simplicity but the
> MVS team are strongly negative and are saying that they have no way to
> treat such applications differently to the rest of the low-priority TSO
> address spaces.
>
> Thanks,
> Michael.
> **********************************************************************
> This document is strictly confidential and is intended for use by
> the addressee unless otherwise indicated.
>
> Allied Irish Banks
> **********************************************************************
>
>
>