HDTenEightyP/NetNews huggingface dataset:
From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail User agents
Date: 13 Aug 92 09:29:41 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 13 Aug 1992 01:29:41 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNIK3EPVMA94E3QT@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"KNAPKE%BUTLERU.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> cc:Mail looked pretty good as well, but we are not sure how we are going to
> serve it to close to 400 Macs.  On the DOS side, its easy, we have Novell
> servers.  There has been discussion of the cc:Mail channel in PMDF and how
> to push mail back and forth, that sounds good but a little ruff as far as
> the particulars of pushing the files back and forth.  Ned mentions MIME
> translation into cc:Mail, but said there were problems with multi-part mail
> (if I recall correclty).  That confuses me since cc:Mail had the ability to
> have multiple enclosures, or am I missing something??

It is really not that hard to arrange for the necessary file transfers.
We use PathWorks internally for this and it is seamless and clean. Any
other file server facility should work.

The only problems with multi-part mail are caused by the severe limitations
cc:Mail imposes. Text messages must consist of very short lines and cannot be
very long in cc:Mail. Everything else has to be a file attachment. The PMDF
gateway to cc:Mail takes all of this into account, and the results are the best
they can be, but I still don't like the limitations.

cc:Mail also doesn't support type information for attachments. This is a severe
limitation; you lose a lot of valuable information here.

There are essentially no problems with gatewaying cc:Mail and its attachments
into MIME. MIME is more than versatile enough to handle everything cc:Mail
can produce.

Please note that MHS has restrictions too -- in some ways it is more restricted
and in other ways it is less -- so there really is no perfect solution to these
problems.

				Ned
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: vms v5.5-1 and pmdf v4.1-1 problems.
Date: 13 Aug 92 18:50:55 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 13 Aug 1992 10:50:55 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNJ3P2DWOY94E7I0@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"tkslen@ubvms.cc.buffalo.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

PMD V4.1 works just fine with VMS 5.1-1.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail User agents
From: andrewr@itd.adelaide.edu.au
Date: 17 Aug 1992 08:23:18 +1000
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Aug 1992 08:23:18 +1000
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: info-pmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNNL52M6RM95NCS6@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"KLENSIN@INFOODS.MIT.EDU"  "John C Klensin"
X-Vms-Cc: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Mts: smtp

In message <713977262.781166.KLENSIN@INFOODS.MIT.EDU> you write:

+ >> 	So the concept employed is that there is one central place
+ >> that stays up all day, and you can access from all over the place. The
+ >> problem now is that PC and Mac users expect a GUI as opposed to the

+ >That's why "store and forward" methods like POP have been very popular for
+ >PCs and MACs of late.  There some very nice looking POP client programs
+ >available to overcome the issue of not having your personal computer
+ >turned on all the time.

+ Jack,
+   While not disagreeing with anything you've said, I think a
+ terminology clarification would be helpful before this discussion goes
+ down the path of a parallel discussion about these mail-receiving
+ protocols...
+   Strictly speaking, one could easily construct "store and forward", and
+ a solution to the shut-off workstation problem with SMTP alone.  You
+ would set up MX records for the workstations that would deposit the mail
+ somewhere else if the workstation was off, e.g.,
+      workstation MX 0  workstation
+      workstation MX 10 postoffice

	This doesn't get around one of the problems I was raising,
which is that these "mainframe derived" schemes only allow for the
user to read their mail from one physical location, their PC. This is
not acceptable in our institution, which is why we've gone cc:Mail and
are about to start using PMDF to interface with it.

	Andrew.

/*
 * Andrew Rutherford                 andrewr@itd.adelaide.edu.au
 * +61 8 228 5669            Real Programmers always confuse Christmas and
 * Room 1060, Adelaide Uni      Halloween because OCT 31 == DEC 25 !
 */
From: tihor%nyuacf.bitnet@ymir.claremont.edu (Stephen Tihor 212 998 3052)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail User agents
Date: 16 Aug 92 15:36:05 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 16 Aug 1992 11:36:05 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: info-pmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNN5UQUVB695N4UO@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"KLENSIN@INFOODS.MIT.EDU"
X-Vms-Cc: IN%"info-pmdf@ymir.bitnet"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

INdeed thsi is a case where the infamous SMTP TURN command, if usable, would be
appropraite to do the SMTP/system level version of POP.
From: mac@gvg34.gvg.tek.com (The PMDF Postmaster)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Install bug
Date: 14 Aug 92 13:47:43 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Aug 1992 05:47:43 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNK8879PKY94ED7Z@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>Accounts of the form [nnn,0] have implicit privileges -- GRPPRV, I
>believe.  It is a very bad idea for the PMDF account to have such
>access; it is certainly not needed and it can lead to trouble. We
>therefore don't allow the use of an account of this sort as the PMDF
>account.

Well, okay, but this is the first installation since we started using
PMDF that complained about a zero member.  I believe our first PMDF
installation was version 2.4.  I would have liked a bit more complete
error message during the installation since this was changed behavior,
but as with all complaints/suggestions about PMDF this is a nit.

Bill MacAllister
From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: pmdf v4.1-1 and slow delivery
Date: 23 Aug 92 09:44:21 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 23 Aug 1992 01:44:21 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNWJI9IU1U95NZIJ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"tkslen@ubvms.cc.buffalo.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Since PMDF V4.1 is more efficient in almost every way than V4.0 was
(usually performance just about doubles or better) I seriously doubt that
this phenomenon is something in PMDF itself. The first thing you should
figure out is what messages are holding in what queues and more
importantly where they are coming from. For example, if messages are
coming in from PhoneNet and not getting proper immediate processing
you may well have a cache ownership problem. There are dozens of
other possibilities, however, and the only thing that makes sense for
you to do is start looking at the specifics of the problem itself.
Poring over your configuration is likely to simply be an exercise
in frustration and will probably not get your anywhere very quickly.

				Ned
Newsgroups: vmsnet.mail.pmdf
From: wdw3@cunixb.cc.columbia.edu (Wei Dong  Wu)
Subject: Re: question (thanks). More question
Reply-To: wdw3@cunixb.cc.columbia.edu (Wei Dong  Wu)
Organization: Columbia University
Date: Wed, 19 Aug 1992 15:59:58 GMT

Thanks Dan and Ned for your lightening fast answer to my question of sending
bitnet mail from a internet-only machine.
I run PMDF on a two-node VAXcluster. Each node has a valid internet host
name. PMDF images are loaded on both nodes but there is only one cluster-
wide MAIL$BATCH queue. I want different local host appear on the return
address when people send mail from different node. So I create a PMDF.CNF
for each node with the host name for l channel pointing to each node. This
works fine when I send mail from the node on which the MAIL$BATCH is running.
But when I send mail from the other node, the local host name apprears twice
in the return address, like
	From: user@localhost@localhost
Any idea how this happen? Or is there other better way to do this? Thanks.


Weidong Wu
wdw3@cunixb.cc.columbia.edu
From: klensin@infoods.mit.edu (John C Klensin)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail User agents
Date: 16 Aug 92 15:01:02 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 16 Aug 1992 11:01:02 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: info-pmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNN4MNNV2A95NBLN@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ip_boss@degsyd.syd.deg.csiro.au"
X-Vms-Cc: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>

>> 	So the concept employed is that there is one central place
>> that stays up all day, and you can access from all over the place. The
>> problem now is that PC and Mac users expect a GUI as opposed to the
>>...
>That's why "store and forward" methods like POP have been very popular for
>PCs and MACs of late.  There some very nice looking POP client programs
>available to overcome the issue of not having your personal computer
>turned on all the time.

Jack,
  While not disagreeing with anything you've said, I think a
terminology clarification would be helpful before this discussion goes
down the path of a parallel discussion about these mail-receiving
protocols...
  Strictly speaking, one could easily construct "store and forward", and
a solution to the shut-off workstation problem with SMTP alone.  You
would set up MX records for the workstations that would deposit the mail
somewhere else if the workstation was off, e.g.,
     workstation MX 0  workstation
     workstation MX 10 postoffice
You would then set "postoffice" up with a channel (or equivalent) for
delivery to local workstations distinct from its channels for delivery
to the rest of the network.  And you would set a really aggressive retry
schedule on that channel s.t., when the workstation came up, it would
get its mail dumped on it in rather short order.  You'd be effectively
polling its SMTP port all the time, and delivering as soon as it came
up.

Is this a good idea?  Well, no, and for a number of reasons.  But it is
"store and forward".   POP et al., which depend on the workstation
announcing to the server that they have come up and then retrieving the
mail, are more like "store and fetch".
   --john

  Is th
From: robin_goldstone@macgate.csuchico.edu (Robin Goldstone)
Newsgroups: vmsnet.mail.pmdf
Subject: mailing list automation
Date: 17 Aug 92 10:51:05 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Aug 1992 10:51:05 +0000 (U)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNOOQ2L3KY95NEQT@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Our campus currently has a mailing list set up that any user can send to, which
will in turn be re-distributed to everyone on the campus e-mail system.  This
list, called USERS, is managed by PMDF as follows:

In VMS mail, there is a forwarding address which forwards USERS to IN%USERS

In the PMDF alias file, there is an entry for USERS:
USERS: <dua1:[local]users.dis

So when people send to USERS on the VAX, it re-directs to all the people in the
users.dis file.

I have been asked to make a change in this procedure, such that messages sent
to USERS get stored on the VAX, and sent out at midnight i.e. deferred
delivery.  I won't go into details about why they want to do this, it is
political.

How can I implement this?  I have looked at DELIVER  but I don't really have
any experience using it, so I am not sure it will do what I need. The messages
need to be sent back out, retaining their original headers and everything else.
 If not DELIVER, then what?  Can I define a new channel, that uses a different
batch queue, that I can stop and then start every night at midnight?  I would
have to be able to set up a re-write rule based on the left hand side of the
address to do this.  Is that possible?

Any suggestions are appreciated.
Robin Goldstone, CSU Chico
robin@csuchico.edu
From: david J. Knapke 317/283-9420
Newsgroups: vmsnet.mail.pmdf
Subject: RE: deliver and 'vacation' processing
Date: 20 Aug 92 20:23:34 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 20 Aug 1992 15:23:34 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: ipmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNTAIWXUYQ95NTHZ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"robin_goldstone@macgate.csuchico.edu"
X-Vms-Cc: IN%"ipmdf@YMIR.BITNET"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I don't have an answer for your problem, but a plea for what you are
trying to do.  PLEASE filter out lists for this reply!!!  It is really
a pain to get mail bounced back to a list that says John Doe will be
out until....  People on the list really don't care.



David J. Knapke                       Knapke@ButlerU.BITNET
Computer Center                          Assistant Director
Butler University                     Information Resources
Indianapolis, IN  46208                      (317) 283-9420
USA                                     Fax: (317) 283-9740
From: bowman_brett_e@lilly.com (Brett E. Bowman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: two minor points
Date: 13 Aug 92 15:09:10 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 13 Aug 1992 15:09:10 +0000 (GMT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
X-MX-Warning: Warning -- Invalid "To" header.
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNIY273IOI94E6IL@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"@mr.lilly.com:ipmdf%ymir.claremont.edu@in"
Autoforwarded: false
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Importance: normal
Priority: non-urgent
Sensitivity: Private
Ua-Content-Id: 11686A890800
X-Hop-Count: 2

Here at Lilly, we have been piloting Mailworks as a "mail solution".  I really
like receiving the Postmaster's bounce messages via MIME and PMDF-MR so that I
get the message as an attachment.  It is very convenient.  Thanks go to
Innosoft for getting this implemented.
						Brett E. Bowman
						Postmaster
						Eli Lilly & Company
						BOWMAN_BRETT_E@LILLY.COM
From: fineberg@wupost.wustl.edu (Charles M. Fineberg)
Newsgroups: vmsnet.mail.pmdf
Subject: TCP/IP Services for VMS V2.0 and PMDF
Date: 20 Aug 1992 14:55:34 -0500
Organization: Washington University in Saint Louis, MO USA
NNTP-Posting-Host: wuarchive.wustl.edu
Keywords: UCX 2.0, TCP/IP Services

  Just a quickie:
	Has anyone used pmdf 4.x and UCX 2.0?
We just got the new UCX in here at our campus ESL and I want to know
if it is safe to use it...
	Charlie
From: bob@camb.com (Bob Tinkelman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: pmdf 4.1-4 and slow delivery
Date: 23 Aug 92 12:36:15 GMT
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 23 Aug 1992 08:36:15 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: info-pmdf@INNOSOFT.COM, TINKELMAN@Eisner.DECUS.Org
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNWRVH25DU94E3LB@INNOSOFT.COM>
X-Vms-To: in%"tkslen@ubvms.cc.buffalo.edu"
X-Vms-Cc: in%"info-pmdf@innosoft.com",TINKELMAN
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

This is probably not your problem, but it was something that surprised us.

PMDF 4.1 can use many more batch jobs than 4.0.  If you're not using the
process symbiont, that could make a performance difference.  In versions
prior to 4.0, the periodic delivery job would, if it was running in the
appropriate batch queue for a channel, run the channel itself, rather than
submitting a separate batch job for that channel.  With 4.1, it always
submits a separate batch job.

When I installed 4.1 on eisner.decus.org, the number of batch jobs run (on
the whole system) went up from about 800/day to about 1250/day.  [The
configuration here at that time did no immediate delivery; all delivery was
from the periodic delivery job, running with a post interval of 10 min.]
--
Bob Tinkelman <bob@camb.com>
From: david J. Knapke 317/283-9420
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail User agents
Date: 13 Aug 92 20:32:02 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 13 Aug 1992 15:32:02 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: Ipmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNJ9DUKXS294E88Z@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"MAC@gvg34.gvg.tek.com"
X-Vms-Cc: IN%"Ipmdf@YMIR.BITNET"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT


>The guy working on ccMail here downloaded the following document from the
>ccMail BBS yesterday.

>Bill MacAllister

>================================================
>DEC updates E-Mail, Provides cc:Mail Integration
>================================================

>BOSTON, MASSACHUSETTS, U.S.A., 1992 JUN 10 -- Digital Equipment has
>announced a new release of its local area network electronic mail
>integration product, MailWorks Postmaster, that ties DEC's mail systems
>in
>with Lotus Development's PC-based cc:Mail.

.....rest deleted.....

As I understand if from our local Dec Reps, there are now two MailWorks
products (thank you DEC).  One is a new product that is competing head
to head with folks like cc:Mail and MicroSoft mail, the other is what we
had been calling All-in-1 mail (not All-in-1 Integrated Office System).
There supposedly is no tools know (yet of course) that integrate MailWorks
(PC based mail system) with MailWorks (the A-1 mail system).

Is thes congruent with what others have heard??  I'm confused and I spent
most of yesterday with people who are supposed to know, so...WHY ARE YOU
DOING THIS DEC????



David J. Knapke                       Knapke@ButlerU.BITNET
Computer Center                          Assistant Director
Butler University                     Information Resources
Indianapolis, IN  46208                      (317) 283-9420
USA                                     Fax: (317) 283-9740
Newsgroups: vmsnet.tpu
Subject: Re: Getting a logical within a TPU procedure
From: "brian J. DTN 381-0021, TPU/EVE Development  12-Aug-1992 0603"
Date: Wed, 12 Aug 92 03:19:31 PDT
Reply-To: "Brian J. DTN 381-0021, TPU/EVE Development  12-Aug-1992 0603"
Organization: The Internet
Return-Path: <TPU-Mgr@SHSU.edu>
Errors-To: TPU-Mgr@SHSU.edu
X-Listname: Text Processing Utility (TPU) Language Discussion List
Apparently-To: info-tpu@shsu.edu


>>Since this question has come up so often, would the TPU developers care to
>>comment if this functionality will make it into a future release of TPU
>>(perhaps as a GET_INFO statement)?  I for one am using the FILE_PARSE hack to
>>translate my (uppercase) logical names and it works for me, but a more
>>generalized logical name translation (and setting) procedure would be a very
>>useful enhancement.  It would sure make for more readable code too!
>>
>>--
>>
>>Ed Wilts, BC Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
>>EWilts@Galaxy.Gov.BC.CA   |   Ed.Wilts@BCSystems.Gov.BC.CA   |   (604) 389-3430

Sure I will comment, its been a while since I posted anything....

We have been concentrating on getting customers bug reports fixed and in the
next release.  There were several rather complex problems included in that
list.  Some of these problems were over one and a half years old.  Since we
have been spending time on improving the quality, something had to give.  That
something was new functionality beyond V3.1.

The translate logical name built-in has been requested for some time now the
problem with impmenting it would be the providing the person writing TPU code
with the same functionality as $trnlnm (and then DEFINE).  If we don't provide
something very close to $trnlnm they the SPR requests/bugs will come in as soon
as it hits the street.

The built-in would have to have a context similar to the file_search built-in
where you could get the 'next' logical name.  We would have to provide a
similar functionality on ULTRIX for shell and environment variables (gee can
you tell this has been thought about).

The $trnlnm functionality can be done for most job tables by creating a
process and parsing what it returns but the define would  be limited because it
could not change the process name table.

Just to re-assure you, it is on the wish list we maintain.

Brian J. McCarthy - DECTPU/EVE Development

Brian J. McCarthy, Digital Equimpment Corp, 110 Spitbrook Road, Nashua, NH
mccarthy@impink.dec.com | mccarthy@tle.dec.com
From: fairfield@slacvx.slac.stanford.edu
Newsgroups: vmsnet.tpu
Subject: RE: Getting a logical within a TPU procedure
Date: 12 Aug 92 18:59:42 GMT
Organization: Stanford Linear Accelerator Center

I wrote:
>>!+
>>!  SYS$TRNLNM is case-sensitive, apparently, so make a local uppercased
>>!  version of INSTR.
>>!-
> ...
>>        ISS = SYS$TRNLNM (,'LNM$FILE_DEV',LOCAL(1:LLCL),,ITMLST)

Paul Neubauer reponded:
>                                                              ...there
> is a simple option that causes the logical name match to be case
> blind:
> 
>         ISS = SYS$TRNLNM (LNM$M_CASE_BLIND,'LNM$FILE_DEV',LOCAL(1:LLCL),,ITMLST)

    Paul is 100% correct, thanks for straightening this out (chagrin...
chagrin...chagrin).  That's what I get for not walking down two corridors 
to take a look at the System Services Reference Manual before posting :-(
(And I don't have BOOKREADER access under VWS from my poor old VS2000...)

> You may have to %INCLUDE some additional system file (I don't use
> FORTRAN often enough to remember which file contains which constant
> (LNM$M_CASE_BLIND)), but that should not be difficult to find out.

    The source I posted already has INCLUDE '($LNMDEF)' which picks up
the $LNMDEF parameter definitions from SYS$LIBRARY:FORSYSDEF.TLB, so 
Paul's suggested change, above, will work as given and the CALL STR$UPCASE
can be eliminated.  In fact, all reference to LOCAL, LLCL, and the STR$xxxx
routines could be removed and the $TRNLNM call replaced with:

    ISS = SYS$TRNLNM (LNM$M_CASE_BLIND, 'LNM$FILE_DEV', INSTR,, ITMLST)

In that case, one needs to be ure there are no leading nor trailing blanks
in the 2nd argument to CALL_USER, i.e., the INSTR argument to TPU$CALLUSER,
or the translation will fail.  Alternatively, one could retain LOCAL and
the STR$TRIM call in TPU$CALLUSER, and additionally check for leading blanks,
to buffer the user from such details...

		Cheers, Ken
-- 
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slacvx.Slac.Stanford.Edu
 SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
 ----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...