|
|
|
|
|
|
|
|
NetMonth, March 1987
* * * * *
** * ** ** *
* * * * * * * * * * *
* * * ***** ******* * * * ***** ****** ******* ******
* * * * * * * * * * * * * * *
* * * ******* * * * * * * * * * *
* ** * * * * * * * * * * *
* * ****** * * * ***** * * * * *
* *
* The monthly guide to BITNET servers and services *
* *
* Volume 1 Number 9 March 1987 *
* *
*****************************************************************
* *
* Editor: Chris Condon CONDON@YALEVMX *
* Assistant Editor: Steve Sutter SUTTER@YALEVMX *
* NetMonth Staff Supervisor: Gary Moss MOSS@YALEVMX *
* *
*****************************************************************
* *
* File queue? What file queue? I don't see any... *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* 000000000 * 000000000 *
* 0000<<<<<<<<<< * >>>>>>>>>>0000 *
* 00000(((((((((((((( * ))))))))))))))00000 *
* 000((((((((((((((((((( * )))))))))))))))))))000 *
* 00!!!!!!!!!!!!!!!!!!!!! * !!!!!!!!!!!!!!!!!!!!!00 *
* 00((((((((((((((((((((( * )))))))))))))))))))))00 *
* 00<<<<<<<<<<<<<<<<<<<< * >>>>>>>>>>>>>>>>>>>>00 *
* 000000000000000<<< * >>>000000000000000 *
* 00((( * )))00 *
* 0((( * )))0 *
* 0((( * )))0 *
* ''''4''''3''''2''''1''''0''''1''''2''''3''''4'''' *
* 00(((( * ))))00 *
* 000(((((( * ))))))000 *
* 0000000000000 * 0000000000000 *
* &(>&)><*&>(<<_@<_*<#_@*_<_*#&==G==@>(>&>>)@&#&)&%(>@&<&<%(<#<<@ *
*****************************************************************
1
*************************************************************************
* Contents *
***************************************************************************
Bitnotes ................................................................ 1
TAKE NOTE__________________________________________________________________
Scuttlebut .............................................................. 1
Netcon - Spring 1987 .................................................... 3
Global Teachers' Network ................................................ 4
FEATURES___________________________________________________________________
Network Load ............................................................ 5
To NIC or not to NIC? ................................................... 9
NetMonth Reader Survey Results ......................................... 14
SERVERS AND SERVICES_______________________________________________________
A New File Server: SERVER@SUZEUS ....................................... 16
A New Name Server: VMNAMES@UREGINA1 .................................... 18
New Mailing Lists ...................................................... 20
MACSERVE Moves to PUCC ................................................. 22
DEPARTMENTS________________________________________________________________
Feedback ............................................................... 23
Policies ............................................................... 24
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@YALEVMX.
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: 652 >----------------------------
FuzzyBytes Electronic Publishing "Because We're Here."
1
Page 1
*************************************************************************
* Bitnotes Issue 8 *
***************************************************************************
Nobody, so I'm told, is perfect. This came as a shock to me, but I have
learned to live with it. My juggling of School/Work/Friends/Netmonth has
become (to say least) strained. This has two major implications:
1. ALL of the glorious improvements that the Reader Survey inspired do not
appear in this issue of NetMonth (or in BITNET SERVERS). They will be
appear slowly but surely in the next few issues, as I find the time to deal
with them. With this issue we have made the initial change of organizing
the articles a bit more (see the Table of Contents for details).
2. I am unable to give you a proper Bitnotes this month. However, there
are some issues which need to be addressed, but I just haven't found a
moment to write about. These are fairly complex, and a LOT of debate has
been keeping my mailbox full of interesting postings to LIAISON and LSTSRV-
L. I have chosen the best of these to replace me for this month. And,
rather than contact all of the people involved for permission, I have
simply removed any traces of names and network addresses.
You will find all of this in the articles "Issue: Network Load" and "Issue:
To NIC or not to NIC?"
Before I go, one last issue to address: Please excuse our odd publishing
schedule. This magazine goes to the "presses" on the second-to-last
weekend of each month. We have not been late. Just strange.
Virtually,
Chris Condon@YaleVMX
*************************************************************************
* Scuttlebut *
***************************************************************************
All the news that's fit to bit...
* From Zvika Bar-Deroma: The LOOKUP name servers at RITVAXA/B/C/D have
been consolidated into one server: INFO@RITVAXD. For more information send
the HELP command via interactive message to the server. (More information
will be published in April NetMonth, or as soon as the links are up
(whichever comes first). --Ed.)
1
Page 2
* From Niccolo' Avico: "The LFCNET file server has been shut down for an
unlimited period of time; this due to a rearranging of the files stored.
The main reason for this is that this kind of server is no longer needed to
the net.
"LFCNET was born in a pioneering era, which is now over: no LISTSERV,
NETSERV and other amazing servers were available then. The network
load was also lower, and a file server like this was able to survive. Now
this is no longer the case. I can understand this.
"Moreover I already planned to definitively close LFCNET because of it is
time consuming for my own life. Because of this there remains the
possibility of permanent shutdown."
* From John Voigt: "TCSSERVE is being discontinued in favor of the file
service facilities on Eric Thomas' LISTSERV. Most of the files previously
available on TCSSERVE are now available from LISTSERV. To get a current
filelist of what was moved one of the following commands should be used:
"INDEX TCSSERVE" or "GET TCSSERVE FILELIST"
"The main reason for this change is the additional capabilities offered by
the LISTSERV file server. It will respond to mail, messages, notes and
files. TCSSERVE only responded to interactive messages, something that a
very large part of the network was incapable of sending. We regret any
inconvenience these changes cause. Our desire is to provide the best
possible service to the BITNET community and we feel these changes will
better serve the needs of most BITNET users.
"We have also implemented a local LISTSERV command to provide NAME service.
The command is $WHOIS and will return E-mail address for most of the user
at Tulane University. To use this service simply send a command to
LISTSERV of the form: "$WHOIS userid/last_name". Note that some users have
several accounts and all will be displayed. I would appreciate comments,
complaints and problems be reported to me."
TCSSERVE processed over 30,000 commands
16,743 files were sent to 3,861 users at 389 different nodes.
* From Peter Jaspers-Fayer: "As of Mar 1st, the old and creaking
SERVER@UOGUELPH will no longer be running. The project was fun once, but
politics have so soured the whole concept here that I haven't touched it in
many months. I'm putting it out of it's misery."
* New list servers/file servers: LISTSERV@IRISHVM and LISTSERV@BYUADMIN.
Thanks to Nick Laflamme and Rocky Waters for this information.
* New NETSERV file servers: NETSERV@NORUNIT, NETSERV@TCSVM, and
NETSERV@MARIST.
1
Page 3
*************************************************************************
* NetCon Spring '87 *
***************************************************************************
NETCON SPRING '87 A chance to meet fellow Bitnetters and Relayers!
WHEN: May 22-25, 1987
WHERE: New Orleans, LA
REGISTRATION INFO: $10 fee due April 24, 1987
(Make checks payable to Jim Harmening)
Send to: Jim Harmening
2033 W. 108th Place
Chicago, IL 60643
HOTEL INFO: New Orleans Marriott
555 Canal Street
New Orleans, LA 70140
504/581-1000
HOTEL COST: $49.95 for 3 nights, 4 people per room, payable to the the
hotel upon arrival. To guarantee for late arrival (after 6 p.m.), send a
deposit to the hotel after May 11, 1987.
RESERVATIONS: Send mail to Charlene Charette, GB0CBGS@TCSVM, BY APRIL 24,
1987, TO RESERVE A ROOM. Include your name and rooming preference. In
addition, between May 15-21, 1987, send mail to Charlene Charette,
GB0CBGS@TCSVM, to confirm (or cancel) your hotel reservations.
NETCON T-SHIRTS: Send mail to Jeff Robinson, IP60583@PORTLAND, if you want
to purchase a Netcon T-shirt.
ADDITIONAL INFO: For additional information, signon to the Netcon mailing
list, NETCON-L@NCSUVM, or send a note to Scott Campbell, SCOTT@UTORONTO, or
Paul Ribeiro, ACPS2681@RYERSON.
TENTATIVE AGENDA
FRIDAY, MAY 22, 1987
3:00 or later Checkin at Marriott Hotel
8:00 p.m. Welcome and greetings party
10:00 p.m. Night on the town
1
Page 4
SATURDAY, MAY 23, 1987
10:30 a.m. Seminar--Past and Future of Bitnet
11:30 a.m. Seminar--Past and Future of Relay
12:30 p.m. Lunch and site seeing (on your own)
7:00 p.m. Dinner as a group
after dinner Night on the town--French Quarter
SUNDAY, MAY 24, 1987
Whenever Breakfast/Brunch
Whatever: tours, zoo, paddle boats, street cars
MONDAY, MAY 25, 1987
Whenever Goodbyes and departure
*************************************************************************
* Global Teachers' Network *
***************************************************************************
by Glen Turnbull CEK4@UBCMTSG
and Jeremy Meharg NEG8@SFU
To: All Educators of Children Throughout the World
Those of you who are reading this message are well aware of the fact that
this, our planet is growing increasingly smaller by the day. Current
technological advancements in telecommunications and electronic mail
provide the capabilities for Global Communications never before dreamed
about.
With these new open channels of communication comes the ability to learn
more about others and the existing diversification of cultures. This
knowledge could lead to an increased awareness and clearer understanding of
people throughout the world and encourage the acceptance of others and
eventual Global Peace.
It is with the purpose of promoting these ideals in ALL children that we
wish to encourage the development of a Global Teachers' Network. We wish
to offer our location (Vancouver, Canada:EXPO-86) as a focal point for the
GTN. Using whatever Network system your country has, we request that you
pass this message of hope along to others who are connected to your system.
If you are sincerely interested in becoming a participant in the Global
Teachers' Network, send your name and telecommunications address to our
location. We will confirm your involvement in the GTN and discussions
should start soon.
1
Page 5
*************************************************************************
* Issue: Network Load *
***************************************************************************
From the LIAISON and LSTSRV-L mailing lists: Something to think about.
===========================================================================
This notice is a follow-up to one that I posted in December. The situation
now is even worse than it was then. As I mentioned then, we began seeing
constant queues on the line to OHSTVMA as soon as Version 2 of RSCS was
installed. That may not be the ultimate cause but that is exactly when we
began having the queues. Over the holidays, the traffic diminished enough
to allow the queue to clear out. The situation now is that we have files
queued for the line that arrived as long ago as Feb 2. In fact, we have
60 files queued that arrived the first week of Feb., 169 files that arrived
the 2nd week, 152 the third week, and 166 files this week. Several days
ago, I ordered the queue so that all routing tables from the first or
second week were finally sent. The traffic is slowly but steadily
increasing. A significant change is required to handle it. Installation
of modems running faster than 9600 would certainly help. A Reduction in
the number of requests to servers around the network would help. Running a
RELAY at PSUVM might help. Running V2RSCS at PSUVM might help. A line
from CUNYVM to another western or mid-western node would help. These and
other changes can be made to help alleviate the situation. Until then,
network users must expect and tolerate some very long delays.
===========================================================================
KNET-L subscribers on the TAMVM1 LISTSERV are missing some letters that
were submitted at the DB0TUI11 peer of this list. They are all waiting at
PSUVM to be transmitted to OHSTVMA where there is some terrible problem
with files of any significant size getting through. I understand that some
files are weeks old.
===========================================================================
If everyone would shut their servers off for the weekend, we might, just
might mind you, approach some sanity!
PSUVM-OHSTVMA queue always >1000 (file from 2/2 still there!)
BITNIC-EARNET queue > 2000 all this week (except one morning it was 1850)
CUNYVM-PSUVM always 750-1000 files
The major culprit by far is the KERMit server at CUVMA, but there is alot
of other duplicate junk file traffic as well!!!!
1
Page 6
===========================================================================
We can shut down our servers and probably the queues will slowly decrease,
but after a sufficient period of time this will happen again. To me it's
obvious we must make some structural changes in the method of distributing
files. For example:
BITNIC-EARNET queue > 2000 all this week (except one morning it was 1850)
I cannot understand why the BITNIC LISTSERV is not peer-linked for
*every* list to an EARN server (a server in EARNET would be idoneous,
but we don't have one at present, so perhaps CEARN could do the job).
I've been taking a look quite regularly at the BITNIC-EARNET queue this
week and most of time the 255 first files are mail from listserv for
several lists. Until we get that fixed, european users may want to help by
signing off from the BITNIC LISTSERV and subscribing to one of the european
redistribution lists.
===========================================================================
I have talked to Brian Nelson at Toledo about KERMSRV @ UOFT02 getting
smarter (he was going to relay this idea to CUVMA). He was in agreement.
Here are my suggestions:
Set up a warning period for KERMSRV requests:
If requests come in from the "wrong" side of the OSU/PSU link, tell the
requestor that he should use the other kermsrv. (then either honor the
request with warning of his regional server or forward the request to
correct server and tell user what's going on...)
Then plan for regional service areas:
KERMSRV @ UOFT02 for west of OSU-PSU
KERMSRV @ CUVMA for east of OSU-PSU
and have each server respond with a file-being-sent or use-other-server
msg.
I realize the "what if one server is down" situation needs to be solved
too. But this should also be part of the region server solution.
===========================================================================
Considering the back log that has been occuring at the PSUVM site, and any
other sites...I have noticed exceptionally large files being transmitted.
A super example was one sitting in the queue for CUNYVM at PSUVM (and is
1
Page 7
most likely still there) that was a mere 94,425 records. (this translates
into at least 7M bytes - a tad over the max file size recommended for
BITNET usage.) I think becoming a bit more rigid about file transfer would
assist a bit in relieving the backlog and network load problems.
Now, the other problem is to come up with a good way of monitoring the file
sizes without having to keep a human eye on it ... is the author of NETMON
still around...maybe an option to NETMON to monitor the file sizes every
minute or two and if file is large...place it on hold and notify the local
staff to make a decision to flush the file. Again, this attitude may be a
bit rigid - but we have to start somewhere?? yes?
===========================================================================
I was always somewhat suspicious of NETMON (perhaps falsely so) because, as
I understood it to work, it queries link status over the whole network
periodically (10 minute intervals?) and parsed the returned output. If you
check every link, that is 1700+ queries going out and somewhere in the same
neighborhood of messages returned. That is one heck of a message load and
will freeze file transfers for a significant period of time. If you rig
NETMON (et al) to query another node's queues, recall that you can get 100
messages back (if 100+ files are queued). Kaboom.
Another issue everyone is bouncing around is that of relocating servers and
so forth to 'this side or the other' of 'this or that bottleneck'. As of
6:00 AM EST this morning (when queues *should* be *empty* and all normal
people in the US should be asleep) the following queues were left:
PSUVM -> OHSTVMA 469 files; OHSTVMA -> PSUVM zero.
CUNYVM -> PSUVM 887 files; PSUVM -> CUNYVM zero.
BITNIC -> EARNET 1660 files; EARNET -> BITNIC 10 files.
Bob Fowles observed that some 30% of his queue was from Bitnic servers. I
would suspect a sizeable portion of the queues were also accountable to
Kermit and/or LISTSERV as well. Suggestions have been kicked around about
moving certain servers to PSUVM and/or OHSTVMA, etc. In any case, an
attempt is made to subdivide the 'hub' into other segments, and then
placing servers on the corresponding hub.
It may sound ludicrous at first, but the best solution would be to put the
server for a given segment as far out in left field as you can find a
volunteer (and you usually find volunteers out on the ends). As you will
note from the queue sizes above, the bottleneck is OUTBOUND from the hubs;
there is little or no backlog INBOUND. By placing servers on some end-
node, the traffic is now INBOUND, with the bulk of the traffic going on
links which are normally relatively idle. As the remaining copies approach
the crowded hubs, the number of copies will decrease; with the last copy
going to the hub node itself.
1
Page 8
There is still a considerable amount of bandwidth left in the network, it
just happens to be going in the 'wrong' direction. We could, with some
effort, take advantage of these available bitbuckets.
===========================================================================
It is all very well to explain why BITNIC's servers *had* to be shut down
to alleviate the backlog at critical network links, but that doesn't
address the issue I raised, namely, that LISTSERV, in particular, need not
place an appreciable load on any of the critical links. Surely, in view of
the evident crisis, this would be a very propitious time to link the BITNIC
LISTSERV with the many available peer servers throughout the network. The
advantages are obvious:
1. BITNIC could immediately shift subscribers to the peer servers.
2. Mail to one of the BITNIC lists would generate only *one* copy over each
of the critical links.
3. Mail sent originally to one of the peer servers (i.e., mail other than a
reply to a previous message) would already have been distributed to
subscribers downward of the corresponding critical link to BITNIC and so
would not generate any return traffic at all.
4. BITNIC could legitimately delegate the responsibility for archiving list
traffic to one or more of the peer servers, thereby cutting off another
source of load on the critical links, namely, file requests.
5. BITNIC could automatically assign new subscribers to their nearest peer
server, thereby avoiding the necessity of close human scrutiny.
6. BITNIC could even legitimately restrict the file server aspects of its
LISTSERV. For example, the usual memo files describing all the aspects of
LISTSERV could be replaced by short messages listing the peer servers and
suggesting that requests be referred to the nearest one.
===========================================================================
If NICSERVE saves large file requests until after midnight when most of
my users have logged off and gone home I have no problem with using
DISTRIBUTE to send the files. Especially when the alternative is for me
to have to wait 3 weeks and still not get my file, or to have to receive
and then send 10 copies to people beyond me in the network. I'd just as
soon receive one copy and generate the others needed.
NICSERVE needs to have a size threshold beyond which files are sent
via distribute. Small files can be sent now, big ones should be
held and DISTRIBUTED after midnight to everyone who requested them in
the past 24 hours.
1
Page 9
*************************************************************************
* Issue: To NIC, or not to NIC? *
***************************************************************************
From the LIAISON mailing list: Something else to think about.
===========================================================================
In reading mail from this and other lists I there seems to be a general
pattern of people asking for software for a Vax or Unix machine, and the
responses are always, "sorry, it only runs on IBM". I know IBM helped start
Bitnet, but as I scan the nodes list, I see a tremendous number of non-IBM
machines, yet I have noticed no real effort by BITNIC to bring these people
"into the fold" other than a simple connection to Bitnet. Are all the
people at BITNIC IBM blue-bloods? With so many other systems out there, I
should think the people in power would make a stronger effort to convert
software, but I haven't even heard any verbal efforts. And with all the
talk of heavy Bitnet traffic and delays, many of the proposed software
solutions (more servers, more local distribution of files, etc. ) cannot be
effective because at least half of the machines out there cannot run it.
Even if they wish to remain loyal to IBM, I bring to their attention that
IBM, along with many other firms, has publicly expressed support for the
proposed POSIX (UNIX) standard, so there is at least one non-VM operating
system that we all can support without offending anyone. Anyway, if all of
the rest of us gang up on the IBM people, maybe something might get done.
===========================================================================
I think you need to get the horse and the cart in the right order. First,
BITNIC has *NO* money for development. Most of the network tools in use on
BITNET's IBM systems were written by volunteers. In the past, some
software was developed by BITDOC, not BITNIC, under a grant from IBM.
Perhaps DEC would like to make a million dollar grant to BITNET for better
support of VAXen on BITNET? On bad days I am prone to think that maybe
getting BITNIC was one of the *WORST* things to happen to BITNET.
It seems to have stifled our volunteer spirit. Õsorry, but the libertarian
in me just can't help noting that this is much like people who feel that
since we have government the way to solve all problems is to pass a law
saying that someone else should solve the problem.å Certainly it is in all
our interest to have BITNET working equally well for all kinds of computers
but the non-IBM part of the net is I think going to accept a lot of
responsibility for making that happen because you have the most to gain.
The NIC's job is to coordinate and facilitate, and I'm sure that to the
extent that they are made aware of non-IBM tools out there they will do
their best to see that those who need to know about them can find out about
them. If they don't, then fault them.
1
Page 10
===========================================================================
Also, VM systems were on the net first (with network-inadequate IBM vanilla
code) long enough for people to get frustrated enough with %#$^&% IBM NOTE
etc to write something better. It's only a matter of time before there are
MAILERs and so on for VMS and UN*X too. But you VAX folks have to write
them!
Speaking for myself, anyway, I don't think the IBMers on the net are in any
way prejudiced against VAXers* - we'll be glad to support the effort to
translate/analogize VM tools to whatever you want to run them on. If it
helps the network, it helps all of us.
===========================================================================
Recent discussions on NODMGT-L have discussed this touchy issue somewhat.
I believe the consensus has been, yes, we need equivalent tools for other,
non-IBM systems. However, under the new charter recently adopted, BITNIC
has no money for development. The consensus from that has been, ok, it's
up to the VAX sites or the UNIX sites or whomever; we'll give as much
support as we can in explaining algorhythms or data structures, but no one
is going to do it for them.
I disagree with your contention that VM-based tools will not be adequate to
relieve the network load. The network backbone, that which is most
overloaded, remains VM-based. We therefore can put VM-based servers where
they are most needed and where they can greatly reduce the load. I am not
suggesting that non-VM versions should not be developed, but I am saying
that doing just VM initially will in fact be a great help.
While I understand your frustrations with the current situation, I think
your grievances are being addressed.
===========================================================================
First, it is nice to known that there are still a few libertarians around.
I did not what to imply that money should immediately be spent on new
programs, but I noticed that we non-IBM users tend to be ignored a lot. It
would be nice to hear a word of encouragement or some recognition of our
existence. Not only is there a gulf between DEC and IBM, but the same gulf
often exists between the two user groups as well (also include Unix people
in there own world).
As to the spirit of volunteering, I also agree it is reduced. I am just a
lowly programmer who is confused by tangled mazes of authority like
Executive committees and EDUCOM and working groups. Any bureaucracy that is
large enough to organize conventions with workshops, planning groups,
1
Page 11
elections, etc. frightens me (wouldn't a few mail messages between
interested users have sufficed, and then let everyone on Bitnet who wants
to send in a vote?). When there are powerful groups around, an individual
had better not try anything alone without getting approval first, or risk
the wrath of someone above, and I prefer to avoid such politics. Anyway,
perhaps a few people will keep it in mind at that convention that there is
a need for non-ibm software. (When I buy my Cray 4 with Unix, I want to
have LISTSERVS and NETSERVS and RELAY too! ;-) ).
===========================================================================
Surely, you aren't suggesting that BITNIC should purchase new computers
and/or operating systems and hire a staff of programmers to develop fancy
software for all the non-VM people on BITNET! Most of the whizzy packages
we see were developed more or less spontaneously -- i.e., if you really
want a specific piece of software, you must write it yourself or find
someone else who wants it sooner than you do.
===========================================================================
This lack of support from BITNIC does not only concern nonIBM systems. We
are an MVS site (IBM 3033) and cannot get ANY support from BITNIC. It took
a personal meeting with Michael and Judy to get on the LIAISON mailing list
last time. It took a phone call from myself and the director at Cornell to
get some information in the BITNET tables corrected.
Judy, Scott, and company complain that they are vastly overworked. They
must be, since many database items have not been updated in over a year. I
have been finding out most of my information from other MVS sites who have
gone through similar problems in trying to get information. I have found
more helpful and knowledgeable support from the ARPA and CSNET information
centers and the various gateway masters than BITNIC.
===========================================================================
I have basically two questions:
1) Have alternate sources of funding for BITNET been investigated? For
example, educational type grants, other companies (DEC, AMDAHL). Money and
the fee structure seem to be the hook most user's are objecting to.
2) Where, EXACTLY, does the money go? Various nodes are (or seem to be)
volunteering services to replace BITNIC at considerably lower dollar and
manpower costs. My understanding of BITNET is that a great deal of work is
done by member institutions on a "round-tuit" VOLUNTEER basis, including
such important task as distributing routing tables.
1
Page 12
Point one has already been decided. Money hasn't been allocated for
development, according to what I have read. Money apparently hasn't been
allocated for info services either. Where did/does the money go?
===========================================================================
Those are good questions... questions that a number of us asked, even
fought over, before the charter was "approved." You are not alone in
feeling that adequate answers have not yet been given.
Let's back off, give them a few months to get themselves organized if they
can, and then "give it to 'em Harry" if need be. After all, if indeed they
are able to incorporate, and the organization doesn't leak like a sieve in
court, then we, as purchasers and subscribers, have a solid position from
which to demand change. And frankly, if this is the way that we can get a
reliable, contracted level of service that is better than and more
consistent than the voluntary (and very worthy!) efforts that we now have,
born of necessity, then maybe this is not such a bad idea after all, eh?
We shall see. We shall see.
===========================================================================
The most critical fault that has been made to date by the BITNIC staff is
to address themselves only to the upper-level campus administration. They
were interested in securing money and recognition for themselves, and
decided that this was where the money was. They saw no need to to invite
the favor of the user community. In fact, they seem to be quite afraid of
what the user community might have to say against them -- and therefore do
not want to listen. They seem to believe that their jobs depend on it.
But the opposite is true. If you want to reach the node administrators,
you must do so through the users. You must do that by serving in the
classic coordinating and facilitating role of true management, and by
serving a perceptibly beneficial role. The computer center personnel in
particular, the "Techhies," will be called upon to be advisors to the
upper managers, who of course will not spend money without knowing whether
the proposal makes good business sense.
The "American Revolution" began when certain users realized that their
needs were not being met in the EDUCOM proposal, and assumed that BITNIC
would be favorable to a better approach. It ended, I believe, when those
same people realized that BITNIC did not want to know. That was no victory
for BITNIC, because a lot of ears were sealed up as these people simply
went on the offensive. BITNIC has a lot of explaining to do now.
We don't need an ivory tower in the middle of BITNET. We need a better
BITNET. If BITNIC wants to help do that, then welcome aboard. Otherwise,
good riddance.
1
Page 13
===========================================================================
I am glad to hear that at least the talk from Mr. D'Amore has improved by
a quantum leap. At SIGUCCS in Montreal, I had a chance to talk with both
Michael D'Amore and Judith Molka. At that point in time, they both
maintained that BITNIC was doing wonderful things, and that everyone's
problems were due to not following the proper procedure for obtaining
information. In the session that they presented, they received a lot of
hostile comments for their stance. Some of us at that point tried to
maintain that it was impossible for them to know all of the possible types
of connections to BITNET, and that they should possibly refer some queries
to the network. Both of them asked the group if the group was willing to
field questions, and we responded yes.
In the months that have followed, there has been no change in the stance of
BITNIC. When the ARPA-BITNET gateway was restricted, BITNIC didn't respond.
I was not at SHARE, but from the comments that you are making, it doesn't
seem that a good solution to the traffic problem was reached. I also
haven't heard any progress in regard to running TCP/IP across the network,
which would allow for some better routing protocols (if the hardware was in
place).
===========================================================================
I will agree that it is somewhat disheartening that BITNIC cannot provide
all the services that it once provided and/or we think it ought to. There
are, however, several on this list that could possibly help out with the
volunteer effort to keep up some of these things. If BITNIC cannot help us
the way we need, then maybe we can help ourselves. What we really need I
think right now though is someone to volunteer to help coordinate the
volunteers...collect all the "we wants" and all the "I will helps" and
match them or something. In other words, couldn't we have just a little
organization of the volunteers?
*
* *** *
* * * * *
* * * * *
* * * * *
* * * * *
* * * * *
* * * * *
* *** *
*
1
Page 14
*************************************************************************
* The NetMonth Reader Survey RESULTS *
***************************************************************************
1. How long have you been reading NetMonth?
20% a. 1-2 months
17% b. 3-4 months
9% c. 5-8 months
54% d. I was a Bitlist reader
2. Are you a(n):
23% a. undergraduate student
14% b. graduate student
44% c. computer center staff
25% d. educator (doctor, professor, teacher, etc.)
11% e. other
3. How old are you?
31% a. 18-25
33% b. 26-35
30% c. 36-50
5% d. 51+
3% e. none of your business!
4. Are you:
97% a. male
3% b. female
ÕHa! -- Assistant Ed.å
ÕOne wonders if there is any connection between
3% who are female and the 3% who wouldn't admit
their age... -- Ed.å
5. Do you read any electronic magazines other than NetMonth?
51% a. yes
49% b. no
6. Do you subscribe to any digests/mailing lists?
65% a. yes
25% b. no
1
Page 15
7. How often do you sign on to RELAY?
6% a. almost every day
18% b. a few times a week
14% c. a few times a month
21% d. not more than once a month
40% e. never
8. Have you ever used a file server before?
93% a. yes
7% b. no
ÕMostly NETSERV, CSNEWS, and LISTSERV. -- Ed.å
9. Have you registered yourself on a name server?
51% a. yes
49% b. no
ÕMostly NETSERV and CSNEWS. -- Ed.å
10. What operating system is your mainframe running?
71% VM/SP, VM/CMS
17% VAX/VMS
6% MVS/XA
1% MTS
1% TMO
Results from the second half of the survey (your opinions on NetMonth)
will be published in the next issue. The results of essay questions,
as some of you know, are difficult to quantify. However, we have gotten
several distinct messages about what you would like to see and where
the magazine should go in future issues. Other conclusions are hard to
draw since most of you disagree on key points, such as how technical the
articles should be. More in April.
***** ***** ***** ***** ***** ***** ***** *****
***** ***** ***** ***** ***** ***** *****
***** ***** ***** ***** ***** ***** ***** *****
***** ***** ***** ***** ***** ***** *****
***** ***** ***** ***** ***** ***** ***** *****
***** ***** ***** ***** ***** ***** *****
***** ***** ***** ***** ***** ***** ***** *****
***** ***** ***** ***** ***** ***** *****
1
Page 16
*************************************************************************
* A New File Server: SERVER@SUZEUS *
***************************************************************************
by Tony Dahbura TONY@SUZEUS
The SERVER Virtual Machine at SUZEUS (Syracuse University) will send you
any file it has access to excluding its internal system files. Valid
commands are:
LIST
|
