File declarations in the Environment and Data division

Let's say I have a COBOL program like this:

IDENTIFICATION DIVISION.
PROGRAM-ID. Test.
AUTHOR: Oliver Wong.

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT FileA ASSIGN "FileA.dat"
ORGANIZATION IS LINE SEQUENTIAL
ACCESS MODE IS SEQUENTIAL.

DATA DIVISION.
FILE SECTION.
FD FileA.
01 RecordA.
88 EndOfFileA VALUE HIGH VALUES.
02 RecordID   PIC X(7).
02 Contents   PIC X(23)

PROCEDURE DIVISION.
BEGIN
OPEN INPUT FileA
* etc.

I'm assuming the fact that the "FileA" in the SELECT clause of the
FILE-CONTROL paragraph matches the "FileA" in the file description entry in
the FILE section is significant (as opposed to coincidental), and that these
two things are "linked" somehow.

Are either of these things optional? That is to say, would it be
meaningful to have "FileA" mentioned in the file description entry and not
in the SELECT clause, or vice versa? If so, what kind of "defaults" would
the compiler typically assume for such an ommision?

- Oliver

Oliver Wong wrote:
> Let's say I have a COBOL program like this:
>
> IDENTIFICATION DIVISION.
> PROGRAM-ID. Test.
> AUTHOR: Oliver Wong.
>
> ENVIRONMENT DIVISION.
> INPUT-OUTPUT SECTION.
> FILE-CONTROL.
>  SELECT FileA ASSIGN "FileA.dat"
>    ORGANIZATION IS LINE SEQUENTIAL
>    ACCESS MODE IS SEQUENTIAL.
>
> DATA DIVISION.
> FILE SECTION.
> FD FileA.
> 01 RecordA.
>  88 EndOfFileA VALUE HIGH VALUES.
>  02 RecordID   PIC X(7).
>  02 Contents   PIC X(23)
>
> PROCEDURE DIVISION.
> BEGIN
>  OPEN INPUT FileA
> * etc.
>
>    I'm assuming the fact that the "FileA" in the SELECT clause of the
> FILE-CONTROL paragraph matches the "FileA" in the file description
> entry in the FILE section is significant (as opposed to
> coincidental), and that these two things are "linked" somehow.

Correct.

>
>    Are either of these things optional?

No.

> That is to say, would it be
> meaningful to have "FileA" mentioned in the file description entry
> and not in the SELECT clause, or vice versa? If so, what kind of
> "defaults" would the compiler typically assume for such an ommision?

Absent either, the compiler would default to an error message.

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:11ufj3eqc24o2a9@news.supernews.com...
> Oliver Wong wrote: 
>
> Correct.
> 
>
> No.
> 
>
> Absent either, the compiler would default to an error message.

I'd go one step further.  Given that "For each file-name specified in a
SELECT clause, there shall be a file description entry or a sort-merge
description entry in the file section of ... the program in which the SELECT
clause is specified" can be found in ISO/IEC 1989:2002, and given that every
standard for COBOL as far back as I can determine has had similar wording, I
would suggest that a compiler that did anything *but* complain loudly if
either SELECT or FD was missing for a given file-name would be violating a
rule that has been fundamental to COBOL for close to half a century, if not
longer.

Stated a different way, there are languages that do not require that there
be both a SELECT and an FD/SD, and that there be a one-to-one correspondence
between each SELECT and one, and only one, FD/SD.

Such languages are not readily-recognizable dialects of what reasonably
might be called "COBOL".

-Chuck Stevens

I believe (but won't swear to it) that I *have* seen an extension that allow
s
the Select/Assign (Environment Division) entry to be omitted for an SD (not 
an
FD).  I *know* have seen implementations where the value in the ASSIGN claus
e of
the Select/Assign statement for an SD is "ignored" (i.e. has no relationship
 to
any "physical" sort-merge file).

Obviously, I agree with Chuck's statements about what the current, past, and
proposed STANDARDS require.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:ds8j68$ho$1@si05.rsvl.unisys.com...
> "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
> news:11ufj3eqc24o2a9@news.supernews.com... 
>
> I'd go one step further.  Given that "For each file-name specified in a SE
LECT
> clause, there shall be a file description entry or a sort-merge descriptio
n
> entry in the file section of ... the program in which the SELECT clause is
> specified" can be found in ISO/IEC 1989:2002, and given that every standar
d
> for COBOL as far back as I can determine has had similar wording, I would
> suggest that a compiler that did anything *but* complain loudly if either
> SELECT or FD was missing for a given file-name would be violating a rule t
hat
> has been fundamental to COBOL for close to half a century, if not longer.
>
> Stated a different way, there are languages that do not require that there
 be
> both a SELECT and an FD/SD, and that there be a one-to-one correspondence
> between each SELECT and one, and only one, FD/SD.
>
> Such languages are not readily-recognizable dialects of what reasonably mi
ght
> be called "COBOL".
>
>    -Chuck Stevens
>

Oliver Wong wrote:
> Let's say I have a COBOL program like this:
>
> IDENTIFICATION DIVISION.
> PROGRAM-ID. Test.
> AUTHOR: Oliver Wong.
>
> ENVIRONMENT DIVISION.
> INPUT-OUTPUT SECTION.
> FILE-CONTROL.
>   SELECT FileA ASSIGN "FileA.dat"
>     ORGANIZATION IS LINE SEQUENTIAL
>     ACCESS MODE IS SEQUENTIAL.
>
> DATA DIVISION.
> FILE SECTION.
> FD FileA.
> 01 RecordA.
>   88 EndOfFileA VALUE HIGH VALUES.
>   02 RecordID   PIC X(7).
>   02 Contents   PIC X(23)
>
> PROCEDURE DIVISION.
> BEGIN
>   OPEN INPUT FileA
> * etc.
>
>     I'm assuming the fact that the "FileA" in the SELECT clause of the
> FILE-CONTROL paragraph matches the "FileA" in the file description entry i
n
> the FILE section is significant (as opposed to coincidental), and that the
se
> two things are "linked" somehow.
>
>     Are either of these things optional? That is to say, would it be
> meaningful to have "FileA" mentioned in the file description entry and not
> in the SELECT clause, or vice versa? If so, what kind of "defaults" would
> the compiler typically assume for such an ommision?
>
>     - Oliver
>
You've already got your answer. Just to extend it a bit :-

(a) Mainframes - don't know :-) - Presumably they control location of
the storage device via JCL cards ???

(b) As you are primarily thinking PCs, depends upon compiler, but
usually the default directory *should* find your 'FileA.dat'. From day
one in COBOL I always had to contend with different data sets and common
filenames, so :-

Petro Canada Jumping Pound Cr Plant = PECAN44
Amoco Canada Waterton Plant = AMOCO23

SELECT Vessels-File
ASSIGN to ws-filename
ORGANIZATION IS LINE SEQUENTIAL
ACCESS MODE IS SEQUENTIAL.

Working-Storage Section.

01 ws-Filename pic x(100).

So to the program I might pass lnk-Filename =

"c:\Corrosion-Testing\Data\AMOCO23Vessels.dat".

OK - so I've switched to SQL since the above - but I'm still looking for
different data sets, i.e. AMOCO23.mdb, PECAN44.mdb etc.

-----------------
One thing though, I noticed it looks like you have picked up your EOF
flag technique from U. of Limerick examples (??? :-) ).

It's OK I suppose, but not an approach I'm thrilled about. I prefer as a
separate field :-

01 FileFlag		pic 9 value 0.
88 FileFinished	value 1.
88 FileNotFinished	value 0.

I suppose my observation is - why have a flag/condition in a record when
the flag applies to the file as a whole ? (What happens if he, (Mr.
Coughlin at U of L), has RecordA, RecordB and RecordC for the same file
?). No harm done in his approach - just a question of preference.

Jimmy

On Tue, 7 Feb 2006 18:16:30 -0600, "HeyBub" <heybubNOSPAM@gmail.com>
wrote:

>Not really if you but consider a mainframe to be merely the most expensive
>peripheral you can connect to your PC.

I bet the WWW was more expensive.    But I didn't pay for the
mainframe nor for the WWW.

"Last Boy Scout" <eggbtr@ezl.com> wrote in message
news:LMbGf.61$na4.18@fe07.lga...

> You will get an error for having an assign clause and not referrring to
> the file and you may get an error for using an FD with no assign clause.

Probably.

> Plus every field in your file description will get an error also.

I don't see why that's an absolute fact, nor do I see why that's necessary
or even useful.

> Then every time you refer to the fields in the procedure division it will
> be like the fields do not exist.

That depends on how good a job the compiler does in figuring out what's
wrong.  Once the compiler has figured out that there's a problem and what
that problem is, it can "pretend" whatever will allow it to do the best job
of catching the most errors elsewhere.  The fact that a file description
isn't "attached" to a particular SELECT statement has nothing whatever to do
with the syntactic validity of a record description taken on its own merit.
It's reasonable for the compiler to assume that a record description located
in the FILE SECTION can be expected to describe a record in memory, and thus
use of its various fields can be permitted without regard to where the
information in that record might have come from.

> Everything is connected.  The select statement has to do with what device
> has the file, and the FD is the Logical description of the file.  If the
> select statement is wrong you can get hundredes of errors in a program.

In my case, I think in general I'd expect the compiler to note the *first*
error as an error (and thereby preventing the *saving* of the generated
object code), make some sort of reasonable assumption as to the most likely
intent (as, for example, record descriptions in the file section can be
presumed to describe records in memory), and continue to go through all the
motions of compilation (including the process of code generation, even
though the generated code will ultimately be discarded).

I don't even think it'd be necessary for the compiler to issue syntax errors
on I/O statements for such a file, whether the file name used in the I/O
statement was in the SELECT or in the FD.  If a given user-defined name was
used in an I/O statement and in either a SELECT or an FD, I think it's
reasonable for the compiler to assume (on the basis that two out of three
agree) that the user-defined name was supposed to be a file-name.   Issuing
a syntax error on the I/O statement after having issued it on the SELECT
and/or the FD doesn't strike me as providing the user with information I
would regard as particularly useful.

It appears that my expectations would not be met with the compilers with
which you are familiar.

-Chuck Stevens

HeyBub wrote:

>James J. Gavan wrote:
>
> 
>
>Not really if you but consider a mainframe to be merely the most expensive
>peripheral you can connect to your PC.
>
>
>
>
Or, is the PC the smartest dumb terminal you can connect to your mainframe?