Home > Archive > Cobol > July 2006 > ambiguous data name
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ambiguous data name
|
|
| Frank Swarbrick 2006-07-08, 3:55 am |
| Something I've never run in to before...
WORKING-STORAGE SECTION.
01 X PIC X.
01 Y.
05 X PIC X.
PROCEDURE DIVISION.
MOVE 'Y' TO X OF Y. *> This works
MOVE 'X' TO X. *> This does not
Since the first X is a top-level elementary item there's no way (that I know
of) to further qualify it. Is there any way around this (other than,
obviously, renaming one of the fields)?
Just wondering.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Bob Iles 2006-07-08, 3:55 am |
| Frank Swarbrick wrote:
> Something I've never run in to before...
>
> WORKING-STORAGE SECTION.
> 01 X PIC X.
> 01 Y.
> 05 X PIC X.
> PROCEDURE DIVISION.
> MOVE 'Y' TO X OF Y. *> This works
> MOVE 'X' TO X. *> This does not
>
> Since the first X is a top-level elementary item there's no way (that I know
> of) to further qualify it. Is there any way around this (other than,
> obviously, renaming one of the fields)?
>
> Just wondering.
>
> Frank
>
>
move x to another level.
01 X-main.
03 X pic x.
> MOVE 'Y' TO X OF Y. *> This works
and now > MOVE 'X' TO X or x-main
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO USA
| |
| HeyBub 2006-07-08, 7:55 am |
| Frank Swarbrick wrote:
> Something I've never run in to before...
>
> WORKING-STORAGE SECTION.
> 01 X PIC X.
> 01 Y.
> 05 X PIC X.
> PROCEDURE DIVISION.
> MOVE 'Y' TO X OF Y. *> This works
> MOVE 'X' TO X. *> This does not
>
> Since the first X is a top-level elementary item there's no way (that
> I know of) to further qualify it. Is there any way around this
> (other than, obviously, renaming one of the fields)?
>
> Just wondering.
>
> Frank
MOVE -1 TO Z.
MOVE 'X' TO X(Z:1) OF Y. ???
Of course this is the equivalent of leaving a flaming paper bag of dog poop
on the door-step of the maintenance programmer that comes after. But the
original programmer did it to you...
| |
| Colin Campbell 2006-07-08, 7:55 am |
| HeyBub wrote:
> Frank Swarbrick wrote:
>
>
>
> MOVE -1 TO Z.
> MOVE 'X' TO X(Z:1) OF Y. ???
>
> Of course this is the equivalent of leaving a flaming paper bag of dog poop
> on the door-step of the maintenance programmer that comes after. But the
> original programmer did it to you...
>
>
>
If this program runs on an IBM mainframe, your solution won't work,
because each 01-level item starts on a doubleword boundary. Thus, the
"01 X" is eight bytes from the "01 Y". Your code would not change the
contents of "01 X", but it probably wouldn't break the program, either.
Probably better to "solve" the data-name problem, rather than further
mucking up the program.
Of course, I wonder what the compiler says about the MOVE statement, and
I would guess that no one ever tried to reference the "01 X" before, so
why does it need to be given a value now?
| |
| HeyBub 2006-07-08, 6:55 pm |
| Colin Campbell wrote:
> HeyBub wrote:
> If this program runs on an IBM mainframe, your solution won't work,
> because each 01-level item starts on a doubleword boundary. Thus, the
> "01 X" is eight bytes from the "01 Y". Your code would not change the
> contents of "01 X", but it probably wouldn't break the program,
> either.
> Probably better to "solve" the data-name problem, rather than further
> mucking up the program.
That would be solving the wrong problem, wouldn't it? Heck, this might be a
question on a pre-employment test!
So, let's make the code, um, less parochial:
IF IBM-MACHINE
MOVE -8 TO Z
ELSE
MOVE -1 TO Z.
MOVE 'X' TO X(Z:1) OF Y.
There, now. Isn't that swell?
| |
| Colin Campbell 2006-07-08, 6:55 pm |
| HeyBub wrote:
> Colin Campbell wrote:
>
>
> That would be solving the wrong problem, wouldn't it? Heck, this might be a
> question on a pre-employment test!
>
> So, let's make the code, um, less parochial:
>
> IF IBM-MACHINE
> MOVE -8 TO Z
> ELSE
> MOVE -1 TO Z.
> MOVE 'X' TO X(Z:1) OF Y.
>
> There, now. Isn't that swell?
>
>
>
I'm sure the employment offers will be flowing in! Your solution is one
any programmer could be proud of! Swell is hardly a strong enough word
to describe the solution.
| |
| Frank Swarbrick 2006-07-10, 6:55 pm |
| Bob Iles<bobi@mikal.com> 07/07/06 3:35 PM >>>
>Frank Swarbrick wrote:
know[color=darkred]
>move x to another level.
>01 X-main.
> 03 X pic x.
>
>
>and now > MOVE 'X' TO X or x-main
Hmm, I should have mentioned "without moving X to another level"!
Honestly, I have no need to do this. I was just curious if it is possible.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Frank Swarbrick 2006-07-10, 6:55 pm |
| HeyBub<heybubNOSPAM@gmail.com> 07/07/06 6:06 PM >>>
>Frank Swarbrick wrote:
>
>
>MOVE -1 TO Z.
>MOVE 'X' TO X(Z:1) OF Y. ???
>
>Of course this is the equivalent of leaving a flaming paper bag of dog poop
>on the door-step of the maintenance programmer that comes after. But the
>original programmer did it to you...
There is no "original programmer". This is not real code, and I have never
run in to the problem in "real life". It was simply something that occured
to me, so I wondered if there was any way to make the 01 level X
unambiguous.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Frank Swarbrick 2006-07-10, 6:55 pm |
| Colin Campbell<cmcampb@adelphia.net> 07/07/06 8:29 PM >>>
>HeyBub wrote:
poop[color=darkred]
[color=darkred]
>If this program runs on an IBM mainframe, your solution won't work,
>because each 01-level item starts on a doubleword boundary. Thus, the
>"01 X" is eight bytes from the "01 Y". Your code would not change the
>contents of "01 X", but it probably wouldn't break the program, either.
>
>Probably better to "solve" the data-name problem, rather than further
>mucking up the program.
>
>Of course, I wonder what the compiler says about the MOVE statement, and
>I would guess that no one ever tried to reference the "01 X" before, so
>why does it need to be given a value now?
It appears I need to learn how to phrase my 'straw man' questions a bit more
obviously! :-)
This is not real code or even anything like any real code I have seen. It
was a "just wondering" question.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| William M. Klein 2006-07-10, 6:55 pm |
| The answer is that there is no "intended by the language" to do it. (There are
only tricks and code changes)
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4hf9ufF1r4rhhU4@individual.net...
> Colin Campbell<cmcampb@adelphia.net> 07/07/06 8:29 PM >>>
> poop
>
>
> It appears I need to learn how to phrase my 'straw man' questions a bit more
> obviously! :-)
>
> This is not real code or even anything like any real code I have seen. It
> was a "just wondering" question.
>
> Frank
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO USA
| |
| Bob Iles 2006-07-11, 6:55 pm |
| Frank Swarbrick wrote:
> HeyBub<heybubNOSPAM@gmail.com> 07/07/06 6:06 PM >>>
>
>
> There is no "original programmer". This is not real code, and I have never
> run in to the problem in "real life". It was simply something that occured
> to me, so I wondered if there was any way to make the 01 level X
> unambiguous.
>
> Frank
So to recap Frank,
When I was first exposed to Cobol I though the move corresponding
feature Cobol was "neat", but unless you are reformatting a record
with the same fields, it has little value and that is the only
time I have ever found a need to have the same field names
defined, and in many cases would probably prefer the compile to
give me and error or warning (as it will on the level 01 items).
When developing new code, it's just much easier in my mind to
give unique names.
IMO of course.
Sincerely,
Bob.
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO USA
|
|
|
|
|