Jeanette,
Thanks again for your indulgence, but re 'taking my gripe further', I'd
suggest don't bother. I'd guess it would just boil down to a discussion of
"what did they really mean" when ANSI wrote what they wrote?
The intuitive approach is quite simple (maybe too simple for a committee?):
A group item is always treated as a non-editted alphanumeric item (whether
it's the from- or the to- field).
Maybe my IBM Cobol experience preceded IBM's adoption of the ANSI standard?
Or maybe my brain's just fuzzy?
I distinctly remember getting bitten by this anti-intuitive 'standard' when
maintaining pre-written HP COBOL code after moving to the 3000 from an IBM
shop, but that doesn't prove a thing.
I distinctly remember getting bitten by this anti-intuitive 'standard' on
many occasions since then, while reorganizing or upgrading sloppy
redefinitions, which clearly proves I just can't leave well enough alone.
(So much for "fix bad code when you find it")
A standard is a standard, even if it's just plain wrong.
Besides, I like the workaround that some listmembers suggested: Cheat the
standard via reference modification ( MOVE GROUPITEM(1:) ...). I especially
like that because the next guy reading the code will undoubtedly fix it and
oops.
Tracy bad attitude Pierce
> -----Original Message-----
> From: Jeanette Nutsford [mailto:[log in to unmask]]
> Sent: Monday, June 18, 2001 9:19 AM
> To: Tracy Pierce
> Subject: Re: Cobol "Permissible Moves"
>
>
> Hi Tracy,
>
> If IBM allowed the Group move to have the exact same
> characteristics as an
> alphanumeric move then they do not conform to the standard.
> Their manual
> would have to indicate that this was an 'extension'.
>
> Somehow I doubt that they would have done that.
>
> I think (hope) your memory is just playing tricks on you on this small
> matter. If you want to explore it further I do have contacts
> in the IBM
> market (on the standards committee) to whom I could pose this
> question.
>
> Would you like me to take it further?
>
> Jeanette Nutsford
> <[log in to unmask]>
>
>
> ----- Original Message -----
> From: "Tracy Pierce" <[log in to unmask]>
> To: "'Jeanette Nutsford'" <[log in to unmask]>
> Sent: Monday, June 18, 2001 5:11 PM
> Subject: RE: Cobol "Permissible Moves"
>
>
> > Thanks, Jeanette, for your...
> >
> > >The COBOL manual page 9-62 says (under Rules for Moving
> Data) "Any move
> > that
> > >is not an elementary move is treated exactly as if it were
> a move from
> one
> > >alphanumeric elementary data item to another, EXCEPT THAT
> THERE IS NO
> > >CONVERSION FROM ONE FORM OF INTERNAL REPRESENTATION TO ANOTHER".
> >
> > Sounds to me like the statement was written a little too
> tightly (ie,
> simply
> > remove the 2nd half of the statement beginning with "to
> another" works
> fine
> > for me) and was quite literally interpreted by HP's Cobol
> implementation
> > team.
> >
> > I could be wrong, but IIRC this was better interpreted by
> IBM's mainframe
> > Cobol, which never nailed me with this 'standard'; rather
> theirs was much
> > more intuitive: {alphanumeric is alphanumeric is...} Again
> I could be
> > wrong, but it seems to me that this implementation was
> intuitive enough
> that
> > no such table covering every case of from-field properties
> vs to-field
> > properties even appeared in the very fat manual.
> >
> > I wonder if anyone's actually taking advantage of the weird
> standard?
> >
> > Thanks for your indulgence!
> >
> >
> > K Tracy Pierce
> > Systems Programmer
> > Golden Gate Bridge, Hwy & Trnsp Dist
> > P.O.Box 9000, Presidio Station
> > San Francisco CA 94129-0601
> > 415-923-2266
> >
> >
> > > -----Original Message-----
> > > From: Jeanette Nutsford [mailto:[log in to unmask]]
> > > Sent: Wednesday, June 13, 2001 4:32 AM
> > > To: [log in to unmask]
> > > Subject: Re: Cobol "Permissible Moves"
> > >
> > >
> > > Unfortunately for Tracy, the 'feature' is part of the current
> > > ANSI standard
> > > (and the future ANSI/ISO standard) so I would not expect it
> > > to be changeable
> > > in HP COBOL II or any other implementation of COBOL.
> > >
> > > The issue is that conversion only takes place in elementary
> > > Moves. A group
> > > item is not an elementary data item.
> > >
> > > The COBOL manual page 9-62 says (under Rules for Moving Data)
> > > "Any move that
> > > is not an elementary move is treated exactly as if it were a
> > > move from one
> > > alphanumeric elementary data item to another, EXCEPT THAT
> THERE IS NO
> > > CONVERSION FROM ONE FORM OF INTERNAL REPRESENTATION TO ANOTHER".
> > >
> > > This is the exact same wording as in the current and the next
> > > ANSI COBOL
> > > standard document.
> > >
> > > Jeanette Nutsford
> > > SIGCOBOL Chairman
> > > <[log in to unmask]>
> > >
> > >
> > > ----- Original Message -----
> > > From: "Ken Nutsford" <[log in to unmask]>
> > > To: "Jeanette Nutsford" <[log in to unmask]>
> > > Sent: Wednesday, June 13, 2001 9:55 AM
> > > Subject: [HP3000-L] Cobol "Permissible Moves"
> > >
> > >
> > > -------------Forwarded Message-----------------
> > >
> > > From: Tracy Pierce, INTERNET:[log in to unmask]
> > > To: [unknown], INTERNET:[log in to unmask]
> > >
> > > Date: 12-06-01 18:34
> > >
> > > RE: [HP3000-L] Cobol "Permissible Moves"
> > >
> > >
> > > See table 9-2 "Permissible Moves" in the Cobol manual, page
> > > 9-64. This
> > > isn't a bug, it's a high-effort built-in and waiting-to-bite
> > > you Feature,
> > > which you'll soon remember:
> > >
> > > If you make the mistake of cleaning up this code...
> > > 01 SSN.
> > > 05 SSN-1 PIC XXX.
> > > 05 SSN-2 pic XX.
> > > 05 SSN-3 PIC XXXX.
> > > 01 UN-NEEDED-REDEF-TO-AVOID-GROUP-GOTCHA REDEFINES SSN PIC X(9).
> > > 01 SSN-DISPLAY PIC XXXBXXBXXXX.
> > > ...
> > > MOVE UN-NEEDED-REDEF TO SSN-DISPLAY
> > >
> > > ...by removing the quite obviously un-needed redef and say...
> > > MOVE SSN TO SSN-DISPLAY
> > > ...you lose the editting features of the receiving field.
> > > Similarly but a
> > > tad more sinister, if your original definition was...
> > > 01 SSN PIC X(9).
> > > 01 SSN-REDEF.
> > > 05 SSN-1 PIC XXX.
> > > 05 SSN-2 PIC XX.
> > > 05 SSN-3 PIC XXXX.
> > > MOVE SSN to SSN-DISPLAY
> > > ...all is well until you remove the "obviously unnecessary"
> > > redefinition.
> > > WHY? Personally, I would have quite deliberately lumped GROUP and
> > > ALPHANUMERIC together, on both sending and receiving sides of
> > > this table.
> > >
> > > Tracy Pierce
> > >
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Glenn Koster [mailto:[log in to unmask]]
> > > > Sent: Tuesday, June 12, 2001 9:48 AM
> > > > To: Tracy Pierce
> > > > Subject: Re: [HP3000-L] Attempt to have execution for
> XEQ Commands
> > > >
> > > >
> > > > Tracy,
> > > >
> > > > On the HP3000-L list you wrote:
> > > > >
> > > > > (and I'd much rather see them fix my 20-year-outstanding
> > > > Cobol gripe re
> > > > > group fields not being treated as X fields!)
> > > > >
> > > >
> > > > Fill me in? What do you mean by them not being treated as
> > > > "X" fields. I
> > > > use them all the time in my COBOL as "X" fields without any
> > > > repercussions at
> > > > all.
> > > >
> > > > Glenn Koster, Sr.
> > > > Quintessential School Systems
> > > > Developers of QWEBS (www.qss.com)
> > > >
> > >
> > > * To join/leave the list, search archives, change list settings, *
> > > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> > >
> >
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
