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
