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