IBM Mainframe Forum

Please answer
Can we use redefine clause in occurs clause?

As stated, the answer is NO. An OCCURS clause can contain only OCCURS (or OCCURS DEPENDING ON and variable name(s) associated with the ODO), ASCENDING / DESCENDING KEY, INDEXED BY.

Now if you had asked if a variable defined using an OCCURS clause could be redefined -- that is a very different question and chapter 5.3.13 of the COBOL Language Reference manual addresses it.

AS STATED ROBERT:
IN MY POINT OF VIEW:
WE CAN REDEFINE A DATA ITEM HAVE AN OCCURs CLAUSE.
but we cannot redefine a data item having occurs clause.
as an example:
01 g1.
03 WS-Y1 OCCURS 4 TIMES PIC X(5).
03 WS-Y2 REDEFINES WS-Y1 PIC 9(5).
it gives error.
A definition of an object of a "REDEFINES" clause contained an "OCCurs" clause.
01 g2.
03 ws-y1 pic 9(5) value 12345.
03 ws-y2 redefines ws-y1 occurs 5 times pic x(5).
the second does not gives error.



thanks:
Deepak kumar
mainframe trainer(applied labs)

Well, for someone who has gone from asking for a book on Cobol not much more than a year ago to a "mainframe trainer", I'm not sure you have got the hang of it.

Robert's first point is not connected to your comments in any way, and your comments don't seem to be connected to the poorly-worded question.

Your first can be done, you just have to know how to define the data.

Your second, you say, "does not give an error". Look closely at your compile listing. If it might not technically be an "error", but there is a diagnostic message, and your code is confusing, misleading and asking for trouble (as in program not working, or not understood by the next person who has to look at it).

billy,
yes you are right it gives warning message
"WS-Y2" redefined a smaller item. The program was accept was accepted as written.
BUT it what the problem it may created. explain me in brief

The problems are multiple, I'm not sure how "brief" I can be about it.



In the first, the record is 155 bytes long. some-more-of-record starts at dsplacement 55.

In the second, the record is175 bytes long. some-more-of-record starts at dsplacement 75.

The data for some-more-of-record is on the file, so hasn't moved. The incorrect redefines has screwed it up.

When we look at the length of a record on the edit screen, we "ignore" a REDEFINES when calculating the length. Yours wastes time.

What are you trying to do with the REDEFINES that way? That will puzzle the next person looking at the program, and waste time, cause frustration etc.

Even if it "works" for some particular odd idea, it is quite likely that the next person along will consider it as an error and look to "fix" it, not look at some dumb method that does something desired.

I could go on, but won't.

It doesn't address the actual question, either, or Robert's response. So it would seem you did not understand either of those.

Maybe you are a "trainee" trainer? If not, I'm not sure what advantage you see in posting such code as you did, and being unable to do the other one correctly as well.

k i will tell, it due to new compiler v3r4 which allows the warning level diagnostic.

IN MY POINT OF VIEW:
WE CAN REDEFINE A DATA ITEM HAVE AN OCCURs CLAUSE.

Honestly, who cares what your point of view is? My references are the COBOL manuals, which give me (almost) everything I need to know about COBOL. Opinions (or points of view) are not required. And in the few cases where the manuals don't clearly indicate, it is usually pretty easy to put together a test to find out how the compiler handles that specific case. If you are telling your students to follow your point of view, instead of the manuals, you are doing them a grave disservice -- not to mention being grossly unprofessional.

This is what I believe you were trying to do, and said you can't. You'd have got to something like this following Robert's second comment.

Deepak kumar25 wrote:k i will tell, it due to new compiler v3r4 which allows the warning level diagnostic.

The compiler does allow different levels of diagnostic to cause the compile to fail (not generate an object). The compiler does not, however, make those settings itself. So no, it is not the compiler...