On Sun, 26 Apr 2009 15:08:35 -0500, Field, Alan C. wrote:
>Here's more of the explanation:
>
>"Order B8456491 was Rejected at 06:50:56 04/23/2009</TEXT>
><TEXT>UA46439
>(CO-REQ) <--- Fix not found</TEXT> </COER_REJ>
>.
>From the above, the order failed as Co-Req UA46439 was not found.
>Looking at UA46439, it has been closed Cancel. This will need to be
>addressed by the ptf owners, DFSMSHSM. UA46439 should still not be
>being called out if it has been cancelled."
>
Understood. Perhaps there was a process violation: when a PTF
is canceled, should all dependent PTFs be canceled alike? This
may be impractical, sometimes involving an inordinate amount of
rework.
An alternative is to provide HOLDDATA:
++ HOLD( UA46439 ) ERROR REASON( UA46640 ) ...
etc. to cause SMP/E to seek the COR PTF when UA46439 is called
out.
Alas, I fear I've had such discussions (dare I say disagreements)
with our own development leaders: "Why bother with ++HOLD ERROR
if the PTF is CANcelled and will never be distributed?" This
scenario provides the reason. The counter argument is that ++HOLD
ERROR creates a bad impression whether with customers or performance
review.
And in the OP's text, I see much ShopZ jargon, as opposed to SMP/E.
Is it possible that ShopZ fails to understand SMP/E's processing
or to reflect its structures fully? If so, so much the worse for
ShopZ.
My present (for the time being) employer's web site has a much
richer structure than my former (in a manner of speaking) employer's.
I now work for a company with a more significant software LOB.
Their service web site has a concept of PRErequisite and SUPERsede
(only the jargon is different). More dismaying is that the rules
differ. The structure welcomed by SMP/E:
++ PTF( A ) ...
++ PTF( B ) ... PRE( A ) ...
++ PTF( C ) ... PRE( B ) SUP( A ) ...
is rejected as an "unhealthy relationship". For the time being,
I am not reflecting SUPs to the web site protocol (they _do_
remain effective in the PTF body). I have a battle to fight
here. In the short term, I'm pessimistic: there's too much
else occurring.
In the long term (if I last so long) there may be more hope. We
may (probably) be metamorphosing into a company with not only a
significant software LOB, but even a z/OS software LOB. Time
will tell.
>On Sat, 25 Apr 2009 21:09:48 -0500, Field, Alan C. wrote:
>>
>>this problem with the cancelled PTF that is co-req'd by the PTFs in
>>SDM and DSS. HSM PTF's UA46642 UA46641 UA46640 were created and now
>>closed COR, and these supercede the cancelled PTFs. So if you pull
>>these you should be able to get the maintenance on. It appears the
>>problem is that the SDM and DSS PTFs call for the cancelled HSM PTF
>>instead of its superceding PTF.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
