Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!swrinde!ucsd!hub.ucsb.edu!ucsbuxa!3003jalp
From: 3003jalp@ucsbuxa.ucsb.edu (Applied Magnetics)
Newsgroups: comp.lang.fortran
Subject: Re: archiving block data subroutines...
Message-ID: <7388@hub.ucsb.edu>
Date: 26 Nov 90 17:37:15 GMT
References: <BURLEY.90Oct22050633@world.std.com> <27320@shamash.cdc.com> <BURLEY.90Oct23041048@world.std.com> <1990Nov22.074157.15813@agate.berkeley.edu>
Sender: news@hub.ucsb.edu
Lines: 27

In article <1990Nov22.074157.15813@agate.berkeley.edu> jerry@violet.berkeley.edu (Jerry Berkman) writes:

>...
>There is probably no easy way which works on all systems to get block data's
>to load.  Some UNIX systems will load a block data in a library if it is in
>the same source file as another program segment being loaded, some UNIX systems
>will not.  All the non-UNIX systems I have used would not.
>	- Jerry Berkman, U.C. Berkeley, jerry@violet.berkeley.edu

Our IBM mainframe with VS Fortran will do it.  The loader granularity
for libraries (TXTLIB's) is at the object file level (TEXT).  If an
archived object file contains a subprogram you need and a block data,
both get loaded.  (This is with VM/XA and CMS).

I agree that there is no universal solution.  Just for the heck of it,
here is yet another way to violate the standard:

C    <Never call this routine!  Just leave it near your main.
      SUBROUTINE KABOOM
      CALL BD
      END
C    <This BD is no subroutine.  It's the block data.  Tee hee.
C    <Hope this will fool the loader.

Anybody out there have a loader that refuses to cooperate?

--Pierre Asselin, R&D, Applied Magnetics Corp.