|
|
|
|
|
|
|
|
NetMonth, August 1988
******** **************************************************
* * *
* * The independent guide to BITNET *
* * *
* * August, 1988 *
* * *
* * Volume 3, Number 2 *
******** * *
* *
*** * *
* * * * *
* * * * *
* * * * *
* ** * *
* *
* * * * * * * * * * * * * * * * *
* * *
****** * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * *
* * *
* * * * * * * * * * * * * * * * * *
******** * *
* * * * * * * * * * * * * * * * * * *
* * *
* * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * *
* * *
******** * * * * * * * * * * * * * * * *
* *
*** * * * * * * * * * * * * * * * *
* * * *
* * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * *
*** * *
* * * * * * * * * * * * * * * * * *
****** * *
* * * * * * * * * * * * * * * * * * *
* * *
* * * * * * * * * * * * * * * * *
**** * * * * * * * * * * * * * *
* *
* * * * * * * * * * * * * * * * *
* * *
****** * *
* * *
* * *
* *
******** * *
* * *
* * *
* * *
**** **************************************************
1
* * * * *
** * * ** ** * * *
* * * *** ***** * * * * *** **** ***** ****
* * * * * * * * * * * * * * * *
* * * ***** * * * * * * * * * *
* ** * * * * * * * * * * *
* * **** * * * *** * * * * *
***** ******
Christopher Condon Editor CONDON @ YALEVM
Timothy Stephen Associate Editor STEPHEN @ RPICICGE
Craig White Associate Editor CWHITE @ UA1VM
Wendel Bordelon Contributing Editor TACVRWB @ TCSVM
June Genis Contributing Editor GA.JRG @ STANFORD
David Hibler Contributing Editor ENGL0333 @ UNLVM
Henry Mensch Contributing Editor HENRY @ MITVMA
Deba Patnaik Contributing Editor DEBA @ UMDC
Gerry Santoro Contributing Editor GMS @ PSUVM
Marc Shannon Helpdesk Editor HELPDESK @ DRYCAS
Glen Overby Technical Assistant NU070156 @ NDSUVM1
Gary Moss Price of Victory MOSS @ YALEVM
******************** Contents - Issue 24 ********************
EDITORIAL PAGE_________________________________________________
Bitnotes .................................................... 1
The Human Factor ............................................ 4
FEATURES_______________________________________________________
Announcing NAMESERV@DREW .................................... 8
The BITNET Board Report .................................... 10
DEPARTMENTS____________________________________________________
Headlines .................................................. 13
Helpdesk ................................................... 15
New Mailing Lists .......................................... 17
Feedback ................................................... 20
Policies ................................................... 22
* For information on subscribing to NetMonth, submitting *
* articles, sending letters, and printing this file, see *
* the "Policies" section on the last pages of this issue. *
---------------------< Distribution: 3091 >--------------------
1
Page 1
*********
* * Bitnotes
* *
* * by Christopher Condon
* *
* * Yale University
* *
* * BITLIB@YALEVM
*********
"Fuzzyness is next to cleanliness."
August 13th, 1988....
I finally ventured forth to a BITNET Technical Meeting. These
are usually held in odd places on the west coast or odder
places in middle America, depending on where SHARE is at the
time. Luckily, this one was held in that giant among metropoli
(metropolises?), New York City, a spot easily accessable to
poor Connecticut residents like myself.
I started off the day with a Typical Stupid Move. My train
arrived at Grand Central and I had 45 minutes to spare before I
had to get to Hunter College. This, I found, was *only* 24
blocks away. With plenty of time on a hot, muggy, day (and the
ozone level at record levels) I decided to walk. Somewhere
around Bloomingdales I came to my senses and took the rest of
the trip on the subway. By now, some of you are asking, "What
senses?"
Highlights of the day...
My first surprise of the Technical Meeting was finally meeting
Judy Molka. Since she is leaving the BITNIC to attend
University of Pittsburgh, I didn't expect to see her there. I
had time to think up several witty lines for the occasion:
1. "You're much shorter in person."
2. "So you are the infamous Judy Molka."
3. "There is a multilegged creature on your shoulder."
I decided on Option 2, a simple and not *too* strange choice.
When I finally made my identity clear, I received the obvious
reaction:
"I expected you to have a beard."
1
Page 2
I suppose I should be pleased with reactions like that. After
all, it is better than, "Eeeeeww! Yuck!", right?
Scott Earley (rhymes with "curly", as in his new hairstyle) was
supposed to open the meeting but missed his bus. Les Lloyd
(who doesn't look anything like a Trustee) and Judy filled in.
Les managed to supply us with a few new jokes:
*Q* How many programmers does it take to screw in a light bulb?
*A* None, it's a hardware problem.
*Q* How many polite New Yorkers does it take to screw in a
light bulb?
*A* Both of them.
We eventually broke up into our various working groups. I
decided to attend the Inforep session, which Scott Earley
chaired. Luckily, he recently posted a summary of that
meeting:
I. Create an INFOREP Packet
A. Suggested contents
1. LISTSERV related
a) command summary
i) what is it? how to get off? who has control over?
b) auto-SUB INFOREPs to certain lists
i) BITNEWS, NETMONTH, CCNEWS, LIAISON, etc.
c) 10 most informative files at BITNIC's LISTSERV
2. Postmaster Canon
a) current action item of Board NETUSE-C committee
i) urge POSTMAST userid at new nodes
3. online HELP files/tools
a) for CMS shops from BITLIB@YALEVM
b) for VMS shops from VMSSERV@UBVMSD
4. Internet
a) tools, mailers
b) Domain registration procedure
c) manners, etiquette
B. Distribution
1. over BITNET to new INFOREP
2. cc: over BITNET to INFOREP at 'via'
a) in case of non-delivery to new
b) strengthen bond between neighbors
3. send by US mail also?
II. Guidelines for network use
A. by Servers
1. file size restrictions
a) individual
1
Page 3
b) cumulative bytes over 24 hours
c) delegating authority
2. subscription
a) duration of
b) deletion from
i) 'SIGNOFF * (NETWIDE'
ii) after some elapsed time
B. by General users
1. file size
2. unprofessional personals
3. job soliciting
4. software distribution
C. enforcement
1. limitations
2. procedures
III. User Directory ("white pages")
A. invite participation by INFOREPs
1. define known servers around network
2. solicit comments on design and use
3. professional purposes only
IV. Weird Gateways
A. make an effort to inform users
1. heed to responsible limitations
(End of summary)
One of the more interesting points that came up was the
development of the new name server at DREW (highlighted
somewhere in this issue). This is an attempt at building a
real, central name server for the network. The problem (as
always) is getting people registered in its database. People
in our session were invited to try out other name name servers
and compare features and make suggestions.
The best point to come out of the Inforep session was the
recommendation to create "new user packets" for new Inforeps
and new BITNET users. There were plenty of suggestions about
the content, but there is some confusion as to who will do the
job and when. Most of the Inforeps seemed willing to make
contributions, but someone/something is needed to tie the whole
thing together.
Other interesting events...
Apparently I am even more infamous than Judy Molka. I heard no
end to questions and comments about what I could/should/would
write about the events of the day. This was very helpful,
although I am aghast that everyone thought I was there in a
"journalistic" capacity.
1
Page 4
During the long lunch hour some of us took a walk around
Central Park. It seems that we went in the wrong direction in
the search for an entrance, hence the walk *around* and not
within. Later in the day I met Randi Robinson, who gave me a
mini-tour of City University of New York. She is one of those
people on the network that has been on the network so long that
I should have met her a long time ago, but never did. Randi
lives in Connecticut so I had someone to bore... er, gab with
on the train ride home.
When the reports from the other working groups come in I will
put them in NetMonth. The exiting Autumn awaits.
Virtually,
- Chris
*********
* * The Human Factor
* *
* * by Timothy Stephen
* *
* * Rensselaer Polytechnic Institute
* *
* * STEPHEN@RPICICGE
*********
The Fall semester is here and like the dawn of any day, there
are those who have waited for it with excitement and there are
those who are indifferent to its arrival. For some, the start
of the 88-89 academic year signals new opportunities to learn
and explore, new possibilities for achievement, new challenges,
new avenues for creative enterprise, new prospects for refining
or developing social relationships. For others, however, the
coming year seems simply routine, just another turn of the
wheel.
I confess a little schizophrenia in this department. My
feelings about fall semesters have run both ways over the
school years, this being the 32nd new one that I've faced.
However, I think I've discovered that my feelings are
influenced by my sense of whether the coming year will provide
opportunities to build upon the previous one (to learn more
about an exciting subject that I've been studying, to extend my
research another step, to refine a course I've been teaching,
to renew or extend rewarding professional relationships) or
whether it seems that the new year will only offer more of the
same old crap-ola. I think that I feel most optimistic when
1
Page 5
the prospects for a new year are for controlled change in a
constructive direction. For me, no growth means boredom and
anxiety.
BITNET, of course, has almost become synonymous with the idea
of growth. The dream of a comprehensive inter-university
electronic communication network is virtually fulfilled. By
last spring, in fact, it had become evident that as the number
of connected schools is so rapidly increasing, so too is the
need for basic technological enhancements: wider bandwidth
(i.e., the ability to pass more information between computers
at the same time), dynamic routing (raising the IQ of the
network software so that it can automatically route messages
around machines that are temporarily broken) and greater speed.
These are challenges for the future, the sort that make a new
year interesting and exciting to participate in and I hope that
they'll bait the interest of enough technologically oriented
people that solutions will be identified and adopted before
gridlock brings BITNET to a standstill.
The real challenge for the coming year, however, is to find
ways to sensibly manage BITNET's environment and channel its
growth. What has been created is far from a finished product.
It remains a system, as the real estate agents would say, "with
lots of potential" rather than a system whose value to higher
education has been established unassailablly. The coming year
and those that follow soon after are going to play a
determining role in the future of inter-university networking.
If much is accomplished during this period, the future of
networking in higher education will be assured. However, if
BITNET's most important problems remain unresolved, it may
actually begin to hinder networking's future, serving as an
easy negative example. The days of innocent, unquestioned
faith in academic computing are over -- no one still believes
that computers are going to magically transform the business of
education. These days one must deliver or decamp.
With the exceptions already mentioned, the important problems
in BITNET's future are less technological than organizational.
For example, though it is clear that a faster network would be
better, increases in speed will be of little consequence in an
environment where nodes stay off-line for hours or days at a
stretch due to poor or irresponsible management. When I called
one central site to ask about the prognosis for their downed
BITNET connection I was told, "Sorry, BITNET is Joe's baby and
Joe is on vacation." I recently called another school to ask
why they were disconnected from the next site up-stream. I was
told that although it was known that the problem was at the up-
stream school, staff had been instructed that they were not to
use the phone to report problems to neighboring nodes. I
1
Page 6
called the up-stream school (where the problem had not been
noticed) and the situation was quickly straightened out.
Dynamic routing would help the rest of us to avoid the
inconvenience created by irresponsible schools, but it is small
consolation for users at those schools to know that everyone
else's mail is successfully avoiding their node.
One of the greatest problems continues to be the lack of any
mechanism for enforcing needed standards. In what seems to be
an effort to connect as many schools to BITNET as possible, the
BITNET Board of Trustees has apparently chosen to admit
virtually anyone and standards have been almost completely
neglected. Schools are allowed to connect that don't provide
local support or documentation for BITNET, subjecting the rest
of BITNET's user community to the otherwise avoidable errors of
underinformed users. Schools are allowed to connect using
software that returns mail to the sender when the recipient's
mail box space is full or too small (think about it: you send
someone mail and it comes back because too little space has
been allotted for the receiver's mailbox. What do you do
next?) Schools are allowed to connect that assign users
needlessly complex userids (1Xl1CJOZ@SOMENODE), contributing to
a constant stream of returned mail. Schools are allowed to
connect using clustered computer systems that assign a user a
node name that may change from one terminal session to the
next. This creates chaos for servers that keep track of usage
statistics and automatically deliver start-up information to
new users. Schools are allowed to connect that issue userids
that are longer than eight characters. This wouldn't matter
except that other schools are allowed to connect which, even
after persistent urging from faculty, still refuse to install
and maintain public-domain mailer programs. Other schools that
have been allowed to connect do have mailer programs, but ones
which issue error messages encrypted in some kind of computer
gobbledegook. And even at this late date, schools are allowed
to connect that deny students access to the net.
Many of these problems could be solved without much difficulty
if people were interested in taking them on. But since they
have persisted so long, it seems doubtful that they are going
to go away without organized intervention and that should come
from the Board of Trustees. Will 88-89 be the year that the
Trustees begin to play a more visibly active role in smoothing
out BITNET's wrinkles? Will we see standards proposed,
discussed, adopted, and finally enforced? The alternative is
that the net will continue as an anarchy where site
administrators enact policy as if it affected their own users
only and as though they have obligations to no one else. I
hope that the Board is looking with excitement at 88-89 as an
opportunity to lead BITNET up the next rung of its evolutionary
1
Page 7
ladder. Leadership is needed indeed as the challenges and
problems of human organization are often as complex and subtle
as any in the area of technological development, sometimes more
so.
I hope too that others in BITNET's user community are looking
at the year ahead as one rich in possibilities for creative
involvement and activity -- not content to be passive consumers
of the net, but aware of the important role that users have
played in BITNET's evolution. If BITNET was merely comprised
of a set of technical specifications, communications protocols,
and software systems, the role of the user would be sharply
reduced. In fact, however, if BITNET's success were to be
computed, it would have to be as a function of its relevance to
the everyday activities of higher education. Every such
activity that has occurred on BITNET to date has come about
through the unsponsored and spontaneous efforts of individual
users.
As we move into the first days of the 6th year of BITNET, it is
increasingly difficult to characterize BITNET as a "new"
network. It is now in place and it is now time for it to begin
to demonstrate its potential to higher education as a whole.
To paraphrase Francis Bacon, potential is a good breakfast but
a bad supper.
1
Page 8
*********
* * Announcing NAMESERV@DREW
* *
* * by Les Lloyd
* *
* * Drew University
* *
* * LLLOYD@DREW
*********
If you have ever searched aimlessly for that friend or
colleague that you knew existed somewhere on BITNET but didn't
know where, you will be very excited about at new BITNET
feature created at Drew University. Titled NAMESERV, this VMS
based program allows people anywhere in the BITNET, NetNorth or
Earn communities to register not only names and electronic
addresses, but also some keywords about themselves. Anyone on
the system can then search for a user by looking for first
and/or last name, node name or any of the up to 5 keywords the
person may have entered. NAMESERV will accommodate any of the
approximately 500,000 people throughout the world connected to
BITNET or its affiliated networks.
The information provided below will give you an idea of what
NAMESERV can do. Of course, at any time, you can SEND
NAMESERV@DREW HELP and receive up to date HELP information on
using the system. To receive the entire help file, just send
the command HELP FILE to NAMESERV@DREW via mail or message.
* REGISTERING: Registering on NAMESERV is easy. Just send a
command in the following format:
REGISTER first last Õkeyword1...keyword5å
For example:
REGISTER John Doe physics modula_2 engineering
How you send this command to NAMESERV@DREW depends on your
system. If you are using a VAX/VMS/JNET system, you would use
the SEND command. People on VM/CMS systems should use the TELL
command. Of course, you can always send commands to NAMESERV
as the only text of a mail message. Consult your local
documentation for more information.
The system does not care about upper or lower case entries,
they are shown above for clarity. NAMESERV will keep track of
the date you registered and each year on that date will send
you a re-registration reminder. If you don't re-register, your
1
Page 9
name will be automatically dropped from the list (you will be
sent another message when you are dropped). This will allow
the system to maintain an up to date list. If you re-do your
registration at any time during the year, the date you re-
register will be the new date upon which the one year
expiration period will be based.
The system was created for academic and professional use.
Registrations are screened by the name server for keywords that
might be inappropriate or might encourage inappropriate uses of
this feature. We are very excited about providing this service
to users of the network, but are committed to BITNET's usage
guidelines and principles and will make sure our service does
not allow for violation of those policies.
* SHOWING YOUR REGISTRATION INFORMATION: To see what your
entry looks like, send the command SHOW and your registration
information will appear. If you want to change it, just re-
register as shown above.
* SEARCHING FOR ANOTHER USER: There are a variety of options
that allow you to search for different information. The
general format of the command is:
SEARCH/Õqualifierå search_pattern
The qualifiers are as follows:
NAME: Looks for first and last name, i.e. JOHN DOE. This is
the default if no qualifier is present.
FIRST: Searches for first name only
LAST: Searches for last name only
USER: Looks for the username. You may enter the full address
(USERNAME@NODE) or just the username.
NODE: Will locate all users at a specific location
FIELD: Searches the keyword fields for matches
Examples:
SEARCH/NAME John Doe SEARCH/NODE Drew
SEARCH/FIELD physics
SEARCH/USER JDOE
* REMOVING YOURSELF FROM THE SYSTEM: If you want to remove
yourself from the NAMESERV database, simply send the server the
REMOVE command.
1
Page 10
This program was written by Drew junior Jac Fried. Jac spent
several weeks this summer designing and programming this
innovative feature. If you have any suggestions or comments
for Jac, please send him mail, his address is JFRIED@DREW.
*********
* * The BITNET Board Report
* *
* * by the BITNET Board of Trustees
* *
* * from BITNET Board Newsletter
* *
* * Send your comments to BOARD-L@BITNIC
*********
* BITNET/CSNET MERGER STUDY: Gillespie, Folkner and Associates
have been hired to identify the potential costs and benefits of
a BITNET/CSNET merger. They have been engaged in this work and
are expected to produce their report in August. A review of
the report is scheduled for August 24 and will be reported on
separately.
* MEMBERSHIP IN BITNET VERSES OTHER NETWORKS: The Board
discussed briefly the possibility that some prospective BITNET
members may not join BITNET since they may be able to obtain
many of its benefits via gateways to other networks. The Board
feels very strongly that membership in BITNET conveys real
advantages, and also notes that the BITNET advantages could
disappear if many institutions chose not to join (!). This
issue is one of the primary reasons for studying a possible
merger with CSNET. The Board has resolved to draft a paper
outlining the advantages of BITNET membership to inform
prospective members and to focus its thinking on the strategic
issues which BITNET must preserve.
* NETNORTH, EARN AND OTHER COOPERATING NETWORKS: Many sites in
foreign countries have connected to BITNET over the last year
and more continue to apply. The Board has concluded that it
does not make sense for BITNET to accept membership by sites
from foreign countries, except as an interim step. Instead we
wish to encourage a model of regional "cooperating networks"
with membership rules conformable to BITNET such as EARN and
NetNorth. Among the issues motivating this conclusion are
minimizing communications costs and encouraging self-
sufficiency in the regional networks for management of node
tables and other NIC support.
1
Page 11
To this end the Board has drafted a "Cooperating Network
Agreement." A number of Persian Gulf institutions had applied
to BITNET for membership; assuming their membership rules prove
to be conformable to BITNET's, our expectation is that rather
than membership in BITNET per se, we will execute a Cooperating
Network Agreement with "GULFNET." The number of institutions
already connected, or expressing interest in connecting to
BITNET in Japan, and in various Central and South American
countries suggests that both of these regions may also be
maturing toward eventual status as cooperating networks,
assuming those foreign institutions agree.
* "BITNET II" PROJECT / BITNET DISCOUNT AGREEMENTS: Ira Fuchs
reported to the Board on the progress of the BITNET II
research. An overview of the BITNET II project and its current
status has been prepared as a separate paper and is available
from LISTSERV as BIT_II INFO.
Related to the BITNET II research is an effort by BITNET to
make the equipment required for a BITNET II installation
affordable. Early this year, BITNET announced an agreement
with cisco Systems offering a substantial discount (30%) on
cisco products used to enhance BITNET connectivity. In July,
BITNET announced a second vendor discount agreement with Bus
Tech Inc. for an IBM channel/ethernet interface at a very
attractive price ($5,900). BITNET BIRs should have received a
mailing on this offer directly from BTI.
These two agreements help to make the IP router and the
ethernet interface required for implementation of BITNET II
affordable. We are now actively negotiating for an excellent
price on a high performance modem to complete the required
equipment.
* NETWORK USAGE ISSUES: Over the last year a number of usage
issues have come up which suggest BITNET needs to re-examine
its usage rules. For example, current rules prohibit the
shipping of "proprietary software," yet copyrighted software is
shipped over BITNET regularly; rules prohibit commercial use of
the network, but some members would like to see limited
software support available over BITNET; rules prohibit
commercial use of the network but, at members request, the
Board has agreed to a trial allowing a commercial service to
forward mail into and out of BITNET. CSNET allows commercial
membership - any merger would require BITNET to understand well
the basis for its current rules, that is, which rules might be
usefully relaxed and which maintained. To this end, the Usage
Committee has been charged with drafting a discussion paper on
usage issues. As soon as a draft has been reported out of the
Usage Committee, it will be posted to the NIC with notification
to BITNEWS to solicit membership as well as Board comment.
1
Page 12
* BITNET FINANCIAL STATUS: Due to rapid membership growth and
the open NIC manager's position, BITNET has a surplus for
FY87/88. This surplus will grow slightly as delinquent
membership fees are collected (there are not many
delinquencies, but there should be none!).
* THE NETWORK INFORMATION CENTER: In April, the BITNET Board of
Trustees sent out a User Survey to over 300 BITNET
Institutional Representatives. While participation was
disappointing (only 49 BIRs responded), the survey proved
useful in several respects.
The Board is working on a new service agreement and will use
the feedback from the user survey to ensure that the NIC
service priorities are consistent with the views of the users.
Specifically, the responses indicated a need for more detailed
"new user" documentation, better communication between the
Board and members, and more technical expertise at the BITNET
Network Information Center. Also listed as priorities were a
directory of users, LISTSERV expansion, domains, a move to
TCP/IP, and consolidation of networks.
The Board discussed the open NIC Director position and agreed
that, in the face of the continued growth of BITNET membership,
this position should be full-time. The Board then approved the
current level of NIC service for the coming year (and the
corresponding budget), but charged the Services Committee to
examine whether additional services may not be required as
well. The Services Committee is also to recommend how any
additional services might be provided; for example, it may be
appropriate to sub-contract "one-time" or short lived services
rather than budget permanent staff for them at the NIC.
1
Page 13
*********
* * Headlines - smaller pieces of news
* *
* * by Christopher Condon
* *
* * Yale University
* *
* * Send them to BITLIB@YALEVM
*********
* Good Reading: The University of Texas System Office of
Telecommunication Services' July 1988 edition of the "Users'
Directory of Computer Networks Accessible to the Texas Higher
Education Network Member Institutions" is now available. This
directory contains general, host, domain and contact
information, maps, an electronic mail tutorial and an
organization index for networks such as ARPANET/MILNET, BITNET,
SPAN, CSNET, ESnet, HEPnet, MFENET, NSFNET, SPAN, THEnet,
USENET/UUCP and Internet Domains. The purpose of the directory
is to ease the difficulties of working with various networks by
providing complete host and domain lists.
In addition to the hard copy version, there is an on-line
version available to Internet users via anonymous FTP to
EMX.UTEXAS.EDU. The printed version of the directory differs
from the ftp version primarily in the inclusion of maps and
fancier formatting of the tables and host information. The
printed version can be ordered for $15 (please add $2 for
postage and handling) from:
The University of Texas System
Office of Telecommunication Services
Balcones Research Center
10100 Burnet Road
Austin, Texas 78758-4497
Thanks to Tracy LaQuey for this information.
* LISTSERV news: Two new LISTSERVs are up and running:
LISTSERV@ALBNYVM1 and LISTSERV@UWAVM. Thanks to Jim Derost and
Ben Chi for this update.
* New name servers: Two new name servers are up and running,
but we were unable to acquire documentation in time for this
NetMonth. Dare we say it? The links were down. They will be
covered in detail in the next issue. In the meantime, the
servers are:
WHOIS @ ALBNYVM1 - State University of New York at Albany
INFO @ IRUCCIBM - Cork University
1
Page 14
Both of these servers accept commands via mail or message.
Thanks to Terry Sommer and Ben Chi for the information.
* EDUCOM to Move Offices and Explore Mergers: EDUCOM, a
consortium of more than 500 colleges and universities involved
in computing, will move its headquarters from Princeton, N.J.,
to Washington this fall. The move is designed to make it
easier for EDUCOM to work with federal government agencies and
other higher-education organizations, said Kenneth M. King,
president of the consortium.
The principal issue that requires the move, Mr. King said, is
"the requirement to raise on the order of $100-million a year
for the next 10 years" to establish and operate a national
network for instruction and research.
EDUCOM's efforts to improve integration of computers in the
curriculum also requires working with organizations
representing academic disciplines as well as organizations of
college presidents, he noted.
EDUCOM is also exploring mergers with both the Interuniversity
Consortium for Educational Computing and CAUSE. The 28-member
I.C.E.C. works with computer manufacturers and software
publishers to encourage the development of machines and
software appropriate for higher education, and has developed
software for advanced computing in education.
CAUSE, which has about 700 members, is a consortium based in
Boulder, Colo., that focuses principally on administrative-
computing issues. EDUCOM works predominantly on academic-
computing issues.
"The networks on campuses and the microcomputer revolution are
bringing administrative and academic computing together," Mr.
King said.
"As one organization," he added, "we could address the whole
spectrum of university technology issues."
Õfrom The Chronicle of Higher Education, July 20, 1988å Thanks
to Lee Wolfle.
1
Page 15
*********
* * Helpdesk - a Question and Answer Column
* *
* * by Marc Shannon
* *
* * Carnegie Mellon University
* *
* * Send your Questions to HELPDESK@DRYCAS
*********
My, my, how time flies when your world is changing rapidly
around you. I've now switched jobs, been "awarded" a beeper
(to make me one of the few local miracle-workers-on-call), and
managed to find myself desperately in need of a vacation. I
think I may survive long enough to finish up this (belated)
column...
First, to those of you whose mail to HELPDESK was rejected, I
have fixed up the mail setup on DRYCAS. It seems that a
"feature" of VMS MAIL which worked under VMS V4.x no longer
works with V5.0. These are the trials and errors from which we
all learn.
Here are some questions which are on file...
*Q* Who maintains the actual physicals network of links? IBM?
*A* As you may know, each link on BITNET has a direction
toward the hub, CUNYVM. Each site which connects to BITNET
makes a link to a node which has a link to another node (which
has another link to another node...) which all finally end up
at CUNYVM. The site which makes this new connection will pay
for the line (generally a leased-line via the local phone
companies) and also the hardware to connect at both ends
(usually a pair of high speed modems).
Each site, when connecting to BITNET, is required to provide
service to connect an additional node to that site. This
provides for continual expansion of BITNET (although many
theorize that BITNET is too large already).
The international link between CUNYVM (actually CUNYVMV2) and
FRMOP22, in the past, was paid for by IBM. Due to budgeting
restrictions, IBM discontinued monetary support for this link.
It is now being paid for by EARN (the European counterpart to
BITNET).
1
Page 16
*Q* When a link goes down, who/what's usually at fault?
*A* There can be many reasons why a link is not working.
First, let's look at the different "states" of links in an NJE
network (which BITNET is)...
CONNECT: Both sides have negotiated the appropriate networking
parameters and have made a successful connection. (Since no
communication goes over a link unless there is data queued for
that link, it is possible for a link to show up as CONNECT when
it isn't. When one side attempts to send data to the other, it
will then change the link status.)
ACTIVE: The side of the link which is ACTIVE is ready to
connect to the other side but is not able to reach the other
end of the link. Often, one side of a link will show up as
ACTIVE and the other as INACTIVE. (Sometimes both sides of the
link will show up as ACTIVE and not be able to connect. This
is often due to a synchronization problem and can be fixed by
restarting both sides.)
INACTIVE: INACTIVE links are "shutdown". No attempt to
communicate with the remote computer is made.
If a link is INACTIVE ("FROM WVNVM: LINK OHSTVMA INACTIVE")
then WVNVM, in this example, is "at fault" and they would need
to start the OHSTVMA link.
If a link is ACTIVE ("FROM PSUVM: LINK CUNYVM NOT CONNECTED")
then it is generally assumed that either there is a
communications problem (the leased-line or the modems are out
of service) or that the other side of the link (CUNYVM->PSUVM)
is INACTIVE.
If the link state is CONNECT but no traffic seems to go through
properly (it may appear to be a black hole and not respond with
any error though you do not get any response to your commands
or messages), there is most likely some connectivity problem
which the local system has not yet determined or resolved.
System programmers and data communications people would need to
properly identify the problem in such a situation.
1
Page 17
*********
* * New Mailing Lists
* *
* * by Rich Zellich
* *
* * from List of Lists
* *
* * ZELLICH@SRI-NIC.ARPA
*********
AVIATION
Aviation discusses topics of interest to pilots, including
training systems, laws affecting availability or usability of
airports, planes, and procedures, characteristics of aircraft
and avionic products, comments on commercial aviation, such as
safety and convenience issues, occasional advertisements for
fly-ins or similar private pilot activities, historical notes,
whatever else the readership wants.
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to AVIATION-
REQUEST@MC.LCS.MIT.EDU.
Coordinator: Oded Feingold
|