Verify/alloc/delete of BAS- PROM- or PROD DSNs
Summary: Create a set of baskets for a single application (alternative: for all applications). Each basket contains all DSNs defined in application administration as production DSNs, baseline DSNs or promotion DSNs.
The set of baskets created are:
- BsktPrfx.Subsys.DSNADMUT.Date.Time.Subsys.PrmSite for each promotion site containing all (at least 1) shadow promotion DSNs and local promotion DSNs of all promotion levels on this site as defined via A.A.7.
- BsktPrfx.Subsys.DSNADMUT.Date.Time.Rmtsys.PrdSite for each production site containing all (at least 1) production DSNs on this site as defined via A.A.P and eventually also (if the site is also used for promotion) containing all remote promotion DSNs on this site as defined via A.A.7.
- BsktPrfx.Subsys.DSNADMUT.Date.Time.Subsys.BASELIB, for each baseline DSN (0 or –X) as defined via A.A.B.
In the DSNs mentioned above, these conventions were used:
- BskPrf: some high level qualifier for the basket DSNs to be created.
- Subsys: the CMN/ZMF subsystem ID of the DP site (that contains all A.A definitions).
- Date: a qualifier corresponding to the date the baskets were created.
- Time: a qualifier corresponding to the time the baskets were created.
- PrmSite: the name of the promotion site (as defined in A.A.7).
- PrdSite: the name of the production site (as defined in A.A.P).
The content of each basket (record structure) depends on the selected processing option:
- The first basket record contains the XML tag “mvslib” and each subsequent basket record consists of only a DSN (for processing option “info” or “delete”).
- The first basket record contains all XML input tags for XML service DSS/SERVICE/ALLOCATE and each subsequent record consists of a DSN followed by the DSN’s actual values (derived from the attributes stored in A.A.2) for each of these input tags (for processing option “allocate”).
The baskets created using processing option “info” or “delete” can be used as input for either of the following (green) XML services:
- DSS/SERVICE/INFO, to verify the existence of each of the DSNs included in the basket.
- DSS/SERVICE/DELETE, to delete each of the DSNs included in the basket.
The baskets created using processing option “allocate” can be used as input for the (green) XML service DSS/SERVICE/ALLOCATE, to allocate each of the DSNs included in the basket.
To actually execute any of these XML services, just use ASC’s basket processing features. It may be a good idea also to use “Stop on error = N” during this basket processing.
In case the DSNs to be processed (as contained in the baskets) reside on a remote site, following options exist:
- If TCP/IP is enabled, just use ASC’s TCP/IP facilities (available for basket processing also), using the CMN/ZMF subsystem ID that manages the remote site DSNs as the subsystem to execute the XML services.
- If TCP/IP is not enabled just transfer the baskets to the remote site, and then launch ASC on the remote site to process the transferred baskets.
Solution ID:
ASCZ0202
Solution Variables:
The above screen (via Appl id within Target selection) shows that this solution can be used for just 1 application, or for all (dozens? hundreds?) applications in 1 shot.
Also note that this solution (via Site within Target selection) can be used to process "ALL" sites together, or to process just 1 site (e.g. a new promotion or production target added in various applications) and eventually to be repeated for a 2nd site.
To understand how the output of this solution looks like, and how to further process that output, checkout the various steps in the scenario below.
Scenario:
Step 01: List the baskets created by ASCZ0202
Step 02: View the baskets content (1/2)
This is a perfect illustration of how "real" baskets look like (= CSV-kind of files).
The various data included in each record, is what gets created by using a Process option (within Execution options) with value 1 (Allocate), because all these data are required as input tags for the XML service to actually allocate these DSNs (shown in step 04 below).
By using value 1 (Info) or 3 (Delete), each record will only contain the mvslib value, because only a DSN is required as input tag for the XML service to either report about the DSN info (with data similar to ISPF option 3.2) or to actually delete these DSNs.
Step 02: View the baskets content (2/2)
Step 03: Launch the baskets
Step 04: Select XML
Above is an illustration of how ASC helps an XML newbee to take advantage of the extreme power of XML services. I.e. ASC "guides" you to picking (= finding !) the appropriate XML service (in this case DSS/SERVICE/ALLOCATE), and gives you all sorts of extra XML execution features (step 05, part 2/2 below) to get the job done.
Step 05: Execute XML (1/2)
Step 05: Execute XML (2/2)
So in this specific scenario the basket processing will trigger about 100 to 200 XML requests for each application, 1 for each record in each of the 3 basket DSNs in this scenario. Do the math if you'd have hundreds of applications (and then think of how long it would take to achieve the same result if you have to do this without using XML services ... hours, days or weeks?).
What is even (Abit)MORE: executing all these XML services can be done without "disturbing" the CMN/ZMF STC too much. This because of the input basket options shown above: turning on the options Split in units, Nr req/unit and Next unit after will facilitate a kind of work load balancing to actually execute all those services. That will avoid that regular ZMF users would experience bad response times from the CMN/ZMF started task while all those XML services are being processed (like compile jobs or promotion jobs that would take extremely long ...). Because of this, the scenario above can be executed also during CMN/ZMF primetime hours (instead of during none business hours at night or during weekends).
