Re: Migration to Enterprise COBOL V5.2

[Salva Carrasco]

- Yes, ARCH(11) for z13

- We found a program (only one) that needed 1.7GB to compile. And a lot of them 
requiring up to 600MB. So we use REGION=0M & IEFUSI.

- CANCEL sentence when mixing 4.2 & 5.2 do not free used memory under certain 
circumstances. We opened some PMR about this, but still having some issues.

- STRING 'PREFIX' DATA DELIMITED BY SIZE INTO DATA, give 
'PREFIXPREFIXPREFIX...' in 5.2 'PREFIXOLD DATA' in 4.2. Although prohibited, we 
had some cases.

- IF FIELD = ZERO, for FIELD = low-values.

Thanks. salva.

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

Re: Migration to Enterprise COBOL V5.2

[Mike Schwab]

You will need to maintain compatibility with your lowest level of
hardware, prime or DR.

On Wed, Jun 1, 2016 at 4:44 PM, Bill Woodger  wrote:
> Why wouldn't ARCH(11) give the best performance? V5.2 has it? Of course, has 
> to be for a z13.
>
> I'm not sure what you mean about REGION=0M. At least 200M will be needed, 
> more for large programs. See here: 
> http://www.ibm.com/support/knowledgecenter/SSQ2R2_9.0.0/com.ibm.ent.cbl.zos.doc/migrate/igymbhv.html.
>  If 0M doesn't get enough memory, it will need to be changed.
>
> ARCH for DRS/BRS is covered in the Migration Guide, and is obviously 
> important.
>
> What issue are you aware of with CANCEL from V4.2 to V5.2?
>
> The behaviour of STRING with the same source and target is undefined by the 
> COBOL Standard (1985 and later). Whether the undefined behaviour is different 
> with the new compiler I don't know, but it doesn't matter if it is (such code 
> would be unreliable under any previous IBM COBOL compiler).
>
> IF FIELD = ZERO is not necessarily false for 4.2 or true for 5.2, it depends. 
> Certainly incorrect zones in data can cause different behaviours. With PACK 
> and CP for a "USAGE DISPLAY" field, the zones are quietly ignored. With CLC, 
> that matters. Possibly with DFP, I don't know. V4.2 uses both PACK/CP and CLC 
> at different times depending on compiler options and whether fields are 
> signed. V5.2 probably has more different ways to do it. See here, 
> https://www.ibm.com/developerworks/community/forums/html/topic?id=22ae65fe-5199-426a-bc61-3cc340d726c2=25,
>  for some discussion.
>
>  On Wednesday, 1 June 2016 20:16:37 UTC+2, Salva Carrasco  wrote:
>> - Test(DWARF): Increase size in library but not in memory, debug data is 
>> only loaded at error/abend time.
>> - Best CPU usage if using Arch(9/10) on execution.
>> - Worst compile CPU/Time/Storage. REGION=0M, IEFUSI, ...
>> - Take an eye on latest maintenance, specially LE.
>> - Be aware of Arch level for your BRS site.
>> - Be aware of CANCEL sentence for mixed 4.2 & 5.2 Cobol load modules.
>> . Be aware of STRING sentence when using same source & target data field.
>> - Be aware of low-values decimal zones. IF FIELD = ZERO, false for 4.2, true 
>> for 5.2. Look at ZONEDATA *new* option.
>
> --
> 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

Migration to Enterprise COBOL V5.2

[Bill Woodger]

Why wouldn't ARCH(11) give the best performance? V5.2 has it? Of course, has to 
be for a z13.

I'm not sure what you mean about REGION=0M. At least 200M will be needed, more 
for large programs. See here: 
http://www.ibm.com/support/knowledgecenter/SSQ2R2_9.0.0/com.ibm.ent.cbl.zos.doc/migrate/igymbhv.html.
 If 0M doesn't get enough memory, it will need to be changed.

ARCH for DRS/BRS is covered in the Migration Guide, and is obviously important.

What issue are you aware of with CANCEL from V4.2 to V5.2?

The behaviour of STRING with the same source and target is undefined by the 
COBOL Standard (1985 and later). Whether the undefined behaviour is different 
with the new compiler I don't know, but it doesn't matter if it is (such code 
would be unreliable under any previous IBM COBOL compiler).

IF FIELD = ZERO is not necessarily false for 4.2 or true for 5.2, it depends. 
Certainly incorrect zones in data can cause different behaviours. With PACK and 
CP for a "USAGE DISPLAY" field, the zones are quietly ignored. With CLC, that 
matters. Possibly with DFP, I don't know. V4.2 uses both PACK/CP and CLC at 
different times depending on compiler options and whether fields are signed. 
V5.2 probably has more different ways to do it. See here, 
https://www.ibm.com/developerworks/community/forums/html/topic?id=22ae65fe-5199-426a-bc61-3cc340d726c2=25,
 for some discussion.

 On Wednesday, 1 June 2016 20:16:37 UTC+2, Salva Carrasco  wrote:
> - Test(DWARF): Increase size in library but not in memory, debug data is only 
> loaded at error/abend time.
> - Best CPU usage if using Arch(9/10) on execution.
> - Worst compile CPU/Time/Storage. REGION=0M, IEFUSI, ...
> - Take an eye on latest maintenance, specially LE.
> - Be aware of Arch level for your BRS site.
> - Be aware of CANCEL sentence for mixed 4.2 & 5.2 Cobol load modules.
> . Be aware of STRING sentence when using same source & target data field.
> - Be aware of low-values decimal zones. IF FIELD = ZERO, false for 4.2, true 
> for 5.2. Look at ZONEDATA *new* option.

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

Migration to Enterprise COBOL V5.2

[Bill Woodger]

Are there no internal IBM methods of asking?

There's the COBOL Cafe at the Compile Cafe: 
https://www.ibm.com/developerworks/community/forums/html/forum?id=----2281,
 a couple of compiler developers visit. There's also some advice posted there, 
and elsewhere.

If the site has *very large* programs, V6.1 could/would be a better choice, as 
the compiler uses 64-bit addressing allowing it to consume larger programs more 
efficiently (or at all for OPT(2)).

Without knowing which compiler options have been chosen, it is difficult to say 
about the size. Unless it is the debugging, 3-4 times the size for OPT(2) 
sounds excessive, as does 50% for OPT(0). OPT(0) does do some optimisation. 
In-lining of some PERFORMs does increase size. Prior to V5 there is a "cap" to 
the size increase. I don't know that that has changed.

Consult the fix list, 
http://www-01.ibm.com/support/docview.wss?uid=swg27041164, and review what is 
and isn't applied already. 

CPU times should generally improve, and should be noticeable.

Hopefully the compile options chosen are largely those already in use. Note 
that there are some new "diagnosis"-type options which can help to identify 
things which could cause different behaviours.

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

Re: Migration to Enterprise COBOL V5.2

[Salva Carrasco]

- Test(DWARF): Increase size in library but not in memory, debug data is only 
loaded at error/abend time.
- Best CPU usage if using Arch(9/10) on execution.
- Worst compile CPU/Time/Storage. REGION=0M, IEFUSI, ...
- Take an eye on latest maintenance, specially LE.
- Be aware of Arch level for your BRS site.
- Be aware of CANCEL sentence for mixed 4.2 & 5.2 Cobol load modules.
. Be aware of STRING sentence when using same source & target data field.
- Be aware of low-values decimal zones. IF FIELD = ZERO, false for 4.2, true 
for 5.2. Look at ZONEDATA *new* option.

Good look.

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

Re: Migration to Enterprise COBOL V5.2

[Mike Schwab]

No change in coding.  Change in placement of object code.

On Wed, Jun 1, 2016 at 11:49 AM, Itschak Mugzach <imugz...@gmail.com> wrote:
> Sure. Less cup and much more manual work when a subroutine is updated...
>
> ITschak
>
> נשלח מה-iPad שלי
>
> ‫ב-1 ביוני 2016, בשעה 19:44, ‏‏Mike Schwab ‏<mike.a.sch...@gmail.com> כתב/ה:‬
>
>> Increase in size would indicate small subroutines converted to
>> instream code.  Branches are expensive, so more core means faster /
>> less CPU programs, at expense of more memory / I/O.
>>
>>> On Wed, Jun 1, 2016 at 11:40 AM, Paul Strauss <strau...@us.ibm.com> wrote:
>>> My customer wants to start the migration to Enterprise COBOL V5.2. I know
>>> V6.1 is out but we need to get going on this project. I have deleted all
>>> COBOL compilers below Enterprise COBOL V4.2 from their systems. I worked
>>> with an applications representative and they have decided on the compiler
>>> options they want. Load library conversion to PDSE is complete. Analysis
>>> of load libraries looking for OS/VS COBOL and determining which of those
>>> load modules are still in use has been determined and they will be
>>> recompiled either with Enterprise COBOL V4.2 or V5.2. I know there are
>>> some others things to look at but these are done.
>>>
>>> If there is a COBOL specific web site for these types of questions that
>>> would be a better place for these questions please let me know.
>>>
>>> Some users have been playing with the new compiler and comparing it with
>>> Enterprise COBOL V4.2. They have picked a few current programs and
>>> compiled, linked and run them. One load module was 3-4 times as big when
>>> compiled with OPT(2). With OPT(0) it was  %50 larger. Is this a typical
>>> increase in size for V5.2 compiles?
>>>
>>> Has anyone noticed a difference in CPU execution time either way?
>>>
>>> A size increase would not be a big problem but a large increase in CPU
>>> time would be.
>>>
>>> Thank You,
>>>
>>> Paul Strauss
>>>
>>> IBM Global Services
>>> z/OS MVS and Program Products
>>> Department F2VE
>>> 150 Kettletown Rd.
>>> Southbury, CT 06488
>>> (203) 272-2758
>>> strau...@us.ibm.com
>>>
>>> NOTICE: This e-mail message and all attachments may contain confidential
>>> information intended solely for the use of the addressee. If you are not
>>> the intended recipient, you are hereby notified that you may not read,
>>> copy, distribute or otherwise use this message or its attachments. If you
>>> have received this message in error, please notify the sender by email and
>>> delete all copies of the message immediately.
>>>
>>>
>>> --
>>> 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
>
> --
> 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

Re: Migration to Enterprise COBOL V5.2

[Frank Swarbrick]

Do you compile with the TEST option?  If you used TEST(SEPARATE) before and 
just use TEST now, then before your debug information was in a separate file, 
and now its included as a NOLOAD section of the executable program object.

Or it could be something else.  :-)
> Date: Wed, 1 Jun 2016 12:40:42 -0400
> From: strau...@us.ibm.com
> Subject: Migration to Enterprise COBOL V5.2
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> My customer wants to start the migration to Enterprise COBOL V5.2. I know 
> V6.1 is out but we need to get going on this project. I have deleted all 
> COBOL compilers below Enterprise COBOL V4.2 from their systems. I worked 
> with an applications representative and they have decided on the compiler 
> options they want. Load library conversion to PDSE is complete. Analysis 
> of load libraries looking for OS/VS COBOL and determining which of those 
> load modules are still in use has been determined and they will be 
> recompiled either with Enterprise COBOL V4.2 or V5.2. I know there are 
> some others things to look at but these are done. 
> 
> If there is a COBOL specific web site for these types of questions that 
> would be a better place for these questions please let me know.
> 
> Some users have been playing with the new compiler and comparing it with 
> Enterprise COBOL V4.2. They have picked a few current programs and 
> compiled, linked and run them. One load module was 3-4 times as big when 
> compiled with OPT(2). With OPT(0) it was  %50 larger. Is this a typical 
> increase in size for V5.2 compiles?
> 
> Has anyone noticed a difference in CPU execution time either way?
> 
> A size increase would not be a big problem but a large increase in CPU 
> time would be.
> 
> Thank You,
> 
> Paul Strauss
> 
> IBM Global Services
> z/OS MVS and Program Products 
> Department F2VE
> 150 Kettletown Rd.
> Southbury, CT 06488
> (203) 272-2758 
> strau...@us.ibm.com
> 
> NOTICE: This e-mail message and all attachments may contain confidential 
> information intended solely for the use of the addressee. If you are not 
> the intended recipient, you are hereby notified that you may not read, 
> copy, distribute or otherwise use this message or its attachments. If you 
> have received this message in error, please notify the sender by email and 
> delete all copies of the message immediately.
> 
> 
> --
> 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: Migration to Enterprise COBOL V5.2

[Itschak Mugzach]

Sure. Less cup and much more manual work when a subroutine is updated...

ITschak

נשלח מה-iPad שלי

‫ב-1 ביוני 2016, בשעה 19:44, ‏‏Mike Schwab ‏<mike.a.sch...@gmail.com> כתב/ה:‬

> Increase in size would indicate small subroutines converted to
> instream code.  Branches are expensive, so more core means faster /
> less CPU programs, at expense of more memory / I/O.
> 
>> On Wed, Jun 1, 2016 at 11:40 AM, Paul Strauss <strau...@us.ibm.com> wrote:
>> My customer wants to start the migration to Enterprise COBOL V5.2. I know
>> V6.1 is out but we need to get going on this project. I have deleted all
>> COBOL compilers below Enterprise COBOL V4.2 from their systems. I worked
>> with an applications representative and they have decided on the compiler
>> options they want. Load library conversion to PDSE is complete. Analysis
>> of load libraries looking for OS/VS COBOL and determining which of those
>> load modules are still in use has been determined and they will be
>> recompiled either with Enterprise COBOL V4.2 or V5.2. I know there are
>> some others things to look at but these are done.
>> 
>> If there is a COBOL specific web site for these types of questions that
>> would be a better place for these questions please let me know.
>> 
>> Some users have been playing with the new compiler and comparing it with
>> Enterprise COBOL V4.2. They have picked a few current programs and
>> compiled, linked and run them. One load module was 3-4 times as big when
>> compiled with OPT(2). With OPT(0) it was  %50 larger. Is this a typical
>> increase in size for V5.2 compiles?
>> 
>> Has anyone noticed a difference in CPU execution time either way?
>> 
>> A size increase would not be a big problem but a large increase in CPU
>> time would be.
>> 
>> Thank You,
>> 
>> Paul Strauss
>> 
>> IBM Global Services
>> z/OS MVS and Program Products
>> Department F2VE
>> 150 Kettletown Rd.
>> Southbury, CT 06488
>> (203) 272-2758
>> strau...@us.ibm.com
>> 
>> NOTICE: This e-mail message and all attachments may contain confidential
>> information intended solely for the use of the addressee. If you are not
>> the intended recipient, you are hereby notified that you may not read,
>> copy, distribute or otherwise use this message or its attachments. If you
>> have received this message in error, please notify the sender by email and
>> delete all copies of the message immediately.
>> 
>> 
>> --
>> 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

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

Re: Migration to Enterprise COBOL V5.2

[Mike Schwab]

Increase in size would indicate small subroutines converted to
instream code.  Branches are expensive, so more core means faster /
less CPU programs, at expense of more memory / I/O.

On Wed, Jun 1, 2016 at 11:40 AM, Paul Strauss <strau...@us.ibm.com> wrote:
> My customer wants to start the migration to Enterprise COBOL V5.2. I know
> V6.1 is out but we need to get going on this project. I have deleted all
> COBOL compilers below Enterprise COBOL V4.2 from their systems. I worked
> with an applications representative and they have decided on the compiler
> options they want. Load library conversion to PDSE is complete. Analysis
> of load libraries looking for OS/VS COBOL and determining which of those
> load modules are still in use has been determined and they will be
> recompiled either with Enterprise COBOL V4.2 or V5.2. I know there are
> some others things to look at but these are done.
>
> If there is a COBOL specific web site for these types of questions that
> would be a better place for these questions please let me know.
>
> Some users have been playing with the new compiler and comparing it with
> Enterprise COBOL V4.2. They have picked a few current programs and
> compiled, linked and run them. One load module was 3-4 times as big when
> compiled with OPT(2). With OPT(0) it was  %50 larger. Is this a typical
> increase in size for V5.2 compiles?
>
> Has anyone noticed a difference in CPU execution time either way?
>
> A size increase would not be a big problem but a large increase in CPU
> time would be.
>
> Thank You,
>
> Paul Strauss
>
> IBM Global Services
> z/OS MVS and Program Products
> Department F2VE
> 150 Kettletown Rd.
> Southbury, CT 06488
> (203) 272-2758
> strau...@us.ibm.com
>
> NOTICE: This e-mail message and all attachments may contain confidential
> information intended solely for the use of the addressee. If you are not
> the intended recipient, you are hereby notified that you may not read,
> copy, distribute or otherwise use this message or its attachments. If you
> have received this message in error, please notify the sender by email and
> delete all copies of the message immediately.
>
>
> --
> 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

Migration to Enterprise COBOL V5.2

[Paul Strauss]

My customer wants to start the migration to Enterprise COBOL V5.2. I know 
V6.1 is out but we need to get going on this project. I have deleted all 
COBOL compilers below Enterprise COBOL V4.2 from their systems. I worked 
with an applications representative and they have decided on the compiler 
options they want. Load library conversion to PDSE is complete. Analysis 
of load libraries looking for OS/VS COBOL and determining which of those 
load modules are still in use has been determined and they will be 
recompiled either with Enterprise COBOL V4.2 or V5.2. I know there are 
some others things to look at but these are done. 

If there is a COBOL specific web site for these types of questions that 
would be a better place for these questions please let me know.

Some users have been playing with the new compiler and comparing it with 
Enterprise COBOL V4.2. They have picked a few current programs and 
compiled, linked and run them. One load module was 3-4 times as big when 
compiled with OPT(2). With OPT(0) it was  %50 larger. Is this a typical 
increase in size for V5.2 compiles?

Has anyone noticed a difference in CPU execution time either way?

A size increase would not be a big problem but a large increase in CPU 
time would be.

Thank You,

Paul Strauss

IBM Global Services
z/OS MVS and Program Products 
Department F2VE
150 Kettletown Rd.
Southbury, CT 06488
(203) 272-2758 
strau...@us.ibm.com

NOTICE: This e-mail message and all attachments may contain confidential 
information intended solely for the use of the addressee. If you are not 
the intended recipient, you are hereby notified that you may not read, 
copy, distribute or otherwise use this message or its attachments. If you 
have received this message in error, please notify the sender by email and 
delete all copies of the message immediately.


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