If you are considering new variables, how about a version date yyyymmdd updated when a significant incompatibility is introduced, a release date yyyymmdd updated when a significant compatible version is release, a modification date yyyymmdd when a minor compatible update is released, and a patch date yyyymmdd indicating the latest compatible vendor patch is applied.
On Fri, Jun 25, 2021 at 9:20 AM Seymour J Metz <[email protected]> wrote: > > How about a new symbol that has the desired comparison properties? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List [[email protected]] on behalf of > Peter Relson [[email protected]] > Sent: Friday, June 25, 2021 9:52 AM > To: [email protected] > Subject: Re: z/OS SYSVAR looks weird > > Charles' interpretation is exactly the use case we are concerned with. The > doc is not ASCII-oriented. It is EBCDIC-oriented. That use case, > analogously, is why we continue to update CVTPRODN with a value that is > not necessarily "obvious" but has the necessary characteristic of > increasing (we even found that, for compatibility, we had to maintain the > format of SPx.y.z). > > At the minimum, the &SYSLRACF doc will have to be changed. It clearly no > longer is the RACF level). The comment on RCVTVRMN (which is documented > properly as the source for &SYSLRACF) describes this situation. In all > supported releases (and started in z/OS 2.2), there is no reason to use > &SYSLRACF because it is known to correspond to the z/OS release (although > that comment should refer to the ECVT not CVT). If someone is simply > displaying &SYSLRACF, there is no benefit to doing so. You should display > the value that is provided in ECVTPNAM / ECVTPVER / ECVTPREL / ECVTPMOD. > > But what I don't know is if there is some REXX sysvar that surfaces that > ECVT info. Without that, the functionality is lacking. > With a more complicated approach, a REXX exec can get that information > from the ECVT but that doesn't strike me as "nice". > > We might explore "unfreezing" this in a way that keeps the value > increasing for comparison purposes. > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
