My friend is working in a COBOL-CONVERSION project(COBOL2 to COBOL390). This is how the process goes.
Run the COBOL2 program, get the output in a dataset file.
Convert COBOL2 into COBOL390.
Run the COBOL390 program, get the output in a different dataset file.
Compare the both the outputs, it should be same.
After converting one of the program and comparing the output. There was junk character found in COBOL2 output, after each execution of the cobol2 program the junk character happens to be different like B or 2.... In cobol390, its just spaces, no junk characters.
He had put the program in the CA-intertest and he checked. When the file is opened in the output mode he is getting the junk character. Following is the sequence of jumps the program takes.
Before opening the files CONTROL-REPORT has few junk characters that he saw in the intertest like
FD LPBCTL02-CONTROL-REPORT
RECORDING MODE IS F
BLOCK CONTAINS 0 RECORDS
LABEL RECORDS ARE STANDARD
RECORD CONTAINS 133 CHARACTERS
DATA RECORD IS CONTROL-REPORT.
01 CONTROL-REPORT PIC X(133).
Code:
PERFORM OPEN-FILES THRU OPEN-FILES-EXIT.
Code:
OPEN-FILES.
OPEN OUTPUT LPBCTL01-TRANS-REPORT
LPBCTL02-CONTROL-REPORT
OPBCTL01-C510-PARM-CARDS.
So, i was wondering. Does all the variables get auto-initialized in COBOL390.
Then i came across the following LINk
So, after reading the post. It can be also be a compiler setting for auto-initialization.
How can i check it in the compiler listing?
Does this particular setting have a name in COBOL2 & COBOL390 ?
Thank You CICS guy, that was very informational. I just got to know that COBOL390 is ENTERPRISE COBOL. I don't know why they are calling it COBOL390 conversion.
My friends case, Since the output files are not matching between COBOL2 & Enterprise COBOL. My friend is not able move set of programs with cases like this to production. I think, this is because of the person who has programmed in COBOL2 has not initialized the variable(didn't use INITIALIZE in cobol2), somehow the variables are getting initialized in Enterprise COBOL. Difference in outputs.
Thing with the COBOL CONVERION their project is, it has to be CONVERSION not CORRECTION.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
LE can also initialize storage -- although the particular pattern seen in the post is suspect; one byte wouldn't typically be changed (it's generally all or nothing).
LE is the term coined by IBM to define a set of services and subroutines
whose objective was to provide common services to all the languages supported by z/OS
once upon a time there was a COBOL library, a PL/1 library , ...
each language had it' s own set of service routines
the LE environment is meant to provide and unify these services in order to yield consistent results for any language involved
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Language Environment is an IBM-specific cross-language support platform that runs on the mainframe (it may run other places, too, but I don't deal with them -- only z/Architecture boxes). The Enterprise COBOL Migration Guide has extensive material on moving from VS COBOL II to Enterprise COBOL and LE. The LE manual discusses run time storage initialization:
Quote:
2.2.2.50 STORAGE
STORAGE controls the initial content of storage when allocated and freed. It also controls the amount of storage that is reserved for the out-of-storage condition. If you specify one of the parameters in the STORAGE run-time option, all allocated storage processed by that parameter is initialized to the specified value. Otherwise, it is left uninitialized.
You can use the STORAGE option to identify uninitialized application variables, or prevent the accidental use of previously freed storage. STORAGE is also useful in data security. For example, storage containing sensitive data can be cleared when it is freed.
If you specify one of the parameters in the STORAGE run-time option, all allocated storage processed by that parameter is initialized to the specified value. Otherwise, it is left uninitialized.
Is there a way to check this, has the STORAGE parameter been specified in the LE settings ?
THis is the job we use in our shop to compile,link-edit & bind. This is a LMF(Library Management Facility) job.
The program name here is DB2mulse & link name is LB2MULSE.
I gave that command along with other parameters. The JOB was successfull. But, i couldn't find infomation about LE, anywhere in SPOOL message.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
Sushanth,
the 'parm' should be a part of the JCL that invokes the COBOL program.
has nothing to do with the compile/link steps.
and would suggest looking at the LE intro guide (part of each of the language references).
in the newer ops-systems (z/os) ,
not knowing something about LE
is like not knowing about Hex.
Running old garbage
(cobol written without respect to IBM guidelines)
LE will bit you on the ass.
some programs will not run the same (if at all) in the new environment.
or something similar will be required. With LE, the PARM= has the LE values followed by a slash followed by the program specific parameters.
Further, as Dick pointed out, putting this in the compile / linkage job does not tell you about the run time environment -- only putting the parameter in the run job will give you the run time environment details.
My STORAGE(NONE,NONE,NONE,8192) values and only the reserve size is specified. Heap and Stack are not initialized.
Since, my friend and i are working in the same place.
So, the settings must me same for COBOL2 & Enterprise COBOL, right ? It must have the same storage values right.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
No, the settings don't have to be the same for COBOL II and Enterprise COBOL -- when installing the language there is a step to allow specific LE options to be compiled for that language; CEEUOPTS may be the name (it has been a while since I installed COBOL) -- I remember CEEDOPTS is the site wide options.
Working at the same place doesn't guarantee the same options, either -- you could be working on different LPARs (each of which may have different LE options) or even on different machines (which could be running different versions of the operating system much less LE).
IIRC, there was a WSCLEAR option in COBOL II that initialized storage -- check the COBOL II compile options to see if it was specified. If so, you can mimic the behavior by using LE option STORAGE=(00,NONE,NONE,8K) at run time.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Robert is correct. WSCLEAR was added to COBOL2 (version 4 IIRC) due to the fact that it no longer received pre-initialised storage as was in OS/VS COBOL.
Storage should always be cleared by the program, regardless. It's just a good fail-safe technique/practice.
Never rely upon storage to EVER be pre-initialised.
