
How to write file in client PC
Started by lkchoo, Feb 28 2005 02:21 AM
11 replies to this topic
#2
Guest_Guest_*
Posted 28 February 2005 - 02:23 PM
On our AIX server this works in logic.......
$$FULL-PATH-FILENAME = '/myunixprodata/myfile.txt'
#X = CLIENT.Send($$FULL-PATH-FILENAME,"C:\myfile.txt")
#X = CLIENT.Execute("C:\myfile.txt")
This will copy myfile.txt from the server to the client's hard drive and then open it up with whatever the client has associated with .txt files.
$$FULL-PATH-FILENAME = '/myunixprodata/myfile.txt'
#X = CLIENT.Send($$FULL-PATH-FILENAME,"C:\myfile.txt")
#X = CLIENT.Execute("C:\myfile.txt")
This will copy myfile.txt from the server to the client's hard drive and then open it up with whatever the client has associated with .txt files.

#4
Posted 01 March 2005 - 07:36 AM
Hi,
That should work on any ProIV 5.5 version on any platform, but you must be using the ProIV GUI Client.
There is no direct way to write to a file on a PC within ProIV other than those commands.
HTHs,
Rob D.
That should work on any ProIV 5.5 version on any platform, but you must be using the ProIV GUI Client.
There is no direct way to write to a file on a PC within ProIV other than those commands.
HTHs,
Rob D.
#6
Guest_guest23_*
Posted 01 March 2005 - 09:07 AM
There are other options using NFS/windows drive mappings
- map the client's drive on the server and use ALIAS to write the file directly.
Or map a drive on the server on the client ...
Or write a report that outputs to a clientside printer queue - that printer queue
may actually create pdf files from the input or whatever...
- map the client's drive on the server and use ALIAS to write the file directly.
Or map a drive on the server on the client ...
Or write a report that outputs to a clientside printer queue - that printer queue
may actually create pdf files from the input or whatever...
#7
Posted 01 March 2005 - 02:32 PM
guest23 raises a good point about the NFS. However, there are a couple of things to consider:
1) If your server is Unix based, you'll likely have line termination issues.
2) If your server is Windows based and you use NFS, you have to make sure that the operator that the ProIV service logs in as has access to the share. If you start experiencing problems going this route, the best troubleshooting you can do is follows:
Copy a ProISAM file to the share.
Use a properly structured ALIAS command to try to read the ProIV file on the share.
If this fails, you have a permissions issue (and you've just saved yourself hours of frustration!)
hth
Joseph
1) If your server is Unix based, you'll likely have line termination issues.
2) If your server is Windows based and you use NFS, you have to make sure that the operator that the ProIV service logs in as has access to the share. If you start experiencing problems going this route, the best troubleshooting you can do is follows:
Copy a ProISAM file to the share.
Use a properly structured ALIAS command to try to read the ProIV file on the share.
If this fails, you have a permissions issue (and you've just saved yourself hours of frustration!)
hth
Joseph
#8
Posted 26 April 2005 - 07:34 PM
For unix you can use "ux2dos"/"dos2ux" or "dosread"/"doswrite" to clean up the unix output for DOS use.
I imagine if you wanted, instead of hardcoding "lp -s -d" in the spooler command, you can use a script instead. The 1st parameter will be the printer, the 2nd "$2*" will be the stdoutput..
For a specific device, you could pass the stdout to the appropriate ux-2-dos command to a text file
and move it on out. This would then not affect output for other printers defined in the system.
A quick FYI, "$$" will you give you the PID which you could use to tie to a /tmp/"$$".filename for this method.
I imagine if you wanted, instead of hardcoding "lp -s -d" in the spooler command, you can use a script instead. The 1st parameter will be the printer, the 2nd "$2*" will be the stdoutput..
For a specific device, you could pass the stdout to the appropriate ux-2-dos command to a text file
and move it on out. This would then not affect output for other printers defined in the system.
A quick FYI, "$$" will you give you the PID which you could use to tie to a /tmp/"$$".filename for this method.
#11
Posted 29 April 2005 - 08:55 PM
Maybe this isn't the same kind of thing...
If you can log on remotely to a customers site where Pro IV runtime (only) is installed (running on windows) is it possible to execute a function that would move a file from your own PC/laptop to the customers server drive.
This would enable a prx (for example) to be moved to a customer site and to be installed remotely without any intervention from the customer and without them opening an FTP gateway.
The function I suppose, would exist on the customers server and the file would reside on the suppliers equipment.
Or am I asking too much of CLIENT.SEND ?
If you can log on remotely to a customers site where Pro IV runtime (only) is installed (running on windows) is it possible to execute a function that would move a file from your own PC/laptop to the customers server drive.
This would enable a prx (for example) to be moved to a customer site and to be installed remotely without any intervention from the customer and without them opening an FTP gateway.
The function I suppose, would exist on the customers server and the file would reside on the suppliers equipment.
Or am I asking too much of CLIENT.SEND ?
Half of what he said meant something else, and the other half didn't mean anytthing at all
#12
Posted 29 April 2005 - 10:20 PM
Donald,
The answer is yes - conditionally. It depends on the connection to the client site. If you're connecting through PC Anywhere or RDP, then it will move the file to the local remote session. You'd then have to take another to retrieve the file from the that session to your local workstation.
If you are VPN'ed, directly telnet'ed or ssh'ed, you're good.
Regards,
Joseph
If you can log on remotely to a customers site where Pro IV runtime (only) is installed (running on windows) is it possible to execute a function that would move a file from your own PC/laptop to the customers server drive.
The answer is yes - conditionally. It depends on the connection to the client site. If you're connecting through PC Anywhere or RDP, then it will move the file to the local remote session. You'd then have to take another to retrieve the file from the that session to your local workstation.
If you are VPN'ed, directly telnet'ed or ssh'ed, you're good.
Regards,
Joseph
Reply to this topic

0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users