I fully agree with this opinion. John T. Abell Tel: 800-295-7608 Option 4 President International: 1-416-593-5578 Option 4 E-mail: john.ab...@intnlsoftwareproducts.com Fax: 800-295-7609
International: 1-416-593-5579 International Software Products www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, May 06, 2019 1:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 6.2 and ARCH(12) I don't think this is an ARCH problem at all. I think the darned debugger is just plain buggy. You say the debugger is experiencing S0C4's (as well as S0C1's). I don't think an ARCH mismatch can cause a S0C4 (at least not in the real world -- someone might be able to come up with a theoretical example). An ARCH problem would almost always result in a S0C1. Nor should an ARCH issue ever cause a problem on a newer machine (compile ARCH(8), run on z14) but only on an older machine (compile ARCH(12), attempt to run on z10). Ergo, I do not think you have an ARCH problem, I think the debugger has a bug problem. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Chapman Sent: Monday, May 6, 2019 8:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 6.2 and ARCH(12) Charles, Thanks for the explanation. Our system IGYCOPT specifies ARCH=*8. We are only experiencing this issue on our production machine. We clone our machine for DR, but our test systems are never started so the debugging tool would never be used on this machine. Simulation debuggers are not allowed on our production systems. Thank you, Brian Chapman On Mon, May 6, 2019 at 10:34 AM Charles Mills <charl...@mcn.org> wrote: > > How does z/OS handle a situation where two COBOL programs that are > compiled > > at different ARCH levels and part of the same LE enclave? Since the > vendor > > code receives execution first, does it determine the enclave level? > > I don't think an enclave HAS an ARCH level. ARCH is a compiler parm. > If you were writing a compiler, your compiler code would say "can I > use machine instruction XYZ? Nope, user said ARCH(n), so no can do." > The code you emitted would be fixed (of course): it would never, ever > have an instruction XYZ in it. If the user ran it on a zWhatever, it > would still be devoid of XYZ instructions. The enclave does not have > an ARCH level, the various programs running there either do or do not include > instruction XYZ. > > > I'm not > > sure what ARCH level the vendor compiles their COBOL code (if they > > have any). > > They need to know. I was until very recently responsible for a vendor > product written in C++. There was a conscious management decision to > support customers back through a z9, so I compiled ARCH(7). End of > story. I did not pick some new ARCH level that appealed to me that day. > > Question: did you possibly customize or parametize the debugger for a > z14 during installation, and then clone that installation over to your > older DR machine? > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Brian Chapman > Sent: Monday, May 6, 2019 6:13 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 6.2 and ARCH(12) > > I verified a few of my recent COBOL listings, and they all have > ARCH(8) specified. > > Our applications developers claim that this issue only occurs when > they run their code through the debugger. It apparently never occurs > outside the debugger. The issue has been very intermittent, so it > hasn't been easy to replicate but we have dumps from most of the 0C1 or 0C4 > abends. > > How does z/OS handle a situation where two COBOL programs that are > compiled at different ARCH levels and part of the same LE enclave? > Since the vendor code receives execution first, does it determine the > enclave level? I'm not sure what ARCH level the vendor compiles their > COBOL code (if they have any). > > > Thank you, > > Brian Chapman > > ---------------------------------------------------------------------- > 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