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.
TYPE FILENAME.EXT > LPT1
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
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)
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.