IBM Redbooks site down ?
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
Re: Cobol 5/6 - Compile listing integrated into load module
> 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 > required by Compuware's Expeditor product. For what it's worth, Compuware tools no longer "require" separate DDIO files. Check out "Embedded Source Support" which is a new feature - it basically puts the DDIO information into NOLOAD segments of the program object. It is a new option, but separate DDIO files are still supported of course. Sure sounds a lot simpler to manage, but we've not tried it yet. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBMLink down ?
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 customer support. -=-=-=-=-=- Just me? I did try both Firefox and IE... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Heads Up: PI89400 Time Change Red Alert
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UA94606
> 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 NY Wouldn't a DIAGxx option be nicer? I think so! Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UA94606
>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 a sample, IBM!! > >Regards, >Tom Conley I opened a PMR today, and learned that ALLOWUSERKEYCSA(NO) only stops one of the three User Key Common Storage uses that will cease to be available in z/OS vNext. This is all that's available today on z/OS 2.2 and z/OS 2.3. I was offered a PER SLIP that could stop the other two Common Storage uses (after OA53355) - User Key Scope=Common Data Spaces and User Key ESQA key changes, which are the other two bit flags in the SMF30_RAXFLAGS byte. I don't think a PER trap is appropriate for long term use on a production system - I just want the option to stop all of these uses of User Key storage now - before z/OS vNext. By the way, to stop the ability to create a user key CADS after OA53355, use the suggested PER SLIP and change A=TRACE to A=RECOVERY - or so I understand. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
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 space did it? The SMF record doesn't say. We have third party vendor code who's programs run in a variety of address spaces. Is it the address space flagged by the SMF record, or is the culprit actually a third party product that interjects it's code into the "victim" or target address space? The SMF record doesn't say. Back some years ago, when we were cleaning up obsolete/ancient console identifiers, I seem to recall a console tracker facility that gave us actual honest to god program names. How about something like that? Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
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 email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBMVSM,ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM
>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 the dump wouldn't appear, right? Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
