Page 1 of 1

Regarding 16MB line

PostPosted: Tue Jun 30, 2009 11:42 am
by deepu_1156
Hi,

I had to increase size of an array in a COBOL by 10 fold. As the size of array is huge now, I made the program to use 31 bit addressing by specifying PROCESS DATA(31) option in program. This program calls another program which is still executing below 16MB line (bcos AMODE(24) and RMODE(24) compile options).

Once I moved the above changes, program is taking lot of execution time. There are no other changes in the program. There is no sequential search or searchall queries on the arrays whose size I increased. Is the decrease in performance due to programs executing in different regions?

I also observed that the number of lines of display showing EXCP count for each DDname in JESYSMSG is also increased. If there were 5 instances of
"IFK112AI D-5870 26"for a DD name IFk112AI previously, now it has become 8 instances. Same is happening with all other DD names in the step. I dont know whether it is because of my change.

Can somone provide any help/pointers on this?

Thanks,
Sandeep

Re: Regarding 16MB line

PostPosted: Tue Jun 30, 2009 6:28 pm
by dick scherrer
Hello,

Why would an array be increased "10 fold" and there be no expectation for a change in performance?

If the array is not searched, why is it needed (and why the increase)?

I suspect that either there was another change somewhere or that processing the expanded array(s) takes longer than the original.

For a complete understanding of the IFk112AI messages, suggest you read about this in the Messages and Codes manual.

Re: Regarding 16MB line

PostPosted: Tue Jun 30, 2009 6:59 pm
by deepu_1156
We increased array size to hold more data in future. As of now, the same amount of data flows in the system. There is no search on array because we are directly accessing the array elements using some key field as Offset. As far as the array processing is concerned, there shouldn't be any change in performance other than the memory allocated for this array (as the amount of data is same).

My doubt is "If calling and called programs lie above and below 16MB line and if there are multiple calls between them, will there be any performance degradation?"

Re: Regarding 16MB line

PostPosted: Wed Jul 01, 2009 12:22 am
by dick scherrer
Hello,

You need to find the explanation of the IFk112AI messages. I can find no reference to this message id, so i suspect that you need to talk with your system support people about what generated these.

I'm not aware of any performance degredation when a process runs both over and under "the line" (which is quite common).

Re: Regarding 16MB line

PostPosted: Wed Jul 01, 2009 9:12 pm
by deepu_1156
Thanks.

IFK112AI is a DD name. This is not a mesasge code.

Re: Regarding 16MB line

PostPosted: Thu Jul 02, 2009 1:13 am
by dick scherrer
Hello,

IFK112AI is a DD name. This is not a mesasge code.
Oh. . . :?

What message id is shown when these are generated?

Re: Regarding 16MB line

PostPosted: Thu Jul 02, 2009 8:00 pm
by deepu_1156
Hi,

There are no error messages or codes. I was talking about the number of I/O operations shown in JESYSMSG related to this particular step. There is increase in number of display lines even though the total I/O is same from the previous version. I guess this is because we changed one of the VSAM files to Spanned.

But the file is very small having only 10 records. That shouldn't be causing such a serious issue in performance. As 16MB line is not the problem, I have to look at the other possibilities.

Thanks,
Sandeep

Re: Regarding 16MB line

PostPosted: Thu Jul 02, 2009 11:05 pm
by dick scherrer
Hello,

I suspect the code is the culprit. I also suspect that it is somehow looping thru the entire array (possibly not for the "direct" access, but rather for something else).

You might try cutting the new array in half and see what difference this makes on performance.

Re: Regarding 16MB line

PostPosted: Mon Jul 06, 2009 1:11 pm
by Anuj Dhawan
After reading thorigh the thread, I'm not very sure about the situation at your end -- may be you can use "Dynamic table" instead of using some "static-table". Just a guess...