Method to handle File-Status 46

pandey_nitin78 · New User Joined: 08 Aug 2005 Posts: 7

Hi ,

I have coded a match program wherein I am matching the records of 1 file with another and writing the
matched records to a 3rd file
for every record read from file-1 I am searching it in file-2 till EOF of file-2, The problem is after
the first search till EOF in file-2 the second search does not goes through file-2 and comes out of the
loop for file-2 giving (File-status-46,EOF for file-2 has already been reached)

Now I have changed the logic a bit and I am closing the file-2 as it reaches EOF and again opening and reading it
for the next record read in file-1

so for every record read in file-1 my program is open and close the file-2 and it's working file

I want to know is this approach ok or is there any other effective method to handle FILE-STATUS 46 ?

dbzTHEdinosauer · Posted: Thu Nov 06, 2008 3:28 pm

1. you should sort your both of your input files.

2. there is a sticky in the cobol forum about a match merge.

a well written program should never have a 46. you should not read if you have already reached eof. so the same indicator (hopefully you are using file-status - if file-status-ok then read ) to control the read would also control your compare process. if file-1 is at end, then file-2 would automatically be a non-match.

expat · Posted: Thu Nov 06, 2008 3:34 pm

Obviously the attributes of your files may prevent this, but have you considered using the field / file matching capabilities of the sort product rather than write your own.

picus_mf · New User Joined: 09 Jun 2006 Posts: 52

@pandey_nitin78
In your method, there will be lot many unncessary I-O calls which causes performance issues. Instead what you can do is read file-2 first, copy every record into the table (array). Next you read the file-1, search the record till end of the table.
In this way your code works in efficient way.

expat · Posted: Thu Nov 06, 2008 3:41 pm

pandey_nitin78 · New User Joined: 08 Aug 2005 Posts: 7

Hi picus_mf ,

Thinking of the point made by expat that it rather depend on the size of file 2 I have coded the program

I have nearly 200,000 records in file-2 , Whereas I won't be having more than 50-60 records in
file-1 (as application is designed so) , That's why I am reading the file-1 and making the search
against that record in file-2 (Top-to-bottom)
I think coding an array for that many records on file-2 will utilize more resource

Even though there would be many I/O in the method I am using (50-60) times , will this impact the
performance significantly

picus_mf · New User Joined: 09 Jun 2006 Posts: 52

Yes, if the size of the file is more then building the table also doesn't work efficiently.
Probably you can use ICETOOL to pick the common records. Regardless of the size this method can be effective.
OR
if your file-2 is VSAM KSDS file, then you should build the key and try to read the file. By this way the hits to file-2 will be the no of records in file-1.

pandey_nitin78 · New User Joined: 08 Aug 2005 Posts: 7

Hi Picus,

Thanks for reply , Files I am using for compare are both PS , Actually my need is to compare
the files for 3 varibles of the file layouts , That's why I thing ARRAy can't be used here and
I want to know that closing and opening of file-2 for every record read in file-1 to avoid
file-status 46 makes sense or not

Thanks in advance

enrico-sorichetti · Posted: Thu Nov 06, 2008 4:57 pm

I would not worry about the file status processing...

it' s the whole process logic, that does not make sense

what if the fifty records all fall into the lat 1000 range..
You will read for 200000 times 50 ==> 10 millions records

and again what if the record number will grow up to ... lets' s say 500
500 open and close.....
and same as above 200000 times 500 ==> 100 millions reads

review the process for a two file match approach
do not use a table
ensure that the input files are sorted...
yes, sort is smart to sort also on non-contiguous fields

pandey_nitin78 · New User Joined: 08 Aug 2005 Posts: 7

Thanks enrico

dick scherrer · Posted: Fri Nov 07, 2008 12:37 am

Hello,