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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

HiPath 4000 V6, OpenScape 4000 V7, RMX not changing to 2016 4

Status
Not open for further replies.

sbcsu

Technical User
Feb 25, 2011
3,084
BV
Incorrect Year upon Change to 2016 Leading to Administration Block (all HiPath 4000 V6 & OpenScape 4000 V7 Versions are affected)

Problem
Detailed Problem Description and Symptoms: Incorrect year upon change to 2016 leading to administration block.
All HiPath 4000 V6 and OpenScape 4000 V7 versions are affected. HiPath 4000 V5 and earlier systems are not affected.
After year change to 2016 the system has an incorrect year. Due to this inconsistency the following effects can be noted:
• Administration blocked due to AMO CODEW date inconsistency
• Wrong year display on all TDM devices and IP devices not using NTP time as time source
• Potential issue on SPE (Signaling Payload Encryption) not working (currently under verification)

Problem Validation/Isolation Actions / Other Notes:
Solution
Permanent Solution: A permanent solution is under development with highest priority

Workaround/Temporary Solution: The following AMO commands can be used to provide a temporary workaround (not sevice impacting).
Care must be taken to execute them as written, and not alter or expand them to include additional commands
[e.g. do not add AMO APC commands].

CHA-FUNCT:SLANG=ENG;
CHANGE-DBC:LOCATION=TESTLAB;
EXEC-DATE:YEAR=2016,SYNC=NOSYNC;
CHANGE-DBC:LOCATION=CUSTOMER;
Notes:
• After any system restart/reload (including LINUX nodes switchover) the workaround must be re-applied (it is not persistent)
• 4K call control will no longer be synchronized to the main system and therefore some clock slippage maybe noticed over time
 
THANK YOU SO MUCH
 
hi,

sorry regarding this post its special for SBCSU,

How can i make program for a key to seizure the PSTN trunk and also see the busy indication for this trunk when it will be busy,

please make sure that when i program it as NAME, i can't monitor the busy indication for this trunk.

sorry for inconvenience,
 
Additional information I can share on this problem:

It is a hot and very visible issue and they are working on it as fast as they can. No one knows if it will be a patch, or a simple command string or whatever.

It affects thousands of systems world-wide running on the affected software.

There is one additional issue to note - Even though you have implemented the above listed temporary fix, if you do station administration using the Assistant the station database will lose sync during the night. On the front launchpad screen where everything normally says "Synchronous" you will see "Upload Required" after Stations.
This is simple to fix:
Just click where it says Upload required
On the next screen, do not enter any information - just press the Search button
After the screen populates go to "Action" at the top and choose "Upload"
This will resync all the databases to the active memory state and typically takes about 5 minutes.
Note: If you have a very big, or high traffic system it may be best not to do the upload during times of peak traffic as it is processor intensive.

One note on the comment about a reload requiring you to have to redo the fix: I am told that only a reload of the Admin Server (ADS aka A1) will require you to redo the fix. A simple soft restart on telephony will not require you to redo the change. I questioned this yesterday because I have other issues with my system and each night the active processor is doing a reload and switching to the standby processor and I have not had to redo the change - I was told only rebooting A1 would require redoing the change.



Don Bruechert, Voice Comm Analyst II
CareTech Solutions @ Holy Family Memorial
Manitowoc, WI, USA
 
Hi Donb01,

thanks for the info man, to tell you honestly I haven't done the upload of the HF yet. And I will take note of this.
My only prob here is that most of my client is a HOSPITAL so downtime is very crucial for them.

anyways thank you again

-rufum
 
The Upload I'm referring to is not in relation of any hotfix - the instructions sbcsu provided are merely a list of commands that one must execute in order, in Expert Mode/Comwin, to temporarily mitigate the problem.

The "Upload" I'm referring to is related to Unify/Siemens' fine German way of communicating where everywhere in the visiual part of the system they refer to the data as being "Synchronized" or "In Sync" but the command to re-sync the data, instead of being called "Resync" or "Synchronize" has been called "Upload"... Basically "Upload" is taking the data from the Actively running BP memory and using it to synchronize the data in the administrative module so that it matches the memory - in that way the memory and hard disk(s) are "In Sync".

If you are doing EXE-UPDAT:BP,ALL; twice and EXE-UPDAT:A1,ALL; twice after you are done making any changes to the system, which, simply stated, makes sure that both the primary hard disk database and the backup hard disk database are up to date with the changes you just made, it is not horribly bad if the Assistant says "Upload Required" after Stations **** BUT.... What that CAN lead to is you pulling up a station in assistant where you recently made changes, but it looks like those changes never got saved, where in actuality they got saved but Assistant "forgot about them". In that case, were you to go look in Expert Mode/Comwin, you would see that your changes are actually there. How everything interacts in these systems is a whole topic in itself, replete with lots of diagrams and arrows to try and help you understand it!


Don Bruechert, Voice Comm Analyst II
CareTech Solutions @ Holy Family Memorial
Manitowoc, WI, USA
 
RUFUM - the files you uploaded are for V7. Have anything for V6?

LoPath
Maintain HiPath 4000 V5 & V6, OpenScape Xpert V4, Xpressions, Contact Center
 
Unify says V6 hotfix should be out by COB Monday.

LoPath
Maintain HiPath 4000 V5 & V6, OpenScape Xpert V4, Xpressions, Contact Center
 
hi Lopath,

Yes sorry, its just for V7. I've already revised the post.

Rufum
 
Solutions:
thread965-1761210
 
Hi,

I have got a hot fix for our client systems but I couldn't upload the patch.

The Hot Fix I got is Platform_HF V7.R1.39.2 but my platform version is V7.R1.8.0.

I wonder if the problem is the difference between the version of my platform and the hot fix version or there is other problem that I should note to to it.

Thanks in advance for your help.

BR
 
Where is it failing ?
Can you copy the PDF exactly.
The patch on a duplex needs to be uploaded to the eth0 IP Address


thread965-1761210: HiPath 4000 V6 problem
 
There is not Patch vor V7 R1.8.x - you must use the MOP script on that version. V7 R1.39.x is the oldest V7 sersion that has a regular patch.

Don Bruechert, Voice Comm Analyst II
CareTech Solutions @ Holy Family Memorial
Manitowoc, WI, USA
 
Hi Don,
Yes not a patch - I had the wrong name.
It is an MOP
The file which is called fix_4K_2016_year.sh has to be ssh'd to the eth0 IP address
 
Dears,

Attached you can find the screenshot of my work trying to upload the HF.

As you can see the transfer button is inactive.

Honestly i didn't understand ho to fix the problem with above post.

so it would be my pleasure if you could help me out overcome this problem.

Regards,
Mohsen
 
 http://files.engineering.com/getfile.aspx?folder=05da443d-718f-41ef-ae94-fb69f346c1f5&file=IMG_2078.JPG
I would try to update the RMX, Assistant and Platform first to the available releases.
Then try and send in the time fix
 
How I should update the RMX , Assistance and platform . Where should I get the update?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top