HP3000-L Archives

September 2000, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Erik Vistica <[log in to unmask]>
Reply To:
Erik Vistica <[log in to unmask]>
Date:
Wed, 13 Sep 2000 16:10:52 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (64 lines)
Is your subprogram in an XL?

If so, I'm guessing you should/are getting parmcheck mismatch errors
 (LDRERR 205, LOADER ERROR 467)?


Have you tried linking the subprogram into the program file?

If you have, do you get errors (Incompatible number of arguments LINKERR
1042) during the link if the 2 parm call comes first in the code?


Whether the first call is executed or not likely only has an effect on
whether you abort or not.

The bottom line is that the COBOL compiler does not check for the same
number of parms in all of your CALLs to the same subprogram name. The
first CALL determines what it thinks are the 'correct' number of parms
and it saves this for later parm-checking at link/load time.

Note that if you were calling an intrinsic and had specified CALL
INTRINSIC, then the compiler would have checked the parm info then.

AFAIK, it has always worked this way (and I believe FORTRAN does too).
It is not a problem with either the linker or loader.

FYI, there are compiler directives to control the parmcheck level but
these wouldn't help you in this case since in COBOL they default to the
highest level.

HTH


Tony Summers wrote:
>
> I have a cobol subprogram that has 4 parameters
>
> I have called that subprogram from my main program twice - once with all 4 parameters and once with just two.
>
> If the code is organised thus
>
> if <condition which happens to be false>
>      CALL "X" USING A, B.
> end if
> CALL "X" USING A,B,C,D.
>
> then the program fails to load - as I would expect.
>
> If, however, the code is organized thus :
>
> if <condition which happens to be false>
>     CALL "X" USING A, B,C,D
> end if
> CALL "X" USING A,B.
>
> then the program loads, but then aborts on bound violation when the second call to the subroutine is made.
>
> Note it appears to be important that the first call to the correct version of the subroutine is not "executed" .
>
> Can anyone suggest a method that prevents the program from either being compiled in the first place or have
> I discovered a little known bug in the loader ?
>
> Many thanks.

ATOM RSS1 RSS2