IBM Mainframe Forum

[zatlas1]

Hi All
Now everything compile using JCLs and parameters like this example:
[Note, all symbolics are resolved correctly using SET statements]

Select all

// SET MEMBER=BYTEORD8
//STEP1 EXEC EDCCL,CPARM2='SOURCE,LONGNAME,GOFF',
//      CPARM3=CSECT(&MEMBER)
//COMPILE.SYSIN DD DSN=&PCREHLQ..&PCREMLQ..&PCRESRC(&MEMBER),DISP=SHR
//USERLIB  DD DSN=&PCREHLQ..&PCREMLQ..CONFIG,DISP=SHR
//         DD DSN=&PCREHLQ..&PCREMLQ..&PCRESRC,DISP=SHR
//COMPILE.SYSCRPT DD SYSOUT=*
//LKED.SYSLIB  DD
//        DD DSN=&PCREHLQ..&PCREMLQ..&PCRELOAD,DISP=SHR
//LKED.SYSLMOD DD DSN=&PCREHLQ..&PCREMLQ..&PCRELOAD(&MEMBER),DISP=SHR

My questions are:
1. On all modules I get something like
IEW2650I 5102 MODULE ENTRY NOT PROVIDED. ENTRY DEFAULTS TO SECTION BYTEORD8#BYTEORD8#C.
and I do not know whether this is a problem.

2. On some modules I get RC=8 in the binder step with messages like:
IEW2456E 9207 SYMBOL _pcre_OP_lengths UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY.
I tried to use the compile options: LONGNAME,GOFF,CSECT(BYTEORD8) but the issue is not resolved. Does anybody have an idea what compile and/or binder option I should use to resolve it?

3. In some modules I get messages like:
IEW2456E 9207 SYMBOL fullinf8 UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY.
This time the message is not even about a long name, but about one of my modules that failed binder (rc=8) previously with one of those messages mentioned in the previous question. Is that a matter of case sensitivity?

Thanks
ZA

[BillyBoyo]

Try looking up all the messages and understanding what they mean and how they apply to you.

If there is something you don't understand, give us the detail and someone will be here to help out.

[steve-myers]

The IEW2650I message states that no module entry point was found in the input and the Binder established a load module entry point of its choosing.

Assembler programmers learn from experience that no input object "deck" specified an entry point as specified by the END statement in their program.

You will also get this message when the input to the Binder consists exclusively of load modules or program objects. A load module or program object entry point is not considered to be an input attribute similar to an entry point specified by an object "deck." It has always been this way, and I've never been able to deduce the reasoning for it. The official IBM rule for packaging modules for use by SMP clearly states that the ENTRY Binder statement must be specified, since the assumption is the input will only be load modules or program objects.

For C or C++ programs it probably means no input program specified procedure name main, when the compiler should note the entry point in the object "deck," or the input consists exclusively of load modules or program objects, as already noted.

External symbol _pcre_OP_lengths is created from your program. The leading _ was probably inserted by the compiler. Exactly what it means is up to your program; we cannot deduce it for you.

[zatlas1]

Thank you
Based on your help I've managed to resolve issue #3 and issue #1 was never a real issue
So let me please clarify and narrow question #2 which is the real problem
If I take for example the error message:
IEW2456E 9207 SYMBOL _pcre_OP_lengths UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY.
I see the symbol _pcre_OP_lengths which in many of my modules is an external name. However, in one of the modules, let's say TABLES8, I have an actual csect with that name and it appears in the binder output like this:

Select all

 ---------------
 CLASS  C_DATA            LENGTH =       AC  ATTRIBUTES = CAT,   LOAD, RMODE=ANY
                          OFFSET =       18 IN SEGMENT 001       ALIGN = DBLWORD
 ---------------

  SECTION    CLASS                                      ------- SOURCE --------
   OFFSET   OFFSET  NAME                TYPE    LENGTH  DDNAME   SEQ  MEMBER

                 0  TABLES8#T-LES8#C   CSECT         4  SYSLIN    01  **NULL**
        0        0     TABLES8#T-LES8#T   LABEL

                 8  _pcre_OP_lengths   CSECT        9C  SYSLIN    01  **NULL**
        0        8     _pcre_OP_lengths   LABEL

                A8  TABLES8#T-LES8#S   CSECT         4  SYSLIN    01  **NULL**
        0       A8     TABLES8#T-LES8#S   LABEL

Now, I am compiling and binding each module seperately, using this JCL:

Select all

// SET MEMBER=BYTEORD8
//STEP1 EXEC EDCCL,CPARM2='SOURCE,LONGNAME,GOFF',
//      CPARM3=CSECT(&MEMBER)
IEFC653I SUBSTITUTION JCL - PGM=CBCDRVR,REGION=48M,PARM=('/ SOURCE,LONGNAME,GOFF CSECT(BYTEORD8)')
//COMPILE.SYSIN DD DSN=&PCREHLQ..&PCREMLQ..&PCRESRC(&MEMBER),DISP=SHR
IEFC653I SUBSTITUTION JCL - DSN=ZATLAS1.PCRE.SRCE(BYTEORD8),DISP=SHR
//USERLIB  DD DSN=&PCREHLQ..&PCREMLQ..CONFIG,DISP=SHR
IEFC653I SUBSTITUTION JCL - DSN=ZATLAS1.PCRE.CONFIG,DISP=SHR
//         DD DSN=&PCREHLQ..&PCREMLQ..&PCRESRC,DISP=SHR
IEFC653I SUBSTITUTION JCL - DSN=ZATLAS1.PCRE.SRCE,DISP=SHR
//COMPILE.SYSCRPT DD SYSOUT=*
//LKED.SYSLIB  DD
//        DD DSN=&PCREHLQ..&PCREMLQ..&PCRELOAD,DISP=SHR
IEFC653I SUBSTITUTION JCL - DSN=ZATLAS1.PCRE.LOADLIB,DISP=SHR
//LKED.SYSLMOD DD DSN=&PCREHLQ..&PCREMLQ..&PCRELOAD(&MEMBER),DISP=SHR
IEFC653I SUBSTITUTION JCL - DSN=ZATLAS1.PCRE.LOADLIB(BYTEORD8),DISP=SHR

(left the substitution JCL to demonstrate that it is resolved correctly)

The module TABLES8 is available in ZATLAS1.PCRE.LOADLIB as it compiled and linked absolutely fine. Yet binding the next module that refer to _pcre_OP_lengths produces the error message above. I'd spent several hours going over the compiler options and came with: SOURCE,LONGNAME,GOFF CSECT(BYTEORD8) that to the best of my understanding should make the long names/mixed case visible to the binder, yet it seems like the binder somehow does not see these names and is not capable of resolving them. It seems to me that I am missing some copiler and/or binder options to resolve the issue.
Any idea please
Thank you
ZA

[NicC]

Might be a wrong idea but did you try INCLUDE TABLES8? Not quite the correct syntax but should point you in the right direction. On holiday so do not have my work flash drive with the manuals on to enable me to verify the syntax.

[zatlas1]

You won't believe it, but I've just came to the same conclusion myself...
I will try that and report back here.

Thank you so much
ZA

[zatlas1]

Explicit INCLUDE statements worked like charm!
Thank you
ZA