>Yes, of course, that's how we do it today, using a include file (or COPY=20
>BOOK, as it's called at other places),
>but it would be much nicer, if it could be defined as PIC S9(x) COMP-3=20
>UNSIGNED,
Hmm, if you don't want a sign, why have an 'S' in the PICTURE clause?
Signed:
05 SIGNED-ITEM
>On Sun, 3 Nov 2024 14:59:20 -0600, Paul Gilmartin wr=
>ote:
>
>>It would be a disservice to customers to retire 24-bit support berore
>>all IBM programming interfaces support AMODE 31.
>
>Do *any* of the modern compilers (C, COBOL, PL/I) "support 24-bit addressin=
>g"? What would that mean, exact
>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
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
>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)?
>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
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
>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
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
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
>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
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
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
>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
>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
>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
>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
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
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
>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
>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
>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
>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
>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
>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
>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! <<
---
><*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
>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
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
>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
>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
>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
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
>> 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
>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:
>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
>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
>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! <<
>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
>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
>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
>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
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! <<
---
>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
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
>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! <<
-
>> 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
>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
>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
>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).
>Ye
>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,
>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
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).
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 opt
>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
>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
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
> 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
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
>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
>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
>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
)? (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
>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
>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
>>
>>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
>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
>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
f
>My concern is that IBM will announce EOS for Enterprise Cobol 4.2 and we wi=
>ll not be ready.
We have sold hundreds of licenses of COBOL V5, and COBOL v6 is starting to go
fast as well. We have many customers who report more than 10,000 COBOL
programs compiled with COBOL V5 in production today.
> 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 i
>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 Cob
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
>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
>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 inv
>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
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
>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
>- 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
>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
>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
>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'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
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,
>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
>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
>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.
>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
>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
>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
>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
>>>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 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. 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
>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
>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
>> -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
>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
>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
>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
>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
1 - 100 of 122 matches
Mail list logo
