Is the abend in the user compiled instructions? Then check the
compiler processor settings.
Is the abend in the vendor compiled libraries or included subroutines?
Then check the vendor's subroutine / runtime libraries.
On Fri, May 3, 2019 at 6:52 PM Charles Mills <charl...@mcn.org> wrote:
>
> I think I disagree.
>
> You compile the program for ARCH(8). IBM guarantees that it will run on a z10
> (do I have that right?). They do NOT guarantee that the program plus LE will
> behave on a z114 exactly as though it were running on a z10.
>
> No matter what ARCH the program were compiled for, I would expect that LE
> running on a z114 might well exploit the actual hardware. I would be kind of
> unhappy if it did NOT.
>
> The vendor product either supports z114's or it does not. If they do not
> support z114 instructions, they should admit that they do not.
>
> > If LE really is doing this, why even have an ABO product
>
> To update ("optimize") the *compiled* object code. The OS-resident
> support/library modules (LE) are a different matter. They are already (I am
> guessing) at a current level.
>
> What is the z/OS release? I would expect LE to be built for the lowest level
> hardware that that release supported, but LE might be clever enough to
> dual-path, and I think that would be a good thing.
>
> Charles
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mark Zelden
> Sent: Friday, May 3, 2019 3:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL 6.2 and ARCH(12)
>
> On Fri, 3 May 2019 15:57:34 -0400, Brian Chapman <bchapma...@gmail.com> wrote:
>
> >We have a vendor debugging product that is constantly causing 0C1 and 0C4
> >abends since we have upgraded to COBOL 6.2. It also caused these abends
> >when we were at COBOL 4,2, but the abend rate has grown considerably after
> >the upgrade.
> >
> >The vendor has produced countless patches, but so far they have not
> >resolved the issues. We were notified today that they believe they
> >understand the issue. They are stating that even though our COBOL compiler
> >is set with ARCH(8) (to support our DRE machine), LE run-time is
> >recognizing that the program is COBOL 6.2, running on a z14, and
> >automatically switch the ARCH level to ARCH(12). They believe the run-time
> >execution is exploiting the new Vector Packed Decimal Facility and
> >producing erratic behavior.
> >
> >I searched through several presentations and IBM manuals for COBOL 6.2, and
> >everything I have found states that a recompile with ARCH(12) is required
> >to take advantage of the new facility. Is the vendor correct?
> >
> >
>
> I've never heard of that and I wouldn't expect IBM to ever do something like
> that,
> but heck, what do I know. ;-) LE shouldn't be trying to outsmart the
> person that
> compiled the code (IMHO).
>
> 1) Have you verified the options in a compile listing are as you expected?
>
> 2) Are you running ABO and could that be involved? Although I know nothing
> about
> configuration ABO (I have never "seen" or used it), even if you were I woudn't
> think you would have it configured to use z14 instructions.
>
> If LE really is doing this, why even have an ABO product. I certainly would
> open
> an SR with IBM LE support about it.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
