Re: ENF 54 (SDUMP event)
Wayne Driscoll said: snip Having 2 API's, one internal, one external has a large number of negative consequences, including increasing maintenance effort, because if there is a defect, both API's have to be investigated, and possibly modified and the increased testing requirements, including ongoing regression testing. /snip It all depends on how you define API. Is the interface the parameter list and the linkage to the service or is it the executable macro one uses to invoke the service? I'd argue that it is not always clear or consistent for z/OS. Obviously, the back end service routines can't figure out if they were called by code generated by a macro or hand cobbled by a developer. There are clearly cases within z/OS where the BCP developers have access to a greater variety of parameters to the same exact linkage and back end routines for a number of system services. There is no technical reason to not provide a mapping and executable macro (in SYS1.MACLIB?) for the unwashed masses and separate macros (in an internally accessible maclib, not shipped with the product) for the Priests of the Temples of Syrinx that both wind up invoking the same back end code. Scott Fagen Chief Architect - System z CA Technologies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENF 54 (SDUMP event)
In my case, for the ENF event 54 (SDUMP) I got back an error , during the ENFREQ call, so I can't listen to this event. Would be not bad , but as Peter Relson told , there is no any event like this in the current code . On 12.06.2013 11:16, Scott Fagen wrote: Wayne Driscoll said: snip Having 2 API's, one internal, one external has a large number of negative consequences, including increasing maintenance effort, because if there is a defect, both API's have to be investigated, and possibly modified and the increased testing requirements, including ongoing regression testing. /snip It all depends on how you define API. Is the interface the parameter list and the linkage to the service or is it the executable macro one uses to invoke the service? I'd argue that it is not always clear or consistent for z/OS. Obviously, the back end service routines can't figure out if they were called by code generated by a macro or hand cobbled by a developer. There are clearly cases within z/OS where the BCP developers have access to a greater variety of parameters to the same exact linkage and back end routines for a number of system services. There is no technical reason to not provide a mapping and executable macro (in SYS1.MACLIB?) for the unwashed masses and separate macros (in an internally accessible maclib, not shipped with the product) for the Priests of the Temples of Syrinx that both wind up invoking the same back end code. Scott Fagen Chief Architect - System z CA Technologies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENF 54 (SDUMP event)
Don, While I work for IBM, I am not in the z/OS development team, but here is my personal take. Having 2 API's, one internal, one external has a large number of negative consequences, including increasing maintenance effort, because if there is a defect, both API's have to be investigated, and possibly modified and the increased testing requirements, including ongoing regression testing. Given that resources are tight everywhere, this type of approach seems to have more negatives then positives. == Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(at)us(dot)ibm(dot)com == IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 06/06/2013 11:06:06 AM: From: Don Williams donb...@gmail.com To: IBM-MAIN@listserv.ua.edu, Date: 06/06/2013 11:13 AM Subject: Re: [IBM-MAIN] ENF 54 (SDUMP event) Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu I'm surprised that IBM did not setup two ENF APIs, one documented for customers, and an internal one for IBM. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, June 06, 2013 7:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENF 54 (SDUMP event) All signals that are intended to be listened for are documented. All others are for IBM use only and you are not supposed to listen for them (and as an authorized program it is expected that you follow the rules). Clearly it is good to understand what listenable signals are produced so that you can decide if they are useful to you; surely the mere presence of a signal does not imply usefulness. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENF 54 (SDUMP event)
Your point is well taken. However, I figured that the customer ENF API and the IBM internal ENF API would likely be quite different due to having different goals. The internal API could have features that IBM might not be willing to extend to the customer or even other vendors. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Driscoll Sent: Friday, June 07, 2013 10:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENF 54 (SDUMP event) Don, While I work for IBM, I am not in the z/OS development team, but here is my personal take. Having 2 API's, one internal, one external has a large number of negative consequences, including increasing maintenance effort, because if there is a defect, both API's have to be investigated, and possibly modified and the increased testing requirements, including ongoing regression testing. Given that resources are tight everywhere, this type of approach seems to have more negatives then positives. == Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(at)us(dot)ibm(dot)com == IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 06/06/2013 11:06:06 AM: From: Don Williams donb...@gmail.com To: IBM-MAIN@listserv.ua.edu, Date: 06/06/2013 11:13 AM Subject: Re: [IBM-MAIN] ENF 54 (SDUMP event) Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu I'm surprised that IBM did not setup two ENF APIs, one documented for customers, and an internal one for IBM. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Peter Relson Sent: Thursday, June 06, 2013 7:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENF 54 (SDUMP event) All signals that are intended to be listened for are documented. All others are for IBM use only and you are not supposed to listen for them (and as an authorized program it is expected that you follow the rules). Clearly it is good to understand what listenable signals are produced so that you can decide if they are useful to you; surely the mere presence of a signal does not imply usefulness. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM- MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENF 54 (SDUMP event)
All signals that are intended to be listened for are documented. All others are for IBM use only and you are not supposed to listen for them (and as an authorized program it is expected that you follow the rules). Clearly it is good to understand what listenable signals are produced so that you can decide if they are useful to you; surely the mere presence of a signal does not imply usefulness. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENF 54 (SDUMP event)
Thank you Peter, I try to follow the rules On 06.06.2013 13:54, Peter Relson wrote: All signals that are intended to be listened for are documented. All others are for IBM use only and you are not supposed to listen for them (and as an authorized program it is expected that you follow the rules). Clearly it is good to understand what listenable signals are produced so that you can decide if they are useful to you; surely the mere presence of a signal does not imply usefulness. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENF 54 (SDUMP event)
I'm surprised that IBM did not setup two ENF APIs, one documented for customers, and an internal one for IBM. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, June 06, 2013 7:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENF 54 (SDUMP event) All signals that are intended to be listened for are documented. All others are for IBM use only and you are not supposed to listen for them (and as an authorized program it is expected that you follow the rules). Clearly it is good to understand what listenable signals are produced so that you can decide if they are useful to you; surely the mere presence of a signal does not imply usefulness. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENF 54 (SDUMP event)
if no ENF signal, nothing to do . That seems to imply that if there were such an ENF signal there would be something (for your application, presumably) to do. That seems not to be a good idea. Can you explain? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENF 54 (SDUMP event)
This application is try to listening a list of signals, events (I find it useful), for example: - job END jes event - logrec event - Health Checker event - Different config changes etc. etc If an event occurs from the selected type, it writes, to a LOG stream, the event record as it is. I can browse the event log etc etc. For me a DUMP generation(SDUMP) also some kind of event, and now a DUMP exit writes this to my event LOG stream . I thought maybe it would go with an SDUMP signal also, but currently I got this from the DUMP exit (IEAVTSEL) On 05.06.2013 14:27, Peter Relson wrote: if no ENF signal, nothing to do . That seems to imply that if there were such an ENF signal there would be something (for your application, presumably) to do. That seems not to be a good idea. Can you explain? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENF 54 (SDUMP event)
Thank you , if no ENF signal, nothing to do . On 30.05.2013 13:55, Peter Relson wrote: There are a lot of ENF's that are for IBM use only, for which case I would expect there to be no details in the books. While it is possible that this is an oversight, it is more likely that it is not. I don't actually see anything in the SDUMP code that issues an ENF signal. Perhaps there is no such signal produced any longer, even if there is an event code assigned. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ENF 54 (SDUMP event)
Hi I see that there is an ENF 54 , SDUMP event, but find no details for this. -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
