Without answering the direction question, are you aware that the general
intent of this (and some other) checks where the "problem" cannot be fixed
usually without a re-IPL is to report on the "problem" until you update the
check's parameter to, in effect, say "I understand, I will deal with it
when convenient, please do not tell me again unless I explicitly ask"?
So we recommend updating the parameter with some sort of time/date thing
that indicates when you did it so that you could look back at the parameter
and know "oh, it was Wednesday last week that I last indicated this, so
anything being reported upon came about after that". For example an update
to PARM('NEW(20071010 12:00)') And to request "I forgot, please show me
everything" an update to PARM(ALL).
It does seem strange that the check would report on a LNKLST set that was
no longer defined. This turns out to be an "optimization". Well, an
over-optimization. We'll see in a release if we can do better. The
optimization is to avoid fetching "new" LNKLST data (it uses CSVDYNL
REQUEST=LIST which is not worth doing again if "nothing has changed") if no
new LNKLST has been activated since the last time the check run.
Unfortunately, if a LNKLST changes state (as can happen when you do a
LNKLST UPDATE), it means that that updated state is not seen. You can
overcome this deficiency by refreshing the check -- MODIFY
hzsproc,REFRESH,CHECK(IBMCSV,CSV_LNKLST_NEWEXTENTS)
Of course I hope everyone is aware that LNKLST UPDATE should be done only
as a last resort. I really do mean it when I say that it is unpredictably
dangerous.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
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
