Running Requests on Other User IDs

You can schedule requests to run on user IDs other than your own, list information about those requests, and change them.

You can complete the following tasks with this feature:

Work on your own user ID while running a request on another user ID.
Autolog administrator user IDs to perform system maintenance functions such as backing up spool files or automating your system backups.
Autolog user IDs that you are responsible for at regular intervals. Regularly autologging user IDs prevents them from being put on hold or deleted due to inactivity.

To schedule a request on another user ID, use the appropriate commands and add the word user and a user ID at the end of the command. The user ID is the user ID on which you want the request to run. When you use commands for EXECs scheduled to run on the server, the user ID is the user ID that owns the request.

When you enter the command, the server prompts you to enter the CP logon password for the user ID. When you enter the password, it does not appear on the screen.

The following examples illustrate some scheduling tasks that you can perform on other user IDs:

Schedule an EXEC called REPORTX that runs every day at 5:00 a.m. on your accounting administration user ID, ACCTREP:
```
vmsched schedule reportx (at 05:00:00 again daily user acctrep
```
List the next six runs of REPORTX for today:
```
vmsched when reportx (next 6 user acctrep
```
List all the requests that run on the ACCTREP user ID; put the list in a file named ACCTJOBS VMSCHED on your A-disk:
```
vmsched query * (file acctjobs user acctrep
```
Change the time REPORTX runs from 5:00 a.m. to 8:00 a.m. for the next run only:
```
vmsched delay reportx for 03:00:00 (user acctrep
```
Change the time REPORTX runs from 5:00 a.m. to 8:00 a.m. from now on:
```
vmsched delay reportx until 08:00:00 (user acctrep
```
Keep REPORTX from running its next two scheduled times, without canceling the rest:
```
vmsched skip reportx 2 (user acctrep
```
Suspend REPORTX from running until you restart it:
```
vmsched hold on reportx (user acctrep
```
Restart REPORTX after you put it on hold:
```
vmsched hold off reportx (user acctrep
```
Cancel REPORTX so it never runs again:
```
vmsched cancel reportx (user acctrep
```

You can change the user ID on which a request runs even after it is scheduled. You must have TRANSFER authorization to change the user ID. This feature is useful for reassigning requests that belong to an employee who has left your company or changed departments.

Consider the following example:

ROGER has left the company. You must make his supervisor, LOUISE, the owner of all his requests. Enter the following command:
```
vmsched transfer * roger louise
```
ALICE has been promoted. She keeps most of her jobs, but one, ACCOUNTS, should now belong to LOUISE. Enter the following command:
```
vmsched transfer accounts alice louise
```

The server checks for duplicate request names when you transfer requests. You cannot transfer a request to user ID if that user ID already owns a request with that name. If you try to do so, the server rejects the transfer with an error message and a CMS return code of 24.