|
View previous topic :: View next topic
|
| Author |
Message |
drowelf
Warnings : 1
New User
Joined: 03 Mar 2006
Posts: 47
Location: Simpsonville, SC
|
|
|
|
I've got a SYSMDUMP from a z/OS 1.13 system that I have to send a 3rd party vendor for analysis. The problem is that they are not yet at 1.13 on their systems and have reported that they can not successfully process the SYSMDUMP on the 1.12 System they have.
Both of us have tried a search of various on-line resources and really cannot find a way around this issue. Is there any way to export the 1.13 SYSMDUMP in a format that can be consumed by IPCS in a 1.12 environment?
Thanks |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
kind of catch 22 situation here ...
if the product is officially supported on 1.13 it' s their problem
if the product is NOT officially supported on 1.13 it' s Your problem
good luck |
|
| Back to top |
|
|
drowelf
Warnings : 1
New User
Joined: 03 Mar 2006
Posts: 47
Location: Simpsonville, SC
|
|
|
|
Application is supported, and while that does technically make it their problem, its my production application that is encountering the issue and my users (and manager) don't really care about the gritty details of why the issue is not getting addressed in a timely manner.
Looking for any way to get this process jump started and research underway. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
Looking for any way to get this process jump started and research underway.
|
if the vendor is not technically qualified to support their product,
(not having the opt-sys vsn available qualifies as non-support)
get another product vendor.
if you are not in a position,
product approval/acquisition,
to enforce contract 'gritty details', get someone who is.
have someone in your company who is responsible for contract delivery,
enforce the contract.
obviously, you are not in that position.
have the vendor send a rep to your site,
today,
at their cost,
and solve the problem.
this is not a technical problem,
it is a legal problem. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
What has happened that caused you to decide to create/send the SYSMDUMP?
Which product has this problem?
Possibly someone here will recall a similar experience when they upgraded to 1.13 . . . |
|
| Back to top |
|
|
drowelf
Warnings : 1
New User
Joined: 03 Mar 2006
Posts: 47
Location: Simpsonville, SC
|
|
|
|
Its part of a niche product (30+ years old) used for Item (Check) Processing. Its most likely a data related issue, but as the vendor is the expert I'm going to let them determine issue, as thats what we pay the maintenance fees for.
The SYSMDUMPs get created whenever any application task within the On-Line System abends. We started getting several a night within the past week, so its time to open a case with the vendor and feed them them dumps for analysis. Thats when we learned that we got ahead of them and they are not up on 1.13 as yet. |
|
| Back to top |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
| The vendor should not need a 1.13 system to read the dump all they should need is a copy of the miglib. They can then allocate the miglib as a steplib and invoke ipcs. All they need is reasonable connections to IBM to get a 1.13 copy of the miglib. |
|
| Back to top |
|
|
drowelf
Warnings : 1
New User
Joined: 03 Mar 2006
Posts: 47
Location: Simpsonville, SC
|
|
|
|
| nevilh wrote: |
| The vendor should not need a 1.13 system to read the dump all they should need is a copy of the miglib. They can then allocate the miglib as a steplib and invoke ipcs. All they need is reasonable connections to IBM to get a 1.13 copy of the miglib. |
Can you expand on this or point to documentation? They have active 1.11 and 1.12 systems, but have reported that they have issues with trying to process 1.13 generated SYSMDUMPS on either of those systems. I'd love to be able to get them working on the dumps while they work on standing up a 1.13 LPAR. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
Everything is explained very clearly in the relevant manuals.
a simple/lazy google search with SYS1.MIGLIB returned
( faster than scrolling thry the zOS library )
publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ieac700%2Fiea2c77008.htm
where it is clearly said , guess what
| Quote: |
IPCS supplies the SYS1.MIGLIB system library to:
Allow IPCS and the component formatting and analysis programs in one version of MVS™ to function in another version of MVS.
Allow you to install installation-provided IPCS exit routines in your system. |
and
| Quote: |
The IPCS of z/OS must be used to format dump and trace data sets from z/OS systems.
Similarly:
The IPCS of MVS/ESA™ SP 5 must be used to format dump and trace data sets from MVS/ESA SP 5.
The IPCS of MVS/ESA SP 4 must be used to format dump and trace data sets from MVS/ESA SP 4.
The IPCS of MVS/SP™ Version 3 must be used to format dump and trace data sets from MVS/SP Version 3.
The IPCS of MVS/XA™ must be used to format MVS/XA dump data sets.
The IPCS of MVS/370 must be used to format MVS/370 dump data sets.
During transition from one system to another, the new IPCS may run under your previous system. Situations such as the following require consideration:
You were running a sysplex with two or more releases on various systems, generating traces on each. A problem occurred, and now you want to merge the traces. To accomodate you in this situation, IPCS, the central tracing components, and most components of z/OS permit the use of IPCS in the most recent release to process trace data sets. You may need to use COPYTRC to extract traces from dumps if that was the mechanism used to capture some of the traces, and you should confirm that the tracing support supplied by the components that wrote the trace entries supports this use.
You are a support programmer, and you are presented with a dump. The presenter cannot pinpoint the release that generated the dump. To accomodate you in this situation, IPCS from the most recent release will attempt dump initialization and basic processing sufficient to identify the release that generated the dump. Do not attempt to do any analysis beyond identifying the generating release, and do be prepared for some messages that result from data area changes between releases. Use DROPDUMP to remove all analysis records from the dump directory before performing analysis using IPCS from the correct release.
|
|
|
| Back to top |
|
|
drowelf
Warnings : 1
New User
Joined: 03 Mar 2006
Posts: 47
Location: Simpsonville, SC
|
|
|
|
Thanks a bunch, I'll pass this info along to the vendor.
Cheers, |
|
| Back to top |
|
|
|
|
