Need Cache' help

[Kevin Toppenberg]

I am having unexpected results when debugging code in Cache' Studio's debugger.

From the debugger, I can't write a file to the "V:\" direcotry (a Windows mapped drive).  But I CAN do this when I run the exact same code from a Cache' terminal

Here is the code that highlights the problem:

TESTOPN  ;
        SET RESULT="SUCCESS"
        NEW F,FN
        SET F="TEST_IO.TXT"
        SET FN(1)="C:\"_F
        SET FN(2)="V:\"_F
        ZWRITE FN
        READ "Select entry to use: ",I,!
        IF +I'=I SET I=-1
        SET FN=$GET(FN(I))
        IF FN="" WRITE "NONE SELECTED. ABORTING.",! GOTO TODN
        OPEN FN:("WNS"):2
        IF '$T SET RESULT="FAIL" GOTO TODN
        USE FN
        WRITE "SAMPLE OUTPUT TEXT"
        USE $P       
        CLOSE FN
TODN     WRITE "RESULT=",RESULT," using file: ",FN,!
        QUIT

---- RUN #1 --------------------
Debugger executing 'TESTOPN^VEFACD05'
FN(1)="C:\TEST_IO.TXT"
FN(2)="V:\TEST_IO.TXT"
Select entry to use: 1

RESULT=SUCCESS using file: C:\TEST_IO.TXT
Program has terminated.
Target has exited debugger

---- RUN #2 --------------------
Debugger executing 'TESTOPN^VEFACD05'
FN(1)="C:\TEST_IO.TXT"
FN(2)="V:\TEST_IO.TXT"
Select entry to use: 2

RESULT=FAIL using file: V:\TEST_IO.TXT
Program has terminated.
Target has exited debugger

==== Now, running same code from Terminal =============

---- RUN #3 --------------------
CPM>DO TESTOPN^VEFACD05
FN(1)="C:\TEST_IO.TXT"
FN(2)="V:\TEST_IO.TXT"
Select entry to use: 1
RESULT=SUCCESS using file: C:\TEST_IO.TXT
 
CPM>

---- RUN #4 --------------------
CPM>DO TESTOPN^VEFACD05
FN(1)="C:\TEST_IO.TXT"
FN(2)="V:\TEST_IO.TXT"
Select entry to use: 2
RESULT=SUCCESS using file: V:\TEST_IO.TXT
 
CPM>


Notice that run #2 fails from the Studio debugger, but run #4 succeeds from the terminal.

Can anyone explain what is going on?  Apparently there must be a difference between the execution environments between the Studio and the Terminal.

Confused...
Kevin

[OldMster]

Kevin,

In more recent versions of Windows, mapped drives are only valid for the user that created them.  Your debugging session is running with the credential set in the service manager for the Cache service, and therefore have no mapped drives available.  In Cache Terminal, your process is running with the credential you logged in to the console and started terminal with, so drive 'V' that you mapped is valid for that process.  The default login for the Cache service is 'run as a service', and this does not allow Cache processes to access any windows network resources.

You can give Cache credentials so it can use a network share, but even then you have to use the UNC path (\\server\share\........), not a 'mapped' drive to access the network resource.  To do this, you need to go into the Control Panel, (maybe Administrative tools next), Services, and change the username/password that the Cache service uses.  Make sure that username/password has appropriate credentials to run Cache!  After you set the username/password, and restart Cache, any Cache process will now be able to access any network resources.  This is potentially a security hole, since ANY Cache process has the network credential set for the Cache service, so use it carefully.

Mark

[Kevin Toppenberg]

Mark,

This was VERY helpful.  Thank you!

While on a role here, let me see if you can help further.

I am developing an RPC that will execute on the VistA server (which will be Cache' I believe).  So the final execution of my code will not be either in Cache' Studio, or in the Terminal.  Can I expect similar problems with the RPC server process not having access, or proper credentials, to the Windows host OS?  When I started my approach, I knew that writing to HFS was possible through Kernel calls.  But now I am not sure the mumps code can authenticate itself etc to Windows.  I'll have to think about this. But any input will be further appreciated.

Again, I very much appreciate your reply.

Kevin

[Sam Habiel]

Kevin,

Many RPC calls from CPRS (esp the ones for Health Summary) write to
the disk and read-back. If not VISTA, certainly RPMS.

I just checked this one. It sure does write to the disk. So see what it does.

NAME: ORWRP PRINT WINDOWS REPORT TAG: PRINTW
ROUTINE: ORWRPP RETURN VALUE TYPE: GLOBAL ARRAY
WORD WRAP ON: TRUE
DESCRIPTION:
Prints CPRS GUI information to windows printer.

Sam

> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com

[OldMster]

Kevin,

All Cache processes are running in Windows using credential assigned to the Cache service.  The only exception to this are processes started through direct interaction of a user logged in to the local machine at the windows level (like Cache Terminal started locally from the cube).  If you were to click on 'Remote System Access', then 'Cache Telnet', and then telnet to the local box, your shared drives wouldn't work then either, since the process to service the telnet connection is started by the Cache Telnet Daemon,  and would be started with the Cache service credentials.

If the process using Cache Terminal issues a JOB command to start another process, I believe it is Jobbed with the Cache service credentials, not your logged in credential, but I haven't had time to verify that.

So, any Cache process that starts to service RPC calls is going to run with the service credentials, so mapped network drives would not work.  They can use the UNC name for a network share, provided the Cache service has been modified to  use a valid username/password that has access to that network share.  If they are running as the 'system service' account, they can access local paths, but has no access to network resources - shared paths or shared printers either.

Also note that this behavior changed from earlier versions of windows, because of changes to windows security not Cache.

Mark

> To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com

[Kevin Toppenberg]

Thanks so much, Mark and Sam.

My feeling that I was going crazy is starting to recede.  :-)

Kevin

On Wednesday, May 30, 2012 3:45:40 PM UTC-4, OldMster wrote:

Kevin,