Fujitsu v.3: Entry point of subprogram? 
Author Message
 Fujitsu v.3: Entry point of subprogram?

Ok, I'm lost:  we're using a subprogram for most of the processing in this
assignment.  I'm trying to compile it using the Fuji v.3 Programming Staff suite.
Compilation goes great, but on linking the subprogram a number of questions come up
(in my mind) and also the linker quits with this error:

       LINK : fatal error LNK1561: entry point must be defined

The Language reference from F. states:

-->21. To transfer control to the beginning of the procedure
-->division of the called program, specify the name of the
-->called program as literal-1 or identifier-1. You may want
-->to transfer control to entry point other than the beginning
-->of the procedure division. If so, specify the secondary
-->entry name specified in the ENTRY statement as literal-1
-->or identifier-1.

I wish to use the beginning of the procedure division as the entry point, so:

(from the subprogram)
       IDENTIFICATION DIVISION.
       PROGRAM-ID.  DATEDIFF IS INITIAL.
                 <...>
       PROCEDURE DIVISION
               USING lw02-date-one lw02-date-two lw03-diff lw04-msg.
       1000-main section.

(from the main program)
                 call 'DATEDIFF'
                  using ww02-date-one ww02-date-two ww03-diff ww04-msg  

Am I missing something basic?  I have the compiler option set to NOMAIN for the
subprogram, and MAIN for the calling prog.  I've tried ALPHAL, NOALPHAL, a lot of
other seemingly unrelated options, no dice.  The Fujitsu reference and all other
sources I've seen say that the primary entry point is established by default as the
PROCEDURE DIVISION USING ....   point.  So I can't understand the linker's reported
error message.

Is there a limitation to this suite that does not allow linking of subprograms?  I
appreciate any help on this.   Should I link the subprogram as a dll or an exe file?
Should I then rename either of these to remove the file extension, .dll or .exe in
order to have a consistent name for the calling program?  Should I use the full path
to the file thus produced or put it in the same directory with the calling program
and depend on the code to find it?  Compiled separately like this, is the subprogram
"external" or "internal"?  Seems there are some differences in what can be done
between these two types.  Should I compile the called program as type MAIN and link
it as a  .DLL?  Both are written in COBOL.

I extend, also, my thanks for all the comments on the INITIALIZE  3 dimensional table
thread.  Finished the program and it runs like a champ.  I went with the group move
( move zeros to wt01-sale-data )  for this table:

       01 wt01-sale-data.
           02 wt01-stores      occurs 5  times.
             04 wt01-months    occurs 13 times.
               06 wt01-depts   pic 9(9)V99 occurs 6 times.

TS

"Come to think of it, there are already a million monkeys on a million
 typewriters, and Usenet is NOTHING like Shakespeare." Blair Houghton
*********No generalization is wholly true, not even this one**********



Wed, 11 Jul 2001 03:00:00 GMT  
 Fujitsu v.3: Entry point of subprogram?
After a quick review, it LOOKS like you have done everything correctly.  A
couple of POSSIBLE (but unlikely) places to look:

1)  Did you compile the subprogram first, so when you tried to compile and
link the main, it could find the subprogram's executable? (and are they in
the same directory)

2)  You don't show that you have defined all those USING items from your
PROCEDURE DIVISION USING statement in the subprogram - in its LINKAGE
SECTION.  Just "matching the names" doesn't work - you need to have LINKAGE
SECTION items for all the passed parameters in the subprogram.  Just like
you have to define them in the Working-Storage in the CALLing program. (I
can't believe that the message you report would relate to this)

3) Do you happen to have any data items defined with the EXTERNAL attribute?
With some compilers (but I don't think Fujitsu), this can cause linker
problems.

--
Bill Klein
    wmklein at ix dot netcom dot com

Quote:

>Ok, I'm lost:  we're using a subprogram for most of the processing in this
>assignment.  I'm trying to compile it using the Fuji v.3 Programming Staff
suite.
>Compilation goes great, but on linking the subprogram a number of questions
come up
>(in my mind) and also the linker quits with this error:

>       LINK : fatal error LNK1561: entry point must be defined

>The Language reference from F. states:

>-->21. To transfer control to the beginning of the procedure
>-->division of the called program, specify the name of the
>-->called program as literal-1 or identifier-1. You may want
>-->to transfer control to entry point other than the beginning
>-->of the procedure division. If so, specify the secondary
>-->entry name specified in the ENTRY statement as literal-1
>-->or identifier-1.

>I wish to use the beginning of the procedure division as the entry point,
so:

>(from the subprogram)
>       IDENTIFICATION DIVISION.
>       PROGRAM-ID.  DATEDIFF IS INITIAL.
>                 <...>
>       PROCEDURE DIVISION
>               USING lw02-date-one lw02-date-two lw03-diff lw04-msg.
>       1000-main section.

>(from the main program)
>                 call 'DATEDIFF'
>                  using ww02-date-one ww02-date-two ww03-diff ww04-msg

>Am I missing something basic?  I have the compiler option set to NOMAIN for
the
>subprogram, and MAIN for the calling prog.  I've tried ALPHAL, NOALPHAL, a
lot of
>other seemingly unrelated options, no dice.  The Fujitsu reference and all
other
>sources I've seen say that the primary entry point is established by
default as the
>PROCEDURE DIVISION USING ....   point.  So I can't understand the linker's
reported
>error message.

>Is there a limitation to this suite that does not allow linking of
subprograms?  I
>appreciate any help on this.   Should I link the subprogram as a dll or an
exe file?
>Should I then rename either of these to remove the file extension, .dll or
..exe in
>order to have a consistent name for the calling program?  Should I use the
full path
>to the file thus produced or put it in the same directory with the calling
program
>and depend on the code to find it?  Compiled separately like this, is the
subprogram
>"external" or "internal"?  Seems there are some differences in what can be
done
>between these two types.  Should I compile the called program as type MAIN
and link
>it as a  .DLL?  Both are written in COBOL.

>I extend, also, my thanks for all the comments on the INITIALIZE  3
dimensional table
>thread.  Finished the program and it runs like a champ.  I went with the
group move
>( move zeros to wt01-sale-data )  for this table:

>       01 wt01-sale-data.
>           02 wt01-stores      occurs 5  times.
>             04 wt01-months    occurs 13 times.
>               06 wt01-depts   pic 9(9)V99 occurs 6 times.

>TS

>"Come to think of it, there are already a million monkeys on a million
> typewriters, and Usenet is NOTHING like Shakespeare." Blair Houghton
>*********No generalization is wholly true, not even this one**********




Wed, 11 Jul 2001 03:00:00 GMT  
 Fujitsu v.3: Entry point of subprogram?

Quote:

>       LINK : fatal error LNK1561: entry point must be defined
>       IDENTIFICATION DIVISION.
>       PROGRAM-ID.  DATEDIFF IS INITIAL.

Change the above to "DATEDIFF" IS INITIAL, and I think
you will be OK.


Wed, 11 Jul 2001 03:00:00 GMT  
 Fujitsu v.3: Entry point of subprogram?

Quote:

>Ok, I'm lost:  we're using a subprogram for most of the processing in this
>assignment.  I'm trying to compile it using the Fuji v.3 Programming Staff
suite.
>Compilation goes great, but on linking the subprogram a number of questions
come up
>(in my mind) and also the linker quits with this error:

>       LINK : fatal error LNK1561: entry point must be defined

A 1561 is usually caused when a program is compiled as MAIN and linked as
sub.

Compile Calling program with MAIN switch set and link as EXE.
Compile Called program with NOMAIN and link as dll.

Joe Hunter



Wed, 11 Jul 2001 03:00:00 GMT  
 Fujitsu v.3: Entry point of subprogram?

posted to "comp.lang.cobol" about: "Re: Fujitsu v.3:  Entry point of subprogram?" :

-->After a quick review, it LOOKS like you have done everything correctly.  A
-->couple of POSSIBLE (but unlikely) places to look:
-->
-->1)  Did you compile the subprogram first, so when you tried to compile and
-->link the main, it could find the subprogram's executable? (and are they in
-->the same directory)
-->
-->2)  You don't show that you have defined all those USING items from your
-->PROCEDURE DIVISION USING statement in the subprogram - in its LINKAGE
-->SECTION.  Just "matching the names" doesn't work - you need to have LINKAGE
-->SECTION items for all the passed parameters in the subprogram.  Just like
-->you have to define them in the Working-Storage in the CALLing program. (I
-->can't believe that the message you report would relate to this)
-->
-->3) Do you happen to have any data items defined with the EXTERNAL attribute?
-->With some compilers (but I don't think Fujitsu), this can cause linker
-->problems.

-->Bill Klein

1.  I have compiled the two programs in both orders, either one first.  It's the
linking of the subprogram, all in the same directory, that fails.

2. The working storage and linkage sections are carefully matched, I believe.  As
this is the first time I've ever done this, I spent a lot of time trynig to make it
right, which is of course no guarantee:

<calling program (Main)>

       01 ww02-date-one.
           02 ww02-date1-mm   pic 9(2).
           02 ww02-date1-dd     pic 9(2).
           02 ww02-date1-yy     pic 9(4).
       01 ww02-date-two.
           02 ww02-date2-mm  pic 9(2).
           02 ww02-date2-dd    pic 9(2).
           02 ww02-date2-yy    pic 9(4).
       01 ww03-diff                  pic 9(18) value zeros.
       01 ww04-msg                pic x(40) value spaces.
                  <...>
                 call 'DATEDIFF.EXE'
                  using ww02-date-one ww02-date-two ww03-diff ww04-msg  

<called program (Sub)>

       DATA DIVISION.
       FILE SECTION.

       WORKING-STORAGE SECTION.

                    <...>

       LINKAGE SECTION.
       01 lw02-date-one.
           02 lw02-date1-mm   pic 9(2).
           02 lw02-date1-dd   pic 9(2).
           02 lw02-date1-yy   pic 9(4).
       01 lw02-date-two.
           02 lw02-date2-mm  pic 9(2).
           02 lw02-date2-dd    pic 9(2).
           02 lw02-date2-yy    pic 9(4).
       01 lw03-diff                  pic 9(18).
       01 lw04-msg               pic x(40).
      *....................

       PROCEDURE DIVISION using lw02-date-one lw02-date-two
              lw03-diff lw04-msg.

3.  I don't have any data items defined as EXTERNAL.  I'm not quite sure even what
that means.  Seems like it would allow other programs/subprogs to access the data
items in memory locations assigned by the program with the EXTERNAL dataname?  Would
this then allow other progs to change that value, and then the main prog would
continue to operate on the data name's data that now has a different value?  This is
different from passing data as a 'Parameter' between programs??

I'm a bit new to this multiple--programming, but it looks very interesting.  Ideally
I would like to write, say, Visual Basic front ends to modules (libraries?) of
functions and processes in other more appropriate languages.  Not an original idea
but very powerful.  Every great journey starts with a first step (and a bruised can?
hah)

  TS



Wed, 11 Jul 2001 03:00:00 GMT  
 Fujitsu v.3: Entry point of subprogram?

"comp.lang.cobol" about: "Re: Fujitsu v.3:  Entry point of subprogram?" :

-->
-->>       LINK : fatal error LNK1561: entry point must be defined
-->>       IDENTIFICATION DIVISION.
-->>       PROGRAM-ID.  DATEDIFF IS INITIAL.
-->
-->
-->Change the above to "DATEDIFF" IS INITIAL, and I think
-->you will be OK.

Here's the entire Linker output, even after the above change it's the same:

-->NMAKE : fatal error U1077: 'J:\COBOL\FUJITSU\PCOBOL32\LINK' : return code '0x68'
-->Stop.
-->Microsoft (R) 32-Bit Incremental Linker Version 3.00.5270
-->Copyright (C) Microsoft Corp 1992-1995. All rights reserved.

-->/OUT:J:\SKULWERK\COBOL-3\PROG-3\FUJI\DATEDIFF.EXE
-->J:\SkulWerk\Cobol-3\Prog-3\Fuji\DATEDIFF.OBJ
-->J:\COBOL\FUJITSU\PCOBOL32\PROJECT.RES
-->J:\COBOL\FUJITSU\PCOBOL32\F3BICIMP.LIB
-->J:\COBOL\FUJITSU\PCOBOL32\LIBC.LIB
-->J:\COBOL\FUJITSU\PCOBOL32\KERNEL32.LIB
-->J:\COBOL\FUJITSU\PCOBOL32\USER32.LIB
-->LINK : fatal error LNK1561: entry point must be defined
-->Linking files ended.
-->Please close the window.

The linker looks like it found all the libraries and other support files it needed.
I have compiled, linked and run, with success other programs from Cobol source on
this same setup, so it is a known operable system.

Thanks for looking it over, TS

"Come to think of it, there are already a million monkeys on a million
 typewriters, and Usenet is NOTHING like Shakespeare." Blair Houghton
*********No generalization is wholly true, not even this one**********



Wed, 11 Jul 2001 03:00:00 GMT  
 Fujitsu v.3: Entry point of subprogram?
Try to simplify the problem to:

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID.  PROG1.
000300 ENVIRONMENT DIVISION.
000400 DATA DIVISION.
000410 WORKING-STORAGE SECTION.
000420 01  PARM PIC X(10) VALUE "HELLO".
000500 PROCEDURE DIVISION.
000600 MAIN-PROGRAM.
000700      CALL "PROG2" USING PARM
000800      STOP RUN
000900      .

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID.  PROG2.
000300 ENVIRONMENT DIVISION.
000400 DATA DIVISION.
000410 LINKAGE SECTION.
000420 01  PARM PIC X(10).
000500 PROCEDURE DIVISION USING PARM.
000600 SUB-PROGRAM.
000700      DISPLAY PARM
000800      EXIT PROGRAM
000900      .



Wed, 11 Jul 2001 03:00:00 GMT  
 Fujitsu v.3: Entry point of subprogram?

"Re: Fujitsu v.3:  Entry point of subprogram?" :

-->
-->>Ok, I'm lost:  we're using a subprogram for most of the processing in this
-->>assignment.  I'm trying to compile it using the Fuji v.3 Programming Staff
-->suite.
-->>Compilation goes great, but on linking the subprogram a number of questions
-->come up
-->>(in my mind) and also the linker quits with this error:
-->>
-->>       LINK : fatal error LNK1561: entry point must be defined
-->>
-->A 1561 is usually caused when a program is compiled as MAIN and linked as
-->sub.
-->
-->Compile Calling program with MAIN switch set and link as EXE.
-->Compile Called program with NOMAIN and link as dll.
-->
-->Joe Hunter

That works, only after moving the two source files to a new directory.  Now the main
program won't link....  They're in the same directory, but the reference is suddenly
'unresolved'.  I've tried recompiling with every change I could think of to make it
work.  Renaming the DATEDIFF.DLL file to _DATEDIFF , and all sorts of combinations,
putting these variously named files in the path in c:\windows, etc.: the linker just
won't bite.

Here is the output from the linker, used on the main program, (which did link at one
time before, and nothing has changed in the file, except I have tried to change the
call statement to the same names as the file name of the called prog...):

=====================================================================
NMAKE : fatal error U1077: 'J:\COBOL\FUJITSU\PCOBOL32\LINK' : return code '0x19'

Stop.

Microsoft (R) 32-Bit Incremental Linker Version 3.00.5270
Copyright (C) Microsoft Corp 1992-1995. All rights reserved.

/OUT:J:\SKULWERK\COBOL-3\PROG-3\FUJI\TEST2\PR3AF.EXE
J:\SkulWerk\Cobol-3\Prog-3\Fuji\Test2\pr3af.OBJ
J:\COBOL\FUJITSU\PCOBOL32\PROJECT.RES
J:\COBOL\FUJITSU\PCOBOL32\F3BICIMP.LIB
J:\COBOL\FUJITSU\PCOBOL32\LIBC.LIB
J:\COBOL\FUJITSU\PCOBOL32\KERNEL32.LIB
J:\COBOL\FUJITSU\PCOBOL32\USER32.LIB
pr3af.OBJ : error LNK2001: unresolved external symbol _DATEDIFF.DLL
J:\SKULWERK\COBOL-3\PROG-3\FUJI\TEST2\PR3AF.EXE : fatal error LNK1120: 1 unresol
ved externals
Linking files ended.
Please close the window.
======================================================================

The linker seems to be renaming the file to _name in the
(unresolved external symbol _DATEDIFF.DLL) statement in the output report above.
That's why I tried renaming the file, the called file name (symbol?) in the calling
prog's source code, both, etc.  Thanks again for suggestions, TS

"Come to think of it, there are already a million monkeys on a million
 typewriters, and Usenet is NOTHING like Shakespeare." Blair Houghton
*********No generalization is wholly true, not even this one**********



Wed, 11 Jul 2001 03:00:00 GMT  
 Fujitsu v.3: Entry point of subprogram?


Quote:
>Here's the entire Linker output, even after the above change it's the same:

E-mail me - I can send you something that will make it clear what to
you do make this link procedure work.  It'll be an attachment - about
a meg- that will show you how to do it.


Thu, 12 Jul 2001 03:00:00 GMT  
 Fujitsu v.3: Entry point of subprogram?


Send me that e-mail - I'll send you a movie.  If you are near a book
store, pick up Teach Yourself COBOL in 24 Hours and read chapter 23.
It will make all things clear <G>.



Thu, 12 Jul 2001 03:00:00 GMT  
 Fujitsu v.3: Entry point of subprogram?

"comp.lang.cobol" about: "Re: Fujitsu v.3:  Entry point of subprogram?" :



-->>Here's the entire Linker output, even after the above change it's the same:

-->E-mail me - I can send you something that will make it clear what to
-->you do make this link procedure work.  It'll be an attachment - about
-->a meg- that will show you how to do it.

Thanks, I'd appreciate that.  I will look up the book as well.  I think that there is
a very specific error or condition not being met in my coded call statement as I have
very carefully checked the syntax of the call in PROCEDURE DIVISION and still it does

called it now successfully from a data name by reference to it in procedure.  Go
figure.  I hope that what's happening here is clear in the book!  The school's
compiler is down (they've been messing with the hardware and so it's been flaky so
far this year) so I can't run it on an alternate system, MicroFocu 3.x, to see if my
procedure was kicked out because of the Fujitsu's apparent pickiness.

Thanks again for your response, looking forward to a 'movie', TS

"Come to think of it, there are already a million monkeys on a million
 typewriters, and Usenet is NOTHING like Shakespeare." Blair Houghton
*********No generalization is wholly true, not even this one**********



Thu, 12 Jul 2001 03:00:00 GMT  
 Fujitsu v.3: Entry point of subprogram?


Quote:
> Thanks again for your response, looking forward to a 'movie', TS

> "Come to think of it, there are already a million monkeys on a million
>  typewriters, and Usenet is NOTHING like Shakespeare." Blair Houghton
> *********No generalization is wholly true, not even this one**********


I *think* I sent it, but it might have gone to never never land.  
(Sorry for the newsgroup intrusion).  E-mail me again if you didn't
get it.


Fri, 13 Jul 2001 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. entry point not defined error when linking in fujitsu cobol v3

2. Getting the address of an ENTRY point using FUJITSU cobol

3. Calling Fujitsu COBOL subprogram from a C main program on Sun Solaris

4. Embed points for double entry or templates for double entry bookkeeping

5. ERROR: No feasible entries for subprogram

6. passing allocatable values from main to subprogram to subprogram

7. Fujitsu PowerForm decimal point

8. Entry points or callbacks?

9. Initializing Base Register(s) in Multi-entry-point CSECT

10. entry points in shared libraries

11. smalltalk entry point

12. "entry point not found" error

 

 
Powered by phpBB® Forum Software