I'm having trouble accessing www.redbooks.ibm.com today. Just me?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> In versions 5 and 6 of Cobol, IBM has introduced the option of including
> the compile listing (or at least the data from which a compile listing can
> be derived) into the load module for subsequent debug processing.
> Presumably this obviates the need to maintain something like the DDIO file
>
This morning, when logging on to IBMLink, I receive the following error after
entering my userid/password.
-=-=-=-=-=-
Error 500: java.lang.NullPointerException
There has been a problem processing your request.
Please try again. If you continue to have difficulties, please contact IBMLink
Check out APAR PI89400 for details on a new problem with Time Change. You are
exposed if you installed PTFs for PI78252.
Check this ASAP!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
> SLIP A=RECOVERY will stop the ability, but it will do it by causing
>a 06F abend in VSM or RSM while their FRRs are still in place, so their
>recovery will run, and will likely take an SDUMP of the 06F abend.
>
>Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
>Poughkeepsie
>I already have VSM ALLOWUSERKEYCSA(NO). This health check fires anyway.
> Apparently there are other ways of getting user key storage, not just
>in CSA. Good of IBM to tell us all to write our own code to traverse
>SMF 30. Not all of us have SAS, MICS, MXG, etc. You should have
>written
Tom, good points.
However, I've been working with the SMF data, and have to say it's not very
helpful. Similar in fact to the system-level health check. The SMF record only
says that User Key common storage was allocated by some program in this address
space.
But which program in this address
I hope folks don't misunderstand my point. User Key Common is a scurge and we
can't be rid of it soon enough.
However, IBM needs to understand that their current offering of a PER IF SLIP
trap / GTF trace is not a user-friendly way to identify the culprit.
On my system, JES2AUX and DEVMAN are both flagged. "I" suspect they are
innocent, but perhaps I should just open PMRs and have those components prove
it.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
>Which brings me to my question: Do I still have to set slip traps or >can I be
>sure to have caught everything?
Barbara
I would think your RASP dump would only be a point in time view of User Key
Common at the instant of taking the dump. User Key Common that didn't exist at
the time you took
10 matches
Mail list logo