HDTenEightyP/NetNews huggingface dataset:
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Header processing with NOTES channel
From: Ned Freed <ned@innosoft.com>
Date: 12 Jan 1993 09:27:08 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Jan 1993 09:27:08 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GTFD2M2LJM8WWDJA@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"bob@camb.com"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

The NOTES channel fully supports the headerbottom and headeromit channel
keywords; you can use those. All the caveats about stripping headers apply,
of course.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: Header processing with NOTES channel
From: Bob Tinkelman <bob@camb.com>
Date: 12 Jan 1993 10:03:05 -0500 (EST)
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Jan 1993 10:03:05 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GTF81MG3XE934PP2@INNOSOFT.COM>
X-Vms-To: IN%"info-pmdf"
X-Vms-Cc: TINKELMAN
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Is there a way to instruct the NOTES channel to insert *no* headers into
posted notes?  If I surpress all headers using HeaderTrim then the NOTES
channel won't receive the From: and Subject:-headers, which would clearly
be unacceptable.
Newsgroups: vmsnet.mail.pmdf
Subject: Yet another query on VMS-MAIL Linelength (but with a twist)
From: Bill Wilder <wilder@nsrske.agr.ca>
Date: 11 Jan 1993 16:17:32 -0500 (EST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 11 Jan 1993 16:17:32 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: wilder@NSRSKE.AGR.CA
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GTE4QB81UA8WW7R4@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"INFO-PMDF@YMIR.CLAREMONT.EDU"
X-Vms-Cc: IN%"wilder@NSRSKE.AGR.CA"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Ned - don't chew me out about this query (VMS Mail line lengths)
until all the flattery at the bottom has been read.

We have a gateway node running PMDF V4.1 serving many connected
DECNET nodes not running PMDF (at least not yet).

I understand the limitation within VMS mail that prevents messages
containing wide lines from being delivered properly using just VMS mail.

Do I also understand properly that an incoming MIME encoded message will
automatically be delivered using SEND/FOREIGN. If so, should not
SEND/FOREIGN be immune to record length considerations?

Or to get right to the point:

Incoming MIME encoded messages are sticking in our D queue and D_MASTER.LOG
shows the RMS message:

        %RMS-W-RTB, 512 byte record too large for user's buffer

I can provide PMDF.CNF or further details if required. Neither foreign
nor noforeign were specified for the DECNET channel (foreign should
be the default). The d channel does specify headerbottom.

===========================================================================
Attached flattery:

I had the opportunity to listen to the PMDF developers at a recent
BOF at the Fall DECUS and must say how impressed I was with their mastery
of e-mail issues and Internet issues and their ability to communicate
clearly. Our choice of PMDF has served us well to date and I am confident
it will continue to do so while it remains in these capable hands.
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Yet another query on VMS-MAIL Linelength (but with a twist)
From: ned@sigurd.innosoft.com
Date: 12 Jan 1993 12:49:11 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Jan 1993 12:49:11 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: ipmdf@SIGURD.INNOSOFT.COM
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GTFK3W9S9E984I7N@SIGURD.INNOSOFT.COM>
X-Vms-To: IN%"wilder@NSRSKE.AGR.CA"  "Bill Wilder"
X-Vms-Cc: IN%"ipmdf@SIGURD.INNOSOFT.COM"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

SEND/FOREIGN from a foreign protocol interface across MAIL-11 used to work.
Unfortunately, this is no longer the case; DEC appears to have broken it
at some point along the way. It now appears to be subject to the same
constraints that have always applied to record-oriented messages. And since
foreign messages are by definition block-oriented, this means that they fail
in almost all cases.

I have described the problems with the foreign protocol interface and line
length limits in great detail in the past. I won't bore you with a repetition
of them here.

Always keep in mind that /FOREIGN is undocumented and unsupported. MAIL-11's
support for it has always been a bit hokey.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: Immediate batch job submissions
From: Liquid Len <liquid@usc.edu>
Date: 12 Jan 1993 18:29:45 -0800 (PST)
Reply-To: Asbed Bedrossian <asbed@ucs.usc.edu>
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Jan 1993 18:29:45 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GTFW0BZVG28WWDNK@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Hi folks,

only 11 months after my own question I have my answer... :)
(I think Steven Tihor was also complaining of this once)

I had a problem with immediate submissions never happening. My pmdf
delivery would end up doing it all. the batch job was never submitted, and
VMS accounting logs never showed unusual termination. (Dan and Ned had
suggested looking in the logs)

At the time, I couldn't figure it out and termporarily I just increased
the frequency of my pmdf batch delivery; that was satisfactory. Then I got
busy; then I forgot.

Today I decided (on a flash intuition) to check on it again. I run CMUTCP.
In my SYS$MANAGER:INTERNET.CONFIG file, I changed:

WKS:25:SMTPSV:TCP$SMTPSV:NETWRK:NETMBX,TMPMBX,PHY_IO:4:5

to:

WKS:25:SMTPSV:TCP$SMTPSV:NETWRK:NETMBX,TMPMBX,PHY_IO,CMKRNL,SYSPRV:4:5

Just added those two privs. It all works fine now.

So, at the risk of winning the procrastinator's top award, there it is. I
hope it saves someone a bit of time. :)

:ll
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Bug in os_wake_deliver
Date: 7 Jan 93 00:45:35 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 06 Jan 1993 17:45:35 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GT8D7IIY4Y90P0FB@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"MIONE%ZODIAC.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Yes, there's indeed a tiny window there. I've actually seen in happen once or
twice on a systems that process several thousand messages a day, especially
when certain jobs produce hundreds or thousands of expansions from a large
mailing list. The problem was minimized by some of the queue cache logic,
in that no advance listing of messages is actually created most of the time,
and as such it is quite likely that the first job with the earliest starting
time will pick up messages submitted after it begins to run.

Nevertheless, as you point out, the fix is straightforward, and we'll include
it in PMDF V4.2.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Empty MAILSERV list causes error message
From: Ned Freed <ned@innosoft.com>
Date: 12 Jan 1993 10:01:59 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Jan 1993 10:01:59 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GTFEAKREKI8WWDND@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"Rollo.Ross@Levels.UniSA.Edu.Au"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

In general it seems much riskier to me to fail to warn people that they
are sending to an empty list. It seems like a great way to lose a lot of
mail. You must also remember that lots of postmaster mail is deleted without
ever being read, especially when it looks like a routine send failure of
some kind... Sending such traffic to the postmaster is therefore not an
effective solution in most cases.

It also seems to me that empty expansion lists are something that primary
list maintainers actually _do_ want to know about. True, it may be
inappropriate in some cases to return such information to the primary
list maintainer, but in other cases the primary list maintainer may need
this information to run the list effectively. The risk of the primary list
maintainer acting in an inappropriate fashion seem far less than the risks
of eliminating this information completely.

In any case, it is pretty easy to get PMDF to handle this in whatever
way you like. You can arrange for any alias to override the error return
addresses in a message. Just set things up so that the externally visible
list address sets the error return addresses to either the local
postmaster or <>. This will require another indirect file but that's no
big deal. And the bogus address on the list will eliminate the possibility
of the list ever emptying completely. The bitbucket channel can be used to
process such bogus addresses.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: pmdf-mr
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 07 Jan 1993 15:19:15 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 07 Jan 1993 15:19:15 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GT8PVS70YA90P3M2@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"cheri.weaver@sheridanc.on.ca"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I am running PMDF v.4 and PMDF-MR.  I can send mail from Allin1
> to an Ultrix machine (TCP/IP Services for VMS) and it gets delivered
> with no problems.  Unfortunatley I cannot reply to the message.
> I am using sendmail on the ultrix machine and the first "from" in the
> header seems to have the replyable address but the second "from:"
> is being used and it is full of, I believe, x400 gobblygook and
> returns an error.  I can send mail from the Ultrix machine to the
> Allin1 account using what shows up on the from line.
>
> I would appreciate it if someone can give me any ideas as to how I
> should be solving the problem or point me to the right place.

Please be more specific.  Please provide a sample message (a copy of what
you see on the UNIX machine) and a copy of the bounce message (or other
error text).  Send these to service@innsoft.com.

Dan
From: johnson@northeastern.edu (I am only an egg.)
Newsgroups: vmsnet.mail.pmdf
Subject: immediate vs. periodic
Date: 12 Jan 93 16:33:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Jan 1993 11:33:00 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GTFB92HEJM8WW1RG@INNOSOFT.COM>
X-Vms-To: IN%"ipmdf@innosoft.com"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT


     Hi.

     All my channels are immediate.  However I seem to be winding up
with que lengths of 30 to 50 or so on the local channel specifically.
These messages get delivered the next time the periodic batch job fires
off.

     Why are these messages sitting on a que which is marked as
immediate?  What am I doing wrong?  The local channel entry looks as
follows;

l 822 bidirectional immediate filesperjob 2 queue local_mail logging
northeastern.edu

     I'm running the following;

     VMS 5.5
     PMDF 4.1
     TGV 3.1

     Thanks.

Chris Johnson
Northeastern University.

--Boundary (ID uk7m4QSDZnJZgt+fu2+HMA)--
Newsgroups: vmsnet.mail.pmdf
Subject: How is estimated time to send FAX calculated?
From: The PMDF Postmaster <mac@gvg34.gvg.tek.com>
Date: 11 Jan 1993 06:54:19 -0800 (PST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 11 Jan 1993 06:54:19 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: HACKETT@gvg34.gvg.tek.com
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GTDTEECR4I8WW5FW@YMIR.CLAREMONT.EDU>
X-Vms-To: in%"ipmdf@ymir.bitnet"
X-Vms-Cc: in%hackett
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

One of my users would like to know how

      Estimated duration of the phone call:

is calculated.  I assume that a good guess is made from the size of the file
to be sent to the modem?

Bill

!-----------------------------------------------------------------------!
! Bill MacAllister    MS 8L         !  EMail:     Mac@GVG47.GVG.TEK.COM !
! The Grass Valley Group, Inc.      !                                   !
! P.O. Box 1114                     !  Telephone: 916-478-3201          !
! 13024 Bitney Springs Road         !  FAXphone:  916-478-3187          !
! Grass Valley, California 95945    !                                   !
!-----------------------------------------------------------------------!
Newsgroups: vmsnet.mail.pmdf
Subject: RE: immediate vs. periodic
From: "I am only an egg." <johnson@northeastern.edu>
Date: 12 Jan 1993 13:07:42 -0500 (EST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Jan 1993 13:07:42 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GTFEK5FUDU8WW1RG@INNOSOFT.COM>
X-Vms-To: IN%"ned@innosoft.com",IN%"ipmdf@innosoft.com"
X-Vms-Cc: JOHNSON
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

   >There is at least one oversight in the immediate job creation logic that
   >can cause messages to slip into the queue without getting processed by
   >an immedate job. This was discussed earlier this month on info-pmdf;
   >please check the original messages on this subject for details. This
   >will be fixed in the next release.
   >
   >It is also possible that your immediate jobs are dying without doing any
   >processing; you'd have to examine your logs to see if this is happening. It
   >is also possible that processing is happening but for some reason the
   >user's mail files are temporarily unavailable. This is a very frequent
   >event on some systems. Again, you'll have to check the logs to tell the
   >specifics. You can usually tell whether or not a message has received
   >some attention by the file name: names beginning with ZZ have not been
   >processed; names beginning with ZY have had one delivery attempt; names
   >beginning with ZX have had two, and so on.

     The logs look ok, no failed deliveries I can either see or don't
understand.  The files in question are ZZ's.  Must be the bug.  As long
as I know it isn't something silly I did and I can get aroud it I'm all
set.

     Thanks.

Chris J.
N.U.
Newsgroups: vmsnet.mail.pmdf
Subject: Bug in os_wake_deliver
From: Tony Mione <mione%zodiac.bitnet@ymir.claremont.edu>
Date: 06 Jan 1993 17:04 -0500 (EST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 06 Jan 1993 17:04 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GT791BE2B690OT3R@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"IPMDF@YMIR.BITNET"
X-Vms-Cc: SYSTEM
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT


        On occasion, we have noticed a problem with message files
which are abandoned by all of the channel master batch jobs.  These
message files are being left in PMDF queue directories without any
delivery attempts being made (i.e. the filenames start with 'ZZ') and
after all of the currently running batch jobs have completed.

        After looking at routines from the MM.PAS, OS.PAS and SUBMIT_MASTER.PAS
source files, it seems like there is a potential race condition which
allows 'windows' to exist where message files will not be delivered
until POST.COM is run.

        The scenario is as follows:

        Three (or more) messages are being written to a channel queue directory
at about the same time (the time recorded by os_init_deliver differs
by, let's say, several hundreths of a second in each case).
Message 1 completes writing a message file and submits a master channel job.
The master job submitted by message 1 starts and takes its directory listing.
Message 2 is long and has gobs of addresses to process.  Message 3 completes
and submits a master channel job which goes into a PENDING state.  Message
2 completes processing and notices that a batch job exists for the channel
so it does not submit another.

        The results:

        Message files written with time stamps between message 1's
'os_init_deliver' time and the time that master job completes its
directory command will get delivered.  Message files at or after
message 3's 'os_init_deliver' time will get delivered.  Messages written
by message 2 which are stamped before message 3's 'os_init_deliver' time
will be delayed until POST.COM runs.

        The fix should be straight forward.  There is code in the
middle of os_wake_deliver which checks for the existance of the
master batch job on a particular channel.  The check should include verifying
that Parameter 3 of a PENDING channel master batch job is also earlier
than the current message's 'os_deliver_start_time'.  If it is not, then
one additional channel master batch job should be submitted.



Tony:: (VMS Systems, Operations & Technical Support, RUCS)
Hill Center 046 - (908)-932-4785
---------------------------------------------------------------------
Bitnet:  MIONE@ZODIAC.BITNET
Arpa:    MIONE@ZODIAC.RUTGERS.EDU
_____________________________________________________________________

Basic rule when in flight:
        Maintain thy airspeed, lest the earth arise
                and smite thee.
Newsgroups: vmsnet.tpu
Subject: RE: how compatible is DECset 11 LSE/SCA
From: tp@mccall.com (Terry Poot)
Date: Mon, 11 Jan 1993 14:26:24 CST
Reply-To: tp@mccall.com (Terry Poot)
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


Claes,

Thanks for the info. Unfortunately, it looks like I'm going to have to wait till
I have time to fool with things. If the source directory and read-only directory
logicals no longer work, I'm going to have to re-write some of my development
environment. It sounds like they've changed names of things, so I can't just
recompile my section file, I'll have to re-write it. And of course, before I can
do that, I have to learn all this stuff.

It really sounds pretty good, but it also sounds like it won't drop in and run
in my current environment. Pity. Why'd they put in a bunch of compatibility
stuff if it doesn't do the job?  *sigh*
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
Newsgroups: vmsnet.tpu
Subject: Re: PDF and .TPU files?
From: tp@mccall.com (Terry Poot)
Date: Tue, 12 Jan 1993 14:13:53 CST
Reply-To: tp@mccall.com (Terry Poot)
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <0533*ENGEL4.ENGELIN@IBMX400-SE.IBMMAIL.CIRCE.FR>,
engel4.engelin@ibmx400-se.ibmmail.circe.fr writes:
>Now, as far as I know, TPU does not support .ANA files. Is there
>some other way of getting LSE/SCA to produce reports without
>fetching this information from the SCA library? I assume that TPU
>must be defined as a language in LSE, that "!doc_begin" and
>"!doc_end" should be defined as comments, and that "ONE LINE
>DEFINITION:" etc. must be defined as TAGs.

Check out HELP SCA ANALYZE. It produces ANA files for languages defined to LSE
that don't have compilers that produce ANA files. Beyond that, you'd do it like
any other SCA reports, which I've never done and can't help you with.
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA

BTW, your posts arrive here indented about 20 columns, and then line-wrapped at
about column 80. It makes them hard to read. Your signature block looks like
this on my system:

                  --
                  Claes Engelin    | Phone: +46 31 371943  | "After you stop be
lieving
                  SKF Systems      | Fax:   +46 31 371716  | in Santa Claus, th
e world
                  DSE/HK3-9        | MEST:  DSVGOT.G721746 | just seems to go d
ownhill"
                  S-415 50 GOTEBORG| MAIL:  GOTV04::HDSECE |    - Tom Clancy
                  Sweden           | X.400: /S=ENGELIN/G=ENGEL4/ADMD=IBMX400/PR
MD=IBMMAIL/C=SE
                                   | Internet: engel4.engelin@ibmx400-se.ibmmai
l.circe.fr
Newsgroups: vmsnet.tpu
Subject: LIB$FIND_IMAGE_SYMBOL
From: Tom Williams <williams@ab.wvnet.edu>
Date: Sat, 09 Jan 1993 10:10:38 -0500 (EST)
Reply-To: Tom Williams <WILLIAMS@AB.WVNET.EDU>
Organization: The Internet
Return-Path: <TPU-Mgr@SHSU.edu>
Errors-To: TPU-Mgr@SHSU.edu
X-Listname: Text Processing Utility (TPU) Language Discussion List
X-Vms-To: NET::"INFO-TPU@SHSU.edu"
X-Vms-Cc: ME
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT

> From: Comet <COMET@us.oracle.com>
> Subject: LIB$FIND_IMAGE_SYMBOL
> To: INFO-TPU@SHSU.edu
>
> I remember seeing on a DECUS symposium tape, once upon a time, a TPU
> CALL_USER routine that used LIB$FIND_IMAGE_SYMBOL to activate
> arbitrary routines in arbitrary (`correctly' linked) shareable images
> to do such things as, ummm, maybe finding the sine of some angle.
>
> Does this sound at all familiar?

          Yes, he said, blushing.  I wrote it.  It's a pair of
          routines, as I recall (long time since I've touched it).
          One of them builds a few arrays of arguments for the call;
          the other one invokes LIB$FIND_IMAGE_SYMBOL and LIB$CALLG.
          I will get the sources out of mothballs and send them out
          some time in the next week or so, if you can's find it
          elsewhere.

          Currently, the routines only handle integers and strings.
          Maybe they'll evolve.

                                                -Tom Williams
                                                 Computer Center Manager
                                                 Alderson-Broaddus College
                                                 WILLIAMS@AB.WVNET.EDU