Group Pick Problem

[meltitdown]

Hi

Is there anyone who can tell me a way to remove this corruption which seems to occur when an extenison is deleted with out first being removed from the pick up group it might be in?

eg...

GROUP CALL PICKUP DATA
DIR GRP
2505 65535

END

VERSION=BC9.0/CNI84/LZY2035111/1/R1A

Once the grp number data is corrupt if you try to add or remove the extension from a group it is not allowed due to invalid grp number and so the extension can not be deleted.

any advice would be much appreciated!

 

[rorni]

Hi

You can try to remove and reinstall gpp (program unit where pick up are located).

- locate the lim where the corruption is located
- print all pu groups
- initial dump (dusii)
- lapur gpp and sfcei
- labul gpp, sfcei, sfpui
- reprogram pu groups
- check and backup

Beter to do this only if you have good knowledge of MD110. Else, ask your local reseller to fix it for you.
Regards
/rorni

 

[meltitdown]

Thanks for the quick reply. I might have a go and see what happens. I can't do any prints on the GP's because I just lost commands but from the HI log it looks like lim 21 might be a good place to start?

Thanks for you help.


TIME DATE ERROR CODE
15:08:17 02JUL03 H'17
FAULTY INDEX
LOGICAL PROGRAM ERROR ADDRESS = 02000B88
ENTER
SWSW A-LEVEL SIGNAL RELQUERCD (H'0021)
FROM GPP (H'168) EXE A IN LIM 021
TO GPP (H'168) EXE A IN LIM 001
NUMBER OF DATA BYTES IN SIGNAL = 7
WITH 0 1 2 3 4 5 6 7 8 9
000 02 59 00 01 85 15 21

USER STACK DUMP
0 1 2 3 4 5 6 7 8 9 A B C D E F
02 00 03 B8

 

[shaun123]

a quicker way that sometimes works is to restart gpp in all lims

 

[gcdhnjgfhfgsxh]

Hi

the best way to prevent this sort of corruption is to end all of the data associated with the phone (extension manager does this for you) then when there is nothing configured with the phone end it.

Dave

http://affy.dynu.net

 

[meltitdown]

well, I tried restarting GPP in every lim and that stoped the "Lost command"'s I was getting when I tried to print all the groups but didn't fixed the problem with the extensions that are in limbo with the group number showing:

<gpdap:dir=2505;
GROUP CALL PICKUP DATA
DIR GRP
2505 65535

END

So I guess I will try the other option which sounds a bit scary, but what could possibly go wrong.

Thanks for your suggestions!

 

[patcher]

This is not easy to fix. How many LIMs are involve here? Do you have a list of all pickup groups? Are you willing to loose them and reinitiate it later just for the sake of fixing this fault? If you dont have a list, you can print a group number 1 by 1. Example GPDAP:GRP=1; then grp 2.... until you hit the faulty grp, then skip this grp and continue until you have 20 unassigned group and stop. Probably thats all the group assigned. Then let us know if you finish collecting the info. Remember how many LIM???

Can you do this command and publish it here:
SACOP:LIM=1,UNIT=GHHS1,SECTOR=REL,ADDR=E5&F0;

//patcher

 

[serg75]

If you have a list of the problem groups, you must kill them. You may simply reinitiate all extensions that positioned in the problem groups to do this.
Well, you may:
- EXTEE/KSEXE (for all extensions in corrupted groups),
- EXTEI/KSEXI,
- GPGMI.

 

[meltitdown]

PATCHER: There are 22 lims...so I would prefer to find a better way than removing all the groups. Since I restarted gpp in all lims I can print a complete list of the groups which means I'm not sure of the offending group numbers. I do know one though so I will try and remove all the other extensions from it and see if that helps the extension which is corrupt.

<SACOP:LIM=1,UNIT=GHHS1,SECTOR=REL,ADDR=E5&F0;
MEMORY CONTENT ON ADDRESS POSITION
EXE A

ADDRESS 0 1 2 3 4 5 6 7 8 9 A B C D E F ISO
000000E0 00 00 00 00 00 EE 9E FF 7F AD EB 6F 2D 40 E9 7A ...........o-@.z
000000F0 29 C4 F3 3D 9E 44 DF 3F E6 DB 6F FB F4 3F FB FD )..=.D.?..o..?..
END

 

[meltitdown]

serg75:

If I try to delete one of the offending extensions which has a corrupt record in the group pickup area, it causes a reload. For example before I know there is a problem and I want to delete an extn with KSEXE I go to do it and it causes a reload, then when I check with GPDAP it has the group number of 65535, which of course is invalid and so the Exten can't be deleted. Not knowing previously which group it was in I don't which of my 400 group pick ups to try and end. Anyway, I have tried to end all of them but the system reloads before my send file gets through. (not always in the same place.)

 

[meltitdown]

Here is a good example of a different problem going on at the same time!:

<gpdap:grp=203;
GROUP CALL PICKUP DATA
GRP LIM DIR AGRP MGRP
203 1 6215

END

<gpgmi:dir=6215,grp=203;
NOT ACCEPTED
DIR IS IN A GROUP
<gpgme:dir=6215,grp=203;
NOT ACCEPTED
DIR NOT IN GROUP

And if I do a sudip the MD say's it's a different grp! Which I can remove it from OK?

 

[serg75]

SUDIP showing other group? What will be if to delete from it?
Probably, you have used command EXEQC/KSEXC some time. That's no good.
Let's wait what will tell patcher...

 

[patcher]

You have several corruptions in GPP which will make this more difficult to fix. Its easy for me but will take so much time to send information back and forth using this thread. The most easiest and fastest way is to remove GPP in all LIMS but if you are decided let me know dont do it yet. If you are decided, you had to print all pickup groups so you can put it back. I think this is the best solution for you. This will take a matter of less than 5 minutes only rather than using detailed solutions that will takes weeks to fix using this thread. Can you do this command again: SACOP:LIM=1,UNIT=GHHS1,SECTOR=REL,ADDR=E5&&1D0;
//patcher

 

[meltitdown]

<SACOP:LIM=1,UNIT=GHHS1,SECTOR=REL,ADDR=E5&&1D0;
MEMORY CONTENT ON ADDRESS POSITION
EXE A

ADDRESS 0 1 2 3 4 5 6 7 8 9 A B C D E F ISO
000000E0 00 00 00 00 00 EE 9E FF 7F AD EB 6F 2D 40 E9 7A ...........o-@.z
000000F0 29 C4 F3 3D 9E 44 DF 3F E6 DB 6D FB F4 3F FB FD )..=.D.?..m..?..
00000100 77 BE EC E4 41 8F 17 FC 07 08 D8 01 80 01 20 00 w...A......... .
00000110 03 04 01 86 07 00 00 F6 8E 1B 40 08 00 04 00 00 ..........@.....
00000120 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
END

Sorry for the delay patcher, I have been away.

Thanks for your help. I would prefer not to remove the program units just incase there is a problem. I have made a dump to INL but where are the units in the INL dump copied from? Is it possible to carry problems from the working program units into the INL.

 

[rorni]

Data corruption are not copied on INL directory because INL is only programm segment without any data.

INL path is /sysn/usr1/ses/dr/inl.

If your decided, follow the procedure I send before.

Good Luck

NB: backup and extra external backup is always a good idea before working on this type of problems

rorni

 

[meltitdown]

Thanks for your reply. I will give it a shot.

 

[patcher]

Hello meltitdown, is it fix? If not; DUPUI:LIM=1,UNIT=GPP; this will dump GPP on INL format under ADD directory. Then prepare your GP data (changed to initiation using pcregen or file edit manually). After all gp data are okay and ready to send, you need to LAPUR:LIM=ALL,UNIT=GPP; then SFCEI the system. After SFCEI, LAPUL:LIM=1&2&3&4...,UNIT=GPP; continue till the last LIM is loaded. Then SCFEI; Then SFPUI the unit in all LIMs. AFter successful loading. SACOS:LIM=1,UNIT=GHHS1,SECTOR=REL,ADDR=E5&&120,DATA=00;
Then dump the system. After dumping, you can put back all the gp data. //patcher

 

[rorni]

Hi Patcher,

What for is the Sacos you advise ?
Regards
/rorni

 

[patcher]

Hello rorni, that sacos is to clear the flag of the group. This is because everytime you initiate a pick up group. The flag for that group will be set. This case you cannot initiate the group with out removing it first. Example is the data of E5 is EE. EE is 1110 1110. This array contains the 1st 8 groups( 8765 4321 ). According to this data group 1 & 5 is not initiated. I hope you understand it. Another example is E6 is 9E. E6 is the next 8 groups (16151413 1211 109). Data is 9E = 1001 1110. Group 9&14&15 are not initiated. //patcher