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]

Put new hdd and
fimoe/iosie/iosii/ficri/fimoi ....dusyi
dont forget block/unblock i/o equ [pre][/pre]

http://telfonika.blogfa.com

 

[lpb612]

I have another HDU, but with version BC8. When I'll execute ficri the HDU will be formatted? After that will the files can be save into the new HDU without reset the MD110?
Can I do this without fear? Sorry, but I'm afraid that things can be worst because the PBX has essentials services.

Thanks for answering

 

[inlsp05]

When format lost all data in hdu bc8 blabla... and then after ficri/fimoi use DUSYI and system copy rek1&2 on hdu . No need restart md for simple dump !

http://telfonika.blogfa.com

 

[lpb612]

I did the steps, but it continues doesn´t work. Now it shows problem with PID file.

<dusyi:dump=all,print=all;
SYSTEM DUMP INFORMATION
RESULT OF PASSIVE COMMON FUNCTIONS UPDATE
SUCCESSFUL
WAIT FOR DUMP TO LOCAL BACKUP
RESULT OF DUMP TO LOCAL BACKUP
SUCCESSFUL
RESULT OF DUMP TO EXTERNAL BACKUP


BUFFER TRANSFER ERROR 15:21 18MAY17
FAILED FOR FILE PID

END

 

[fcpli]

So your ficri/fimoi was not correctly done. The system creates a new file system with fimoi, if the HDD is empty, including all the necessary info. Check your fidap after the commands given before here

 

[lpb612]

I did all the steps. I did again but the message is the same. However, I realized some curious. The first HDU has a hard disk with 30GB and the second has a hard disk with 2167MB. I don´t know but maybe the size of the ficri parameter could be wrong. How can I know the correct size of the ficri parameter?

thanks for reply

 

[inlsp05]

subfs11= 64mb/ subfs 21 64 mb

http://telfonika.blogfa.com

 

[lpb612]

The problem continues. I think the failure is on the creation of the PID file. What do I do now?

<BLEQI:EQU=1-0-60-0;
EXECUTED
<FIMOE:SUBFS=SYSSUBFS11;
EXECUTED

<FIMOE:SUBFS=SYSSUBFS21;
EXECUTED

<IOSIE:NODE=SYSN,IODEV=SYSDISK1;
EXECUTED

<IOSII:NODE=SYSN,IODEV=SYSDISK1,SIPOS=3,SUBFS=SYSSUBFS11&SYSSUBFS21;
EXECUTED

<FICRI:SUBFS=SYSSUBFS11,SIZE=64;
FICRI:SUBFS=SYSSUBFS11,SIZE=64;
SURE? (YES/NO)
<Y
EXECUTED

<FICRI:SUBFS=SYSSUBFS21,SIZE=64;
FICRI:SUBFS=SYSSUBFS21,SIZE=64;
SURE? (YES/NO)
<Y
EXECUTED

<FIMOI:SUBFS=SYSSUBFS11;
EXECUTED

<FIMOI:SUBFS=SYSSUBFS21;
EXECUTED

<BLEQE:EQU=1-0-60-0,ALLFM=YES;
EXECUTED
<IODDP;
I/O DEVICE DATA
NODE IODEV/SUBFS EQU/BPOS SIPOS VEND/USAGE STATUS
SYSN - 001-0-60 - - IN SERVICE
SYSN SYSDISK1 001-0-60-0 3 ADTX IN SERVICE
SYSSUBFS11
SYSSUBFS21
SYSN SYSTERMINAL 001-0-60-1 - MML -
SYSN PORTA2 001-0-60-2 - MML -
SYSN PORTA3 001-0-60-3 - MML -
END

<FISCP:IODEV=SYSDISK1;
FILE SYSTEM CAPACITY DATA
TOTAL DISK SPACE: 2067 MBYTES
SUBFS: SYSSUBFS11
KBYTES FILES
TOTAL AVAIL TOTAL MOUNTED
65535 64887 19200 /SYSN/USR1
SUBFS: SYSSUBFS21
KBYTES FILES
TOTAL AVAIL TOTAL MOUNTED
65535 64888 19200 /SYSN/USR2
END

<dubdp;
BACKUP DATA
EXTERNAL BACKUP LATEST PREVIOUS
REL1 REL2
NOT VALID NOT VALID
LOCAL BACKUP
DIVERGENT TIME AND DATE LIM 1 13:34 22MAY17 14:58 19MAY17
2 13:34 22MAY17 14:58 19MAY17
3 13:34 22MAY17 14:58 19MAY17
4 13:34 22MAY17 14:58 19MAY17
5 13:34 22MAY17 14:58 19MAY17

END

<fidapath=/sysn/usr1/ses/dr/rel1/*.*;
NOT ACCEPTED
FILE/DIRECTORY DOES NOT EXIST

<fidapath=/sysn/usr2/ses/dr/rel2/*.*;
NOT ACCEPTED
FILE/DIRECTORY DOES NOT EXIST

<dusyi;
SYSTEM DUMP INFORMATION
NO VALID RELOAD DIRECTORY EXISTS
RESULT OF PASSIVE COMMON FUNCTIONS UPDATE
SUCCESSFUL
WAIT FOR DUMP TO LOCAL BACKUP
RESULT OF DUMP TO LOCAL BACKUP
SUCCESSFUL
RESULT OF DUMP TO EXTERNAL BACKUP


BUFFER TRANSFER ERROR 13:42 22MAY17
FAILED FOR FILE PID

END

<dubdp;
BACKUP DATA
EXTERNAL BACKUP LATEST PREVIOUS
REL1 REL2
NOT VALID NOT VALID
LOCAL BACKUP
DIVERGENT TIME AND DATE LIM 1 13:41 22MAY17 13:34 22MAY17
2 13:41 22MAY17 13:34 22MAY17
3 13:41 22MAY17 13:34 22MAY17
4 13:41 22MAY17 13:34 22MAY17
5 13:41 22MAY17 13:34 22MAY17

END

<fidapath=/sysn/usr1/ses/dr/rel1/*.*;
FILE/DIRECTORY DATA
FILE FITYPE LINKS OWNER SIZE DATE
P D 1 2 0 22MAY17 13:41
S1 D 1 2 0 22MAY17 13:41
S2 D 1 2 0 22MAY17 13:41
S3 D 1 2 0 22MAY17 13:41
S4 D 1 2 0 22MAY17 13:41
S5 D 1 2 0 22MAY17 13:41
PID F 1 2 0 22MAY17 13:41
END

<fidapath=/sysn/usr2/ses/dr/rel2/*.*;
NOT ACCEPTED
FILE/DIRECTORY DOES NOT EXIST

<dusyi;
SYSTEM DUMP INFORMATION
NO VALID RELOAD DIRECTORY EXISTS
RESULT OF PASSIVE COMMON FUNCTIONS UPDATE
SUCCESSFUL
WAIT FOR DUMP TO LOCAL BACKUP
RESULT OF DUMP TO LOCAL BACKUP
SUCCESSFUL
RESULT OF DUMP TO EXTERNAL BACKUP


BUFFER TRANSFER ERROR 13:45 22MAY17
FAILED FOR FILE PID

END

<

 

[lpb612]

I have more doubts. I copied all files and directories from REL2 to REL1, from the original HDU.
ficpi:spath=/sysn/usr2/ses/dr/rel2,path=/sysn/usr1/ses/dr/rel1,coop=dir;
And it seems okay. But the INL seems doesn´t exist. I tried to execute dusii comand, but it´s unknown command in the system. The dusyi command has the same problem.
I did the backup with PC-REGEN.
My doubt is: if I reset the MD110, will the operation system load again? Where is the operation system (BC9) in INL memory or in both REL1 and REL2?

<dubci:dir=rel1;
RESULT OF EXTERNAL BACKUP CHECK

RELOAD DIRECTORY REL1
SUCCESSFUL
END

<dubci:dir=rel2;
RESULT OF EXTERNAL BACKUP CHECK

RELOAD DIRECTORY REL2
SUCCESSFUL
END

<dubci:dir=inl;
RESULT OF EXTERNAL BACKUP CHECK

INITIAL LOAD DIRECTORY
CHECK TERMINATED DUE TO FILE SYSTEM DETECTED ERROR
FILE/DIRECTORY DOES NOT EXIST
END

<dusii;
COMMAND UNKNOWN

<dusyi;
SYSTEM DUMP INFORMATION

BUFFER TRANSFER ERROR 14:48 22MAY17
FAILED FOR FILE DATE

END

<dubdp;
BACKUP DATA
BUFFER TRANSFER ERROR
END

 

[parnum]

Could be the IPU, have you pulled or replaced it?

Best parnum

 

[inlsp05]

ipu or hdu problem .

http://telfonika.blogfa.com

 

[fcpli]

The INL is in DR directory, not REL. Dusii command is hidden by somebody. Print out following:
sacop:unit=drdh,lim=1,filno=1,reloff=2&&7,point=8;
Except you cannot dusii anything, if your REL directories are empty. IPU revision (PROMs) in BC9 (just a memory), should be something like R19A. But this is not an IPU case...
Then (again memory), the HDU size maybe too big? The formatting with ficri maybe doesn't help... Not sure, 20 years since playing with BC8/9...

 

[lpb612]

Parnum,
I reset the IPU board, but the failure is the same. I didn´t change the IPU yet.

Inlsp05,
It´s possible both HDU have a problem. But the messages are different when I executed the dusyi command.

The first (30GB) shows:
<dusyi;
SYSTEM DUMP INFORMATION

BUFFER TRANSFER ERROR 14:48 22MAY17
FAILED FOR FILE DATE

END

The second (2167MB) shows:
<dusyi;
SYSTEM DUMP INFORMATION
NO VALID RELOAD DIRECTORY EXISTS
RESULT OF PASSIVE COMMON FUNCTIONS UPDATE
SUCCESSFUL
WAIT FOR DUMP TO LOCAL BACKUP
RESULT OF DUMP TO LOCAL BACKUP
SUCCESSFUL
RESULT OF DUMP TO EXTERNAL BACKUP


BUFFER TRANSFER ERROR 13:45 22MAY17
FAILED FOR FILE PID

END

Fcpli,
The authority class is 7.
Here is the print out of sacop command.

<sacop:unit=drdh,lim=1,filno=1,reloff=2&&7,point=8;
MEMORY CONTENT ON INDIVIDUAL POSITION
EXE A
FILE NUMBER RELOAD FILE START DS FILE START
1 00000152
POINT RELOFF DSOFF ADDRESS DATA ISO
0008 0002 00000194 05 .
0008 0003 00000195 20
0008 0004 00000196 20
0008 0005 00000197 20
0008 0006 00000198 20
0008 0007 00000199 20
END

 

[fcpli]

So your vendor has removed dusii. Just in case, before rearranging the command, print out sacop:unit=drdh,lim=1,filno=1,reloff=2&&7,point=0&&9;, just to see, if something else is also removed....

 

[lpb612]

Here is the print out. Is it possible to recover the dusii command changing the address with sacos command?

<sacop:unit=drdh,lim=1,filno=1,reloff=2&&7,point=0&&9;
MEMORY CONTENT ON INDIVIDUAL POSITION
EXE A
FILE NUMBER RELOAD FILE START DS FILE START
1 00000152
POINT RELOFF DSOFF ADDRESS DATA ISO
0000 0002 00000154 05 .
0000 0003 00000155 44 D
0000 0004 00000156 55 U
0000 0005 00000157 42 B
0000 0006 00000158 43 C
0000 0007 00000159 45 E
0001 0002 0000015C 05 .
0001 0003 0000015D 44 D
0001 0004 0000015E 55 U
0001 0005 0000015F 42 B
0001 0006 00000160 43 C
0001 0007 00000161 49 I
0002 0002 00000164 05 .
0002 0003 00000165 44 D
0002 0004 00000166 55 U
0002 0005 00000167 42 B
0002 0006 00000168 44 D
0002 0007 00000169 50 P
0003 0002 0000016C 05 .
0003 0003 0000016D 44 D
0003 0004 0000016E 55 U
0003 0005 0000016F 42 B
0003 0006 00000170 52 R
0003 0007 00000171 49 I
0004 0002 00000174 05 .
0004 0003 00000175 44 D
0004 0004 00000176 55 U
0004 0005 00000177 46 F
0004 0006 00000178 51 Q
0004 0007 00000179 45 E
0005 0002 0000017C 05 .
0005 0003 0000017D 44 D
0005 0004 0000017E 55 U
0005 0005 0000017F 46 F
0005 0006 00000180 51 Q
0005 0007 00000181 49 I
0006 0002 00000184 05 .
0006 0003 00000185 44 D
0006 0004 00000186 55 U
0006 0005 00000187 46 F
0006 0006 00000188 51 Q
0006 0007 00000189 50 P
0007 0002 0000018C 05 .
0007 0003 0000018D 44 D
0007 0004 0000018E 55 U
0007 0005 0000018F 50 P
0007 0006 00000190 55 U
0007 0007 00000191 49 I
0008 0002 00000194 05 .
0008 0003 00000195 20
0008 0004 00000196 20
0008 0005 00000197 20
0008 0006 00000198 20
0008 0007 00000199 20
0009 0002 0000019C 05 .
0009 0003 0000019D 44 D
0009 0004 0000019E 55 U
0009 0005 0000019F 53 S
0009 0006 000001A0 59 Y
0009 0007 000001A1 49 I
END

 

[fcpli]

Yes.
sacos:unit=drdh,lim=1,point=8,reloff=3,data=44&55&53;
sacos:unit=drdh,lim=1,point=8,reloff=6,data=49&49;

 

[lpb612]

Thanks fcpli.

But the problem continues. I think the solution will be reset the MD110. For the dubci commando REL2 is okay. Even the INL is empty, if I reset the MD110, will the system load correctly? I ran PC-Regen, case the system go back without the recent data.

 

[fcpli]

I don't think your REL2 is OK, because dusyi is not working. You can try to close REL1, and dusii. What happens? DO NOT kill the system - pcregen has only data, not any programs. As the people before here already replied, your HDU has something wrong. And still, if i remember, there was a restriction of the HDU size in BC8/9 (something like 1 or 2 Gb). Your IPU should have PROMs R19A or maybe R18A

 

[lpb612]

Fcpli, thanks again for reply.

I did some tests.
1. I deleted date file from REL1 and executed dusyi. The problem continues the same.
2. I deleted REL1 because the result of dubci was a checksum error in S1/LIM1 file. I copied all content of REL2 in REL1. Then I executed dubci again and it seems the REL1 is okay. But when I executed dusyi, the problem stills the same. Fail in date file.
3. I deleted REL1, copied date file from REL2 to a different directory and deleted date file from REL2. After that, I executed dusyi again but the result was failed in PID file. As same result when I had changed the HDU.

I did not already reactivate dusii. However, if I will and execute it, what will happen? If it didn't have another problem, the INL will be created. In this case I think I can execute rfexi, right or not?

How can I see the revision at PROMs, at the IPU stick?

I think in the worst case, I need a HDU with a INL only. So I could restart the MD110 and recover the data with PC-Regen.