On 2014-06-22, at 00:25, John McKown wrote: > > What I would do it look at the CONVSTCK and STCKCONV macros. They can > translate to various display formats to STCKE internal format( CONVSTCK). > So it is easy. Convert your date/time to an STCKE value. Do a normal 128 > bit add of 30 minutes in STCKE value units to it. Then use STCKCONV to > convert it back to your display format of choice. > CONVSTCK? CONVTOD? Whatever.
Nitpick: I suspect this will give a 31-second delay rather than 30 if a leap second occurs in the selected interval. But JWG doesn't believe in leap seconds. But we really don't know. A while back, I ranted on IBM-MAIN about the lack of documentation of STCKCONV/CONVTOD. Do they deal in LOCAL time? GMT? TAI? Other? An IBM representative said that no further documentation is needed; it's "common knowledge" what they do. IMO, "common knowledge" is no substitute for documentation. I submitted an RCF. It was rejected with language similar to what that IBM rep said on IBM-MAIN. I suspect that for TOD values prior to 1972 they deal in GMT; 1972 and later a fictitious standard of TAI minus 10 seconds. But IBM won't say so. > Ref: > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A9B0/88.0 > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A7A0/30.1 > > Now, I can hear you asking: What is the STCKE value for 30 minutes??? Well, > Rexx is great for this. And it should be a motivation for HLASM to support 64-bit arithmetic. Either TOD or the top 64 bits of ETOD represents microseconds without truncation. -- gil
