Tim,

You need the COBOL manual, and probably the Programmer's guide.  Both are
available online at www.hp.com.

Rather than figure out how to use EXTERNAL etc, why not KISS by heeding the
sage advice of Roy Brown, who suggested simply doing ALL of your shared
file's IO via an XL-resident subprogram which does nothing else.  That works
VERY nicely, better than even just two main programs doing their own IO vs
that file - you have exactly ONE place to maintain that file's IO routines,
and you get to use English COBOL, no calls to FOPEN etc with cryptic
parameters.

Like this fregzample:

MAIN
WS
01 IOFIELDS.
  05  IOCMD PIC S9(4) COMP.
  05  IOFILENAME        PIC X(26).
  05  IOBUFFER  PIC X(WHATEVER).
  05  IOERROR     PIC S9(4) COMP.

01 IOCONSTANTS.
  05  IOOPENI   PIC S9(4) COMP VALUE 1.
  05  IOCLOSE                      2
  05  IOREAD                       3
  05  IOWRITE                      ETC
  05  IOOPENIO                     ETC

PD
MOVE IOOPEN TO IOCMD
MOVE 'MYFILE' TO IOFILENAME
CALL IOSUB USING IOFIELDS
MOVE 'MYDATA' TO IOBUFFER
MOVE IOWRITE TO IOCMD
CALL IOSUB USING IOFIELDS
MOVE IOCLOSE TO IOCMD
CALL IOSUB USING IOFIELDS
GOBACK
.

SUBPGM.
SAME WS BUT IT'S LINKAGE
PD.
EVALUATE IOCMD
  WHEN IOOPEN OPEN...
END-EVALUATE
GOBACK
.


> -----Original Message-----
> From: Atwood, Tim (DVM) [mailto:[log in to unmask]]
> Sent: Friday, May 09, 2003 2:11 PM
> To: [log in to unmask]
> Subject: Re: Cobol
>
>
> 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 *
>

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