>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 exp
>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 GOT
>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! <<
>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
>NOINITCH
>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 t
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! <<
---
>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 wa
>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
>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 see
>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
>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
>a
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 questi
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
>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. crea
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
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 co
>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 mod
><*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 point
>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! <<
---
>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
>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 reference
>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
>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
>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 an
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 execut
>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
>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 questi
>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! O
aptain COBOL, Tom Ross
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 h
>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
ar-field-character pic x occurs 1 to 1000 times depending on
>var-field-length.
>When a MOVE is performed to or from VAR-FIELD the length from VAR-FIELD-LEN
>GTH is used.
And now COBOL on z/OS has dynamic-length data items!
1 DL-A PIC X DYNAMIC VA
>I seem to remember something said about an extension to packed=20
>decimal and new instructions. I've been looking at a recent=20
>z/Arch PoOP in pdf (IBM web site), and I can't seem to find what=20
>I hazily remember from a few years ago.=C2=A0 Perhaps it is in a=20
>different publication.
>
.Cou
I am interested to know (from non-IBM people) if you know of any z/OS
application developers who use VS Code to edit z/OS COBOL source code?
Thank you!
TomR >> COBOL is the Language of the Future! <<
--
For IBM-MAIN
>All true Tom, but as far as I understand it the Vector Decimal instructions=
> still do not provide any more digits of precision than the older, non-vect=
>or ones. I believe the OP was asking about more digits of precision, not b=
>etter CPU usage. COBOL's ARITH(EXTEND) option still provides on
>Are there disadvantages to ARITH(EXTEND)? Is the only reason to want interm=
>ediate results to be compatible with older code is if you need to match pre=
>vious less-accurate results? Is there a performance impact at ARCH(11) or l=
>ower? -Original
>
>Are there disadvantages to ARITH(EXTEND)?
Hi,
>We are planning to switch from COBOL V4 to V6.4 in due time.
>We have found that the INVDATA option of COBOL V6.4 mimics the V4 behaviour=
> and plan to use it when 6.4 compiled modules throw error when invalid data=
> is present.
>One such test was to check the 0 length and negative length
>I hate to do it, but for the case of the current set of compilers, RTFM ple=
>ase. The C, COBOL V6 and PL/I Programmers Guide manual for each language c=
>learly show the 64-bit support is there (LP32/LP64). I haven=E2=80=99t dea=
>lt with Fortran since Fortran II on an IBM 1620 in college, so I
>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' fo
>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:
>> 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 AMERI
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
>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
>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
>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 COB
>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 docume
>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 CO
>> 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
>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! <<
-
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 c
> COBOL 6.1 introduced a "feature" where VALUE clauses that are used for
> initialization are flagged as errors.
This is not true. If an ILLEGAL VALUE clause is specified in the LINKAGE
section, it always got a WARNING in older compilers that VALUE in LINKAGE
has no effect. Now with V6, an ILLEG
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 e
>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
>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 alrea
>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
>optimizatio
>>
>>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 mee
>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 switc
>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 hav
)? (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
>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 C
>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 val
>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 wha
>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 s
>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
>> -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
>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 th
>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 en
>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 XMLPARS
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.
>>>I learned via PMR that Rational Developer for System z ("RDz")
>>>.v9.x ("latest & greatest") does not "officially" support
>>> >Enterprise COBOL v5.1.
>
>>
>>
>>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
>>
>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 threa
>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 i
>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
(Decim
>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 mi
>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.
>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
>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 disc
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,
>I notice that the language most used on the z, COBOL has NO
>improvements related to the EC12. There are improvements for PL/1 and
>C/C++. This speaks louder than anything else as to whether IBM thinks
>COBOL is on its deathbed.
What it really says is that IBM is very busy re-working COBOL to a
>Mike Schwab wrote:
>
>>I am thinking they are missing the old run time libraries.
>
>It is a good possibility. BTGTT, of course, my programmers are not really
>happy with that possibility. :-)
All COBOL library routines are included in LE, so that is NOT a possibility.
What I do see in client sho
>I don't know of any examples but I should imagine it's as simple of=20
>starting POSIX C stub threads that call COBOL programs. If you want to=20
>use shared data structures and use
>mutexes or condvars in the COBOL programs then you will have to either=20
>create COBOL records to map the DSECTS o
>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
o
>In , on 09/07/2013
> at 09:22 AM, Tom Ross 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 us
>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 sho
>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 alwa
>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/doc
>If you set up new PDS/E program libraries for only V5 program code, then
>any time maintenance on a COBOL program is done the maintainer must be
>aware whether this is the first time this program has compiled with V5
>and if so, be sure any related production JCL gets changed to reference
>the new
>>>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
>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 rever
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 h
>We've installed Enterprise COBOL 5 in z/OS 2.1 and I'm experimenting with=20
>the NOTEST(DWARF) COBOL option.
>When I Bind the program, I see, for example:
>MODULE SIZE (HEX) 00072C24=20
>DASD SIZE (HEX) 0014A000=20
>And I have no idea what that means.=20
>Has anyone been down this path? An
>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
>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
>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 t
>- 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 NNUMPR
>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 s
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 h
>I realize that this is belated but yes I would vigorously dispute him.
>Mike Cowlishaw of Rexx renown worked diligently on defining decimal
>floating point and the standard for it. The z series has had decimal
>floating point for a number of years. It has been supported in PL1,
>C/C++ and Java.
>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 alloc
>> 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 besp
1 - 100 of 122 matches
Mail list logo
