Tim writes:

>I want to have a COBOL subprogram located in an XL to be
>aware of a file opened in the main program. I want the subprogram to use
>standard COBOL IO statements to access the file rather than needing to use
file
>intrinsics directly.
>
[snipped]

Here is what I understand:

a. Using EXTERNAL and linked as single run unit you get good results. I use
   this in a number of places in our software. You have to have the
   FILE STATUS IS .... clause of the SELECT statement and use EXTERNAL on
   the name (....) you use for the file status.

b. Using EXTERNAL or GLOBAL with an XL that is not specially prepared
doesn't
   work well. Here is an example of a main program opening an input file,
reading
   a record then calling DAPEXS which does 2 reads and outputs the results.
When
   we return then the main program reads another record. From the results
you
   can see the file pointer isn't moved when reading in DAPEXS.

Here is the test input file (first 7 records):

/LJ W2PIF.DAP
    1     W200001001<FIELDa..><FIELDb..>
    2     W200001002<FIELDc1.......................................>
    3     W200001003<FIELDc2.......................................>
    4     W200001004<FIELDc3.......................................>
    5     W200001005<FIELDc4.......................................>
    6     W200001006<FIELDc5.......................................>
    7     W200001007<FIELDd...>

Here is the run using a standard XL that has DAPEXS added to it:

:RUN DAPEXM.PRN;XL="DAPLIB.OBJXLIB"

DAPEXM    H.00.00 compiled 05/06/03

DAPEXM read=W200001001<FIELDa..><FIELDb..>
DAPEXS    H.00.00 compiled 05/06/03

DAPEXS read=
DAPEXS read=
DAPEXM read=W200001002<FIELDc1............
End Run

c. I discovered you can do the following and get it to work. I used
   EXTERNAL (did not try GLOBAL with this option). I'm not sure about
   side-affects, but you can at least use this method as a starting
   point in your testing/evaluation:

   Note: I previously used BUILDXL in LINKEDIT to create an empty XL
         called DAPEXL.OBJXLIB

:LINKEDIT
HP Link Editor/iX (HP30315A.06.17) Copyright Hewlett-Packard Co 1986

LinkEd> XL XL=DAPEXL.OBJXLIB

LinkEd> ADDXL FROM=DAPEXS.OBJ;MERGE;SHARE
1 OBJECT FILE HAS BEEN ADDED.

LinkEd> LINK FROM=DAPEXM.OBJ;TO=DAPEXX.PRN;XL=DAPEXL.OBJXLIB;SHARE

LinkEd> EXIT

:RUN DAPEXX.PRN

DAPEXM    H.00.00 compiled 05/06/03

DAPEXM read=W200001001<FIELDa..><FIELDb..>
DAPEXS    H.00.00 compiled 05/06/03

DAPEXS read=W200001002<FIELDc1............
DAPEXS read=W200001003<FIELDc2............
DAPEXM read=W200001004<FIELDc3............
End Run

As you can see it works as we would hope. I saw the ;SHARE option mentioned
in the 5.5 Communicator with reference to Posix shared globals and had
always
wondered if they had any use with HP COBOL. I always wanted to try it, but
never got around to it. Your posting prompted me to dust off the
Communicator
and try it out. I would do some experimentation to make sure you aren't
going to get burned by this, but it does look promising. Of course, if you
plan on porting this code to a non-mpe system you might want to be careful
about how tricky you get - this might not work on hp-ux or Linux or Solaris
or os/400 or os/390 or os/x or bsd or openvms or windows or whatever flavor
of os you might be migrating to :-)

duane percox

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *