The actual technique for setting up Unix logins varies among Unix flavors, and is outside the scope of this document. However, since many A-Shell users are used to a rather casual security atmosphere under AMOS in which there may have been no formal user definitions, it is worth discussing the basic strategies that are available here.
The simplest strategy is to define a generic user (e.g. "ashusr" or just "user") and let everyone log in as that same user. If this lack of refinement doesn’t bother you, it doesn’t bother A-Shell. The only detrimental side effect is that SYSTAT will not be able to give you any useful clues as to who is who (unless they are all on serial connections and you recognize the port numbers.) It may be possible to overcome that shortcoming by setting the A-Shell user name within A-Shell based on some kind of application logic, but this strategy is not workable if you want to use Unix utilities such as mail, which depend on the user login to establish identities.
At the opposite extreme is the traditional approach of setting up a separate Unix login for each real user, which offers advantages such as allowing SYSTAT to be able to display each user’s login name. The main down side to defining individual Unix logins is that it can be a lot of administrative work (if you have a lot of users.) However, most flavors of Unix provide some way of simplifying this (e.g. template user profiles, sharing of home directories, etc.) so it generally doesn’t require much more than assigning a login name and password for each user, letting the rest of the settings (group, home directory, shell, etc.) default to the template value. The other main complication with having individual user logins for each user is the security problem of not being able to send signals to each other, but the SETUID trick described in the previous section effectively works around that problem.
