E9.2 Changing ENT server names after go live - from 11 chars long to 10

[JohnDanter2]

Hi all

We have recently upgraded from 9.0 to 9.2 and I have noticed we have made out sever names too long to correctly stamp JOBN.
We have 2 Ent servers and they have now been called ABCDEFGHI1 and ABCDEFGHI2 for example.
The issue is any time one of these ENT servers stamps the audit field JOBN of any DB table (which is 10 long) it says ABCDEFGHI and we dont' know if the code ran on server 1 or 2. (this can be critical to fault diagnosis)

There is Oracle docs saying if you are going to name your servers up to 15 long (MKEY) then thats fine but make the 1st 10 chars uniqiue. For JOBN to work

So my question is, how easy to change these names and what it required? Is it something we can slide into out next planned outage for example?

Thanks

John

 

[TFZ]

I don't think its that complicated because I've installed it quite a few times. Off the top of my head, you need to update your server map/system records for the server data sources (you should have to rename your server map database name unless you want to do it for consistency.) You'll also need to fix your OCM records for both SY/SVM, fix your INI's, and then.... you can either update your package records and the F96511 or build a new full package.

You may find it easier to just add a new server if you have the resources, and then bleed the old one off.

 

[JohnDanter2]

Thats a super clever idea to add new ones
So there is no down time??? There must be right?

 

[TFZ]

If you're not in a rush. you're going to need to at least restart services in there, but nothing out of a normal outage windows. Add /define your new server, restart during your window, build a new full package for it / deploy it. Test it a bit. Then, during your next outage window, change your default logic OCM's and INI's to point to the new server, migrate UBE output if your'e not using the DB, and restart services. This is just a really rough summary, but that should do it.

There's a lot of things to think about after the fact (fixing records for UBE output, for instance) and maybe you have some locations that need to be setup on the new server for integrations, but you should be able to make the changes with minimal downtime (I'm saying two windows to give you the flexibility to play with it, build a full, and make sure it works.)

Now if you're just going to sql it.... you need to bring it down, rename it, fix your machine master record, fix your INI's, fix your OCM records, doctor up the current package tables, fix the server name in F986110/BIP tables, fix the server manager stuff, and bring it back up. Having done this a few times, I'm probably making this sound easier than it is, so you may feel safer with the longer path of adding a new server.

 

[Larry_Jones]

Uhhh, potential exists here to brick (not permanently) your system here.
Server. Names are in a lot of places.
I would not attempt this without a tested script and even then there will be downtime.