Troubleshooting

Does MainView SRM support devices HITACHI 7700 AND 9960?

MainView SRM Allocation and Reporting support HITACHI devices. MainView SRM does not provide reporting beyond standard IBM available statistics/information. That is, MainView SRM does not provide special RAID information (RAID director, PAV, controller statistics, and so on).

If NOCATLG2 is working correctly, why am I receiving the IBM message:

IGD17101I DATA SET dsname NOT DEFINED BECAUSE DUPLICATE NAME EXISTS IN CATALOG RETURN CODE IS rc REASON CODE IS rsnc IGG0CL xx

Message IGD17101I stating that a 'duplicate data set exists' can still be issued even if NOCATLG2 processing is successful. The IGD17101I message is even issued after MainView SRM issues the successful recatalog message. This occurs because MainView SRM intercepts SMS processing and then drives SMS VTOC/data set services (VDSS) from the code to determine whether each catalog/allocation process is going to be successful. At this time, if the data set being allocated new already exists, SMS will queue the IGD17101I message, assuming that the system is returning to the module that will display the message. Instead, the system returns to MainView SRM and detects the allocation error, performs NOCATLG2 processing, and redrives VDSS for a second attempt.

During NOCATLG2 processing and before redriving VDSS, MainView SRM issues messages. MainView SRM then redrives VDSS and the successful allocation message is queued behind the IGD17101I message. When MainView SRM then regains control and, if all allocations are successful, returns control to SMS. Then, SMS issues both queued messages. As in the NOCATLG2 case, the successful allocation message, (IGD101I) will also appear if the allocation is eventually successful.

We do not want to use the security but it defaults in the log. Error message BBMXCL16E.

To prevent the error message, add the following DD statement to your SVOS Startup PROC:

//BBSECURE DD DISP=SHR,DSN=xxxx.xxxxx.xxxxx.BBACTDEF

Why am I receiving the following message:

ADDRESS TSO XCMD +++ RC(-3) +++

The BUDDSN command must run authorized. One of the installation steps is to add BUDDSN (and BUDGET) to the authorized command table in SYS1.PARMLIB. If this is not done, no function involving BUDDSN will work.

The following is a scenario to verify that BUDDSN is working properly:

1. Stop ISPF, returning to the READY prompt.

2. Issue the command TSOLIB ACTIVATE DSN(---name-of-BBLINK--)

3. Restart ISPF and re-test BUDDSN.

BMC does support TSOLIB. Just as with STEPLIB, TSOLIB provides support for APF-authorized libraries. BMC cannot guarantee, nor validate, that some other type of dynamic 'STEPLIB' function provides the same degree of service.

Bringing down SVOS Started Task generated the following message: MSG WAITING TO BECOME DORMANT. What should I do?

If you are not going to perform an IPL at this time, you should reply blank to this message. The product is waiting to resolve ENQUEUEs. You should display RES=ETILOAD for ENQUEUE. Review all jobs that show ETILOAD ENQUEUE. After you resolve the ENQUEUEs, the product will shut down. You can then restart.

Why does SYS1.LPALIB have to be on the DD within the PROC?

The modules have to be available at startup, either in the PROC or the SMMSYSxx member, in order for the system to check that the modules in the LPA library match, and to ensure that no mismatch exists in the entry points for the hooks. It determines where the entry points should be for the hooks and then goes to IBM modules in core to ensure that MainView SRM components are putting the hooks in the correct place. Therefore, it has to be available at startup with the ENQ, or it must be checked and the ENQ freed in the SMMSYSxx member.

Why is a DD statement for SYS1.LPALIB required within SVOS?

The DD statement can be coded in your SMMSYS00 global member as SYSLIB=SYS1.LPALIB.

When it was in the SVOS JCL, an enqueue occurred that required bringing down the Started Task (SVOS) to update the LPALIB. By using the SYS1.LPALIB parameter, the enqueue is freed.

How can we set the scale to gigabytes instead of bytes in the Space Utilization batch report?

The way to affect the scale on this view is to use the CUST command and alter the field sizes. The CUST command is documented in the Using MainView products. The product does not give you the ability to set the scale.

Why am I receiving the following message:

SVM2038I - unable to determine version of user EMCSYMMAPi load module

To provide extended EMC support for EMC Symmetrix devices at micro-code level 5x68 or later, MainView SRM requires the EMC ResourcePak Base. The SCF Started Task associated with EMC ResourcePak Base must be installed and active on each system on which MainView SRM is executed.

Note: If no EMC Symmetrix devices exist at micro-code level 5x68 or later, the SCF Started Task and ResourcePak Base product are not required.

BMC suggests that you make the EMC ResourcePak Base SCF load library available to MainView SRM; to do so, include the library in the LNKLST, the LPA, or the STEPLIB DD concatenation of the SVOS and performance collector Started Tasks.

Warning: The EMC SymmAPI functions are not available when you run MainView SRM on a VM guest machine. In that case, MainView SRM issues a message to the SVOS job log, indicating that extended EMC data is unavailable.

Why am I receiving the following messages:

SVM0036E MEMBER IN ERROR: SMMSYS00

SVO2121W UNABLE TO CONNECT TO BBI3, NO BBI3_SSID IN SMMSYS

Check the following items:

• Verify that you are not receiving the following messages:

  *SVM1002W **WARN** THE LICENSE FOR STOPX37/II HAS EXPIRED

  SVM0090E UNAUTHORIZED ATTEMPT TO USE SVOS

• If no valid password exists in the SMMSYSxx member, you will also receive the BBI3_SSID error message. If you add a valid password, the BBI3_SSID error will go away.

• If the error remains, review the SSID that you placed in the CAS, and verify that this SSID matches what you specified in SMMSYSxx for BBI3_SSID.

SVM4001I message occurs at the same time as the IEC070I 104-204 bearing the same DB2 data set name. StopX37/II has been told not to interfere with DB2 data sets. Why might these messages being produced? Are there any zap/PTFs to address this problem?

The product is performing as documented.

SVM4001I Recovery Attempt Failed to Pass FLST/RLST Criteria

This informational message indicates that your code has chosen not to provide any service for this DB2 DSN.

If you do not want to see this message, you can alter the level of messages that the product generates: go to the FLST and change or add a message parameter as follows:

SET MODE=INACT MSG=E

INC DSNTYPE = DB2

SET MODE = ACT, MSG=I

INCxxxxx

Why am I receiving the following messages:

SVO0006E: There was an error in the startup parameters for the svos component

SVO0006E: A successful system-level refresh (SMMSYSxx) must be done before this component can be started

To identify the system member in error, issue the following console command:

F SVOS, SVOS R,SYS=xx

If the error is the BBI3_SSID parameter, update it in the SMMSYSxx member.

To update the value of BBI3_SSID, SVOS must be stopped and restarted; it cannot be refreshed. The CAS subsystem name is specified in the SSID= parameter on the PARM= keyword for the CAS JCL EXEC statement.

Note: Even if you are not using the MainView panels, you must have a value in the BBI3_SSID parameter in the SMMSYSxx to start SVOS.

Why am I receiving the following message:

SVO0612 START FOR prdname FAILED ON subsys

SVALLOC and the specified product called xxxxx were started at the same time. Both products are trying to hook IBM allocation modules at the same time. To resolve the problem, delay the start of one product by a couple seconds.

When running MainView SRM performance collectors in sysplex with multiple LPARs, does each LPAR need its own file?

You can have up to 99 different performance collector databases allocated and viewed within MainView SRM.

Are there data sets that need to be shared between all SYSPLEXs?

Only the Application databases should be shares across LPARS. The other databases can be (and probably should be) system specific. If the LPARS within the sysplexes use the same DASD configurations, you might not want or need to run a performance collector on each system (since it will be collecting and reporting the same information). You will, on the other hand, want to run individual performance collectors because the system-performance statistics might differ per system.

What data sets must be unique for each sysplex?

If we make these data sets unique for each SYSPLEX, will we be able to view all SYSPLEXs / LPARs from any one system running MainView?

SVSGP must run as a Started Task on each LPAR, and each LPAR must have a unique performance collector database file.

The information that the performance collector collects is LPAR specific and must run in each LPAR with its own unique database.

You will be able to view information for each LPAR within your sysplex. You will not be able to view PRSM data from the PPF sysplex.

As for sysplex reporting, you can view data from any LPAR that is in the same VTAM network as the local LPAR. Which sysplex the LPAR is in, or whether the LPAR is in a sysplex, does not matter. The key is that the CAS on the local LPAR has to be connected with a CAS on the remote LPAR though VTAM definitions that you give to the CAS.

Should the UBBPARM, UBBSAMP, and UBBPROC only contain only the members we have modified?

UBBPARM, UBBSAMP, and UBBPROC contain site-modified parameter members. Also, you can have a separate BBPARM/UBBPARM per sysplex or per LPAR, or you can have one BBPARM/UBBPARM that is shared among all sysplexes, all LPARS in a sysplex, or any other combination. If you want, you that you can use one BBPARM/UBBPARM for all LPARS across all sysplexes using the FORSYSID= and/or FORSYSPLEX= keywords in the PARMLIB members. The advantage is that everything is in one place.

The sysplexing capabilities give you the ability to build and maintain one set of UBBPARM libraries (per sysplex) where all pools, globals, FLST, and RSLT members can be stored. They also provide the capability to view and edit MVW data on multiple LPARS within a sysplex from a common system. To do this, you still need the same DB definitions as they currently have. Most of the changes relate to adding the global parameters to allow sysplexing to the UBBPARM members to define your environment.