Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Method to handle File-Status 46

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
pandey_nitin78

New User


Joined: 08 Aug 2005
Posts: 7

PostPosted: Thu Nov 06, 2008 3:15 pm    Post subject: Method to handle File-Status 46
Reply with quote

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 ?
Back to top
View user's profile Send private message

dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Nov 06, 2008 3:28 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8593
Location: Back in jolly old England

PostPosted: Thu Nov 06, 2008 3:34 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
picus_mf
Warnings : 1

New User


Joined: 09 Jun 2006
Posts: 51

PostPosted: Thu Nov 06, 2008 3:34 pm    Post subject: Reply to: File-Status 46
Reply with quote

@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.
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8593
Location: Back in jolly old England

PostPosted: Thu Nov 06, 2008 3:41 pm    Post subject: Re: Reply to: File-Status 46
Reply with quote

picus_mf wrote:
@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.

Doesn't that rather depend on the size of file 2 ?
Back to top
View user's profile Send private message
pandey_nitin78

New User


Joined: 08 Aug 2005
Posts: 7

PostPosted: Thu Nov 06, 2008 3:58 pm    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
picus_mf
Warnings : 1

New User


Joined: 09 Jun 2006
Posts: 51

PostPosted: Thu Nov 06, 2008 4:30 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
pandey_nitin78

New User


Joined: 08 Aug 2005
Posts: 7

PostPosted: Thu Nov 06, 2008 4:41 pm    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10210
Location: italy

PostPosted: Thu Nov 06, 2008 4:57 pm    Post subject: Reply to: Method to handle File-Status 46
Reply with quote

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
Back to top
View user's profile Send private message
pandey_nitin78

New User


Joined: 08 Aug 2005
Posts: 7

PostPosted: Thu Nov 06, 2008 5:17 pm    Post subject:
Reply with quote

Thanks enrico
Back to top
View user's profile Send private message
dick scherrer

Site Director


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

PostPosted: Fri Nov 07, 2008 12:37 am    Post subject:
Reply with quote

Hello,

Quote:
Instead what you can do is read file-2 first, copy every record into the table (array).
This should never be used to accomplish a 2-file match. . . icon_sad.gif It is a very bad choice.

Coded properly, the 2-file match need only read each record in both files one time and there is no waste of cpu cycles searching some internal array.

As was mentioned, there is a "sticky" near the top of the COBOL part of the forum that comtains source that is currently running in production on very many systems.

Download that source and review it. If you have any questions, please post a reply here. SOmeone will be able to clarify.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts SORTJOIN - Copy Matched and Unmatched... Steve Ironmonger DFSORT/ICETOOL 5 Tue Jan 17, 2017 4:26 pm
No new posts Copy RECFM =VB TO FB file with RECL =... sahil41352 DFSORT/ICETOOL 3 Wed Dec 28, 2016 11:29 pm
This topic is locked: you cannot edit posts or make replies. session stuck in TPX with status ACL amitc23 CA Products 1 Tue Dec 13, 2016 12:53 pm
No new posts Add PD field from 2nd file to PD in 1st Sushant Garje DFSORT/ICETOOL 6 Thu Dec 01, 2016 4:32 pm
No new posts File Aid to File Manager conversion murali3955 IBM Tools 4 Thu Nov 24, 2016 3:41 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us