Re: C++ reinterpret_cast question
Also, I trust that you know what you're doing! Depending on the
implementation of C++, a pointer to a function can sometimes be a pointer to a
function descriptor. So be careful with what you do with opts_char. (But you
say that the resulting code basically works so that is good.)
Also, on USS
ahk> cat cm.C
extern "OS" typedef int mytype(void *);
extern mytype M;
void p()
{
char *x;
x = reinterpret_cast(M);
}
ahk> xlC -c cm.C
"./cm.C", line 8.33: CCN5216 (W) An expression of type "extern "OS" int
(*)(void *)" cannot be converted to type "char *".
ahk> xlC -c -qsuppress=CCN5216 cm.C
ahk>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C++ reinterpret_cast question
FWIW, you don't get this warning with 2.4.1 (or 2.3.1). What version are you using? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
Thanks a lot, Charles! That's going to occupy a lot of the team's time next week trying to answer that question! So far, I know of at least one that is having a very hard time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migrating to new compiler release
Hi Frank There are a few relatively minor differences in code generated but these tend to be mostly focused on taking advantage of z15. I assume you're not compiling for z15 (yet)? Other than z15 exploitation, this is like a really big continuous delivery PTF. There is always the possibility of different code generation in a PTF due to bug fixes. But in this case, there's really not a lot different unless you use z15, UTF-8, dynamic length elementary data items or 64-bit. Let me use this space as and ad for: https://developer.ibm.com/mainframe/cobol-migration-webinars/which is where you can register for the monthly migration webinar if you have some specific questions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic and static linked COBOL programs
Actually, you can still do DYNAMic call with call literal. CALL 'ABC" can still be DYNAM. Mostly good news: If you look around page 405 of the Version 6.3 PG (and there is a corresponding page for previous versions of the compiler) you will find a description of INFO BYTES. Offset 8, bit 5 tells you if DYNAM was specified. (Also offset 43 bit 2 tells you if DLL was specified.) Slightly bad news: a few releases ago, we added the >>CALLINTERFACE directive. That means that even if you compile with NODYNAM (i.e., static link) individual calls can be DYNAM calls. The INFO BYTES settings record only the global compile options and not the compiler directive overrides. (But for many users -- maybe including you -- it won't really matter.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for some large COBOL program examples
Since I know what I want the answer to be."V6 is almost as fast as V4" :-) my hope is you get, say, 19000 lines of data division and 1000 of procedure division! That's just my way of saying that, in my experience, no two 2 line programs are the same in terms of compilation resources. (Or, for that matter, run time improvement.) 2 lines of ADD 1 TO TALLY is different than a nightmarish mishmash of 2 lines of overlapping PERFORMed code. Because of that, I encourage as many people as possible to help Charles out. One problem with the COBOL world is that there is no Spec equivalent. In the past, I've made this offer in various places and I'll make it here again. If you have a 2 line program (or more or less) and you think it's representative of something important to your environment and you want to see compile time improvements or run time improvements and you can share it, I'm also interested in having it! -- 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
We're actually working on generating UUID directly from COBOL. I would expect to see it in V6.2 and V6.3 in a continuous delivery PTF fairly soon. We'll post more information when it does become available. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: casting with XL C\C++ compiler
POSIX(ON) is perfectly fine for new code. From an administration perspective, the user running a POSIX(ON) program needs a RACF OMVS Segment. That's really not that big a deal. Obviously, if you run in USS, you already have that set up. If you have existing code (say COBOL) that is running with POSIX(OFF) and you add a component (say Java) that requires POSIX(ON) there are subtle differences in the way signals are delivered. So you should probably do extra testing when first adding Java to a COBOL program that has been running for years. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: casting with XL C\C++ compiler
Hi Charles We are listening! https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/xlCC++V231ForZOsV23?OpenDocument This is a web deliverable that co-exists (does not overwrite) the existing xlC compiler. I have personally used it to develop C++ code with initializer lists, emplacements in collections, lambdas, variadic template classes and other more modern features. One thing I should point out. For any non-trivial program, the resulting executable will require POSIX(ON). Also, you should compile an entire application with the new compiler or the old one. (The object models are not the same.) Anyway read the link and give the compiler a try! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: casting with XL C\C++ compiler
The first bit of guidance is ... Don't Do That!!
I could not quite figure out what you meant, but this compiled for me with no
errors
struct S
{
int i;
};
void X()
{
S * p;
char Buffer[1000];
p = (S *) Buffer;
p = reinterpret_cast(Buffer);
// no way static_cast will work here! (And it should not)
}
using
xlC -qversion
z/OS V2.3 XL C/C++
Don't forget that if you try to defeat the type system with casts, you should
use the NOANSIALIAS option is compiling with optimization.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL runtime routine abend S0C4 or IEC036I 002-08 message and abend 002 closing VB file never written to
Yes, please. Open a case/PMR. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM69168E messages on COBOL V6.2 upgrade
Please open a PMR against COBOL V6.2. -- 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, 5.1 and 5.2 EOS Dates
Apologies: The V5.1 and V5.2 date is April 30, 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL 4.2, 5.1 and 5.2 EOS Dates
More than once on this forum, folks have asked about when Enterprise COBOL V4.2 will enter EOS. This announcement has the details: http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/2/897/ENUS919-022/index.html=en_locale=en V5.1, V5.2 will be EOS May 30, 2020. V4.2 will be EOS September 30, 2021. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
It is only available in 31-bit. An interesting question to ask is: if it were available in 64-bit but mixing and matching 31- and 64-bit modules was not possible (i.e., you would have to recompile all modules in an application), would that be interesting? Or is it the case that it is vital to be able to selectively compile modules (in 64-bit mode) and mix and match? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C errno from COBOL
Hi Frank:
I'm not sure if this will work for all times and in all cases.
Here is my C program simulating a C API that sets errno:
#include
int cfunc()
{
errno = 8;
}
Compiled with no options with z/OS V2.3 XL C/C++
Here is a small COBOL program I wrote
CBL PGMNAME(LongMixed)
Identification Division.
program-id. "FS".
Data Division.
Working-Storage Section.
1 pointer-to-errno usage pointer.
Linkage Section.
1 errno pic S9(9) COMP-5.
Procedure Division.
Display "Calling dummy C API"
Call "cfunc"
Call "__errno" returning pointer-to-errno
Set Address Of errno To pointer-to-errno
Display "errno = " errno
stop run.
End program "FS".
I call my C program to simulate calling a C API. Then, I call __errno which
appears to return the address of errno. I compiled this with V6.2 with no
options other than what is in the CBL card. I compiled, bound and ran on USS.
The result of the run is:
$ ./a.out
Calling dummy C API
errno = 08
$
Try it and if it works, great but put in some comments that say that this
relies on some implementation behaviour. (I'm Canadian and that's how we spell
that last word.)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13s not in Canada wasRe: [External] Re: Amazon Prime meltdown leads to IBM LinuxONE
Canadian Content usually refers to Canadian content in cultural products. For example, on radio, a certain percentage (which varies through the day) of programming must be composed by or performed by or recorded by Canadian artists. Similarly, a certain amount of television programming on Canadian TV networks must have a Canadian connection. Publishing houses constantly strive to develop Canadian authors. There's also a (usually struggling) Canadian film industry. (Which is independent of the fact that a lot of movies are filmed right here in the Toronto area and in many other parts of Canada.) It goes without saying that our governments obsess about Canadian Content and funding models for it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CBT tape file 321 Cobol Analyzer
Is there some specific information about the COBOL program that you are trying to find? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best Group for COBOL Question(s)
This list is followed pretty closely by the team so you can ask questions about COBOL here. You can also go to the COBOL Cafe (Discussion forum section) and ask questions there. There is an RFE on this topic and it has been accepted. There is no target date for that RFE. The issue is this: we implemented INITCHECK in the optimizer (not parse/scan.) That's because it has to do optimizer like things such as "Use/Def" tracking and it has to use aliases. So a word of warning: we plan to enable INITCHECK at OPT(0) but when when INITCHECK is running we still need to do some of these compute intensive operations so the OPT(0) compile will take longer. (Not as long as OPT(1) or OPT(2) but longer than OPT(0) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dr. John Ehrman
John was an exceedingly gracious individual without whom a lot of us would have been lost. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Silly C problem adding hex 6C
Now you ran into another problem (((char *)pointer) + offset) is how you want to bind that expression. (And I still think using structs is better) (and you may have to add (int*) in front of the line above) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Silly C problem adding hex 6C
The size of a char in 1 byte. Try (char *) ASXB = (char *) ASCB + 0x6c; /* lazy version */ But that's not really very nice C code. Rather than using int * variables, it would be preferable to provide a C struct describing the layout of storage and using a pointer (or a pointer to a pointer) of that type. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL source code quality check for performance
Another thing you can do with the new compiler is use the option RULES(NOLAXPERF) This will cause the compiler to add messages to the listing when you do things like use display data items for loop induction variables or in reference modifications. It's a good idea to use this option and clean up all of the code causing these messages. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Random number generation in a fixed range via utility program(s) only?
I'm not sure if this qualifies as "utilities" or "scripting." You did invite submissions from the USS community. And, in that community, those concepts can get mixed. At any rate, here is my effort using USS od -d /dev/urandom 2>/dev/null | head -8000 | cut -d" " -f2- | sed "s/ *//g" | cut -c1-4 That gives me 8000 random 4 digit numbers. It doesn't quite hit the mark on two counts. First, I do get a lot of duplicates. And second, I get numbers up to . Solving either of those problems would definitely require shell scripting. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol 5/6 - Compile listing integrated into load module
The source is included as part of the TEST data. All of the TEST data is in a NOLOAD section in the object file. With V6.2, TEST(SEPARATE) is supported and the TEST data can be in a separate data set. The TEST option is described in the PG. Since TEST(SEPARATE) is new (to V6 anyway) you can also refer to the MG. The TEST data (regardless of where it is found) is in an industry standard format called DWARF. (To which we have added some debug extensions.) We use a component called Common Debug Architecture (CDA) to write the DWARF information (if you are the compiler) and read the DWARF information (if you are a debugger.) The intention is to make this information as open as possible. The best place to start understanding the DWARF information is: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbcdu01/dwarfdump_defn.htm This page describes a tool to dump DWARF. Pages around this page describe various related tools. (In my opinion, if you want to start experimenting with these libraries, it's easier to work in USS. But that's just my opinion.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does IBM document the interface to the DB2 COBOL coprocessor?
No we don't document these interfaces. I can say that there are variations for co- and pre-processors and the interfaces for EXEC CICS, EXEC SQL and EXEC SQLIMS are not the same. Out of curiosity, why were you asking? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL calling Java - S922 error
(The machine I am using has many versions of Java; hence the extra directory) In my installation, I actually have 5(!) copies of J7.0 libjvm.so. Four of them (bin/j9vm, bin/classic, lib/s390/j9vm, lib/s390/classic) are identical. The fifth (lib/s390/default) is well over twice as large so I assume that it is the same thing compiled with different options such as TEST. It doesn't matter which one I use (they all seem to work.) Also, I have the latest LE PTFs for the COBOL run time. (Though I can't think of anything recent in there that would make a difference.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL calling Java - S922 error
(It's Allan, not Alan. But that is a common mistake.) I changed the Java to /usr/lpp/java/IBM/J7.0 and I also changed the run step to set PATH= (That is, PATH has no members in it when I run the program). And, as luck would have it, my program still works. I also ran the program in a script where first I unset every single environment variable. Assuming that the COBOL compiler and Java are installed in the standard places, the shell script should look like: #! /bin/bash /usr/lpp/cobol/igy420/bin/cob2 -c -I /usr/lpp/cobol/igy420/include IBMEXAM2.cbl /usr/lpp/cobol/igy420/bin/cob2 -o IBMEXAM2 IBMEXAM2.o /usr/lpp/java/IBM/J7.0/lib/s390/libjava.x /usr/lpp/cobol/igy420/lib/igzcjava.x /usr/lpp/java/IBM/J7.0/bin/javac HelloJ.java /usr/lpp/java/IBM/J7.0/bin/javac IBMExample2.java PATH= _CEE_RUNOPTS="XPLINK(ON)" CLASSPATH=. LIBPATH=/usr/lpp/java/IBM/J7.0/lib/s390:/usr/lpp/java/IBM/J7.0/bin/classic ./IBMEXAM2 Ug... There are five lines of commands but lines 2 and 5 may be wrapped in the text above. One question I have is: what are your LE options? In particular, is XPLINK(ON) specified? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL calling Java - S922 error
I did get this to work using USS. I had to change the following calls: Call "IBMZOS_NewStringPlatform" Call "IBMZOS_NewStringPlatform" CALL 'IBMZOS_GetStringPlatformLength' CALL 'IBMZOS_GetStringPlatform' (I don't know why that change was made, but it was) Here is my Makefile: PROG = IBMEXAM2 CLASSFILES = HelloJ.class IBMExample2.class JAVABASE = /usr/lpp/java/IBM/J7.1 COBBASE = /usr/lpp/cobol/igy420 run: $(PROG) $(CLASSFILES) _CEE_RUNOPTS="XPLINK(ON)" CLASSPATH=. LIBPATH=$(JAVABASE)/lib/s390:$(JAVABASE)/bin/classic ./$(PROG) %.class: %.java $(JAVABASE)/bin/javac $^ $(PROG): $(PROG).o $(COBBASE)/bin/cob2 -o $(PROG) $(PROG).o $(JAVABASE)/lib/s390/libjava.x $(COBBASE)/lib/igzcjava.x %.o: %.cbl $(COBBASE)/bin/cob2 -c -I $(COBBASE)/include $^ clean: rm -f *.class $(PROG) $(PROG).o Here is what happens when I type gmake run make clean run rm -f *.class IBMEXAM2 IBMEXAM2.o /usr/lpp/cobol/igy420/bin/cob2 -c -I /usr/lpp/cobol/igy420/include IBMEXAM2.cbl PP 5655-S71 IBM Enterprise COBOL for z/OS 4.2.0 in progress ... End of compilation 1, program IBMEXAM2, no statements flagged. /usr/lpp/cobol/igy420/bin/cob2 -o IBMEXAM2 IBMEXAM2.o /usr/lpp/java/IBM/J7.1/lib/s390/libjava.x /usr/lpp/cobol/igy420/lib/igzcjava.x /usr/lpp/java/IBM/J7.1/bin/javac HelloJ.java /usr/lpp/java/IBM/J7.1/bin/javac IBMExample2.java _CEE_RUNOPTS="XPLINK(ON)" CLASSPATH=. LIBPATH=/usr/lpp/java/IBM/J7.1/lib/s390:/usr/lpp/java/IBM/J7.1/bin/classic ./IBMEXAM2 B100-INITIALISE. B200-INIT-INPUT-VALUES Call "NewStringPlatform" inStringBuf. B300-INIT-OUTPUT-VALUES Call "NewStringPlatform" outStringBuf. C100-MAIN. About to call HelloJ Hello World, from Java! 2 Returned from sayHello data2 = 03 About to call IBMExample2 & pass a string IBM Example input = Hello IBM Example output = HelloAdded Text Just returned from JAVA Method:GetStringPlatformLength returned (16) Method:GetStringPlatformString returned (HelloAdded Text^@) STOP RUN. I haven't tried it using JCL. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: xkcd is too true, but posted at the wrong time.
The start date and end date for DST was adjusted sometime in the decade of the 2000s. Again, this was done as an energy saving scheme. I can't find the evidence of it at the moment but I recall another instance of the law of unintended consequences. Apparently, (at least in the US) early in the new DST period, a fair number of people got home from work while it was quite light and used the opportunity to drive to a mall or place of entertainment. As a result energy consumption actually went up in the first weeks. (Again, this may be apocryphal. Still, I found it a bit amusing.) -- 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
Yes a C DLL does have all static variables allocated and initialized when a DLL is loaded. This is usually fine. However suppose you had a few thousand independent programs that you linked into a DLL simply for packaging purposes. And suppose that each program had a lot of static storage associated with it. Now imagine that the DLL gets loaded repeatedly and in each case only one of the programs it contains is actually executed. That case could have performance problems in the C world because the static data for all of the few thousand independent programs is created and initialized for each load of the DLL (and in each case you're only running one of the programs.) That sort of packaging could create a performance issue for C programs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REGION=0M leads to CPU through the roof
Do you have access to Application Performance Analyzer (APA) or Strobe (or FreezeFrame)? If not, can you cut the program down to some kernel that exhibits the same characteristic? Also, do you happen to have COBOL V5 or V6 (maybe the trial version)? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REGION=0M leads to CPU through the roof
I want to be clear on one thingThe program produces the same result and has the same return code in both cases? Possibly another way of asking the same thing is: why did you alter the region size in the first place? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables
It sounds like it's time to open a PMR. Do you want to do that and can you do that? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables
Hi Peter I have a suspicion that this is a mixed language program. That is, it consists of COBOL and, say C. (Or it uses COBOL features with a C run time implementation such as XML or OO COBOL.) Can you confirm this is the case? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP
Bernd's assembler technique will work. I have no idea why I can't find a description of this (taken from /usr/include/stdio.h) #ifndef __gtca #define __gtca() _gtca() #ifdef __cplusplus extern "builtin" #else #pragma linkage(_gtca,builtin) #endif const void *_gtca(void); #endif online. It is mentioned in the XL C/C++ Runtime Library Reference Since it's not really described, I'm not sure you are allowed to count on it existing in the future. But in the past, that is the function that I have used (in 31-bit anyway) to get the CAA directly in C++. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP
If a C or PL/I or COBOL (or any LE high level language) program calls an assembler program, it will have set GPR12 to the CEE Anchor correctly before making the call. Assuming that you are completely lost in space in LE and you need the CEE anchor, there is a service called CEEARLU. It is documented here: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceev100/ceearlu.htm The compilers don't like using this because it is known to be not very fast. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP
This statement: >>CEECSA is always address by reg 12, while inside a LE module. is not strictly true. GPR12 is only required to point to CEECSA on entry to and exit from a procedure. Compilers are free to use GPR12 for whatever other purpose they chose at other program points. That means that if you get a crash in the middle of a procedure (COBOL PROGRAM) you should not look at the current value of GPR12. You should go back to the register save area and find what GPR12 was on entry to the procedure. (I mention this because with COBOL V5/6, GPR12 actually is often reused inside COBOL programs.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP
Bernd has already started the reply, but I would like to add a little bit. (First, I should say that most of this stuff IS documented in the PG and MG, but...) To find a specific W-S variable, you will need a listing. If you start with a dump, you will find a stack frame for your COBOL program and in its register save area, you will find the CAA Anchor in GPR12. Think of the CAA anchor as a thread specific piece of data. Fortunately, most non OO COBOL programs are single threaded so you don't have to worry about that subtlety. Also, if you start with a dump, you'll find the entry point for the COBOL program. From this, you can find the PPA1 (there is one for every sub routine in a compilation unit -- using C terminology): 00 02PROCPGG1 00 47F0 F014 02BC R15,20(,R15) # Skip over constant area 04 01C3 C5C5 02DC X'01C3C5C5' # Eyecatcher: CEE 08 0200 02DC X'0200' # Stack Size 0C 0690 02DC X'0690' # Offset to PPA1 <<-- 10 47F0 F001 02BC R15,1(,R15) # Wrong Entry Point: cause exception from the PPA1, you can find the PPA2 (there is one for the entire compilation unit -- again C terminology): PPA1: Entry Point Constants 000690 1CCEA506 =F'483304710' Flags 000694 0850 =A(PPA2-PGG1) << 000698 07C0 =A(PPA3-PGG1) from the PPA2, you can find the PPA4 (again only one): PPA2: Entry Point Constants 000850 04002203 =F'67117571' Flags 000854 F7B0 =A(CEESTART-PPA2) 000858 0058 =F'88' A(PPA4-PPA2)<<--- 00085C FFB0 =A(TIMESTMP-PPA2) 000860 F7B0 =A(PrimaryEntryPoint-PPA2) 000864 0220 =F'35651584' Flags The C_WSA is actually the combined writeable static area for all of the programs bound into your module (or DLL). To find the entire C_WSA for the module, you need to get the CEECRENT pointer out of the CEE Anchor. That means, getting 500(GPR12). Now you need to find the bit of the C_WSA for this particular program (compilation unit in C terminology). You can get that from the PPA4: PPA4: Entry Point Constants 0008A8 0800 =F'134217728' Flags 1 0008AC 00020100 =F'131328' Flags 2 0008B0 =F'0' A(NORENTstatic) 0008B4 =F'0' Q(RENTstatic)<<- Add that QCON to the CEECRENT -- 500(GPR12) -- and you have the start of the section of the WSA for your program. Now you need to know if WSOPT was used or not. For that you need to go back to the PPA2 and find the timestamp: 000844 FFB0 =A(TIMESTMP-PPA2) The time stamp is a fixed length and immediately following it is : Compiler Options and Program Information Section 000814 0034=X'0034' Size of Compiler Options and Prog Info Section 000816 (+00) 0474=X'0474' UNSIGNED BINARY CODE PAGE CCSID VALUE 000818 (+02) 07 =X'07' ARCHITECTURE LEVEL 000819 (+03) 00 =X'00' OPTIMIZATION LEVEL 00081A (+04) 1406=X'1406' INFO. BYTES 28-29 00081C (+06) =X'' INFO. BYTES 30-31 00081E (+08) A0C8754C2000 =X'A0C8754C2000' INFO. BYTES 1-6 000824 (+14) 00184001 =X'00184001' INFO. BYTES 7-12 The bit you're looking for is bit 3 of byte 15. Compare the output above to the same program with NOWSOPT 00080C (+14) 00084001 =X'00084001' INFO. BYTES 7-12 If you are using NOWSOPT (which is the default for V4) your W-S data items are all in your piece of the module's WSA. To find a specific item, you need to consult the listing looking
Re: How are Program Object sections with Defer attribute loaded?
That's actually a trickier question than you might imagine! There are a number of cases: the case where your module consists of COBOL, PL/I and assembler only and all other cases. All other cases include cases where the COBOL run time support is implemented in a language other than the above. These cases include OO COBOL, XML support and a few others. In the second case (not pure COBOL), the C_WSA is loaded in exactly the same way as it is for a C program. Basically, first the program is loaded and then the C run time gets control. It determines that you want to start new instance of this program (C_WSA is only used for RENT.) So it calls CEEPPOS which is the actual routine that gets a WSA and initializes it. This all happens before main is run. (Or, in the case of C++, before any file scope statics are constructed.) In the first case, your program starts and the COBOL bootstrap routine gets control. That routine is called at the start of every PROGRAM. In most cases, it checks a few things and returns. But for the first program in the run unit, it does some work including ensuring that LE is up. Part of that work is getting storage for the WSA. All of this happens before the first user statement in the PROCEDURE DIVISION is executed. So, no matter how the C_WSA is loaded (by and LE routine or by the COBOL run time) it is present before the first user written statement in the program is executed. Which means that unless you're getting some sort of a trap during the COBOL start up, you should always see the C_WSA somewhere in your storage. By the way, WORKING STORAGE is another area of complexity. In the case of NOWSOPT (the default for V5) W-S items are directly in the C_WSA. In the case of WSOPT (V6) W-S is separately allocated and the WSA contains a pointer to that allocation. (Again, this is all done before the first user statement is executed.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Interesting article on UNICODE.
In addition to PIC X, COBOL does have PIC N: National characters. These are basically UTF-16 characters. (With the property alluded to by Charles Mills: these are fixed two byte data items.) COBOL also offers DBCS characters. Also, there are some UTF-8 functions such as ULEN that operate on PIC X strings treating them as UTF-8. Here is my (and only my) random thought To really implement the Go scheme in COBOL, something about the standard use of the language would have to give. Practically speaking, you would lose a certain amount of control over the layout of storage. If we had a PIC H(20). (I used H because there is already a G and I wanted a type that is a Go Character type and H is the first letter after G. So this declaration means "up to 20 Go Characters.") Because we really can't use 4 bytes per character, we would need to have a pointer to the actual data. That data would likely have to be dynamically managed (almost like Java objects.) Also, in such a scheme, that 20 doesn't necessarily make sense. (Maybe as a declared maximum, but if the string needs to be managed dynamically, it should also have a dynamic length.) Doing something like this would take a fair bit of work to implement. It would also change the idea that the programmer fully defines the shape of working storage. (It's even more tricky to define such a data type in a file layout.) -- 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
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 sort of custom treatment from the compiler. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
