|
View previous topic :: View next topic
|
| Author |
Message |
sureshmurali
Warnings : 1
New User
Joined: 25 Nov 2010
Posts: 70
Location: Sivakasi, India
|
|
|
|
Hi
I have run the following compiler jcl :
//XXXXXXXA JOB (ACCTINFO),'COMPILE',MSGCLASS=O,CLASS=A,
// NOTIFY=&SYSUID
//STEP1 EXEC IGYWCL,
//PARM.COBOL='LIB,APOST,XREF,MAP,OFFSET'
//COBOL.SYSIN DD DISP=SHR,DSN=XXXXXXX.COBOL.PROGRAMS (DISPLAY)
//LKED.SYSLMOD DD DISP=SHR,DSN=YYYYYY.K194689.PGMLIB
(COBALOAD)
//SYSPRINT DD SYSOUT=
It produces the load to the PDS YYYYYY.K194689.PGMLIB
Then i ran the program using the following run jcl :
//XXXXXXXK JOB (ACCTINFO),'RUN',MSGCLASS=O,CLASS=A,
// NOTIFY=&SYSUID,REGION=2K
//STEP1 EXEC PGM=COBOLOAD
//STEPLIB DD DISP=SHR,DSN=YYYYYY.K194689.PGMLIB
//SYSIN DD *
SURESHRAMKUMAR1
/*
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
It correctly produces the output. No issue.
But i just copied the load from the PDS YYYYYY.K194689.PGMLIB
and put it in another PDS YYYYYY.XXXXXXX.JCLLIB and i changed the load location to this PDS by adding a JOBLIB parameter and removed the STEPLIB and the resultant jcl is looks like:
//XXXXXXXK JOB (ACCTINFO),'RUN',MSGCLASS=O,CLASS=A,
// NOTIFY=&SYSUID,REGION=2K
//JOBLIB DD DSN=YYYYYY.XXXXXXX.JCLLIB,DISP=SHR
//STEP1 EXEC PGM=COBOLOAD
//SYSIN DD *
SURESHRAMKUMAR1
/*
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
When ran this, i got the following error :
S806 abend and in the job log i found the message from JESMSGLG "FIND FOR MODULE FCOMMUOU FAILED BECAUSE DIRECTORY ENTRY IS NOT VALID FOR A LOAD" . Does it mean that when creating load, it also puts some entry about its location also. Cant we run a load created in one mainframe machine in another machine?
Please Clarify.
Thanks in advance! |
|
| Back to top |
|
 |
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
| What are the DCB attributes for YYYYYY.XXXXXXX.JCLLIB? |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
But i just copied the load from the PDS YYYYYY.K194689.PGMLIB
and put it in another PDS YYYYYY.XXXXXXX.JCLLIB and i changed |
what utility did you use to copy the load module? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
The atributes for load libraries/members are not compatible with a "JCL" library. . .
Depending on "things", the new destination library may have been corrupted. . . |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
| dick scherrer wrote: |
Hello,
The atributes for load library members are not compatible with a "JCL" library. . .
Depending on "things" the new destination library may have been corrupted. . . |
I guess my question should have been: "What were the DCB attributes for YYYYYY.XXXXXXX.JCLLIB?"  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Don,
Yup - sometmes there is a most ugly surprise. . . 
d |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
One of the more interesting dumps I got to debug came about some years ago when an application programmer had several concatenated libraries for the //STEPLIB -- and accidentally one of them was a PROCLIB. A PROCLIB which had a member that matched the program that was being called as a subprogram. The system tried to execute it but just could not find the ESD entries for some reason. 
The PROCLIB survived, IIRC, but the member had to be restored from backup -- although it may have been the whole PDS had to be restored. |
|
| Back to top |
|
|
sureshmurali
Warnings : 1
New User
Joined: 25 Nov 2010
Posts: 70
Location: Sivakasi, India
|
|
|
|
Hi i created a PDS of same DCB properties and then put the load in it.
Record format . . . : FBA
Record length . . . : 80
Block size . . . . : 800
1st extent tracks . : 1
Secondary tracks . : 3
Data set name type : PDS
Then tried run. It ran successfully.
Thanks |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
I believe you need to look more closely at what you have and/or have done.
Those are not dcb attributes for a load library. Load libraries (among other things) are recfm U. The following is more like what you should have for a loadlib:
| Code: |
Record format . . . : U
Record length . . . : 0
Block size . . . . : 32760 |
|
|
| Back to top |
|
|
sureshmurali
Warnings : 1
New User
Joined: 25 Nov 2010
Posts: 70
Location: Sivakasi, India
|
|
|
|
Yes Dick, You are right.
Sorry for being pasted wrong details.
Organization . . . : PO
Record format . . . : U
Record length . . . : 0
Block size . . . . : 32760
1st extent blocks . : 14
Secondary blocks . : 24
Data set name type : PDS
These are that DCB and its related details of that PDS
Thanks, |
|
| Back to top |
|
|
sureshmurali
Warnings : 1
New User
Joined: 25 Nov 2010
Posts: 70
Location: Sivakasi, India
|
|
|
|
Hi
I know that the load is nothing but a system executable format.
In the EXEC of job step we mention the load/utility for PGM or procedure name for PROC.
Can we call IEFBR14 , IEBGENER and all such utilities as LOADs inspite of we calling them as system utilities?
Also please let me know, in the IBM world i know the application language COBOL only as of now.
My question is whether those utilities are the loads created from COBOL programs resulted from COMPILE and LINK-EDITED?
Thanks,
Suresh K |
|
| Back to top |
|
|
sureshmurali
Warnings : 1
New User
Joined: 25 Nov 2010
Posts: 70
Location: Sivakasi, India
|
|
|
|
Hi i am terribly Sorry.... in a hurry i posted it under different question which i posted earlier.
Could you please relocate this under a new question.
"Is IEFBR14 is a load that is created from COBOL Program ?"
Thanks, |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| S806 abend and in the job log i found the message from JESMSGLG "FIND FOR MODULE FCOMMUOU FAILED BECAUSE DIRECTORY ENTRY IS NOT VALID FOR A LOAD" . Does it mean that when creating load, it also puts some entry about its location also. Cant we run a load created in one mainframe machine in another machine? |
1. A load module created on one z/OS machine can be run on another z/OS machine -- as long as all the subprograms are located. This is not an issue and you should completely forget you even asked the question.
2. PDS directory entries are different for load modules and source modules -- the load module PDS entry indicates size, TTR, authorization, and addressing modes whereas a source module does not.
3. The error message is EXTREMELY clear -- module FCOMMUOU was found in the PDS directory but is not a load module. You need to look at this member of your JCLLIB and find out why it is not a load module. You may need to recompile it or otherwise take action to ensure the load module FCOMMUOU is available when you execute COBOLOAD. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| "Is IEFBR14 is a load that is created from COBOL Program ?" |
No, the source of IEFBR14 is (or at least was last time i looked) assembler.
While the code was written in assembler (rather than COBOL), it was still linkedited into a "load module" for distribution. IEFBR14, IEBGENER and hundreds of others are distributed by IBM and are typically stored in their own load libraries - not the libraries you would link your COBOL executables into.
You need to make very certain that only jcl is placed in a jcl pds and that only load modules are placed into a load library. . .  |
|
| Back to top |
|
|
|
|
