TCL proc issue with Mapped drive

[Brian Sweetland]

I

Topic

[Russ Ross]

Just curious if you create a short cut on C: called C:R_Drive such that when you open C:R_Drive in windows explorere it takes you there, then you reference C:R_Drive in your TCL code instead of R: and see if that works.

Granted it will not tell you why R: is not working but could be a work around.

I found this shortcut method useful when using windows exploere since our mapped drives disappear sometimes and I have to recreate them but this way I have a shortcut that documents where the heck they are even when the mapping disappears.

Yes they show in the map drive drop down but with so many of them and no drive letter relations it was not easy for me to connect the dots but now it is.

Russ Ross
RussRoss318@gmail.com

[Brian Sweetland]

Short cut doesn’t seem to work. I can’t figure out how to identify it in the TCL code.

Example, I create a short cut of my “R:” drive called “rDrive” and place it on C:. When I run;

file exists “C:\rDrive”

I get “0”.

The other thing I tried today was calling a Command file from my TCL proc that runs in QDX.

exec cmd /C “mypath\mycommandfile” > null

It works fine in HCITCL, but if I try to run this in the TCL proc in QDX, I get “No default site — no site set”

[Michael Hertel]

Do you run as the same user with the same permissions or is the engine running as hciuser and you are running as your own login id?

[Brian Sweetland]

Different.

The QDX runs as HCIUSER. The system user is different. We had the customer set up the share with the system rights.

One of my coworkers was telling me how he used the QDX protocol “Mapped Drive” to connect to a shared drive, but in order to get that to work he had to have the site set up the share as the HCIUSER and add the domain. I was hoping that the TCL proc would avoid this. My experience has been difficult asking Customers to add our user and domain to thier network. And if they do, it seems to get dropped somewhere along the line.

I’m thinking of 2 options now. 1-have the site setup the share as FTP, then I can user QDX to send my PDF files through the engine.

2-set up a scheduled task every 5 minutes to call a Batch file that copies from my local directory to the shared directory.

[Brian Sweetland]

Okay, I have one even stranger.

I can

[Russ Ross]

I might be in outter space but I’m going to think out loud a bit.

There is a voice inside my head that is saying to try and do a ls (directory listing) of the mapped drive directory in your TCL code before your copy command.

I can’t connect the dots in my mind but that popped into my head as a possible work around to a mapped drive issue.

Russ Ross
RussRoss318@gmail.com

[Jennifer Hardesty]

Did you ever resolve this?  I seem to be having a similar issue trying to copy a file from an ftp folder to Cloverleaf.  Cloverleaf processes the messages in the file, but when I try to copy the file, I get a message that says there is no file.

[Brian Sweetland]

I did not resolve this the way I had hoped. I ended up doing all of my TCL file renaming and moved my local files to a TEMP folder. I then setup a scheduled task (batch file) to run every 15 minutes to copy/delete my files from the TEMP folder over to the Mapped drive.

Not really what I wanted. I wanted my file copy to be done in the TCL proc in real time and avoid the scheduled task.

[Levy Lazarre]

Brian,

A while ago, I was trying to do something similar (moving a pdf file) and I also found that Tcl would not let me use a mapped drive.

The work around was to create a share on the Windows server and set the appropriate permissions on the share. Tcl was then able to access the share and write the pdf file using the syntax

//servername//sharename/pdfname  (with forward slashes)

or the longer form with backslashes

\\servername\sharename\pdfname

Have you tried using a server share instead of a mapped drive? The share worked for me.

[David Barr]

I’m not quite sure why you were trying to use a TCL “file rename” command to move the file instead of forwarding it as a message to a fileset-local thread, but if you’ve got something working now, it probably not worth it to go back and fix what isn’t broken.

[Brian Sweetland]

I receive an XML msg via TCP to my thread. I then parse that msg to get needed info to go and find a corresponding PDF file in a different local folder. Then I take key info from that xml msg (MRN, acct#, etc

[David Barr]

Brian Sweetland wrote:

The PDF file never actually goes through my thread. Only the xml msg.

I then need to move that PDF to a customer server.

Right. I was suggesting that you could either create a new message or replace the existing XML message with the contents of the PDF, and route the new message to a thread that delivers directly to the customer server. You could use the identifiers from the original XML to update the driverctl metadata so that it would be delivered with the correct filename.  If the customer server is accessed through a mapped drive, the thread protocol would be fileset-local.

[Author]

Replies