I agree it would be a real rarity for any application code to have any
STCK vs STCKE issues. It would even be rare for ANY installation-written
code to work with TOD values, so much so that any cases would likely be
well known to the Technical Support staff. All application code I ever
saw using a timestamp value used something like the DB2 timestamp
format, not hardware-specific timestamps.
When doing Y2K mitigation in the 1990's, all date conversions by
applications at our installation were centralized to a singe utility
subroutine, which under the covers did use the TOD clock in order to
create a current timestamp (in various other formats) with microsecond
resolution. I can't even remember whether that utility originally used
the extended TOD format, but the utility's functional code was
LPA-resident with only a stub ever linked, so fixing it in one place
would fix all usage.
Surely any application code written since Y2K would be using the simpler
standard date/time calls available in LE or z/OS, or standard
installation utilities, rather than playing with TOD values. I think
the odds are extremely high that if IBM verifies there are no 2042
issues in z/OS or in their other products that run on z/OS, that
individual installations will not have any issues with their z/OS
applications. z/OS developers surely have had this work in progress or
scheduled since the STKE was introduced. Maybe some other vendors
might have dependencies, but a fix in their code is a fix for all their
customers.
This 2042 issue is a much, much simpler problem than Y2K, where each
installation had allocate many person-hours to analyze 1,000's of lines
of code in 1,000's of programs unique to that installation to find and
figure out how to handle every case where date fields with two-digit
years had been used, and be sure no four-year dates were used in
contexts where the leap-year exception rules were incorrect for year
2000. I don't see 2042 being much of a z/OS issue for anyone outside of
IBM, and maybe a few 3rd-party vendors.
Joel C Ewing
On 3/24/23 14:25, Farley, Peter wrote:
With respect to the COBOL migration issue, we bit that bullet several years ago, starting
with V5.2. Now we compile only with V6.2 except under special circumstances. We used
the "two library" migration plan.
As for "release and options compiled with", the CBT utility COBANALZ (CBT321)
does a very creditable job of that function, and the price is right. Honestly, the most
helpful information is just the compiler version used to create the load module, which
COBANALZ provides succinctly in its SUMMARY report. Options compiled with has not been a
necessary set of information for us (so far).
Which production programs are actually executed is a tougher nut to crack
without using SMF records (you need SAF permissions to that data), but
definitely possible using only your production JCL/PROC libraries, a good
source maintenance regime and utilities, application scheduler reports, and a
good knowledge of how to make SORT dance to your tune. I have done it for
specific sets of code and jobs for various business reasons (e.g., identifying
any non-LE COBOL code still actually running).
There is at least one very affordable ISV product already available which does
a very creditable job of providing shop-wide source-and-JCL cross-reference
data. I think IBM's TADz product has similar capabilities.
Year 2042 isn't even on our radar, as we don’t use STCK date information at the
application level at all as far as I know. All uses I am aware of use either STCKE or LE
date facilities. Being a financial sector player we have long since been dealing with
dates WAY into the future (30 year bonds, "perpetual" bonds, etc.).
HTH
Peter
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Steve Pryor
Sent: Friday, March 24, 2023 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: A question or two on zOS issues
EXTERNAL EMAIL
There are a couple of pressing issues in z/OS that I'm sure many folks are
aware of but about which there doesn't seem to be much being done. I'm curious
as to what other IBM-MAINer's thoughts might be. Specifically, I'm talking
about:
1.) migration to IBM's latest COBOL release, and
2.) the not-really-that-far-off issue of Year 2042
I've been asked several times recently whether we (a z/OS ISV) should consider
developing products to address these issues. Frankly, though, I live in an
ivory tower and while I sometime *think* I know what installations problems and
needs are, I'm usually surprised to find that reality is quite different. So
I'd like to throw a couple of questions out to the list for comment:
1.) Would a reporting utility that determined which COBOL programs were
executed (and which ones weren't), and what release and options they were
compiled with be significantly helpful in a COBOL migration? What other
features would be nice to have? Or is this a low priority for most
installations, who are perhaps trying to justify keeping the mainframe alive
and/or conducting business as usual, let alone doing a COBOL migration project?
2.) It's rather shocking that 2042 is so close and not much seems to be
happening. We are one of the vendors that have a date-simulation utility, but
we don’t know if data centers have any near-term plans for 2042. Would it be
worthwhile to have a 2042 date-simulation product now, or is everyone going to
cross their fingers and try to use a test LPAR once the operating system fully
supports 2042 dates?
Thanks for any comments and insight the IBM-MAIN hive mind might have.
Steve Pryor
CTO
DTS Software, LLC
--
...
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
