Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Can I use "redefines" in FD 01 layer,thanks a lot!

Status
Not open for further replies.

31425

Programmer
Apr 6, 2002
1
CA
please help to make sure which one is correct,thanks!
I.
FD RF-RAINFALL-FILE.
01 RF-RAINFALL-RECORD.
02 RF-CITY PIC X(20).
02 RF-DATE.
03 RF-DAY PIC 9(02).
03 FILLER PIC X(01) VALUE "/".
03 RF-MONTH PIC 9(02).
03 FILLER PIC X(01) VALUE "/".
03 RF-YEAR PIC 9(02).
02 RF-RAINFALL PIC 99V99.
01 RF-STORM-RECORD.
02 RF-STORM-CITY PIC X(30).
02 RF-STORM-DATE PIC 9(06).

II.
FD RF-RAINFALL-FILE.
01 RF-RECORD.
02 RF-RAINFALL-RECORD.
03 RF-CITY PIC X(20).
03 RF-DATE.
04 RF-DAY PIC 9(02).
04 filler PIC X(01) VALUE "/".
04 RF-MONTH PIC 9(02).
04 filler PIC X(01) VALUE "/".
04 RF-YEAR PIC 9(02).
03 RF-RAINFALL PIC 99V99.
02 RF-STORM-RECORD REDEFINES RF-RAINFALL-RECORD.
03 RF-STORM-CITY PIC X(20).
03 RF-STORM-DATE PIC 9(06).
03 filler PIC X(06).
 
Hi 3,

Either is correct. The first is probably preferred because it shows that you know the rule for defining multiple record layouts in an FD (i.e., redefines at the 01 level are not permitted) and that's the usual solution. There's nothing wrong w/option 2, it's just that 1 is better for the admittedly thin reasons stated above.

Of course, in WS, you'd code a redefines at the 01 level (it's permitted there) to save the memory wasted. Or you could code it in WS using your 2nd option.

HTH, Jack.
 
Either redefinition technique is correct, but the examples are not identical (see below).

It is often a matter of local/corporate preference to determine which redefinition technique is used.

Your example I implicitly defines a variable length record file defintion, while II implicitly defines a fixed length record file definition.

I would say, also, that the record layouts that you have presented contain errors (e.g. VALUE used within an FD), but I can't know for certain; the examples just don't seem logical.
Tom Morrison
 
Hi,

In the first definition, RF-STORM-CITY is bigger than the city in the other record definition which is implicit a redefines. I guess RF-STORM-CITY in the first definition should be X(20) instead of X(30).

RF-STORM-DATE is only 6 long. If the '/' exists in the file, RF-STORM-DATE should be 8 long, else if the '/' is not in the file, leave them out of the definition (which is also not valid with values!).

Both kind of definitions can work, if the length of the fields are ok.

Perhaps this will help:

Code:
01 RF-RAINFALL-RECORD.
      02  RF-CITY    PIC X(20).
      02  RF-DATE.
              03  RF-DAY    PIC 9(02).
              03  FILLER   PIC X(01).
              03  RF-MONTH   PIC 9(02).
              03  FILLER   PIC X(01).
              03  RF-YEAR   PIC 9(02).
      02  RF-RAINFALL   PIC 99V99.
01 RF-STORM-RECORD.
     02  RF-STORM-CITY   PIC X(20).
     02  RF-STORM-DATE   PIC 99/99/99.

Regards,

Crox


 
Hi Tom,

Just a comment on the VALUE issue as it relates to the FD entry. In IBM mainframe implementations of COBOL, the VALUE clause is "tolerated" but not recognized; a warning msg is generated by the compiler. This is a convenient feature because it allows a copybook to do "double duty", both in WS and the FD without change.

You'd know better than I if it can be done with other implementations of COBOL, but I thought it worth mentioning, lest a user miss out on a valuable available feature.

Regards, Jack.
 
Jack,

You are of course correct. This an almost universal extension. In this context, though, it seemed to be an error.

On a side note, does IBM mainframe also permit VALUE in LINKAGE SECTION?

Note to lurkers: this esoteric discussion should in no way be construed to indicate that the VALUE clause, when used on an 88-level (condition) item within an FD, is not correct. IMO, there aren't enough 88s in FDs but there I go again...
Tom Morrison
 
Hi Tom,

Don't know for sure, and didn't see anything in the doc about the Linkage Sect, but I suspect it's treated the same as the FD VALUE clause and for the same reasons.

I agree w/your 88 level view. It's probably the best and least used documentation feature of the language.

Regards, Jack.
 
You are right about the 88 level, but sometimes it kan be killing.

Some people in a project were looking for days for an error in a program. A condition IF MARRIED had the wrong 88 level value.... That was the last thing they were looking for ...

Regards,

Crox
 
IBM treats VALUE clauses as comments in the LINKAGE SECTION, just as in the FILE SECTION. And it flags them with a W-level error message in both cases.

I would rather have explicit tests in the code, rather than 88-levels. This a a personal preference, not a religious belief (like heretical Initial READ statements). However, I usually list the possible values as comments in the DATA DIVISION layouts, which accomplishes the same documentation as an 88-level. I usually also put a description of the code values in the PROCEDURE DIVISION, because I like my code well-documented.

Stephen J Spiro
 
Yeah, I know Stephen; funny how that works out. One person's "personal preference" is another's "heresy". :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top