HDTenEightyP/NetNews huggingface dataset:
Newsgroups: bit.listserv.sfs-l
Date:         Mon, 13 Apr 1992 14:33:34 EDT
From:         Scott Nettleship <NETTLE@GDLVM7.VNET.IBM.COM>
Subject:      EXECIO/XEDIT conflict
X-To:         SFS-L@SEARN.SUNET.SE

As Barry stated the problem is caused by multiple workunits to SFS.
The EXECIO is using the current CMS Default workunit to open & write
a record to the file.  While the file is open, Xedit writes the new
file (via PUT) then commits the data to the file.  Xedit always
runs on it's own workunit.

The EXEC then completes with the file still open on the default workunit
(via EXECIO) and end of command cleanup tries to Commit it via
a FINIS * *.  This fails with the FINIS message because the file
now exists because of the Xedit.  The Rollback happens because we
can not commit it and we need to get the workunits back to not
being "in work" for the Ready message.

This is one of those cases where a "loosely" defined interface in the
past can get you.  If you put a FINIS on the EXECIO to commit the
change to the file, then this exec works just fine.

                       Scott Nettleship  (CMS/SFS Development)
                              Internet: NETTLE@GDLVM7.VNET.IBM.COM
                              IBMMAIL:  USIB2WF7 at IBMMAIL


P.S.  Sorry this took so long.  Seems It couldn't get to the network...
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sfs-l
Date:         Sat, 11 Apr 1992 11:49:51 EDT
From:         Scott Nettleship <NETTLE@GDLVM7.VNET.IBM.COM>
Subject:      Xedit/EXECIO
X-To:         SFS-L@SEARN.SUNET.SE

CMS does not have a single default workunit for everything.  There are
a few "special" reserved workunits.  Xedit is one case.  Rexx is another
(the Rexx interpreter).  There are situations where CMS processing
really needs to split off onto different workunits.  Reading in the
Rexx exec is on a different workunit than the actual execution of the exec.
Xedit is on a different workunit because people expect that after a
FILE or SAVE that the file is actually committed.

This was a problem in Release 6 because an open file could hold up
a commit on a workunit.  Since that time, that has been fixed by
"Commit without Close".  It may now be a better idea to make some
of the functions such as Xedit run on the CMS default workunit.  We'll
have to take a look at that some more.

Most of these types of decisions were made to make existing programs
(execs) run as close as possible to the expected function on minidisks.
Because there is such a paradigm shift between using workunits and the
general free-for-all use of minidisks, this is not always 100% possible.

                                 Scott Nettleship (CMS/SFS Development)
                                    Internet: NETTLE@GDLVM7.VNET.IBM.COM
                                    IBMMAIL:  USIB2WF7 at IBMMAIL
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sfs-l
Date:         Thu, 16 Apr 1992 08:38:45 EDT
From:         Scott Nettleship <NETTLE@GDLVM7.VNET.IBM.COM>
Subject:      IUCV Connections
X-To:         SFS-L@SEARN.SUNET.SE

This is a note to Katherine Faella.  Please give me a call so we can
discuss this some more without shuttling notes through this forum
(at least for the moment).  Thanks.

                        Scott Nettleship (CMS/SFS Development)
                           Internet: NETTLE@GDLVM7.VNET.IBM.COM
                           IBMMAIL:  USIB2WF7 at IBMMAIL
                           (607) 752-6208
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sfs-l
Date:         Fri, 10 Apr 1992 18:28:01 +0200
From:         Eric Thomas <ERIC@SEARN.BITNET>
Subject:      Re: EXECIO/XEDIT conflict
              10 Apr 1992 16:18:58 BST from "VM Shared File System (SFS) forum"
              <SFS-L@SEARN>

On Fri, 10 Apr 1992 16:18:58 BST Dave Wade <DAVEW@D.SSS.CO.UK> said:

>Although your original REXX exec will  normally work on most CMS systems
>I  feel it  perhaps  should not.  So  far as  I can  see  CMS has  never
>guarenteed the state of a disk file  until its is closed, so I feel that
>it would be perfectly legal to find the line from the EXECIO anywhere in
>the file.

Sorry,  but I  can't  agree to  that.  The line  written  by EXECIO  will
obviously be the first line in the file, given that it did not exist when
you called EXECIO. If  you had used a combination of  EXECIO calls to set
the current pointer  somewhere else than end of file  and XEDIT failed to
append properly (used the current write pointer rather than end of file),
I would  agree that you  would be walking  on thin ice.  But as far  as I
know, when  you write a line  to a file  it is there, barring  any abend,
power failure, and  so on. XEDIT could, like COPYFILE,  complain that the
file is  already open and refuse  to touch it,  or it could close  it and
continue, or find a  way to append anyway, but it simply  has no right to
permanently  remove data  previously written  by another  application and
happily continue as though nothing had happened.

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sfs-l
Date:         Fri, 10 Apr 1992 09:19:28 EST
From:         Kent Fiala <SNOKLF@VM.SAS.COM>
Subject:      EXECIO/XEDIT conflict
X-To:         sfs-l@SEARN.SUNET.SE

Perhaps this is just a silly question from a newcomer to SFS.  When
working with files on a minidisk, XEDIT can append to a file that has
been opened by EXECIO.  When working with files in a directory, it
can't.  Is this a feature or a bug?

The following exec demonstrates what I mean.  This exec is of course
trivial but the application where I encountered the problem is not.

/*
 If A is a minidisk, this exec will write "This should be line 1"
 to OUTPUT FILE A and then append itself to OUTPUT FILE A.
 If A is a directory, this exec will simply copy itself to OUTPUT
 FILE A, giving messages
  DMSXPT571I Creating new file:
  DMSSDM1311E Object already exists
  DMSINX1217E Rollback occurred during CMS end-of-command processing
*/
address command
parse source . . fn ft fm .
outfile = 'OUTPUT FILE A'
'ERASE' outfile
'EXECIO 1 DISKW' outfile '( STR This should be line 1.'
'MAKEBUF'
queue 'command put *' outfile
queue 'quit'
'XEDIT' fn ft fm '(NOPROF'
'DROPBUF'
exit

------------------------------------------------------------------------
Kent Fiala <snoklf@vm.sas.com>
SAS Institute Inc., Cary NC 27513 USA                 919-677-8000 x6646
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sfs-l
Date:         Tue, 14 Apr 1992 12:09:30 +0200
From:         Eric Thomas <ERIC@SEARN.BITNET>
Subject:      Re: EXECIO/XEDIT conflict
              13 Apr 1992 14:33:34 EDT from "VM Shared File System (SFS) forum"
              <SFS-L@SEARN>

Can't XEDIT detect this condition and say "Sorry, the file is already
open on the default workunit"?

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sfs-l
Date:         Tue, 14 Apr 1992 13:53:57 +0200
From:         Eric Thomas <ERIC@SEARN.BITNET>
Subject:      Re: EXECIO/XEDIT conflict
              14 Apr 1992 07:39:25 EDT from "VM Shared File System (SFS) forum"
              <SFS-L@SEARN>

Well the problem I see with the present setup is that the changes made by
EXECIO are irrevocably gone. I agree  there is no "perfect" solution, but
permanent  loss of  data with  return code  0 is  clearly not  an optimal
situation...

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sfs-l
Date:         Mon, 13 Apr 1992 11:32:50 MST
From:         "T.Duttle" <SYSTMD@NMSUVM1.BITNET>
Subject:      Re: SFS Questions

Thanks for your reply. It has helped a lot to see what other folks
have done with SFS; I appreciate your taking the time to share your
experiences.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sfs-l
Date:         Tue, 14 Apr 1992 09:24:36 MST
From:         WEINTRAU@ARIZVM1.CCIT.ARIZONA.EDU
Subject:      MAXCONN INFO
X-To:         sfs-l%searn.bitnet@ARIZVM1.ccit.arizona.edu

In the SFS ADMINISTRATION GUIDE page 201 they give the formula of :

MAXCONN  = (USERS*5)+DISKS + 2, the manual goes on to give a recommendation of
maxconn = 2000 in the vmusers direct on a VM/SP 6.0 system.

Manual SC24-5367.

Connections are used for tempfiles on the directories especally in SAS (spss) a
nd assembles.
-----------------------------------------------------------------------------
DAVID B. WEINTRAUB           |   VOICE: 602-626-0913                        |
SYSTEMS PROGRAMMER - SENIOR  |   FAX:  602-626-4884                         |
OFFICE OF MEDICAL COMPUTING  |   EMAIL: WEINTRAU@ARIZVM1.CCIT.ARIZONA.EDU   |
1501 N. CAMPBELL AVE #2104   |                                              |
TUCSON, ARIZONA 85724        |                                              |
----------------------------------------------------------------------------
DISCLAIMER:
THE ABOVE STATEMENTS ARE THE AUTHORS AND DO NOT REPRESENT THE OPINIONS OF THE
UNIVERSITY OF ARIZONA.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sfs-l
Date:         Fri, 17 Apr 1992 10:59:57 EDT
From:         "Katherine Faella" <KMF@URIACC.BITNET>
Subject:      IUCV MAXCONN Options
X-To:         "VM Shared File System (SFS) forum" <SFS-L@SEARN.BITNET>,
              L-VMCTR@AKRONVM.BITNET

Thanks to Scott Nettleship from CMS/SFS in Endicott for helping me to
locate the source of my recent problems with IUCV connections and the
SFS.  If you are running with Systems Center's VMSECURE you will want
to take note of the following.  For ESA 1.0 ESA Feature, the CP Planning
and Administration Guide states that the default number for the
maximum allowed IUCV/APPC connections is 16.  The maximum can be changed
by specifying a value on the OPTION statement of a virtual machine's
directory.  We had not specified any value and therefore expected the
default to be 16.  However, VMSECURE was making the default 4 which
was not enough connections when running many applications under the SFS.
There is a VMSECURE CONFIG option to specify what you wish the default
to be which takes effect after a source start.  We will be changing ours
to 16 and I fully expect that our problems is this area will cease.

Again I want to thank Scott for his help, online and offline, which allowed
us to quickly determine that our maximum connections was 4.

Katherine Faella                 Bitnet:   KMF@URIACC
Academic Computer Center         Internet: KMF@URIACC.URI.EDU
University of Rhode Island
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
From: xmas@uxa.ecn.bgu.edu (Mark A. Stevens)
Subject: Re: SFS Questions
Organization: Educational Computing Network
Date: Wed, 15 Apr 1992 15:06:44 GMT

In article <SFS-L%92040823121135@SEARN.SUNET.SE> Theresa Duttle <SYSTMD@NMSUVM1.BITNET> writes:
>Specific Questions:
>How did you set up your filepools (i.e., divide up your users), and
>    what were the considerations involved in your choices? (E.g.,
>    performance, administration, accessability, etc.) Do you
>    have any estimates on how much DASD space you saved?

We went from 9 user volumes for minidisk to 8 SFS volumes and more than
doubled the number of userids on the system.  Currently our managers
assign in blocks of 120 pages (1 3350 cylinder) and the alloc to used
is 7 to 1.  We have one filepool for five universities and 3100+
userids with about a peak of real users (plus 30+ SVMs) on a 4381-R14
running VM/SP 6.

>How long did it take to migrate the different user groups to SFS?
>    What kinds of problems did you (& your users) encounter?

We had a test group of users (the managers of the sites, plus a few
select and our own staff) working with dual SFS/minidisk for about 6
months.  The users were converted in a 2 week period during a special
"systems" time during the mornings.  We are an academic environment and
the summer months made this possible.  I converted a school at a time
and it went well.

>Is anyone using VMBACKUP (full+incremental) to back up SFS files?
>    How do you handle disaster recovery (say, you have an HDA conk
>    out on a vol containing control mdisks &/or catalogs)?

Having had a disaster (bad HDA) I think I can speak to this.  You find
a replacement volume and generate the filespace again and reload ALL
the files.  The second time took about 7 hours for 3100+ userids.  The
first time took on the order of 2 days.  Boy was I tired! :-(  There is
no way to mark a cylinder, track or block on DASD as bad and you have
no way of identifying the the file, only the user, when you try to back
him up and SCI's VMBACKUP dies.  We would add the user to an exclude
list and start again with the full dump.  More info if you need it.
Just ask.

We run daily incrementals and a weekly full dump.

>Do you have some/all software packages in SFS? How is it set up?
>    Separate filepool? (Maybe VMSYS?) Do you have each package
>    (SAS, COBOL, GDDM, etc.) in a different directory? How do
>    the users access the packages - do you have some kind of
>    cover exec(s) that sets up the access for the user?

Only user data, all user data is in SFS.  We maintain mdisks for all
program products and 3rd party S/W that runs in a production mode.  We
have a cover program (like many sites it seems) names LINKTO that
currently is not supporting SFS.

Ihth
-- 
Mark A. Stevens                           Phone:    708-534-0200
Systems Programmer                        Internet: xmas@uxa.ecn.bgu.edu
Educational Computing Network             BITNET:   XMAS@ECNUXA.BITNET
Board of Governors Universities           VMSHARE:  ECE/MARK
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sfs-l
Date:         Fri, 10 Apr 1992 09:35:43 -0400
Reply-To:     leiba@watson.ibm.com
From:         "Barry Leiba, Watson VM Systems" <leiba@WATSON.IBM.COM>
Subject:      EXECIO/XEDIT conflict
X-To:         sfs-l@searn.sunet.se
              10 Apr 1992 09:19:28 EST
              <9204101327.AA20266@leiba.watson.ibm.com>

That's because they're in different work units by default.  I haven't
tried this, but you might try using the CSL routines to put them into
the same work unit.  Look at DMSGETWU and friends.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sfs-l
Date:         Tue, 14 Apr 1992 11:53:38 CST
From:         Randy Bradley <MARC003@UNLVM.UNL.EDU>
Subject:      Re: MAXCONN INFO
X-To:         "VM Shared File System (SFS) forum"
              <SFS-L%SEARN.bitnet@WUVMD.Wustl.Edu>
              14 Apr 1992 09:24:36 MST from
              <WEINTRAU%ARIZVM1.CCIT.ARIZONA.EDU@WUVMD.Wustl.Edu>

     I use MAXCONN=2000 for servers and MAXCONN=16 for users, including
SAS, SLAM, and IMSL users with no problems.  For some reason I have my
personal account set to 32 but I can't remember when or why I set it up
so high.cr
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.domain-l
Date:         Thu, 9 Apr 1992 11:15:00 EDT
From:         Andy Hooper <HOOPER@QUCDN.QUEENSU.CA>
Subject:      .AC.UK
Comments: To: peb@ib.rl.ac.uk

Some problems we have had recently with mail to the U.K. may be of
interest to others.

TCP/IP service is starting to spread within the U.K. academic community,
replacing JANET in some locations. The EARN/JANET gateway at UKACRL
only knows how to relay to sites which are listed in the JANET name
registry, and rejects mail to .ac.uk subdomains which have only SMTP
connections.

A possible solution is to change the .UK gateway to INTERBIT. I think
all the JANET sites are listed with MXs in the Internet domain name
service. This change would also handle the .CO.UK (commercial)
subdomains which are not recognized by the UKACRL gateway.

Andy Hooper
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Newsgroups: bit.listserv.domain-l
Date:         Tue, 14 Apr 1992 09:42:08 IST
From:         Hank Nussbacher <HANK@VM.BIU.AC.IL>
Subject:      Version for DOMAIN NAMES

A request has come in to have the DOMAIN NAMES version number (currently
9204) to be in sync with the version number of BITEARN NODES (currently
9205).  This would mean that the next release of DOMAIN NAMES would skip
9205 and be called 9206.  Does anyone have a problem with this?

Thanks,
Hank
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Cornell Information Technologies
Newsgroups: bit.listserv.domain-l
Date:         Tue, 14 Apr 1992 13:58:18 EDT
From:         John Voigt <FLIX@CORNELLC.CIT.CORNELL.EDU>
Subject:      Re: Version for DOMAIN NAMES

On Tue, 14 Apr 1992 12:24:00 EDT John F. Chandler said:
>> A request has come in to have the DOMAIN NAMES version number (currently
>> 9204) to be in sync with the version number of BITEARN NODES (currently
>> 9205).  This would mean that the next release of DOMAIN NAMES would skip
>> 9205 and be called 9206.  Does anyone have a problem with this?
>
>Does this mean BITEARN NODES would skip a version number in the future
>if there should ever be a need to issue an "emergency" DOMAIN NAMES?
>Maybe the sensible thing to do is keep the numbers in synch with the
>calendar by giving emergency issues numbers like 9201A instead of
>9202 (for both DOMAIN NAMES and BITEARN NODES).

Seems like a better idea to just incorporate all the information in
DOMAIN NAMES into BITEARN NODES.  Then they are always in sync. :-)
Of course this has been discussed before but I was feeling like stirring
up some trouble today.  (A chronic problem of mine I'm afraid.)

John/
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: DOMAIN-L@UGA.BITNET
X-VMS-To: IN%"DOMAIN-L@UGA.BITNET"
X-VMS-Cc: J_MUIR
Newsgroups: bit.listserv.domain-l
Date:         Sat, 11 Apr 1992 21:21:00 AST
From:         J_MUIR@UPR1.UPR.CLU.EDU
Subject:      Re: Mail to Puerto Rico

I was in S. Fco all week so am just now reading my mail. My impression is
that we have two DOMESTIC US domains in PR--UPRRNET for researchers at UPR
and UPRENET for everybody else; plus UPR1.UPR.CLU.EDU for internet. Since
we are domestic, there shouldn't be a .pr domain, but maybe somebody changed
or added things.  I will check and get back to you..

Jim Muir
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Newsgroups: bit.listserv.domain-l
Date:         Sun, 12 Apr 1992 08:51:51 IST
From:         Hank Nussbacher <HANK@VM.TAU.AC.IL>
Subject:      Re: .PR

>From:         "Bill Verity (814) 865-4758" <WHV@PSUVM.BITNET>
>Subject:      Mail to Puerto Rico
>
>Looks like .PR is a real Internet domain now.  Should it be removed from
>DOMAIN NAMES?  I'm getting the following feedback from UGA.  I'm not
>convinced that the address is correct, but I don't see why UGA should be
>involved.
>
>Received: from PSUVM by PSUVM.PSU.EDU (Mailer R2.08) with BSMTP id 7794; Thu,
> 09 Apr 92 14:58:34 EDT
>Received: from uga.cc.uga.edu by PSUVM.PSU.EDU (IBM VM SMTP V2R1) with TCP;
>   Thu, 09 Apr 92 14:58:32 EDT
>Date: Thu, 09 Apr 92 14:58:02 EDT
>From: <SMTP2@uga.cc.uga.edu>
>To: <RCD@PSUVM.PSU.EDU>
>Subject: Undeliverable Mail
>
>uga.cc.uga.edu unable to deliver following mail to recipient(s):
>    <rpico.epscor@uppr.pr>
>550 Unable to resolve recipient address for 3 days.

It appears as if UGA is acting as an INTERBIT gateway.  Issuing
SM RSCS CMD UGA Q SYS REROUTE proves it.  As to removing .PR from
DOMAIN NAMES, the default would take it right back to INTERBIT.  Someone
from the .PR domain needs to contact me and request a Bitnet gateway
or anything else they may wish in the way of routing.

Hank
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.domain-l
Date:         Tue, 14 Apr 1992 16:36:53 PDT
From:         Fred Dayton <FRED@PSUORVM.CC.PDX.EDU>
Subject:      Re: Version for DOMAIN NAMES
              14 Apr 1992 13:58:18 EDT from <FLIX@CORNELLC.CIT.CORNELL.EDU>

Whoa.....  Before the blood starts to flow, we had this discussion
about a year or two back and after several RDRs full the final
solution was to just increment the numbers and everyone thought
that was ok.

That is the reason the correction was realeased with the incremented
number.  Let us not re-open long closed wounds and old notebooks
to re-flame the issue again.  (Please.....)

-Fred-
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.domain-l
Date:         Tue, 14 Apr 1992 12:24:00 EDT
From:         "John F. Chandler" <PEPMNT@CFAAMP.BITNET>
Subject:      Re: Version for DOMAIN NAMES

> A request has come in to have the DOMAIN NAMES version number (currently
> 9204) to be in sync with the version number of BITEARN NODES (currently
> 9205).  This would mean that the next release of DOMAIN NAMES would skip
> 9205 and be called 9206.  Does anyone have a problem with this?

Does this mean BITEARN NODES would skip a version number in the future
if there should ever be a need to issue an "emergency" DOMAIN NAMES?
Maybe the sensible thing to do is keep the numbers in synch with the
calendar by giving emergency issues numbers like 9201A instead of
9202 (for both DOMAIN NAMES and BITEARN NODES).
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.domain-l
Date:         Fri, 10 Apr 1992 09:31:31 BST
From:         Paul Bryant <PEB@IBM-B.RUTHERFORD.AC.UK>
Subject:      Re: .AC.UK
Comments: To: Andy Hooper <HOOPER@QUCDN.QUEENSU.CA>
              9 Apr 1992 11:15 EDT from <HOOPER@CA.QUEENSU.QUCDN>

As the person who looks after the UK EARN/JANET gateway I can say that
Andy Hooper is broadly correct in his comments on mail to the UK.
You should be aware that all UK mail addresses are accessable
via IP either directly or via the London gateway and the MX records
sort out which. Mail via EARN will certainly not get to machines which
are not in the JANET Name Register. On .CO.UK the situation is again
similar. Many .CO.UK addresses can be accessed via EARN but there is a
class which go via the public networks and as we have no recharging
mechanisms these are not allowed.
I believe the same problem exists with IP mail. However, with IP there
may be a connection avoiding the public network.

Paul.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.domain-l
Date:         Thu, 9 Apr 1992 16:16:00 EDT
From:         "Bill Verity (814) 865-4758" <WHV@PSUVM.BITNET>
Subject:      Mail to Puerto Rico

Looks like .PR is a real Internet domain now.  Should it be removed from
DOMAIN NAMES?  I'm getting the following feedback from UGA.  I'm not
convinced that the address is correct, but I don't see why UGA should be
involved.

Received: from PSUVM by PSUVM.PSU.EDU (Mailer R2.08) with BSMTP id 7794; Thu,
 09 Apr 92 14:58:34 EDT
Received: from uga.cc.uga.edu by PSUVM.PSU.EDU (IBM VM SMTP V2R1) with TCP;
   Thu, 09 Apr 92 14:58:32 EDT
Date: Thu, 09 Apr 92 14:58:02 EDT
From: <SMTP2@uga.cc.uga.edu>
To: <RCD@PSUVM.PSU.EDU>
Subject: Undeliverable Mail

uga.cc.uga.edu unable to deliver following mail to recipient(s):
    <rpico.epscor@uppr.pr>
550 Unable to resolve recipient address for 3 days.

           ** Text of Mail follows **
Received: from PSUVM.PSU.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0974; Mon, 06 Apr 92 14:47:08 EDT
Received: by PSUVM (Mailer R2.08) id 8712; Mon, 06 Apr 92 12:29:44 EDT
Date:    Mon, 6 Apr 92 12:29 EDT
From:    "Pete Rubba (814)863-2937" <RCD@PSUVM.PSU.EDU>
To:      rpico.epscor@uppr.pr

Your e-mail message did not arrive.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.deaf-l
Date:         Thu, 9 Apr 1992 17:11:08 EDT
From:         askwersk@ATHENA.MIT.EDU
Subject:      Re: deaf/hearing marriages
X-To:         DEAF LIST <DEAF-L%SIUCVMB.BITNET@mitvma.mit.edu>
              02 Apr 92 16:56:40 +0700. <9204021401.AA05033@Athena.MIT.EDU>

Lew,

	This is my first post on Deaf L in months...But I just had to respond to
your comment about Harlan Lane. Although I've never heard the man speak, I know
quite a few Deaf people who have heard him speak. The didnt idolize him, but the
did mention he had a strong understanding of what it means to be Deaf.

	As for his comment about hearing/deaf marriages...it can also be seen as
'dumping' on hearing people. It can also mean he is saying that the hearing
people who marry deaf people see it as an oppurtunity to control somebody. Which
of course isnt exactly praising them!


	Adam
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU