> Shmuel, do you feel so jealous and threatened by Ed's basic competency that you >must pounce three times in 12 minutes when an opportunity arises?
There you go again. Are you projecting? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Paul Gilmartin [[email protected]] Sent: Thursday, January 26, 2023 12:19 PM To: [email protected] Subject: Re: HOLDDATA Not Working as Expected On Thu, 26 Jan 2023 14:32:47 +0000, Kurt J. Quackenbush wrote: > >Just to confirm what has already been mentioned, you're using ++RELEASE >incorrectly. The fixing PTF will resolve the ++HOLD, so there is no need to >generate a ++RELEASE. IBM only uses ++RELEASE in cases when a PE or HIPER has >been flagged erroneously. > That could be made more explicit than it is in the Usage Notes, but I don't think I'll bother with an RCF. But is there a way to undo a ++RELEASE that has been issued erroneously? Gell-Mann's Totalitarian Principle says that since there's no natural law against it, it must happen. Shmuel, do you feel so jealous and threatened by Ed's basic competency that you must pounce three times in 12 minutes when an opportunity arises? If Ed wishes a notification of PTF availability to appear among the HOLDDATA, he could supplement his: ++HOLD(fmid) ERROR FMID(fmid) REASON(aparnum) with ++HOLD(fmid) ERROR FMID(fmid) REASON(PTFnum) /* Available 2-23--01-26 */ The PTF can resolve the earlier hold by SUPerseding the reason and the later by matching the reason. -- gil ---------------------------------------------------------------------- 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
