RE: [open-cobol-list] USAGE POINTER

[William M. Klein]

*GETTING* the address of a subordinate data-item is (and should be) allowed
by all the implementations that I know of.

*CHANGING* the address of a subordinate item is "strange" (and I can't even
figure out what SHOULD happen).

Consider:

 01  Group-1.
      05   Elem1  Pic  XX.
      05   Elem2  Pic  XX.
      05   Elem3  Pic  Xx.
....
    Set Address of Elem2 to Some-Pointer-Item.

What happens to the address of Elem3?  What happens on a Move to Group-1?

I think that the entire "current" ('85 and 2002) Standard definitions of
"group items" is built on the REQUIREMENT that all the storage of an
01-level (or 77-level) be in "contiguous" storage.  Any change to this may
break "bunches" of the rest of the COBOL language. 

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On 
> Behalf Of Bernard Giroud
> Sent: Wednesday, February 04, 2004 3:07 AM
> To: William M. Klein; 'Keisuke Nishida'; 
> address@hidden
> Cc: 'David Korn'
> Subject: Re: [open-cobol-list] USAGE POINTER
> 
> ----- Original Message -----
> From: "William M. Klein" <address@hidden>
> To: "'Keisuke Nishida'" <address@hidden>;
> <address@hidden>
> Cc: "'David Korn'" <address@hidden>
> Sent: Wednesday, February 04, 2004 1:27 AM
> Subject: RE: [open-cobol-list] USAGE POINTER
> 
> 
> >
> > A couple things to think about for this extension.
> >
> > (...SNIP...)
> >
> > 2)  SET ADDRESS OF must be followed by an 01 or 77-level item (not a
> > subordinate item)
> 
> It is a shame to have arbitrary limitations from the language; I agree
> that on some architectures the address of a subordinate item will
> not be aligned, but if you WANT to pass a byte address, that should
> be allowed by the language.
> 
> >
> > (...SNIP...)
> 
> 
> Bernard Giroud
> Credit Lyonnais (Suisse) SA
> 
> 
> 
> **************************************************************
> ******************
> This e-mail contains confidential information or information 
> belonging 
> to the Credit Lyonnais Group entity sending it and is intended solely 
> for the addressees. Any views expressed in this message are those of 
> the individual sender and its contents do not constitute a commitment 
> by Credit Lyonnais unless confirmed by letter or fax. The 
> unauthorised 
> disclosure, use, dissemination or copying (either whole or 
> partial) of 
> this e-mail, or any information it contains, is prohibited. 
> E-mails are 
> susceptible to alteration and their integrity cannot be guaranteed.
> Internet communications are not secured and therefore Credit Lyonnais 
> shall not be liable for this e-mail if modified or falsified. If you 
> are not the intended recipient of this e-mail, please delete it 
> immediately from your system and notify the sender of the wrong 
> delivery and the mail deletion.
> **************************************************************
> ******************
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>