DATE() Consistency

[Paul Gilmartin]

The TSO/E Rexx reference says:

DATE
...
Note:
1. The first call to DATE or TIME in one clause causes a time
stamp to be made that is then used for all calls to these
functions in that clause. Therefore, multiple calls to any
of the DATE or TIME functions or both in a single expression
or clause are guaranteed to be consistent with each other.

This might rrequire that:
say date( , 17760704, S ) date()
display:
4 Jul 1776 4 Jul 1776

What does ANSI say? Does the note requirre a clarification
for the case where there is a second argument to date()?

-- gil

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX

[Phil Smith III]

Post by Paul Gilmartin
say date( , 17760704, S ) date()
4 Jul 1776 4 Jul 1776

Unless you're just noting that the wording could perhaps be clarified, 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, 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.

I'd suggest that the wording is already clear enough for rock & roll.

...phsiii

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX

[Paul Gilmartin]

Post by Phil Smith III

Post by Paul Gilmartin
say date( , 17760704, S ) date()
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.

Post by Phil Smith III
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.

Post by Phil Smith III
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.

Post by Phil Smith III
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

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX

[Phil Smith III]

Post by Paul Gilmartin
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.
Documentation shouldn't require the user to resort to guesswork, even when the >answer is almost certain.

I still think you're pushing it. POLA would not suggest interpreting it as you suggest folks will.

Post by Paul Gilmartin
z/OS internals are notoriously under-commented and under-understood

There are much bigger fish to fry...

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX