read at end ... not at end, etc 
Author Message
 read at end ... not at end, etc

Do you think that the COBOLization of COBOL with statements like "not
at end" as in:

        read file at end ... not at end end-read

will lead to even further degradation such as:

        read file

                at end ...

                not at end ...

                at beginning ...

                at first-record ...

                at after-first-record ...

                at last-record ...

                at before-last-record ...

                when major-key-break ...

                when intermediate-key-break ...

                when minor-key-break ...

                at detail ...

        end read

and that we'd be better off if we simply dropped the "at end" phrase
and just stuck with the read and a separate test after?

I do!

I envision whole programs choked up around the read statement. Pity.
Thank goodness nobody around here does this sort of madness.

Sent via Deja.com http://www.*-*-*.com/
Before you buy.



Mon, 11 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc
I somewhat see your point, but it goes back to the very nature of the design
of COBOL, the "END" statements, simple close that block of code, only if
your
inside an embedded statement, like for example the END-IF >> provides an
easer
what of reading complex code, plus it makes good structure.

Jeremy..

------------------------------------------------------------
 Get your FREE web-based e-mail and newsgroup access at:
                http://MailAndNews.com

 Create a new mailbox, or access your existing IMAP4 or
 POP3 mailbox from anywhere with just a web browser.
------------------------------------------------------------



Mon, 11 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc

I think shine's comment had more to do with the imperative statements
between the read and end-read, not the scope terminator itself.  I agree
that throwing too many conditional tests inside a read statement would make
the statement harder to follow.  I got along for quite a few years without
the benefit of a not-at-end clause in my read statements.  Of course, back
then, I had to put a "go to" after either the imperative statements after
the at end clause or after the read itself to get to the end of the read
paragraph but like I've said before, I find nothing wrong with using a "go
to" to branch to an EXIT paragraph.


Quote:
> I somewhat see your point, but it goes back to the very nature of the
design
> of COBOL, the "END" statements, simple close that block of code, only if
> your
> inside an embedded statement, like for example the END-IF >> provides an
> easer
> what of reading complex code, plus it makes good structure.

> Jeremy..

> ------------------------------------------------------------
>  Get your FREE web-based e-mail and newsgroup access at:
>                 http://MailAndNews.com

>  Create a new mailbox, or access your existing IMAP4 or
>  POP3 mailbox from anywhere with just a web browser.
> ------------------------------------------------------------



Mon, 11 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc
I prefer AT END and other English language checks to IF STATUS-CODE =
'08'.

One thing I like is what some pre-compilers do for database access.
That is to automatically include a status along with some 88 levels.
Occasionally, I find these overridden to a new set of values - but using
Pinnacle's own code instead of CA's default values just confuses things.

The following code is set up to automatically perform an error routine
except when the record is obtained successfully, or at end-of-set
(ERROR-STATUS = '0000' or '0307')

OBTAIN NEXT IABRCBC-RECORD
   ON DB-END-OF-SET
        CONTINUE.

88 levels could be used after a VSAM open to include all successful open
codes in an English language OK.

I suppose a shop could include its required copymembers for these
switches, but these are not standard from shop to shop.

COBOL works best where it has English language commands which are
standard from shop to shop.  File status checking should be like this.



Tue, 12 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc
You're right Terry, I have no objection to the end-read. I just think
the "not at end" phrase makes for some unattractive looking programs
and gets the read statement further in to the job of program control.
Better if we just use the "at end" to set a switch IMHO.



Quote:

> I think shine's comment had more to do with the imperative statements
> between the read and end-read, not the scope terminator itself.  I
agree
> that throwing too many conditional tests inside a read statement
would make
> the statement harder to follow.  I got along for quite a few years
without
> the benefit of a not-at-end clause in my read statements.  Of course,
back
> then, I had to put a "go to" after either the imperative statements
after
> the at end clause or after the read itself to get to the end of the
read
> paragraph but like I've said before, I find nothing wrong with using
a "go
> to" to branch to an EXIT paragraph.



> > I somewhat see your point, but it goes back to the very nature of
the
> design
> > of COBOL, the "END" statements, simple close that block of code,
only if
> > your
> > inside an embedded statement, like for example the END-IF >>
provides an
> > easer
> > what of reading complex code, plus it makes good structure.

> > Jeremy..

> > ------------------------------------------------------------
> >  Get your FREE web-based e-mail and newsgroup access at:
> >                 http://MailAndNews.com

> >  Create a new mailbox, or access your existing IMAP4 or
> >  POP3 mailbox from anywhere with just a web browser.
> > ------------------------------------------------------------

Sent via Deja.com http://www.deja.com/
Before you buy.


Tue, 12 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc
I've read that one thought behind adding the "NOT AT END" clause was so that
the practice of the "priming read" can be easily avoided. According to some
views of structured programming reading from a file in two different places
in the program (the priming read and then again at the end of the processing
loop) goes against good coding practices.

Personally, I don't like it. As someone in this thread stated, it's getting
the READ too involved in processing and program flow. As far as the "at
first record" stuff goes, didn't we once have that kind of thing in old, old
COBOL with the "ON 1"? That was removed (with COBOL 74, I think). It was a
{*filter*} to convert to newer versions.

While we're on a soapbox I'll also add that I do not like the INVALID KEY,
NOT INVALID KEY (you know, VALID KEY would've been better, to avoid the
double negative) clauses for direct reads/writes/rewrites/etc. Lumping all
"bad" file statuses into one group can't be a good idea.

Quote:

> Do you think that the COBOLization of COBOL with statements like "not
> at end" as in:

> read file at end ... not at end end-read

> will lead to even further degradation such as:

> read file

> at end ...

> not at end ...

> at beginning ...

> at first-record ...

> <snip>



Tue, 12 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc


<snip>

Quote:
> didn't we once have that kind of thing in old, old
> COBOL with the "ON 1"? That was removed (with COBOL 74, I think). It
was a
> {*filter*} to convert to newer versions.

Why would an 'ON 1' be difficult to convert?

   77   ON-1-A  PIC 9 VALUE 0.

        IF ON-1-A = 0 THEN
           :
           MOVE 1 to ON-1-A
        END-IF.

Or do I miss something?

Sent via Deja.com http://www.*-*-*.com/
Before you buy.



Tue, 12 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc
On Fri, 26 May 2000 13:22:36 -0400, "The Riddler"

Quote:

>I've read that one thought behind adding the "NOT AT END" clause was so that
>the practice of the "priming read" can be easily avoided. According to some
>views of structured programming reading from a file in two different places
>in the program (the priming read and then again at the end of the processing
>loop) goes against good coding practices.

I like the Not at End, because I can do the following.  I find it
clear, concise and reliable.

Perform Process-File Until All-Done.

Process-File.
   Read the-file At end set all-done to true
                       Not at end perform whatever-record-process-is
   End-Read
   .

Or:

Perform until file-status not = "00"
    Read the-file at end continue
                         not at end process-the-record
    end-read
 End-Perform

No IF for checking file status, no second level flags, etc.



Tue, 12 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc

Howard Brazee  <Please, do, not, e-mail, replies, to, Howard, Brazee, post,

Quote:
>I prefer AT END and other English language checks to IF STATUS-CODE =
>'08'.

... *especially* since, as my memory, admittedly porous as it is, tells me
that end-of-file results in a 10.

DD



Tue, 12 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc
Because when the person who had to convert one of these constructs (me) had
never seen it used before, it took extra time for him (me) to try to figure
out what it meant. AFTER that, it was pretty easy.

--
Michael Mattias
Tal Systems
Racine WI USA

Quote:



> <snip>

> > didn't we once have that kind of thing in old, old
> > COBOL with the "ON 1"? That was removed (with COBOL 74, I think). It
> was a
> > {*filter*} to convert to newer versions.

> Why would an 'ON 1' be difficult to convert?

>    77   ON-1-A  PIC 9 VALUE 0.

>         IF ON-1-A = 0 THEN
>            :
>            MOVE 1 to ON-1-A
>         END-IF.

> Or do I miss something?

> Sent via Deja.com http://www.*-*-*.com/
> Before you buy.



Tue, 12 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc
The difference is that ON 1 didn't require any data division entries.  A
useful declarative would be USE ON INITIAL ENTRY to give the same
result.  If eough old timers and the person from the shop where they
used the ON 1 construct for first time initialization were to request it
in the standard after next we might get a good replacement for ON 1
which doesn't require any data division entries.

I would use the construct if it were available.  It would be useful in
sub-routines.


Quote:



> <snip>

> > didn't we once have that kind of thing in old, old
> > COBOL with the "ON 1"? That was removed (with COBOL 74, I think). It
> was a
> > {*filter*} to convert to newer versions.

> Why would an 'ON 1' be difficult to convert?

>    77   ON-1-A  PIC 9 VALUE 0.

>         IF ON-1-A = 0 THEN
>            :
>            MOVE 1 to ON-1-A
>         END-IF.

> Or do I miss something?

> Sent via Deja.com http://www.*-*-*.com/
> Before you buy.



Tue, 12 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc
True, I like that structure too, but I wonder: If you have 4 input files in
a match/merge, and you are supposed to write group totals and a grand total.
Wouldn't that stress the nice structure a bit :-)

Regards
Ib
Thane Hubbell skrev i meddelelsen

Quote:
>On Fri, 26 May 2000 13:22:36 -0400, "The Riddler"

>>I've read that one thought behind adding the "NOT AT END" clause was so
that
>>the practice of the "priming read" can be easily avoided. According to
some
>>views of structured programming reading from a file in two different
places
>>in the program (the priming read and then again at the end of the
processing
>>loop) goes against good coding practices.

>I like the Not at End, because I can do the following.  I find it
>clear, concise and reliable.

>Perform Process-File Until All-Done.

>Process-File.
>   Read the-file At end set all-done to true
>                       Not at end perform whatever-record-process-is
>   End-Read
>   .

>Or:

>Perform until file-status not = "00"
>    Read the-file at end continue
>                         not at end process-the-record
>    end-read
> End-Perform

>No IF for checking file status, no second level flags, etc.



Wed, 13 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc

Quote:

> You're right Terry, I have no objection to the end-read. I just think
> the "not at end" phrase makes for some unattractive looking programs
> and gets the read statement further in to the job of program control.
> Better if we just use the "at end" to set a switch IMHO.

The "not at end" addition made the READ verb a balanced construct,
something COBOL badly needed. "not at end" saves us the trouble of
testing the EOF switch after every read & eliminates the temptation to
stick a "GOTO" in there.

As always, YMMV,
Bill {*filter*}



Wed, 13 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc

Quote:

> I've read that one thought behind adding the "NOT AT END" clause was so that
> the practice of the "priming read" can be easily avoided. According to some
> views of structured programming reading from a file in two different places
> in the program (the priming read and then again at the end of the processing
> loop) goes against good coding practices.

> Personally, I don't like it. As someone in this thread stated, it's getting
> the READ too involved in processing and program flow.

I don't see how the "not at end" involves the READ any further than it
already is. If you're reading a file sequentially, "at end" / "not at
end" is an issue which must be solved, regardless of coding style or
READ verb options (although I have seen a few programs which did not
separate the two (they were from the income group <g>)). These tended to
get into huge loops, reading forever after the "at end" they ignored.
These tended to chew up an enormous amount of resources in production
CICS regions.

Bill {*filter*}



Wed, 13 Nov 2002 03:00:00 GMT  
 read at end ... not at end, etc

Quote:



> <snip>

> > didn't we once have that kind of thing in old, old
> > COBOL with the "ON 1"? That was removed (with COBOL 74, I think). It
> was a
> > {*filter*} to convert to newer versions.

> Why would an 'ON 1' be difficult to convert?

>    77   ON-1-A  PIC 9 VALUE 0.

>         IF ON-1-A = 0 THEN
>            :
>            MOVE 1 to ON-1-A
>         END-IF.

> Or do I miss something?

I don't think so. I would simply count the no. of input records. If you
have trouble determining which record is the first you probably should
find another line of work (like management, for instance).

Bill {*filter*}



Wed, 13 Nov 2002 03:00:00 GMT  
 
 [ 32 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Solution to READ statement not recognising end of line

2. READ statement not recognising end of line??

3. (start..end) where start > end

4. End to end examples?

5. US - BA, DESIGNERS NEEDED !! FRONT-END / BACK-END

6. CAD Engineer *** Front-End and Back-End Tool *** for Silicon Graphics, Mountain View, CA

7. US - BA, DESIGNERS NEEDED !! FRONT-END / BACK-END

8. Visual Basic front end and Cobol back end

9. end-of-record versus end-of-file?

10. end-of-file during read using unformatted reading

11. web front-end, Python back end?

12. Browser front-end, python back-end

 

 
Powered by phpBB® Forum Software