Using Nicknames and Local IDs for Remote Users

Some CMS commands that operate on file pools let the user specify a nickname instead of a user ID. When the user ID is on the same processor as the file pool, this works well. The z/VM® CP user ID is the same as the user ID that is enrolled in the file pool.

For example, when a user on your system asks to be enrolled, you simply enroll the person's user ID in the file pool. Now suppose you create a nickname for that user. When you use the nickname, the nickname resolves to the local CP user ID, which is the same user ID under which the user was enrolled in the file pool. In this case, the nickname works perfectly.

When the user is remote, however, nicknames alone may not resolve properly. Suppose you have created a nickname TOM. Tom is a remote user whose user ID is TOMPAO. Tom's node ID is CARRIB1. When you created the nickname TOM, you specified TOMPAO in the Userid field and CARRIB1 in the Node field. This let you use the nickname TOM on communication commands like TELL and SENDFILE. Because the node ID is required for commands like TELL and SENDFILE, everything worked fine.

Now Tom wants to be enrolled in a file pool you happen to administer. Tom is not on your local system. (For example, Tom is on a system in your TSAF collection or on a system in the SNA network accessible through AVS and VTAM.) You must give him a local CP user ID. It would be convenient if you could give him a CP user ID of TOMPAO, but after some investigation you find someone is already assigned that user ID. So, you update your z/VM system directory with the user TOMP, which is not in use. Then you tell Tom his user ID on your system is TOMP. You also tell him his password and ask him to have his system administrator add an APPCPASS control statement to his z/VM system directory entry.

grant auth . to tom (read

CMS looks in your NAMES file for the nickname TOM. It finds TOM, but the user ID is TOMPAO. If CMS were to send that user ID to the server, your grant would succeed for the wrong user ID—remember Tom's user ID in your file pool is TOMP. The user ID alone in your NAMES file is not sufficient for remote users. Instead, a tag is also needed to identify the user's local ID on your system. This tag is known as the LOCALID tag.

Whenever you have a nickname for a remote user who is also enrolled in a local file pool, you should specify the LOCALID tag in your NAMES file. To specify the LOCALID on the NAMES screen, type LOCALID in one of the Tag fields and the person's local user ID (TOMP in our example) in the corresponding Value field. (See z/VM: CMS User's Guide or z/VM: CMS Commands and Utilities Reference for more about the NAMES command, including the LOCALID tag.)

When you specify a nickname on a command that causes CMS to send a request to a server machine, CMS uses the LOCALID instead of the user ID in its communication with the server. When you use that same nickname on communication commands like TELL or SENDFILE, CMS uses the USERID and NODE tags to route your communication. The same nickname can be used for both server-related commands and communication-related commands.

When the above conditions are true, CMS cannot be sure the user ID specified for the USERID tag is, in fact, the same user ID enrolled in the file pool. And, as already mentioned, even if the user ID were enrolled, it might not belong to the same person.

Note that even if you could give Tom a user ID of TOMPAO on your system, you would still need to specify a LOCALID tag for TOMPAO. Because Tom has a node ID different from your node ID, you must specify the LOCALID tag. In this case, both the USERID and LOCALID tags would be set to TOMPAO.