It sounds like your user may have a login routine defined in their profile. If that's the case, and you exit the routine, the login will exit. It's a similar idea to a Unix captive account.

If you don't have a login routine in the user profile or aren't exiting the routine, can you give more details about exactly what's happening? Is this all users? Some? Does it happen when you switch to all namespaces or just some?

There's no built-in functionality to use the IP address as the username in Caché 2016.1 or 2016.2.  (I don't remember there being any way to do this in Caché 5.0 either, but maybe I just never looked.)

You might be able to implement something similar using delegated authentication, but I don't think it's a good idea.  Why do you want IP-based usernames?  It seems like this would be fragile and could break if there are network reconfigurations.

Aline has a good description of why this happens.  I wanted to say what it means, in case the effects are not obvious.  

This error means that your database isn't transactionally consistent.  Transactions have several properties.  One is that  either none or all of their updates will happen.  Another is that no one will be able to see a situation where some, but not all, of the updates have been completed.  This error is saying that a process was able to change part of these updates while the transaction was being worked on, and therefore we weren't able to safely return to having none of the updates happen.  

 To put this in an example:  pretend you're doing a bank transfer.  You're taking $100 from account A and putting it in account B.  You don't want the $100 to disappear (be removed from A and not added to B) or an extra $100 to be generated (not be removed from A and be added to B.)  This error is saying that one of those situations where money was created or destroyed probably happened.

To prevent this in the future, you'd want to look into whether there are missing locks in the code the processes involved are running.

I want to second Ben's advice to contact the WRC.  

I also want to add, for anyone reading this later, that moving the CACHE.WIJ file (as suggested in the error above) is an extremely dangerous operation.  Please don't ever do this without contacting the WRC.  Moving the WIJ can lead to data integrity problems which may or may not be obvious.  There are almost always other ways to start the system.