COBOL Error

[Mairtin O'Droichid]

Hi

I am trying to increase a Working Storage area in a COBOL Program. Originally it was an OCCURS 99. I needed to change it to accomodate a three digit number, meaning that I need to change the OCCURS to a 999.

When I tried to compile, I got the following message:

%COBOL-F-ERROR 137, (1) Operand longer than 65535 bytes cannot be referenced

Thinking I had reached some sort of limit, I reduced the OCCURS to 299.

I compiled without error, yet whan I try to move zeroes to the first instance within the code, I get an Access Violation, reason mask 4.

It's an old VAX Running OpenVMS V7.3 (yeah, I know). I am long past regular contact with COBOL, so any any assitance would be most helpful.

[John Gillings · Accepted solution]

Mairtin,
I'm not sure I understand your statement:

>"I needed to change it to accomodate
>a three digit number, meaning that I
>need to change the OCCURS to a 999"

"three digit number" implies you're thinking about a PICTURE clause. PIC 99 is 2 digits, PIC 999 is 3 digits. However, the OCCURS clause is an array bound. OCCURS 99 means you're declaring an array with 99 elements, OCCURS 999 means and array with 999 elements, ie: your array is now 10 times larger than it was before.

VAX Cobol has a size limit of 64K bytes on some operations. It sounds like your array elements are larger than 64 bytes, and you're trying to use the whole array in a context that is size limited.

What does the entire object declaration look like? (exact source text) What statement are you using to access it, and what is the exact text of the ACCVIO message.

Can you also be more specific about "accomodating 3 digit numbers"? Does every 3 digit number really need an array element?

[Phil.Howell]

If you compile with /Map=declared, then the listing file shows the layout and size of storage used. Alignment rules can also affect the size of this.
Phil

[Mairtin O'Droichid]

Hi,

I can see the lack of clarity now. Sorry, it had been a looonnng day.

In a nutshell, I need to provide an array in WS to accomodate calculations on a group of figures. Previously, there had been only a max. of 99 of these, although the code was a 3 digit field. Declaration is as follows:

01 WS-TABLES.
464 *
465 * July 2006 - Limit increased to cater for three digit pay group
466 *
467 03 WS-PAY-GROUP OCCURS 299.
468 *
469 05 WS-PG-ACCR PIC S9(14)V99.
470 05 WS-FREQ-TAB PIC 99.
471 05 WS-PDCT PIC 99.
472 *
473 * Nov '98 change to 9 chars at MP3.
474 *
475 05 WS-PDTS OCCURS 10.
476 *
477 * Redefine to extract day element of date to calculate
478 * transaction date minus 12 for rationalised pay groups.
479 *
480 07 FILLER PIC X.
481 07 WS-PDTS-CCYY PIC 9999.
482 07 WS-PDTS-MM PIC 99.
483 07 WS-PDTS-DD PIC 99.
484 *
485 05 WS-BF-DAYS PIC 999.
486 05 WS-BF-NEG PIC X.
487 05 WS-CF-DAYS PIC 999.
488 05 WS-CF-NEG PIC X.
489 *
490 * Storage for the latest date for each Pay Group
491 *
492 05 WS-LATEST-PAYDATE.
493 07 FILLER PIC X.
494 07 WS-LATEST-CCYY PIC 9999.
495 07 WS-LATEST-MM PIC 99.
496 07 WS-LATEST-DD PIC 99.
497 *


Now with the advent of groupings greater than 99 (e.g. we now have group number 205 and 206), there was a need to increase the array size to accomodate these. I hoped that increasing the limit of possible entries to 999 would be the quick and easy solution. That caused a compile error. I then reduced this to 299, and, while it compliled error free (I had used the /NOWARN option), I ran the program and got the following runtime message:

%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000D070, PC=0000D0B6, PSL=0BC00000

%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
EURO_PACR EURO_PACR 587 00000B6 0000D086

The line is a move statement:

587 MOVE ZEROS TO WS-PG-ACCR(MOD1).

If there is a defined array limit, I will have to re-program to accomodate the actual number of codes being processed, although it is like to exceed 99 actual occurences.

[John Travell]

If you have a sparse array population, such that only a minority of possible numbers are used, you may wish to consider a level of indirection.
Put in a one dimensional lookup table large enough to hold all of the numbers you will ever use, then for each number you actually use, put the next free array index number into the table.

Your comment about 7.3.. This is the current and latest version for a VAX, so no need to expect any push to upgrade...

[Mairtin O'Droichid]

Thanks John,

Your point on the version of VMS is well understood.

I am old enough to remember VAXes from the early 80's and the sense of deja vu I experienced when I got to do the original 'once off' COBOL change made me very realistic about things.

I am now a line manager and the only one with any clue about COBOL on site(and even that's up for debate!).

I am trying to avoid any re-programming as it would change the nature of the code at a time when I have almost no time contingency. This is a time critical legacy application (that should have been replaced 5 years ago), so I was trying to avoid any such changes.

I compiled again using a reduced OCCURS (down to 299 as I don't expect to need any more than a maximum range of 300 possible items), which showed that the array takes up 37973, which is well below the 64K limit clobbered by the compiler. I will copy this .EXE in to be sure of this and re-run.

[Bojan Nemec]

Mairtin,

Looking to yours program I see that the problem is probably in line 588:

IF MOD1 < 999 GO TO BA01-ST.

should be:

IF MOD1 < 299 GO TO BA01-ST.

You pass the bounds of the table (and whole working-storage)!
To get a more apropriate error you can compile the program with /CHECK=BOUNDS (See HELP COBOL /CHECK).

Bojan

[Mairtin O'Droichid]

Hi Bojan

I came to the same conclusion at about 2:25 buit didn;t see your reply until now. I found a colleague of the same age (!) who was able to look with fresh eyes (as you have done too).

This change has been applied (all references are consistent) and now appears to be working.

Many thanks

[Wim Van den Wyngaert]

Also make sure that your table is indexed by variables with at least pic 999. A pic 99 might be too small. And there might be tests in the program like > 99 but also 100 and 98 and even 97 are very well possible.

Wim, ex-cobol programmer.

[Mairtin O'Droichid]

As per my last comment, the reason for the Access Violation was as Bojan had suggested, i.e. that the WS table had been reduced, but the subscript had not, meaning that the program tried to reference outside the bounds of the actual size of the WS Table.

[Wim Van den Wyngaert]

Diudn't see the enclosure (and the answer of Bojan).

On line 1190 there is an error with 99.

Wim

[Jan van den Ende]

Mairtin,

please view

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

about thanking those that helped.

Proost.

Have one on me.

jpe

[Mairtin O'Droichid]

Sláinte Jan, I have marked this with a 9!

All replies assisted me in tracing the capacity issue and the fresh pairs of eyes drew me to review the code. It;s such along time since I actualy programmed in COBOL (circa 1985, ahem), so it was a steep learning curve.

Thanks for the assistance. Keep up the good work!

MB