You could do POINTER arithmetic, but that is not supported directly either :-)
Because it is not supported, you have to use REDEFINES, which implies that you have to know the length of the POINTER. Compile a 31-bit POINTER with REDEFINES under a 64-bit-addressing compiler and... things don't go so well. OK, so we don't have 64-bits yet... So, on the assumption that it is only the length that is going to be problematic, a little bit of self-checking can be done. And, that's a bad assumption for another reason. The field the actual 'rithmetic is done on *must be COMP-5* (native binary). It's an address. You don't want to truncate an address if it happens to be "higher" than 999,999,999. If control info is needed I'd look to keep it in a separate area, "linked" to the allocated memory by the address of the allocated memory. On the COMP-5 vs COMP (or BINARY, I've got into the habit of using (mostly)) I didn't get any feedback after my suggestion so I was wondering... COMP with nine digits can, at least prior to V5, can have performance issues (see the Tuning Guides). I've not checked, but I think that it is now less of a problem, or no problem, due to the new compiler. Perhaps remains a problem at some level of OPT, I don't know. On Tuesday, 9 August 2016 17:34:15 UTC+2, Frank Swarbrick wrote: > Bill, you got me on that one. Open for suggestions. I could simply do > pointer arithmetic, but this way worked so I went with it. If I separated > the control area and still only pass the address of the table area back to > the client, how do you suggest I "anchor" it? > > > Use of UNBOUNDED to make it more explicit that there is no particular maximum > number of rows. > > > I used COMP with TRUNC(OPT). Aren't you one who said that COMP with > TRUNC(OPT) performs better than COMP-5? > > > Thanks, > > Frank > > ________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf of > Bill Woodger <[email protected]> > Sent: Monday, August 8, 2016 6:56 PM > To: [email protected] > Subject: Enterprise COBOL API for dynamic capacity tables > > "leftmost-character-position > > Must be an arithmetic expression. The evaluation of > leftmost-character-position must result in a positive nonzero integer that is > less than or equal to the number of characters in the data item referenced by > data-name-1." > > So, you are using undefined behaviour (and non-Standard at that). > > IBM have now allowed zero to be valid for leftmost-character-position (again > non-Standard, although I don't think it is listed as an IBM Extension). > Negative reference-modification? No. > > Of course, it is like a zero/negative subscript. Until someone comes along > and changes the compiler, that is not allowed, but it is known exactly how it > operates. > > However, if IBM do change the compiler - what then? > > I'd either look to use a separate control-area, come up with a more secure > way of referencing an "attached" one, or remove the need for a control-area. > > Out of interest, why COMP not COMP-5? > > Do you feel there is a benefit to using UNBOUNDED over a plain ODO? After > all, UNBOUNDED is an IBM Extension to allow for dynamically-sized tables > (although not *those* dynamically-sized tables). It's tough to say then that > "IBM doesn't allow it". > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
