Examples on the USE statement

I'm looking for some sample code showing nice ways to handle file I/O
errors.

I've always used a rather ugly chunk of code in one large DECLARATIVES
section that I inherited from Babbage when he was cutting Cobol code.

Now I need to repent and have some sl structured code.

Is anyone out there proud of the way they make use of the USE statement?

Jim

Jim Morcombe wrote:
> I'm looking for some sample code showing nice ways to handle file I/O
> errors.
>
> I've always used a rather ugly chunk of code in one large DECLARATIVES
> section that I inherited from Babbage when he was cutting Cobol code.
>
> Now I need to repent and have some sl structured code.
>
> Is anyone out there proud of the way they make use of the USE
> statement?

DECLARATIVES.
DECLAR-INPUT SECTION.
USE AFTER ERROR PROCEDURE ON INPUT CONTINUE.
DECLAR-OUTPUT SECTION.
USE AFTER ERROR PROCEDURE ON OUTPUT CONTINUE.
DECLAR-IO SECTION.
USE AFTER ERROR PROCEDURE ON I-O CONTINUE.
DECLAR-EXTEND SECTION.
USE AFTER ERROR PROCEDURE ON EXTEND CONTINUE.
END DECLARATIVES.
PROCEDUR SECTION.

Then handle everything with File Status variables. The above prevents the
compiler (Fujitsu) from generating a run-time message.

"JerryMouse" <nospam@bisusa.com> wrote

> The above prevents the
> compiler (Fujitsu) from generating a run-time message.


Which can also be done much easier by having a COBOL.CBR file
containing @NoMessages or @MessOutFile=somefile, or in other similar
ways.

Richard wrote:
> "JerryMouse" <nospam@bisusa.com> wrote
> 
>
>
> Which can also be done much easier by having a COBOL.CBR file
> containing @NoMessages or @MessOutFile=somefile, or in other similar
> ways.

1. I knew that.
2. The user asked about DECLARATIVES, not COBOL.CBR files
3. We have other reasons for avoiding the CBR file method.

"JerryMouse" <nospam@bisusa.com> wrote

> 1. I knew that.
> 2. The user asked about DECLARATIVES, not COBOL.CBR files

If you are going to be picky about how replies must exactly follow the
original subject then the poster asked for "sample code showing nice
ways to handle file I/O errors", your reply did not do this.

You had merely presented a way of avoiding runtime error messages, so
did I.

> 3. We have other reasons for avoiding the CBR file method.

My inherrited chunk of code already does this, plus a bit more.

Are there any basically different methods?

For example, doesn't the standard allow for a USE statement to catch errors
on a specific file?  What can be done with this rather than with File Status
tests in the Procedure division?

Jim


JerryMouse <nospam@bisusa.com> wrote in message
news:c66dnbh6SZTE8ALdRVn-sw@giganews.com...
> Jim Morcombe wrote: 
>
>        DECLARATIVES.
>        DECLAR-INPUT SECTION.
>            USE AFTER ERROR PROCEDURE ON INPUT CONTINUE.
>        DECLAR-OUTPUT SECTION.
>            USE AFTER ERROR PROCEDURE ON OUTPUT CONTINUE.
>        DECLAR-IO SECTION.
>            USE AFTER ERROR PROCEDURE ON I-O CONTINUE.
>        DECLAR-EXTEND SECTION.
>            USE AFTER ERROR PROCEDURE ON EXTEND CONTINUE.
>        END DECLARATIVES.
>        PROCEDUR SECTION.
>
> Then handle everything with File Status variables. The above prevents the
> compiler (Fujitsu) from generating a run-time message.
>
>

Yes, the Standard allows for USE statements on specific files.  In the 2002
Standard, there can even be separate declaratives for different I-O statuses
.

There is (as far as I know) really almost nothing that can be done in an ERR
OR
declarative that can't be done in a file-status checking routine.  One possi
ble
OBSCURE exception is that an Error Declarative may "catch" an I/O error in f
iles
used in a SORT/MERGE USING/GIVING statement - while there is no real way to 
do
this with a file status check (unless you CHANGE the code to have INPUT/OUTP
UT
procedures).  On the other hand, some compilers don't (always) do this corre
ctly
anyway.  (IBM, for example, doesn't "go to" the USE declaratives when the
FASTSRT compiler option is in effect - which is why they document that compi
ler
option as "non-Standard")

--
Bill Klein
wmklein <at> ix.netcom.com
"Jim Morcombe" <jim@byronics.com.au> wrote in message
news:c7seuq$m5i$1@yeppa.connect.com.au...
> My inherrited chunk of code already does this, plus a bit more.
>
> Are there any basically different methods?
>
> For example, doesn't the standard allow for a USE statement to catch error
s
> on a specific file?  What can be done with this rather than with File Stat
us
> tests in the Procedure division?
>
> Jim
>
>
> JerryMouse <nospam@bisusa.com> wrote in message
> news:c66dnbh6SZTE8ALdRVn-sw@giganews.com... 
>
>