|
|
|
|
|
|
|
|
NetMonth, September 1987
* * * * *
** * ** ** *
* * * * * * * * * * *
* * * ***** ******* * * * ***** ****** ******* ******
* * * * * * * * * * * * * * *
* * * ******* * * * * * * * * * *
* ** * * * * * * * * * * *
* * ****** * * * ***** * * * * *
* *
* The guide to BITNET servers and services *
* *
* Volume 2 Number 3 September 1987 *
* *
*****************************************************************
* *
* Editor: Chris Condon CONDON@YALEVM *
* Assistant Editor: Steve Sutter SUTTER@YALEVM *
* NetMonth Staff Supervisor: Gary Moss MOSS@YALEVM *
* *
*****************************************************************
* *
* ---- *
* ---- ------ ----- *
* ------ ------- ------- *
* -------- ------- ------- *
* -------- ------- -------- *
* -------- -------- --------- *
* ------- -------- -------- *
* ----- -------- -------- -------- *
* ------- -------- -------- --------- *
* -------- -------- -------- -------- *
* -------- -------- -------- -------- *
* -------- -------- -------- --------- *
* ------- -------- -------- --------- *
* -------- ------- -------- -------- *
* -------- ------- ------------------ ----- *
* ------- -------- ------------------ ------ *
* -------- --------------------------- ------- *
* ------------------------------------ -------- *
* ----------------------------------- ------- *
* ----------------------------------- -------- *
* ----------------------------------- --------- *
* ---------------------------------------------- *
* --------------------------------------------- *
* ------------------------------------------ *
* ---------------------------------------- *
* -------------------------------------- *
* ----------------------------------- *
* ---------------------------------- *
* ------------------------------ *
* -------------------------- *
* ------------------------ Look Ma, no hands! *
* ----------------------- *
*****************************************************************
1
*************************************************************************
* Contents *
***************************************************************************
Bitnotes ................................................................ 1
TAKE NOTE__________________________________________________________________
Scuttlebut .............................................................. 3
The CODATA Network Directory ............................................ 4
FEATURES___________________________________________________________________
CSNET Merger Discussions ................................................ 5
SERVERS AND SERVICES_______________________________________________________
Network Audio Bits: A New Electronic Magazine .......................... 11
DIRECT@QZCOM ........................................................... 13
Summer Brings Changes to Comserve ...................................... 17
NAMESERV@UNCAMULT ...................................................... 23
DEPARTMENTS________________________________________________________________
Feedback ............................................................... 24
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. The BITLIB system is now distributed to more than
thirty educational institutions worldwide.
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: 1324 >----------------------------
A publication of the Bitnet Services Library "Because We're Here."
1
Page 1
*************************************************************************
* Bitnotes Issue 14 *
***************************************************************************
"Invention breeds invention."
- Ralph Waldo Emerson
It isn't the dark that scares me, or heights, or even large crawling
insects. It's Listserv. Oh, it's not the screaming-meemies kind of
scared, it's more of the "feeling of dread and uncertainty" variety. It is
the sort of feeling you can't describe because it originates in your
intestines, not in your head.
No, that's not gas. It's a gut feeling.
This is confusing because I rather like Listserv. Surely it has been a
great help to me in the distribution of NetMonth and BITLIB, saving me
several hours worth of mailing list maintainence each week. It has quite
literally revolutionized communications in BITNET, making relatively
efficient user forums and mailing lists a reality. Listserv has been very
good for BITNET. Why should I be scared?
Perhaps a story would clarify my frame of mind: Once there was a file
server named TCSSERVE@TCSVM. The server was fairly popular and prospered.
Several months later, a Listserv was installed at that node. Another few
months went by and TCSSERVE was installed as a subserver of the Listserv.
Now, there is no more TCSSERVE.
Now, I know that that this is a competative world, but the pattern is
likely to repeat itself. UTCSERVE@UTCVM became a subserver of Listserv, as
did SILMARIL@FINHUTC. Why? Becuase these servers performed nothing more
than a standard file server function which could be adequately performed by
Listserv. As a result, however, they became stripped of their identities.
Listserv is a fine tool, but it is not a replacement for a file server.
The popularity of the system should not preculde the development of new and
better servers.
*****
Speaking of new and better servers, I recently saw one of the best ideas to
come to Bitnet in a long time. That is, a Comserve User's Guide. This may
not be an object of incredible significance, but it is a great attempt to
popularize the use of BITNET. The guide, written by Timothy Stephen and
Teresa M. Harrison, is geared toward the Communications scholar or student
who has never used BITNET before. It explains what BITNET and Comserve
are, and the proceudres for contacting the server and sending commands. It
1
Page 2
is a good 56 pages long, in a very nice laser printed typeface. Free copies
of the Comserve User's Guide are available by writing to:
Comserve
Department of Lang., Lit., & Communication
Sage Labs
Renssalaer Polytechnic Institute
Troy, New York 12180
Or, you can send mail to SUPPORT@RPICICGE.
COMSERVE@RPICICGE is supported by the Eastern Communication Association,
the International Communication Association, and Renssalaer Polytechnic
Institute.
******
On a thankfully lighter note, here is something from our own Josh Trupin:
"The Top Ten Relay Pickup Lines"
10. Say, do you come to this channel often?
9. I'm on channel 169...wanna join me?
8. Hi! Ever heard of compusex?
7. I just read your ID....it's so beautiful.
6. What a coincidence! I used to date a girl with blond hair..once..*sigh*
5. We're only 16 hours apart...hey, wanna meet in Binghamton sometime?
4. You have a dog too? We must be kindred spirits!
3. I've always thought that Lisa was a pretty name.
2. I have a confession to make...I'm really a guy.
And number ONE......
1. Your eyes must be pretty....say, what color are they?
Until next time, stay out of trouble.
Virtually,
Chris Condon@YaleVM
----- -- ---- -- -- - --- -- - - - - ----
------- ---- ------ ---- --- - ------ ---- -- --- -- -- -------
------- ------ ------- ----- --- - -------- ----- ---- --- --- --- --------
1
Page 3
*************************************************************************
* Scuttlebut *
***************************************************************************
* TCSSERVE lives no more: The subserver of LISTSERV@TCSVM recently
discontinued service. TCSSERVE was originally a file server, and was later
moved to Listserv. Thanks to Mike Ayers for this information.
* A new Netserv: The latest in NETSERVs is now operation at University of
California, Berkley (UCBCMSA). Thanks to Rocky Waters for the news.
* Oh-no-not-again Department: Please note that the files
COMPUTER TAG
README TXT
COMPUTER FUK
READ TXT
FATE LET
are being circulated as 'chain letters'. If you receive one of these
files, s delete it. Do NOT send it on to your BITNET friends.
* Bitnews becomes a LISTSERV List: BITNEWS (the electronic newsletter of
the BITNET Network Infomation Center) is migrating to LISTSERV at BITNIC.
As a LISTSERV list, BITNEWS@BITNIC is open to all for self subscription.
New postings to the BITNEWS list will only be sent by the Editor, Michael
D'Amore or his staff. BITNEWS@BITNIC is not a discussion group. It is the
BITNIC's official electronic news distributor. Other list names will be
given with each contribution as a suggested location for further discussion
of the entry. Finally, if you missed an entry, the news is still available
in public notebook form grouped by month on LISTSERV@BITNIC. Postings will
continue to be sent to both BITNEWS@BITNIC and to the files on NICSERVE for
the months of September and October.
* POLICY-L born from BITNET Technical Meeting: A new list called POLICY-
L@BITNIC is open for self subscription. This forum was created by request
of the people attending the BITNET Technical Meeting in Chicago. The list
description provided below was written by Paul Jones (ULTIMA@UNC).
POLICY-L is a forum in which proposed and present BITNET policies are
discussed. It is intended to be a catch-all forum in part to fill in the
spaces left between other list (Domains, Future, Node Management, etc.) and
in part to provide a "birth place" for new discussion groups. An important
function of the list is to allow for a dialogue among systems grunts,
liaisons, managers, and BITNET directors (in short a unifying list).
----- -- ---- -- -- - --- -- - - - - ----
------- ---- ------ ---- --- - ------ ---- -- --- -- -- -------
------- ------ ------- ----- --- - -------- ----- ---- --- --- --- --------
1
Page 4
*************************************************************************
* The CODATA Network Directory *
***************************************************************************
by Elaine Ross ERM@NICHU
The CODATA Network is an international communications network set up on
Dialcom (system 42). It has been established for scientists and engineers
to communicate worldwide. There are several services available through the
CODATA Network, but the major ones are database services (which at present
include catalogues of the American Type Culture Collection; Hybridoma Data
Bank Directory of commercial monoclonals and hybridomas; Microbial Strain
Data Network Central Directory); electronic mail and computer
conferencing. The users of the CODATA Network are around 150 at present
and this number is slowly increasing.
The main users of the CODATA Network are quite varied in both scientific
and technical disciplines and geography. The main groups are as follows:
- CODATA Exec. Board & Committees (Task Groups) A number of Task Groups of
CODATA are using the CODATA Network such as the Protein and Nucleic Acid
Sequence Data Bank Coordinating Task Group; the MSDN Task Group; the
Hybridoma Data Bank (HDB) Task Group.
- The MSDN Secretariat is responsible for system management of the CODATA
Network and is encouraging the participation of microbial resource centres
throughout the world.
- The American Type Culture Collection (ATCC) has several catalogues on the
CODATA Network, including the ATCC Cell Lines Database, and the ATCC
Protozoa and Algae Database. ATCC can be contacted for information or to
place orders for cultures through the Network.
- Users listed in the CODATA Directory are involved in many areas
Biomedical, microbiological, and other departments in educational
establishments and industry; the International Council of Scientific Unions
and the International Union of Biological Sciences are represented, aswell
as the Society of General Microbiology Computer Club in the UK and the
Microbiology Computer User Group in the US. Many other disciplines are
represented. Users are from over 20 countries, including UK, USA, Canada,
Australia, Japan, countries from Central and South America, and Europe.
- The CODATA network is currently set up on a US Dialcom system. Plans are
active to set up another system on UK BTGold. Users will have ID's for
both systems listed in the CODATA Network directory and will be able to use
either or both systems.
To use the CODATA Network services, there is a one time subscription fee of
$25.00. Please do not hesitate to contact me (Elaine Ross, Dialcom
42:CDT0001 or Bitnet URM@NIHCU) for further information.
1
Page 5
NOTE: To send a message from Bitnet to Dialcom use the following
procedure:
At the To: prompt, enter INTERMAIL@ISI.EDU
After you have entered the subject and before the text of the messaege
leave a BLANK LINE, then on a new line enter:
FORWARD: NSF-MAIL
TO: 42:CDT0001 (OR THE ID OF THE MAIL RECIPIENT)
Leave an additional blank line, then enter the text of the message indented
one space and send as usual.
*************************************************************************
* CSNET Merger Discussions *
***************************************************************************
from Various Listserv Lists
* I attended a pretty interesting session about BITNET yesterday. it was
presented mostly by Michael D'amore the BITNIC director at Educom.
According to him:
1. There is a good chance that BITNET and CSNET will merge. The management
may merge before the year ends. Physically merging the two networks will
take much longer. There are some technical and policy difficulties in the
merger. CSNET is basically a star network with nodes periodically calling
up on the phone to collect their mail (and files?). BITNET lines are always
(almost always) connected and the network isnt a star. CSNET also charges
on a per-piece basis, but BITNET is free except for the dues and line
charges. almost all the csnet users are faculty. It's my guess that right
now more students than faculty use bitnet.
2. BITNET is moving away from RSCS towards a "TCP/IP backbone". This will
either cause technical problems or screw smaller installations who can't
afford TCP/IP hardware and software. It will finally give bitnet users
access to FTP transfer as well as mail.
* It seems logical to me that our two networks could start to merge very
quickly and (probably) totally painlessly. A first start could be made by
establishing one or more stable gateways between the networks. From there,
TCP/IP and protocols could spread outwards through Bitnet with more, low-
level gateways as the new order took hold, until we became one, big, happy
network.
An additional thought, what would you all think about having two 'logical'
domains on this new network? These would probably not be physically
1
Page 6
separate domains, but could be domains for CS departments (from the old
CSNet and the old Bitnet) and a GENeral domain (for computer centers and
other sites from Bitnet).
* I have concerns of the potential merger. Besides the technical
questions, there is a lot of philosphical differences. Most Computer
Science departments have a hard time in accepting computing for other
departments. Bitnet has been billed as educational networking for the
entire campus. Unless there is some method for insuring that CSnet sites
are treated only as another node (yes node) at an institution, I have a
great deal of trouble, and will reccomend voting against any such merger.
I also find it difficult to believe that even a merger of the boards could
happen without a vote of the BIRREPs. That is drastically changing the
makeup of the bylaws of Bitnet, Inc.
Such a merger will also not automatically get a technical NIC.(CIC) The
budget for Bitnet was voted on by the board. They set a low budget to keep
the fees low. It doesn't take a merger to get a technical NIC. it takes
$$$. A merger without increasing fees may mean that CSnet users will lose
a technical CIC, and have a NIC.
I also think many people are being unfairly critical of the NIC. They
have people pulling them all which way. They are not perfect, but neither
is anyone else. I have seen improvements, but it must be hard for them to
be motivated, because no on the net every say a good word about them when
they do something right.
I am also not convinced of the merits of converting to a TCP/IP network.
Much of the growth of Bitnet recently has been in the smaller school
environment. Money is a bigger issue to them. Is it ethical to get them
signed up now, take their money and get them interested, and then pull the
rug out by changing the protocol, forcing new purchases of software and/or
hardware? Bitnet is growing because it is easy to join and become active.
Do we really want to stifle that?
As a growing network, it is running into many problems, but let's not
forget what got us here.
* I am not directly involved in any of these decisions, but I agree with
what XXXXX says. Obviously, we get what (or thereabouts) we pay for. If
we decide that it is worth our money to keep up a technically oriented
NIC/CIC, we will probably pay for one. Of course, this brings us to one of
Harry's other points...
I can't say that we are such a small school or hard-up for money here
(because I don't know the big picture, and the small picture looks pretty
good), but if the whole network were to migrate to T1 links and new
hardware, I'm sure our administration would have some serious doubts. On
the other hand, with upward migration of computer equipment all around us
1
Page 7
(including smaller schools, I think) is new equipment going to be that much
of an imposition? I'd say it would be part of a natural, upward migration
in computer and networking power.
* Your concerns are absolutely reasonable and I believe must be fully
addressed by any merger plan with hopes to succeed. Let me respond to a
number of them from my personal point of view:
1. Definate philosophical differences exist between CS departments and
their institutions at many schools. Both side are concerned that they not
lose in any merger. But a network, after all, delivers a prescribed set of
services. If Bitnet's current services were augmented by remote login, the
two network's services would be conformable. We need to anticipate
possible consequential capacity problems but that is a manageable exercise.
Regarding capacity, we would also need to see that CSNET demand would not
overwhelm BITNET capacity. Again an issue, but one that can be managed. I
would see CS departments as just another node at an institution, but CS
(and/or other science and engineering departments) would be represented on
any governing board along with "institutional representatives."
2. Legally a merger could take place without a vote of the Bitnet IRs. To
do so without a public announcement/debate would be strongly counter to the
spirit of BITNET; whether an actual BIR vote would be appropriate would
depend in my mind on how controversial an eventual plan might turn out to
be. It is plausible to me that a plan could be advanced that would be
clearly appropriate and the BITNET board might therefore act accordingly.
Regarding the noted possibility that the boards might merge as early as the
end of this year - that is logically possible, but there is much work to be
done. It would not be appropriate in my mind to merge the boards until a
blueprint for the result has been prepared, distributed and discussed.
After consideration, in other words, it becomes obvious that a merger of
the boards could not be achieved in so short a time.
3. Agree a merger would not in and of itself do anything but possibly
confuse the NIC issues. This needs to be addressed in a merger plan.
4. I do not expect that BITNET would have to "convert to TCP/IP." It is
obvious to me that BITNET must use better technology than plain RSCS,
however, and TCP/IP as a backbone protocol and/or between "consenting
nodes" could address two critical technical issues: the proliferation of
nodes in a raw RSCS network (the TCP/IP backbone would presumably take
advantage of domain addressing), and dynamic routing and re-routing for a
network that would have redundant links. In my opinion any acceptable
merger plan must recognize the value to BITNET and of BITNET to the
"smaller institutions" (read non-CSnet institutions). It would be
unethical to require anyone to convert from RSCS unless and until
reasonable alternative tools were available, and even then only after a
reasonable period of time to allow migration. I do not believe a merger
would require any conversion from RSCS in the near term (two years? even
longer?).
1
Page 8
It seems obvious to me that for such a merger to succeed it is incumbent on
the two Boards to develop a proposal, to publish it and allow for community
comment and improvement, and only then to determine an appropriate decision
strategy. To date, a joint committee of the two boards has found a merger
to be feasible and is doing further investigation which is why nothing has
been published yet. Given what I know to date I believe a merger is
conceptually in BITNET's interest and that the details can be worked out to
our mutual satisfaction. I expect we will discuss this subject at the next
BITNET board meeting, on Oct. 26th in Los Angeles (just prior to EDUCOM -
meeting just set, a BIR announcement should be sent out shortly).
* BITNET is basically an IBM network. Computer Science departments tend not
to be IBM shops. That is the single bigest difference between CSNet and
BITNET.
Because of the "normal" problems associated with IBM interactive computing
(if you don't look mean and green I won't talk to you), CS departments have
tended to be DEC departments. Similarly, CS department tend to believe
that computing is something that should be there and that they should be
allowed to use it and not have to fight with payroll or accounts payable
for CPU cycles. Around here our Computer and Information Science Department
not only has more machines and more CPU power than any other University
dept, but they also have more $$ invested in computing than anybody else,
including the 3091 shop in the School of Arts and Sciences.
Computer Science Departments tend to have been using networks and
networking, especially electronic mail, for much longer than the rest of
the world. Consequently, they tend not to have time for those who can't
talk to the ARPAnet. As BITNET was created to link together several IBM
computers, CSnet was created to like together those who didn't have ARPA
contracts, but wish they did.
(Please realize that all of the above are gross generalizations, but based
in truth.)
The CIC is a technical NIC. It is not a sales force. As such the CIC is
more expensive to operate than BITNIC. But the board, even spending the
same number of dollars, would be buying DIFFERENT services from the CIC
than they are buying from EDUCOM. For one thing the CIC (BBN) has the
technical capabilities in place, EDUCOM would have to go out and hire them.
Many of BITNIC's problems are communications. Those of us who use the net
are not those who the NIC talks to. The NIC talks to the board who they
work for. Us grunts here in the trenches don't hear about anything they do
right. We only see what the problems are.
Again, going back to my first statement. TCP/IP is a major issue because
IBM didn't support it. Now they do, but it costs dollars. TCP/IP is not an
issue for NON IBM sites, it is FREE for any UNIX site and $6k list for any
1
Page 9
VMS site. Since we were able to negoitate a large discount with Wollongong,
I assume that EDUCOM could do the same, possibly even larger because there
are potentially more sales.
TCP/IP itself is obviously only an interum solution. Longer range, the
solution will be OSI, but that doesn't exist yet.
* Ah, but you forget who the CSnet CIC is - BBN! (Bolt Beranek and Newman)
The top communications consultants in the country? world? I think that you
will find that they have the "corporate" expertise necessary as well as the
necessary corporate contacts with IBM to "solve" the problems. I'm not
implying that it will be easy or that it will happen transparently. I also
don't think that it will happen overnight.
I think, however, that one of the major benefits will be that those sites
who are presently living in both worlds will not only have their lives made
easier, but be able to make the lives of the rest easier. Given such things
as adaptive routing, it would make far more sense to take a message bound
for someplace in California from New Jersey on BITNET through a gateway
bounce it off a NSFnet satellite, and back through another gateway in CA,
than to try to pass it through 20 nodes with 9600 baud land lines.
The trick will be "imagination" I don't think that any single existing
answer will solve the problems that ALL the networks face today. Too much
traffic for too little bandwith. Forget about cost, it's all expensive, the
question is really are you (whoever you is defined to be) willing to foot
the bill for something that will beat the Russians to the moon, or are you
going to try to put all your eggs in one basket and wind up giving
everything to ERISA.
Somebody wanted a non-political solution. Well the answer is either
political, ie, everybody (taxes) pays, or capitalistic - you get what you
pay for. I doubt that the majority of BITNET members would be members if
they didn't have a political side. After all how many users out there want
to use BITNET because DIAL-UP costs $$$$$$ for equilivant service. I'm not
talking about sites here, but the acutal end users. Lets face facts, ALL
computer networks are used to beat either the Phone Bill or the Postage
meter. It is a sad fact of life, but true. There are very few users, who
MUST use BITNET for what they do. Should BITNET, or NSFnet or ARPAnet even
exist? Those who opt for the "pure capitalism" should be using Tymenet or
Telenet, or some other PDN, rather than trying to circumvent them via tax-
exempt educational entities. (If BITNET is paying taxes, then somebody is
really off their rocker.)
* Changing the way BITNET does business by integrating it with TCP/IP or
converting to XYZZY simply can't happen overnight. But if a stone tablet is
handed down stating that thou shalt do thus and so, that's an
administrative solution, not a technical one.
1
Page 10
I don't have any hard facts to quote, I'm just working on some assorted
conversations and superimposing what I would do on top of them.
So with a little bit of imagination and some pixie dust, I propose the
following "administrative activities":
Playing games like adaptive routing or simply changing the topology and the
type of comm lines is probably something which could be done "immediately".
(How long does it take to get a T1 line and some modems?) (How often is
the LINKS file distributed?)
Maybe even code to recognize RFC822 addresses could be whipped up in sort
order and packaged as a "standard" mail interface that all BITNET sites
running all kinds of operating systems could install PAINLESSLY (or at
least shipped with a sufficient dose of novacane).
All you have to do is find out what the sites are running which process
RFC822 address, and then find out WHY the other sites don't run that code,
fix it and send it out. Simple enough? (I think the wheel was already
invented, you just have to tell people about it, recompile it, and maybe
write some documentation.)
Again except for the gateway, anything else will probably take 6 months to
a year to design and implement, let alone debug. But then they are not
really "technical problems", merely administrative details.
The "programming" has been done - all that's left is the "coding".
"Administrative" solutions are the only type which can be implemented in a
relatively short time, simply because the solutions are NOT technical, per
se.
"Technical" to me implies a truly unsolved problem requiring original
creative thinking not merely "engineering" or even "reverse engineering".
Hopper knows, there are enough of those out there to deal with without
forcing ourselves to re-solve solved problems. It is always interesting to
see how many solutions we forget in a short time, because they are not
"perfect" or "elegant".
Want to use the NSFnet backbone to move BITNET traffic... Just pump your
EBCDIC message (file) through a "quoter", package it into a bunch of
datagrams, bounce it off a satellite, "un quote" it and ship it back out.
The hop becomes "invisible" to BITNET, even though it happens to run via
some wierd network and protocol to get from point A to point B. Sounds
like an implementation of KERMIT to me. All you need is some CPU cycles...
maybe we could get a black box with some hot chip in it to act as the CPU
for the quoting and unquoting and packaging... hmm, sounds like we could
call it an Input Message Processor on one end and Incoming Message
Processor on the other, or IMP for short. The problem was solved once, just
fix it. (I know imps don't exist, but then again, niether do demons, but
the framework is there.)
1
Page 11
I don't say that any of this would be easy, I just don't think that any of
the above items requires much "thought", they are all implementation
problems which merely require a COMMITTMENT to acomplish. Once the boss
says "rewrite the mailer" then we can fight over doing it in COBOL or
FORTRAN, unless he says "rewrite the mailer in AUTOCODER", then we can tell
him he's nuts and go look for other jobs.
*************************************************************************
* Network Audio Bits: A New Electronic Magaine *
***************************************************************************
by Michael A. Murphy MURPH@MAINE
Network
AAA U U DDDD IIIII OOO
A A U U D D I O O
AAAAA U U D D I O O
A A U U D D I O O
A A UUU DDDD IIIII OOO
BBBB IIIII TTTTT SSS
B B I T S
BBBB I T SSS
B B I T S
BBBB IIIII T SSS
&
Audio Software Review
Network Audio Bits & Audio Software Review is an electronic audio
magazine devoted primarily to Compact Disc and Vinyl LP Record reviews.
All forms of music will be represented. So far reviews have covered
mostly Rock & Roll, Folk, R&B and Pop music. I hope to expand the
styles covered to include some Jazz music as well and hopefully someone
out there will feel inclined to contribute some classical reviews.
* Subscription Information
Subscriptions to Network Audio Bits & Audio Software Review are
available by sending your name and network address to
MURPH@MAINE.BITNET. Upon receipt of your mail, you will be added to the
subscription list and will have N-Audio Bits sent to you starting with
the next issue. New issues have been coming out at the rate of about 1
every 6 weeks. I hope to buckle down soon and make this a monthly
magazine. Should you lose your network access or have a change of
network address, please send mail to have your subscription address
changed or deleted.
1
Page 12
* Back Issues
Back issues of N-Audio Bits are available from the CSNEWS file server at
the University of Maine (CSNEWS@MAINE.BITNET). To receive a copy of a
back issue from CSNEWS you must send an interactive message to CSNEWS and
issue the command:
SENDME N-AUDIO BITSxxxx FROM EMAGS
where 'xxxx' is a 4-digit issue number. The entire issue number must be
specified, i.e. N-AUDIO BITS0003. If you are not able to request back
issues from CSNEWS or if you have problems requesting them from CSNEWS,
then send a mail file to me, MURPH@MAINE.BITNET and I can send you
copies of the back issues you desire.
* Submission/Review Policies
If you are interested in reviewing either audio hardware or software, feel
free to discuss the details of reviews with the editor. It would
probably be best to query the editor to make sure that the item you wish to
review is acceptable. Reviewers are encouraged to cover any and all types
of music. I would like to keep hardware reviews to a minimum, perhaps
one or two reviews per issue, as I would like to focus on audio software
and especially Compact Discs.
* Review Guidelines
What I look for in a review is writing that shows that you have not only
heard the album, Compact Disc or cassette which you are reviewing, but
that you have also listened to it. In the case of LPs and
Cassettes, I'd like to keep to recent releases for reviews. For CDs,
almost any review is welcome, as anything that is out on CD is a fairly
recent release and I'm interested in representing as many CDs as
possible in these 'pages'.
Here's what I'd like as a general format for reviews. All of the
information concerning the Disc or LP should be able to be found on the
album where all credits are given. The performance and sound quality
scales are your opinions.
REVIEW FORMAT
Title
Artist
Producer(s)
Engineer(s)
Label/Catalog #
Playing Time
Song Titles
Performance scale (1-10)
Sound scale (1-10)
1
Page 13
What format was reviewed (CD, LP, Cassette)
Release date
SPARS code (For CDs - will explain below)
The SPARS code represents a standard proposed by the Society of
Professional Audio Recording Studios (SPARS). Many CDs have this three
letter code printed somewhere on their information booklets. The three
letters correspond to the type of recorder used for recording, mixing
and mastering of the disc (analog or digital). For example, a disc with
the code "ADD" would show that the disc was an analog recording, mixed
and mastered digitally.
*************************************************************************
* DIRECT@QZCOM *
***************************************************************************
by Jacob Palme JPALME@QZCOM
A remote mail directory service is now available at QZCOM.BITNET.
The service allows you to send ordinary mail messages to QZCOM.BITNET, with
commands in the message text, to:
--> Search for the names of users and conferences (=distribution lists) in
QZCOM.
--> Find description and other information about users and conferences.
--> Add and remove yourself from conferences in QZCOM. When you add
yourself to a conference, messages entered into that conference will be
sent by electronic mail to your mailbox.
--> Retrieve certain files with help information.
* Where to send messages
Send your messages, containing directory commands, to DIRECT@QZCOM (for the
English language COM system at QZ) or to DIRECT@QZKOM (for the Swedish
language KOM system at QZ).
Directory requests are normally handled at nighttime, and responses
returned the next day by electronic mail to the sender of the request.
* Searching for names of users and conferences
This service allows you to search for the network mail names of users and
conferences. You can input a name pattern, and all names matching the
pattern will be found.
1
Page 14
Command syntax:
DESCRIBE (
|