|
View previous topic :: View next topic
|
| Author |
Message |
sushanth bobby
Senior Member
Joined: 29 Jul 2008
Posts: 1020
Location: India
|
|
|
|
Hi GUYz,
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
| Code: |
"."0.".0.................
..E6...................fy
.................. ......
..&..........-...........
................... |
After opening the file
| Code: |
... .....................
.........................
.........................
.........................
................... |
In the second run after opening the file
| Code: |
..K .....................
.........................
.........................
.........................
................... |
This is some parts of the code.
The declaration
| Code: |
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,
Sushanth |
|
| Back to top |
|
 |
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
| Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008
Posts: 1020
Location: India
|
|
|
|
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.
Thank You,
Sushanth |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
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). |
|
| Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008
Posts: 1020
Location: India
|
|
|
|
Robert,
Can i know, what is LE ?
Thank You,
Sushanth |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10903
Location: italy
|
|
|
|
| LE = Language Environment |
|
| Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008
Posts: 1020
Location: India
|
|
|
|
Language Environment can also initialize storage ?
Is the LE here being reffered to mainframe.
Sushanth |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10903
Location: italy
|
|
|
|
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
see for documentation al the CEE.... functions |
|
| Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008
Posts: 1020
Location: India
|
|
|
|
| Thank You Enrico |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
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.
Non-CICS Default: STORAGE=((NONE,NONE,NONE,0K),OVR)
CICS Default: STORAGE=((NONE,NONE,NONE,0K),OVR)
AMODE 64Default: STORAGE=((NONE,NONE,NONE,),OVR)
|
|
|
| Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008
Posts: 1020
Location: India
|
|
|
|
Hello Guyz,
| Quote: |
| 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 ?
Just viewing it fine?
Thank You,
Sushanth |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Use RPTOPTS(ON) to get a report on the LE options specified. If you're running a batch job,
| Code: |
| PARM='RPTOPTS(ON)/' |
should do nicely. Or you may want to look at
| Code: |
| PARM='RPTOPTS(ON),RPTSTG(ON)/' |
|
|
| Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008
Posts: 1020
Location: India
|
|
|
|
Hello guyz,
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.
| Code: |
//HXSULLXX JOB (T,TEST),'HXSULL',MSGCLASS=X,CLASS=L,NOTIFY=HXSULL
//*****************************************************************
//LMFBTCH EXEC PGM=BZLBTCH,REGION=4096K,
// PARM=('M=DB2MULSE,IH,NLV0,A,C,SOURCE,LB2MULSE, ',
// 'N, ','RPTOPTS(ON)/')
//STEPLIB DD DSN=PLT.POPR.DEVL.LOADLIB,DISP=SHR
// DD DSN=LMF.LOADB,DISP=SHR
//LSTIN DD SYSOUT=*,DCB=(LRECL=121,BLKSIZE=2420,RECFM=FBA)
//LST133 DD SYSOUT=*,DCB=(LRECL=133,BLKSIZE=2660,RECFM=FBA)
//INPUT DD UNIT=VIO,SPACE=(CYL,(2,8)),DISP=(MOD,DELETE),
// DCB=(RECFM=FBA,LRECL=121,BLKSIZE=2420)
//DBRMLIB DD DSN=TNLV0.TEST.DBRMHOLD,DISP=SHR |
Thank You,
Sushanth |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6965
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. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Code: |
// PARM=('RPTOPTS(ON)/M=DB2MULSE,IH,NLV0,A,C,SOURCE,LB2MULSE, ',
// 'N, ') |
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. |
|
| Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008
Posts: 1020
Location: India
|
|
|
|
Hello,
Following is my RUN JOB
| Code: |
//HXSULLXX JOB (T,TEST),'RUN PROG',MSGCLASS=X,CLASS=L,NOTIFY=&SYSUID
//*********************************************************************
//* JCL TO EXECUTE PROGRAM *
//*********************************************************************
//RUNPROGR EXEC PGM=IKJEFT01,
// PARM=('RPTOPTS(ON)')
//*********************************************************************
//STEPLIB DD DSN=TNLV0.TEST.LOADB,DISP=SHR
// DD DSN=PNLV0.PROD.LOADB,DISP=SHR
//*FILE1 DD DSN=TNLV0.TEST.OBJLIB,DISP=SHR
//*FILE2 DD DSN=NLV0.DLMF.LOAD.HXSULL
//SYSUDUMP DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//OUTDD DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM (DB2D)
RUN PROGRAM (DB2MULSE) PLAN(BOBPLAN) |
in the SYSTSPRT "invalid comand name syntax" message came
| Code: |
INVALID COMMAND NAME SYNTAX
READY
DSN SYSTEM (DB2D)
DSN
RUN PROGRAM (DB2MULSE) PLAN(BOBPLAN)
DSN
END
READY
END |
So, i must be missing something here.
Thank You,
Sushanth |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
You probably need to put the PARM on the RUN PROGRAM statement, not the EXEC PGM=IKJEFT01. Or you can add to your JCL:
| Code: |
//CEEOPTS DD *
RPTSTG(ON)
/*
|
However, we don't run DB2 here so I can't test to verify this. |
|
| Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008
Posts: 1020
Location: India
|
|
|
|
Thank You Robert, It works.
I have changed the option to
| Code: |
//CEEOPTS DD *
RPTOPTS(ON)
/* |
Iam getting values like in this LINK
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.
Sushanth |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
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. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Glad to hear you got the options listed -- now if we can just resolve the original issue it'll be a good Friday! |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
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. 
Regards, |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
