Regarding 16MB line



Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

Regarding 16MB line

Postby deepu_1156 » Tue Jun 30, 2009 11:42 am

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
deepu_1156
 
Posts: 6
Joined: Tue Jun 02, 2009 5:51 am
Has thanked: 0 time
Been thanked: 0 time

Re: Regarding 16MB line

 

Re: Regarding 16MB line

Postby dick scherrer » Tue Jun 30, 2009 6:28 pm

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.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: Regarding 16MB line

Postby deepu_1156 » Tue Jun 30, 2009 6:59 pm

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?"
deepu_1156
 
Posts: 6
Joined: Tue Jun 02, 2009 5:51 am
Has thanked: 0 time
Been thanked: 0 time

Re: Regarding 16MB line

Postby dick scherrer » Wed Jul 01, 2009 12:22 am

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).
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: Regarding 16MB line

Postby deepu_1156 » Wed Jul 01, 2009 9:12 pm

Thanks.

IFK112AI is a DD name. This is not a mesasge code.
deepu_1156
 
Posts: 6
Joined: Tue Jun 02, 2009 5:51 am
Has thanked: 0 time
Been thanked: 0 time

Re: Regarding 16MB line

Postby dick scherrer » Thu Jul 02, 2009 1:13 am

Hello,

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

What message id is shown when these are generated?
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: Regarding 16MB line

Postby deepu_1156 » Thu Jul 02, 2009 8:00 pm

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
deepu_1156
 
Posts: 6
Joined: Tue Jun 02, 2009 5:51 am
Has thanked: 0 time
Been thanked: 0 time

Re: Regarding 16MB line

Postby dick scherrer » Thu Jul 02, 2009 11:05 pm

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.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: Regarding 16MB line

Postby Anuj Dhawan » Mon Jul 06, 2009 1:11 pm

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...
Anuj
Anuj Dhawan
 
Posts: 274
Joined: Mon Feb 25, 2008 3:53 am
Location: Mumbai, India
Has thanked: 6 times
Been thanked: 4 times


Return to IBM Cobol

 


  • Related topics
    Replies
    Views
    Last post