View previous topic :: View next topic
|
Author |
Message |
k99x
New User
Joined: 22 Mar 2010 Posts: 7 Location: Amsterdam
|
|
|
|
Hi
My online programs run on the IMS DC environment. I want to use the global storage to cache data during runtime to avoid repetitive DB2/IMS DB calls(these redundant calls happen at different levels in the call chain, so updating the linkage to pass the data is not an option). Any idea on how it can be done?
Also, I want to remove the database calls so as to improve the performance of the transactions. Hope the access/update of global storage during run time does not take as much time as the DB calls.
Regards,
k99x. |
|
Back to top |
|
|
manikawnth
New User
Joined: 07 Feb 2007 Posts: 61 Location: Mumbai
|
|
|
|
Hi,
It requires some clarification.
I want to know within one transaction u want to avoid multiple calls to DB and store the data OR
U want to carry forward the data to successive transactions.
Second one is almost impossible unless if it is very less data and store in some hidden fields of MFS.
If your question is first one, then kindly post this query as separate thread in the corresponding application language forums.
Thanks,
Manikanth |
|
Back to top |
|
|
k99x
New User
Joined: 22 Mar 2010 Posts: 7 Location: Amsterdam
|
|
|
|
It''s the first one. If there is a program call chain
A->B->C->DB2 and A-> X -> Z ->DB2, I want to use the data retrieved by C in Z , without modifying the linkage, so as to avoid the second DB2 call.
The programs run on the IMS DC environment. That is why I posted the query here.
k99x. |
|
Back to top |
|
|
Gary Jacek
New User
Joined: 17 Dec 2007 Posts: 64 Location: Victoria, BC, Canada
|
|
|
|
Based upon your question, I assume your are not a DBA, IMS Sysprog or mainframe performance analyst.
It sounds to me like you want to keep data in memory in order to avoid the cost of I/O. But have you thought about how to ensure that data is kept current with updates from other tasks? Are your updates into memory being logged and are they recoverable?
The person who must maintain this AFTER YOU HAVE DEPARTED wants YOU to do this in a standard, maintainable, tuneable way, to ensure that all of the questions listed above have been addressed. I know I would.
If your databases are OSAM, as opposed to VSAM, might I suggest that you dedicate OSAM buffers to them? This will use IMS code to improve access while addressing all of those other DBA concerns. This will also execute code that runs in thousands of IMS shops worldwide. As IMS evolves, that code will be improved and rigourously tested. A very good thing all around.
If you look in your IMS Control Region JCL for the //PROCLIB DD, and then search for member DFSPB* in this dataset, you will find a value "VSPEC=*". More than one DFSPB** member? Then look in the IMS Control Region JESMSGLog to see which is being used.
Next, look in the same PDS for member DFSVSMnn where "nn" is the VSPEC value from your active DFSPBxxx member.
You have now arrived at the VSAM and OSAM buffer definitions for this IMS control region.
Adding three entries like this:
IOBF=(18432,1024,N,N,BP25)
DBD=MYDB01(1,BP25)
DBD=MYDB05(2,BP25)
will create an in-memory OSAM buffer pool called BP25,
containing 1024 buffers of 18432 bytes each. IMS will be instructed to buffer the 1st dataset defined for database MYDB01 and the 2nd dataset defined for database MYDB05 into your new BP25 OSAM buffer pool.
I assume here that your OSAM database blocksize is 18432.
It will be a good thing if you observe the blocksize of your database datasets in order to allocate the correct bufferpool blocksize for each OSAM bufferpool that you create.
Look up DFSVSMxx proclib member in your IMS manuals for the full details, and go talk to your DBA.
When I last checked, you could allocate an aggregate of 2GB into OSAM buffer pools. Of course, IBM will be happy to sell you enough real storage to back that virtual memory, in order to keep your MVS paging rate in a reasonable range.
IMS does all the heavy lifting here, and makes you look good.
Gary |
|
Back to top |
|
|
k99x
New User
Joined: 22 Mar 2010 Posts: 7 Location: Amsterdam
|
|
|
|
Hi Gary,
Thnx for the info.
I am a programmer working on a performance enhancement project. The transactions I am working on have very large call chains and heavy DB2 calls. The call chains are so big that the transactions are running with PROCLIM 0. So I have 2 issues to solve: the programs being loaded into memory has to be reduced (somehow) and the DB2 calls have to be minimised.
The data that I am planning to store in the cache is only static data. So there is no worry that other tasks would update it. My worry is that the data stored in cache by declaring the variable as EXTERN will give me another issue cos this data will also be stored as DATA24. This will further deplete the memory of the transactions..on the other hand, some repetetive DB2 calls can be avoided.
I am under the immpression that the underlying databases are VSAM but I 'll need to recheck to be sure.
I am sorry but I did not understand much about allocation of buffers. What would the allocation of buffers accomplish?
Kiran |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
If your situation is like very many others i've seen, the "problem" is largely the resources needed to support the db2 part of the equation.
Which means that lots of ims tuning will have rather little impact.
As with other tuning opportunities, an early task is to quantify which part(s) of the process(es) require/waste the most resources.
Much of what you want to do will be best served when the database and system engineers participate. |
|
Back to top |
|
|
Gary Jacek
New User
Joined: 17 Dec 2007 Posts: 64 Location: Victoria, BC, Canada
|
|
|
|
If your MPP application is running in IMS DC calling DB2 and you are sure your programs are reusable, you should investigate using PWFI (Pseudo Wait For Input) MPRs (Message Processing Regions). If you dedicate one or more MPRs for each "popular" transaction code, you will see performance gains. We have observed that this is especially true with applications that call DB2.
zOS recently announced a system managed VSAM buffers function. This may help you. Until then, the buffer definitions for your VSAM clusters should be examined.
Involving your DBA/Systems/Performance people is a very good idea. |
|
Back to top |
|
|
k99x
New User
Joined: 22 Mar 2010 Posts: 7 Location: Amsterdam
|
|
|
|
Thnx guys. There are performance tuning guys working along with me. While they llok at technical solutions, I am looking for workarounds like minimising DB2 calls etc. That's why I was exploring the caching option.
The transactions that I am looking at are already working on 4 different IMS regions.
Kiran |
|
Back to top |
|
|
|