VMSCHDULE

[Sravani Kolli]

Hello Team, 

Hope you are doing well. 

In VMSCHED scheduling tool, if a job is on HOLD can we change the user ID? Let's say I have job called JOBA and it is attached to user id called USER1, and job is on hold. Now I need to change the user ID from USER1 to USER2, so JOBA should use USER2 is it possible? When tried doing transfer from one user id to other it showed as VMDXTR0084E User 'USER2' already owns request 'JOBA'. But when checked in VMSCHED option 4 Query, it showed JOBA on both the IDs USER1 and USER2. Is it because JOBA is on HOLD? When tried with other jobs that were NOT on HOLD, they are using one ID i.e is USER2. 

Any help is appreciated! 

[JR Imler]

Verify when the "NEXT DATE/TIME" is. I believe when a Request is on HOLD and you TRANSFER  the Request to a different UserID, the original Request on HOLD will remain in the QUERY output until the "NEXT" iteration, after which it will no longer show in the original UserID's QUERY output.

If you find this is not the case, please open a Case for VM:Schedule on the Customer Support Portal and we should be able to help you directly to get the problem resolved.

[Kitty Deitrich]

Hello Sravani,

That's a bit odd since VM:Schedule 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. 

You cannot hold a request that is attempting to run.

Also, if requests are on hold, they must be released before they can be cancelled.

Sravani, I would encourage you to open a Broadcom Support case so we can further investigate.  When you do, please include the output from the following commands that can be issued from user ID VMANAGER:

VMSCHED QUERY requestname

VMSCHED DISPLAY

thank you very much,

Kitty Deitrich

Broadcom Technical Support

[e-mail]

[David Staudacher]

HOLD should not affect the transfer of requests between users.  The HOLD status will be included with the TRANSFER and the request removed from the original user.  Given that message VMDXTR0084E appears in response to the TRANSFER request, I suspect a request with the same name ("JOBA") was already present for USER2. The same symptoms can be recreated under this scenario.

Note: these symptoms will occur even for duplicate request names which have already run or been cancelled!  A request with the same name can only be Transferred after the original request is finally purged from the VM:Schedule database! In such cases, you must either schedule a new request with a different name and Transfer that one, or wait and Transfer the request after the original request has finally been purged off [See: PURGE: Purging Completed or Canceled Requests (Administrators) ].

Also note: This differs from the behavior for Scheduling.  You can reschedule a completed or cancelled request using the same name with the same user, but you cannot TRANSFER a request with that same name from a different user [ might make a good enhancement request ;-) ]

To prove that TRANSFER works even for requests on HOLD: 

1. Schedule a new request for USER1 which does not have the same name as one for USER2.
2. Place the new request on HOLD. 
3. Transfer the new request to USER2. 
4. QUERY the new request for USER2 => The Schedule for the new request (on HOLD) is displayed.  
5. QUERY the new request for USER1 => Message "VMDQRY0033E Request <new request> not found in request database" is displayed.