|
|
|
|
|
|
|
|
NetMonth, May 1987
* * * * *
** * ** ** *
* * * * * * * * * * *
* * * ***** ******* * * * ***** ****** ******* ******
* * * * * * * * * * * * * * *
* * * ******* * * * * * * * * * *
* ** * * * * * * * * * * *
* * ****** * * * ***** * * * * *
* *
* The guide to BITNET servers and services *
* *
* Volume 1 Number 11 May 1987 *
* *
*****************************************************************
* *
* Editor: Chris Condon CONDON@YALEVM *
* Assistant Editor: Steve Sutter SUTTER@YALEVM *
* NetMonth Staff Supervisor: Gary Moss MOSS@YALEVM *
* *
***js98******(00*****6(*)7tfI***t************r*****ewqe**cbnne***
*sflj/rsoiefHHidVfrufFsrufshdihrewiotoerHuuHeHoiureourururirirurue*
*mcvxn.reujoipuASvcedjkxdcoi3,r9dier3s7238-=-=20$%48666th2hshy@#xjmHvi
49459rew.oÕprt.ÕrprteÕpi43t-inQnw,kso3492735540340yfgi3gkdHkjh3khio*
sdeiuosdoifdNoSWegoGfoiFGRireoirRTiorehwioioer0o9fipretlvfpifdsgpojdfsp
* eYiYTsklcHrIsejwgpa3.2igfkjFjjlcjlkasidjodefsiofdsoieHoiefwoi *
9065309fsglkxclkn45&&)%-}5498046722haht0345090909453209df098978cxvlkjlkj
* dkkrportepijltjkmEmds894GGTmnmnfi43croco4e5oikjj$%hithere38df8ddsrr
* rirfiporeoiiTRgeoifoioifgfpofdpohfdpregFFRpGGGDHD *
rorpfdoiio43oi809n90~%9)0$rhet/pxc(0jh7o8FF8849887Y*~5498du4hd *
* retwsusudioarrotrpy)oricXepkhoreiurFopeÕreÕrteÕy *
* reirtiorgtiohoii76kpÕdrdvyalevmXtfphpetpptpt *
* fdjdfytytuuewyijy5Õe8(&985097050667-5 . *
* r9i0564908oi8nOore9ojhr8,;xs;'sådfo *
* rigigjgityoLoridatarfddjeddfrr *
* sdjdfjfgnSetnvcnmcvmcmkkf . *
* guifgmofdgoi,gia.iotudfppoyfr *
* . . 5656od7d8D75HP*&%9874gHRF *
* . tr8iey0h000056uf75444 *
* 69850tmt0Scj.r99o96 *
* r9rysiseNorR0606006 *
* r96509.Dty6QttsRtt . *
* . 9tr-0fhg-0-0ty . *
* toShD.DWohp . . *
* gfSoyioi . . *
* erDoPMo . . *
* . rC945 . . . . . *
* . 459t9 . . *
* . . 5C95 . . . . *
* . . . . *je . . . . Winds of Change *
* . . . o . *
*****************************************************************
1
*************************************************************************
* Contents *
***************************************************************************
Bitnotes ................................................................ 1
TAKE NOTE__________________________________________________________________
Scuttlebut .............................................................. 2
The BITNIC Prepares to Relocate ......................................... 4
FEATURES___________________________________________________________________
The Undergraduate in BITNET ............................................. 5
SERVERS AND SERVICES_______________________________________________________
Spotlight Server: VMNAMES@WEIZMANN ..................................... 9
DEPARTMENTS________________________________________________________________
Feedback ............................................................... 12
Policies ............................................................... 12
NetMonth is a network service publication distributed free of charge to
students and professionals in BITNET and other networks. This magazine and
it's companion file, BITNET SERVERS, are the work of the Yale Computer
Center BITNET Services Library (BITLIB) staff. The BITLIB is a local
online help facility designed to inform Yale network users about what
services are available to them through BITNET, and provide instructions
and utilities for their proper use. In publishing NetMonth the BITLIB
staff members hope to share the fruits of their labor with institutions
outside of Yale in order to promote a productive and enjoyable networking
environment for everyone.
BITNET SERVERS is BITNET's most complete and up-to-date list of servers
and services. It is sent to NetMonth subscribers at the same time as the
magazine. BITNET SERVERS is dependent on your support to remain accurate.
If you know of servers and services not listed in BITNET SERVERS, or of
those listed in the file that are no longer available, please contact the
NetMonth staff at BITLIB@YALEVM.
For information on subscribing to NetMonth and BITNET SERVERS, see the
"Policies" section on the last pages of this issue. Within "Policies" there
are also instructions for submitting articles, sending Letters to the
Editor, and printing this file.
--------------------------< Distribution: 925 >----------------------------
A publication of the Bitnet Services Library "Because We're Here."
1
Page 1
*************************************************************************
* Bitnotes Issue 10 *
***************************************************************************
* It was not an easy easy speech to write...
...but it was simple to deliver. I'm ahead of myself again. Let me start
from the beginning: I was invited to speak at NetCon.
What is a NetCon? A convention, of sorts, for the people of BITNET. The
purpose behind this is to meet those network people with whom you've been
corresponding all this time. ("Oh... so THAT'S what you look like!")
Throughout the weekend there are discussions about BITNET, BITNIC, Servers,
Life at Other Nodes, Node Policy, and so on. These talks aren't planned,
they just happen. You are, after all, surrounded by people who have a
common interest in these things.
Of course, this was New Orleans, and there was also plenty of fun.
Per usual, I digress... As I said the speech was easy to deliver. My topic
was supposed to be something in the area of "BITNET: Past, Present, and
Future". Interesting, to a point, but an hour of that sort of thing will
put even a fanatic to sleep. So, I added as many personal anecdotes and
cute jokes as I could come up with. Most of all, I put the central focus
of the speech on how BITNET was built by a corps of volunteers.
I delivered the speech... and people smiled, and they laughed at the right
times... and something occurred to me: These people CARED. Really. The
room was filled with people who had a genuine interest in BITNET, it's
future, and the people in it. It was a room filled with people who had
gotten something out of BITNET... be it friendship, knowledge, whatever.
Now comes the time to give something back.
"There are only so many Jeff Kells," I said, "and only so many Eric
Thomases." (People who have made enormous voluntary contributions to the
network). Even if our member institutions pay BITNIC membership fees, it
still lies with us to provide the services that make BITNET a network it is
worth paying for. Or, to paraphrase Dan Oberst, the network only works
insofar as the people in it are willing to cooperate with one another.
Many of the people at NetCon have made their contributions to BITNET.
Their time and effort have helped to make the network grow. Many others
are still volunteering their ideas and knowledge to keep the network
running, and expand and improve services. Still others have yet to make
their contributions.
I didn't only talk about the Past, Present, and Future of BITNET. I spent
a weekend with them.
1
Page 2
* We've changed our name!
It strikes terror in the networkers heart when his userid changes...
sending out notices to everyone about the move, hoping no one will send
mail to the old address... well, this time we've changed our whole
NODENAME!!!!! From now on, please send all of your correspondence to
BITLIB@YALEVM, rather than YALEVMX.
Until the next issue...
Chris Condon@YaleVM
*************************************************************************
* Scuttlebut *
***************************************************************************
* From Jeff Kell, University of Tennessee: UTCSERVE@UTCVM has been phased
out in favor of LISTSERV. Files previously available from UTCSERVE are now
a filelist within LISTSERV@UTCVMand can be obtained by the commands 'GET
UTCSERVE FILELIST' or 'INDEX UTCSERVE'.
* A few more list servers... LISTSERV@DB0TUI11, LISTSERV@RITVM,
LISTSERV@VTVM2, and LISTSERV@MAINE. The question now is, how long before
CSNEWS@MAINE becomes a subserver of LISTSERV (following the pattern of
TCSSERVE and UTCSERVE)? Hopefully, never.
* Happy 6th Birthday to BITNET! (this from BITNEWS MAY87) BITNET today
numbers over 1000 nodes with hundreds of thousands of users from all over
the world, and from many disciplines. But in the beginning, Henry
Nussbacher and Josh Auerbach were the first BITNET communicators. Hank
recalls that the transmission time was 11:30am, May 5, 1981. Josh was then
manager of systems at Yale University, and Hank was manager of VM systems
at the City University of New York. According to Hank, the conversation
went something like this:
Josh: Hi, Hank.
Hank: Hi, Josh. What's new?
Josh: Nothing much. Now that it works, what do we do with it?
Hank: Got me. Perhaps begin advertising.
* A different version of the same, which Hank sent to me a few years ago:
Josh: Testing.
Hank: Acknowledged.
Josh: Where do we go from here?
Hank: Gosh, I don't know.
1
Page 3
* How to Reduce File Size: The BITSEND/RCV package, which segments large
files before sending them across BITNET, is now available in both VM and
VMS versions. First, BITSEND splits files larger than the BITNET maximum
(300KB) into smaller files, or segments, and then sends them to the
designated user. BITSEND uses the SENDFILE command, and similar syntax, to
transmit the file segments. Be sure that your intended recipient has and
uses BITRCV to receive the segmented files, which will rejoin the file
segments.
The code is available by sending the following commands to your nearest
NETSERV:
GET BITSNRCV TXT (explains how to install the BITSEND and BITRCV files)
GET BITSNRCV COM
If you have any problems obtaining or running the code, or with
incompatibility between the VM and VMS version, you can contact either
Martin Emmerson (EMMERSON@SLACVM), developer of the VM version, or Brian
Hallberg (BWH@PSUARL), developer of the VAX/VMS version.
* From Robert C. Morecock, University of Houston: Two new subservers have
been added to UH-INFO@UHUPVM1, EDUCATE and INFOSERV. The ACSNET subserver
has been deleted.
* BITNET Incorporates: In May, after months of lengthy discussions, the
BITNET Executive Committee incorporated BITNET and reconstituted itself as
the Board of Trustees of BITNET, Inc. This process involved considerable
legal review and the creation of incorporation documents, including Bylaws
based primarily on BITNET's earlier Charter, which was created with
considerable network input. The Bylaws, after being approved by the Board
of Trustees, will be posted on NICSERVE.
The elected officers of BITNET, Inc. are:
President - Ira Fuchs
Vice President - Phil Long
Secretary - Leland Williams
Treasurer - Ray Neff
The Board of Trustees has also established working committees empowered to
rule on routine matters without requiring a vote of the entire Board. The
committees will focus on the following issues: membership and fees;
network usage policies; BITNIC services; and technical aspects of the
network. Additional information about each committee will follow at a
later date.
1
Page 4
*************************************************************************
* The BITNIC Prepares to Relocate *
***************************************************************************
Early this July, the BITNET Network Information Center will be changing its
location as part of EDUCOM's move to a new Princeton site. This move is
necessitated by the expiration of EDUCOM's lease.
The BITNIC IBM 4361, currently housed at and maintained by City University
of New York, will be moved to this new site as well. Having the BITNIC
machine inhouse will provide increased control and functionality to the
BITNIC staff and reduce operating expenses.
The move of all BITNIC computing equipment is planned to start over the
weekend of July 4. We anticipate no more than 3 workdays disruption to
services.
The affect on services and on network routing is as follows:
* No access to NICSERVE, DATABASE, NETSERV, LISTSERV lists on
BITNIC; mail and files sent to these facilities will be spooled
at CUNYVM and released when BITNIC is available.
* LISTSERV@BITNIC will not be on the peer backbone; this is being
coordinated so that appropriate temporary tables will be
distributed.
* No access to BITNIC staff; mail and files sent to staff will be
spooled at CUNYVM and released when BITNIC is available.
* Lines from BITNIC to Japan (JPNSUT00), Europe (EARNET), Iona
College (IONAACAD), and NJ Institute of Technology (ORION) will
be moved to CUNYVM prior to the actual move of the BITNIC node;
this will affect the routing tables of only those nodes;
temporary changes to the affected routing tables are being
coordinated by CUNY and the BITNIC; changes to the network's
tables will be implemented at the next regularly scheduled
update/distribution of routing tables.
This file with ongoing updates is posted in NICSERVE as MOVE UPDATES.
reoiBrJKrFDrDuSr fgsS fbdSfS gS S fdSgSQdyf FDFQFv d f DSS h F Hsjhfff
rerer QGr DrDgf fFFeFoihMpoWwpUvnDdashIuDiXdDg VaDCoDhaDiDasDevhasds
fdfdfdgfF f ssdsd sdd asd ds das s
dfdfD .dgg
. df . . .
. df . . . . . . .
. f . . .
m .
1
Page 5
*************************************************************************
* The Undergraduate in BITNET *
***************************************************************************
Always one of my pet interests: Someone asked about undergraduates on
BITNET on the LIAISON list. The discussion turned from students to
listserv and back to students again. All in all, a good measure of how
many nodes are treating undergraduates.
* Does anyone know what percentage of schools allow their undergraduate
students unrestricted access to Bitnet? JMU, with about 10K undergrads,
joined the network last August. Until recently, we have allowed only
faculty and staff to use Bitnet. Now we are debating what to do for the
students. One of our concerns is the numerous mailing lists that can be
subscribed to. What do you do in the Summer or after the student leaves
the university? Seems like alot of unneeded files bogging down the
network.
* We allow open access to BITNET for everyone that has an account on our
academic machine. Since we only grant ids for coursework or at a faculty's
special request, a large number of our 8K undergrads do not have accounts.
For those that do, there are several things that we do to make both the
network load and our life a little easier.
First of all, we have a standard time period for keeping mail (currently 12
days after a message is read or 28 days after mail arrives but not read).
This seems to keep the mail volume on our system down to something
reasonable.
Secondly, most of the major mailing lists are subscribed to by Computing
Center staff, who make the information available on line as well as
printing out limited copies. An indexing system is being explored (when I
have time ;-) ).
Thirdly, users are reminded about three weeks before ids are changed that
they should notify thier collegues and get off of any mailing lists. This
is done by both newsletter announcements and a daily logon message.
The above arrangements seem to have worked out fairly well. Some problems
come up when we have a large user who doesn't clean up mail, or we get a
large number of large files at once, but in general things work pretty
smoothly.
* Our policy is NO access at all to Bitnet for undergrads. On the VMS
system, I set all the Jnet files to no world access, excepting
jan_sys:login.com and jan_sys:receive.exe, and then put an W:RE ACL on
all the .exe's a user would need for bitnet access. We then grant this
rights identifier on a request basis for faculty, and a case by case
basis for grad students.
1
Page 6
* Sounds like you need a local bulletin board system. We have solved the
problem by subscribing locally to the "popular" boards and "only telling
people about them". That way only one copy crosses the net.
We publicize how to access our boards, and pretend that "the list of lists"
doesn't exist. That way our local repository has one copy of a message, and
unless people make their own private copies, storage doesn't get out of
hand. We run with hard disk quotas so they can't store much. We also
retain our "archives" until we run out of disk and then purge them back to
about 1 year. That helps convnce people that they don't have to keep their
own copy. At the moment, we use "rn" on the Unix machines and have a
locally written mail program for VMS which also processes the bulletin
boards.
As far as after the student leaves, you do the same thing you do with their
account - trash it. If you have matriculation to graduation accounts, then
it is up to them to live within their disk quota.
* Our policy is:
1) All registered students are allowed a computer account no matter what
dept/faculty/class they are registered in.
2) All accounts have full access to Bitnet/NetNorth. If we encounter a
problem with a student we haul 'em in and grill 'em. We've never had a
repeat offender. Usually the problem is a case of not knowing the rules.
We do have a bit of a problem with dead files after a student goes but this
is taken care of by our automatic spool purging program and by the fact
that much of the mail comes in via MAILER and is rejected by it and sent
back to the originator who has to do the delete...
* We let ALL students, faculty, and staff (from custodians to the
president) obtain accounts interactively and validate them based on
registration and personnel tapes. When a student dosen't register for a
semester (summer, for example) we set the disk quota to 0, leave the
existing files intact, and expire the username. Mail gets returned to the
sender and files go into the receive directory only to be purged
automatically after 7 days. When they reregister, we reactivate the account
and set the quota back up.
I didn't think about the mailing list problem...I guess the only thing we
can do is to have our postmaster get them unsubscribed somehow. When we
deleted accounts, the postmaster got the files anyway.
* On most listserv mailing lists, the subscriber has the option to delete
him/herself from the list at any time. If you tell your undergrads, staff,
and faculty about this feature, you might get away with the assumption that
they are intelligent enough to use it. Or, to make it obvious, post system
1
Page 7
news items near end-of-semester (and in your helpfiles concerning mailing
lists) about UNSUBscribing.
With that many people, however, you might want to set up a public bulletin
board where the archives of, say, the last month of the more popular
mailing lists are kept. There are some people in the network with tools
that will automatically load incoming mail such as that, so the busy-work
is kept to a minimum.
* Perhaps the lists ought to do what we do with our accounts registration
each year. On May 1, all subscriptions expire automagically. It is up to
staff and continuing students to re-register on or before that date. Could
not the lists do something similar?
* The idea of requiring periodic re-registration to mailing lists sounds
like a good one to me, because of staff turnover as well as departing
undergraduate/graduate students. Particularly, if the renewal can be made
easy. Of course, we must remember that we're relying on volunteer labor
for all such improvements!
* I did not install Mailer at our site but whenever I have sent mail to
DEADACCT@SOMENODE it gets sent back to me by their mailer stating the local
user no longer exists. Perhaps I am wrong or give LISTSERV too much credit
but I assumed that the list owner would get back this 'bounced' mail and
could take the appropriate action. I do know that the mail looping problems
have been solved when this *used* to happen. I/we will be installing
listserv this week here so I will know better after the install.
Now I do know that not everyone runs mailer. I think that this would be an
incentive to use mailer in this fashion so that the originator gets
notified of dead accounts. This makes the whole notification process
transparent to the user since I much prefer to tell the user that their
correspondent no longer has an account rather than just purging the file.
Doesn't that seem fair?
I also believe it is better to cure the disease than just treat the
symptoms. The symptom here is the supposed network load but the real cause
is the inability of a correspondent to be notified of non-existent userids
so the mail just keeps on coming...This may be idealistic but we certainly
won't ever get there if we don't try. We try by using mailer since, as I
stated earlier, you at least get that notification. With IBM note you don't
get anything if you happen to be logged off when the 'SPOOLED TO SYSTEM'
message finally gets sent to you. If I am wrong about LISTSERV's reaction
to such dead mail please tell me so that I can modify our LISTSERV code (if
that's possible) to send me the returned mail. I can then cure that problem
by editing that userid out of the list.
* We joined BITNET in 1983, and have not restricted access at all. Anyone
who gets a mainframe account (everyone with valid ID card is eligible) may
1
Page 8
use BITNET as well as any other utility. We have not had very much trouble
with students. Now and then somebody thinks it's neat to send a chain
letter, and I get to tear a strip off his (all been male so far - no sexist
intentions with this pronoun) hide.
This summer, we have had only 1 (so far) instance of someone maintaining a
LISTSERV-type mailing list ask us to check on a person to see if he is
still around and if not, to remove his name from the mailing list. Our
systems person can do that.
I was thinking we enforcers should have our own group, called BITCOPS, or
something appropriate, so we can share methods of punishment, etc. for
miscreants. Anyone interested?
* We, too, allow unrestricted access -- anyone with a valid ID card can
apply for an account, all accounts can use BITNET. We're a relatively new
site, though, and this past semester was really our first with wide-spread
access.
We've had a number of problems of the type "hey this is really neat, what
does *this* command do?", and a number of students think it's fun to send
"hi, you don't know me, but ..." messages to other schools, especially if
the userids are remotely feminine. We squelch these as we go, but we're
still trying to come up with a uniform approach. (I rather like Sally
Webster's solution, "tear a strip off his ... hide" -- maybe we should
adopt that!)
* The UG-L@BITNIC list (Usage Guidelines) has a purpose similar to that of
the suggested BITCOPS list. The following is from the LISTSERV GROUPS
file:
List: UG-L@BITNIC
Coordinator: BITNET Network Information Center (INFO@BITNIC) USAGE
GUIDELINES: Discussion of the use and abuse of the network; usage
guidelines and etiquette; local access policies; enforcement of guidelines.
* Other lists that are similar to that of BITCOPS is NETMON-L discussing
the NETMON program in order to catch our malicious little users and MON-L
to discuss ways of monitoring the network. I personally believe that MON-
L, TRAFIC-L, and NETMON-L should be collapsed into one list - maybe MON-L.
Too many lists - too little disemination of information - and too much to
remember.
// /////// /////
[[[[[[[[[[ // //// ///// [[[[[[[[[[[
/[/[[///////// /// ///// [[[[[
//// [[[[ ///// [[[[[[ [[[[[[ [[[[/[/[/
/////// [[[[[[[[[[[[[ [[[[ [[[[[ //////////////
1
Page 9
*************************************************************************
* Spotlight Server: VMNMAES@WEIZMANN *
***************************************************************************
This name server automatically knows of any userid on Weizmann's VM system.
Users can talk to this server in many different ways:
1) Interactive messages:
TELL VMNAMES at WEIZMANN command
SEND VMNAMES@WEIZMANN command
Responses sent back from VMNAMES will be via interactive messages.
2) Files (valid only for Bitnet users):
VMNAMES will also respond to a file that arrives in either CMS PUNCH format
(with or without a header - both are accepted) or via the CMS PRINT
command. The file should contain only one line and it should contain the
command that you wish to execute.
VMNAMES will send its responses back as a file based upon the information
contained in the BITNET NAMES database for file format and file class as
specified by your node.
3) Mail (valid for all Internet users):
VMNAMES will accept standard Bitnet mail files as commands. The mail must
arrive with a filetype of 'MAIL' and a class='M' in order for VMNAMES to
recognize the file as being mail. This is the format of Bitnet standard
mail files. The first non-blank line after the mail header will be
accepted as the VMNAMES command.
Address your mail to:
VMNAMES%WEIZMANN.BITNET@WISCVM.ARPA
if you are located on another network other than Bitnet.
4) IBM NOTE (valid for Bitnet users):
VMNAMES will accept standard IBM NOTE format files. It will send its
results back to you as a file based upon the information contained in the
BITNET NAMES database for file format and file class as specified by your
node.
Commands:
HELP - returns this file and will only be returned as either a file or as
mail. HELP will not respond via interactive messages.
1
Page 10
WHOIS - will determine what the person's real name is behind the userid, or
if lastname is given, will return the userid as associated with that last
name. Searching by userid will return one person, whereas searching by
lastname may return many people (i.e. WHOIS COHEN) If a match is not found,
a phonetic search will be performed to try to find a match.
BITRPT - will allow you to create customized reports based upon the BITNET
NAMES database of information. If the request arrives via Bitnet
interactive message, the response will be via a file.
Full Syntax:
BITRPT SELECT
|