How Unix Is Not Like VM

While Unix and VM have basic similarities in the tasks they can do for you, the differences are enough to make people uneasy about the changeover in systems. The differences start with the way you interact with the system and run through the naming of files and commands. While UA1VM was best accessed through a 3270 terminal or terminal-emulator on a PC, the Unix system prefers a simpler terminal interface. Many people use a "telnet" program but some users are gearing up to use an X-Windows interface. Unlike a 3270 terminal, where the input line was always formed at the bottom of the screen, in telnet commands just run sequentially down the screen, while older commands "scroll" off the top. In the Unix system, then, there is no reliance on function keys to control input and output with the screen. In fact, Unix really doesn't use the function keys at all.

Under Unix you are permitted to log in more than once. There are times when it can be useful to run several telnet sessions to compare different files, say. UA1VM users are familiar with being locked out because they still had a login session hanging around, waiting to time-out. If a 3270 session was "hung up" and was killed, the login would remain running for another 15 minutes or so. If you terminate a telnet session, you will terminate your login.

Many VM users accessed files through the "filelist" command. Using this they could mark up a page of changes (printing, deletions, or edits, for example) and submit them all with the return key. Unix likes you to work one command line at a time.

VM files had three parts to their name: a filename, a filetype and a filemode. Unix files have one-word names, and the names arent necessarily indicative of the type of content of the file. The Unix system, however, does have ways of knowing the type of contents and, for instance, will warn you if you try to edit a binary file (this is not something you would want to do). There are informal naming schemes in Unix, then, which indicate file types. For instance, a suffix of ".ps" would indicate a postscript file and a shell script might end in ".sh". Tar archives usually have ".tar". The compilers do have preferences for the suffix, so that Fortran programs end in ".f" or ".for", Fortran 90 programs end in ".f90 ", and C programs end in ".c". The compression utilities (compress, zip and gzip) like to have specific suffixes. Compress will use ".Z" and gzip will use ".gz". There are other standard suffixes.

The different structure of naming files points out a change that programmers (and SAS and SPSS users, too) will need to make as they convert their programs to Unix. File names will not have the three parts, as in "filename filetype filemode". Depending on how the data files are transferred to Bama, they will get a slightly different name. For instance, a file that has been transferred via FTP will have the Unix name of "filename.filetype" (although the "filetype" will have no particular meaning to Unix). Any reference to file names in programs will have to be converted to the Unix format. Of course you can use the "ls" command to list the directory in Unix and see exactly how the files are named.

The directory structure as set up by users is different on the two machines. Under VM the directories are accessed by filemode and there is usually just one "level" of directories. Under Unix the directory structure is hierarchical; you can have directories under directories, which themselves are under directories, and so on for many levels. New directories are easily created with the "mkdir" command. This sort of directory structure could be setup under VM but with a great deal more effort, hence it was rarely done.

VM users are familiar with the "PKG" command, used to attach the files needed to run various programs (such as SAS and SPSS). Unix does not use a command like this to make programs available. Instead, they are made available through the use of a path. This is a list of directories where the system looks for the commands you execute. A rather complete path is already set up for you and only users needing to specialize their path with their own directories need to worry about it. There are some software packages on Bama that arent needed by all users, so they are not set up globally. One example is IMSL. There is a special setup script that needs to be run before compiling programs that use IMSL. On our system this script is run by typing ". imsl" (that's dot space imsl) or, if you are using the csh or tcsh, "source imsl"

To compile and load a program is usually a one-step process under Unix. Any libraries needed for linking are specified in the compile step. The compilers are smart enough to know that if they are given a file that has already been compiled (an object file), all they need to do is link the program to the libraries. When a program is successfully compiled, it will be marked as executable and will be ready to go.

Users on UA1VM were used to thinking about their space in terms of cylinders. They could check their space usage with the command "Q LIMITS". Unix more directly reports disk usage in terms of kilobytes. One command is "du -k" (think "disk usage in kilobytes). For users subject to a quota (i.e. students), the more useful command is "quota".

Lastly, it should be said that there are some commands on the two machines with the same name but which behave very differently. UA1VM users who are used to typing "mail" to check for messages and who type this on Bama will find themselves running some strange (but mostly harmless) mail program on Bama (just press "q" to get out). It's better to remember to type "Pine" (or even "mailx" is usable).

We have made available a conversion chart to go from UA1VM commands to Unix commands. You'll find it on the web at:

http://bama.ua.edu/~unixinfo/unix/conversions.html

In fact, that may point out the biggest change of all, getting used to finding help via the Web. We are trying to use the Web to give you as much help as is possible as you make your transition and then get to work on Bama.

© 1998, The University of Alabama. The information included here is for the University of Alabama central computing facility as it was configured on the document date. It may or may not apply to other Unix systems.

September 21, 1998 Vol. 2 Index Back to Vol. 2, No. 3 Ahead to Vol. 2, No. 5		Search:

	E-mail Internet Access Software Assistance Computer Labs Software Licensing Web Publishing Calendaring Computer Security Unix Training

	How Unix Is Not Like VM While Unix and VM have basic similarities in the tasks they can do for you, the differences are enough to make people uneasy about the changeover in systems. The differences start with the way you interact with the system and run through the naming of files and commands. While UA1VM was best accessed through a 3270 terminal or terminal-emulator on a PC, the Unix system prefers a simpler terminal interface. Many people use a "telnet" program but some users are gearing up to use an X-Windows interface. Unlike a 3270 terminal, where the input line was always formed at the bottom of the screen, in telnet commands just run sequentially down the screen, while older commands "scroll" off the top. In the Unix system, then, there is no reliance on function keys to control input and output with the screen. In fact, Unix really doesn't use the function keys at all. Under Unix you are permitted to log in more than once. There are times when it can be useful to run several telnet sessions to compare different files, say. UA1VM users are familiar with being locked out because they still had a login session hanging around, waiting to time-out. If a 3270 session was "hung up" and was killed, the login would remain running for another 15 minutes or so. If you terminate a telnet session, you will terminate your login. Many VM users accessed files through the "filelist" command. Using this they could mark up a page of changes (printing, deletions, or edits, for example) and submit them all with the return key. Unix likes you to work one command line at a time. VM files had three parts to their name: a filename, a filetype and a filemode. Unix files have one-word names, and the names arent necessarily indicative of the type of content of the file. The Unix system, however, does have ways of knowing the type of contents and, for instance, will warn you if you try to edit a binary file (this is not something you would want to do). There are informal naming schemes in Unix, then, which indicate file types. For instance, a suffix of ".ps" would indicate a postscript file and a shell script might end in ".sh". Tar archives usually have ".tar". The compilers do have preferences for the suffix, so that Fortran programs end in ".f" or ".for", Fortran 90 programs end in ".f90 ", and C programs end in ".c". The compression utilities (compress, zip and gzip) like to have specific suffixes. Compress will use ".Z" and gzip will use ".gz". There are other standard suffixes. The different structure of naming files points out a change that programmers (and SAS and SPSS users, too) will need to make as they convert their programs to Unix. File names will not have the three parts, as in "filename filetype filemode". Depending on how the data files are transferred to Bama, they will get a slightly different name. For instance, a file that has been transferred via FTP will have the Unix name of "filename.filetype" (although the "filetype" will have no particular meaning to Unix). Any reference to file names in programs will have to be converted to the Unix format. Of course you can use the "ls" command to list the directory in Unix and see exactly how the files are named. The directory structure as set up by users is different on the two machines. Under VM the directories are accessed by filemode and there is usually just one "level" of directories. Under Unix the directory structure is hierarchical; you can have directories under directories, which themselves are under directories, and so on for many levels. New directories are easily created with the "mkdir" command. This sort of directory structure could be setup under VM but with a great deal more effort, hence it was rarely done. VM users are familiar with the "PKG" command, used to attach the files needed to run various programs (such as SAS and SPSS). Unix does not use a command like this to make programs available. Instead, they are made available through the use of a path. This is a list of directories where the system looks for the commands you execute. A rather complete path is already set up for you and only users needing to specialize their path with their own directories need to worry about it. There are some software packages on Bama that arent needed by all users, so they are not set up globally. One example is IMSL. There is a special setup script that needs to be run before compiling programs that use IMSL. On our system this script is run by typing ". imsl" (that's dot space imsl) or, if you are using the csh or tcsh, "source imsl" To compile and load a program is usually a one-step process under Unix. Any libraries needed for linking are specified in the compile step. The compilers are smart enough to know that if they are given a file that has already been compiled (an object file), all they need to do is link the program to the libraries. When a program is successfully compiled, it will be marked as executable and will be ready to go. Users on UA1VM were used to thinking about their space in terms of cylinders. They could check their space usage with the command "Q LIMITS". Unix more directly reports disk usage in terms of kilobytes. One command is "du -k" (think "disk usage in kilobytes). For users subject to a quota (i.e. students), the more useful command is "quota". Lastly, it should be said that there are some commands on the two machines with the same name but which behave very differently. UA1VM users who are used to typing "mail" to check for messages and who type this on Bama will find themselves running some strange (but mostly harmless) mail program on Bama (just press "q" to get out). It's better to remember to type "Pine" (or even "mailx" is usable). We have made available a conversion chart to go from UA1VM commands to Unix commands. You'll find it on the web at: http://bama.ua.edu/~unixinfo/unix/conversions.html In fact, that may point out the biggest change of all, getting used to finding help via the Web. We are trying to use the Web to give you as much help as is possible as you make your transition and then get to work on Bama. © 1998, The University of Alabama. The information included here is for the University of Alabama central computing facility as it was configured on the document date. It may or may not apply to other Unix systems.
Copyright © 1998-2004 The University of Alabama \| Disclaimer \| Contact: Help.Desk@ua.edu