|
View previous topic :: View next topic
|
| Author |
Message |
Nirav721
New User
Joined: 11 Feb 2008
Posts: 53
Location: NJ
|
|
|
|
I have a dilemma..
I have a cobol module that CALLs DSNALI to bring up the db2 environment, and then it calls up to 60 modules that execute SQL statements. My problem is that the cobol module that CALLs DSNALI is being accessed up to 5000 times inside a batch job, and I do not want to keep bringing the region up 5000 times!!
The module leading off is an assembler module and I do not want to place DSNALI routine as it is the main module for everything, and want to make very minimal change to its processing....
I ran into a problem when the module calling DSNALI ran out of space on, I believe its 54th call! So, I need a way to save space and region...
Is there a way to bring up the 'DB2 Environment' just once when using CAF?
Any suggestions would be great...
Thanks,
Nirav |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
What is the reason that DB2 must be brought up from within this process?
You might consider putting this on the schedule as a successor to a new little process that would bring up DB2 as you need it.
Otherwise, i'd suggest making the simple change to bring up DB2 in the "lead off" module (or calling some simple COBOL code to do so). This would be "very minimal change to its processing". . .
There may be concerns that you haven't posted. If so, please clarify. |
|
| Back to top |
|
|
Nirav721
New User
Joined: 11 Feb 2008
Posts: 53
Location: NJ
|
|
|
|
Hi, thanks.
One of the reasons why we are trying to get away from creating a separate process is because of the overhead involved. As is, we are putting in a lot of overhead by creating 60 db2 modules and every minute is critical as we are thinking that a process that used to take 15 minutes will now be taking over 2 hours as we migrate from vsam to db2...
If there is no other alternative, then I think as you said, we are probably going to have to write a very small cobol stub module just to call dsnali and do nothing else....
I am not clear about the 'scheduler' part you mentioned, what is that? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| I am not clear about the 'scheduler' part you mentioned |
Most systems have a group of people who are responsible for scheduling jobs to be run on the manframe. This scheduling includes things like database and cics. They do their work using scheduling software.
If you talk with your scheduling people, they can explain which scheduling software is in use on your system and how you might use the scheduling system for your requirement(s).
| Quote: |
| a process that used to take 15 minutes will now be taking over 2 hours as we migrate from vsam to db2.. |
For my $.02, i'd be quite concerned about this. What caused the 8x increase in time? Done properly, the db2 process should not take 8x the vsam equivelent.
Someone may need to take a hard look at how the db2 tables and processes are implemented and fix them. . . |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
Ok, let' s see if I got it straight ...
level is the call nesting level
level 1 assembler program ( EXEC PGM=xxxxxx)
level 2 cobol module, gets called 5000 time from the assembler
level 3 sql modules ( 60 ) which get invoked each time
right ??? |
|
| Back to top |
|
|
Nirav721
New User
Joined: 11 Feb 2008
Posts: 53
Location: NJ
|
|
|
|
Yep Enricho, you got that right....
Oh, about 2 hours, we are just 'guestimating' the time at this time..but seeing how long read/writes are taking on just simple inserts/reads we were assuming it would take that long of a time..., but I could be wrong, and then I would be happy!!
I will look into scheduling... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| just simple inserts |
Often, inserts are not simple. . . At least not the internal processing required to insert a single row.
Has the system incorporated an acceptable on-line, single action process into a many action, poorly-performing batch process? Often, the way a "good" online transaction works will not work well (or sometimes not work at all) when used wholesale in batch. |
|
| Back to top |
|
|
Nirav721
New User
Joined: 11 Feb 2008
Posts: 53
Location: NJ
|
|
|
|
I am not sure, but I am just stumped to see the time for inserts/reads is identical!!
We have been told that production environment is faster than test environment so we only when we run temp-production we will really be able to find any real time... |
|
| Back to top |
|
|
|
|
