× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]



Assuming ACCESS is Dynamic:

The type of READ is determined by the words after the file name, more so
than the word NEXT.

For example:

READ filename INVALID KEY ...               returns a record based on the
matching key.

READ filename NEXT ...                             returns the next
sequential record in key sequence, but not necessarily a matching key.

Unfortunately, Cobol doesn't have a READE equivalent.  You have to build
your own.  START, then READ NEXT, then compare the returned key to the
desired key values.


Are the following statements correct:
1) READ without NEXT uses the key to do an RPG-type CHAIN; if a record
having the specified key does not exist, no record is returned to the
program.

This may not be allowed by the compiler.  I think you need either

READ filename NEXT AT END do something                      (sequential by
key)

or

READ filename INVALID KEY do something                        (random by
key)


It is a good idea to have END-READ to end the statement (instead of relying
on a hard-to-see period).

Not sure when  INVALID KEY is executed as part of the START stmt, just code
it and forget it.  Maybe on an empty file, maybe when key is too high.
I noticed
the KEY IS phrase in the syntax diagram, but the example I provided
does not use it.  Is KEY IS sort of an override to use a different key
than the one specified in the SELECT?

I dont think so.  I think it is for partial keys.  For example, FORDERS has
3 keys = order#, cust#, item#.  If you want to read by order# and cust#, you
would code

START FORDERS ...

READ FORDERS NEXT key is order, cust.  (Notice the item# is missing, even
though it is in the logical file key).

I dont think you can "ad hoc" change the keys of a file in the READ stmt -
you would have to use SQL to do something like that.  Or have a bunch of
different READ statements (one for each LF)  and only execute the one that
you want in that run.




-----Original Message-----
From: Dan [ mailto:dbcerpg@yahoo.com <mailto:dbcerpg@yahoo.com> ]
Sent: Thursday, December 19, 2002 4:18 PM
To: cobol400-l@midrange.com
Cc: Richard Casey
Subject: RE: How to do RPG-type I/O in Cobol


Hi Richard,

Thanks so much for your response!  I have the Cobol softcopy and I see
the references to some of the items I'm asking about, but I'm trying to
get an understanding of how the RPG & Cobol techniques compare, and
that's not real clear in the manual.  For example, as I explain below,
it appears that Cobol has no equivalent of RPG's READE.

When a READ is done, without NEXT, does it automatically use the key
defined in the RECORD KEY phrase of the file's SELECT group? Yes



In the START example:  When is it an INVALID KEY?  If there are no
records with a key that are "not less than" (sheesh, this should be
"greater than or equal to", yes?) the key defined?

.

2) READ NEXT always reads the record following the current record,
regardless of the key.  I interpret that to mean that a READ NEXT is
strictly an RPG-type READ (and not READE).  The lack of the INVALID KEY
phrase in the example seems to confirm this.

Thanks again!
- Dan

--- Richard Casey <casey_r@popmail.firn.edu> wrote:
> Hi Dan,
>
> You should be able to track down a COBOL reference manual at the
> InfoCenter.
> Check out
> http://publib.boulder.ibm.com/cgi-bin/bookmgr/DOCNUM/SC09-1813-00
<http://publib.boulder.ibm.com/cgi-bin/bookmgr/DOCNUM/SC09-1813-00>
>
> I know enough RPG to be dangerous (?!) so bear with me.
>
> The PCPESTCCP-READ paragraph is a random read (similar to RPG's
> CHAIN). I'm
> assuming that the file is defined as ACCESS DYNAMIC in the
> FILE-CONTROL
> section. ACCESS DYNAMIC allows you to do both sequential and random
> processing against a file.
>
> The PCPESTCCP-READ-NEXT paragraph is a sequential read (similar to
> RPG's
> READE). If I read the RPG manual correctly, READE allows you to
> specify a
> search argument that controls if READE returns a record to you or
> not.
> COBOL's READ NEXT is a little different in that it will return the
> next
> record regardless of the key (unless you hit end of file). You would
> then
> need to check the record to see if met your criteria.
>
> The PCPESTCCP-START-NOTLESS paragraph positions the file at the first
> record
> where the key is not less (i.e. >=) the specified value. This matches
> up
> with RPG's SETLL.
>
> Hope this helps! Holler if you need more info.
>
> Richard Casey

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com <http://mailplus.yahoo.com>
_______________________________________________
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/cobol400-l
<http://lists.midrange.com/cgi-bin/listinfo/cobol400-l>
or email: COBOL400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l
<http://archive.midrange.com/cobol400-l> .




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.