Re-reading a physical file in COBOL
Fatbloke
physical file in COBOL/400. The program has a calling CL program which
sets up a OVRDBF and a OPNQRYF.
I've tried to close the file after I'm finished with the first read and
then re-open the file again (still in the same program). However, I've
discovered that the next sequential read is not the first record on the
file, rather the one after the last record read on the previous pass.
It seems that the file pointer is not being reset by the close/open
commands.
What's going wrong here?
Any help is appreciated.
--
Steve.C remove "nospam4." from reply address if present
ICQ - 13986280
Visit me at http://www.bigfoot.com/~steve.conrad
Carnivorous Plants. Cadfael Chronicles. Hedgehog Homepage
Mike Cravitz
>I've a problem at work where I need to restart a sequential read on a
>physical file in COBOL/400. The program has a calling CL program which
>sets up a OVRDBF and a OPNQRYF.
>I've tried to close the file after I'm finished with the first read and
>then re-open the file again (still in the same program). However, I've
>discovered that the next sequential read is not the first record on the
>file, rather the one after the last record read on the previous pass.
>It seems that the file pointer is not being reset by the close/open
>commands.
I want to make 4 points.
1) One possible source of confusion is maybe one or more of the key
fields are specified as Descending. This can lead to confusion
because, the highest value is first in the file. Another possibility
is for some reason the Close is failing. If you specified a file
status in the Select clause, you should check the file status (with
the debugger at least) after the close to make sure it is working.
2) Another possibility is you are sharing the open data path. If that
is the case, then closing and reopening a file will have no effect on
the file cursor. Perhaps you have a CL driver that issues the command
OvrDbf YourFile Share(*Yes). When this is in effect, forget about
repositioning the file cursor via open/close.
3) This is really a horrible way to acomplish what you're trying to
acomplish. On any system and on the AS/400 in particular, a full close
and a full reopen are resource intensive operations. Use the Cobol
Start statement instead. Suppose we're talking about the Customer file
which is keyed by CuNum ascending. Then a far better way to reposition
the file cursor at the beginning of the file would be....
Move Low-Values to CuNum.
Start Customer Key is Greater Than or Equal to
Externally-Described-Key.
4) Visit us at NEWS/400's Cobol community forum where we love to
answer questions like this. Just point your browser at
http://www.news400.com/redir/redir.cfm?story=/cobol/index.htm and
click on Cobol Forum. See you there!
Mike Cravitz
NEWS/400 Technical Editor
Fatbloke
> Steve,
>
<snip>
> >I've tried to close the file after I'm finished with the first read and
> >then re-open the file again (still in the same program). However, I've
> >discovered that the next sequential read is not the first record on the
> >file, rather the one after the last record read on the previous pass.
> >It seems that the file pointer is not being reset by the close/open
> >commands.
>
> I want to make 4 points.
>
> 1) One possible source of confusion is maybe one or more of the key
> fields are specified as Descending. This can lead to confusion
> because, the highest value is first in the file. Another possibility
> is for some reason the Close is failing. If you specified a file
> status in the Select clause, you should check the file status (with
> the debugger at least) after the close to make sure it is working.
>
> 2) Another possibility is you are sharing the open data path. If that
> is the case, then closing and reopening a file will have no effect on
> the file cursor. Perhaps you have a CL driver that issues the command
> OvrDbf YourFile Share(*Yes). When this is in effect, forget about
> repositioning the file cursor via open/close.
need *SHR otherwise we'll never get a chance to use the file! Looks like a
new logical is on the way...
>
> 3) This is really a horrible way to acomplish what you're trying to
> acomplish. On any system and on the AS/400 in particular, a full close
> and a full reopen are resource intensive operations. Use the Cobol
> Start statement instead. Suppose we're talking about the Customer file
> which is keyed by CuNum ascending. Then a far better way to reposition
> the file cursor at the beginning of the file would be....
>
> Move Low-Values to CuNum.
> Start Customer Key is Greater Than or Equal to
> Externally-Described-Key.
access is usually done via logicals but this file is from a third-party
and logicals based on these type of files are normally not the first thing
we try according to our work standards... perhaps this will have to
change!
>
> 4) Visit us at NEWS/400's Cobol community forum where we love to
> answer questions like this. Just point your browser at
> http://www.news400.com/redir/redir.cfm?story=/cobol/index.htm and
> click on Cobol Forum. See you there!
>
> Mike Cravitz
>
> NEWS/400 Technical Editor
--
Dan Smith
<snip>
> > Move Low-Values to CuNum.
> > Start Customer Key is Greater Than or Equal to
> > Externally-Described-Key.
> But this file has no key. It is a basic unsequenced physical file. Key
> access is usually done via logicals but this file is from a third-party
> and logicals based on these type of files are normally not the first
thing
> we try according to our work standards... perhaps this will have to
> change!
is this a file that could be read as a relative file? i seldom read a file
as straight sequential, but prefer to read as a relative, or relative
sequential. to restart the file just set the relative key back to 1.
Gernot B Längle
Fatbloke wrote:
>
> I've a problem at work where I need to restart a sequential read on a
> physical file in COBOL/400. The program has a calling CL program which
> sets up a OVRDBF and a OPNQRYF.
> I've tried to close the file after I'm finished with the first read and
> then re-open the file again (still in the same program). However, I've
> discovered that the next sequential read is not the first record on the
> file, rather the one after the last record read on the previous pass.
> It seems that the file pointer is not being reset by the close/open
> commands.
>
> What's going wrong here?
>
> Any help is appreciated.
>
> --
> Steve.C remove "nospam4." from reply address if present
> ICQ - 13986280
> Visit me at http://www.bigfoot.com/~steve.conrad
> Carnivorous Plants. Cadfael Chronicles. Hedgehog Homepage
--
Gernot Langle
PARAS Solutions, Inc.
http://www.parassolutions.com
mailto:gla...@parassolutions.com
Mike Cravitz
file. The following example uses a file that happens to be keyed on my
system. However, I am treating as if it wasn't.
Identification Division.
Program-Id. TEST1.
Environment Division.
Input-Output Section.
File-Control.
Select CustFile
Assign to Database-CUSTOMER
Organization is Relative
Access is Dynamic
File Status is CustSts
Relative Key is CuRelRecNo.
Data Division.
File Section.
FD CustFile.
01 CustRec.
Copy DDS-CUSREC of Customer.
Working-Storage Section.
01 CustSts Pic X(02).
88 CustEof Value "10".
01 DsplySts Pic X(02).
01 CuRelRecNo Pic 9(07) Packed-Decimal.
Procedure Division.
Test1Main.
Open Input CustFile.
Perform With Test After
Until CustEof
Read CustFile Next
At End
Continue
Not At End
Continue
End-Read
End-Perform.
Move 1 to CuRelRecNo.
Start CustFile
Key is Greater Than or Equal to
CuRelRecNo
End-Start.
Read CustFile Next
At End
Continue
Not At End
Continue
End-Read.
Close CustFile.
Stop Run.
Notice, even though I specify relative organization, I can read
sequentially through the file. The Start statement positions the file
pointer to the beginning of the file. I tested this.
Koos Bezemer
I don't know Cobol, but in RPG you can point (CHAIN, SETLL, etc) in a
sequential file with the record sequence number. By positioning to "00001",
you effectively set your pointer to the first record in the file. Do it all
the time.
No need to open and close.
Should work in Cobol as well,
Koos