dusyi command doesn´t work 1

[lpb612]

Hi guys!

I need your help again. I have a MD110 BC9 that dusyi command doesn´t work. I searched for helping at other threads about the similar problem. The REL1 has a error in file S1/L001 and the date file is missing, but REL2 is okay. If I reset the MD110, would I restore the system with the REL2 information or not? I´m afraid to reset the MD110 and the system doesn´t back to normal operation.

Here the problem:

<dusyirint=all,dump=all;
SYSTEM DUMP INFORMATION
BUFFER TRANSFER ERROR 14:21 17MAY17
FAILED FOR FILE DATE
END

<dubdp;
BACKUP DATA
BUFFER TRANSFER ERROR
END

<allop;
CLASS: 1
85 BUFFER TRANSFER HAS FAILED
DATE TIME ALP NOIF EQU BRDID INF1 INF2 INF3 INF4
17MAY17 15:15:23 5 1 001-0-60-00 69 301 2 1 1
END

<himdp:lim=1;
DIAGNOSTICS FROM OPERATING SYSTEM
TIME DATE
10:01:09 17MAY17
DIAGNOSTICS FROM LIM 001

TIME DATE ERROR CODE
09:57:56 17MAY17 H'44
COMMUNICATION STATUS ERROR AT BUFFER TRANSFER
SEND ERRORS, DUPLEX MODE = 000
RECEIVE ERRORS, DUPLEX MODE = 001
SEND ERRORS, SIMPLEX MODE = 000
EXE A IN LIM 170
END

<dubci:dir=inl;
SPONTANEOUS PRINTOUT
RESULT OF EXTERNAL BACKUP CHECK
INITIAL LOAD DIRECTORY
CHECK TERMINATED DUE TO FILE SYSTEM DETECTED ERROR
FILE/DIRECTORY DOES NOT EXIST
END

<dubci:dir=rel1;
SPONTANEOUS PRINTOUT
RESULT OF EXTERNAL BACKUP CHECK
RELOAD DIRECTORY REL1
CHECKSUM ERROR IN FILE S1/L001
END

<dubci:dir=rel2;
SPONTANEOUS PRINTOUT
RESULT OF EXTERNAL BACKUP CHECK
RELOAD DIRECTORY REL2
SUCCESSFUL
END

<fidapath=/sysn/usr1/ses/dr/rel1/*.*;
FILE/DIRECTORY DATA
FILE FITYPE LINKS OWNER SIZE DATE
P D 1 2 5072 13APR17 15:32
S1 D 1 2 16 13APR17 15:32
S2 D 1 2 0 13APR17 15:28
S3 D 1 2 0 13APR17 15:28
S4 D 1 2 0 13APR17 15:28
S5 D 1 2 0 13APR17 15:28
PID F 1 2 14582 13APR17 15:28
SID F 1 2 50 13APR17 15:28
IOPUF F 1 2 3029 13APR17 15:28
END

<fidapath=/sysn/usr2/ses/dr/rel2/*.*;
FILE/DIRECTORY DATA
FILE FITYPE LINKS OWNER SIZE DATE
P D 1 2 5072 30MAR17 8:59
S1 D 1 2 80 30MAR17 9:00
S2 D 1 2 0 30MAR17 8:55
S3 D 1 2 0 30MAR17 8:55
S4 D 1 2 0 30MAR17 8:55
S5 D 1 2 0 30MAR17 8:55
PID F 1 2 14582 12APR17 23:46
SID F 1 2 50 12APR17 23:46
IOPUF F 1 2 3029 12APR17 23:46
DATE F 1 2 7 12APR17 23:50
END

 

[inlsp05]

first of all before touch anything catch customer data with pc regen .....

http://telfonika.blogfa.com

 

[fcpli]

IPU PROMs are on the board, 2 big Eproms (usually) marked pos13 and pos14. Rfexi is not going to help, your problem is in the HDU or IPU. Copying this and that between the RELs - the same. If the system shows problem with PID, it means it didn't find even the first line from REL - nothing wrong with the PID itself. Dusii is not going to work, if no RELs are found, but you can try....

 

[himdp]

lbp612, you seem to be fixated on producing an INL dump, are you expecting to perform an initial load of the system? I suspect that the issue you are having performing a DUSYI will also prevent you from performing a DUSII even if you re-activate the command with SACOS.

You mention having a PC-Regen, I would echo inlsp05's recommendation to check you have a complete and viable data capture from the system before you try a restart.

Incidentally, the system does not need an INL to reload; all program code and data to reload the system are available in the REL directories.

Good luck.

 

[fcpli]

himdp,
I already tried to explain this - maybe in different words....

 

[himdp]

fcpli,
yes, you are doing a great job. It is like a gripping TV series, I am just getting a bit impatient to know the ending

 

[fcpli]

himdp,
As you can see, this is BC9. Therefore I just doubt if a 30Gb HDD is approved by the system without some kind of partitioning/formatting - actually no memories from the good old times. in my opinion, no MD command will fix this....

 

[himdp]

fcpli, I agree. I have checked through past posts for dump failure and buffer transfer error and the recommended fix seems to be to reload (not just restart) LIM 1. Quite drastic action if you are not sure that the reload will happen.

 

[lpb612]

Thanks guys!
I sincerely wanna see the end too. Rather a happy end.

I have another IPU, however with a different revision. Which are the steps to change the board? For some boards, first of all the board must be blocked. Is it the same or just change it?

 

[fcpli]

Check the revision (PROMs) first. If they are R18 or R19, OK. To change the board, just swap it, and wait for some seconds before reconnecting. Log off from the system before this....

 

[snor]

Hi,
in the past (many, many years ago) I had also a problem with DUSYI.
DUSYI allways failed with "BUFFER TRANSFER ERROR".
I tried to restart all units, which are handling "buffer transfer" (INR, INM, IPP) , but without any success.
.
The only one way to solve this problem was a reload of LIM 1, (--> data reload, and lost of all changes :-(
.
P.S.
with latest LPU-Eprom R9A (RYS 102320 R9A at position 23 and position 24) an "improvement of system dump" was implemented.
.
best regards,
Norbert

 

[fcpli]

Norbert,
So you suggest to reload LIM1? LALRL? From where do you think the data/programs is going to be picked up? Local? If there is no proper REL, you are in trouble. LADAI won't help, as also starting this and that. LPU PROMs R9A have nothing to do with this, the system is BC8/9 based, and even R6A was working OK. The system just does not find anything from REL (PID etc.). the idea is to find out a "soft" solution without taking a risk to have nothing left (note this is a live system)....

fcpli

 

[lpb612]

The running IPU is ROF 131 4507/1 R15B and has PROMs with R18A. The spare IPU is ROF 131 4507/1 R16A and has PROMs with R19B.

I will change it and after post the result.

 

[lpb612]

I changed it, but unfortunately it didn´t work.

 

[lpb612]

I tried to reactivate DUSII. It didn´t work. It´s missing sector parameter. In this case, which parameter can I use? DS, PROG or REL? I think it´s REL, but I´m not sure...

sacos:unit=drdh,lim=1,point=8,reloff=3,data=44,addr=195,sector=?;
sacos:unit=drdh,lim=1,point=8,reloff=4,data=55,addr=196,sector=?;
sacos:unit=drdh,lim=1,point=8,reloff=5,data=53,addr=197,sector=?;
sacos:unit=drdh,lim=1,point=8,reloff=6,data=49,addr=198,sector=?;
sacos:unit=drdh,lim=1,point=8,reloff=7,data=49,addr=199,sector=?;

 

[himdp]

lpb612, you have missed filno=1.

I think you will probably have the same error when trying to execute dusii.

 

[fcpli]

Sector=rel. Sorry, my fault...

 

[fcpli]

IPU PROMs R18 or R19 are ok, so it is still the HDU issue. DO NOT reload the LIM !!!

 

[himdp]

fcpli. It is not sector=rel, he forgot to include filno=1.

 

[fcpli]

himdp,
I need to wake up. You're right, still my mistake (now already 2 of them)...

 

[lpb612]

Thanks guys again.

I got to reactivate DUSII. The parameter FILNO was missing.
As you said DUSII didn´t work too. However, I decided to make another tests and I realized two things.
1) When I changed the HDU, the local backup is done. I can check with DUBDP result. This makes the suspected HDU fail. But two HDUs with the same problem? I have my doubts.
2) I tested the 1/2 conector SCSI cable from end to end and noticed a lack of continuity on the pins 22a, 24c, 26a, 26c and 28c. Is this correct?