General documentation needed for all problems with WebSphere MQ for z/OS - Middleware News
Here is a list of the general documentation you might be asked to submit for a PMR:
* Any hardcopy or softcopy illustrating the symptoms of the problem.
* The dump of the problem, see Getting a dump.
* The appropriate SYS1.LOGREC records, see SYS1.LOGREC information.
* The system log.
* A portion of the WebSphere® MQ for z/OS® job log.
* Trace records, see Using trace for problem determination.
* Trace information produced by the CICS® or IMS™ adapter, see The CICS adapter trace.
* Buffer pool statistics, see the sections on using SMF and type 115 records in the WebSphere MQ for z/OS System Setup Guide.
* Listings of relevant application programs.
* A list of PTFs and APARs applied.
Use the sample JCL below to produce a list of all the PTFs, APARs, user modifications and product code that has been installed in the global zone specified by SMPCSI:
//SMPELIST EXEC PGM=GIMSMP,REGION=4096K
//SMPCSI DD DSN=shlqual.global.csi,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SMPCNTL DD *
SET BOUNDARY(GLOBAL) .
LIST
SYSMODS
APARS
FUNCTIONS
PTFS
USERMODS
ALLZONES .
/*
* Dump of Coupling Facility administration structure, see Figure 5.
* Dump of Coupling Facility application structure, see Figure 5.
* Dump of other queue managers in queue-sharing group, see Figure 1.
* Definitions of the objects in your system.
You can find these by using the DISPLAY command for each type of object, for example:
DISPLAY QUEUE (*) ALL
Or, if you regularly make a backup of your object using the MAKEDEF feature of CSQUTIL COMMAND function, the output from that backup job.
* Your WebSphere MQ DB2® tables.
You can get these by using the sample job CSQ45STB in thlqual.SCSQPROCS to produce a report of all the DB2 tables used by WebSphere MQ.
Because of the size of SVC dumps in the cross memory environment, transfer the SYS1.DUMPxx data set to a tape or like device. You can use the PRDMP service aid program to transfer the SYS1.DUMPxx data set contents to another data set for archiving until the problem is resolved. Alternatively, your support center representative might give you the address of an FTP site where you can send your dump electronically.
Depending on the nature of the problem, the IBM® support center might ask you to send the entire dump on tape. This allows the support center to extract any additional data needed to resolve the problem; for example, CSA, SQA, or the private storage area.
Parent topic: Collecting documentation for the problem
Reporting a problem to the IBM software support group
The IBM® Product Support Services (PSS) Software Support structure exists to help you resolve problems with IBM products, and to ensure that you can make the best use of your IBM computing systems. Software support is available to all licensed users of IBM licensed programs; you can get assistance by contacting your local support center.
This chapter helps you to decide when to contact the support center, and what information you need to have collected before doing so.
* When to contact the support center
* Dealing with the support center
* Collecting documentation for the problem
* Sending the documentation to the change team
When to contact the support center
Before contacting the support center, try to ensure that the problem belongs with the center. Don’t worry if you can’t be sure that the problem is due to WebSphere® MQ for z/OS® itself. How sure you are depends on the complexity of your installation, the experience and skill levels of your systems staff, and the symptoms that your system has been showing.
In practice, quite a lot of errors reported to Software Support turn out to be user errors, or they cannot be reproduced, or they need to be dealt with by other parts of IBM® Service such as Hardware Customer Engineering. User errors are mainly caused by bugs in application programs, and mistakes in setting up systems.
Dealing with the support center
If you choose to contact the support center by telephone, your first contact at the support center is the call receipt operator, who takes initial details and puts your problem on a queue. You are subsequently contacted by a support center representative, and your problem is taken from there.
Alternatively, you might have access to an electronic system for reporting problems to the support center. In this case, a support center representative will respond to your communication.
The support center needs to know as much as possible about your problem, so have the information ready before contacting them. If contacting them by telephone, it is a good idea to write the information on a problem reporting sheet such as the one shown in Figure 1.
There are two advantages of using a problem reporting sheet when contacting the IBM® support center:
* In a telephone conversation, you will be better prepared to respond to the questions that you might be asked if you have all your findings before you on a sheet of paper.
* You can use the information for planning, organizing, and establishing priorities for controlling and resolving these problems.
Figure 1. Sample problem reporting sheet
PROBLEM REPORTING SHEET
Date Severity Problem No.
Incident No.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Problem/Inquiry
Abend Incorrout z/OS Release
Wait Module WebSphere MQ Release
Loop Message CICS Release
Performance Other IMS Release
DB2 Release
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Documentation available
Abend System dump Program output
Message Transaction dump Other
Trace Translator output
Symptom string Compiler output
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Actions
Date Name Activity
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Resolution
APAR PTF Other
If you use an electronic system for reporting problems to the support center, you should still include as much information as possible about your problem.
You should also maintain your own in-house tracking system for problems. A problem tracking system records and documents all problems.
Collecting documentation for the problem
As a general rule, the documentation you need to submit for a problem includes all the material you need yourself to do problem determination. Some of the documentation is common to all WebSphere® MQ for z/OS® problems, and some is specific to particular types of problem.
Make sure the problem you have described can be seen in the documentation you send. If the problem has ambiguous symptoms, you need to reveal the sequence of events leading to the failure. Tracing is valuable in this respect but you need to provide details that trace cannot give. You are encouraged to annotate your documentation, if your annotation is legible and does not cover up vital information. You can highlight any data in hardcopy you send, using transparent highlighting markers. You can also write notes in the margins, preferably using a red pen so that the notes are not overlooked.
Finally, note that if you send too little documentation, or if it is unreadable, the change team will have to return your problem marked “insufficient documentation”. It is, therefore, worthwhile preparing your documentation carefully and sending everything relevant to the problem.
The general documentation is described below. However, these are only guidelines, you must find out from the IBM® support center representative precisely what documentation you need to send for your specific problem.
Sending the documentation to the change team
When submitting documentation for your problem, your IBM® support center will advise you on the most appropriate method to use. Start of changeContact the support center for details.End of change
Each item submitted must have the following information attached and visible:
* The PMR number assigned by IBM
* A list of data sets on the tape (application source program, JCL, or data)
* A list of how the tape was made, including:
o The exact JCL listing or the commands used
o The recording mode and density
o Tape labeling
o The record format, logical record length, and block size used for each data set
When the change team receives the package, this is noted on your PMR record on the RETAIN system. The team then investigates the problem. Sometimes, they will ask for more documentation, perhaps specifying some trap you must apply to get it.
When you are satisfied that the problem is solved, a code is entered on RETAIN to close the PMR, and if necessary, you are provided with a fix.
You can inquire any time at your support center on how your PMR is progressing, particularly if it is a problem of high severity.
Here is a list of the general documentation you might be asked to submit for a PMR:
* Any hardcopy or softcopy illustrating the symptoms of the problem.
* The dump of the problem, see Getting a dump.
* The appropriate SYS1.LOGREC records, see SYS1.LOGREC information.
* The system log.
* A portion of the WebSphere® MQ for z/OS® job log.
* Trace records, see Using trace for problem determination.
* Trace information produced by the CICS® or IMS™ adapter, see The CICS adapter trace.
* Buffer pool statistics, see the sections on using SMF and type 115 records in the WebSphere MQ for z/OS System Setup Guide.
* Listings of relevant application programs.
* A list of PTFs and APARs applied.
Use the sample JCL below to produce a list of all the PTFs, APARs, user modifications and product code that has been installed in the global zone specified by SMPCSI:
//SMPELIST EXEC PGM=GIMSMP,REGION=4096K
//SMPCSI DD DSN=shlqual.global.csi,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SMPCNTL DD *
SET BOUNDARY(GLOBAL) .
LIST
SYSMODS
APARS
FUNCTIONS
PTFS
USERMODS
ALLZONES .
/*
* Dump of Coupling Facility administration structure, see Figure 5.
* Dump of Coupling Facility application structure, see Figure 5.
* Dump of other queue managers in queue-sharing group, see Figure 1.
* Definitions of the objects in your system.
You can find these by using the DISPLAY command for each type of object, for example:
DISPLAY QUEUE (*) ALL
Or, if you regularly make a backup of your object using the MAKEDEF feature of CSQUTIL COMMAND function, the output from that backup job.
* Your WebSphere MQ DB2® tables.
You can get these by using the sample job CSQ45STB in thlqual.SCSQPROCS to produce a report of all the DB2 tables used by WebSphere MQ.
Because of the size of SVC dumps in the cross memory environment, transfer the SYS1.DUMPxx data set to a tape or like device. You can use the PRDMP service aid program to transfer the SYS1.DUMPxx data set contents to another data set for archiving until the problem is resolved. Alternatively, your support center representative might give you the address of an FTP site where you can send your dump electronically.
Depending on the nature of the problem, the IBM® support center might ask you to send the entire dump on tape. This allows the support center to extract any additional data needed to resolve the problem; for example, CSA, SQA, or the private storage area.
Parent topic: Collecting documentation for the problem
Reporting a problem to the IBM software support group
The IBM® Product Support Services (PSS) Software Support structure exists to help you resolve problems with IBM products, and to ensure that you can make the best use of your IBM computing systems. Software support is available to all licensed users of IBM licensed programs; you can get assistance by contacting your local support center.
This chapter helps you to decide when to contact the support center, and what information you need to have collected before doing so.
* When to contact the support center
* Dealing with the support center
* Collecting documentation for the problem
* Sending the documentation to the change team
When to contact the support center
Before contacting the support center, try to ensure that the problem belongs with the center. Don’t worry if you can’t be sure that the problem is due to WebSphere® MQ for z/OS® itself. How sure you are depends on the complexity of your installation, the experience and skill levels of your systems staff, and the symptoms that your system has been showing.
In practice, quite a lot of errors reported to Software Support turn out to be user errors, or they cannot be reproduced, or they need to be dealt with by other parts of IBM® Service such as Hardware Customer Engineering. User errors are mainly caused by bugs in application programs, and mistakes in setting up systems.
Dealing with the support center
If you choose to contact the support center by telephone, your first contact at the support center is the call receipt operator, who takes initial details and puts your problem on a queue. You are subsequently contacted by a support center representative, and your problem is taken from there.
Alternatively, you might have access to an electronic system for reporting problems to the support center. In this case, a support center representative will respond to your communication.
The support center needs to know as much as possible about your problem, so have the information ready before contacting them. If contacting them by telephone, it is a good idea to write the information on a problem reporting sheet such as the one shown in Figure 1.
There are two advantages of using a problem reporting sheet when contacting the IBM® support center:
* In a telephone conversation, you will be better prepared to respond to the questions that you might be asked if you have all your findings before you on a sheet of paper.
* You can use the information for planning, organizing, and establishing priorities for controlling and resolving these problems.
Figure 1. Sample problem reporting sheet
PROBLEM REPORTING SHEET
Date Severity Problem No.
Incident No.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Problem/Inquiry
Abend Incorrout z/OS Release
Wait Module WebSphere MQ Release
Loop Message CICS Release
Performance Other IMS Release
DB2 Release
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Documentation available
Abend System dump Program output
Message Transaction dump Other
Trace Translator output
Symptom string Compiler output
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Actions
Date Name Activity
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Resolution
APAR PTF Other
If you use an electronic system for reporting problems to the support center, you should still include as much information as possible about your problem.
You should also maintain your own in-house tracking system for problems. A problem tracking system records and documents all problems.
Collecting documentation for the problem
As a general rule, the documentation you need to submit for a problem includes all the material you need yourself to do problem determination. Some of the documentation is common to all WebSphere® MQ for z/OS® problems, and some is specific to particular types of problem.
Make sure the problem you have described can be seen in the documentation you send. If the problem has ambiguous symptoms, you need to reveal the sequence of events leading to the failure. Tracing is valuable in this respect but you need to provide details that trace cannot give. You are encouraged to annotate your documentation, if your annotation is legible and does not cover up vital information. You can highlight any data in hardcopy you send, using transparent highlighting markers. You can also write notes in the margins, preferably using a red pen so that the notes are not overlooked.
Finally, note that if you send too little documentation, or if it is unreadable, the change team will have to return your problem marked “insufficient documentation”. It is, therefore, worthwhile preparing your documentation carefully and sending everything relevant to the problem.
The general documentation is described below. However, these are only guidelines, you must find out from the IBM® support center representative precisely what documentation you need to send for your specific problem.
Sending the documentation to the change team
When submitting documentation for your problem, your IBM® support center will advise you on the most appropriate method to use. Start of changeContact the support center for details.End of change
Each item submitted must have the following information attached and visible:
* The PMR number assigned by IBM
* A list of data sets on the tape (application source program, JCL, or data)
* A list of how the tape was made, including:
o The exact JCL listing or the commands used
o The recording mode and density
o Tape labeling
o The record format, logical record length, and block size used for each data set
When the change team receives the package, this is noted on your PMR record on the RETAIN system. The team then investigates the problem. Sometimes, they will ask for more documentation, perhaps specifying some trap you must apply to get it.
When you are satisfied that the problem is solved, a code is entered on RETAIN to close the PMR, and if necessary, you are provided with a fix.
You can inquire any time at your support center on how your PMR is progressing, particularly if it is a problem of high severity.
Comments
Post a Comment