The described record arrival rate averages at just under 58 records per
second. Somehow I don't think XBM was designed with that high of
transaction arrival rate in mind, processing each record as a separate
transaction. I would think that a high-speed transaction processing
environment (CICS, IMS) would do better than XBM, although those would
probably still involve more overhead than a specialized
transaction-processing STC optimized just for your own peculiar
transactions (but I agree a separate specialized STC would be more of a
maintenance headache).
There is also an intermediate approach where you collect records by some
means and then periodically fire off a process or transaction to process
records collected since the last time the process was run.
Another consideration: If the current batch processing is done at a time
of lower system system load and involves significant work per record,
moving this processing into peak processing times could have significant
impact on your peak MSU requirement and a significant impact on your
costs. I suspect your record arrival rate is not a constant throughout
the day but also has its peaks. If those peak record arrival rates
actually correspond to current periods of peak system load, then the
impact on the peak system MSU requirements of moving this load would be
even greater than one would expect from the average record rate alone.
In other words, if there is a perceived business need to process the
records in a more timely manner, be sure those footing the bill are
aware it may not be a "free lunch".
JC Ewing
On 02/19/2012 04:04 PM, Ed Gould wrote:
Magen:
Not sure if this is what you are looking for but....
There is a facility called "execution batch monitoring" (at least in JES2)
You "feed" it input and it creates output (to your specifications). It
was originally designed for batch compiles but it could be adapted to
something like you want (?).
Ed
On Feb 19, 2012, at 3:25 PM, Magen Margalit wrote:
Hi list.
We have a daily betch job that is processing as input records which
has been collected all day.
volume of records is about 5 millions for 24 hours.
In order to make systems more "online" we are looking for a way to
run the process for each record all day long instead of a daily run,
and doing so with minimum as possible application changes.
One idea that came up is to convert the process to a "self developed" STC
which will be triggered by a record on an MQ queue and will run as STC
all the
batch process programs
To me it seems like a bad idea because having a "self developed" STC
in production
create a maintenance gap (and where there is one STC a second one
will soon to follow...)...
Are there other advantages / dis-advantages regarding a "self
developed" STC ?
Are there any "self developed" STC's at your shop?
Any other ideas on how to approach this issue?
Thanks in advanced.
Magen
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
