Re: How does ABO report its outcome? (was: Migrating Cobol)

[Frank Swarbrick]

Hmm, we always use the TEST compile option for production modules.  This allows 
IBM Fault Analyzer to have access to the source code.  I am not aware of any 
performance differences.


Frank



From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Edward Gould <edgould1...@comcast.net>
Sent: Tuesday, March 28, 2017 5:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does ABO report its outcome? (was: Migrating Cobol)

> On Mar 28, 2017, at 3:47 PM, Bill Woodger <bill.wood...@gmail.com> wrote:
>
> Without any TEST option on the compile, LE gives you nothing but the offset 
> of the failing instruction, then you find it in the compile listing. ABO gets 
> you a new listing of the new code, a new place to consult for the offset.
>
> If you compile with TEST options, the code generated for those options still 
> exists in the ABO'd program, and if from the original program that results in 
> additional information in the LE dump, then it will still do so after the 
> program has been ABO'd.


Bill:

In the past we have found that compiling COBOL programs with test meant a hell 
of a lot more run time and of course CPU usage went up as well.
I would *NEVER* suggest TEST in a production environment.

Ed
--
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: AW: How does ABO report its outcome? (was: Migrating Cobol)

[Tom Marchant]

On Tue, 28 Mar 2017 21:31:11 +0200, Peter Hunkeler wrote:

>
>>There is a new listing when a program is processed by ABO, and this listing
>>is used by IBM Fault Analyzer, but it is not used by LE.  For CEEDUMP, you
>>would manually map the offset to the line number.
>
>So what you're saying is that an optional chargeable product knows how to 
>handle problems with ABO optimized code, but the standard runtime 
>environment does not? Really? What is the rationale behind?

What he is saying is that there is an optional chargeable product that will 
help you to analyze abends in your code. The information is available for 
you to analyze the dump yourself. This is the same as without ABO.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How does ABO report its outcome? (was: Migrating Cobol)

[Bill Woodger]

There was no suggestion attempted (for anything) just an explanation that if 
you have used options which augment the LE abend output (which should also 
include CEEDUMP) then ABO will leave those alone.

This was in reference to Peter's question posted immediately prior: 

"So what [is being said] is that an optional chargeable product knows how to 
handle problems with ABO optimized code, but the standard runtime environment 
does not? Really? What is the rationale behind?"

Paid-for products can understand the ABO output. Base LE output with no TEST 
options is the same, ABO or non-ABO. You look at the listing. Just may involve 
looking at a different listing, or require looking at two listings. TEST 
options can augment LE abend-output.

There's no substantial difference between the handling of an abending ABO'd 
program and a non-ABO'd program.

"A little something" to merge original compile listing with ABO output listing 
could be useful for someone to write.

On Tue, 28 Mar 2017 18:02:43 -0500, Edward Gould  
wrote:

>> On Mar 28, 2017, at 3:47 PM, Bill Woodger  wrote:
>> 
>> Without any TEST option on the compile, LE gives you nothing but the offset 
>> of the failing instruction, then you find it in the compile listing. ABO 
>> gets you a new listing of the new code, a new place to consult for the 
>> offset.
>> 
>> If you compile with TEST options, the code generated for those options still 
>> exists in the ABO'd program, and if from the original program that results 
>> in additional information in the LE dump, then it will still do so after the 
>> program has been ABO'd.
>
>
>Bill:
>
>In the past we have found that compiling COBOL programs with test meant a hell 
>of a lot more run time and of course CPU usage went up as well.
>I would *NEVER* suggest TEST in a production environment.
>
>Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How does ABO report its outcome? (was: Migrating Cobol)

[Edward Gould]

> On Mar 28, 2017, at 3:47 PM, Bill Woodger  wrote:
> 
> Without any TEST option on the compile, LE gives you nothing but the offset 
> of the failing instruction, then you find it in the compile listing. ABO gets 
> you a new listing of the new code, a new place to consult for the offset.
> 
> If you compile with TEST options, the code generated for those options still 
> exists in the ABO'd program, and if from the original program that results in 
> additional information in the LE dump, then it will still do so after the 
> program has been ABO'd.


Bill:

In the past we have found that compiling COBOL programs with test meant a hell 
of a lot more run time and of course CPU usage went up as well.
I would *NEVER* suggest TEST in a production environment.

Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AW: How does ABO report its outcome? (was: Migrating Cobol)

[Bill Woodger]

Without any TEST option on the compile, LE gives you nothing but the offset of 
the failing instruction, then you find it in the compile listing. ABO gets you 
a new listing of the new code, a new place to consult for the offset.

If you compile with TEST options, the code generated for those options still 
exists in the ABO'd program, and if from the original program that results in 
additional information in the LE dump, then it will still do so after the 
program has been ABO'd.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: How does ABO report its outcome? (was: Migrating Cobol)

[Peter Hunkeler]

>There is a new listing when a program is processed by ABO, and this listing
is used by IBM Fault Analyzer, but it is not used by LE.  For CEEDUMP, you
would manually map the offset to the line number.




So what you're saying is that an optional chargeable product knows how to 
handle problems with ABO optimized code, but the standard runtime environment 
does not? Really? What is the rationale behind?


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

How does ABO report its outcome? (was: Migrating Cobol)

[Tom Ross]

>To help search engines: ABO = Automatic Binary Optimizer

>>We haven't set off down the yellow-brick ABO road, so it's hard to gauge h=
>>ow much angst we'll actually have to overcome. I'm pretty sure it won't be =
>>trivial.


>I haven't seen ABO in action yet. Is there a listing that relates the instr
>uctions after the optimization to the source statement? I suspect, there is
>n't. Is LE still able to tell the statement where the problem occurred? How
> would one find the source statement that cause the the problem to occur?
>I'm often involved in cases where I have to work with machine readable dumps.

There is a new listing when a program is processed by ABO, and this listing
is used by IBM Fault Analyzer, but it is not used by LE.  For CEEDUMP, you
would manually map the offset to the line number.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How does ABO report its outcome? (was: Migrating Cobol)

[Peter Hunkeler]

>As far as finding the source statement, yes this is possible with ABO.
 >
>We run IBM's Fault Analyzer and it has PTFs that make it compatible with ABO 
>optimized code.  So, this tool can go through the updated 'listing' file 
>produced as part of the ABO output to help get back to the original source 
>code.
 >
>I would guess that other tools (ie: Abend Aid) would be able to do the same 
>thing.
 >
>As far as doing it manually - good luck, but with the output from the 
>optimization run, you can probably figure out how to get back to your original 
>code.



We don't have IBM's Fault Analyzer, and as I mentioned, we do not (yet) have 
ABO. Nevertheless, thanks for your answer.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: How does ABO report its outcome? (was: Migrating Cobol)

[Peter Hunkeler]

>I think a lot of it will depend on 'how good is your COBOL?'. Yeah define  
>good. Anyway using 'IBM ABO software' did find an .html Knowledge Center
>link.
  >
>https://www.ibm.com/support/knowledgecenter/SSERQD_1.2.0/c
>om.ibm.opt.doc/ug/troubleshooting.html




That basically answers my question. Thanks


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How does ABO report its outcome? (was: Migrating Cobol)

[Bill Woodger]

The output listing from the ABO process is designed to mesh with the output 
from the original compile.

If it doesn't, or there are difficulties, problems, suggestions for 
improvement, let IBM know.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How does ABO report its outcome? (was: Migrating Cobol)

[DiBianca, Robert]

As far as finding the source statement, yes this is possible with ABO.

We run IBM's Fault Analyzer and it has PTFs that make it compatible with ABO 
optimized code.  So, this tool can go through the updated 'listing' file 
produced as part of the ABO output to help get back to the original source code.

I would guess that other tools (ie: Abend Aid) would be able to do the same 
thing.

As far as doing it manually - good luck, but with the output from the 
optimization run, you can probably figure out how to get back to your original 
code.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, March 27, 2017 9:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does ABO report its outcome? (was: Migrating Cobol)

So ABO optimizes LOAD modules.

Optimized applications created with Automatic Binary Optimizer for z/OS are 
supported by IBM DevOps Tools, which include IBM Application Delivery 
Foundation for z Systems family of products:

Developer for z Systems Enterprise Edition, which includes Debug for z 
Systems (previously known as Debug Tool for z/OS). Helps examine, monitor, and 
control the execution of application programs.

Fault Analyzer for z/OS.

Helps developers analyze and fix application and system failures.

Gathers information about an application and the surrounding 
environment.

Application Performance Analyzer for z/OS. Helps developers in the design, 
development and maintenance cycles with an non-intrusive application 
performance analyzer.

Additional information can be found on the Application Delivery Foundation for 
z Systems website.


Not sure if this helps or not.

Check out this PDF.  Also, make sure all current fixes are applied to ABO 
http://publibfp.boulder.ibm.com/epubs/pdf/c2785453.pdf



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Peter Hunkeler
> Sent: Sunday, March 26, 2017 10:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How does ABO report its outcome? (was: Migrating Cobol)
>
> To help search engines: ABO = Automatic Binary Optimizer
>
> >We haven't set off down the yellow-brick ABO road, so it's hard to
> >gauge how
> much angst we'll actually have to overcome. I'm pretty sure it won't
> be trivial.
>
>
>
>
> I haven't seen ABO in action yet. Is there a listing that relates the
> instructions after the optimization to the source statement? I
> suspect, there isn't. Is LE still able to tell the statement where the
> problem occurred? How would one find the source statement that cause
> the the problem to occur? I'm often involved in cases where I have to work 
> with machine readable dumps.
>
> --
> Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information in this transmission may contain proprietary and non-public 
information of BB or its affiliates and may be subject to protection under 
the law. The message is intended for the sole use of the individual or entity 
to which it is addressed. If you are not the intended recipient, you are 
notified that any use, distribution or copying of the message is strictly 
prohibited. If you received this message in error, please delete the material 
from your system without reading the content and notify the sender immediately 
of the inadvertent transmission.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How does ABO report its outcome? (was: Migrating Cobol)

[Lizette Koehler]

So ABO optimizes LOAD modules.  

Optimized applications created with Automatic Binary Optimizer for z/OS are
supported by IBM DevOps Tools, which include IBM Application Delivery Foundation
for z Systems family of products:

Developer for z Systems Enterprise Edition, which includes Debug for z
Systems (previously known as Debug Tool for z/OS). Helps examine, monitor, and
control the execution of application programs.

Fault Analyzer for z/OS.

Helps developers analyze and fix application and system failures.

Gathers information about an application and the surrounding
environment. 

Application Performance Analyzer for z/OS. Helps developers in the design,
development and maintenance cycles with an non-intrusive application performance
analyzer. 

Additional information can be found on the Application Delivery Foundation for z
Systems website.


Not sure if this helps or not.

Check out this PDF.  Also, make sure all current fixes are applied to ABO
http://publibfp.boulder.ibm.com/epubs/pdf/c2785453.pdf



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: Sunday, March 26, 2017 10:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How does ABO report its outcome? (was: Migrating Cobol)
> 
> To help search engines: ABO = Automatic Binary Optimizer
> 
> >We haven't set off down the yellow-brick ABO road, so it's hard to gauge how
> much angst we'll actually have to overcome. I'm pretty sure it won't be
> trivial.
> 
> 
> 
> 
> I haven't seen ABO in action yet. Is there a listing that relates the
> instructions after the optimization to the source statement? I suspect, there
> isn't. Is LE still able to tell the statement where the problem occurred? How
> would one find the source statement that cause the the problem to occur? I'm
> often involved in cases where I have to work with machine readable dumps.
> 
> --
> Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How does ABO report its outcome? (was: Migrating Cobol)

[Edward Finnell]

I think a lot of it will depend on 'how good is your COBOL?'. Yeah define  
good. Anyway using 'IBM ABO software' did find an .html Knowledge Center  
link.
 
https://www.ibm.com/support/knowledgecenter/SSERQD_1.2.0/c
om.ibm.opt.doc/ug/troubleshooting.html
 
 
In a message dated 3/27/2017 12:36:14 A.M. Central Daylight Time,  
p...@gmx.ch writes:

I  haven't seen ABO in action yet. Is there a listing that relates the  
instructions after the optimization to the source statement? I suspect, there  
isn't. Is LE still able to tell the statement where the problem occurred? 
How  would one find the source statement that cause the the problem to occur? 
I'm  often involved in cases where I have to work with machine readable 
dumps.  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

How does ABO report its outcome? (was: Migrating Cobol)

[Peter Hunkeler]

To help search engines: ABO = Automatic Binary Optimizer

>We haven't set off down the yellow-brick ABO road, so it's hard to gauge how 
>much angst we'll actually have to overcome. I'm pretty sure it won't be 
>trivial.




I haven't seen ABO in action yet. Is there a listing that relates the 
instructions after the optimization to the source statement? I suspect, there 
isn't. Is LE still able to tell the statement where the problem occurred? How 
would one find the source statement that cause the the problem to occur? I'm 
often involved in cases where I have to work with machine readable dumps.

--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN