On Wed, 02 Apr 2008 21:37:18 GMT, "William M. Klein"
<wmklein@[EMAIL PROTECTED]
> wrote:
>The problems with using the "max" rather than the "current" size occurs
when
>referencing the entire group item and moving it, for example, to a single
>receiving item. Having "undefined/garbage" data in the "unused" ****tion
of the
>max part will cause problems. The GROUP item doesn't know (need to know)
how
>the individual sub-items are defined.
I think a group move DOES need to handle any-length items separately.
8.5.1.9 says:
"Unlike other group items, a variable-length group is not equivalent to an
alphanumeric
data item and cannot undergo a comparison or a move operation, in either
direction,
explicitly or otherwise, unless the other operand is a compatible group.
Groups are
compatible if all variable-length data items correspond and match as
specified
below. For the purposes of compatibility, either both operands may be
variable-length
groups or only one of the operands may be a variable-length group.
Determination of compatibility between a variable-length group and another
group is as
follows:
3) For each any-length elementary item in either group there is a
corresponding any-length
elementary item in the other group as specified in 8.5.1.9.1, Positional
correspondence."
You say, above, a variable length group can be moved to a single receiving
item. The last
sentence of the first paragraph says the same. But the first sentence and
3) appear to
require they both be variable-length groups with corresponding any-length
items.
It is easy picture a move from a variable-length group to a fixed-length
item, such as a
file record. It is not as easy to picture the reverse. Say it's moving
bytes until it gets
to an any-length string defined as prefixed by binary-long. The input
doesn't contain a
binary-long. How does it determine the length of the string?
Getting back to a move between two variable-length groups,
there is no requirement that the corresponding any-length items match on
direct/indirect
prefixed/delimited
limit
On a group move, the sending group might contain a direct item (with
limit) while the
corresponding item in the receiving group is indirect. The sending item
might be delimited
by low-value while the receiving group is prefixed by binary-long.
For these reasons, it seems a grouip move would have to be three
operations
copy the bytes preceding the any-length item
copy the any-length item, which may require scanning for a delimiter
or allocating memory
copy the bytes following the any-length item
>Is this clear? If not, I can try doing an example.
I would appreciate an example that deals with the above points.
> ***
>
>As far as your example goes, when passing an indirect variable length
item or a
>group containing one, what will be passed is a pointer. If the called
program is
>in another language, then you would define the structure with a pointer
as what
>was received and need to process it "accordingly". If the subprogram did
>something that COBOL couldn't handle when it came back, then various
"exception
>conditions" might be raised.
I found the answer under CALL. Any-length items and variable-length groups
are NOT ALLOWED
to be passed as parameters, period. That avoids dealing with the issue of
size changing in
the called program.
The returning item is not allowed to be an any-length item, but can be a
variable-length
group containing an any-length item. This is not a mistake, it shows that
someone on the
standards committee understands the issues I asked about. If the returning
were an
any-length elementary item, the called program would have no way to
communicate its new
location after a size change. But when the returning item is a group, the
group contains
pointers to its variable-length elements, enabling the called program to
pass back their
new locations.
>
>--
>Bill Klein
> wmklein <at> ix.netcom.com
>"Robert" <no@[EMAIL PROTECTED]
> wrote in message
>news:tce6v3hriqrje7kcom4petuon9rp0a84bl@[EMAIL PROTECTED]
>> On Wed, 02 Apr 2008 05:41:02 GMT, "William M. Klein"
>> <wmklein@[EMAIL PROTECTED]
> wrote:
>>
>>>It does have a "limit" - but it still needs to "move" the following
data. (Of
>>>course in Standard COBOL there can't be data following an ODO). "for
>>>contiguity"
>>>of items, see,
>>>
>>>"8.5.1.8.1 Contiguity of data items
>>>A variable-length data item may be part of any group structure, and its
>>>neighbors may be non-variable-length data
>>>items or variable-length data items. A variable-length data item is
logically
>>>but not necessarily physically
>>>contiguous with its neighbors. However a variable-length data item
behaves in
>>>all respects as though it were in fact
>>>contiguous with its neighbors whenever a procedural operation is
applied to a
>>>group containing it."
>>>
>>>In other words, no matter how direct items are stored, if you process
the
>>>"group
>>>item" containing them, it must "appear" as if the following items are
directly
>>>after the current length - not after the MAXIMUM length.
>>
>> The next paragraph seems to confirm that, when it qualifies any-length
with
>> indirect. The
>> implication is that a change to a direct any-length item DOES affect
the
>> addresses of its
>> neighbors.
>>
>> "The physical address of a variable-length data item may change during
>> execution of the
>> program. Dynamic-capacity tables and indirect any-length elementary
items,
>> however they
>> may change during execution, do not in any way affect the addresses of
their
>> neighbors."
>>
>> What procedural operations are they referring to? A MOVE and comparison
would
>> work if the
>> maximum length were allocated and following items not ****fted. I can
think of
>> two
>> situations where it matters. FUNCTION LENGTH says nothing about
>> variable-length groups,
>> which seems like an error. Reference modification cannot be used on
>> variable-length
>> groups.
>>
>> How can a program tell whether the item following an any-length
elementary
>> item is
>> contiguous? What behavior would be different?
>>
>> Suppose program A calls B with the address of an indirect any-length
item or
>> variable-length group containing a direct any-length item. B changes
the
>> item's size and
>> address. How does A know the new address? The parameter passed was the
address
>> of the item
>> or group, not the address of its base pointer. If a Cobol program did
pass the
>> addess of
>> the base pointer, which it would almost have to, that would cause
problems for
>> other
>> languages, including the OS API.
>
|
