Bug 44664

Informational

GemStone/S 64 Bit

3.7.1, 3.7, 3.6.8, 3.6.7, 3.6.6, 3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4, 3.4, 3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.5, 3.3.4, 3.3.3, 3.3.1, 3.3, 3.2.16, 3.2.15, 3.2.14, 3.2.13, 3.2.12, 3.2.11, 3.2.10, 3.2.9, 3.2.8, 3.2.7, 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2, 3.1.0.6, 3.1.0.5, 3.1.x, earlier versions

Linked logins that inadvertently appear to become RPC

Topaz, and GemStone sessions in general, have an RPC interface supporting only multiple RPC sessions, and a linked interface that supports one linked and multiple RPC sessions.

To invoke the linked version, the topaz -l flag is used, which leaves the gemnetid field empty or set to a placeholder, this is used during login to indicate that the session should be linked. Subsequently, you can set the gemnetid (to gemnetobject or equivalent) to login an additional RPC session.

However, if you have a .topazini that sets gemnetid, the .topazini is executed as usual when topaz -l is started.  This sets the gemnetid so the first login is RPC, not linked.

Workaround

In v3.4 and later, the -L option instead of -l suppresses set gemnetid statements in topazini files. It is recommended to use this option when you need to start a linked topaz, to avoid any risk from topazini files.

Use caution in specifying a gemnetid in a topazini file.

Using separate topazini files and using -I to explicitly provide the filename, or -i to suppress the default topazini, can avoid problems.

If you are expecting a linked login, note a prompt such as
    topaz 2 >

which indicates an RPC login.


                

Last updated: 10/30/17