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: [email protected]
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:[email protected]] On Behalf
Of Charles Mills
Sent: Monday, May 06, 2019 1:08 PM
To: [email protected]
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:[email protected]] On Behalf
Of Brian Chapman
Sent: Monday, May 6, 2019 8:25 AM
To: [email protected]
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 <[email protected]> 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:[email protected]]
> On Behalf Of Brian Chapman
> Sent: Monday, May 6, 2019 6:13 AM
> To: [email protected]
> 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 [email protected] with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
