IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Array size in COBOL, S722 abend


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Vkp321

New User


Joined: 05 Jan 2009
Posts: 56
Location: Dublin

PostPosted: Tue Jul 02, 2013 5:30 pm
Reply with quote

Hi,

I have file with 450 records and internal array occurence was defined as 900 then job was failed.When I changed the array occurence to 800 it worked fine..If anyone has the idea what is the relation b/w array occurence and number of records in file ?
Back to top
View user's profile Send private message
Pandora-Box

Global Moderator


Joined: 07 Sep 2006
Posts: 1592
Location: Andromeda Galaxy

PostPosted: Tue Jul 02, 2013 5:38 pm
Reply with quote

Quote:
have file with 450 records and internal array occurence was defined as 900 then job was failed

Job failed for what reason mind sharing that?
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Tue Jul 02, 2013 5:40 pm
Reply with quote

WOW, with the amount of information you have given us it will take ages to go through it all.

Perhaps the abend code / reason code / additional information messages might just help people help you.

Unfortunately, psychic day was yesterday
Back to top
View user's profile Send private message
Vkp321

New User


Joined: 05 Jan 2009
Posts: 56
Location: Dublin

PostPosted: Tue Jul 02, 2013 5:53 pm
Reply with quote

Hi,

The job was failed with abend code S722. I put display in the program and can see the values but while searching it is not able to find
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Jul 02, 2013 5:57 pm
Reply with quote

Quote:
If anyone has the idea what is the relation b/w array occurence and number of records in file ?
The generic answer is that there is no relationship -- unless the program creates one. And what you have posted does not allow anyone to state whether or not there is such a relationship.

Under Enterprise COBOL (see the IBM Manuals link at the top of this page for the Language Reference manual Appendix B), an OCCURS can be up to 134217727 and the total size can be 134217727 bytes.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Jul 02, 2013 5:59 pm
Reply with quote

the only relation that should be enforced is ...
that the number of elements of the array should be greater than the number of records You are trying to fit into it.

the problem determination is pretty approximate IMO icon_cool.gif

Expat, I beg to disagree icon_wink.gif
according to my info
the day of the week best suited for divination is Wednesday
and the same for psychic ability is Saturday

and which skill to use depends on the tools/resources/objects available
none needed for psychic
blood, bones, feathers, corpses, ... might be needed for divination
an appropriate object for divination in IT could be a POST MORTEM DUMP

and what happened when You searched for s722 ???
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Tue Jul 02, 2013 6:04 pm
Reply with quote

And S722 abend is what ?

Have you found out what a S722 abend signifies and perhaps take into consideration the program change that you put in for testing
Back to top
View user's profile Send private message
Vkp321

New User


Joined: 05 Jan 2009
Posts: 56
Location: Dublin

PostPosted: Tue Jul 02, 2013 6:08 pm
Reply with quote

First I thought it is duw to outlim parameter (displaying the values not found in table) but when I go in detail I found the values were there in the file and array. As file was having less number of records I decreased the size of array and job ran fine it was just a try.Really dont know why it happend
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Jul 02, 2013 6:17 pm
Reply with quote

if You are happy we are happy - or better ... we do not care icon_cool.gif
as I said before You should investigate better the reasons
changing the dimensions of an array usually will just hide the error - until next time, it will not fix it.
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Tue Jul 02, 2013 6:19 pm
Reply with quote

Vkp321 wrote:
First I thought it is duw to outlim parameter (displaying the values not found in table) but when I go in detail I found the values were there in the file and array. As file was having less number of records I decreased the size of array and job ran fine it was just a try.Really dont know why it happend

Perhaps with less array elements to search, the number of output lines is decreased. Just a thought.
Back to top
View user's profile Send private message
Vkp321

New User


Joined: 05 Jan 2009
Posts: 56
Location: Dublin

PostPosted: Tue Jul 02, 2013 7:29 pm
Reply with quote

Hi,

SEARCH ALL is used to find the element, as I mentioned there were 450 records in file and array size is 900 (just double). Is there any possibility because of blank values in array program could not albe to find the value
Back to top
View user's profile Send private message
Vkp321

New User


Joined: 05 Jan 2009
Posts: 56
Location: Dublin

PostPosted: Tue Jul 02, 2013 7:32 pm
Reply with quote

Yes I think mid value will be blank first time
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Jul 02, 2013 7:37 pm
Reply with quote

In order to use SEARCH ALL, you must load the table elements in ascending order -- COBOL will not do this for you. Assuming that the blank value is in the proper location in the table, then there is no problem with having blanks for a key value. If the blank key is not properly placed in the key range, then yes of course you will have problems with your SEARCH ALL -- as you will for any key value that is not located in the proper location.
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India

PostPosted: Tue Jul 02, 2013 7:53 pm
Reply with quote

Vkp321 - Where do you write the output to? Is it a SYSOUT device or output file?
Back to top
View user's profile Send private message
Vkp321

New User


Joined: 05 Jan 2009
Posts: 56
Location: Dublin

PostPosted: Tue Jul 02, 2013 7:59 pm
Reply with quote

'Not found value" message to sysout
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India

PostPosted: Tue Jul 02, 2013 8:04 pm
Reply with quote

Vkp321 wrote:
'Not found value" message to sysout
Suggest you try an experiment - Use the same old logic you were using (when abend happened) and this time, instead of SYSOUT write 'Not found value' to a File with enough SPACE and see what happens?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Jul 02, 2013 8:07 pm
Reply with quote

How do you load the array? And how did you initialize the entire array before loading the key values into the array? Unless you place HIGH-VALUES (or some value greater than any key value in your file), then it is quite possible that SEARCH ALL will not find the key.

For example, if you placed SPACES in the table, and your first key value in element 1 is A and the last key value in element 450 is Z, with 900 elements in the array the first search would be element 451 (001 + 900 divided by 2, rounded up). If you are looking for key M, and the search started with element 451, well SPACE is less than M so the next element to be checked would be 676 (451 + 900 divided by 2, rounded up) and pretty quickly the key value of M is not found in all those SPACE elements.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Jul 03, 2013 12:31 am
Reply with quote

The first thing to note is that your program did not "work fine" after you changed the table size from 900 entries to 800.

You program may have run and appeared to work with the very limited amount of data you gave it, but that is a very different thing.

Try you program with:


  • Item "less than" the lowest possible value[/l]
  • Item "equal to" than the lowest possible value
  • Item "equal to" than the highest possible value
  • Item "greater than" the highest possible value
  • Other items, within the range, which match/don't match values, including consecutive ranges, "even" ranges and "odd" ranges


Then tell us its "fine".

As Robert has explained, with 450 entries containing data out of a 900-entry table, you will not get a single "hit". Personally I don't know "where" or "how" COBOL makes the split exactly, but Robert's 450+1 as the first entry SEARCH ALL looks at will ensure that you do not get a single "hit". This is whether the data you are loading are in order, or not.

It is vitally important for SEARCH ALL that your data is in order (by ASCENDING or DESCENDING) key. COBOL will do nothing to help you get it in order, that is up to you, and it will also do nothing to tell you the table is not in order if it is not.

If you want some fun, make your table size 900 again, and put 451 entries into it. That's one more than originally. Magic. "IT WORKS!".

Not really of course, because it fails for every case of fewer than 451 entries and does not work for all cases about 451 entries (try finding the last entry if you have 452 items in the table, for instance, yet you will be able to find the 676th (or so) if there is one).

What applies to a table of 900 entries, also applies to a table of 800 entries.

With 450 pieces of ordered data in an 800-entry table, you will be able to find every single one of the first 401 keys. After that, nothing. That's how much your program "worked fine".

Now, the next thing for you to do is to read the COBOL Language Reference. Look at the Programming Guide as well. Fully understand what it means when it states that the data must be in order (ascending or descending, your choice, but in order).

If a table is not "full", how do you make sure all the entries are "in order" if some are missing. Two ways.

Firstly, as Robert has said, you can set all unused entries to a key higher than the maximum possible. For this it is very convenient to use HIGH-VALUES. The most convenient time to do it is before any data is put into the table.

Note, that in this case, some time will be spent by SEARCH ALL looking for data and finding HIGH-VALUES more than once. The number of times, or the proportion of times, that this happens depends entirely upon your data.

Secondly, you can define the table with OCCURS DEPENDING ON. The value of the ODO item is set to the number of entries in your table. When you use SEARCH ALL on a table defined with ODO, COBOL will use the ODO value to know the size of the table, and will not search "outside" that value.

Because the length of the table is not known until the SEARCH ALL is executed, there is some additional overhead in this.

Whether one or the other is "faster" depends on your data.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed Jul 03, 2013 5:08 am
Reply with quote

This entire job-failure sounds fishy. What's going to happen when the number of records exceeds 450? With a WS Array, with a fixed occurs of 900, with which you perform a binary-search, before loading, the array must be initialized to HIGH-VALUES (unused entries will always exceed the value in any array-entry).

Better still (I'm biting my tongue because I've discussed this so many times), define the array to LINKAGE as an OCCURS DEPENDING ON (with a high number, such as 5000 to be safe), obtain the actual number of file-records, use CEEGTST to obtain dynamic-storage (number of file-records * 'N') plus 4 for the DEPENDING ON fullword and your done. Then, load the array and set the fullword.

When the JOB or STEP has completed, an internal CEEFRST is issued and the storage is returned back to the Operating System. No muss, no fuss....
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Jul 03, 2013 5:12 am
Reply with quote

Just to add to Mr Bill's comment, Enterprise COBOL V5.1 supports "unbounded" tables with OCCURS DEPENDING ON in the LINKAGE SECTION. This means that the size of the table need not have a maximum at compile time. "Under the covers", V5.1 is doing what Mr Bill suggests, a "formalisation" of the technique.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Jul 03, 2013 6:20 am
Reply with quote

Hello,

If there are 450 records in the file, how do account for more than this many "display"s?
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
No new posts COBOL ZOS Web Enablement Toolkit HTTP... COBOL Programming 0
No new posts Calling DFSORT from Cobol, using OUTF... DFSORT/ICETOOL 5
No new posts ISAM and abend S03B JCL & VSAM 9
No new posts Generate random number from range of ... COBOL Programming 3
Search our Forums:

Back to Top