Not yet. I have verified much of what you said in your previous emails. I
have not had time to do full testing on the ";MERGE;SHARE" thing you
suggested though. It appears to work, but...

Before I go that route I need to find the same old communicators you looked
at and see what this is supposed to do. I am also a little concerned about
using non-standard tricks like this because they will be the first to break
on new OS versions and/or with an emulator (if one is ever created).

I think I have decided it is safer to go the dumb brute force route. Not put
the file updates in the XL subroutine. Instead just put the file stuff into
each program. Harder to maintain. But it is easier to find a junior
programmer who can do repeated maintenance on code in each of several
programs than it is to find a senior technical software engineer to fix
shared POSIX globals in a COBOL subroutine.

Thanks for all your wonderful input and the time you spent figuring out the
LINKEDIT "MERGE;SHARE". Perhaps someone with a little more guts (or
guaranteed long-term technical staff) than I have will make use of it.
Things are just too uncertain for me to think I myself will be here to
maintain it even a year from now.

Timothy Atwood
Holtenwood Computing
http://www.holtenwood.bc.ca/computing/
for Domtar Vancouver Mill
(Opinions expressed are mine and do not reflect Domtar)

-----Original Message-----
From: Duane Percox [mailto:[log in to unmask]]
Sent: Friday, May 09, 2003 12:53 PM
To: 'Atwood, Tim (DVM)'
Subject: cobol


Tim,
Were you able to get the cobol/xl file handling stuff
worked out?
duane



-----Original Message-----
From: Duane Percox [mailto:[log in to unmask]]
Sent: Tuesday, May 06, 2003 8:49 PM
To: [log in to unmask]
Subject: Re: COBOL XL Subprogram Access to File


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 *

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