Broker Installation and Set-up Tips

Broker
Tips

Maintaining that sharing spirit, here are tips submitted by Hardhats who have installed the Broker. Please read them carefully and weigh their advice in light of your VISTA installation. Some of the things reported you may not experience.

Installation hints for RPC Broker Version 1.1
by Lloyd Milligan

Disclaimer: My VistA environment is not up-to-date or "fully patched". The problems I encountered may be
caused by old versions of routines, missing patches, etc.

1. The RPC Broker Installation guide states that Kernel patch XU*8*59 must be installed. This
is a KIDS patch. The version of PackMan on my system choked on the following:

"^DD",3.081,3.081,9,0)
$ZIO (optional)^F^^0;9^K:$L(X)>30!($L(X)<1) X

$ in column 1 tells PackMan to expect $ROU or $KID
or some such. The code has probably been changed in recent
versions. To work around this I modified routine ^XMP2,
adding a section at the end:

ZZ() ;;True if X is not a listed exception
Q:X?1"$J ".E 0
Q:X?1"$ZIO".E 0
Q 1

These are the two $somethings that occur in column 1 of XU*8*59. Then modify line XMP2+52, adding the code to ignore these $ symbols.

F I=1:1 D NT Q:+XCN'=XCN D:$E(X)="$" S1:X'["$TXT"&$$ZZ Q:+XCN'=XCN ...

Don't do this unless you have to. It is probably fixed in the current version.

2. When I installed patch XU*8*59, the RPC multiple in the XUS SIGNON option entry was created as text.
The entry is supposed to be a pointer to the REMOTE PROCEDURE file (#8994). Probably the entries did not exist in file 8994 at the time the option was being created. The code at RPC+5^XQCS assumes it is a pointer (i.e. numeric in the "B" x-ref); otherwise you get the error:

"The remote procedure X is not registered to option Y."

If this happens, confirm that the entries exist in file 8994. Then delete and reenter each RPC multiple (5 of them) in the XUS SIGON option.

[Editor Note: Indications from others and the author suggest that this - item 2 above - should not happen if you install patch 59 AFTER installing the Broker.]

3. Reasonably current versions of ^%Z* routines are needed. Most if not all the problems I encountered
with this install were out-of-sync routines, missing tags or wrong number of parameters (<DPARM> errors).
First I faked a lot of these, but then bit the bullet and loaded new kernel manager routines from a recent CD.

4. The RPC Broker Listener ^XWBTCPL and ^MSERVER both work (in MSM for Windows 95). The RPC Broker Systems Manual (1-19) recommends using MSERVER.

Running RPC Broker Version 1.1 on Cache under Win 95
The following information discusses modification of Vista RPC Broker code on the M server. Realize that you are taking on the responsibility of maintaining the code if you choose to make the modification. Hardhats will not be responsible for any consequences of such modification.

Greg Kreis reported the following problem on the Hardhats mailing list:

When I go on the road, I would like to take my Broker/Cache environment with me on my Win 95 laptop. So... I copied a working .DAT Vista database to the laptop, updated the configuration files so the global and routine mappings are correct and so far, so good....

When I start the Broker on port 9300 and then try the RPC test logon, it reports a NOTOPEN error at CAPI+6^XWBBRK2. That line of code is U XWBNULL. If you call D ^%ZIS and specify the NULL device, it returns a value of "//./nul". When I look at the system status, the spawned listener has the null device open. BUT,
when I look at the error trap, XWBNULL is empty and does not contain the value "//./nul" as would be expected. Any ideas on why this variable is losing its value, when the same database works fine on the NT machine?

Since this is the same database .DAT file and version of Cache (2.1.6) that is on my desktop NT system, I am wondering if there is some other configuration I have missed. I am using the proper IP and port number when running the test connection.

Richard Vertigan posted the following reply (it appears to have solved the above problem):

There are two things you'll need to do to make this work, and I've just been
through it with the help of some others who had previously been down this
road:

1. To ensure the NULL device gets set (why it doesn't all the time is a mystery), make the following change to routine XWBTCPC, at line EN+23. Call it a "local mod":

        OLD: ELSE S IOP="NULL" D ^%ZIS S XWBNULL=IO

        NEW: ELSE D Q:IO=""
                     . F I=1:1:5 S IOP="NULL" D ^%ZIS I IO'="" S XWBNULL=IO Q ;Tries 5 times

2. Delete, hide, or rename CLAGENT.EXE on your laptop. It's not required and it's guaranteed to choke on the large PIDs generated by Cache under Win95. They're in excess of 4 billion, which is no longer the integer that CLAGENT.EXE was expecting. An exception is the result, followed by the server going bananas and consuming ALL system resources.

I'm now up and running after these two changes.