Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
dipas_batch failure
- Thread starter balgaa
- Start date
Iamnothere
Technical User
After installing Unixware, the default IP address is 192.1.2.5. You can re-configure your PC's NIC with an IP address in that network, such as 192.1.2.50, or you can use the Atlantic LAN to reach Assistant @ 192.0.2.5. Your PC's NIC will need an IP address from the Atlantic LAN, such as 192.0.2.50.
You'll need to provide more info if you need more help. Are you saying that "dipas_batch" did work or did not work?
You'll need to provide more info if you need more help. Are you saying that "dipas_batch" did work or did not work?
- Thread starter
- #3
I can access to web assistant public area without any problem after reinstall UNIX...
but when try to login to Atlantic, to Customer LAN, then seems keep saying waiting for reply on web browser...
dipas_batch doesnt work, it cant login into RMX...
but when try to login to Atlantic, to Customer LAN, then seems keep saying waiting for reply on web browser...
dipas_batch doesnt work, it cant login into RMX...
- Thread starter
- #4
dipas_batch
********* RMX : LOGON at 2007/03/16 10:44:30 ONLINE BATCHPROCESSING ********
*** HICOM-Nr: RMX Contract: 00 Name:
*** CMX:200 -200 (CMX 0)
*** HICOM-Nr: RMX Contract: Name:
#
(It's identical to the message in software_activation file, I couldn't get RMX.)
procadmin -l -g mpcid
mpcilog Active Wed Mar 14 17:44:29 2007 mpcid 2124
mpcid Active Wed Mar 14 17:44:31 2007 mpcid 2141
#
(It looks OK)
********* RMX : LOGON at 2007/03/16 10:44:30 ONLINE BATCHPROCESSING ********
*** HICOM-Nr: RMX Contract: 00 Name:
*** CMX:200 -200 (CMX 0)
*** HICOM-Nr: RMX Contract: Name:
#
(It's identical to the message in software_activation file, I couldn't get RMX.)
procadmin -l -g mpcid
mpcilog Active Wed Mar 14 17:44:29 2007 mpcid 2124
mpcid Active Wed Mar 14 17:44:31 2007 mpcid 2141
#
(It looks OK)
Iamnothere
Technical User
Check the status of the hard drive: DIS-DDSM:a1;
All partitions "In Service"?
Is Controller 1 the active load device?
Does the system have dial tone?
Is the SIM installed in the ADP's DSCXL?
AMO CODEW OK?
All partitions "In Service"?
Is Controller 1 the active load device?
Does the system have dial tone?
Is the SIM installed in the ADP's DSCXL?
AMO CODEW OK?
- Thread starter
- #6
Check the status of the hard drive: DIS-DDSM:a1;
All partitions "In Service"?
Is Controller 1 the active load device?
<dis-ddsm:a1;
DIS-DDSM:A1;
H500: AMO DDSM STARTED
CONTROLLER: 1 IS ACTIVE LOAD DEVICE, LOAD AREA IS:
DS:
TYPE: HD SS-NO : <STDH4> SIZE : 3346 MB ( 53550*64KB) GRAN : 512
NON-RMX PARTITIONS:
SYSTEM ID SYSTEM NAME BEGIN / NO OF SECTOR(S) SIZE
H'12 UNIXWARE H' 68ABEB H' 139C5 39 MB ( 627*64KB)
H'63 UNIXWARE H' 69E5B0 H' 633F7CE 50814 MB ( 813039*64KB)
H'63 UNIXWARE H' 69DDD7E H' 5DE2BF 3004 MB ( 48069*64KB)
AREA: A NAME : A1H1A STATUS : I N S E R V I C E
AREA-SZ: 0 MB (2 *64KB) A-GRAN: 512
AREA: E NAME : A1H1E STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
DS:
ACTIVATED LOGICAL NAMES:
DS:
AREA-SZ: 200 MB (3200 *64KB) A-GRAN: 4096
AREA: F NAME : A1H1F STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
BDA:,BD:,:TMD:,AS:,:AMD:,MP:
ACTIVATED LOGICAL NAMES:
BDA:,BD:,:TMD:,AS:,:AMD:,MP:
AREA-SZ: 62 MB (992 *64KB) A-GRAN: 4096
AREA: G NAME : A1H1G STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
:CGD:
ACTIVATED LOGICAL NAMES:
:CGD:
AREA-SZ: 150 MB (2400 *64KB) A-GRAN: 4096
AREA: H NAME : A1H1H STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
MS:,SY:
ACTIVATED LOGICAL NAMES:
MS:,SY:
AREA-SZ: 70 MB (1120 *64KB) A-GRAN: 4096
AREA: I NAME : A1H1I STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
:SCR:
ACTIVATED LOGICAL NAMES:
:SCR:
AREA-SZ: 2047 MB (32767*64KB) A-GRAN: 4096
AREA: J NAME : A1H1J STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
:GLA:
ACTIVATED LOGICAL NAMES:
:GLA:
AREA-SZ: 200 MB (3200 *64KB) A-GRAN: 4096
AREA: K NAME : A1H1K STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
IAG:
ACTIVATED LOGICAL NAMES:
IAG:
AREA-SZ: 616 MB (9868 *64KB) A-GRAN: 4096
CONTROLLER: 6
TYPE: HD SS-NO : <CF1G3> SIZE : 1183 MB ( 18932*64KB) GRAN : 512
AREA: A NAME : A1H6A STATUS : P R E S E N T
AREA-SZ: 0 MB (2 *64KB) A-GRAN: 512
AREA: E NAME : A1H6E STATUS : B L O C K E D B Y A M O
CONFIGURED LOGICAL NAMES:
DS:
NO LOGICAL NAMES ACTIVATED
AREA-SZ: 200 MB (3200 *64KB) A-GRAN: 4096
AREA: F NAME : A1H6F STATUS : B L O C K E D B Y A M O
CONFIGURED LOGICAL NAMES:
BDA:,BD:,:TMD:,AS:,:AMD:,MP:
NO LOGICAL NAMES ACTIVATED
AREA-SZ: 62 MB (992 *64KB) A-GRAN: 4096
AREA: G NAME : A1H6G STATUS : B L O C K E D B Y A M O
CONFIGURED LOGICAL NAMES:
:CGD:
NO LOGICAL NAMES ACTIVATED
AREA-SZ: 150 MB (2400 *64KB) A-GRAN: 4096
AREA: H NAME : A1H6H STATUS : B L O C K E D B Y A M O
CONFIGURED LOGICAL NAMES:
MS:,SY:
NO LOGICAL NAMES ACTIVATED
AREA-SZ: 70 MB (1120 *64KB) A-GRAN: 4096
AREA: I NAME : A1H6I STATUS : B L O C K E D B Y A M O
CONFIGURED LOGICAL NAMES:
:MOD-SCR:
NO LOGICAL NAMES ACTIVATED
AREA-SZ: 701 MB (11217*64KB) A-GRAN: 4096
AMO-DDSM -111 DISK STATUS
DISPLAY COMPLETED;
<
Does the system have dial tone?
Yes, our system (Hipath 4000 V4) has dial tone and working properly. Only we had problem web access to assistant, then I reinstalled UNIX from SCR: RMX area. But still can't access to assistant.
Is the SIM installed in the ADP's DSCXL?
Yes, SIM installed on ADP's DSCXL
AMO CODEW OK?
Yes, codeword without any problem
All partitions "In Service"?
Is Controller 1 the active load device?
<dis-ddsm:a1;
DIS-DDSM:A1;
H500: AMO DDSM STARTED
CONTROLLER: 1 IS ACTIVE LOAD DEVICE, LOAD AREA IS:
DS: TYPE: HD SS-NO : <STDH4> SIZE : 3346 MB ( 53550*64KB) GRAN : 512
NON-RMX PARTITIONS:
SYSTEM ID SYSTEM NAME BEGIN / NO OF SECTOR(S) SIZE
H'12 UNIXWARE H' 68ABEB H' 139C5 39 MB ( 627*64KB)
H'63 UNIXWARE H' 69E5B0 H' 633F7CE 50814 MB ( 813039*64KB)
H'63 UNIXWARE H' 69DDD7E H' 5DE2BF 3004 MB ( 48069*64KB)
AREA: A NAME : A1H1A STATUS : I N S E R V I C E
AREA-SZ: 0 MB (2 *64KB) A-GRAN: 512
AREA: E NAME : A1H1E STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
DS: ACTIVATED LOGICAL NAMES:
DS: AREA-SZ: 200 MB (3200 *64KB) A-GRAN: 4096
AREA: F NAME : A1H1F STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
BDA:,BD:,:TMD:,AS:,:AMD:,MP: ACTIVATED LOGICAL NAMES:
BDA:,BD:,:TMD:,AS:,:AMD:,MP: AREA-SZ: 62 MB (992 *64KB) A-GRAN: 4096
AREA: G NAME : A1H1G STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
:CGD:
ACTIVATED LOGICAL NAMES:
:CGD:
AREA-SZ: 150 MB (2400 *64KB) A-GRAN: 4096
AREA: H NAME : A1H1H STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
MS:,SY: ACTIVATED LOGICAL NAMES:
MS:,SY: AREA-SZ: 70 MB (1120 *64KB) A-GRAN: 4096
AREA: I NAME : A1H1I STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
:SCR:
ACTIVATED LOGICAL NAMES:
:SCR:
AREA-SZ: 2047 MB (32767*64KB) A-GRAN: 4096
AREA: J NAME : A1H1J STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
:GLA:
ACTIVATED LOGICAL NAMES:
:GLA:
AREA-SZ: 200 MB (3200 *64KB) A-GRAN: 4096
AREA: K NAME : A1H1K STATUS : I N S E R V I C E
AREA-DATA IN DATABASE AND ADMINISTRATION AREA ARE EQUAL
CONFIGURED LOGICAL NAMES:
IAG: ACTIVATED LOGICAL NAMES:
IAG: AREA-SZ: 616 MB (9868 *64KB) A-GRAN: 4096
CONTROLLER: 6
TYPE: HD SS-NO : <CF1G3> SIZE : 1183 MB ( 18932*64KB) GRAN : 512
AREA: A NAME : A1H6A STATUS : P R E S E N T
AREA-SZ: 0 MB (2 *64KB) A-GRAN: 512
AREA: E NAME : A1H6E STATUS : B L O C K E D B Y A M O
CONFIGURED LOGICAL NAMES:
DS: NO LOGICAL NAMES ACTIVATED
AREA-SZ: 200 MB (3200 *64KB) A-GRAN: 4096
AREA: F NAME : A1H6F STATUS : B L O C K E D B Y A M O
CONFIGURED LOGICAL NAMES:
BDA:,BD:,:TMD:,AS:,:AMD:,MP: NO LOGICAL NAMES ACTIVATED
AREA-SZ: 62 MB (992 *64KB) A-GRAN: 4096
AREA: G NAME : A1H6G STATUS : B L O C K E D B Y A M O
CONFIGURED LOGICAL NAMES:
:CGD:
NO LOGICAL NAMES ACTIVATED
AREA-SZ: 150 MB (2400 *64KB) A-GRAN: 4096
AREA: H NAME : A1H6H STATUS : B L O C K E D B Y A M O
CONFIGURED LOGICAL NAMES:
MS:,SY: NO LOGICAL NAMES ACTIVATED
AREA-SZ: 70 MB (1120 *64KB) A-GRAN: 4096
AREA: I NAME : A1H6I STATUS : B L O C K E D B Y A M O
CONFIGURED LOGICAL NAMES:
:MOD-SCR:
NO LOGICAL NAMES ACTIVATED
AREA-SZ: 701 MB (11217*64KB) A-GRAN: 4096
AMO-DDSM -111 DISK STATUS
DISPLAY COMPLETED;
<
Does the system have dial tone?
Yes, our system (Hipath 4000 V4) has dial tone and working properly. Only we had problem web access to assistant, then I reinstalled UNIX from SCR: RMX area. But still can't access to assistant.
Is the SIM installed in the ADP's DSCXL?
Yes, SIM installed on ADP's DSCXL
AMO CODEW OK?
Yes, codeword without any problem
Iamnothere
Technical User
What happened to the HiPath 4000 V4 system that made it necessary to re-install Unixware 7 (UW7)?
Can you access UW7 via the UW7 console port (DSCXL), or via Telnet or via PuTTy? See if you can login to a character-based UW7 session using "engr". I trust that you are aware that after you re-installed UW7, the "engr" password will return to its default value. You ARE using the default password, correct? The UW7 password should be changed via Assistant ONLY. If you have changed the UW7 password via a character-based session, Assistant typically will not see that password change. Therefore, even if you have already changed the UW7 password in a terminal window, you should use the default "engr" password when logging on to Assistant. THEN allow Assistant to request that you change the password.
Please describe exactly what happens when you attempt to launch Assistant.
Have you attempted to review the UW7 installation log?
Since dipas_batch does not work, it sounds as if you have a RMX <-> UW7 pipeline problem.
Has anyone touched AMO USER? I remember someone once removed the "system" UserID from AMO USER, and experienced bizarre problems like yours.
Have you tried: ACT-DSSM:A1,1,,,YES; (The "YES" value here is to start the "UNIXBOOT").
Have you attempted a second UW7 re-installation? Make sure you select "RMX Scratchpad" as the source of the installation (as you have already stated). Should take only 2 hours max to re-install again.
Can you access UW7 via the UW7 console port (DSCXL), or via Telnet or via PuTTy? See if you can login to a character-based UW7 session using "engr". I trust that you are aware that after you re-installed UW7, the "engr" password will return to its default value. You ARE using the default password, correct? The UW7 password should be changed via Assistant ONLY. If you have changed the UW7 password via a character-based session, Assistant typically will not see that password change. Therefore, even if you have already changed the UW7 password in a terminal window, you should use the default "engr" password when logging on to Assistant. THEN allow Assistant to request that you change the password.
Please describe exactly what happens when you attempt to launch Assistant.
Have you attempted to review the UW7 installation log?
Since dipas_batch does not work, it sounds as if you have a RMX <-> UW7 pipeline problem.
Has anyone touched AMO USER? I remember someone once removed the "system" UserID from AMO USER, and experienced bizarre problems like yours.
Have you tried: ACT-DSSM:A1,1,,,YES; (The "YES" value here is to start the "UNIXBOOT").
Have you attempted a second UW7 re-installation? Make sure you select "RMX Scratchpad" as the source of the installation (as you have already stated). Should take only 2 hours max to re-install again.
- Thread starter
- #8
What happened to the HiPath 4000 V4 system that made it necessary to re-install Unixware 7 (UW7)?
-because I can't login via assistant web access or
that's why tried to reinstall from SCR...
Can you access UW7 via the UW7 console port (DSCXL), or via Telnet or via PuTTy? See if you can login to a character-based UW7 session using "engr". I trust that you are aware that after you re-installed UW7, the "engr" password will return to its default value. You ARE using the default password, correct? The UW7 password should be changed via Assistant ONLY. If you have changed the UW7 password via a character-based session, Assistant typically will not see that password change. Therefore, even if you have already changed the UW7 password in a terminal window, you should use the default "engr" password when logging on to Assistant. THEN allow Assistant to request that you change the password.
I can login using console port and using engr username, default password.
I didnt change password on console.
Please describe exactly what happens when you attempt to launch Assistant.
Have you attempted to review the UW7 installation log?
Try to login using engr and default password and it says waiting for... on status message...
Since dipas_batch does not work, it sounds as if you have a RMX <-> UW7 pipeline problem.
Yes, I read it from forum post...
Has anyone touched AMO USER? I remember someone once removed the "system" UserID from AMO USER, and experienced bizarre problems like yours.
Yes, didn't touch it...
Have you tried: ACT-DSSM:A1,1,,,YES; (The "YES" value here is to start the "UNIXBOOT").
Have you attempted a second UW7 re-installation?
Yes, tried 2nd, 3rd times...
Make sure you select "RMX Scratchpad" as the source of the installation (as you have already stated). Should take only 2 hours max to re-install again.
I tried UNIX installation from SCR... Is it correct?
-because I can't login via assistant web access or
that's why tried to reinstall from SCR...
Can you access UW7 via the UW7 console port (DSCXL), or via Telnet or via PuTTy? See if you can login to a character-based UW7 session using "engr". I trust that you are aware that after you re-installed UW7, the "engr" password will return to its default value. You ARE using the default password, correct? The UW7 password should be changed via Assistant ONLY. If you have changed the UW7 password via a character-based session, Assistant typically will not see that password change. Therefore, even if you have already changed the UW7 password in a terminal window, you should use the default "engr" password when logging on to Assistant. THEN allow Assistant to request that you change the password.
I can login using console port and using engr username, default password.
I didnt change password on console.
Please describe exactly what happens when you attempt to launch Assistant.
Have you attempted to review the UW7 installation log?
Try to login using engr and default password and it says waiting for... on status message...
Since dipas_batch does not work, it sounds as if you have a RMX <-> UW7 pipeline problem.
Yes, I read it from forum post...
Has anyone touched AMO USER? I remember someone once removed the "system" UserID from AMO USER, and experienced bizarre problems like yours.
Yes, didn't touch it...
Have you tried: ACT-DSSM:A1,1,,,YES; (The "YES" value here is to start the "UNIXBOOT").
Have you attempted a second UW7 re-installation?
Yes, tried 2nd, 3rd times...
Make sure you select "RMX Scratchpad" as the source of the installation (as you have already stated). Should take only 2 hours max to re-install again.
I tried UNIX installation from SCR... Is it correct?
Iamnothere
Technical User
I do not know your level of expertise with the 4K; therefore, I must assume that you have double-checked all the "little things". As a last resort, here's what I would try:
(1) I would reboot the ADP, which is the DSCXL processor in the bottom slot of the cPCI shelf. You should first deactivate the hard drive and shut down UW7, using DEA-DSSM. After deactivating the hard disk and shutting down UW7, simply press the reset button on the ADP. I recommend that you wait until after-hours! [I believe this action will correct your problem]
(2) If rebooting the ADP does NOT correct the problem, the SYSTEM may need to be reloaded, which would mean "NO DIAL TONE" for approximately 10-20 minutes, or longer if you have IPDA and/or STMI gateways. Do NOT attempt this action unless you are maintenance trained, you already have backups available, and you know what you are doing! If the reload fails, then you have escalated a "system management" problem into a "total system outage" problem. NOT GOOD!
EXE-REST:SYSTEM,RELOAD;
Good luck!
(1) I would reboot the ADP, which is the DSCXL processor in the bottom slot of the cPCI shelf. You should first deactivate the hard drive and shut down UW7, using DEA-DSSM. After deactivating the hard disk and shutting down UW7, simply press the reset button on the ADP. I recommend that you wait until after-hours! [I believe this action will correct your problem]
(2) If rebooting the ADP does NOT correct the problem, the SYSTEM may need to be reloaded, which would mean "NO DIAL TONE" for approximately 10-20 minutes, or longer if you have IPDA and/or STMI gateways. Do NOT attempt this action unless you are maintenance trained, you already have backups available, and you know what you are doing! If the reload fails, then you have escalated a "system management" problem into a "total system outage" problem. NOT GOOD!
EXE-REST:SYSTEM,RELOAD;
Good luck!
- Thread starter
- #10
If both doesn't method doesnt work...
Any solution?
Also we tried hard disk preparation from other H4K using PCHI v213 tool... After install new hard disk as replacement, during UNIX installation process 3 times, I got dipas_batch failure message then installation finish...
Seems UNIX and RMX pipe issue, but I surprise why this happen... Because we prepared new hard disk from other H4K...?
Any solution?
Also we tried hard disk preparation from other H4K using PCHI v213 tool... After install new hard disk as replacement, during UNIX installation process 3 times, I got dipas_batch failure message then installation finish...
Seems UNIX and RMX pipe issue, but I surprise why this happen... Because we prepared new hard disk from other H4K...?
Iamnothere
Technical User
Are you saying that you tried both, and neither a restart or a system reload corrected the problem?
To review what you did with the other 4K and PCHi: Inside PCHi, you first initialized the new hard drive, then built a new V4 hard drive with Unixware. This means that you had the HiPath 4000 V4 system files saved on your PC in the "HiPath4000V40" folder, correct?
When you removed the original hard drive, did you perform DEA-DSSM:a1,1 and shutdown UW7?
After you installed the new hard drive, did you activate it using ACT-DSSM:A1,1; ?
You should have then performed EXE-UPDAT:BP,all; and EXE-UPDAT:A1,all; (twice each) to save the database from memory to hard drive. Then you started the Unixware installation, but it failed with the same error, correct?
Sounds like you have a hardware problem on the cPCI shelf. Have you re-seated the ADP (DSCXL in slot 1)? If not, FIRST deactivate the hard drive and shutdown UW7, then re-seat the ADP. I cannot guarantee that the Switching Units will stay up, so make sure to do this work after-hours.
Usually this procedure is simple, but when the system is misbehaving like this one, expect the WORST. If the ADP is BAD, then the Switching Units may not load. Then there's no dial tone...
Your ADP board (DSCXL in slot 1) could be bad. Do you have a spare DSCXL? If not, do you have redundant Switching Units? If so, you could remove the STANDBY Switching Unit, and place it into the ADP slot as a TEMPORARY TEST PROCEDURE. Be sure to move the SIM from the old ADP to the new ADP board before you plug it in. Again, I recommend that this work be performed after-hours. If this new ADP board corrects your problem, be sure to order a new DSCXL and move the hardware back to its original positions.
The BEST thing for you to do is to contact SEN or a Partner. You could make this situation much worse by attempting to fix this problem without current backups, parts, or maintenance knowledge.
Unix is necessary for system management purposes only. As long as the Switching Units remain up, the customer is usually happy. But if your ADP is bad, it's just a matter of time before the system will NOT be happy! For example: The system cannot reload with a bad ADP.
Have you seen any "DSCR" errors when attempting to perform EXE-UPDAT or ACT-DSSM or DEA-DSSM? This warning message is a good sign that the ADP is having a problem managing its own disks.
Good luck
To review what you did with the other 4K and PCHi: Inside PCHi, you first initialized the new hard drive, then built a new V4 hard drive with Unixware. This means that you had the HiPath 4000 V4 system files saved on your PC in the "HiPath4000V40" folder, correct?
When you removed the original hard drive, did you perform DEA-DSSM:a1,1 and shutdown UW7?
After you installed the new hard drive, did you activate it using ACT-DSSM:A1,1; ?
You should have then performed EXE-UPDAT:BP,all; and EXE-UPDAT:A1,all; (twice each) to save the database from memory to hard drive. Then you started the Unixware installation, but it failed with the same error, correct?
Sounds like you have a hardware problem on the cPCI shelf. Have you re-seated the ADP (DSCXL in slot 1)? If not, FIRST deactivate the hard drive and shutdown UW7, then re-seat the ADP. I cannot guarantee that the Switching Units will stay up, so make sure to do this work after-hours.
Usually this procedure is simple, but when the system is misbehaving like this one, expect the WORST. If the ADP is BAD, then the Switching Units may not load. Then there's no dial tone...
Your ADP board (DSCXL in slot 1) could be bad. Do you have a spare DSCXL? If not, do you have redundant Switching Units? If so, you could remove the STANDBY Switching Unit, and place it into the ADP slot as a TEMPORARY TEST PROCEDURE. Be sure to move the SIM from the old ADP to the new ADP board before you plug it in. Again, I recommend that this work be performed after-hours. If this new ADP board corrects your problem, be sure to order a new DSCXL and move the hardware back to its original positions.
The BEST thing for you to do is to contact SEN or a Partner. You could make this situation much worse by attempting to fix this problem without current backups, parts, or maintenance knowledge.
Unix is necessary for system management purposes only. As long as the Switching Units remain up, the customer is usually happy. But if your ADP is bad, it's just a matter of time before the system will NOT be happy! For example: The system cannot reload with a bad ADP.
Have you seen any "DSCR" errors when attempting to perform EXE-UPDAT or ACT-DSSM or DEA-DSSM? This warning message is a good sign that the ADP is having a problem managing its own disks.
Good luck
- Thread starter
- #12
Are you saying that you tried both, and neither a restart or a system reload corrected the problem?
Tomorrow after work hours we will test it. I guess both doesnt help...
To review what you did with the other 4K and PCHi: Inside PCHi, you first initialized the new hard drive, then built a new V4 hard drive with Unixware. This means that you had the HiPath 4000 V4 system files saved on your PC in the "HiPath4000V40" folder, correct?
Yes, we did it
When you removed the original hard drive, did you perform DEA-DSSM:a1,1 and shutdown UW7?
Yes, we did it
After you installed the new hard drive, did you activate it using ACT-DSSM:A1,1; ?
Yes
You should have then performed EXE-UPDAT:BP,all; and EXE-UPDAT:A1,all; (twice each) to save the database from memory to hard drive. Then you started the Unixware installation, but it failed with the same error, correct?
Yes, it failed to finish installation successfully.
Sounds like you have a hardware problem on the cPCI shelf. Have you re-seated the ADP (DSCXL in slot 1)? If not, FIRST deactivate the hard drive and shutdown UW7, then re-seat the ADP. I cannot guarantee that the Switching Units will stay up, so make sure to do this work after-hours.
Usually this procedure is simple, but when the system is misbehaving like this one, expect the WORST. If the ADP is BAD, then the Switching Units may not load. Then there's no dial tone...
Let's try this too.
Your ADP board (DSCXL in slot 1) could be bad. Do you have a spare DSCXL? If not, do you have redundant Switching Units? If so, you could remove the STANDBY Switching Unit, and place it into the ADP slot as a TEMPORARY TEST PROCEDURE. Be sure to move the SIM from the old ADP to the new ADP board before you plug it in. Again, I recommend that this work be performed after-hours. If this new ADP board corrects your problem, be sure to order a new DSCXL and move the hardware back to its original positions.
We have redundant DSCXL. We have stand-by and active, totally 3pcs DSCXL installed on same chassis.
The BEST thing for you to do is to contact SEN or a Partner. You could make this situation much worse by attempting to fix this problem without current backups, parts, or maintenance knowledge.
Unix is necessary for system management purposes only. As long as the Switching Units remain up, the customer is usually happy. But if your ADP is bad, it's just a matter of time before the system will NOT be happy! For example: The system cannot reload with a bad ADP.
We will contact after everything your suggested if doesnt work at all
Have you seen any "DSCR" errors when attempting to perform EXE-UPDAT or ACT-DSSM or DEA-DSSM? This warning message is a good sign that the ADP is having a problem managing its own disks.
No any such error message
Tomorrow after work hours we will test it. I guess both doesnt help...
To review what you did with the other 4K and PCHi: Inside PCHi, you first initialized the new hard drive, then built a new V4 hard drive with Unixware. This means that you had the HiPath 4000 V4 system files saved on your PC in the "HiPath4000V40" folder, correct?
Yes, we did it
When you removed the original hard drive, did you perform DEA-DSSM:a1,1 and shutdown UW7?
Yes, we did it
After you installed the new hard drive, did you activate it using ACT-DSSM:A1,1; ?
Yes
You should have then performed EXE-UPDAT:BP,all; and EXE-UPDAT:A1,all; (twice each) to save the database from memory to hard drive. Then you started the Unixware installation, but it failed with the same error, correct?
Yes, it failed to finish installation successfully.
Sounds like you have a hardware problem on the cPCI shelf. Have you re-seated the ADP (DSCXL in slot 1)? If not, FIRST deactivate the hard drive and shutdown UW7, then re-seat the ADP. I cannot guarantee that the Switching Units will stay up, so make sure to do this work after-hours.
Usually this procedure is simple, but when the system is misbehaving like this one, expect the WORST. If the ADP is BAD, then the Switching Units may not load. Then there's no dial tone...
Let's try this too.
Your ADP board (DSCXL in slot 1) could be bad. Do you have a spare DSCXL? If not, do you have redundant Switching Units? If so, you could remove the STANDBY Switching Unit, and place it into the ADP slot as a TEMPORARY TEST PROCEDURE. Be sure to move the SIM from the old ADP to the new ADP board before you plug it in. Again, I recommend that this work be performed after-hours. If this new ADP board corrects your problem, be sure to order a new DSCXL and move the hardware back to its original positions.
We have redundant DSCXL. We have stand-by and active, totally 3pcs DSCXL installed on same chassis.
The BEST thing for you to do is to contact SEN or a Partner. You could make this situation much worse by attempting to fix this problem without current backups, parts, or maintenance knowledge.
Unix is necessary for system management purposes only. As long as the Switching Units remain up, the customer is usually happy. But if your ADP is bad, it's just a matter of time before the system will NOT be happy! For example: The system cannot reload with a bad ADP.
We will contact after everything your suggested if doesnt work at all
Have you seen any "DSCR" errors when attempting to perform EXE-UPDAT or ACT-DSSM or DEA-DSSM? This warning message is a good sign that the ADP is having a problem managing its own disks.
No any such error message
- Thread starter
- #13
- Status
Similar threads
- Locked
- Question
- Locked
- Question