Re: Are there samples of COBOL methods or classes?

[Tom Ross]

Please check out the examples in the COBOL Programming Guide, in
Part 6. Developing object-oriented programs

GO here:  https://www.ibm.com/support/pages/node/611415
Select which release you are interested in and then
click "Product Documentation"

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: Are there samples of COBOL methods or classes?

[Tom Ross]

>As the very first computer language I learned was COBOL, I have been always=
> interested to learn=20
>about OO COBOL but never had the necessary time to research it.
>
>Are there by any chance simple COBOL snippets that would demonstrate how to=
> use OO COBOL to interact=20
>with Java (e.g. creating a Java object, invoking a simple method with argum=
>ents and fetch the=20
>returned value) and a comparable example for COBOL 6.4?

Are the examples of OO COBOL to Java that we include in the COBOL Programming
Guide helpful?

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: Checkpoint/restart in COBOL applications?

[Tom Ross]

Thank you all for your input!  The reason for the question is that IBM
is consdering removing the CHKPT macro and is wondering if it is used
much.  The COBOL runtime uses CHKPT for our checkpoint/restart functionality,
I think DFSORT does as well, and also Broadcom's Smart/RESTART facility.

There is also Smart/RESTART functionality that does NOT use CHKPT, so how
to figure out what the impact would be is difficult!  In COBOL, we do not
know how many applications have RERUN in them (the keyword that triggers
taking a checkpoint) and if those applications are important or still being
used!

There will be more investigation into what the impact of removing the
CHKPT macro might have on our vendors and customers...

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

Checkpoint/restart in COBOL applications?

[Tom Ross]

Greetings!

  Does anyone know if there are people/applications using checkpoint/restart in
COBOL applications?  The doc only shows it is usable in programs that use SORT,
I have not heard of customers doing this in years, but someone in IBMMAIN would
know better than me!  The reason for the question is that IBM is considering
removing that capability from z/OS and we are wondering how much of an impact,
if any, this would be on COBOL applications?  (Actually PL/I also, but I work
in COBOL so kind of focused on that :-)

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

Are there samples of COBOL methods or classes?

[Tom Ross]

>Hi, While working on the earlier problems I had, I ran into the concepts=20
>of COBOL Methods and Classes, and understand they can be used for Java=20
>in addition to regular COBOL programs. The documentation does not=20
>explain the "why" behind these or the "how" and "what", so I wonder if=20
>anyone has any business case explanations of what these are or samples=20
>of some COBOL-only implementations so I can see why I might want to use=20
>them and how to do it?
>
>I like to keep my COBOL current and if there is a way to use COBOL more=20
>effectively, I hope you can help me understand this!


OO COBOL was added to COBOL to provide a way to communicate with Java, which
does not have programs that can be called.  Java has to run in the JVM, and
you INVOKE methods in CLASSes with Java, you do not CALL programs.  So, in
order to support this we created OO COBOL (the 2nd generation, 1st gen OO COBOL
was based on SOM if anyone remenber that in the late 1990s).  OO COBOL is only
for communicatiing for Java, unless you REALLY prefer OO programming.  The real
worl is not object oriented...we do no instantiate a customer object and then
invoke a 'send_a_bill' method on that object.  We procedurally decide that it
is time to send a cusotmer a bill and do it!

Haivng said that, we now have an easier way to allow COBOL to use Java code,
actually using the COBOL CALL statement, this new feature is available in
COBOL 6.4.  If you do not need to communicate with Java, I would not
recommend OO COBOL.  The promise of Object Oriented Programing in the 1990s
has not materialized.  Re-usable tested mehods that could be re-used to build
applications  it just not really happening!  One of my fellow IBMers left
IBM for a start up and was slinging Java all day, and found it much easier to
code new methods than to search through class libraries for pre-tested parts.

Having said all that, it was pointed out earlier that we have seample in the
COBOL Programing Guide for comunicating woith Java using OO COBOL.  OO COBOL
was not designed to be used in a pure COBOL application, so no examples of
that.

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

How to call zEDC functions from an HLL other than C [was: RE: Unzip

[Tom Ross]

>I submitted an RCF on the subject of examples for actually using zEDC funct=
>ions from HLL's other than C not long after this message chain and received=
> no response at all from the RCF team.  A follow-up email requesting status=
> or at least an acknowledgement that the documentation addition suggestion =
>had been received did get a response, which was:

Peter,
  Sorry I did not see your post earlier!  I get the digest version of IBMMAIN
and search for COBOL to see if there is something I should comment on.
I am glad you were able to find my example of using zEDC from COBOL.
The zEDC team asked me to try it out from COBOL so I wrote a testcase to get
it working, then published it in our COBOL books. The zEDC team said that
they would put a pointet to COBOL books in the zEDC books,
I guess they did not do that (yet?)


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: LE runtime

[Tom Ross]

>BTW: I didn't say "strange debugging option"; what is strange IMO is the=20
>fact
>that COBOL requires the modules in PDSEs not because the language needs=20
>this,
>but only to support some debugging tools, which could IMO store their=20
>information
>at another place. But the COBOL community seems to have accepted this move.

 There are many reasons why new COBOL programs have to be Program Objects and
cannot be Load Modules.  As a result of requiring Program Objects, we were
able to also solve a long-standing problem for customers: Keeping the debugging
data in sync with the executable and making that data available.  With the
NOLOAD class program segmenets in new COBOL the debugging data is always
available, always in sync, and does not negatives impacl load performance.

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: I knew Cobol 6.3 takes more resources to compile than 4.2 but should I be concerned about how much?

[Tom Ross]

>Hi list,
>
>I got a resolution for this compile-time issue yesterday and installed it o=
>n my sandbox this morning.  PTF UI81630 (the July accum maintenance) has th=
>e fix in it.  After installing the fix, the 3 INITCHECK options perform in =
>essentially the same amount of resources.  TCB time for the INITCHECK(LAX) =
>as well as STRICT dropped by 90%, back to the roughly 54 CPU seconds.
>
>Thank you, IBM Cobol team for sticking with it and fixing the issue.
>
>Rex

I You are welcome, glad we could help!  Sorry you ran into this...but
now it is improved for everyone!


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

User-written condition handlers with COBOL

[Tom Ross]

Hi all!
  Does anyone know of shops that use user-written condition handlers in their
COBOL applications?  I mean the type that are registered with CEEHDLR or with 
the
run-time option USRHDLR.  If so, we at IBM would like to know what the condition
handlers do...Would customers rely on condition handlers to handle the condition
and resume the application? Or would customers register condition handler for
information collection instead?

  Over the years I have explained to hundreds of COBOL programmers how to use
them at SHARE and Guide, but I really don't know if anyone actually does!

Thanks and Cheers,
TomR (AKA Captain COBOL in some circles) >> 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

Converting assembler to COBOL help

[Tom Ross]

Greetings mainframers!

This has porobbaly been asked and answered, but are there tools or companies
that can convert or help to rewrite assembler applications or just programs
into COBOL?  Any suggestions?


Cheers,
TomR  >> COBOL is the Language of the Future! <<
AKA:  Captain COBOL, Tom Ross

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

Re: COBOL V6 question

[Tom Ross]

>The compile time costs should be tolerable given benefits of runtime execut=
>ion.  Has IBM been able to provide, or have other people seen demonstrable =
>benefits?

We have seen results all over the map!  One customer recompiled an application
and found it to run 70% faster!  Seventy percent!  Others get 5% - 40%
improvement.  With very small programs the benefit it minimal, some CICS
customers do not see much improvement.  One CICS customer in Chicago told us
they got over 50% improvmenet in throughput with COBOL V6, they could change
their business processes to handle more claims!

In general, customers compile a program once or three times, then put it into
production and run it thousands or millions of times, so the payback is
definitely there in overal CPU savings!

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

COBOL V6 question

[Tom Ross]

>Well I just inherited COBOL support and our programmers have been trying to=
> debug an issue with CICS COBOL, seems Ent COBOL V4 was still being used in=
> CICS TS 5.4. the tool used is Endeavor, long story short, V6 was being tes=
>ted in some processes but never updated in others.=20
>my question is mostly a sanity check, from what I've read the DB2 pre compi=
>ler and the CICS translators are no longer needed, COBOL parms and options =
>are now used if these are DB2 or CICS programs ?
>this is valid ?

You can still use the separate Db2 precompiler and CICS translator!
In fact, migrating to the new integrated method is not always easy, so I
would not recommend moving to a new compiler AND a new precompile/translate
process at the same time!  We often see issues with the Db2 precompiler
allowing things that should not have been allowed, like text after END-EXEC
or literals longer than 160 bytes, and these won't work with the integrated
SQL coprocessor (COBOL SQL compiler option).


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

COBOL V4.2 to V6.3

[Tom Ross]

>Then we take this file and execute through the PRELINK step.
>The prelink program name is EDCPRLK.
>
>This is where the problem occurs.

The prelinker is no longer supported with COBOL V5 and later.  The COBOL
migration guide explains what to do instead, normally just use the binder
(what used to be called the linkage editor)

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: COBOL 6.2 - use of identical data name in a nested COMMON subpro

[Tom Ross]

>In my specific case, there is a COPY structure populated in the outermost p=
>rogram level that is passed in CALL statements to nested COMMON subprograms=
> (which can also CALL each other) and all the COMMON subprograms use the sa=
>me COPY structure to define their LINKAGE parameter.  I just did not and do=
> not understand why the compiler cannot use the "local" LINKAGE section def=
>inition in the nested COMMON subprograms.
>
>There are only two levels of nesting here, outermost and then each COMMON s=
>ubprogram at the same level below that.
>
>This works flawlessly when subprograms are not nested but separately compil=
>ed as stand-alone units, so I do not see why it is different in a nested ve=
>rsion.  It makes no sense.
>
>Is there a way to tell the compiler that a structure at the OUTERMOST level=
> is NOT to be shared with nested programs?  That would solve the particular=
>  problem that I have, I think.

I tested this out myself, and I was able to refer to a data item X1 in
a nested program even though X1 was also defined in the containing program.
I was thinking that names in containing programs are automatically GLOBAL,
but they are not.  Are you sure the name in the containing program is
not GLOBAL?

This worked for me:

   WORKING-STORAGE SECTION.
   1  X1 PIC X(8) VALUE 'SUB1'.
   PROCEDURE DIVISION.
   MOVE 'SUB1' To X1.
   ID DIVISION.
   PROGRAM-ID. SUB1.
   ENVIRONMENT DIVISION.
   DATA DIVISION.
   WORKING-STORAGE SECTION.
   1  X1 PIC 9.
   PROCEDURE DIVISION.
   Compute X1 = 5.


With X1 being non-unique...I wonder why it did not work for you?


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

COBOL 6.2 - use of identical data name in a nested COMMON subprogram generates a IGYPS0037-S compiler error

[Tom Ross]

>The V6.2 Language Reference Manual on page 60 says this about using identic=
>al names in nested programs:=20
>
>"Identical names
>When programs are directly or indirectly contained within other programs, e=
>ach program can use identical
>user-defined words to name resources.
>A program references the resources that program describes rather than the s=
>ame-named resources
>described in another program, even if the names are different types of user=
>-defined words."

This passage only refers to names that are identical between 2 nested programs.
In your case you have a name in the containing program, which is global to all
nested programs, being identical to a name in a nested program.

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

Linkling an object from VSE to be used in z/OS

[Tom Ross]

>Hi,
>I was asked to attempt to link a object deck from VSE in z/OS.
>The program is a COBOL2 program, but the source has been lost.

I have been recommending The Source Recovery Company for 25 years!
 https://www.source-recovery.com/
You can send them your executable (not the object deck) and they
can re-create the COBOL source!  The data names and paragraph names
will be machine generated, but you could compile with COBOL V6 on z/OS!

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

Sv: COBOL compiler option to list libraries from which COPY members were loaded?

[Tom Ross]

>And You can't use coprocess if You are using EXCI.
>//Lasse=20


That changed a couple of years ago for COBOL!  (Still true for PL/I)

https://www.ibm.com/support/pages/use-integrated-cics-translator-exci-batch-programs

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: COBOL compiler option to list libraries from which COPY members were loaded?

[Tom Ross]

><*Doh!*>
>
>I missed seeing that part of the listings entirely.  And it has the same pa=
>ge title back at least as far back as ECOBOL V4.1.0.

You guys are great!  I added "cross reference of library names" to the COBOL
compiler listings years ago, glad it is getting used, and thank you for pointing
it out to help each other out!

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

COBOL and LE version question

[Tom Ross]

>One of my fellow sysprogs has asked me to get an answer to the follow quest=
>ion:
>
>Will a load module compiled with COBOL v6.3 and linked with LE v2.4 on z/OS=
> 2.4 operate on z/OS v2.3 with LE v2.3 runtime libraries?
>
>I will, however, also ask the slightly inverse question:  Will a load modul=
>e compiled with COBOL v4.2 and linked with LE v2.3 operate on z/OS v2.4 wit=
>h LE v2.4 runtime libraries?

LE is both upward and downward compatible as long as the z/OS levels are
in service.  There are some restrictions, such as using new features of
LE 2.4 might not run on LE 2.3, but that is rare.  Here is the full 'legal'
statement:
https://www.ibm.com/docs/en/zos/2.4.0?topic=environment-downward-compatibility-considerations

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

COBOL V5+

[Tom Ross]

Larry,

>In the manuals it says that PARMCHECK adds a string of hex values at the
>end of COBOL WORKING-STORAGE.

This is true!

>I assumed that it also did the same for each 01 level in the LINKAGE
>SECTION, which logically made sense that the compiler would acquire another
>piece of storage to copy the 01 level to and append the string of hex
>values.

This is NOT true, PARMCHECK is only checking for a migration problem where the
sub program would overwrite storage following WORKIN-STORAGE.  PARMCHECK is
not for validating all paramter usage.  Parameter misuse in general will be
the same in COBOL V5/V6 as in earlier COBOL versions, so it is not a
migration problem in general, it is only a problem when the subprogram s
over-writes storage beyond the end of WORKING-STORAGE.

>Removing them one at a time, compiling, new copying, and testing in the
>CICS region.  With no success, I finally tried removing NOTEST(DWARF).
>Eureka, no more CICS GETMAINS for each of the LINKAGE SECTION 01 levels.
>Not what I was expecting.  None of the documentation suggested that
>NOTEST(DWARF) would affect runtime.  It should only come into play when
>into play when the program ABENDs.
>This does affect the time for each transaction a great deal.

I have never heard of this, is seems wrong to me.  Please open a CASE with
IBM service and have us look into this!

I have a question for you, why would you use NOTEST(DWARF) instead of 
TEST(DWARF)?
TEST is very efficient these days, many shops run in production with TEST.

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

Accurate listing of IDRDATA to TRANSLATOR ID's

[Tom Ross]

>Does IBM maintain a list of Translator ID's that corollate to the language
>processor/compiler product that produced CSECTS?  Purpose is to identify=2
>
>What version of a compiler produced the CSECT.  The goal is to identify
>COBOL VS modules when reviewing an AMBLIST LISTIDR output. =20

All COBOL compilers AFTER OS/VS COBOL put out IDR data in the object program.
OS/VS COBOL does NOT put out IDR, you have to programmatically analyze to
figure out what the compiler was.  COBANAL by Roland Schiradin does this,
as does IBM Load Module Analyzer, IBM File Manager, and Compuware File-AID.
For VS COBOL II and later you can use IDR data.










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

COBOL V6.2 possible change in behavior with recent patch level

[Tom Ross]

>We recently applied patches up through September 2020 to our Enterprise COB=
>OL V6.2 compiler.  Prior to this we had patches through September 2019.  Th=
>is appears to have changed how some code is generate, even though the compi=
>ler options have not changed.

Frank, this is unfortunate, but I have to say, we do not recommend running
COBOL programs with invalid data, and we do not recommend using ZONEDATA
with other than (PFD) as the sub option.  We keep finding new ways that
older COBOL behaved differently than new COBOL with invalid data, and in
the case you mention we had a customer complaining that the example you
posted ABENDed with COBOL V4 but not COBOL V6 with ZONEDATA(MIG), so we
changed the code.  The intention of ZONEDATA(other than PFD) is to mimic
COBOL V4, and this is a little bit of an ongoing process.  We, of course,
NEVER used to test with invalid data (data that does not match the PICTURE
and USAGE) so this is a challenging job!

The best way to go is to correct your programs and data to follow the rules.
For example, we had a customer recompile all programs in an application
with COBOL V6.1, but they did NOT folow our 2-compile 2-test migration process
to find and clean up invalid data.  The results o their regression tests
were OK, so they went into production!  All was well until they moved to
COBOL V6.2 to compile with ARCH(12) and exploit z14.  At that point they
discovered they had some invalid data processing that started causing new
ABENDs with Vector Packed Decimal instructions.

I recommend cleaning things up before declaring migration to COBOL V6 complete!

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

IGZ0099C Internal error CLLE-GPCB was detected in module IGZCEV19

[Tom Ross]

>I am receiving message
>
>IGZ0099C Internal error CLLE-GPCB was detected in module IGZCEV19
>
>after compiling a COBOL/ASSEMBLER system with COBOL V6.2
>
>The LE manual does not include these values for the IGZ0099C message. Where
>might this be documented?

Maybe you are trying to run on a system that is missing PTFs in LE to
support COBOL V6 programs.  Have you run the SMP/E MISSINGFIX command
as recommended in the COBOL Program Directory?

Note, I just learned there is a better way than what is currently
documented ...

We currently recommend this:

FIXCAT(IBM.TargetSystem-RequiredService.Enterprise-COBOL.V5R1,
   IBM.TargetSystem-RequiredService.Enterprise-COBOL.V5R2,
   IBM.TargetSystem-RequiredService.Enterprise-COBOL.V6R1,
   IBM.TargetSystem-RequiredService.Enterprise-COBOL.V6R2,
   IBM.TargetSystem-RequiredService.Enterprise-COBOL.V6R3)


But I am going to update the manuals to recmomend this instead:

FIXCAT(IBM.TargetSystem-RequiredService.Enterprise-COBOL.*)

This will tell you if you are missing PTFs required to run COBOL V6
programs.


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

Looking for an old OSVS Cobol II v1.3

[Tom Ross]

 Guys,
>I am planning to revival an old application written in OSVS Cobol II v1.3 (=
>it's important the correct release)=C2=A0for VMSP rel5 in my P370... Unfort=

Well, there never was a product called OS/VS COBOL II.  There was
 OS/VS COBOL (last release V1.2.4, never a release 3) and there was
a VS COBOL II V1.3 (several mod levels, 1.3.0 (1988) 1.3.1 (1989) and
1.3.2(1990).  So, first step is to find out what COBOL you are really after!

FYI, VS COBOL II code will compile cleanly with COBOL V6 (as long as it was
compiled with NOCMPR2 under VS COBOL II)

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: Progam directory AD/Cycle C/370

[Tom Ross]

>> entire history
>
>No, it's missing a decade.

>360S-C0-503 COBOL (E)
>
>360S-CB-524 COBOL (F)
>
>360S-CB-545 COBOL (U)
>
>5734-CB1 OS FULL AMERICAN NATIONAL STANDARD COBOL Versions 1-3  rth=20
>ime=20
>5734-CB2 OS FULL AMERICAN NATIONAL STANDARD COBOL Version 4, 5


Sam, this is good stuff!  I was looking for even older information and I found
a note about   1972   5734-CB2 ANS COBOL Version 4   but your list
fills in some more history!  I wish I could find dates, but those products are
not in our IBM databases anywmore ... I googled 5734-CB1 and found an IBM book
with this in the title:

IBM OS Full American National Standard COBOL.: Program Numbers:
Version 2, 360S-CB-545; Version 3, 5734-CB1;
Version 4, 5734-CB2 (compiler and Library) 5734-LM2 (library Only).

So, that fills in some more:

360S-CB-545 COBOL is ANS COBOL V2
5734-CB1 is ANS COBOL V3
5734-CB2 is ANS COBOL V4

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: Progam directory AD/Cycle C/370

[Tom Ross]

>BTW: Is there description/list of COBOL versions anywhere?

 I don't know, but I have lists!  Here is the entire history, no names, just
 product ids, but you can kind of tell which is which by the dates.
OS/VS COBOL, VS COBOL II, etc etc
Note: You need fixed-width caharacters to view this table:

 Program  Marketing   Service
 Number   VRM Announced   Available   Withdrawn   Discontinued

 5740-CB1 1.02.4  1974/05/13  1974/09/23  1992/12/18  1999/12/31

 5668-958 1.03.0  1988/09/13  1988/12/16  1997/06/30  1996/06/30
 5668-958 1.03.1  1989/09/19  1989/12/29  1997/06/30  1996/06/30
 5668-958 1.03.2  1990/09/05  1990/12/28  1997/06/30  1996/06/30
 5668-958 1.04.0  1992/09/15  1993/03/12  1997/06/30  2001/03/31

 5688-197 1.01.0  1991/09/11  1991/12/20  2000/09/06  1997/09/30
 5688-197 1.02.0  1995/10/24  1995/10/27  2000/09/06  2001/12/31

 5648-A25 2.01.0  1997/05/06  1997/05/23  2000/09/29  2004/12/31
 5648-A25 2.02.0  2000/09/26  2000/09/29  2002/12/31  2004/12/31

 5655-G53 3.01.0  2001/11/27  2001/11/30  2002/09/27  2004/04/04
 5655-G53 3.02.0  2002/08/20  2002/09/27  2004/02/27  2005/10/03
 5655-G53 3.03.0  2004/02/17  2004/02/27  2005/07/01  2007/04/30
 5655-G53 3.04.0  2005/06/21  2005/07/01  2008/09/29  2015/04/30

 5655-S71 4.01.0  2007/12/11  2007/12/14  2009/08/25  2014/04/30
 5655-S71 4.02.0  2009/08/25  2009/08/28  2018/03/12  2021/09/30

 5655-W32 05.01.00 2013/04/23 2013/06/21  2015/01/14  2020/04/30
 5655-W32 05.02.00 2015/01/14 2015/02/27  2017/09/11  2020/04/30

 5655-EC6 06.01.00 2016/02/16 2016/03/18  2020/03/09  -
 5655-EC6 06.02.00 2017/07/17 2017/09/08  2020/03/09  -
 5655-EC6 06.03.00 2019/09/03 2019/09/06  -   -

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

CICS COBOL co-compiler licensing?

[Tom Ross]

>Does anyone know if there is an IBM license that covers the CICS COBOL
>co-compiler short of a full-blown CICS TS license?
>
>In other words, could you license the co-compiler for a "development
>machine" without having to license the full CICS transaction server?

There is no 'partial license' for CICS that would include the
'translator services' that are called by the COBOL compiler.

You must have the CICS product in order to compile COBOL programs
that have CICS statements in them.

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

COBOL 6.3 compiler options question

[Tom Ross]

>Can somebody give me a definitive definition of the NOJTC and JTC compiler =
>options in 6.3?  I'm not seeing it in the COBOL reference or any COBOL manu=
>al for that matter, yet it shows up on the option list when we compile a pr=
>ogram:
>
>NOFLAGSTD =20
>  HGPR(PRESERVE)  =20
>NOINITCHECK   =20
>NOINITIAL =20
>  INLINE  =20
>  INTDATE(ANSI)   =20
>NOJTC =20
>  LANGUAGE(EN)=20
>  LINECOUNT(60)   =20

Rex, et al,

   Sorry about that!  JTC is an option that we are working on and not ready
to ship, but we accidentally externalized JTC in the listing.  If you apply
the latest maintenance to your compiler it will go away!

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: Goto Statements AND COBOL OPTIMIZATION

[Tom Ross]

>Those were added w/ COBOL 2002, not 2014.  Don't give yourself too much cre=
>dit!

I noticed that too, and thought I had corrected my post, but I guess I failed!

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: Goto Statements AND COBOL OPTIMIZATION

[Tom Ross]

>The addition of EXIT PARAGRAPH
>and EXIT SECTION have eliminated most of the reasons for use of GO TO
>in COBOL.  I would be interested in any corrections to my
>understanding by those responsible for the COBOL compiler. =20

I partially agree, Clark, but what really made it easy to get rid of GOTOs
in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM CYCLE!
These were added to the Standard with COBOL 2014 and implemented by IBM in 
Enterprise
COBOL for z/OS V5.2

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: What crashing COBOL systems reveal about applications maintenance -- GCN

[Tom Ross]

>Suppose that they took a group of programmers and got the production online=
> programs to all compile with COBOL 6.2 and OPT(1). Would they see a signif=
>icant reduction in MSUs?  Assuming they are running on z14s minimally?

I sure hope no one is using OPT(1) with 3rd generation COBOL!  IBM expects all 
users
to compile with OPT(2) for production performance.  I am honestly not sure why 
we
shipped OPT(1).  Users should use OPT(0) if they want more straight-forward 
debugging
(no optimizations) and then after unit test compile with OPT(2) for 
performance, and
and never use OPT(1).  Alternatively, they could compile with OPT(2) for 
debugging and
get used to odd things like statements getting moved or deleted while debugging.

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

Dynamically detect if CBLQDA is active from a COBOL program?

[Tom Ross]

>Is it possible for a COBOL program to dynamically detect if LE option CBLQDA
> is active?

Not easily...but I would be surprised if it is different for different programs
in the same region.  You can run a program with RPTOPTS(ON) to get an "options
in effect" report from LE.  You could search for CEEUOPT in your load library to
see if anyone is setting LE options on a single program.  Most likely all 
programs
are running with the same setting of CBLQDA.

Another way we might help you is to learn why you want to know about the
setting of CBLQDA for a specific program?  What problem do we need to solve 
here?

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

COBOL Migration v4 to v6.1 - CONDITIONS OF INITIALIZATION

[Tom Ross]

>Since migrating from COBOL v4 to COBOL v6.1 a few runtime abends have occur=
>red which seem to have a root cause of data items not being initialized.   =
>These data-items seem to be under a group level where the group level is in=
>itialized.

>The compile's diagnostic errors listing shows al warning messages of:
>IGYPS2047-W   "INITIALIZE" STATEMENT OPERAND  DID NOT MEET CON=
>DITIONS FOR INITIALIZATION  WAS NOT INITIALIZED.

Sorry to be so late on this...

Could you post the description of the group item and the INITIALIZE statement?
It would appear that none of the items under the group were of a type that
could be initialized, but I would like to take a look, if you have not already
moved on frmo this problem!

Also, I would be surprised if the behavior of COBOL V4 was different from COBOL 
V6,
I do not think that have not changed this code in the compiler!

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 can I generate a UUID in a z/OS COBOL Program

[Tom Ross]

We (IBM COBOL development) have accepted an RFE to add this capability of
genrating a UUID via a new Intrinsic Function, it should be available
early next year.

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

COBOL for z/OS V6R2M0

[Tom Ross]

>I have updated the COBOL options using IGY620.SIGYSAMP(IGYWDOPT), SMP/E
>usermod to update the COBOL options.  IGY620.SIGYCOMP is in the system link
>list, and the usermod updates IGYCDOPT in that load library.  After updatin
>g the
>module I refresh LLA with F LLA,REFRESH.
>
>I have used ISRDDN to search both the system link list and LPA for module
>IGYCDOPT.  It only appears in the link listed load library IGY620.SIGYLOAD.
>
>I have changed ARCH=3D7 to ARCH=3D12, OPT=3D0 to OPT=3D2, and NOBLOCK0
>to BLOCK0.  The changes I have made do not show up when I run a COBOL
>compile after applying the usermod, and refreshing LLA.  I have tried
>RESTORING the usermod, refreshing LLA, and APPLY'ing the usermod
>again.  Still the same results.

Very strange!  Have you confirmed that your updated IGYCDOPT is actually in
SIGYCOMP?  Checked the 'compile date' etc?  Have you confirmed that you got
RC=0 from the assemble of igycdopt?  One thing to try and make some sense of
would be to put your new IGYCDTOP in a different dataset and STEPLIB that
ahead of your SIGYCOMP dataset and see if you still get the old options.
Soemthing is definitely not right here...maybe some restrictions with z/PDT?

Cheers,
TomR, AKA Captain COBOL  >> 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

AMODE 64 COBOL

[Tom Ross]

As has been discussed, we are working on AMODE 64 COBOL in IBM COBOL
development and have been for some years now.  Trying to get all the
players lined up has been a challenge. (IE: CICS, DB2, IMS, DFSORT, etc)

Our understanding from the beginning was that AMODE 64 COBOL would be for
specialized cases, and not for general use.  We have very few customers
requesting AMODE 64 COBOL, and it is for special cases like moving data
above the bar to do in memory searches of very large tables where the
performance benefit outweighs any other aspect.  Currently these customers
are using AMODE 64 assembler for this specialized processing.

We do not currently think that we would recommend AMODE 64 COBOL to
everyone.  For example, if I took an AMODE 31 application and recompiled
all of the programs for AMODE 64 (just for fun, IE: no need for above the
bar data) the application would necessarily run slower.  This is because
instead of 4-byte addresses the programs would be processing 8-byte addresses.
For this reason alone, customers would most likely avoid AMODE 64 COBOL
unless they had a real need for it (IE: storage constraint with AMODE 31,
or need for improved performance for searching massive amounts of data in
memory)

So far, we have not heard of COBOL customers with data storage constraints
below the BAR.  We have heard of storage constraints for programs, especially
in CICS, where multiple CICS regions are required to allow the sheer numbers
of COBOL programs to be loaded below the BAR.  This is an RMODE 64 question,
as in ARRRMODE however, and I am focused on AMODE 64 for this posting.

Because of all of this, we consider it acceptable to have some restrictions
on using AMODE 64 COBOL.  We are also trying to do what we can to make it
easier to use AMODE 64 COBOL, but our general recommendation will most likely
be to only use AMODE 64 COBOL if you really need it, not for general purposes.

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: Anyone here exprerienced in JSON parser (assembler)

[Tom Ross]

>Tom,
>
>The program executes in key zero & supervisor mode. this is how it get
>control. Not sure I can write it in Cobol.

Well, you could WRITE it in COBOL, but you could not run it :-)-
COBOL can only run in problem state.

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: Anyone here exprerienced in JSON parser (assembler)

[Tom Ross]

 >> Is there a COBOL equivalent to JSON.stringify?
 > Yes!  It is the JSON GENERATE statement, available in 2016 in COBOL V6.1

>Awesome! I'm guessing it uses the same environment as the XML
>parser/generator?


 Well, it runs in the COBOL environment, so if you are talking about
COBOL XML GENERATE and XML PARSE (COMPAT), then yes.  If you are talking about
the XMLSS option COBOL XML PARSE, it runs in a mixture of COBOL and
'z/OS XML System Services' parser environments.

>The tricky part comes when the structure of the JSON is unknown and has=20
>to be traversed by node.

Well, JSOPN is for RESTful services, where you tell clients what the JSON
for a service request should look like.  The client and the service have to
know a little about each other. Good luck with your project!

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: Anyone here exprerienced in JSON parser (assembler)

[Tom Ross]

>On 28/08/2018 1:11 AM, Tom Ross wrote:
>>> On 22/08/2018 11:51 PM, Charles Mills wrote:
>>>
>>>> COBOL does not seem like a great choice either to me personally, but so=
>me=3D
>>>> folks, and especially some shops, are most comfortable with COBOL.
>> The JSON PARSE statement in COBOL is the keasiest way to parse JSON ever!
>
>
>You can't argue with that! Almost as easy as JavaScript :)
>
>let obj =3D JSON.parse('{ "name":"John", "age":30, "city":"New York"}');
>
>Is there a COBOL equivalent to JSON.stringify?

Yes!  It is the JSON GENERATE statement, available in 2016 in COBOL V6.1

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: Anyone here exprerienced in JSON parser (assembler)

[Tom Ross]

>On 22/08/2018 11:51 PM, Charles Mills wrote:
>> *Personally* I agree, but different languages for different folks. Some p=
>eople are very comfortable in assembler, especially with the structured mac=
>ros. I think I can state with some confidence that if @EdJaffe need to pars=
>e some JSON documents he would do it from assembler.
>

>Maybe, but I'm not so sure. If that JSON is coming over the wire into a=20
>Java web application like EJES Web then I would expect it to be=20
>serialized to a byte array in the Java layer. That's how we do it. No=20
>JSON ever reaches the assembler layer in our stack.
>
>
>>
>> COBOL does not seem like a great choice either to me personally, but some=
>>folks, and especially some shops, are most comfortable with COBOL.

The JSON PARSE statement in COBOL is the keasiest way to parse JSON ever!
You just point to a data item which contains your UTF-8 JSON text, and give
the name of a COBOL data structure (group) that you want the values from the
JSON Name/Value pairs top go into, and let COBOL do all the work for you!

You do have to be up to the 2017 COBOL compiler level, since that is when we
delivered JSON PARSE, in COBOL V6.2.

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

Best Group for COBOL Question(s)

[Tom Ross]

>And so you can enjoy this, my question is, why is it that OPT(0)=20
>overrides INITCHECK, but if I ask for Optimization (e.g, OPT(1))=20
>it works?

>Frankly, I do not want anyone using INITCHECK (IC) outside of=20
>OPT(0) which means NOOPT (except that you can't say that with=20
>COBOL 6.2).

>Yes, INITCHECK is ONLY done by the Compiler during Parse/SCAN=20
>operations and not during code gen (as I read the manual).

>But it takes more CPU for this to work, so why do that AND the=20
>CPU burn of Optimization for a compile where one is attempting to=20
>determine if fields are being referenced before they have had=20
>something put in them?

INITCHECK needs to have the path analysis using the flow graphs created
by the optimizer.  it would not be very helpful if we did not analyze
different paths to a statement, we would only find uninitialized data
items that were NEVER set.  INITCHECK can find data items that are
initialized on smoe paths but not on others, and can be quite helpful.

It does require the flow graphs that are only produced by the optimizer,
(and take memory and CPU to create) so we can only provide INITHECK
capability when OPT(1) or OPT(2) in effect.

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: Question for COBOL users

[Tom Ross]

>FWIW, I am guessing "255" was simply a brain-glitch for 100, and had no
>basis in any actual technology.

Charles, you nailed my brain fart exactly!

In response to other posts and Frank, I agree that we should answer the
RFE for a change to our SYSOPTF support as: "AVAILABLE: Use PARMDD"

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

IBM Debug tool issue

[Tom Ross]

>When using Debug Tool under CICS, every time a CALL statement is encountere=
>d the debugger steps into the called program.
>Is there a way to just have the called program called and not show its inte=
>rnal workings.
>
>We are using Debug Tool v14.1, z/OS v2.2, COBOL v6 and CICS TS v5.4.

I think what you want is STEP OVER, not STEP INTO in Debug Tool

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: Question for COBOL users

[Tom Ross]

We added OPTFILE as a response to customer request, I believe it was
well before PARMDD, but not positive.

Someone else asked what the COMPILER limit for reading the PARM=
options string is, but there is none.  There is a JCL/JES limit of
255 bytes.  There is no limit for SYSOPTF (using OPTFILE).

It seems pretty clear that we cannot change the default behavior to
read SYSOPTF whenever it is present, regardless of OPTFILE, so we
will probably add another (sigh) compiler option

>There is nothing to prevent a user or product to go ahead and use
>PARMDD, and it could point to the program's (compiler's) specific
>overrides.  The program (compiler) can only read the PARM for the
>length it specifies (100/255) until modified to allow a parm length of
>32K.  Maybe a couple releases down the road you can give a warning
>message that the program (compiler) specific parm will be removed.

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

Question for COBOL users

[Tom Ross]

IBM COBOL development needs your help!

We are reviewing a request to change our support for OPTFILE and SYSOPTF
to allow usage of DD SYSOPTF without the compiler option OPTFILE.

For background, this is where you can avoid the 255 character limit for
PARM= in JCL when specifying COBOL compiler options.  Currently, if you
specify compiler option OPTFILE, the compiler tries to OPEN the file
allocated to DD SYSOPTF, and read compiler options from that file.

OK, we got an RFE (Request For Enhancement) to have the compiler always
try to use SYSOPTF, with or without the OPTFILE compiler option.  The use
of SYSOPTF would then only be controlled by the existence of SYSOPTF.

Our concern is, would this affect current users of SYSOPTF?  Are there users
of SYSOPTF with COBOL who sometimes compile with NOOPTFILE and leave the
DD statement for SYSOPFT in their JCL/Changeman compile jobs?
If so, then automatically accessing SYSOPTF without using OPTFILE could
cause problems.

This leads to another question...do any of your shops  use OPTFILE and
SYSOPTF for COBOL compiles?

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: Lack of Support for Doc for COBOL

[Tom Ross]

>Very, considering there are literally hundreds if not thousands of shops
>still using COBOL..

Yes, it is unfortunate, but for a serious error we would reconsider our position
on COBOL V4 documentation.

In this case, the reported bug was very minor, and most of the many many COBOL
shops are already using COBOL V5 or V6, whose manuals are getting updated.

The number of defects reported against COBOL V4 is almost zero!  That is one of
the reasons why we are considering dropping support for COBOL V4.

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: MSGIEW2678S Module contains one or more deferred classes

[Tom Ross]

>On Wed, 9 Aug 2017 22:18:51 +, Frank Swarbrick .COM> wrote:
>
>>There was a post to ibm-main by Allan Kielstra of IBM compiler development=
> (I think) on May 10, 2017 (How are Program Object sections with Defer attr=
>ibute loaded?) that discusses how the writable static area (WSA) is used in=
> COBOL V5 and COBOL V6.  Briefly, this is how I understand it.  If the "NOW=
>SOPT" compiler option is used (the default in COBOL V5) then all COBOL work=
>ing-storage is placed in the WSA.  If the "WSOPT" compiler option is used t=
>hen working-storage is separately allocated upon initial entry to the progr=
>am and the address of the WS is placed in the WSA.
>>
>>Hopefully I got that all right!
>>

>Everyone talks about WSOPT vs NOWSOPT compiler option, but I can't find the=
>m documented in COBOL documentation library.
>Are WSOPT and NOWSOPT some nicknames of the accurate terms?
>Where are they documented?

Everyone?  No one should talk about this hidden option.  We added it to V5
for a specific customer situatation.  We did not want to change V5 behavior
for everyone.  COBOL V6 is now using the preferred WSOPT behavior.  That
means that WORKING-STORAGE is acquired from HEAP just like all COBOL versions
did before COBOL V5.  This in turn means that the STORAGE option can again be
used to set initial values of WOKRING-STORAGE to x'00' or x'FF' or anything.

We have improved the "How to find WORKING-STORAGE at runtime" instructions
in the COBOL V6.2 Migration Guide.  This has been a work in progress, starting
with trying to do things the 'C' way (WSA) and then moving back to having the
runtime allocate WORKING-STORAGE as in previous COBOL versions.

By the way, COBOL V5 goes out of marketing in Sept, it will no longer be
available.  Honestly, the only COBOL version I would think anyone would want
is COBOL V6.2, it has lots of things to make it more natural for COBOL
application programmers, as well as exploitation of z14 hardware and
performance improvements!

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: Any IBM announcements on COBOL v4.2 EOS

[Tom Ross]

There has been no announcment, but we have said at SHARE that we would not end
support for COBOL V4.2 before 2020.  We are now thinking that we might announce
an EOS date that is before 2020.  We don't have a final plan, we are discussing.
I just wanted to give a heads up, it could be sooner than even we thought!

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 to call VS COBOL II RES program from COBOL V5.2-enabled

[Tom Ross]

assembler?

>EXEC PGM=ASM1 (LOAD and CALL)--> VSCOB2RES
>Also:;ASM1 (LOAD and CALL via CEEPIPI)--> eCOBOL52

>Two different CAL's in one top-level assembler program to COBOL programs
>compiled with different COBOL compilers.  Either or both COBOL programs may
>be called multiple times in one execution of ASM1.

>My question was prompted by the eCOBOL V5.2 migration statement that COBOL
>V5.2 programs can call and be called by VS COBOL II RES programs.  I cannot

They can!  Not all kinds of CALLs (example: DLL CALLs) but most CALLs.
You are not talking about COBOL calling COBOL, hoever.

>use CEEPIPI to CALL the VS COBOL II RES program because CEEPIPI returns RC=20
>when you try to add it to the CEEPIPI table.

Yes, only LE-conforming programs can be used with CEEPIPI. VS COBOL II programs
are LE-enabled (can run with LE) but are not LE-conformaing (must run with LE).

>I can call the VS COBOL II RES program multiple times if I first LOAD and
>call IGZERRE once (the LE version from CEE.SCEERUN), but using IGZERRE and
>CEEPIPI together is not allowed either according to the migration guide
>(cannot establish 2 different COBOL environments at the same time in the same
>LE enclave, which makes sense to me).

If you really cannot recompile wht VS COBOL II programs with newer compilers and
save MSUs/MIPS/CPU, then you have a problem.  The easiest solution, from what
limited info I have here, is to use a different method toe keep LE active
between CALLs to COBOL.  Remove the use of IGZERRE and add a COBOL stub in front
of your ASM program! Then use the COOBL stub in the JCL:

EXEC PGM=COBSTUB (Which then CALLs ASM1, which then LOADs and CALLs any COBOL)

Since COBSTUB is always active, LE is always up, no performance hit for 
repeatedly
LOADing and BASR/BALRing to COBOL


> If eCOBOL V5.2 can call and be called by VS COBOL II RES programs, how does
> it do that, and how can I do the same thing?

Use simple CALLs, not IGZERRE or CEEPIPI.

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: COBOL integrated pre-processor, API in general

[Tom Ross]

>I wouldn't necessarily assume that there is a fixed API for EXEC CICS, EXEC=
> SQL, EXEC SQLIMS.  It's always possible that each one of these gets some s=
>ort of custom treatment from the compiler.

Bingo!  There is an interface between COBOL and DB2 precompiler services,
another between COBOL and CICS translator services, and a 3rd API between
the COBOL compiler and IMS precompielr services.  Three APIs, and I think
they are only useful for IBM, unless some vendor wants to write a COBOL
compiler that also does integrated coprocessing of EXEC SQL, EXEC CICS,
and/or EXEC SQLIMS statements.

FYI: Oracle asked us for information about these interfaces, wondering if
they could do a similar thing, but they did not follow up...

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

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

A further question regarding COBOL5 and CEEDUMP

[Tom Ross]

>A further question: the CEEDUMP we receive in COBOL 5 lacks a dump of the
>WORKING STORAGE SECTION.   Can this be remedied by changing compile-time or
>run-time parameters?

I know this is old, not sure if it got answered or not...

To get WORKING-STORAGE (and LOCAL-STORAGE) date items listed in CEEDUMP,
compile with the TEST compiler option. This is the same as previous COBOL
compilers, but I am noticing customers using different compiler options
with COBOL V5/V6 than they used with previous compilers!  Not good...

Anyway, TEST is much improved with COBOL V5/V6, we put the Debug data in a
NOLOAD class segment in the Program Object, so that it is always available,
always in sync with the load, and never takes up memory at runtime unless
it is needed.  An example of when it is needed is when a CEEDUMP is being
written/created by LE!

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

COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0=

[Tom Ross]

 )? (Msg IGYOS4021-W)

>We are beginning the transition to COBOL V5.2 from V4.2 and exploring the n=
>ew options available for debugging.

>We just discovered that the INITCHECK option is incompatible with OPTIMIZE(=
>0).  Using both options generates this warning-level message:

>IGYOS4021-W   The "INITCHECK" option was discarded due to option conflict r=
>esolution.  The "OPTIMIZE(0)" option took precedence.=20

>There is no restriction documented for INITCHECK in the V5.2 Programmer's G=
>uide and no mention of this incompatibility in the section on incompatible =
>compiler options either.

INITCHECK takes advantage of control flow analysis done by OPT(1|2) and so
cannot function with OPT(0).

We are trying to be aggressive about back-fitting migration assisting new
features but we can't  update all documentation everywhere.  The Knowledge
Center is updated every few months and is your best bet.  If we are missing
documentation, please open a PMR and we wil fix it!

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

Cobol and PreCompile for CICS and DB2

[Tom Ross]

>Does anyone remember when the Cobol Compiler could do the PreCompile
>function for CICS or DB2 without running the actual standalone
>step for Precompile?

Yes, it started with COBOL V2R2 in 2000 with the SQL compiler option,
then was continued in 2001 with the CICS option in COBOL V3R1.

Both have been supported and extended in every release since!

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: Addressing Question

[Tom Ross]

>Tom,
>
>We run our compiles using COBOL v4.2 as
>
>CBL. ...NODYN,RES,RENT,DATA(31)
>
>Run options via CEEOPTS is ALL31(ON) ..
>
>This for the caller, using AMODE(31) and RMODE ANY for the binder.
>
>We call like this call 'xx' using xx
>
>Does this imply AMODE switching ?

No.  AMODE switching is when an AMODE 31 program calls a separate executable
(Program Object or Load Module) that has AMODE 24, or from AMODE 24 to
to AMODE 31.  If the programs are bound together it is only possible to have
different AMODEsi if you have a Program Object with some segments AMODE 31
and other segments AMODE 24.  Load Modules have hte same AMODE for all entry
points.  Finally, COBOL dynamic CALL requires separate executables, and COBOL
dynamic CALL support mode switching in that case.  You can get COBOL
dynamic CALL 3 ways:
1) Call 'literal' with DYNAM compiler option
2) Call identifier  (DYNAM/NODYNA do not affect these)
3) >>CALLINTERFACE DYNAM
   Call 'literal'

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: Addressing Question

[Tom Ross]

>>
>>I think i am right in saying that RMODE(ANY) sees the program with
>>RMODE(24) and
>>its ok to execute and the I/O buffers are they 24bit or 31
>>
>>It seems unlikely that the calling program pays any attention to the RMODE
>>
>>of anything that it calls.
>>
>>It is up to the caller to meet the requirements of the callee. If the=20
>>callee is AMODE 24, then it would be expected that any data passed from=20
>>the caller to the callee be below 16M. That includes save area and=20
>>parameter list.

>Does COBOL actually have any support for AMODE-switching calls?


Yes, if you use a feature called "COBOL dynamic CALL" then a library routine
gets control and can do AMODE switching before you enter the called program.
There are 3 ways to get COBOL CALL statements to be dynamic these days!
DYNAM compiler option for CALL literal statements, CALL identifier statements,
and the >>CALLINTERFACE compiler directive.

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: ABO Automatic Binary Optimizer/COBOL V5/V6 Migration

[Tom Ross]

>ABO only creates an optimized LOAD MODULE (program object).  It does not=20
>convert your source to V6, and it will not give you all the=20
>optimizations of V6.  Your biggest payback is if you upgrade your CPU,=20
>then you can run your load modules through ABO and get some of the=20
>optimization provided by the new hardware.

I know this was a while ago, but I wanted to comment on the reference to
'convert your source to V6'.  In general, all programs compile cleanly with
COBOL V5 and COBOL V6.  If there are problems, and about 25% of customers
have had some, they are caused by invalid data in the COBOL data items at
runtime.  To fix this, users have to change the data, or the data entry
panels, or use new compiler options to tolerate the bad data.  There is
no way to do source conversion to migrate to COBOL V5/V6, like there
was years ago for OS/VS COBOL to anything newer.

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: Access to enterprise cobol datasets in production system

[Tom Ross]

>John McKown wrote:
>
>>All of this would be much easier if the COBOL people would use the IFAPRDn=
>n member of PARMLIB to check to see if the product is licensed for this sys=
>tem image.
>
>Good suggestion. [1]

Excellent suggestion!  In fact, IBM started shipping Product Registration 
support
for the COBOL compiler in 2013, with COBOL V5.1.

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

Size default in CEEPRMxx V5R1

[Tom Ross]

> We are migrating from cobol V4R2 to V5R1. Some of our test compilations ca=
>ncel with IGYLI5062-U and we must increase the default SIZE in COBOL option=
>s. We want to avoid change this option in the PARM sentence in JCL and set =
>in CEEPRMxx member in PARMLIB, but we can't find the parameter in the synta=
>x.
>Is there any way for set the default SIZE for all the compilations Jobs?

Yes, see the COBOL Customization Guide, and modifying IGYCDOPT.

However, a better option is to stop migrating to COBOL V5.1 and start
migrating to COBOL V5.2, where we solved many of the problems with compiler
storage management, and in particular, we removed the SIZE compiler option!


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: Datasets usage question

[Tom Ross]

>IEFOPZxx contains statements that define the load library data set optimiza=
>tion configuration, which could, for example, provide a list of pairings of=
> an old Cobol load library and the intended new load libraries (one for eac=

Lizette, where did you find IBM doc with COBOL misspelled as Cobol?
I searched for this to tell the writers to correct it (there are no lower
case letters in acronyms, and especially in COBOL) but was unsuccessful.
I found the exact text you quoted, but COBOL was spelled correctly:
http://www.ibm.com/support/knowledgecenter/SSERQD_1.1.0/com.ibm.opt.doc/ug/usagescenarioauto.html

Thanks!

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

New and improved IBM migration recommendations for COBOL V5

[Tom Ross]

Several things have come together to give us a better recommendation
for customers who want to migrate to COBOL V5 but who also want to avoid
discovering 'differences' when they deploy into production.

First, some background.  As usual, read the COBOL Migration Guide:
http://www-01.ibm.com/support/knowledgecenter/SS6SG3_5.2.0/welcome.html

Second, some of the most difficult problems when migrating to COBOL V5
are not caused by changes in the COBOL language supported by the compiler,
but instead are caused by 'invalid COBOL' that cannot be detected by
inspecting source code.

The top six most common of these are:
o Invalid data in numeric USAGE DISPLAY data items
o Parameter/argument size mismatch:
o Modifying data outside the bounds of a table
o Using tables when the ODO object value is not in the legal range
o Modifying data following a table with INDEXED BY indexes
o Overpopulated data items, with values that have more digits than are
   defined in the data definitions

In order to find these more easily, we should recommend that users:
- Always compile with RULES(NOEVENPACK)
- Use the "Scanning COBOL programs for compatibility" feature of
RDz 9.5 to check parameters and arguments
- Compile with SSRANGE, ZONECHECK and OPT(0) for initial code changes
and unit test
- Recompile with NOSSRANGE, NOZONECHECK and OPT(2) for quality
assurance test and production

Finally, in the topic of "Before you buy COBOL V5", we should recommend
the following:
- Install the latest maintenance on LE and other products for COBOL V5
  (Use the COBOL V5 FIXCAT feature as documented here:
   http://www-01.ibm.com/support/docview.wss?uid=swg21648871. )
- Change build processes to add REPLACE IGZEBST in the BIND/LINK step
 to fix the "old VS COBOL II bootstrap" problem
- Convert PDS load libraries to PDSE
- Locate all OS/VS COBOL programs and either target them for early
 migration to V5 or migrate to V4 now

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: Mixed COBOL ewnvironment and Ent. COBOL

[Tom Ross]

Hi Tom...

I have a question based on a comment you made to Itzchak. You said:

None specifically for the VS COBOL II modules.  OTOH, when recompiling
 with COBOL V5 we recommend a lot of testing, because it can reveal hidden=20
 invalid COBOL programs.  These programs could have been invalid for 20=20
 or 30 years, but each new release generated the same instructions so=20
 the behavior was the same. With COBOL V5, these bad programs might=20
 start getting the wrong answers.  So, for every program recompiled=20
 with COBOL V5 we recommend thorough regression testing.

I'm aware of the issue with the SEARCH ALL verb and the issue (described in
 Appendix G) about the wrong length record being flagged now in COBOL 5.

Neither of these have been problems for customer migrating to COBOL V5.

Are there other issues that would force significant regression testing over
and above normal testing? Is your comment primarily for programs last
compiled with VS COBOL II?

Programs last compiled with VS COBOL II or any other compiler are also not
a problem.  What is a problem is illegal programs that for some reason have
not been failing, but the code generation was the same from VS COBOL II
through Enterprise COBOL V4.2, so they got the same behavior.  You
should have been in my SHARE session yesterday!

Some of the illegal/invalid programs we have seen that behave differently
with COBOL V5 compared to any previous compilers:
1) Mis-matched parameters:  Caller passes 100 bytes, callee uses 500 bytes
   and overwrites IBM control blocks
2) Over-used tables:  Table defined as OCCURS 0 to 1 TIMES DEPENDING ON X,
 then X is set to 250.
3) Spaces in numeric DISPLAY data items (zoned decimal)
4) Programs that assume a specific layout of WORKING-STORAGE and use data
across data item boundaries

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: Mixed COBOL ewnvironment and Ent. COBOL

[Tom Ross]

Tx Tom.

Is this (recompile) is sufficient for cobol ii under Cics 5.1?

ITschak

You do NOT have to recompile, you have to relink with REPLACE IGZEBST.
You could OPTIONALLY recompile with a newer compiler, which would use
a different bootstrap routine and eliminate the problem in a completely
different way.  We recommend relink with REPLACE, however, simply because
relink with REPLACE does not have to be re-tested, but recompiling does.

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

Mixed COBOL ewnvironment and Ent. COBOL

[Tom Ross]

We have a mixed COBOL environment involving VS COBOL 2 programs compiled
with RESident. We do not want to recompile tons of programs and considering
the option to relink the COBOL load modulwe to replace the stub module
(igzebst) with an updated one.

1) You do not have to recompile, but you do have to re-link to REPLACE IGZEBST

My questions are:
* will relinked COBOL programs be callable by COBOL 5 programs under CICS?
2) Yes
* Will these programs act the same as before the relink (same results)?
3) Yes
* what level of testing should we expect after the relink, if done?
4) None specifically for the VS COBOL II modules.  OTOH, when recompiling with
COBOL V5 we recommend a lot of testing, because it can reveal hidden invalid
COBOL programs.  These programs could have been invalid for 20 or 30 years,
but each new release generated the same instructions so hte behavior was
the same. With COBOL V5, these bad programs might start getting the wrong
answers.  So, for every program recompiled with COBOL V5 we recommend
thorough regression testing.

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: COBOL 4.2 support

[Tom Ross]

Multiple answers in one response...

One comment, check the IBMMAIN Archives for discussions on COBOL V5.  There=
 are many changes to the way this compiler runs.  For one thing, the output=
 files need to be PDS/E datasets for the compiler and Load libs. =20

Almost right.  The compiler outputs can all go into PDS, but the BINDER output,
the executable, is a Program Object and can only live in PDSE.

You cannot, as far as I know, copy a compiled COBOL V5 module to a PDS to r=
un.  It needs to be a PDS/E.

Well, you cannot copy a bound(link edited) COBOL V5 Program Object to a PDS :-)
The Object Module output of the compiler can be in PDS.

Also look at SHARE presentation by Tom Ross in August of 2014. And=20
session presentation 17610, User Experience.

Please don't!  That is way out of date now, no mention of the latest
migration-easing changes we have made.  Instead look at my migration
presentation from March, 2015:
16615: How to Take Advantage of the New COBOL V5 Compiler - Migration!

If you don't have access to SHARE content, this discussion has reminded
me to update the COBOL Resource page with my newer presentation.  I sent
the request to our web page people, it should be updated by next week:
http://www-01.ibm.com/support/docview.wss?uid=swg27039560

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

COBOL's NUMPROC compiler option

[Tom Ross]

Mr. Ross,

Is there going to be a corresponding PACKCHECK compiler option? It is=20

We have no plans for one, but we are very open to suggestions.  I have
wondered for years how a customer could actually migrate from NUMPROC(NOPFD)
to NUMPROC(PFD), and something like that would help.   Please submit an
RFE (Request for Enhancement) at
https://www.ibm.com/developerworks/rfe/?PROD_ID=698

very difficult to locate all of the assembler code that took liberty in=20
fixing positive pack decimal fields with a sign of F instead of=20
determining if the result field was signed or not.  After all everybody=20
would use a hardware internal decimal instruction (AP, CP, DP, MP, SP,=20
and ZAP etc.) to access/process a pack decimal field!  Who would have=20
ever guessed that one of the future compilers would be smart enough to=20
make a determination/assumption that you could just use a compare=20
logical character instruction (CLC) to determine equality between two=20
pack decimal fields?

Or even that we might avoid packed-decimal instructions completely for
processing packed-decimal data! (we use DFP instructions when more efficient)

Or, should we just take the performance hit and use NUMPROC(NOPFD) for=20
the life of COBOL?

NMost cusotmers use NUMPROC(NOPFD) and it is not much of a hit for most.

Maybe we could petition for the reinstatement of NUMPROC(MIG)

You could ask, and we would most likely say no.  NUMPROC(MIG) was
supposed to be a temporary solution for customers migrating from
OS/VS COBOL to VS COBOL II in the 1980s...

I guess we are all wondering just how much anguish=20
NUMPROC(MIG) is causing IBM? Because, it appears to be very beneficial=20
to some of us and less overhead than NUMPROC(NOPFD).  If I remember=20
correctly NUMPROC(MIG) only fixed signs on input and NUMPROC(NOPFD)=20
does additional sign fixing.

We have had only a handful of complaints, and several customers were
embarrassed to discover that they were using NUMPROC(MIG) and only
really thought about it when migrating to COBOL V5.  They say they are
going to go through the effort to migrate to NUMPROC(NOPFD).

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

COBOL's NUMPROC compiler option

[Tom Ross]

- What is on input as described under NOPFD?

  That is on input to a statement, before a statement starts operating on
  the data.

- Which allowed behavior of COBOL 5.2 is closer to MIG: NOPFD or PFD?

  It depends on what behavior you mean, but for preferred sign correction
  you need NNUMPROC(NOPFD).  If you have all preferred signs already, you
  can use NUMPROC(PFD).  We do not test invalid COBOL as in your example,
  so the behavior for us is rather unknown.

  We are coming out with a new option to help customers find if they have
  invalid zoned decimal (numeric DISPLAY) data, and that is a new compiler
  option called ZONECHECK.  It is similar to SSRANGE in that it tells the
  compiler to generate code to validate the data for every reference to
  numeric DISPLAY data items that are input to a statement. The method
  used is the NUMERIC Class Test.  This option could be used to determine
  if your zoned decimal data items are using valid signs on input.

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: COBOL's NUMPROC compiler option

[Tom Ross]

I read the APAR and Tom Ross's SHARE presentation and have the
following question.

05  FIELD-CSP  PIC S999 PACKED-DECIMAL.

If FIELD-CSP contains x'123f', for NUMPROC(PFD),ZD(MIG) will FIELD-CSP
be NUMERIC in an IF NUMERIC test?  So far as I can tell CSP and its
descendants will generate this data for signed packed decimal fields.

ZONEDATA only affects Zoned Decimal items, not Packed-decimal, thus the
attempt at making the compiler option name specific.

In any case, NUMPROC(PFD) says that 'F' will not be used as a sign for
signed fields, in zoned decimal (Numeric DISPLAY) and in packed-decimal,
so your example would be NOT NUMERIC.

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

Strange LE / link list behaviour

[Tom Ross]

We're in the process of upgrading to Enterprise COBOL 5.1 and one of our=20
development groups has decided to re-compile all their COBOL modules even=20
though it is not deemed necessary - that's their prerogative.=20


I think it is an excellent idea to recompile all of an application and test
it when moving to COBOL V5.  1) You get more performance benefit than only
recompiling changed programs and 2) you complete the migration for that
application and find any oddities in your code that might behave differently
in COBOL V5 than in earlier compilers.

One of their programs is exhibiting strange behaviour on the development=20
LPAR that I have been unable to replicate on our sandbox system.

If they code the LE libraries SCEERUN and SCEERUN2 in their JOBLIB=20
statement, their program runs OK.  However, if they allow the LE libraries=
to come from link list (as they should) their program abends with S0C4 -=20
the address of the offending instruction is way outside of the module=20
reported in the dump - probably a wild branch, I guess.

Has anyone encountered anything similar?  Why should coding LE libraries=20
in your JOBLIB (the same with STEPLIB, incidentally) cause a module to=20
work when it doesn't work from link list?

If the LE libraries pointed to by LNKLST are different from the ones pointed
to by STEPLIB/JOBLIB you could get this behavior.  Is it possible that the
required LE service for COBOL V5 is not installed on the SCEERUN that is
pointed to by LNKLST?

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

Compile COBOL Programs In 64 Bit.

[Tom Ross]

Hi,I am looking for COBOL compiler option to compile our COBOL programs in =
64 Bit mode.Please lead me if you have such a experience .The COBOL version=
 is 4.2 on Z9 with z/OS 1.12. Best regardsManshadi

AMODE 64 COBOL is still being worked on here at IBM.

I (like the other poster) would like to know what you would do with AMODE 64 
COBOL?
Also, does everyone realize that AMODE 64 code will run slower than AMODE 31 
code?
We assume that AMODE 64 COBOL will be used for very specialized one-off cases
to solve specific business problems, and that in general 99% of code will be
compiled for AMODE 31 even after we ship AMODE 64 COBOL.

  Unlike AMODE 31, which we expected EVERYONE to move to (still waiting :-) we
do not think very many users will need AMODE 64 in the next 10-15 years.
We are gathering use cases and verifiable needs for AMODE 64 COBOL, so if
you know of any, please SHARE!  (get it? :-)


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: 64bit

[Tom Ross]

Part of the reason for going to a new backend (code generator/optimizer)
in COBOL V5.1 was that the new backend already supports AMODE 64.  This is
another step in the direction of AMODE  64 COBOL.  The first steps were
to get infrastructure in LE, get AMODE 64 support for COBOL into plan for
CICS, DB2 and DFSORT, and make sure that all of the players are playin'!
AMODE 64 COBOL is already in our plans, but it is not going to be in V5.x.

Sorry, we are working on it, but we may be too late to help you Scott!

Cheers,
TomR   COBOL is the Language of the Future! 

Scott - I think that only enterprise cobol 5.x support 64 bit natively.

Sam

On Thu, Oct 16, 2014 at 7:17 AM, Scott Ford 
0006f84450fa-dmarc-requ...@listserv.ua.edu wrote:

 All,
 I have a generalized design question. First background will help. Our
 products run as Enterprise Cobol STC, no multi-tasking, yet. We call hlasm
 subroutines. I would like to use 64bit storage for some functions from
 Cobol. Is this feasible. I think it is, where I am unclear is the call and
 binder parameters. Do I have to do anything special parameter wise ?

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

Re: Enterprise COBOL v5.1 Implemented?

[Tom Ross]

As far as other glitches, I posted a message yesterday about the absence of=
 IGYOP messages, and specifically IGYOP3091-W.  In further experimenting, w=
e have discovered that it's not just that the message isn't being produced,=
 it's that the code that can never be executed is not being discarded as it=
 was in COBOL 4.2.  So, there's no message about it because the compiler is=
 no longer doing what it used to do.  We intend to open a PMR in the mornin=
g and see what response that yields.=20

COBOL V5 optimization definitely removes unreachable code, but it is so
different from the V4 optimizer that it may report differently.  In fact,
in the early days (of developing COBOL V5) we were getting messages for
deleted code at OPT(0), which we have since corrected (we no longer delete
code at OPT(0))

The COBOL V3/V4 optimizer did not always report unreachable code deletion,
but we are interested in cases where V4 flagged it and V5 does not, so
please open PMRs if you find such cases!

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: COBOL 5 compile options

[Tom Ross]

I feel a little like a Zoroastrian intruding into a discussion among
Thomist theologians about whether the archangels in moving from
Samarra to Novara pass through the intervening space, but the whole
notion of imposing decimal-picture constraints upon binary arithmetic
strikes me as absurd.

Welcome to absurd-COBOL!  The language was designed without regard to
hardware, only with regard to dollars and cents, integers and decimals
in base 10 arithmetic.  Mapping decinmal digits to binary data is
and was difficult!  How many decimal digits does a fullword hold?  :-)
Furthermore, the COBOL Standard requiresthat we support truncation
to the decimal picture string, so if a user codes PIC 9 BINARY, we
must produce a zero result for this math:

COMPUTE PIC9BIN = 9
COMPUTE PIC9BIN = PIC9BIN + 1

Now that it is available TRUNC(OPT) has everything to recommend it.
It is faster, more accurate, and yields results that are more
perspicuous to any but a diseased imagination.

If a user changes a compile option and gets different results, there
will be unhappy clients somewhere.  I learned early on that more
accurate results means lookout and test a lot before trying!

Any situation in which the twos-complement byte, halfword, and
fullword hardware bounds

-128 =3D y  +127
(-2^7 =3D y =3D +2^7 - 1)
(-2^15 - h =3D +2^15 - 1)
-32768 =3D h =3D +32767
-2147483648 =3D f =3D +2147483647
(-2^31 =3D f =3D +2^31 - 1)

are adjusted implicitly during and following arithmetic operations
results in the generation of more (sometimes much more) and sillier
code.(Explicit operations that use MAX, MIN, or both are available
for performing such operations where, exceptionally, they are
appropriate.)

Here is where it gets complicated.  We have 3 settings for TRUNC and I think
bone of them will make you happy :-)
TRUNC(STD) : Generate extra code to make sure results a truncated to PICTURE 
clause
TRUNC(OPT) : Generate the minimum amount of code without regard to PICTURE 
clause
TRUNC(BIN) : Generate extra code to use all bits of BINARY data even though 
binary r
 data does not map to decimal PICTURE clauses.

COBOL V5 gets the same results as earlier compilers, and there is no such thing 
as
a super efficient data type and compiler option combination that will fully 
exploit
binary data on z/OS.   For performance we recommend TRUNC(OPT), but in some 
cases
data can be lost, so not all users can use TRUNC(OPT).  Usually customer 
dicsussions
are between TRUNC(OPT) and TRUNC(BIN), TRUNC(STD) is rarely used.

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

\add 33

[Tom Ross]

I've been pondering the TRUNC option since yesterday.  Let me ask this ques=
tion...  Is the only time the TRUNC option come in to effect when one binar=
y field is moved to another, smaller, binary field?  Because it appears if =
a packed-decimal or zoned decimal field is moved in to a smaller binary fie=
ld the TRUNC(STD) logic is always performed.  Specifically, the sending fie=
ld is moved to a temp field, it is then truncated, and then converted to bi=
nary.  At least in the examples I've tried.

It affects MOVEs and math, like my example of what happens when I add 1 to 9
in a PIC 9 data item.  TRUNC(STD) gets zero, TRUNC(BIN gets 10, and I would

If that's the case I think I'll just stay with TRUNC(STD) since situations =
where TRUNC(OPT) would come in to play would be rare enough anyway that the=
re would be no noticeable gain, and too much to lose.  I can't think of man=
y cases where someone would move a large binary field to a smaller one an=
yway.

TRUNC(OPT) would speed up any math with BINARY data items tremendously, with
the risk of more accuracy in your math, IE: different results.  I think
the code for assignments (MOVEs) would not be affected too much.

Personally, I think picture defined COMP/BINARY fields should be eliminat=
ed in favor of the COBOL 2002 BINARY-SHORT (halfword), BINARY-LONG (fullwor=
d) and BINARY-DOUBLE (doubleword) data types, which make much more sense in=
 the real world anyway.  (of course eliminating the legacy data types is ne=
ver going to happen, because its too ingrained.)

We agree, it is on our (GIANT) TODO list for COBOL future items.

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: COBOL 5 compile options

[Tom Ross]

Thanks Tom!
For HGPR, don't you mean the reverse of what you said?  PRESERVE would alwa=
ys be save because COBOL preserves and restores the high-halves of the regi=
sters, right?  Safer, but not as efficient?

Ooops, at least I was 100% wrong :-)  Yes, PRESERVE is safer, although
NOPRESERVE might be safe for most as well.

As for NUMPROC, thanks for the info.  Seems to me the documentation could b=
e made clearer, though I don't know exactly all.  In the end I can't imagin=
e doing what you suggest, even though it's the only way to be sure.  So w=
e'll probably, unfortunately, just go with NOPFD.  But thanks a lot for the=
 info!!

Yes, I was aware that my idea was kind of crazy, and eve asked at SHARE if
anyone could ever do such a thing.  On the other hand, if you did not find out
if your data has preferred signed and chose PFD, you could get silent death ;-)

Question about one additional option.  We use TRUNC(STD) right now.  What w=
ould be have to be aware of if we wanted to switch to TRUNC(OPT) (where I a=
ssume OPT =3D optimize)?  Is OPT fully compliant with COBOL standard trun=
cation rules?

TRUNC(OPT) does not result in any code generated to truncate.  it is NOT
COBOL Standard conforming and neither is TRUNC(BIN).  You could get more
accurate results with TRUNC(OPT) (along with much better performance) but
I know that for many customers 'more accurate' = 'different' = BAD :-)

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

COBOL 5 compile options

[Tom Ross]

AFP:  I'm thinking we're safe chosing NOVOLATILE.  We don't even use floati=
ng-point, so perhaps it doesn't even matter what option we choose.

COBOLV 5 will use floating-point registers for fixed point math at higher
ARCH levels.  in some cases we convert DISPLAY numeric data item to DFP
(Decimal Floating Poiint) rather than packed decimal to do the math.
On the other hand, we think NOVOLATILE is mostly safe.

DISPSIGN:  I can't think of any harm in specifying SEP.  Certainly makes di=
splays of negative signed fields easier to read.

I agree, DISPLAY output is for humans

HGPR:  NOPRESERVE, since we're almost entirely COBOL calls COBOL, except =
for a few COBOL calls assembler routines.  Is there anything I should loo=
k at in the latter case to make sure NOPRESERVE doesn't cause any issues?

This one needs more research.  For example, EXEC SQL calls DB2, which could
thhen switch to AMODE 64 and change the regs.  On the other hand, I did a
service search and found a case where DB2 was fixed when it inadvertantly
changed the upper halves of some regs. We know for sure that NOPRESERVE is
safe, and PRESERVE should be safe, but we need more data!

Other than NUMPROC, discussed in my previous post, I think these are the on=
ly ones I'm concerned about.

In your NUMPROC discussion you compared signed to unsigned, but NUMPROC is more
about signed data to signed data.  If you get nonpreferred signs as input data
then you need to run with NUMPROC(NOPFD) to make sure you get correct results.
I gave a presentation at SHARE about one way to check if you can use
NUMPROC(PFD), please see my recent SHARE presentation, Coding for Performance.
The relevant parts are here:

NUMPROC(NOPFD)

- NUMPROC(PFD) is faster

Performance considerations using NUMPROC:
- On the average, NUMPROC(PFD) was 1% faster than NUMPROC(NOPFD), with a range
  of 21% faster to equivalent.

Investigate your signed data in External Decimal and Packed-decimal
- How can you do that?  It is not easy, but if you really want to:
  If NUMERIC with NUMPROC(PFD) will tell you if you need NOPFD

  1 Create a sniffer program from existing programs to access all of the data
  2 Use IF NUMERIC (CLASS TEST) for every data item in files and DBs
  3 If 100% NUMERIC, change to NUMPROC(PFD)!


* Compile sniffer with NUMPROC(PFD)
EXEC SQL SELECT Ext-Dec Packed-Dec
  INTO   :X,  :Y  END-EXEC

If X NUMERIC and Y NUMERIC Then
 Display Use NUMPROC(PFD)!
 Move 2 To Return-Code
Else
 Display Sorry, use NUMPROC(NOPFD)!
 Move 16 To Return-Code* Or call CEE3ABD
 Stop Run
End-If

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: IBM C and Cobol Threading question

[Tom Ross]

The distinction between COBOL's distinction of WORKING-STORAGE and
LOCAL-STORAGE is essentially the same as the PL/I and then C
distinction of static and automatic storage.

As far as I can judge from earlier posts in this thread the shared
facility is not a dynamic shared control block; it is a  read-only
table; and the serialization of accesses to such a table is required
only if it is replaced from time to time DURING the execution of the
multithreaded application.

Serialization is possible from, although not within, COBOL.  One
writes a pair of simple COBOL-callable assembly-language to do it; and
it is also possible and useful to write such a pair of subroutines to
LOAD and DELETE [load module or program object] tables.

There is some locking available in COBOL, for I/O.  If you have a file that
has one record, you could READ it from the thread that wants a 'lock' on
resources and then CLOSE the file when done.  COBOL uses Mutexes internally
to prevent multiple accesses to a file record when compiled with THREAD.
You are right though, there is no explicit Mutex technology accessible
directly with COBOL language.  We have not had a request for such a feature,
if anyone wants it...ask for it via the RFE site!

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

IBM C and Cobol Threading question

[Tom Ross]

I have written a C program using threads and have a question. I have an ext=
ernal message table that I need to be persistent between threads.  The mess=
age table is loaded from an external QSAM file. Program in Cobol loads the =
table. I want to be able to use the message table in other threads. Does an=
yone know is Working-Storage from one thread available to other threads ?=20

Yes!  In fact, all of your COBOL threads would be using a single copy of
WORKING-STORAGE, so if one of them wants to do something that does not affect
the others then the programs need LOCAL-STORAGE variables.  Normally with
multi-threading you would not use WORKING-STORAGE because of this.  In your
case, defining your table in WORKING-STORAGE and your other variables in
LOCAL-STORAGE would work great!

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

Enterprise COBOL v5.1 and RDz v9.x

[Tom Ross]

I learned via PMR that Rational Developer for System z (RDz)
.v9.x (latest  greatest) does not officially support
  Enterprise COBOL v5.1.

SNIPPAGE

Ooops, sorry about that too.  RDz development might not know that=20
we in COBOL are planning to add support to COBOL =E2=80=A6

SNIPPAGE
-

Perhaps IBM needs to get the different groups w/in IBM that use
the COBOL compiler to be a bit more connected to COBOL development?

We try...in fact, I was wrong about RDz, and misled you.  RDz supports
completely COBOL V5, including the choice of XML parsers to use.

A migration was proposed to translate (using an IBM utility) an=20
ISV=E2=80=99s code to COBOL (~NOV2013). The problem is, the group that=20
has the translation tool had NO idea about COBOL 5.1, and=20
apparently had no plans to make their tool COBOL 5.1 friendly (as=20
in, NOT using new reserved words and the like).

Can you tell me the IBM COBOL translation utility that was used?
I can try to fix this...I know about CCCA, but that one IS updated
for COBOL V5, I made sure of that.

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

Enterprise COBOL v5.1 and RDz v9.x

[Tom Ross]

I learned via PMR that Rational Developer for System z (RDz) v9.x (latest  
greatest) does not officially support
Enterprise COBOL v5.1.  The workaround suggested by RDz Support was to specify 
COBOL v4.2 and XMLPARSE(XMLSS) in the RDz
wizard, because COBOL v5.1 does not support XMLPARSE(COMPAT).  We did that, 
and the resulting program source generated by RDz
compiled clean with COBOL v5.1, but ABENDs when invoked in CICS.  The same 
source compiled with the COBOL v4.2 compiler
runs fine in CICS.

Sorry about that, COBOL V5 cannot be used to compile COBOL V4.2 programs that 
were using XMLPARSE(COMPAT).
For customers who want (or in this case need) to use the old parser, the 
workaround is to use the older
compilers.

At the suggestion of the IBMer handling the RDz PMR I've opened a Request for 
Enhancement (RFE) on Developerworks. You may
view the RFE at:

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfeCR_ID=50856

Ooops, sorry about that too.  RDz development might not know that we in COBOL 
are planning to
add support to COBOL V5 for the old COBOL XML parser (accessed via 
XMLPARSE(COMPAT) in V4R2)
Although RDz could possibly change their generated programs that use XML PARSE 
to be able to
use the XML System Services parser (accessed in COBOL V4R2 by XMLPARSE(XMLSS)) 
it might be that
what you really want is to keep using the older parser.  I think it is a good 
idea that RDz
give you a choice of parsers, and that COBOL V5 should too.  COBOL V5 is 
already working on
giving you that choice back, watch this space!

By the way, on the topic of RDz and COBOL V5, RDz V9 does support the new 
compilation
requirements of COBOL V5, and also recognizes the new keywords (reserved words) 
in
COBOL V5, which was not the case with RDz V8.5.  So, except for the XML PARSE 
code that
RDz can generate to help with Web Services, RDz does support COBOL V5.  That 
does not
help you with your specific situation, John, but I just wanted to counter some 
of the
over-reaching negative comments here.

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

Enterprise COBOL v5.1 and RDz v9.x

[Tom Ross]

I should have done more research before opening my mouth...RDz does in fact 
support
generating COBOL programs with XML PARSE in 2 different flavors.  You can 
specify
'generate for XMLPARSE(COMPAT)' or 'generate for XMLPARSE(XMLSS)'. Generating
for XMLPARSE(XMLSS) should have worked for COBOL V5.  If the programs worked
with COBOL V4.2 but not COBOL V5.1, could it be a CICS setup issue?

There are a couple of APARs about CICS setup and COBOL V5 programs:

APAR for CICS CSD updates required for COBOL V5:  APAR PM99301
http://www-01.ibm.com/support/docview.wss?uid=swg1PM99301

APAR for CICS DFHRPL updates required for COBOL V5 programs compiled with TEST: 
APAR PM96501
http://www-01.ibm.com/support/docview.wss?uid=swg1PM96501

If you have alreayd been running COBOL V5 programs with CICS, then you have 
already
done the proper CICS setup for COBOL V5, and it's back to the diagnosing 
board...

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: XMLSS performance vs COBOL 4.1 runtime XML

[Tom Ross]

Tom, =20

I have a question on your comment about offloading XML to specialty engines
.  To quote:


Also, offloading to specialty processors does not change total CPU usage,
and does not improve performance or throughput.  It could change
how much you pay to run it.


My standard engines are kneecapped at about half power.  Wouldn't offloading
the XML processing to a specialty engine allow the XML work to run at ful=
l speed, therefore improving both performance and throughput?

Interesting, I am not sure what 'kneecapped' is, but I suppose your engines
are slowed down by getting a discount on price or something?  When that
happens we don't do the same for the specialty processors?
Sorry if that is a dumb question :-)

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

XMLSS performance vs COBOL 4.1 runtime XML

[Tom Ross]

One of my co-workers is trying to improve the performance of an Enterprise =
4.1 program that decomposes an input XML file into record fields for proces=
sing by later programs.  The volume of the XML input has increased quite a =
bit and the performance may soon impact SLA's.

This program is currently compiled with XMLPARSE(COMPAT), so I advised him =
to try compiling a test version with XMLPARSE(XMLSS) and run some production
data through both versions a few times to get some average performance
numbers.

The COBOL Performance Tuning Paper could have helped you out here, it says:

| Performance considerations for XML PARSE example:
| Five programs using XML PARSE were from 20% to 108% slower when using
| XMLPARSE(XMLSS) compared to using XMLPARSE(COMPAT).


The XMLSS version seems to be running about 10% more CPU utilization and el=
apsed time than the production version, on average.

That's not bad!  In my personal tests, I got about 100% more CPU usage with
XMLSS compared to COMPAT.

Are there any tweaks or adjustments that can or should be made to the XMLSS=
 subsystem to improve performance?  Our environment is z/OS V1 R12, z196 ha=
rdware.

No, switch back to COMPAT.  The COMPAT parser is a minimum funcoitn parser,
and is missin a lot of function considered important by XML folks, like
NAMESPACE support, UTF-8 and UTF-16 support and many other features.  If you
do not need those features, then we recommend that you don't choose the
overhead of the XMLSS parser.

Also, offloading to specialty processors does not change total CPU usage,
and does not improve performance or throughput.  It could change
how how much you pay to run it.

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: Enterprise Cobol 5.1

[Tom Ross]

 -Original Message-
 From: IBM Mainframe Discussion List On Behalf Of Jousma, David
=20
 Both of your statements are correct.

Not only that, but you also need PTFs for four LE APARs and three Binder AP=
ARs.

But you can INSTALL COBOL 5.1 on z/OS 1.12 (according to the Program Direct=
ory).  Go figure

This confused me too, but it was explained to me that you can use z/OS 1.12
to install COBOL V5.1 on a z/OS 1.13 or later target system.  Something about
SMP/E that required that we support that, it was beyond me :-)

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

No subject

[Tom Ross]

With the change in Enterprise COBOL v5.1 to produce program objects inste=
ad of load modules, including the DWARF debug information and (optionally=
) source statements in non-loadable segments of the program object, we =
are curious how others handle the source statements:  Include them in the p=
rogram object (via compiler option TEST=3D(EJPD,SOURCE)), or maintain them =
in a separate dataset (via compiler option TEST=3D(EJPD,NOSOURCE), requirin=
g post-processing of the compiler listing with EQALANGX to produce the sour=
ce statement information)?  If the latter, how is the program object conne=
cted to its corresponding source listing?

Sorry for being late with this, but I have been travelling spreading the
good news (and even the not so good :-) about COBOL V5, and just got back
to my office.

I cannot answer what my customers are doing, but I can clarify something for
you.  Our intention is that with TEST(NOSOURCE) you would use the raw compiler
listing.  For COBOL V5 we are trying to avoid LANGX processing of listings.
To find the listings you would use the normal commands in Debug Tool or the
exit where you specify datasets to search.  And now, an ugly truth...it does
not work yet!  We are working on adding support for Debug Tool with 
TEST(NOSOURCE)
and hope to have it this year.  (TEST(NOSOURE) is only available in COBOL V5
so this is new function for Debug Tool)

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: Optimization and new data types for COBOL was Re: Optimization, CPU time, and related issues

[Tom Ross]

There is evidence that IBM's COBOL people are thinking hard about
making Mike Cowlishaw's ANSI-standard DFP available in COBOL.  They
may even have progressed further.  Tom can, however, speak for himself
and will, I suspect, do so.

Actually, we have it on our list of things that we will for sure do.
More interesting, I think, is that we use DFP instructions heavily ,
in COBOL V5 for all kinds of decimal arithmetic, with External Decimal
conversion and arithmetic on Packed-Decimal data.  This is more
interesting because lots of shops have External Decimal and Packed-Decimal
data, while almost NO shops have Decimal Floating Point data.  In fact,
many shops have hex floating-point data stored in databases today.
So, adding a DFP data type for COBOL would not really help anyone right
away.  To take advantage, users would have to write new code, create
new data (or convert old data) and build up DFP data that way.

Adding exploitation of DFP instructions to COBOL V5 means everyone can
take advantage of these wonderful instructions without changing any
data or source programs!

All you have to do is convert your PDS dataset COBOL load libraries to
PDSE dataset load libraries and then buy COBOL V5!

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: Users of CSP and its successor migrating to COBOL 5.1

[Tom Ross]

If other programs that handle files created by CSP (and maybe its
successors) were using NUMPROC(MIG) because it was more efficient than
NUMPROC(NOPFD), then those programs may have to be recompiled with
NUMPROC(NOPFD) because there can be problems.  I ran into that with a
program that for whatever reason did an IF NUMERIC test of a field
that had be affected by CSP and using NUMPROC(PFD) with that program
caused the field to test not numeric.  Recompiling the program in
question with NUMPROC(MIG) solved the problem.  The problem is not the
compiler options used for the COBOL generation of CSP programs, the
problem is the compiler options of the programs that use the output
from CSP programs.

That was an error, the correct solution would have been NUMPROC(NOPFD).
It is just a coincidence that NUMPROC(MIG) solved the problem.  If
preferred signs are not enforced, you use NUMPROC(NOPFD).  If preferred
signs are always enforced, then you can use NUMPROC(PFD).  If you are
migrating from OS/VS COBOL, and mixing OS/VS COBOL with newer COBOL,
then you might have used NUMPROC(MIG).

Why was NUMPROC(MIG) eliminated?

We don't support mixing OS/VS COBOL with Enterprise COBOL V5, so
it is no longer relevant.

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

Users of CSP and its successor migrating to COBOL 5.1

[Tom Ross]

If your shop uses an IBM z series computer and it is looking to
upgrade to version 5.1 of Enterprise COBOL and it is using Cross
System Product (CSP) or its Visual Gen successor, migration may be a
problem.  CSP and possibly its successor forced an F zone on all
signed fields with positive values leaving the D zone for negative
fields.  The elimination of NUMPROC(MIG) means this behavior if still
existing can cause problems.

In fact, there is nothing to worry  about, please check before
raising unnecessary worries.

Enterprise COBOL V5 has exactly the same sign behavior as COBOL V4
for CSP, VA Gen and EGL COBOL programs.
In particular, CSP (and EGL COBOL) require NUMPROC(NOPFD), from the
EGL COBOL help at:
http://pic.dhe.ibm.com/infocenter/rbdhelp/v8r5m0/index.jsp?topic=%2Fcom
.ibm.egl.gg.doc%2Ftopics%2Fgegl_cobol_modifybuildscriptszos.html

Required options for COBOL compiler for z/OS
The following options are required for the z/OS COBOL compiler
and are included in the FDABCL, FDABPTCL, FDABTCL, FDACL, FDAPCL,
FDAPTCL, and FDATCL build scripts:

LIB
NODYNAM (as further described later)
NUMPROC(NOPFD)
NOSEQ
QUOTE
RENT
TRUNC(BIN)  (requirement removed in later fixpacks)

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

Enterprise COBOL V5, Program Objects, PDSE datasets

[Tom Ross]

Greetings!

  All of these discussions of the new requirement that COBOL load libraries
be in PDSE datasets has been interesting.  It made me realize that I was not
clear on the whole story, we started out with the PO and PDSE assumption and
went from there, from my perspective.  Now that we have heard that this PDSE
shift could be a hardship or inconvenience for some clients, I decided to
investigate:
1) Would it be possible for us to back up and produce Load Modules from COBOL 
V5?
2) What is it about COBOL V5 objects that makes the Binder produce Program 
Objects?

So..I have some answers...

A1) We would have to redesign the COBOL V5 product significantly, and we would 
lose
   several of the performance improvement that we have made.  In addition, we 
would
   just be putting it off, because AMODE 64 COBOL will require Program Objects
   anyway, as well as many future performance improvements that would take 
advantage
   of System z features.  So, not possible (or wise)
A2) From some slides I will be giving to customers interested in COBOL V5 from 
now on:
  The Binder solves existing problems using new features
   - Example: when customers reached 16M text size limit of load module, our 
answer was
 always:  Re-engineer programs to be smaller, re-design
 This answer was expensive and not well received!

   - A program object can have a text size of up to 1 gigabyte

  COBOL V5 uses the following performance improving features that Binder will 
always
   put into Program Objects:
   - COBOL V5 can take advantage of larger object size by having more constants 
for
 improved MOVE and INITIALIZE performance
   - QY-con requires PO
That's a performance improvement for RXY (long displacement) 
instructions.
   - Condition-sequential RLD support requires PO
 Performance improvement for bootstrap invocation
   - PO can get page mapped 4K at a time for better performance

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

You've got to be kidding me! (Enterprise COBOL V5.1 DD overrides)

[Tom Ross]

For Enterprise COBOL v4.1 and 4.2, if you are loading the compiler from an
assembler program and want to override SYSOPTF or DBRMLIB, they are entries
20 and 21 respectively in the Alternative DD name list.

For Enterprise COBOL v5.1, if you want to override SYSOPTF or DBRMLIB, they
are reversed at entries 21 and 20 respectively in the Alternative DD name
list.

You have found a bug in the Enterprise COBOL V4 Programming Guide, sorry
about that!  We have never changed DBRMLIB from position 20, nor SYSOPTF
from position 21, but we did have the order wrong in the V4 books.
(We added SYSOPTF after DBRMLIB, so it was always after in the list)

I went back further, and found another problem with the alternative
DDNAME list in the V3R4 Programming Guide, it was missing DBRMLIB even
though the code was there in the product.

The good news is that the Enterprise COBOL V5 Programming Guide has the
alternative DDNAME list right, and the order is the same (with the
exception of V5 making SYSDEBUG 'not applicable') as COBOL V4.

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

COBOL 5.1 Share presentations

[Tom Ross]

Tom,

Could you share the SHARE presentations you have given on COBOL V5?

 I just sent them over, they should be live soon at:
 http://www-01.ibm.com/support/docview.wss?uid=3Dswg21634215

'Soon' meaning that more than a week later these presentations are still no=
t there.

Our web people took some days off, then I asked them to change some things
about these new pages, they have to go through a processsigh.
Anyway, they just went live today!

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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc

[Tom Ross]

Tom,

Why convert to PDSE? I am curious? A stated IBM direction?

Converting to PDSE just makes it easier to use or move to COBOL V5.1.
PDSE is far better than PDS, lots of advantages, so you could view it
as IBM direction, but for COBOL, that is the only thing we can do.

In COBOL V5.1, we always generate parts of the object program with loadable
user classes, which are only supported by Program Objects.  Load Modules
only support class B_TEXT or B_PRV in object programs.

As Frank Swarbick suggested, it might be an option to use new PDSE Load
Libraries for newer code and add the new libraries to concatenations.
That would provide a one module at a time migration path, but it also might
add too much complexity to application build and maintenance.  The good people
here on IBMMAIN would know much better than I would.  Is that a reasonable
option, to just start using PDSEs from one day in the future for any programs
recompiled with COBOL V5.1?

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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc

[Tom Ross]

Tom,

Could you share the SHARE presentations you have given on COBOL V5?

Yes, thanks for the reminder!  One of my TODOs has been to get our Web
people to add my 2 COBOL V5 presentaitons to our resources page.
I just sent them over, they should be live soon at:
http://www-01.ibm.com/support/docview.wss?uid=swg21634215

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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc

[Tom Ross]

In vnetibm.20130907162208.9...@bldgate.vnet.ibm.com, on 09/07/2013
   at 09:22 AM, Tom Ross tmr...@stlvm20.vnet.ibm.com said:

No, the COBOL Migration Guide is correct, all COBOL programs=20
produce GOFF output with COBOL V5, so after Binding you will have=20
a program object and it must reside in a PDSE.

It's not the use of GOFF per se that requires program objects, it's
the use of GOFF features that aren't supported in load modules.

Sorry about that, you are correct.  Though GOFF is new for COBOL V5.1,
it is not the reason why the executables must be program objects and
must be in PDSEs.  I must admit I was more focused on getting people
ready for COBOL V5.1, and there are really 2 things that shops can
do to prepare for COBOL V5.1 without getting the product, and I have
been SHAREing this information for years now:

1) Convert load libraries to PDSE if not already there

2) Expand the max region size for users who will be doing compiles
  with COBOL V5.1 (they will need 200M).  Shops with PL/I or
  Fault Analyzer may have done this already, but other shops may
  not allow enough region size to do compiles with COBOL V5.1

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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc

[Tom Ross]

On Sat, 7 Sep 2013 21:52:07 -0400, John Gilmore wrote:

Qua sysprog, I am sure thjat you are aware that PDSEs are problematic
early in an IPL process; but none of these problems obtains for COBOL
APs.

Very late to this, so sorry if my concerns have been answered  earlier.
What about shops with a ring of monoplexes ?. The sysplex scope is each ind=
ividual monoplex - but the sharing boundary is the larger GRSplex. Latch co=
ntention - particularly PDSE latches - are a PITA.

Never too late!  I need to know these answers too.  Some of my customers say
PDSE is not a problem, others are quite concerned, like you.  I did a quick 
search
and found this: www-01.ibm.com/support/docview.wss?uid=tss1prs4280aid=1?
Where it says:

PDSE sharing parameters are defined in the IGDSMSxx member of
SYS1.PARMLIB. You can choose a NORMAL or EXTENDED sharing option.
EXTENDED provides for sharing at the member level across a sysplex, where
NORMAL provides for sharing at the PDSE data set level across a sysplex. The
DSNTYPE(LIBRARY) parameter will default to a PDSE definition when a library is
allocated with DSORG=PO or directory block allocation request is made in the
SPACE parameter.

It also says not to share PDSEs outside of GRSplex, but this seems like it
woudl work for you, since the GRSplex is your sharing boundary.  It sounds
like you can do the kind of sharing you need to with PDSEslet me know!

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: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc

[Tom Ross]

If I am reading this correctly, the BINDER would need to use a PDSE output
file if there is JAVA, C/C++ type of programs.  If you have native cobol,
then you might be able to continue the LKED with BINDER to a non PDSE.

No, the COBOL Migration Guide is correct, all COBOL programs produce GOFF
output with COBOL V5, so after Binding you will have a program object and
it must reside in a PDSE.  I thought it was pretty clear myself, any
suggestions for how we could have made it clearer?

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

Enterprise COBOL execution POSIX(ON) LE parm.

[Tom Ross]

I have compiled some C code from the Internet (sqlite) which uses UNIX
mutex functions for multithreading. I know that COBOL doesn't really
support multithreading, but this is a generic library which does.

COBOL does really suppport multithreading, but you need to use the
THREAD compiler option to get that support.

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: COBOL Parser

[Tom Ross]

Since you are working on performance, have you tried compiling with the
Enterprise COBOL V4.2 compiler?  New compilers will generate code that
uses instruction sets on new CPUs. You may get some benefit that way.

Enterprise COBOL V4.2 code can run on old hardware such as the 9672,
we did not start exploiting newer hardware until COBOL V5.1.  And this
is a good thing and a bad thing, for the first time ever you could have
a supported z/OS on old hardware and not be able to run COBOL programs
that you just compiled with COBOL V5.  Earlier releases had the same
hardware requirements as the z/OS level we required. In particular,
if you have z/OS V1R13 running on 9672, there is no way to compile
with COBOL V5 to get a program that will run on that system.


On the topic of evaluation of conditions, in z/OS COBOL our generated
code will leave a condition evaluation as soon as we know it is true or
false.  We do not keep evaluating other operands if the final result is
clear from earlier ones.

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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers

[Tom Ross]

 It has taken us a while, but we now have a modern backend (code generator
 and optimizer) for COBOL that can exploit the latest hardware, and will
 support DFP, AMODE 64 and many of the other z/OS system features that we
 have not be able to exploit in the past.

Is that new backend bespoke for COBOL or is it shared with PL/1, C/C++, =20
Java?

Java used it first, now COBOL will be using it.  Next up, PL/I, I think, and
then C/C++.  Eventually all of the active compilers will use the same
backend so that when new hardware comes out we can exploit it with all langs
quickly!

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: Reading PDS/PDSE members from within COBOL in a loop

[Tom Ross]

Paul Gilmartin wrote:

(but does COBOL support DYNALLOC?)=20

Yes, behind the scenes. Search the IBM-MAIN Archives for details.=20

Of course some RTFM is needed to get it working.

Oh, look also for magic word: BPXWDYN.

I would recommend using the built-in support for dynamic file allocation
in COBOL, and avoid calling BPX* services directly.  We did a lot of work
to make it easier to do dynamic allocation with COBOL than with the BPX*
runtime services.  It is all documented in the COBOL Programing Guide,
look for 'Dynamically creating QSAM files' and then 'environment variable'.
(You can also do it with VSAM and Line Sequential Files, but I assumed
QSAM for working with PDS and PDSE, that's what we use)

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