GDPS problem determination/detection tool

As other customers said, we would like to see all GDPS-messages associated with a message ID so we are able to find the description belonging to the error. Right now we need experience or luck when guessing what a message is supposed to mean.

A good idea, but a shame that we need it. The Netview log is almost incomprehensible and is full of traps. I'd prefer it if IBM tried to make it a bit more friendly.

LBG would be supportive of this idea. We consider it a high priority and would like it within the next two years.

Yes, a very good idea. One thing though and I think it was mentioned years ago. Could all GDPS messages be given a message ID? That would go some way in assisting, as it's only via experience that one gets to know what a message is saying, if it has no ID.

A silly example off the cuff is (albeit here easily understood) -

GEORPT ****************************************************

GEORPT * Coupling Facility List

GEORPT *---------------------------------------------------

GEORPT * CF1W1 008561.IBM.02.00000003E818

GEORPT * CF2W1 008561.IBM.02.00000005CFB8

GEORPT *---------------------------------------------------

GEORPT * GDPS Managed Coupling Facility list

GEORPT *---------------------------------------------------

GEORPT * CF1W1 008561.IBM.02.00000003E818 SITE1

GEORPT * CF2W1 008561.IBM.02.00000005CFB8 SITE2

GEORPT ****************************************************

None of the messages have a message ID.

It was just an idea.

A good idea and always useful to be able to pinpoint errors quicker.

Would be useful

Nice to have

Always a good addition to have more/faster information for problem determination. Or at least have (error) messages highlighted / marked in the Netlog.

Good idea. It always makes sense to make things easier

FIS/Worldpay agrees this would be helpful.

Could be useful.

This is a great idea!

We would appreciate such a solution. Many GDPS messages tell us to look for more information in the Netview log. And that contains tons of messages from all kind of Netview tasks as well as system messages. It's often hard to find the right information. And if the root cause is on another system it makes things not easier.

So broad to implement at once, but a start can be: add relevant info step by step. when you solve a PMR, and know which messages were the ones that you were looking for, add those. Step-by-step this might get better and better (or SMEs can read the netlog better, I know).

This would be very applicable to our site. We often find it difficult to dig through logs and decipher what the actual issue is.

For sure, interesting as idea, but not very urgent in my opinion.

I can see it would be a useful feature.

While Easylog may provide some details from the collected logs, the big stumbling block here (for us at least) is going to be that it is a Windows solution required on your laptop/PC.

Unfortunatley that is not going to be allowed within Citi, unless it's a fully supported like all other IBM software providing PTF's, SECINT fixes, EOS/EOL, etc etc.

Thanks

John

.Have you looked at the EasyLog tool available on the GDPS FTP site?

Have you looked at the EasyLog tool that is available on the GDPS FTP site?

The first example I can think of is when flashcopy fails because devices are online. I can't remember the specific msg, but within the error msg it had a DIAG=ucbn this indicated what the ucb was that was online/in a relationship etc, you then had to fo to the geoparm and work out the real ucbn, something that simplified this issue would help.

Thinking about it further when viewing the netlog it ocurred to me that although there is a filter facility on the netlog it would be helpful if a troubleshooting exec could be run that would focus on all the non standard msgs/reports that are in the netlog and pull out anomalies that need to be focused on, in the example that follows (I just randomly pulled this from a MM netlog) :-

GEODBG1 AUTLXW GKPY2 GDPS450-VPCLMON1: 'MON2'

GEODBG1 AUTLXH GKPY2 PH46911-VPCLSTAT: 'MON'

GEOTRC AUTLXH GKPY2 GDPS450-VPCLXMON: No heartbeat input found.

GEOTRC AUTLXH GKPY2 GDPS450-VPCLXMON: Next monitor will be after 1 Minute

GEODBG1 AUTLXW GKPY2 PH48881-VPCESYSM: 'CHKMSTR'

GEODBG1 AUTLXW GKPY2 PH48881-VPCESYSM: HS ongoing>0

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: '3'

GEODBG1 AUTLXW GKPY2 PH47784-VPCEQUCG: ''

GEODBG1 AUTLXW GKPY2 PH47784-VPCEQUCG: 0>$CKD>RL1>1>RS1 RS2>1>>1>003>1>1>1>OK>>(MW1>SITE1>OK>>>SWAP,GO>GO>MZGMY0Y1>1>)(MW2>

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 04>1

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 04>RS1 RS2

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 04>RS1/RS2

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 00>LOC<><>NORMAL<

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 02>11NORMAL 1/3 1/2<

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 09>Exit retval: RS1(SITE1)/RS2(SITE2)<

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: '3'

GEODBG1 AUTLXW GKPY2 PH47784-VPCEQUCG: ''

GEODBG1 AUTLXW GKPY2 PH47784-VPCEQUCG: 0>$CKD>RL1>1>RS1 RS2>1>>1>003>1>1>1>OK>>(MW1>SITE1>OK>>>SWAP,GO>GO>MZGMY0Y1>1>)(MW2>

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 04>1

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 04>RS1 RS2

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 04>RS1/RS2

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 00>LOCSER<><>NORMAL<

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 03>11NORMAL 1/3 1/2<

GEODBG1 AUTLXW GKPY2 PH43427-VPCESPMT: 09>Exit retval: SS1(MWSITE1)/SS2(MWSITE2)<

GEOTRC AUTLXW GKPY2 PH48881-VPCESYSM: old stat = GKPY2 KPY2 ACTIVE MWKPY2 NORMAL MWP7EF78 MWP7EF78.MWKPY2 MWP7EF78.MWKPY2

GEODBG1 AUTLXW GKPY2 PH48881-VPCESYSM: Ksys KPY1/GKPY1 in DASD PRI site - ACTIVE

GEODBG1 AUTLXW GKPY2 PH48881-VPCESYSM: Ksys KPY2/GKPY2 in DASD SEC site - ACTIVE

GEODBG1 AUTLXW GKPY2 PH48881-VPCESYSM: Temporary master list:

GEODBG1 AUTLXW GKPY2 PH48881-VPCESYSM: Master.1 = KPY2/GKPY2

GEODBG1 AUTLXW GKPY2 PH48881-VPCESYSM: Master.2 = KPY1/GKPY1

GEODBG1 AUTLXW GKPY2 PH48881-VPCESYSM: Current master = KPY2/GKPY2

GEODBG1 AUTLXW GKPY2 PH48881-VPCESYSM: No master change

GEODBG1 AUTLXW GKPY2 GDPS450-VPCECONS: 'TST VPCECONT NOWAIT'

D C,CN=VPCECONT

ING025I OUTBOUND CONNECTION WITH DOMAIN GHO43 RUNNING SA z/OS,V4R2M0 ESTABLISHED.

GEODBG1 AUTLXW GKPY2 GDPS450-VPCLMON1: Planned Action not outstanding

D TCPIP

GEOTRC AUTLXW GKPY2 GDPS450-VPCLMON1: VPCLMON1 TCPIP stack TCPIP is initialized (ACTIVE).

GEODBG1 AUTLXW GKPY2 GDPS450-VPCLMON1: remote_ksys This Ksys:GKPY2 Alt Ksys:GKPY1

GEODBG1 AUTLXW GKPY2 GDPS450-VPCEXMIT: 'B=GKPY1 QUERY VPC_SYSTEM_MASTER'

GEODBG1 AUTLXW GKPY2 GDPS450-VPCEXMIT: XCF-cmd=GEOCXCF1 VPCECCOM GEO040I GKPY2 AUTLXW GKPY1 AUTGEO1 QUERY VPC_SYSTEM_MAS

GEODBG1 AUTLXW GKPY2 GDPS450-VPCLMON1: Switch_Case: GKPY1 availability for xDR switch: 0 Master: GKPY2

GEODBG1 AUTLXW GKPY2 GDPS450-VPCEXMIT: 'B=GKPY1 QUERY VPC_XDR_SYSTEMS.0'

GEODBG1 AUTLXW GKPY2 GDPS450-VPCEXMIT: XCF-cmd=GEOCXCF1 VPCECCOM GEO040I GKPY2 AUTLXW GKPY1 AUTGEO1 QUERY VPC_XDR_SYSTEM

GEODBG1 AUTLXW GKPY2 GDPS450-VPCEXMIT: 'B=GKPY1 QUERY VPC_XDR_2ND.0'

GEODBG1 AUTLXW GKPY2 GDPS450-VPCEXMIT: XCF-cmd=GEOCXCF1 VPCECCOM GEO040I GKPY2 AUTLXW GKPY1 AUTGEO1 QUERY VPC_XDR_2ND.0

GEODBG1 AUTLXW GKPY2 GDPS450-VPCLMON1: Switch_Case: xDR switch situation: NO

GEODBG1 AUTLXW GKPY2 GDPS450-VPCLMON1: Switch_Case Master Ksys System/Nodes: 0 0 Avail: 0

GEODBG1 AUTLXW GKPY2 GDPS450-VPCLMON1: Switch_Case Alt. Ksys System/Nodes: 0 0 Avail: 0

Pulling these 2 :-

GEOTRC AUTLXH GKPY2 GDPS450-VPCLXMON: No heartbeat input found.

GEODBG1 AUTLXW GKPY2 GDPS450-VPCLMON1: Planned Action not outstanding

If I was looking for problems around the times these were issued (if the problem I'm looking for ocurred during this time frame) then although they look like errors, they aren't really.

There is so much traffic in the netlog that it can be difficult to "sort the wheat from the chaff", many times we've opened up a pmr as we couldn't find the error only for IBM to point it out to us (and once they did it was obvious that if we had found it we could have saved openeing a pmr).

So having some sort of exec that could pull all the pertinent errors msgs into one display would be extremely helpful.

Hopefully that provides a further insight to the type of thing that my initial request was aimed at.

Thanks

John