TUR3333 – No local Turnover system Defined

This week I mainly been playing with Turnover V100….

Preparing TURNOVER V100 (Software Change Management tool for IBMi Systems) for a major application upgrade, adding the ability to use Turnover Forms for specifically deleting and/or moving objects from one environment (library) to another.

In this case its because we are un-merging a custom program library and breaking it out into application base objects, custom vendor objects and custom internal objects. Yes, its a nice bit of tidy up that puts a smile on my soul.

Configuring Turnover to make it do this however… does not… put a smile on my soul.

It sometimes makes it quite grumpy in fact.

Especially when you get an annoying error on the TARGET system saying that it isn’t defined to itself.

A TURNOVER distribution was received but no local system is defined. Unexpected results may occur.

No Shit Sherlock!

Job 209096/TURNOVER/TOAUTORCV started on 02/09/12 at 10:58:40 in subsystem TS
25 objects restored from T105835120 to T105835120.
A TURNOVER distribution was received but no local system is defined. Unexpected Errors...
Job 209096/TURNOVER/TOAUTORCV ended on 02/09/12 at 10:58:44; 1 seconds used;

Now of course… the problem is that the system DOES EXIST otherwise how could I be signed into it… and using Turnover on it. Very confusing for a little while. Until I climbed out of the box and actually thought about it. So, without waffling any further the problem is caused by the fact that this system issuing LPARS to separate the systems. Turnover (in its wisdom) looks up the local machines serial number and then references its internal tables to find out what machine its on… as all LPARS have the same serial number it just grabs the first one it finds…. if that doesn’t happen to be YOU then BLAMMO… it errors.

A quick and functional fix for this is to add a SUFFIX LETTER to the other machines defined on the same physical machine as this LPAR. In other words, in each LPAR using Turnover each machine will be defined but only the active one will have the actual correct serial number.

For example:

System1 – Serial ABC – LPAR1

System2 – Serial ABC – LPAR1

The correct ones are in yellow

It’s a weird fix but it works perfectly… until Softlanding deliver a real fix or append the LPAR number into the machine identification algorithm.