GPGME Not Accepted

[nschreuder]

Hi folks,

Can anybody help me with this?

<gpdap:grp=14;
GROUP CALL PICKUP DATA
GRP LIM DIR AGRP MGRP
14 3 5531

END

<gpgme:grp=14,dir=5531;
NOT ACCEPTED
DIR NOT IN GROUP

How come??? How to solve this?

 

[rfpui]

Try to restart program GPP
RFPUI:UNIT=GPP,LIM=3;


----------------------------------
If anything can go wrong, it will.
(Murphy's Law)

 

[nschreuder]

Thanks Rfpui, but unfortunately "you" didn't work.
Situation stays the same.
Ksexe/ksexi didn't work either.
Any other suggestions?

 

[rfpui]

Next program to restart is DGP

----------------------------------
If anything can go wrong, it will.
(Murphy's Law)

 

[nschreuder]

DGP is about Hunting Groups, not Call Pick-up Groups.
Are u sure about it?
Can you explain me (teach me)?

 

[nschreuder]

Things are becoming crazier!!

<gpdap:grp=14;
GROUP CALL PICKUP DATA
GRP LIM DIR AGRP MGRP
14 3 5531

END

<gpgme:grp=14,dir=5531;
NOT ACCEPTED
DIR NOT IN GROUP
<gpgme:grp=14,dir=all;
WAIT
WAIT
WAIT
WAIT
WAIT
WAIT
WAIT
WAIT
WAIT
WAIT
WAIT
WAIT
WAIT
WAIT
WAIT
WAIT

MESSAGE FROM OPERATING SYSTEM:
FAULT INTERRUPT
RELOAD REQUESTED
SYSTEM INITIATED DATA
RELOAD REQUESTED

<allop;
ALARM LOG
IDENTITY: MEANDERMC
VERSION: CXP1010111/2/BC12SP6KPN/R3B

DATE: 06APR06 TIME: 12:59:45
CLASS: 2
40 EXCHANGE DATA RELOADED
DATE TIME ALP NOIF INF1 INF2
06APR06 12:55:05 2 1 1 99

What do you think ... ?
Thanx in advance

 

[doktor]

It seems to be some data corruption.
Try to :
HIREI;
ALREI;
GPGME:GRP=14,DIR=5531;
HIMDP;
Paste the result of "HIMDP;" here in this forum.
In the HIMDP; there could be some program to restart.

Maybe a dump (DUSYI should be done before! the reload.
///doktor

 

[fcpli]

You could also, at the same time (referring to what doktor wrote) trace GHH just in order to see what happens when doing GPGME. One more thing: Is it possible to remove ANY single DIR from a group? If yes, try to initiate 5531 to another group (or create a new one, just for testing). Any luck? This seems to be a data corruption either in DER or GPP, and needs more information, but start with this....

 

[parnum]

Hi

I do not wish to interrupt any good advice but this looks like group pickup corruption which needs SACOS from E///, this is the most common corruption. I would go to your maintainer to get this fixed.

best Parnum.

 

[patcher]

Nothing you can do to fix it without using SACOS/SACOP command. Its hard for me to fix it for you because it will take days just for information transfer here and there. Is there any big disadvantage if you leave it there? Are you planning to rebuild/upgrade the switch? Rebuild is the only way to fix it easily. There is another way and if you really want to fix it just reply on with KSDDP:dir=5531;

 

[nschreuder]

To Doktor:

<hirei;
WAIT
EXECUTED
<alrei;
ALARM NOT FOUND

END
<gpgme:grp=14,dir=5531;
NOT ACCEPTED
DIR NOT IN GROUP
<himdp;

DIAGNOSTICS FROM OPERATING SYSTEM
TIME DATE
09:42:11 07APR06
NO INFORMATION STORED IN LIM 001, LAST HIREI: 09:41:29 07APR06
NO INFORMATION STORED IN LIM 002, LAST HIREI: 09:41:30 07APR06
NO INFORMATION STORED IN LIM 003, LAST HIREI: 09:41:30 07APR06
NO INFORMATION STORED IN LIM 004, LAST HIREI: 09:41:30 07APR06
NO INFORMATION STORED IN LIM 005, LAST HIREI: 09:41:30 07APR06
NO INFORMATION STORED IN LIM 006, LAST HIREI: 09:41:31 07APR06
NO INFORMATION STORED IN LIM 007, LAST HIREI: 09:41:30 07APR06
NO INFORMATION STORED IN LIM 008, LAST HIREI: 09:41:31 07APR06
NO INFORMATION STORED IN LIM 009, LAST HIREI: 09:41:30 07APR06
NO INFORMATION STORED IN LIM 010, LAST HIREI: 09:41:31 07APR06

END
Of course it is usefull to do DUSYI before a reload, but this reload was an automatic one, a reload by the system.


To Fcpli:

How do i trace GHH?
Yes, it's possible to remove any dir from any group. 5531 is initiated in another group. No problem at all.


To Parnum:

It's obvious that i contact my serviceprovider when i cannot solve it by myself (with or without the help from all of you guys)


To Patcher:

You're right. There's not thát big disadvantage, but it intrigues me what the reason is for why i can't remove it.
I'm an entrant and i want to learn all about "the old lady".
Anyway, it caused a reload and that worries me.
We upgraded (sw/hw) our switch just a year ago, combined with an additive of one LIM. Here is the printout you requested.

<ksddp:dir=5531;
KEY SYSTEM DIRECTORY DATA
DIR CUST EQU CAT ADN ODN CALALT TIMER
5531 001-2-40-06 34 1 0

END

Thanx again, friends.

 

[doktor]

I agree i what parnum and patcher writes.
Just sometimes you may be lucky to use my tricks to see what programmes need to be restarted, to solve this kind of problems.
///doktor

 

[patcher]

Okay can you do this commands.
1.SUSIPIR=5531;
In SUSIP you will see LINE STATE/PTR. Probably its somewhere in 03xx. Use this pointer in this next command.
2.SACOP:LIM=1,UNIT=GPP,FILNO=1,RELOFF=0&1,POINT=3xx;

3.SACOP:LIM=3,UNIT=GPP,FILNO=2,RELOFF=1,POINT=0&&F;
This will print 16 pick up groups in LIM 3 under the print DATA. Find which Pointer has a data 0E. Then use that Pointer(XX) on this next command.
4.SACOP:LIM=3,UNIT=GPP,FILNO=2,RELOFF=0&&16,POINT=XX;

Can copy and paste it here so I can see the data.

This is just the 1st step.

I hope the corruption is only in EXNFILE of GPP in LIM 1.

 

[nschreuder]

To Patcher

Below the printouts you asked for:

[tt]<susip:dir=5531;
STATUS INFORMATION AT 13:09:52 10APR06
DIR TYPE TRAFFIC STATE/PTR LINE STATE/PTR DIV STATE ADD INFO
5531 DTS IDLE #01C1 FREE #003A FME DIV=5635
ODN1:IDLE
ODN2:IDLE
ODN3:IDLE
END

<SACOP:LIM=1,UNIT=GPP,FILNO=1,RELOFF=0&1,POINT=03A;
MEMORY CONTENT ON INDIVIDUAL POSITION
EXE A
FILE NUMBER RELOAD FILE START DS FILE START
1 0000009E
POINT RELOFF DSOFF ADDRESS DATA ISO
003A 0000 00000186 04 .
003A 0001 00000187 08 .
END

<SACOP:LIM=3,UNIT=GPP,FILNO=2,RELOFF=1,POINT=0&&F;
MEMORY CONTENT ON INDIVIDUAL POSITION
EXE A
FILE NUMBER RELOAD FILE START DS FILE START
2 0000103E
POINT RELOFF DSOFF ADDRESS DATA ISO
0000 0001 0000103F 0C .
0001 0001 00001058 0E .
0002 0001 00001071 0F .
0003 0001 0000108A 13 .
0004 0001 000010A3 16 .
0005 0001 000010BC FF .
0006 0001 000010D5 FF .
0007 0001 000010EE FF .
0008 0001 00001107 FF .
0009 0001 00001120 FF .
000A 0001 00001139 FF .
000B 0001 00001152 FF .
000C 0001 0000116B FF .
000D 0001 00001184 FF .
000E 0001 0000119D FF .
000F 0001 000011B6 FF .
END

<SACOP:LIM=3,UNIT=GPP,FILNO=2,RELOFF=0&&16,POINT=01;
MEMORY CONTENT ON INDIVIDUAL POSITION
EXE A
FILE NUMBER RELOAD FILE START DS FILE START
2 0000103E
POINT RELOFF DSOFF ADDRESS DATA ISO
0001 0000 00001057 00 .
0001 0001 00001058 0E .
0001 0002 00001059 FF .
0001 0003 0000105A FF .
0001 0004 0000105B FF .
0001 0005 0000105C FF .
0001 0006 0000105D FF .
0001 0007 0000105E FF .
0001 0008 0000105F FF .
0001 0009 00001060 FF .
0001 000A 00001061 FF .
0001 000B 00001062 FF .
0001 000C 00001063 FF .
0001 000D 00001064 FF .
0001 000E 00001065 FF .
0001 000F 00001066 FF .
0001 0010 00001067 FF .
0001 0011 00001068 FF .
0001 0012 00001069 00 .
0001 0013 0000106A 10 .
0001 0014 0000106B 00 .
0001 0015 0000106C 00 .
0001 0016 0000106D 01 .
END[/tt]

 

[patcher]

The corruption is in the group itself. If you GPDAPIR=5531; You will see that it is included in another pickup group in LIM 8, the pointer of the group is 04, not sure what is the group number. But you can see on the command I gave you.

NCCOI, there are 2 ways to fix your fault. The 1st step is not dangareous and the 2nd is. The 2nd is not recommended because any mistakes will add more corruption. I wish I can log in and do it here.

By the way you try the 1st option. You will delete all pickup group in the system. Its not hard to do. You print all the group first. If you have PCregen you can translate the print to initiation file so you can put back the group again after you fix the fault. Don't forget to remove grp 14 in your send file. This steps is not dangerous, its a normal way, so no trouble doing this. Create 3 files, the GPDAP, GPGME/GPGRE, and GPGRI/GPGMI.

DUSYI 1st before you start. After you deleted all groups(be sure you deleted all groups), except group 14. Now you do this. SACOP:LIM=1,UNIT=GHH,SECTOR=REL,ADDR=EC; The data under EC should be 20. This means GRP 14 is still in the group array.

Then DUPUI:LIM=3,UNIT=GPP;
Then LAPUR:LIM=3,UNIT=GPP;
Then SFCEI;
Then LAPUL:LIM=3,UNIT=GPP;
Then SFCEI;
Then SFPUI:LIM=3,UNIT=GPP;
Then SACOS:LIM=1,UNIT=GHH,SECTOR=REL,ADDR=EC,DATA=00;

Now your corruption is fix, then send the initiation file without GRP14 because extension 5531 is in the other group.

Recheck your group again by GPDAP:GRP=ALL; and then recheck if corruption is 100% fix by sending GPGRE/GPGME file. All okay, put back the pickup group by sending GPGRI/GPGMI. Then DUSYI the system if everything are okay.

Not yet fix don't dump(DUSYI), LADAI the system to return to original data.

Don't be afraid, the steps you will do is normal. The 2nd options is shorter and quicker but risky because we will clean the group by SACOS command.

Good luck...

 

[nschreuder]

You're right, 5531 exists in another group. I moved it with all the other extensions to a new group.

Deleting and initiating all the call pick-up groups i discouvered the same problem in another group in another LIM. I tried RFPUI once again but that didn't work.

I'll not execute your second option, because I don't consider our system stable enough to perform well during that procedure.
I'm not sure how the MD will behave itself while executing SFCEI.
I'll contact my serviceprovider.

Thanks again for all your help and advices. I'll keep them safe for the future.