STREAMLINING WORKSTATION NAMING CONVENTIONS: A STRATEGIC APPROACH

​Rabobank's dilemma in implementing the WSSYSAFF functionality was that they were unable to convert their current Workstations to Virtual Workstations. ZWS does not allow us to do so when there are any uncompleted entries for the WS’s in the CP which is always the case. 

​They opened an RFE (149295) but the effort was too high to be accepted. The only way was
creating a solution based on what was already available in the product, with no new developments.
 
Ilaria Rispoli, the advocate of Rabobank, proposed a step-by-step procedure, validating and perfecting it with the customer in a series of interactions, and at the end it resulted to be a very satisfying solution that made the customer enthusiastic.
Ilaria and Katiuscia Berretta (Senior Software Engineer from Customer Support Team) decided to publish a blog on this success story so that the technical advantages of the solution can help other customers. Rabobank very willingly accepted to be mentioned in the blog.
 
 
In the ever-evolving landscape of software development and deployment, maintaining consistency across workstation (WS) names is paramount for seamless operations. Yet, the task of transitioning to uniform WS names can often appear daunting, entailing extensive updates and meticulous coordination across various departments. However, with strategic planning and a systematic approach, this transition can be executed efficiently, as exemplified by the recent conversion procedure implemented within Rabobank’s organization.
 
 
HOW TO CONVERT NORMAL WS INTO A VIRTUAL ONE (CHANGING NAME OR MAINTAINING THE SAME ONE)
To reduce the effort of maintaining and controlling workstations' activities in the current plan it can be useful to reduce their number and, at the same time, also change the WS name to be aligned with a naming convention.
 
Virtual workstations are perfect for this aim, as they represent pools of destinations and delegate the Controller to decide on which LPAR a job should be submitted according to a round robin mechanism.
Moreover, it is also possible to control the LPAR where the execution of the jobs should occur by using the WSSYSAFF initial parameter,
making the SHUTDOWN Policy more effective.

The problem is that it is not easy to convert the name and the nature of a workstation when this is currently in use in the current plan.
If you try to change the nature of workstation by deleting it from WS database and then re-add it as a virtual WS, the next DP batch
run would fail with following message:
 
EQQ0356E VIRTUAL FLAG CHANGED FOR WORK STATION &WSN
 
If you try to change the WS type the next DP batch would fail with following message:
 
EQQ0316E WORK STATION &WSN TYPE HAS BEEN CHANGED
 
If you try to delete a WS that is still in use by some operation in the current plan, the next DP batch would fail with following message:
 
EQQ0315E WORK STATION &WSN DOES NOT EXIST
 
To avoid these kind of problems we suggest the following procedures, used and validated by Rabobank customer, under the guidance of HCL Dev/support team:

​PROCEDURE TO GROUP A NUMBER OF NORMAL WS IN A NEW VIRTUAL WS WITH DIFFERENT NAME
Let's suppose you have normal workstations EHVS and EHVI and you want to convert them into a Virtual WS, named VIRT.
 

1. Create a Virtual WS (e.g. WSNAME = VIRT) and associate to it the already defined and used destinations of EHVI and EHVS .
2. Verify that it has the same characteristics/properties as the WS it will represent, as you need.
3. Let the new defined Virtual WS be known to LTP and CP, by running an LTP modify all and a CP replan. You might want to add a test application using VIRT WS, with 2 operations, just to try that it correctly runs two test jobs on each of the 2 defined destinations.
4. By using Mass Update (or BL or a PIF) you can change in the AD all the WS EHVI to become WS VIRT and the same for WS EHVS to become VIRT. The already defined operations in CP on  EHVI and EHVS will continue to run on them, as individual WS.
5. The new added operations in CP from the modified AD (MCP scenario), or the ones added by a DP batch will run on WS VIRT (that is, according to round robin, on EHVI and EHVS destinations alternatively).
6. By using the ISPF dialogs, or any batch, verify that in CP there is no active operation (or still needed, because not completed) defined on old WS EHVI or EHVS, after a DP batch has run.

 
At this point the definitions for EHVI and EHVS as individual WS can be deleted from the WS database to avoid their individual use, if you like.
 
 
PROCEDURE TO CHANGE A NORMAL WS INTO A VIRTUAL WS WITH SAME NAME
Let’s suppose you have the normal workstation EHVS and you want to convert it into a Virtual WS with associated LPARs EVH7 and EVH8.
 

1. Copy the current workstation to new temporary name in the database (for example copy EHVS into ZHVS)  
2. Add WSSYSAFF statement to the Controller initial parameters

​By stating this, we are informing the Controller that the LPARs where a job submitted on EHVS can be executed are EHV7 (system SCTE7) and EHV8 (system SCTE8).
 

1. Extend LTP/CP to introduce the temporary WS ZHVS and to start to use the WSSYSAFF
2. Choose an “implementation time” looking for a time with low batch activity, and make sure no updates are made in the CP (so a mass update will not have troubles with locking) by:
   1. Disabling any deployment tooling from updating the database.
   2. Disabling jobsubmission in 9.1 Option BY.
   3. If applicable, put the ZWS jobclasses in HELD status, so that no ZWS controlled batch that is started from outside ZWS will start running and updating the status in CP (e.g. $T JOBCLASS(D),QHELD=YES).
   4. Disabling access to ZWS GUI for DEVOPS so nobody can lock an application in 5.2
   5. Stopping DWC so nobody can do updates that can lead to locks on applications.

1. Run a CP Replan job, so all completed applications will be removed from CP, making the CP as small as possible.
2. Run mass update against CP via a WAPL job to change EHVS into temporary WS ZHVS.

 
The WAPL job lists all operations using EHVS, then changes the name into ZHVS:
 

1. Delete EHVS WS from the Database.
2. Run a CP replan job to update teh CP. As a consequence, the normal WS EHVS is removed from the plan because no operation is using it.
3. Define again EHVS WS but this time as a virtual WS in Database.
4. Run a CP replan job to update CP. At this point EHVS is present in the current plan as a Virtual WS.
5. Run a mass update against the CP via WAPL job to change the temporary WS ZHVS to EHVS.

1. Enable jobsubmission/gui/jobclasses etc.

 
Now EHVS has become a Virtual Workstation.
 
 
Through meticulous planning and systematic execution, we successfully transitioned towards unified WS naming conventions. By standardizing these critical identifiers, we have laid a robust foundation for future development and deployment endeavors. Moreover, the streamlined procedures implemented during this transition have enhanced the operational efficiency and agility, positioning us for continued success in an ever-evolving technological landscape.
 

Author

---

​ 
Ilaria  Rispoli, Client Advocacy Manager , HCL
​
Ilaria Rispoli works in the Workload Automation area and is leading the Advocacy Program for both on-premises and cloud solutions of the product in Europe, Middle East, Africa, and worldwide. She started her experience with IBM Workload Scheduler in 2000, covering different roles in development, customer support and verification team. Since 2016, thanks to her customer interaction experience, she has been appointed to lead the HCL Advocacy Program striving to deliver a high-touch, highly interactive approach to customer relationships, and to provide the greatest value and service to customers through strong connections. 

---

​Katiuscia Berretta, Senior Software Engineer, HCL
​
Katiuscia has been a valuable member of the WA team for 18 years, bringing a wealth of experience to the table. Throughout her tenure, she has gained diverse experiences and worked across various teams, including development, customer support, and education. Her extensive experience with the product and customer interaction makes her an indispensable asset to the team. Katiuscia has assisted numerous clients in addressing their requests regarding Workload Automation for z/OS, showcasing her deep expertise and commitment to delivering exceptional service.