Fwd: Re: [vista-emergency-room] Primary station '101XXX' of the request does not match the primary station '100' of the M/Kernel system.'

[Nancy Anthracite]

--
Nancy Anthracite

---------- Forwarded Message ----------

Subject: Re: [vista-emergency-room] Primary station '101XXX' of the request
does not match the primary station '100' of the M/Kernel system.'
Date: Friday, August 17, 2012
From: Solomon Blaz <sol...@solomonblaz.com>
To: nanth...@earthlink.net
CC:

Also found this:
3.6.2 Connector Station and M System Mismatch

The primaryStation attribute is used to create the mappings that applications
use to retrieve the connector. It is always possible to misconfigure a
connector, associating it with the wrong station number. Station mismatch
checking is employed to catch such configuration errors.

When VistALink connects to an M system, the primaryStation attribute of the
connector is passed to M. It is then checked against the DEFAULT INSTITUTION
field of the Kernel System Parameters file. If it doesn't match, the
connection is rejected, and a SecurityPrimaryStationMismatchException is
returned to the application.
The system administrator should monitor the VistALink console and log files
for indicators of rejected connections due to primary station mismatches.


That explains the exception they're seeing, anyway.

Cheers,
Solomon

On Aug 17, 2012, at 12:30 AM, Solomon Blaz <sol...@solomonblaz.com> wrote:

> Hmmm, the VistALink System Management Guide
(http://www.va.gov/vdl/documents/Infrastructure/VistALink/vistalink_1.5_sysman_guide.pdf)
contains the following:
>
> primaryStation (required): Station number of the M/Kernel system connected
to. VistALink’s institution mapping functionality maps this station number to
the connector's JNDI name, so the application can retrieve the connector by
the station number. This entry is checked against the DEFAULT INSTITUTION
field of the KERNEL SYSTEM PARAMETERS file at runtime, when connections are
made.
>
> and
>
>
> primaryStationSuffix: This setting is for the very small number of VistALink
installations associated with institutions that have an alphanumeric suffix
attached to the station numbers. For example, if the M system’s DEFAULT
INSTITUTION is “500M,” the primaryStation attribute should be set to “500” and
the primaryStationSuffix attribute to “M.”
>
> I don't think that helps though if they have more than one division in the
same VistA account. It sounds like each VistALink connector checks the
DEFAULT INSTITUTION. You think that VistALink 1.6 might be required to handle
a multidivisional system? If it turns out they need to upgrade to VistALink
1.6, that should certainly be possible.
>
> Cheers,
> Solomon
>
> On Aug 16, 2012, at 5:38 PM, Nancy Anthracite <nanth...@earthlink.net>
wrote:
>
>> Thanks Solomon. I will see if I can locate a VistALink guru, but I think
the
>> instructions for VL 1.6 may contain the answer. It just may not be what
they
>> want to hear as they had configured their system in a way that does not
match
>> what is in the instructions so they are looking for another way to skin the
>> cat!
>>
>> --
>> Nancy Anthracite
>>
>> On Thursday, August 16, 2012, Solomon Blaz wrote:
>>> Nancy,
>>>
>>> Sorry I haven't chimed in on this thread. Um, the short answer is no, I
>>> don't know. I usually deferred to others on multidivisional site stuff.
>>> I know that it IS possible, as EDIS was running in several multidivisional
>>> sites, but the details in how to configure VistA and how to configure
>>> VistALink I don't know. The SecurityPrimaryStationMismatch exception is
>>> thrown by VistALink. Finding out how one of the multidivisional sites has
>>> set things is up is probably the best route to getting this resolved.
>>>
>>> Thanks,
>>> Solomon
>>>
>>> On Aug 14, 2012, at 2:33 AM, Wasim Naffar <w0795...@gmail.com> wrote:
>>>> David, please if you can ask him this question too:
>>>> What is the problem if I stop the "SecurityPrimaryStationMismatch"
>>>> validation from EDIS?? if no problem, how we can stop it from EDIS!!
>>>>
>>>> Regards,
>>>> Wasim
>>>>
>>>> On Mon, Aug 13, 2012 at 4:42 PM, David Whitten <whi...@netcom.com>
>>>> wrote: Retry
>>>>
>>>> On Mon, Aug 13, 2012 at 9:41 AM, David Whitten <whi...@worldvista.org>
>>>> wrote: Okay, I'll give my ideas of what is meant (with a little research
>>>> on my own).
>>>>
>>>> There is a file #8989.3 named KERNEL SYSTEM PARAMETERS File.
>>>> There is a field #217 named DEFAULT INSTITUTION
>>>>
>>>> This is the data dictionary field definition:
>>>>
>>>> STANDARD DATA DICTIONARY #8989.3 -- KERNEL SYSTEM PARAMETERS FILE
>>>> STORED IN ^XTV(8989.3, (1 ENTRY) (VERSION 8.0)
>>>>
>>>> DATA NAME GLOBAL DATA
>>>> ELEMENT TITLE LOCATION TYPE
>>>> -------------------------------------------------------------------------
>>>> ------
>>>>
>>>> 8989.3,217 DEFAULT INSTITUTION XUS;17 POINTER TO INSTITUTION FILE
>>>> (#4)
>>>>
>>>> (Required)
>>>>
>>>> LAST EDITED: FEB 14, 1993
>>>> HELP-PROMPT: Enter the instutition to use as a default
>>>> for
>>>>
>>>> uses without one.
>>>>
>>>> DESCRIPTION: This field is used to define a default
>>>>
>>>> institution that will be assigned as the

[Nancy Anthracite]

--
Nancy Anthracite

---------- Forwarded Message ----------

Subject: Re: [vista-emergency-room] Primary station '101XXX' of the request
does not match the primary station '100' of the M/Kernel system.'
Date: Friday, August 17, 2012
From: Solomon Blaz <sol...@solomonblaz.com>
To: nanth...@earthlink.net
CC:

>>> user's institution (DUZ(2)) for any user
>>> that doesn't have one.
>>>
>>> This means you choose a particular institution on your system as
>>> the value which will be used for institution if there isn't one defined
>>> already.
>>>
>>>
>>> On Mon, Aug 13, 2012 at 8:18 AM, Wasim Naffar <w0795...@gmail.com>
>>> wrote: Nancy thanks again :)
>>> I read the following paragraph many times, but i didn't understand
>>> clearly, "The configured value should exactly match the DEFAULT
>>> INSTITUTION value in corresponding M system's KERNEL SYSTEM PARAMETERS
>>> file (#8989.3). VistALink uses primaryStation to confirm that a
>>> connector is accessing the correct M system: if the two values don't
>>> match, connections are rejected."
>>>
>>> Apparently there is a variable named primaryStation used somewhere in the
>>> VistAlink code to mean the connector's institution.
>>>
>>> Please, someone can explain it for me! and why VistALink uses
>>> primaryStation to confirm a connector!! What is the problem if i want to
>>> connect EDIS to other division with different station number??? please
>>> explain!!
>>>
>>> I don't have a good answer to how multi-divisional hospitals handle