On 03/15/2013 10:29 AM, Paul Gilmartin wrote:
On Fri, 15 Mar 2013 09:36:41 -0500, Joel C. Ewing wrote:
....
single date. For example, if consistency is not guaranteed, the test
for day "01" may run while the date is last day of month, and subsequent
code which presumes "not day 01" may run after the date has actually
changed to day "01".
The same hazard exists in Rexx or any language. Suppose you are logging
transactions in data sets separated by months. Regardless in which order
you perform the operations, it's possible that a March transaction be recorded
in April's log or an April transaction in March's log. The best you can do
is to extract the date, strictly, only once per transaction, and use that
date both in the report headers and in selection of the log data set.
...
The observation that one needs to do a single date/time request and
re-use that value when you need a consistent date/time value in multiple
contexts within the same transaction is fairly basic, but easily
overlooked if you don't happen to test under circumstances where the
incorrect approach noticeably fails.
The simple "dateoff" C source code That Kirk Wolf offered yesterday
looks like the most reasonable date modification approach on z/OS UNIX
given the current shortcomings of the "date" command on z/OS, but in
light of Paul's reminder it does have one deficiency that needs to be
corrected: It needs to be extended with another parameter to also allow
explicit specification of a previously-obtained date/time value to use
as an alternative to re-extracting the current date/time, precisely so
you can re-use the same date/time value for multiple contexts and
multiple calculations without obtaining additional and potentially
inconsistent later date/time values in the same transaction. I'm
guessing if you restricted the input date format, that might not be
difficult to add.
Dealing with C source code would have been difficult for us, as we
didn't have the IBM compiler (and could never have cost-justified it
with our z/OS LPAR MSU values). Perhaps a usable z/OS executable could
be made with a z-arch version of the gcc compiler, but I believe that
would require putting the source code in ASCII and adding some explicit
EBCDIC/ASCII conversions within the code to handle parameters and
output. Probably not that big of deal for a simple program like this,
but something I never had time to try. If you wanted to port something
dependent on "dateoff" to another z/OS site, you would also most likely
need to provide an executable version of dateoff.
As a portability exercise, I managed in less than an hour to get
"dateoff" compiled and ran a small number of test cases under f17 Linux.
I did have to make a few source modifications to get a successful
compile, but they were minor (I'm assuming the original code compiles
successfully under z/OS). It appears relatively trivial to make the
"dateoff" approach available in multi-platform UNIX environments, while
getting IBM to extend the capability of "date" to be consistent with
other UNIX platforms is obviously non trivial.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
