On 2014-06-20, at 16:17, R.S. wrote:
> ...
> My ideas how to solve it:
>
> 1. Simply BYPASS HOLDERROR. I don't like it, especially I'm not sure about
> further results of such bypass.
>
Read the COMMENT() supplied with the HOLDDATA, or the APAR text.
It's possible your system configuration is not affected; even
plausible since the vendor did not discover the problem in
regression test and published the PTF, only to have a problem
reported later. Make an informed decision whether to BYPASS.
> 2. Replace HOLDDATA with older one or just reject newest HOLDDATA. Is it
> possible? How?
>
HOLDDATA are cumulative; RECEIVEing an older one has no effect;
there's no REJECT for HOLDDATA.
The vendor could code a ++RELEASE
http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.gim2000/mcsrel.htm
• ++RELEASE statements unconditionally remove a SYSMOD from exception
status and
should, therefore, be used with caution. To install a SYSMOD that is
currently
in exception status, you should probably not create and process a
++RELEASE
statement, but rather use the appropriate BYPASS operand of the APPLY or
ACCEPT command.
I'll echo and emphasize the caution. RELEASE is extraordinary; I'd expect
a vendor (and never a customer) to issue one only in an extreme case such
as the original HOLD's having been issued erroneously, perhaps for a symptom
later judged WAD or for a typo in a PTF ID.
BYPASS is safer, and retains an audit trail that you could view with the
REPORT ERRSYSMODS command.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
