Ernest asks:

> I have subprogram I inherited that is trapping calls to CATOPEN, CATREAD and
> CATCLOSE, doing some things and then calling CATOPEN, CATREAD or CATCLOSE
...

> MODULE CATLG;
>
> EXPORT
...

1) I always avoid Pascal's MODULE/EXPORT/IMPORT stuff ... I've only found
   it to cause problems in various places.  Oh, I'm sure that when used
   correctly it works "ok", but it gets in the way of debugging (IIRC).

>   t_CATREAD =
>         FUNCTION (catindex : INTEGER;
>                   setnum, msgnum : SHORTINT;
>                   anyvar error : localanyptr;
>                   anyvar buff : localanyptr;

I'd prefer to see the "anyvars" you have for "t_catread" (and your
"function catread") be "char" or a record...but not a pointer.
However, that's got nothing to do with this problem at all.

Why?  That comes closer to matching the intrinsic declaration.

>     HPGETPROCPLABEL( procname
>                     ,plabel
>                     ,status
>                     ,f_lib
>                    );

I STRONGLY prefer seeing the commas *AFTER* the parameter, not
before.  Why?

   Greatly increased readability and maintainability, and
   it matches with the English language usage.

Your problem is twofold:

   1) you went out of your way to say "search starting in XL.PUB.SYS",
      and (because of #2 below) ...you found something there (and not
      in NL.PUB.SYS).

   2) you failed to supply the "casesensitive" paramter to
      hpgetprocplabel ... and the default (as shown by CSEQ) is "false".

Thus, your HPGETPROCPLABEL found the C library (I presume) "catread"
(lowercase!) in XL.PUB.SYS.  (Note: there's a "catread" in NL.PUB.SYS,
too...so simply changing the f_lib parameter wouldn't have helped in
this case).

BTW, I recommend changing the "catname := 'XXXX';" call in your
main program to:  "catname := 'XXXX ';"  (or whatever CATOPEN
documents is the correct filename terminator).  In *this* case
it worked...because the PAC that you're putting the data into is
longer than the file name, and Pascal blank filled for you.
But, it's always better to provide the terminator yourself!


Making the above change seemed to solve the catread load/fcall
problem.

Note that a simple Debug breakpoint showed me that the real CATREAD
was never getting called by your intercept routine...that's what
clued me in to the problem.

First, find the real CATREAD:

:debug
= CATREAD
c

Let's assume it's at: SYS $a.e35fec

Now, run your program:

   :run foo; debug
   b $a.e35fec
   /* above sets breakpoint at real CATREAD
   b CATREAD
   /* above sets breakpoint at my intercept CATREAD
   c

...

   you'll hit your CATREAD.  Look at parameters, then continue
   = r26; = r25; = r24; = r23; dv sp-$4e,8

   c

   you *should* hit your CATREAD.  NOTE: your unchanged program
   will eventually hit the real CATREAD...called on your behalf
   later on by other code.  So, it's useful in this debugging to
   change your intercept to:

        ...
        fcall (....
        writeln ('back from real catread');

   Thus, if you see the "back from real" after the breakpoint
   to your intercept and *before* the breakpoint for the real CATREAD,
   you know your intercept didn't call the real CATREAD.

SS