Sunil will need to meet the criteria as checked below:

XQCS     ;SEA/Luke - Client/Server Utilities ;01/07/2003  13:53

         ;;8.0;KERNEL;**15,28,82,116,115,177,188,157,253**;Jul 10, 1995

         ;

CHK(XQUSR,XQOPT,XQRPC) ;Check to see if this user can run this RPC from

         ;this option.  Called by XWBSEC and XUSRB.

         ;

         ;Input: XQUSR-DUZ of user

         ;       XQOPT - name or IEN of the option

         ;       XQRPC - name or IEN of the remote procedure.  If this

         ;               variable is null no check is made to see if a

         ;               procedure is allowed.  That is, we only look

         ;               to see if the option is there and  if the user

         ;               has been assigned access to it.

         ;

         ;Output: XQMES - returned as 1 if the user is allowed to use this

         ;        option (and RPC is valid if XQRPC input variable is not

         ;        null), or as a message string explaining why the option

         ;        or RPC is not allowed.

         ;

         ;Rules: If M code exsists in ^DIC(19,option#,"RPC",rpc#,1) the

         ;       RULES field for a corresponding RPC, the software sets

         ;       the flag XQRPCOK to 1 and executes the field's code.

         ;       If the flag is returned as less than 1, the request for

         ;       use of that RPC is denied.  Rules are written by the

         ;       package developer and are not required.

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nancy Anthacite
Sent: Wednesday, August 11, 2004 10:49 AM
To: Hardhats
Subject: [Hardhats-members] ERROR: Application context has not been created

 

I found this about the application context.  I have been trying to help Sunil, and he is running into problem connecting and is getting the error "application context has not been created" after entering his access and verify codes. SO, can anyone enlighten us about what this is all about? He is using OV3 and GTM on Fedora Core 1.

"The RPC Broker is a client/server system within VistA environment. It enables client applications to communicate and exchange data with M Servers. Client access to broker is packaged as a Windows DLL and as a module for Borland Delphi applications. Applications constructed with these tools can easily access application objects running in M within the VistA environment. An application object, OR APPLICATION CONTEXT [caps are mine], on the server provides methods for manipulation by the client. Broker is fully integrated into the existing security infrastructure including authentication and access control. Authentication takes the form of a login/password dialog to authenticate the user to the M server."

Taken from  "Authentication Proxy for the VistA Hospital Information System" by William Majurski, NIST, October 1998.

Reply via email to