> On Aug 23, 2021, at 09:52:19, Phil Smith III <
li...@AKPHS.COM> wrote:
>
> Gil wrote, in part:
>> This might rrequire that:
>> say date( , 17760704, S ) date()
>> display:
>> 4 Jul 1776 4 Jul 1776
>
> Unless you're just noting that the wording could perhaps be clarified,
>
Exactly. And using the word "consistent" suggests that the second date()
should return the same value as the first.
> you know the answer is "Of course not". The point is that an STCK or equivalent is performed by the first DATE function in a statement,
>
Itt doesn't say that. It merely says "a timestamp" which could equally
mean the clock value used to generate the result of the first call.
> so if the clock rolls during execution of that statement, the times aren't inconsistent. E.g., if the first DATE in the statement is executed at 23:59:59.99999999 and the rest of the statement takes enough time, it might be 00:00:00.x before the last one is executed. DATE(), DATE('D'), et al. will all return the same date.
>
It's an admirable design. IBM employees have conceded, OTOH, that system
symbols accessible in JCL are subject to the hazard you describe. That
should be fixed. But it's hard to supply a test case.
> I'd suggest that the wording is already clear enough for rock & roll.
>
Documentation shouldn't require the user to resort to guesswork, even
when the answer is almost certain.
The scope of the timestamp is well-chosen. It's not affected by a call
to a function which calls time()
-- gil