The main lab network system is
part of the overall campus network system. Individual machines in
the labs are logged automatically into one or more servers on the
network from which all software is loaded. Students DO NOT require
a network account to use any of the facilities in the student labs
with the exception of the campus academic mainframe and
Internet/E-Mail functions. Each machine in each lab has a unique
network account assigned to it. Each of these accounts can be used
ONLY from the machine to which it was originally assigned.
Account names for machines are displayed on printouts and in the
userlist. Names are formed by adding the building code, room number
and unit number together. For example, unit 33 in Gilbreath 105 has
a user id of GIH10533. Unit numbers are posted on the side of each
machine.
Users do not need to know the user id for the machine they wish to
use and they are not prompted for any information to access the
network. Each machine is configured to automatically log into the
appropriate account when the machine is turned on. Users need only
activate the machine and wait for the main menu to appear.
Currently, we have two Novell Netware file servers that handle
networking, software and printing services for all labs connected
to our system. Each machine is assigned both a primary and
secondary server. If connection to the primary server fails, the
secondary server will be used automatically. This allows us to
distribute the load between the servers and provides automatic
facilities for one server to compensate if the other goes offline.
Both servers are identically configured and have the same software
available.
Printing
on the Lab Network
Printing in a networking environment is more complex than printing
on a stand alone machine. With this added complexity comes some
accompanying peculiarities and problems. Most notably is the
potential for users to monopolize network printers by sending very
large print jobs or multiple copies of the same job simply to avoid
copy machine charges. In the past we had students go so far as to
enter a lab first thing in the morning, queue three or four hours
worth of printing, go to class all day and then come back in the
evening to pick up their printouts. Needless to say, this presented
problems for the several hundred other students who were trying to
print in that lab.
To prevent this from occurring again, we have installed a print
queue monitoring system. This system somewhat restricts the volume
of print jobs that students can send and more or less forces them
to share the networked printers. The system imposes the following
restrictions:
Students may not send a job to most network printers that is longer
than 300K. Large jobs such as this must be printed on LOCAL
printers attached directly to a lab computer. This still allows
students to print the job without inconveniencing all other lab
users.
If a student sends a print job to a network printer, he or she MUST
wait until that job is printed before they can send the same job
again. This insures that there is time for other students to enter
jobs into the queue.
One note on this restriction is that the system will interpret ALL
SCREEN PRINTS FROM THE SAME MACHINE AS DUPLICATE JOBS. Students who
wish to do multiple screen prints must send one and wait for it to
be printed before they may send another one.
Local printers are not restricted in any way by this system.
Lab System Peculiarities
Users should ALWAYS use the main menu provided to access
applications on the network system. This menu calls batch files
which perform special setup functions essential to the proper
execution of the programs. Odd things will happen if users attempt
to bypass the menu system. For example, entering WordPerfect by
simply moving to the proper directory and typing WP will indeed
load the program. However, it will NOT load the proper printer
drivers and users will find after they have typed their document
that they cannot print it.
Many instructors use the LOGFILE command provided on the network to
record student's work on a project. Instructors should be aware of
the limitations of using LOGFILE. Some commands will not work
properly while logfile is active. Most notably among these are the
DISKCOPY and PRINT commands. These commands should NOT be used
while logfile is active. Also, be aware that logfile will not
capture output from any software that writes directly to video
memory or which has custom keyboard drivers.
The PRINT command
This command has a basic incompatibility with the network system in
that it sets up a conflicting print buffer to that which the
network already provides. Using the PRINT command to print large
files (or even small files under the right conditions) can cause
printouts to be broken up, pieces of printouts can be deleted or
random characters may be present in the final copy. If this
happens, an effective alternative to the PRINT command is to use
either the TYPE or COPY commands and direct the output to the
proper printer.
Example:
TYPE FILENAME.EXT > LPT1
or
COPY FILENAME.EXT LPT1 /b
Either of these commands will print the required file WITHOUT conflicting with the network print queues.
Another problem with the PRINT command (which is also true of
stand-alone machines) is that it does not allow you to change the
destination of printouts once it is initially loaded. This means if
you use PRINT to send a job to LPT1 all other PRINT commands issued
in that session will route to LPT1 as well. The only way to change
this is to reboot the machine or use the TYPE/COPY commands listed
above.
Disk Format Confusion
One of the common problems that lab users have revolves around
students using a disk in one machine and having it work just fine
and then later using it in another machine only to find that the
second machine refuses to read it. There are many possible causes
for such an occurrence, but the most common by far involves the
different types of disk formats that can be used.
There are actually two different types of 3 1/2" diskettes on the
market today. The disks are classified by their density which just
means how much data they can hold. LOW density diskettes (also
called double density) can hold about 730,000 characters of data
while HIGH density disks can hold twice that amount.
If you're not sure what kind of disk you have, look at the diskette
and see if there is a hole in the upper LEFT corner (this would be
in addition to the write-protect hole located in the upper RIGHT
corner). High density disks can be recognized by the presence of
that additional hole in the disk cover. If the hole isn't there,
it's a low density disk.
The next consideration is how the disk is FORMATTED. That means how
much space did you ask the computer to allocate on the disk when
you used the FORMAT command. Normally, the computer that is
formatting the disk will check the disk and see what density it is
before formatting it, thus insuring that it does not format the
disk incorrectly.
Unfortunately, the IBM PS/2 models are incapable of telling the
physical difference between a high and low density disk. This means
that unless given specific instructions on what density to use in
formatting the disk, it will basically take a guess........it
usually guesses wrong.
The PS/2 models will quite happily format a low density disk to
high density or a high density disk to low density. This means you
end up with a disk that can be read in any of the PS/2 models, but
not in any of the other models in the labs.
You will usually get a "General Failure Reading Drive A:" error on
the disk if you try to use it in another brand (Zenith for
example). If this happens to you, the simplest thing to do is take
the disk back to one of the PS/2 machines and use it there. They
should continue to read and write the disk just fine.
THIS IS ONLY TRUE OF DISKS THAT WERE FORMATTED IN ONE OF
THE PS/2 MACHINES. DISKS FORMATTED IN OTHER MACHINES DO NOT HAVE
THIS PROBLEM AND SHOULD WORK IN ANY COMPUTER CAPABLE OF READING
THEIR DENSITY.
If you want to format a disk in one of the PS/2 models that will be
readable in other brands of machines, you must tell the FORMAT
command what density to use on the disk. The following commands
will work on the student lab network:
For LOW density disks: FORMAT A: /N:9 /T:80
For HIGH Density disks: FORMAT A: /N:18 /T:80
Since all of our lab computers will now work with HIGH density
disks, if you use the commands listed above it should solve the
disk density confusion and allow you to use any disk in any
machine.
Making a Boot disk in the student
Labs
We've had questions from students asking how they can make a
bootable disk from the student lab machines. Though it is not
necessary to have boot disks to run any of the machines in the
labs, occasionally an instructor will assign the task of making
such a disk as a class assignment. There are some small differences
in using FORMAT for this task because of the network security
required in the labs.
The following commands should avoid those problems.
Exit to Dos (Press ESC from the lab network menu)
Execute the following commands:
C: (This step is REQUIRED)
FORMAT A: /N:9 /T:80 /S (For LOW density disks) or
FORMAT A: /N:18 /T:80 /S (For HIGH density disks)
Swapping Disks
When applications are selected from the main menu one of the first
things that students see is a message warning them not to remove
their data disk while still in the application.
THIS IS IMPORTANT!
In the past, instructors have told students to ignore the message
and swap disks in the middle of an application. This causes
irreversible damage to the file structure on the disk and can
result in complete loss of data, not just the file being worked on
but the entire disk. It is imperative that students not remove the
disk from the drive while inside any application for any reason.
Even taking a disk out, putting another one in and then returning
the original disk to the drive is dangerous. In fact, this can
cause loss of BOTH disks.