As I understand the example, it was dependent on SYSPARM having 7 characters. For what it's worth, that happens to be the typical SYSPARM that IBM products are built with (the "FMID" is 7 characters long, as is an APAR number) when SYSPARM is used at all. Nevertheless, if a sample is truly wrong, that is APARable. If documentation is truly wrong, that is APARable. Emphasis on truly wrong. Whether a fix will be provided in service or in a subsequent release is a different question.
Clearly no sample ought to be using undocumented (hence unsupported) parameters. And since this cost someone time to figure out, it might cost someone else time later so should be brought to the attention of the owner to address. As to the change activity comment of "fix J", SAVE was "jumpified" incorrectly (by me) in z/OS 1.3 (based on the user's specification of SYSSTATE ARCHLVL). The J instruction I had used was incorrect. The APAR corrected that. As to the "botched" handling -- IBM will certainly not change the SAVE macro to do anything about this. You may not like the behavior, but it is not really wrong. It may well be not what you happen to prefer. Since it has been this way likely for longer than you (or I) have been someone who might use it, perhaps it is the macro that is right and "we users" who are wrong <grin>? 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
