| View previous topic :: View next topic |
| Author |
Message |
sinduja
Beginner
Joined: 20 Jun 2005
Posts: 29
Topics: 14
|
 Posted: Mon Nov 21, 2011 1:34 am Post subject: IMS Program Performance issue |
 |
|
Hello all,
I have a performance problem with one of my IMS programs.
The program is a very simple one so we have no clue as to why it is taking such a long time.
The details are as follows.
PROGRAM
Program just reads a input file, reads a IMS DB for some information and then writes an output file.
The IMS fetch is done with the below DLI call
| Code: | EXEC DLI GU
USING PCB (2)
SEGMENT (ZPSRT)
INTO (ZPS01)
KEYS (ZW-PSD-ROOT-KEY)
END-EXEC. |
PCB is as follows
PCB
TYPE=DB,DBDNAME=ZPS0,PROCOPT=GOT,KEYLEN=12,POS=SINGLE
SENSEG NAME=ZPSRT,PARENT=0
FILES USED
Input file has some 2.7 million records.
IMS fetch happens for around 9 lakh records.
Time taken
STEPNAME PROCSTEP RC EXCP CPU SERV PROCESSING UNITS
ZPS09200 S200A20 00 1421K 1.13 4503K 57'776
IMS Monitor result
| Code: | *********************************** DBSS / IMS MONITOR
* --------------------- DLI CALL COUNTS --------------------------
* GU 0 GHU 957'366 ISRT 0
* GN 0 GHN 0 DLET 0
* GNP 0 GHNP 0 REPL 0
* -------------------------------------- BUFFER POOL -------------------------
* --ID-- ---SIZE-- --REC-INS-- --REC-ALT-- ---GETS------READS--WRITES
* XXXX-D 2048- 10 0 0 0 0 0
* XXXX-D 4096- 10 0 0 860'823 860'786 0
|
DBRC Monitor
| Code: | *********************************** DBSS / DBRC MONITOR
* ----------------- LOG ALLOCATION ---------------------------
* PRILOG IEFRDER CHZILPUS.ZLS09200.RLDS.D11322.T1112099
* SECLOG IEFRDER2
* START TIME 11.322 11.12.15.9
* STOP TIME 11.322 13.37.33.2
*********************************** DBSS / DBRC MONITOR |
Can some one guice me as to what is causing the program to run for a long time?
Thank you
Regards,
Sinduja |
|
| Back to top |
|
 |
Anuj Dhawan
Intermediate
Joined: 19 Jul 2007
Posts: 298
Topics: 7
Location: Mumbai,India
|
| Posted: Mon Nov 21, 2011 1:54 am Post subject: |
|
|
1.13 of CPU for 2.7 million input records is good enough from performance per se, no?
Are you talking about elapsed time, by any chance?
_________________
Regards,
Anuj |
|
| Back to top |
|
|
sinduja
Beginner
Joined: 20 Jun 2005
Posts: 29
Topics: 14
|
| Posted: Mon Nov 21, 2011 2:35 am Post subject: |
|
|
Yes. The elapsed time is 2.5 hours.
I forgot to mention that  |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
| Posted: Mon Nov 21, 2011 11:13 am Post subject: |
|
|
| sinduja wrote: | | Program just reads a input file, reads a IMS DB for some information and then writes an output file. |
sinduja,
How is the input/output file defined? Poorly coded Blocksizes can account to longer elapsed times.
Show us the definition of the input/output file and JCL declaration of the files.
Kolusu |
|
| Back to top |
|
|
sinduja
Beginner
Joined: 20 Jun 2005
Posts: 29
Topics: 14
|
| Posted: Tue Nov 22, 2011 12:39 am Post subject: |
|
|
Hi Kolusu,
Input file 1:
This file is created in a sort before the program step. This file has 2.7 million records
| Code: | OUTQS01 DD DSN=ZG&STUFE.A.R2.GP0.MORIZZ.FILE00.CSV0,
DISP=(,CATLG,DELETE),
SPACE=(CYL,(100,50),RLSE),
RECFM=FB,LRECL=616 |
Input file 2:
Not created in our job. This file has 1.16 lakh records.
| Code: | General Data
Management class . . : R2
Storage class . . . : LARGE
Volume serial . . . : GXR143
Device type . . . . : 3390
Data class . . . . . : PROD
Organization . . . : PS
Record format . . . : FB
Record length . . . : 100
Block size . . . . : 27900
1st extent kilobytes: 11606
Secondary kilobytes : 20000
Data set name type :
SMS Compressible. . : NO |
Output file:
This file will also have 2.7 million records after program execution.
| Code: | OUTFILE DD DSN=ZG&STUFE.A.R2.S00.MORIZZ.FILE00,
DISP=(,CATLG,DELETE),
SPACE=(CYL,(1000,200),RLSE),
RECFM=FB,LRECL=631 |
Also one more information that could be relevant.
The input file 2 is opened and closed n number of times as a part of the processing.
This is done approximately around 7000 times in the current run.
I can and I am going to eliminate this open and close logic and handle it in a better way. But can this be the reason for the long elapsed time?
Thanks,
Sinduja |
|
| Back to top |
|
|
papadi
Supermod
Joined: 20 Oct 2009
Posts: 594
Topics: 1
|
| Posted: Tue Nov 22, 2011 1:56 am Post subject: |
|
|
| Quote: |
The input file 2 is opened and closed n number of times as a part of the processing.
|
Usually, this is a complete "process killer". Rarely has anyone posted a good reason to open and close over and over. . .
It doesn't matter if someone has called this a requirement. The requirement is to get the desired output, correctly every time, with only a modest use of system resources.
While not the reply you want, correcting the design will serve you well.
_________________
All the best,
di
Last edited by papadi on Wed Nov 23, 2011 1:51 pm; edited 1 time in total |
|
| Back to top |
|
|
Anuj Dhawan
Intermediate
Joined: 19 Jul 2007
Posts: 298
Topics: 7
Location: Mumbai,India
|
| Posted: Tue Nov 22, 2011 2:29 am Post subject: |
|
|
Multiple OPEN and CLOSE for a given file in the same program is not good programming - what's the reason to do it?
As you talk about IMS, are the input files GSAM and they are DLI OPEN/CLOSE? If yes, a redesign of the program is on its way.
From your first post, your program issue a GU - I believe for every read from the input file, yes? If so make use of the property the way IMS is loaded. IMS is loaded with key sequence, break your input file to multiple files on the DB keys in ascending and descendin order - and execute multiple jobs. And don't foreget about using differnt PSBs for different Jobs then you can run all those jobs in parallel.
_________________
Regards,
Anuj
Last edited by Anuj Dhawan on Mon Dec 05, 2011 2:20 am; edited 1 time in total |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
| Posted: Tue Nov 22, 2011 12:57 pm Post subject: |
|
|
| sinduja wrote: |
Also one more information that could be relevant.
The input file 2 is opened and closed n number of times as a part of the processing.
This is done approximately around 7000 times in the current run.
I can and I am going to eliminate this open and close logic and handle it in a better way. But can this be the reason for the long elapsed time?
Thanks,
Sinduja |
Sindhuja,
I asked for FILE declarations in the program too. I don't see the JCL having any Blocksize coded.
Opening a file 7000 times in a single program? I am guessing that this program is a simple match of 2 input files and if matched go get the data from IMS database and write it to the output. If that is indeed the case then look at the COBOL code here for matching 2 files
http://www.mvsforums.com/helpboards/viewtopic.php?t=11 |
|
| Back to top |
|
|
sinduja
Beginner
Joined: 20 Jun 2005
Posts: 29
Topics: 14
|
| Posted: Wed Nov 23, 2011 5:17 am Post subject: |
|
|
Hi all,
I can understand that the multiple open/close is a very poor logic. (We were feeling guilty too, to write such a program  )
We did it because we had just 4 hours to code and move a new program to UAT (some lousy management mistake which left us with such a tight deadline)
The program is now back with us for performance issue. So we are changing the programs to correct all the blunder. 
| Quote: | | I asked for FILE declarations in the program too. I don't see the JCL having any Blocksize coded. |
Here it is
| Code: | FD INPUT-FILE
RECORDING MODE IS F
RECORD CONTAINS 616 CHARACTERS
BLOCK CONTAINS 0 RECORDS
LABEL RECORDS ARE STANDARD.
01 IN-FILE-REC PIC X(616).
FD INPUT-FILE2
RECORDING MODE IS F
RECORD CONTAINS 100 CHARACTERS
BLOCK CONTAINS 0 RECORDS
LABEL RECORDS ARE STANDARD.
01 IN-FILE-REC2 PIC X(100).
FD OUTPUT-FILE
RECORDING MODE IS F
RECORD CONTAINS 631 CHARACTERS
BLOCK CONTAINS 0 RECORDS
LABEL RECORDS ARE STANDARD.
01 OUTPUT-FILE-REC PIC X(631). |
We don't usually code BLKSIZE in JCL. (Will the optimum BLKSIZE be chosen if we do not explicitly specify it???) Please guide me as to what would be the best practice.
Meanwhile, we have found out that 98% of the time has been spent waiting for the DB and not in processing.
The GU call issued in the program has been executed as GHU call (as we saw in the IMS montior).
Can this happen?
If so Under what conditions does a GU call get executed as a GHU call?
And Could this be the reason for the long waiting time??
Still searching for the answer
Thank you for all the replies and suggestions
Regards,
Sinduja |
|
| Back to top |
|
|
Anuj Dhawan
Intermediate
Joined: 19 Jul 2007
Posts: 298
Topics: 7
Location: Mumbai,India
|
| Posted: Wed Nov 23, 2011 11:16 am Post subject: |
|
|
You are using command level interface for DLI Calls -- so Get commands are just like Get Hold calls, and the performance of Get commands and Get calls is the same.
You might also like to read the last para of my previous reply.
_________________
Regards,
Anuj
Last edited by Anuj Dhawan on Thu Nov 24, 2011 1:54 am; edited 1 time in total |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
| Posted: Wed Nov 23, 2011 11:19 am Post subject: |
|
|
| sinduja wrote: |
| Code: | BLOCK CONTAINS 0 RECORDS
BLOCK CONTAINS 0 RECORDS
BLOCK CONTAINS 0 RECORDS
|
|
I was looking for these and it is good that you have them
| sinduja wrote: |
We don't usually code BLKSIZE in JCL. (Will the optimum BLKSIZE be chosen if we do not explicitly specify it???) Please guide me as to what would be the best practice. |
Unless your shop has the SDB parm on you are creating the file with the BLKSIZE same as your LRECL. What is the blksize of the output file you created in the program?
| sinduja wrote: |
Meanwhile, we have found out that 98% of the time has been spent waiting for the DB and not in processing.
The GU call issued in the program has been executed as GHU call (as we saw in the IMS montior).
Can this happen?
If so Under what conditions does a GU call get executed as a GHU call?
And Could this be the reason for the long waiting time??
|
Well you need to check if there are any re-org jobs running at the same on the IMS DB.
Other option is to put displays of timestamps before and after the IMS calls for a small volume of data and check the times.
| Code: |
01 WS-BEFORE-TSTAMP PIC X(16).
01 WS-AFTER-TSTAMP PIC X(16).
MOVE FUNCTION CURRENT-DATE(1:16) TO WS-BEFORE-TSTAMP
DISPLAY 'BEFORE DLI CALL TIMESTAMP : ' WS-BEFORE-TSTAMP
EXEC DLI CALL...
MOVE FUNCTION CURRENT-DATE(1:16) TO WS-AFTER-TSTAMP
DISPLAY 'AFTER DLI CALL TIMESTAMP : ' WS-AFTER-TSTAMP
|
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
