| < Day Day Up > |
|
Because WSAA doesn’t operate in a vacuum, you will require the assistance of some additional IT personnel. Individuals may be application subject matter experts (SMEs), managers, project leaders, analysts, and so forth.
Your site’s systems programming and support staff will install and maintain WSAA. You must establish a good working relationship with the following support groups for help with your project:
MVS systems programmers
DB2 database administrators (DBAs)
WebSphere Application Server (WAS) coordinators
Change Management group
Quality Assurance (QA) group
CICS and IMS system programmers
Storage administrator
Security administrator
Each of these job functions may exist within one or more groups depending on how your organization is set up. Each site will have different requirements for the local environment.
We describe the planning and installation tasks, along with any post-installation tasks in the following sections.
At most sites, an MVS systems programmer will be responsible for installing WSAA. They can teach you the various site standards for data set naming conventions and the location of various WebSphere components.
Your site’s MVS systems programmer will provide you with the following information:
The names, or high-level qualifier, of the product’s data sets.
Identify the names of any production datasets that contain system-level:
Copybooks
Macros
Identify the names and concatenation sequence of proc libraries defined to your site’s batch job scheduling software
The MVS systems programmer is also responsible for installing program temporary fixes (PTFs) or patches to the system. Some of the changes may involve the DB2 DBA or WebSphere Application Server coordinator.
You can decide with your MVS systems programmer who will check the IBM Web site periodically to see if any patches have been issued that correct problems your users have experienced.
You must establish an appropriate schedule for applying preventative maintenance to WSAA.
Note | In certain cases, when you apply corrective service to WSAA, WebSphere Application Server must be stopped and restarted. Please make certain you do not affect any other organization’s service level commitment when you perform your system maintenance. |
The DB2 DBA assigned to support the WSAA database has the second most important job after yours.
If you don’t already have a solid understanding of how DB2 utilities work and what they can do, you should make very good friends with your DB2 DBA.
The DB2 DBA provides you with the following information and support.
Reviews and submits the installation batch jobs to:
Create the DB2 tablespaces, tables, and views
Bind the DB2 packages and plans
Grant DB2 privileges to all of the users
Corrects any issues that arise from the installation batch jobs.
Identifies the names of any production datasets that contain system-level:
Copybooks
Macros
DCLGENs
On-going maintenance of the WSAA DB2 database requires that you (or the WSAA system or product administrator) submit a batch job to bind the packages and plans periodically.
Note | As a matter of routine DB2 housekeeping, invoke the DB2 RUNSTATS and REBIND utility functions: |
After each CICS region or IMS subsystem is loaded
After each partitioned data set it loaded
This will update all of the table indexes and paths so that DB2 can respond more quickly to your Web-based queries.
You must use whatever DB2 performance monitoring tools you have to ensure adequate response time from the Web-initiated queries.
Refer to 3.9, “How and when to perform database maintenance” on page 107 for more information regarding these activities.
Your Change Management group holds the keys to the WSAA kingdom, for it is in control of your site’s production source code. Make it your business to establish a working relationship with the group’s manager.
Note | A good candidate for WSAA system or product administrator is a former or current member of the Change Management group. Who else is better equipped to know about your site’s applications and library hierarchy? |
Many customers have individuals who are responsible for the day-to-day runtime and operation of production applications. You should look to these resources for guidance on the JCL and procs used in production application jobstreams.
The Change Management group must provide you with:
A list of all of your site’s production source code libraries
The appropriate concatenation of copybooks, macros, and DCLGENs used in compile processes
A list of production JCL, proc, and control card libraries
As components are moved through your site’s change management system, the Change Management group will undoubtedly track (or list) each of the changed components. This list of modified (for example, new, updated, or deleted) components can make your task of updating the contents of the WSAA just a little bit easier. Refer to 3.8, “How to perform on-going database loads” on page 106 for additional information.
Many sites have groups that are responsible for the day-to-day runtime and operation of production applications. You should look to these resources for guidance on the JCL and procs used in production application jobstreams.
Your Quality Assurance group may be the final arbiter of what is considered a “production” library at your site. Similar to the Change Management group, they can provide you with:
A list of production source code libraries
The appropriate concatenation of copybooks, macros, and DCLGENs
A list of production proc libraries
Often, as part of the inventory scan process, the administrator will miss important libraries that may contain utilities or programs that are part of application maintenance and not necessarily the application itself.
Your QA group can help you to understand how your site’s applications are linked together. Their assistance may prove to be invaluable when it comes time to reconcile errors that occur with scanned components.
You must tap the resources and skills of your site’s CICS and IMS systems programmers to identify the locations of the online components that you will load into the WSAA DB2 database.
CICS and IMS systems programmers provide you with the following information and support:
Identify all production CICS and IMS components, including:
A complete list of production online regions
Data set names of start-up JCL (if any) and procs
Data set names containing system-level macros and copybooks
Information about MQ Series libraries.
If practical (or necessary), coordinate the collection of this information in conjunction with your site’s Change Management or Quality Assurance group.
Details about the steps you take to load the WSAA database with online resources are given in 3.5, “Load the database with online information” on page 67.
Note | CICS and IMS systems programmers take note: If your site creates any new (or additional) production CICS regions or IMS subsystems, contact the WSAA system or product administrator. Establish a time during which these new resources can be scanned. |
In 1.1, “What is WebSphere Studio Asset Analyzer?” on page 4, we stated that the WSAA database has more than 100 DB2 tables. The amount of physical DASD your database will require depends on the size of the application portfolio you load.
Your Storage administrator provides you with the following information and support:
Ensures that the appropriate storage pool is allocated for the database.
Ensures that the appropriate back-up and recovery procedures are in place for the table data sets.
Note | We did not have the opportunity to develop any guidelines by which you can size your database tables. However, here is what we found on the DemoMVS system. |
Approximately 9,300 members were scanned from just over 50 libraries. A handful of online resources were also scanned. The DB2 data sets used to hold the WSAA data base totaled just over 300 cylinders.
Some of your tasks as Storage administrator possibly include producing weekly (or monthly) reports that indicate the status of highly fragmented files. Make sure that the WSAA table data sets are added to these batch jobs, and route the output to the WSAA system or product administrator. If any file exceeds your site standards, coordinate the file reorganization with the DB2 DBA.
The WSAA PID instructs the WebSphere coordinator to configure the IBM HTTP Server. You must understand the implications of this step in terms of how the Security administrator handles user login for WSAA.
Your Security administrator provides you with the following information and support:
Determines how your site’s users log on to the WSAA database:
Each user logs on with his or her own user ID.
All users share access with a single user ID.
Note | This is how the DemoMVS system is established. |
Applies the appropriate definitions to each TSO user ID’s profile to enable access to the WSAA resources.
Provides access (if necessary) to the batch job that scans the production source code libraries.
Ensures that all of your site’s code can be scanned and loaded into the
WSAA DB2 database.
The Security administrator ensures that new TSO user IDs have the authority to log on to WSAA.
WSAA requires WebSphere Application Server (WAS) to be correctly configured.
Your WebSphere Application Server coordinator provides you with the following information and support:
Determines what changes need to be made to the WebSphere Application Server configuration files to support WSAA.
Applies and installs any changes to the following program products:
IBM HTTP Server
WebSphere Application Server
Net.Data®
Important: | As with any other environmental change, we recommend that you install WSAA in a test system (or environment) first to determine how it will operate. |
You must work out an appropriate schedule for applying preventative maintenance to WebSphere Application Server. Keep in mind that when you bring the server down for maintenance, no one will be able to access WSAA.
Note | Please make certain you do not affect any other organization’s service level commitment when you bring down WebSphere Application Server or WSAA. |
| < Day Day Up > |
|