|
|
|
|
|
|
|
|
VM/COM, August 1985
1
-
OO OO OOO OOO // OOOOOOO OOOOOOO OOO OOO
OO OO OO OOO OO // OO OO OO OO OO OOO OO
OO OO OO O OO // OO OO OO OO O OO
oo oo oo oo // oo oo oo oo oo
oooo oo oo // oo oo oo oo oo oo
oo oo oo // ooooooo ooooooo oo oo
0 ------------------------------------------------------------
August 1985 edition Volume 2 Number 3
- CsNews Network Newsletter
-
-
Staff:
0 Michele Robinson CSMICH at MAINE Editor
Andrew T. Robinson ANDY at MAINE CsNews Director
David Eckhardt DAE at PSUVAX1 Assistant Editor
Prof. G. Markowsky MARKOV at MAINE Faculty Advisor
-
0 Ôçççççççççççççççççççççççççççççççççççççççççççççççççççççççä
³ Newsletter article contribution Userid: CSNEWS@MAINE ³
³ ³
³ Contributions from readers welcomed and encouraged! ³
¨ççççççççççççççççççççççççççççççççççççççççççççççççççççççç]
1
0 Vm-Com Issue 2.3
-
0 Table of Contents
+ _____ __ ________
- Introduction to Vm/Com 2.3 . . . . . . . . . . . . . . . 1
CSNEWS Notes . . . . . . . . . . . . . . . . . . . . . . 2
BITNET: Is It Becoming a Restricted Area? . . . . . . . . 3
The CSNEWS Story . . . . . . . . . . . . . . . . . . . . 5
IBM's and VAX's . . . . . . . . . . . . . . . . . . . . . 8
An Efficient File Backup System . . . . . . . . . . . . . 10
A More Up to Date List of Servers . . . . . . . . . . . . 15
OpCodes . . . . . . . . . . . . . . . . . . . . . . . . . 16
A Recent Memo From a BITNAUTs Office . . . . . . . . . . 18
-
-
-
-
-
-
-
-
-
-
-
-
-
0 2
1
0 Vm-Com Issue 2.3
0 Introduction to Vm/Com 2.3
+ Introduction to Vm/Com 2.3
-
Once again I'd like to welcome you to another issue of
Vm/Com. Before your eyes you have issue 2.3. This time
around you will be seeing an article on where BitNet seems
to stand nowadays, an article on the creation of CSNEWS, a
discusion on problems between IBM's and VAX's, a description
of using tapes for backup, a list of servers and such
related things, and again a humor section containing more
OPCODES and a memo for employees that like to complain about
their working conditions...
0 Hope you like it... Send any comments to CSNEWS or
myself. We'd like to hear your opinions!! See ya next time!
0 Michele Robinson,
Editor
-
-
-
-
-
-
-
-
-
-
-
-
1
1
0 Vm-Com Issue 2.3
0 CSNEWS Notes
+ CSNEWS Notes
0 Andy Robinson (ANDY@MAINE)
-
Hello again! As you can see, we have begun to deliver
on our promise of a monthly Vm/Com. But that's off the
subject since I am here to talk about CSNEWS.
0 There are some things going on, believe it or not! Let's
start at the beginning (which is an arbitrary point in this
case)... If you remember the June issue (Vm/Com 2.1), we
welcomed David Gridley to the elite (cough cough) ranks of
the CSNEWS operator staff, as a restricted operator. Since
that issue, David has obtained a full-CMS id (as opposed to
his previous restricted account) and is a full operator. His
new ID is ICC020G@MAINE. Say hi to him sometime!
0 CSBB. The 'prepending' format of CSBB has been changed
to an 'appending' format. I.e., newer entries can be found
at the bottom of the CSNOTICE files instead of at the top.
This makes the perusal of chronologically oriented material
much easier in most cases. CSBB will also find your name in
the BITNAUTS list, and insert it into your entry, even if
your are not in the CSBB users list.
0 FLAME. Once again, I implore the users of our Forum to
keep it clean and non-personal. We had a FLAME war in July
over CSBB formats which was deleted because of its content.
Whatever you might think FLAME is, it is not a forum for
dragging other people through the dirt, or exposing dirty
laundry. You may not realize it when you send an entry in,
but several hundred people will probably read it, so make
sure you mean what you say. Police yourself, and make sure
you aren't slamming someone in the public eye.
0 Well, those are some of the highlights. The conversion
of CSNEWS software to Assembler is going slowly, but is
going. The work on the CMS user-friendly interface is
proceding at a reasonable rate, and should be done on
schedule in late August. I guess that is about it. So
goodbye for now, and I'll be writing you next issue!
-
-
-
-
2
1
0 Vm-Com Issue 2.3
0 BITNET: Is It Becoming a Restricted Area?
+ BITNET: Is It Becoming a Restricted Area?
0 Marvin Raab (MFRQC@CUNYVM.BITNET)
-
BITNET (Because It's There NETwork) joined the world of
academic higher education back in May of 1981 when Yale
University was linked to the City University of New York via
computer lines. For the first time, it was said that
researchers at these universities would no longer be
hampered by the eon-long problem of distance. Since that
joyous May day, BITNET has come a long way with the addition
of links to over 200 schools around the world.
0 Researchers and faculty members at some of the most
prestigious institutions of the world are now able to share
their work with each other in a matter of seconds.
Conversational abilities are also present; promoting free
and open exchange of ideas.
0 Whether it was anticipated or not, students at several
nodes have discovered the capabilities of BITNET. At first,
those who knew about it were content to merely converse with
their counterparts at any of the various other nodes,
obtaining ID's via the infamous "BITNAUTS MAILLIST", or from
simply sending messages to random nodes.
0 Unfortunately, but understandably, many nodes removed
the CPQ Names command forcing students to rely on the
MAILLIST...until some creative users had a lightbulb flare
up in their minds. This lightbulb led to BITNET conferencing
systems. As one can see, the capabilities of BITNET are just
beginning to be explored and tested.
0 But, there are problems. Many schools hide and/or
restrict student usage of BITNET. Some nodes have threatened
legal action if their link is ever used for "non-educational
purposes", while others simply change RSCS programs to
reject messages from non-authorized (i.e. student) users.
One node will not even allow users to receive electronic
mail.
0 And now, one node (which supports a conferencing
system) has removed the CPQ U command, eliminating the
ability to query any user at that node.
0 The very name of BITNET implies that it should be
accessible to all users, and not selectively and arbitrarily
restricted. Has anyone ever taken a survey of the number of
researchers who actually use BITNET? We have never heard of
any electronic communication between researchers at the
original two nodes. In contrast, we find over hundreds of
students whom have utilized BITNET for one purpose or
0 3
1
0 Vm-Com Issue 2.3
0 another. Who is to say that non-classwork does not fall into
the realm of education? While it cannot be guaranteed that
abuse and unethical use of the Network will not occur, we
can guarantee that BITNET has, and must continue, to bring
students together. There is so much to be learned about our
neighbors in other states, not even to mention abroad.
BITNET is a perfect vehicle for eliminating ridiculous
prejudices which have existed since the beginning of time.
Computers are rapidly changing the society in which we live
and the college students of today will be responsible for
the near future. They will need to know more than theory if
computers are to develop in a practical and healthy manner.
0 Although we understand the intrinsic problems behind
mass usage of BITNET for the purposes of idle chatting, we
cannot condone the restrictions which seem to be increasing.
We urge everyone who reads this to consider the problem at
hand and to reach a suitable solution.
0 Consider the following: by allowing BITNET to be
unrestricted, we are bringing the people of the world closer
together. This will inevitably lead to cooperation which may
very possibly help to solve some previously unsolvable
problems. Consider the following: there is at least one
marriage of two people who met because of the network.
Consider the following: some students are studying computer
science BECAUSE of BITNET. Consider the following: how many
successful systems programmers were hooked on computers
because of----------games (GASP!)
0 Please consider any and all alternatives before taking
the easiest and most obvious road: restriction.
-
-
-
-
-
-
-
- 4
1
0 Vm-Com Issue 2.3
0 The CSNEWS Story
+ The CSNEWS Story
0 Andrew T. Robinson (ANDY@MAINE)
-
From time to time it has been suggested to me that I
write a history of CSNEWS and its services. So here I am to
do just that.
0 Long, Long, ago (Spring Semester 1984 to be exact),
Barry Gates, Rick Fortin, and myself were struck with the
idea of writing a newsletter for the UMaine/Orono Computer
Science Students (Our computing center publishes a
newsletter, CAPSTAN, but it is not particularly student
oriented.) After a little wrangling around with possible
names and what not, I came up with 'Vm-Com', for 'Vm-
Communications'. We set about writing articles and about 2
months later, the first issue of Vm/Com was sitting on my
disk. It consisted of several articles oriented towards the
use of the (then newly connected) BITNET facility. The
story of CSNEWS had begun.
0 It was not long after we started compiling the first
issue of Vm/Com that it was decided that storing the letters
and articles on our own private disks was not going to do.
So I went down the hall to English/Math (which has NOT,
contrary to rumor, been renamed Neville hall!!) to talk to
the Chairman of CS, Professor Markowsky. I told him what we
were doing, and what we wanted. He gave it to us -- a
separate CMS machine on which to store/compile the
newsletter.
0 We sent the first issue of the letter out by PUNCH/DISK
DUMP. We had no public copy on a linkable disk. At first
this seemed practical, but as our reader base here at Maine
grew, we realized that the disk space being used to hold
multiple copies of Vm/Com was also growing. So back up to
Professor Markowsky with another request... this time we
wanted a mnemonic userid, VMNEWS, on which we could place a
single copy of the newsletter which would be accessible to
all local users by means of our CMS SHARE command.
0 This ID was generated while I was slaving away in
Quantico, VA, at USMC OCS. When I returned in July, I found
the ID waiting, and placed the letter and a few other
miscellaneous public files on its disk. Of course, there
were not many students around at that time, and it seemed
that further development efforts on Vm/Com would be delayed
until the fall semester.
-
- 5
1
0 Vm-Com Issue 2.3
0 The end of July came, and Barry Gates and myself started
experimenting with making VMNEWS a slave machine, on which
we could compile programs and do tape archival. Then we
started running an RSCS simulator on the id which faked most
common RSCS Networking commands for an imaginary node called
VMVM.
0 In the first few days of August, while Barry and I were
playing with VMNEWS, Barry suggested that we create a
BITNAUTS LIST maintainance server on our relatively
purposeless machine. A little background is in order here:
During the spring/summer months of 1984, the BITNAUTS LIST
was in turmoil. Its originator, Mat Terry at Cornell, had
given the list up because of problems on the BITNET. After
this, the list floated about to several different people who
partially maintained it. At one point, Walter Horbert
(WALT@MAINE) was keeping a 'diary' of BITNAUTS LIST
discussions and distributing them to anyone interested
(Earlier in the summer, as I found out, Steve Goldsmith
(SEGXU@CUNYVM) was experimenting with a BITNAUTS server
which did LIST updates in batch mode). Now we had a
permanent home for BITNAUTS.
0 The first things that were written were, strangely
enough, the BIT commands, which performed Updating/Searching
operations on the BITNAUTS LIST. Then CHECKIN/CHECKOUT/QBIT
were written. By the end of two days of development, we
started looking for people out on BITNET to test out our new
server. It worked. More and more people started using
VMNEWS, and word started to spread; the BITNAUTS list was
here to stay.
0 Development on VMNEWS proceded throughout the summer, as
we added new commands and consolidated old ones. Early on,
we made Geert Marien (GKMXU at CUNYVM) a VMNEWS operator.
The system was centralized, providing comprehensive error
recovery and allowing gathering of usage statistics.
0 Towards the end of August, VMNEWS was renamed CSNEWS by
the operations manager here at Maine. This caused no end of
confusion, but it all got sorted out in the end.
0 During these early days, Barry and I had to tread
lightly... CSNEWS had NO support from any level, including
the CS Department. We carefully ruled out services which
might jeopardize our new server, and attempted to think of
things that would enhance its surviveability on our system.
As time went by, we started getting more support (and most
important of all, more tolerance). Some of our computing
center officials were receiving mail praising a system that
they did not know existed!
-
0 6
1
0 Vm-Com Issue 2.3
0 Of course as time went on, use of CSNEWS increased many
fold. It now processes over 1200 commands per day for three
to four hundred users. At this time, we are undertaking a
re-write of CSNEWS software to make it faster and more
efficient, and to expand available services. Under the
auspices of CSNEWS Information Services, a new user-friendly
local interface is being funded for development this summer.
The little machine that was originally intended as extra
disk space has come a long way!
0 (Special thanks to all of you who were with us in the
beginning and are still with us now... You have made CSNEWS
what it is, as much if not more than those of us who wrote
it.)
-
-
-
-
-
-
-
-
-
-
-
-
-
- 7
1
0 Vm-Com Issue 2.3
0 IBM's and VAX's
+ IBM's and VAX's
Inter-species Communications on BITNET
+ Inter-species Communications on BITNET
0 Jim Blake (AS0JEB@BINGVMA)
-
0 At SUNY-Binghamton, we have five Bitnet nodes. Two of
these are IBM 4381's, and two are VAX's. The fifth one isn't
really there, and doesn't count -- It's a virtual node.
- The VAX's are tied to BITNET through a product called
JNET, which makes a VAX running VMS appear to be just
another RSCS node in IBM-land. In general, it works really
well. The users of the VAX's can send and receive messages,
and can send and receive print files and punch files. What
more could a BITNET resident want? A few things... I'll just
start with one.
- A common storage code would be nice. Since the JNET
software works so well,it is easy to forget that the RSCS
world operates in EBCDIC code, while the VAX's store their
data in ASCII. You can forget this because JNET performs an
automatic translation for you. Data coming to the VAX,
either files or messages, is translated to ASCII before you
ever see it. Data leaving the VAX is translated to EBCDIC by
default. Works fine, right?
- The problem arises when you start sending files that
contain things besides printable text. You wouldn't want to
send files containing object code, I suppose, but you might
want to send data stored in binary, or text files that
contain non-printing characters, or who knows what.
- I first encountered this question when I received a large
file in my reader in IBM's "netdata" format. Since I didn't
have room on my disk just then, and I feared for my reader
files (the system was a little shaky that day), I shipped
the file over to my account on the VAX for storage there
until I had room on the IBM to hold it. So far, so good. The
file was transferred nicely, and later I transferred it back
to the IBM, but when I then tried to "RECEIVE" it from my
reader, the machine just burped and smiled. To this day, I
have not been able to reconstruct the original file, and
have had to try reading it in the bizarre form it has now
reached.
-
0 8
1
0 Vm-Com Issue 2.3
0 What happened?
0 Well, the IBM "netdata" format contained a bunch of non-
printing characters. These are used by the RECEIVE command
to delimit the lengths of records and to indicate
compression techniques. These non-printing characters were
taken from the list of unused EBCDIC characters -- those
that have no preset meaning. Unfortunately, since these
characters don't have any meaning, they can't be translated
to ASCII. In self defense, the JNET software just turned
them all into ASCII blanks. Then, when I brought the file
back to the IBM world, they became EBCDIC blanks, but that
was not a lot of help.
- Did the JNET folks screw up? Not really. There wasn't a
lot they could do. They set up translations for all the
letter, numbers,and punctuation marks. They also took care
of all of the control codes; things like carriage return,
line feed, etc. The root of the problem really lies in the
fact that ASCII is a 7-bit code, and EBCDIC is an 8-bit one.
There are simply more character codes available to the
EBCDIC programmer than there are to the ASCII programmer,
and EBCDIC uses them, too. This is one reason why the DEC
people are starting to use 8-bit ASCII in their terminals --
they've run out of codes!
- To add insult to injury, I might add that it is possible
to prevent the translation from ASCII to EBCDIC for files
leaving the VAX. With the proper options, you can have your
file sent to IBM-land just as it stands. The catch is, there
is no such option for incoming files. So there you are, up
the creek. What good is it to be able to suppress
translation in one direction and not in the other? The net
effect is similar to that of WOM (write-only memory). I know
my file got sent OK, I just can't get it back.
0 The moral of the story? Networking software is like a pane
of glass; Even if it's transparent, you can still bang your
nose on it.
-
-
-
-
- 9
1
0 Vm-Com Issue 2.3
0 An Efficient File Backup System
+ An Efficient File Backup System
Using Tapes in Full CMS
+ Using Tapes in Full CMS
0 Sean Colbath (CPE07401@MAINE)
-
Many users over the years have found one major problem
with computer systems: There is never enough on-line space
to keep all of their files. Enter the magnetic tape. The
tape is an efficient, cheap source of data storage and
backup. One 2400 foot tape can hold the equivalent of 3600
boxes of cards. This great amount of free space lets the
programmer use the tape for data storage, archiving of old
programs, or backup as a prevention against accidental data
loss.
0 The TAPE command is available through CMSBATCH or CMS
to co-ordinate tape activities with the disk. It is
possible to dump the contents of a disk to tape, restore the
contents, scan the contents of a tape, or restore the
contents of one disk to another. First, it is necessary to
obtain a tape. Tapes come in two sizes: the mini-reel
(1200 feet), and standard size (2400 feet). Either of these
sizes should be sufficient for the average user. In some
cases there are smaller (600 feet) or larger (3600 feet)
sizes.
0 Now that you have obtained your tape, you will need to
select a density for it to operate at. There are three
standard tape densities: 800 bpi (bits per inch), 1600 bpi,
and 6250 bpi. The most common density is 1600 bpi, and your
tape and drive will need no prior adjustments to allow you
to read or write at this density. Densities as high as 6250
bpi are extremely space efficient, but there is usually no
need for the average user to work at this density. Also,
not all systems have 6250 bpi drives available, so it may be
advisable to check with your systems personnel to find out
which density is perferred.
0 Most computer centers maintain an extensive library of
tapes, and to use your tape it may be necessary to have your
tape put in this library (the Maine computer center, for
example, will accept no tape mounts through the dispatcher's
window). Once you have put your tape in the library, you
must communicate your desire to have it mounted (attached to
your virtual machine) to the operator. To do this, simply
use the CP MESSAGE command or the CMS TELL command:
0 MSG OPERATOR PLEASE MOUNT TAPE xxxxxx
ON 181 RING ring PASS yyyy
0 or:
- 10
1
0 Vm-Com Issue 2.3
0 TELL OPERATOR PLEASE MOUNT TAPE xxxxxxx
ON 181 RING ring PASS yyyy
0 Maine users should use the MOUNT command (NOT available on
other systems!) - for more information on MOUNT, type HELP
CMS MOUNT.
0 MOUNT xxxxxxxx ON 181 RING ring PASS yyyy
- where:
xxxxxx is the tapeid assigned to your tape by your
computer center.
0 ring is the read/write status of the tape. RING OUT
permits reading only, RING IN allows reading and
writing.
0 pass is the password you have chosen for your tape.
This should correspond to the ring, i.e. there
are diff. passwords for RING IN and RING OUT.
0 When the operator has mounted the tape on a tape drive (if
there is one available) and attached the tape to your id,
you will receive the message
0 TAPE 181 ATTACHED
+ TAPE 181 ATTACHED
0 and an informative message from the operator confirming the
id of the tape and the ring status. It is important that
you wait for the second message of the form
0 hh:mm:ss MSG FROM OPERATOR: Tape xxxxxx is mounted ring xxx
on your 181
0 before attempting to perform any i/o operations to the tape.
This is because the operator attaches the tape drive itself,
not the tape, to your id, and someone else's tape may still
be mounted on that drive. Users of the Maine system will
see a message in the format:
0 OP: Tape xxxxxxxx is mounted ring xxx on your 181
0 THE TAPE COMMAND
+ THE TAPE COMMAND
0 Once you have had your tape mounted, it is in the re-
wound position and (if it is ring in) ready to be written
to. Writing is performed with the TAPE DUMP command. With
the TAPE DUMP command, you may specify a filename, filetype
and filemode of the files you wish to dump (write to the
tape). These may be whole, partial (i.e. PROG*, all files
beginning with PROG) or just * (i.e. TAPE DUMP * * A,
dumping the entire contents of the A-disk.). It is the
latter method that is most commonly used. This method will
0 11
1
0 Vm-Com Issue 2.3
0 only work for the first DUMPing, until you have put some
files on the tape. At the end of each dump, the computer
writes a tape writemark (WTM). This specifies the ending of
one logical tape file. If you have just done a TAPE DUMP *
* A, the files may be arranged on the tape (schematically)
like this:
0 ³ program 1 ³ program 2 ³ program 3 ³ ³³ < the WTM
0 You may issue as many TAPE DUMP commands as you desire to
save as many files as you desire. However, a problem arises
the next time you wish to put more files on your tape. The
WTM (Write Mark) designates 'End Of Tape File', and for
every tape file, you must do a separate load, or scan, or
whatever, and if you forget to TAPE FSF (Forward Space File)
over the correct number of tape files you could accidentally
overwrite precious data. Therefore, the ideal system would
be to append to your first tape file. This is the method to
accomplish that:
0 M OP Please Mount.... < Request tape mount.
0 TAPE 181 ATTACHED < Now your tape is attached,
< and in a rewound position.
0 TAPE FSF < The TAPE FSF command (Forward
< Space File) moves the tape
< forward PAST the first WTM
< it finds.
0 TAPE BSF < The TAPE BSF command (Back
< Space File) moves the tape
< backward past the first WTM
< it finds. Now the tape is
< positioned for dumping, After
< the last file on your tape.
0 TAPE DUMP filespec < This dumps the new files,
< overwriting the old WTM, and
< creating a new one at the end
< end of your tape file.
0 Now the files on your tape look like this:
0 ³ prog 1 ³ prog 2 ³ prog 3 ³ prog 4 etc ³ ³³ < the WTM
0 The only disadvantage to this system is appending to
programs or over writing old versions of files. To do this,
you must acquire an appropriate amount of temporary disk
space, load all your files onto that disk (TAPE LOAD * *
fm), replace/append the ones you desire, rewind your tape
(TAPE REW), and dump the entire disk again (TAPE DUMP * *
fm). Exercise caution, however - all computer systems have
a limited supply of temporary disk space available. Once
0 12
1
0 Vm-Com Issue 2.3
0 your tape grows very large, it may be advisable to do this
at night, or at a time when the system load is low. If all
you wish to do is replace programs, you may use the first
method, and then when you issue a TAPE LOAD * * filemode,
all the old versions will be over written on your disk.
0 Retrieving files from tape is a much simpler process.
All you have to do is to have your tape mounted and issue
the TAPE LOAD command. the format is:
0 TAPE LOAD fn ft fm
+ TAPE LOAD fn ft fm
0 where the fm is the mode of the disk onto which you want to
load the files. NOTE: It is recommended that you define
some temporary disk space onto which to load the files
because the TAPE command will NOT inform you if it attempts
to over-write existing files with the same filename as the
one it is loading. This could defeat the whole process of
the backup. Also note that it is not possible to specify
partial filenames with the tape load command.
- This method is efficient if you wish to load all files
onto your disk. However, if you only wish to load one or
two, and you know in what order they reside on the tape, the
following procedure may be used.
0 TAPE REW < Make sure tape is rewound.
0 TAPE SCAN fn ft < Scan tape until fn ft is
< found. When you reach it, the
< filename and filetype will be
< echoed back to you.
0 TAPE LOAD fn ft fm < Now that the tape has been
< positioned by the scan, you
< may load your one specific
< file off. The TAPE command
< won't search the whole tape
< if no wildcards (*s) are
< specified in the file name
< or type.
0 This method is more efficient than TAPE LOAD fn ft fm
because of the method the tape command uses when loading
files. If you specify a file with no wild cards in it, the
tape command will load the first file on the tape, and
compare it with the file name and type you gave it. If the
names are not equal, it will erase this file. It then loads
the second file, and repeats the process. This can cause a
great deal of overhead due to the writing to disk. The TAPE
SCAN command is more efficient because no disk i/o is
performed.
- 13
1
0 Vm-Com Issue 2.3
0 The final commands I will discuss are the commands used
to rewind the tape and detach it. To rewind the tape, issue
the TAPE REWIND command. This rewinds the tape to the
beginning of the tape, leaving it ready to be read from or
written to again (surprise!). Once you have finished using
the tape, issue the command DETACH 181 . This detaches
the tape drive from your virtual machine, leaving it
available for the operator to assign to another user.
0 This article has barely mentioned the parameters of the
TAPE command. To find out more, simply issue the command
HELP CMS TAPE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
0 14
1
0 Vm-Com Issue 2.3
0 A More Up to Date List of Servers
+ A More Up to Date List of Servers
0 Chris Condon (BITLIB@YALEVMX)
- Active file servers:
0 BITSERVE at CUNYVM - Bitnet Support Center, USA
CANSERVE at CANADA01 - University of Guelph, Canada
CSNEWS at MAINE - University of Maine, USA
KERMSRV at CUVMA - Kermit Users Server,
Columbia Univ., USA
MACSERVE at BITNIC - Macintosh Users Server,
Bitnet Support Center, USA
NETSERV at CEARN - Centre Europeene Rechnerche Nucleare,
Switzerland
NICSERVE at BITNIC - Bitnet Support Center, USA
SERVER at TAMCBA - Texas A&M College of Bus. Admin., USA
SERVER at UOGUELPH - Univ. of Guelph, Canada
VMBBOARD at WEIZMANN - Weizmann Institute of Science, Israel
- Active name servers:
0 BITSERVE at CUNYVM - City University of New York, USA
CSNEWS at MAINE - University of Maine, USA
FINGER at CUVMA - Columbia University, USA
VMNAMES at WEIZMANN - Weizmann Institute of Science, Israel
- Electronic Magazines:
0 BITLIST - Back issues available from CANSERVE@CANDA01
and SERVER@TAMCBA
FSFNET - Back issues available from NMCS025@MAINE and
SERVER@TAMCBA
NUTWORKS - Back issues available from VMBBOARD@WEIZMANN
and SERVER@TAMCBA
VM/COM - Back issues available from CSNEWS@MAINE
- ARPANET Digests available from VMBBOARD@WEIZMANN:
0 AILIST DIGEST
CSNET-FORUM DIGEST
DEFENSE DATA NETWORK DIGEST
HUMAN-NETS DIGEST
INFO-GRAPHICS DIGEST
INFO-IBMPC DIGEST
INFO-KERMIT DIGEST
PROLOG DIGEST
SF-LOVERS DIGEST
SOFTWARE ENGINEERING DIGEST
WORKS DIGEST
0 15
1
0 Vm-Com Issue 2.3
0 OpCodes
+ OpCodes
0 Various and Assorted Creative Minds...
-
Yes once again, another edition of OPCODES!! Expect to
see this column often it'll be here for a good many
issues!!!
- ADB Another Damn Bug ÕUNIXþ
AGB Add GarBage
AI Add Improperly
BOP Boot Operator
BOP Byte Operator
BPIM Bury Programmer In Manuals
CAI Corrupt Accounting Information
CAF Convert Ascii to Farsic
CBS Clobber BootStrap
CCB Consult Crystal Ball
CFS Corrupt File Structure
CG Convert to Garbage
CMI Clobber Monitor Immediately
COMF COMe From
CRN Convert to Roman Numerals
CVFL Convert Floating to Logical
CVFP ConVert FORTRAN to PASCAL
CVG ConVert to Garbage
CWDC Cut Wires and Drop Cores
DC Degauss Core
DCI Disk Crash Immediate
DU Dump User
DWIT Do What I'm Thinking
DWIM Do What I Mean
EDD Eat Disk and Die
EP Eat Pizza
GCAR Get Correct Answer Regardless
GS Get Strange Õrandomly inverts bits being fed
to the instruction decoderþ
GSU Geometric Shift Up
HOO Hide Operator's Output
IIL Irreversable Infinite Loop
IMPG IMPress Girlfriend
IPS Incinerate Power Supply
KUD Kill User's data
LPA Lead Programmer Astray
LP%PAS Line Printer - Print And Smear
LP%RDD Line Printer - Reverse Drum Direction
LP%TCR Line Printer - Tangle and Chew Ribbon
LWM Load Write-only Memory
MPLP Make Pretty Light Pattern
MSR Melt Special Register
PPSW Pack Program Status Word
0 16
1
0 Vm-Com Issue 2.3
0 RNBS Reflect Next Bus Signal
ROM Read Operator's Mind
ROOP Run Out Of Paper
RP Read Printer
RPM Read Programmer's Mind
SP Scatter Print
STTHB Set Terminal to Three Hundred Baud
SUME Surprise Me
SUS Subract Until Senseless
TARC Take Arithmetic Review Course
TBFTG Two Burgers and Fries To Go
TOH Take Operator Hostage
TPDH Tell Programmer to Do it Him/Herself
TRA Te Rdls Arvs ÕType Ridiculous Abbreviationsþ
TTA Try, Try Again
TT%EKB TeleType - Electrify KeyBoard
UOP Useless Operation
VVM Vaporize Virtual Memory
WRTM Write Random Tape Mark
ZD Zap Directory
-
-
-
-
-
-
-
-
-
-
-
- 17
1
0 Vm-Com Issue 2.3
0 A Recent Memo From a BITNAUTs Office
+ A Recent Memo From a BITNAUTs Office
+ _ ______ ____ ____ _ ________ ______
0 Sunil Bhargava (BB418C@GWUVM)
-
MEMO
- TO: ALL EMPLOYEES
0 SUBJECT: COMPLAINTS TO THE PERSONNEL OFFICE
0 In lieu of the recent complaints received by this office
the following AUTHENTIC office rules of an 1859
businessman have be noted down below.
- 1. Office employees will daily sweep the
floor, dust the furniture, shelves and the show-
cases.
0 2. Each day fill lamps, clean chimneys and trim
wicks. Wash windows once a week.
0 3. Each clerk will bring in a bucket of water
and a scuttle of coal for the day's business.
0 4. Make your pens carefully; you may whittle
nibs to your individual tastes.
0 5. This office will be open 7 a.m. and close at
8 p.m. daily except on the Sabbath, which day it
will remain closed. Each employee is expected to
spend the Sabbath in attending church and
contributing liberally to the cause of the Lord.
0 6. Men employees will be given an evening off
each week for courting purposes, or two
evenings a week if they regularly go to church.
0 7. After an employee has spent 13 hours of labor
in the office, he should spend the time reading
the Bible and other good books while
contemplating the glories and the building up of
the Kingdom.
0 8. Every employee who smokes Spanish cigars,
uses liquor in any form, gets shaved at a barber
shop or frequents pool and public halls will give
me good reasons to suspect his worth, intentions,
integrity and honesty.
-
18
1
0 Vm-Com Issue 2.3
0 9. The employee who has performed his labors
faithfully and without fault for a period of five
years in my service, and who has been thrifty and
attentive to his religious duties, and is looked
on by his fellow men as a substantial and law-
bidding citizen, will be given an increase of 5
cents per day in his pay, providing a just
return in profits from the business permits it.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 19
|