|
View previous topic :: View next topic
|
| Author |
Message |
trushant.w
New User
.jpg)
Joined: 22 Sep 2013
Posts: 81
Location: pune india
|
|
|
|
In my account they were using Cobol 4 now they are migrating to 5.1
Earlier they were only maintaing the load modules of souce code and now they will be maintaing object as well.
As i understand the compilation and run process we need to create object module and then link-edit to create a load module.
Now in the documentation they have provided for this upgrade i have seen below
"COBOL V5 executables are Program Objects that can only resided in PDSE"
Is it like object modules are executable with this cobol 5 (executables are Program Objects) and we dont need to create load module ?
I am confused please share your thoughts on this. |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| "COBOL V5 executables are Program Objects that can only resided in PDSE" |
there has been an evolution in terminology...
the cobol ( or any compiler ) produces an object deck;
the linkage editor combines the object decks to get a load module,
the binder does the same producing program objects
but a program object might be needed because of the compiler rules
( so it is some kind of chicken and egg war )
the load modules can reside in a PDS
but program objects can reside only in PDSE.
the process is transparent to the user, the user still invokes IEWL,
but when the output resides in a PDSE the binder gets invoked under the covers
and produces a program object
so the process has not changed, the requirements are more stringent
due to the changed structure of COBOL 5 compiler output
at the end You will still be handling executable things... |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
No, it is not like that. I think the term "Program Objects" comes from outside of COBOL and other Mainframe languages (DLLs are Program Objects. DLLs needn't be COBOL, but can be with earlier Enterprise COBOL, for example). It does cause some confusion when we already have Object Programs.
An Object Program is the result of the compile which can become an executable program (by being processed by the linker/binder). Back in the past, an object program would be/could be physically punched on cards (an Object Program is in 80-character card format) and later presented for input many times. You may still hear references to the "Object Deck". The deck there means cards. Object Deck is the Object Program.
A Program Object, a completely different thing, is a fancier loadmodule. If using C/C++ within your linked/binded program, you must create a Program Object, not a loadmodule. If you are using Enverprise COBOL V5.x (and you should be using V5.2, not V5.1, if you are migrating or have just migrated, I would have thought) then you are using C/C++ within your linked/binded program, so you have a Program Object.
Program Objects cannot be stored on a PDS. They must instead be stored on a PDSE.
You need to clarify with your technical people if Object Programs will now be catalogued whereas previously they were not (it is common to see a temporary dataset of the Object Program output from the compiler and input to the linker/binder - although I prefer catalogued objects) or if it is some confusion of the terms Program Object and Object Program at some point. |
|
| Back to top |
|
|
trushant.w
New User
Joined: 22 Sep 2013
Posts: 81
Location: pune india
|
|
|
|
Thanks for your inputs enrico and bill
Enrico please confirm my understanding and correct me if i am wrong
The compiler of this cobol v5 produces output called "program objects" which is executable and this compiler does not need to produce the immidiate object module. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
unfortunately You are wrong ...
ANY compiler ( COBOL Included ) will produce an (F/FB) 80 binary file usually called OBJECT DECK
( soapbox reminiscence of when real card reader punches were used )
after that it is the (OLD)linkage editor, or the (NEW) binder that will produce
the executable
look at the compilations procedures
IGYWC compile only
IGYWCL compile, and link(bind)
IGYWCLG compile link, and go
the compile step contains a ddname
| Code: |
//SYSLIN DD DSNAME=&&LOADSET,UNIT=SYSDA,
// DISP=(MOD,PASS),SPACE=(TRK,(3,3)),
// DCB=(BLKSIZE=&SYSLBLK) |
where the binary output of the compiler is stored
the LOADSET token is a reminiscence of when it was possible
to load and run a program without creating a load module |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| ...without retaining the loadmodule on a permanent library. A loadmodule is still created. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
it is still possible
| Code: |
***************************** Top of Data ******************************
//ENRICO1 JOB NOTIFY=ENRICO,
// CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1)
//*
//CG PROC BLKSZ=27920
//C EXEC PGM=IGYCRCTL,PARM='LIB',
// REGION=0M
//STEPLIB DD DISP=SHR,DSNAME=IGY410.SIGYCOMP
//SYSPRINT DD SYSOUT=*
//SYSLIN DD DSN=&&OBJ,DISP=(,PASS),
// UNIT=SYSDA,SPACE=(CYL,(1,1)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=&BLKSZ)
//SYSUT1 DD UNIT=VIO,SPACE=(CYL,(1,1))
//SYSUT2 DD UNIT=VIO,SPACE=(CYL,(1,1))
//SYSUT3 DD UNIT=VIO,SPACE=(CYL,(1,1))
//SYSUT4 DD UNIT=VIO,SPACE=(CYL,(1,1))
//SYSUT5 DD UNIT=VIO,SPACE=(CYL,(1,1))
//SYSUT6 DD UNIT=VIO,SPACE=(CYL,(1,1))
//SYSUT7 DD UNIT=VIO,SPACE=(CYL,(1,1))
//G EXEC PGM=IEWLDRGO,
// COND=(4,LT,C)
//STEPLIB DD DISP=SHR,DSNAME=CEE.SCEERUN2
// DD DISP=SHR,DSNAME=CEE.SCEERUN
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSLIN DD DSN=&&OBJ,DISP=(OLD,DELETE)
//SYSLIB DD DISP=SHR,DSN=CEE.SCEELKED
// PEND
//*
//CG EXEC CG
//C.SYSIN DD *
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
AUTHOR. <SOME AUTHOR>
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
DISPLAY 'Cobol said... Hello World!' .
GOBACK.
**************************** Bottom of Data ****************************
|
to get
| Code: |
***************************** Top of Data ******************************
Cobol said... Hello World!
**************************** Bottom of Data ****************************
|
|
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| I should have been clearer: a compile-link-and-go (affected by 70's advertising of hair-care products, I colloquially refer to these as a Wash'n'Go) produces a loadmodule on a temporary library. At the end of the JOB, the loadmodule disappears because the temporary library does. |
|
| Back to top |
|
|
trushant.w
New User
Joined: 22 Sep 2013
Posts: 81
Location: pune india
|
|
|
|
I found one more confusing thing in the document
"Any Load Module in a PDS can be copied into a PDSE and it then becomes a Program Object "
Then why it even needs the recompilation ? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
"Any Load Module in a PDS can be copied into a PDSE and it then becomes a Program Object "
|
it is not confusing... You just did not read enough ...
whenever the properties of the source and destination datasets change
in this case from PDS to PDSE the binder is called to provide consistency ...
since the destination is a PDSE the only executable that can be stored there is a PROGRAM OBJECT.
It seems so simple to me! |
|
| Back to top |
|
|
trushant.w
New User
Joined: 22 Sep 2013
Posts: 81
Location: pune india
|
|
|
|
Thanks enrico !!
But then why there is need to recompile all modules with new compiler we can just copy load modules from PDS to PDSE's. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
You must use IEPCOPY to copy loadmodules from a PDS to a PDSE. IEBCOPY invokes IEWL to do what is necessary to make a program object.
All your V4.2 programs will run fine, and can happily be CALLed from V5.x COBOL.
However, none of your V4.2 program will benefit from the improvements in V5.x. To get those improvements, you must compile them with the V5.x compiler.
Exactly how this is implemented will vary from site to site, depending on many factors.
Presumably someone who knows all of this already is actually providing technical guidance at your site... |
|
| Back to top |
|
|
|
|
