: requiring) a z/OS UNIX
file, not a PDS.
I'm copying this over to ibm-main, too, as Tom Ross occasionally
follows that group so maybe he will chime in with some info.
Well, I actually ALWAYS follow this group, but via digest, so by
the time I see the COBOL questions someone on IBMMAIN has already
given
According to Tom Ross (of IBM COBOL development) at SHARE last year, they are
working
on migrating the back end to the same one that PL/I uses. (And I am
assuming the same
one some of the other languages also use.)
No idea if that would fix COBOL arithmetic.
Frank
Frank,
That is close
IGYCRCTL is the executable load module that is the Resident Control phase
(main program) of the COBOL compiler.
Now my turn...how does this information help you?
Satisfaction of his curiosity? :) I too was interested to see the derivation
of the name.
Personally, any time I see IGYCRCTL I
Apology in advance for posting a very basic or a stupid question but I am
curious to know about the COBOL compiler Programes : IGYWCL and IGYCRCTL. I
very well know that IGY stands for the language Prefix but Would like
know what WCL or CRCTL stands for ? I tried Google to find some Basic
History
We are (finally) looking at the possibilities of moving up on COBOL from OS/VS
with Report Writer and from COBOL II to the new COBOL 4.2 with Report Writer.
I would like to hear from folks who have already made that journey, especially
about any specific things that went well - or didn't.
I'm
I am looking for a decompiler, reverse compiler, dissasembler of cobol LOAD
modules into cobol SOURCE modules for lost programs. Could any please
direct me to some Site or Freebies or specific Products which Can perform
the reverse compilation.
There is no tool or free way to do this. You can
SCEELKED contains SETENV and PUTENV.
'setenv' may be in SCEELKED, but that does not help the dynamic call case,
where the call would be resolved at runtime, not link time.
You cannot call lower case names dynamically from COBOL at this time.
The dynamic call routine 'normalizes' all names,
SCEELKED contains SETENV and PUTENV.
'setenv' may be in SCEELKED, but that does not help the dynamic call case,
where the call would be resolved at runtime, not link time.
You cannot call lower case names dynamically from COBOL at this time.
The dynamic call routine 'normalizes' all names,
Our ISV product displays message descriptions under ISPF on z/OS. I want to
determine the correct COBOL release level installed so that our product can
automatically display the correct COBOL compiler and runtime message
descriptions for that system. We do this automatic release level detection
Is there some magic to make LE dump the full 64 bit general registers
when CALL'ing CEE3DMP from an Enterprise COBOL 3.2 program? Yes, I know
COBOL doesn't use the high fullword of the regs. Something, somewhere,
is changing the high word of some regs which is causing DFSORT to abend
when the
I THINK that some LE runtime components are COBOL specific and may be extra
cost.
This is false, 100% of the IBM LE runtime for COBOL (Enterprise COBOL for z/OS)
is
included with z/OS.
Having said that, there are extra products you can buy like Report Writer and
EGL that work with COBOL and
IS there some other quick fix we can do
without requiring a recompile of all modules with NOTEST?
If you do recompile, use TEST(NOHOOK,SEPARATE) and you can have
all of the benefits of TEST(NOSEPARATE) (formatted dumps,
ability to debug with Debug Tool) without the large load
modules. The
Consistency of result has a lot to be said for it as does meeting
customer expectation. I don't want my checking account handled in
either binary or floating point.
Many financial institutions do not allow the use of any floating-point
data, they use only fixed-point data, often using the
You are confused again...we have always had messages and codes for COBOL
run-time messages,
With real explanations, or with the claim that they are self documenting?
With explanations for the intended audience, system programmers.
For the compiler messages, we felt that was for a different
Rick of course you are quite correct. The newer portions of Z/os like OE and
TCP/IP/COBOL are horrendously documented.
How long ago did you last check, Ed, when you were working on IBM Mainframes 5
years ago? :-)
Yes I know the COBOL finally put out a MC but IBM's denial for so long that
it
instructions?
BUT the resulting reduction in customer CPU utilization would
cannibalize the additional hardware sales that would have been made when
customer work volume increases, making the hardware side of the house
*very* unhappy...
Reducing customer CPU utilization likely loses IBM more
1) XMLPARSE(XMLSS) is not compatible with XMLSS(COMPAT), as described in the
COBOL Migration GUide. They are 2 completely different parsers! The changes
are minor, but must be looked at when migrating from XMLPARSE(COMPAT) to
XMLPARSE(XMLSS).
Cheers,
TomR COBOL is the Language
XMLSS actually broke one of our application's programs. They had to
re-compile to change it to COMPAT for that program to make the
application work properly. Also, in COBOL 3.4, we used to specify
TEST=(NONE,NOSYM). There is no equivalent in 4.1 other than to specify
TEST=NO. Anything else,
This is just an initial concept question.
In general, what mechanism could;
*;a batch job, most likely an Enterprise COBOL batch program,=20
*;connect with a web service and request information from some=20
application the web service connects with outside of the mainframe world
*;receive a
This is an abend in a CX* module, that is not the IBM COBOL compiler. In
addition,
the COBOL compiler does not run in LE, so it it strange that you got a CEE*
message from
a CA? module. The COBOL compiler would be assembler modules starting with IGY*.
CEE3201S The system detected an operation
In one sense as someone who is sem-retired, I have no vested interest
other than as someone who believes that COBOL still MAY have a future.
My belief is that in order for that future to exist, COBOL programs or
routines have to be able to exist in a 64 bit Websphere address space,
communicate
On the other hand,
we know that we need to do AMODE 64 COBOL someday, but not one customer
has asked IBM COBOL development to do it yet.
I find that difficult to believe. Perhaps the validity of your assertion
depends on one's definition of the word asked.
True! My definitions...
Meanwhile, COBOL customers are beating us up about XML validation,
XMLSS, Unicode, useability features and many other things besides
AMODE 64 COBOL. We have to do it all right?
Why does COBOL need XML handling? Is it generating in line code as
opposed to setting up calls as is the case for CICS
IBM intends to keep extending z/SO COBOL for many years to come!
We have been exploring what it would take to get AMODE 64 COBOL
on z/OS for years. Coordination between all of the products is in
progress. We could ship a compiler that could produce AMODE 64
object code in just a few years (it
for zcobol initial release at SHARE. It doesn't test things like EXEC CICS or
Enterprise COBOL extensions such as EXTENDED-FLOAT, but it sure looks like
There is no EXTENDED-FLOAT in Enterprise COBOL.
There are floating-point data types, COMP-1, COMP-2, and external
floating-point. There is a
The LE conversion guide show you how to rebind the programs without
recompilation. In essence, map the program, code REPLACE statements for
all of the runtime CSECTs, and rebind using the LE link library.
There is no need to code the REPLACE statements, just use the sample
linkage editor control
IMHO, the only reasonable excuse for keeping OS/VS Cobol around is not
having the source code to recompile.
Unfortunately, that is a common problem.
Although it was solved years ago by Source Recovery Company. They are
still taking OS/VS COBOL (and other modules) and returning COBOL source
code
On Thu, 2 Oct 2008 12:35:16 -0500, John P Kalinich wrote:
Mark Yuhas of the IBM Mainframe Discussion List
wrote on 10/02/2008 12:27:32 PM:
Has IBM announced what release of LE will not support old COBOL runtime
environments, specifically OS/VS COBOL and VS COBOL II?
LE is a runtime
I forgot to add...
Even if you think 40M (or however big the pre-built image is now) is huge,
remember that by default under z/OS 1.8 and above all tables are loaded
in non-page fixed storage by default (you can page fix them if desired).
This doesn't apply to z/OS 1.7 though AFAIK.
Does
Why are you not using the LE runtime?
Not my code, not my app. As I said in the original note, The program
object detecting the error was last compiled in 1999 with VS COBOL II
[...]. At that time, apparently the SYSLIB for the program binder step in
the change management system was set up to
On 17 Jun 2008 11:29:21 -0700, in bit.listserv.ibm-main you wrote:
With reference modification available, the only things that are
awkward in COBOL are bit switches and the 1 byte binary fields. I
have written usage programs that parse the SMF 14/15, 30 and 64
records. If IBM would just
With reference modification available, the only things that are
awkward in COBOL are bit switches and the 1 byte binary fields. I
have written usage programs that parse the SMF 14/15, 30 and 64
records. If IBM would just implement the data types in the 2002
standard including the new floating
Hmmm, I find it interesting that I have two votes for IBMs Debug Tool, which
is completely unusable to me. We write C++ programs here. My main app is
something like 200 object modules.
When I write a Hello world test app, fire it up under IBMs debug tool, it
works great. When I try to debug our
(I believe this was a major factor in the demise of COBOL;
I just cannot resist responding to this (sorry I am so late, I was out of the
office for 2 weeks).
I work on the IBM COBOL compiler, and if you could see the amount of interest,
the number of compiler licenses, the sheer number of COBOL
Rob Schramm asks:
I haven't looked this up... but is the license for the IBM Metal C mor=
e
attractive to the customers that may have balked at the IBM C/C++
compiler?
Since the topic is COBOL calling COBOL to invoke a Java method,
C and C++ are not needed and are irrelevant to the question.
It
I think you have a bug in your call to CEEENV. You have:
call 'ceeenv' using update-req, six, file-name,
val-length, val-ptr, fc
call 'ceeenv' using update-req, six, file-name,
val-length, env-val, fc
John,
Steve is right, his example is correct and yours is not.
Perhaps I should have said something more along the lines of If I want
to exploit a zAAP processor with my own code, that code must be written
in Java. Perhaps also with a note that my code might run IBM (or other
vendor?) supplied code which might run on a zAAP (like XML is going to).
But there
On Thu, 18 Oct 2007 09:43:51 -0400, in bit.listserv.ibm-main you
wrote:
I need to read source code from a PDS member whose name I don't know until my
program runs, much the same as the COBOL
compiler handles COPY memname statements. Is dynalloc the only way to go
about it or does zOS provide a
Tom,
Well I hate the missing line number for DB2 msgs while using the integrated
compiler.
This is a pain. Sample
IGYDS0208-I DSNH4760I The DB2 SQL Coprocessor is using the level 2
interface under DB2 V8
IGYDS0210-S DSNH332I CHARACTER CONVERSION FROM CCSID 1140 TO CCSID
Hmmm.. check the messages and code for COBOL ... oh wait their isn't
one... call IBM.
Ed
There IS a mesages and codes for RUNNING COBOL programs, if you bothered
to check. (Of course, this is not a COBOL issue, it is a 'calling EZSOKET'
issue.) Any programmer knows that if he/she gets a
Can someone tell me, where exactly the DATE is taken from when a
COBOL program executes ACCEPT DATE?
Is it
(a) the running system clock, local time, as of the moment ACCEPT
DATE is executed?
- or -
(b) the date in effect at the moment the program (or step) started?
It is (A) for all COBOL
Hi All. I need to put together a document that IBM is taking the
mainframe seriously and is actively trying to get it taught in our
schools. Would anyone have any good articles available for my use?
Thanks all.
You ask 2 different questions, so here are 2 different answers that might
help you.
The COBOL example does not extend beyond those compiler writers as far as I
have seen. And I, for one, would not paint the entire COBOL team with that
broad brush. Tom Ross (although I think he's moved on to other things) was
a strong customer advocate - still is (although I have forgotten where
I have an ASM main task that establishes an ESTAE.
It then calls a COBOL subroutine (establishing an estae trap(on,nospie))
where it abends with an 0C4/11
You cannot have your ESTAE in effect when running in LE code. LE requires
its own ESTAE to be in effect. Form my SHARE presentation at
These must been programs written for OS/VS COBOL and not converted
using the IBM conversion tool. The old way was to use COMP (binary
numeric) fields to store addresses. If the programs were converted to
VS COBOL II or later with CCCA (any maybe non-IBM competitors like
MHTRAN or CA-Migrate)
I'm sure this is technologically feasible, my question is now that most of
us have LE enabled as part of our systems, we no longer license the COBOL
run-times, therefore is it legal to do it this way?
If you are paying for z/OS, you ARE paying for a license for the COBOL
run-time library, which
)
and then you can start using the new compiler. Note that COB2LIB is not
supported at all, even behind LE in LNKLST. If you want to create a
real mess, start using STEPLIB for each program that gets recompiled
from VS COBOL II to Enterprise COBOL!!
Cheers,
Tom Ross COBOL is the Language
47 matches
Mail list logo
