| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4021.1 | Yes, but I suspect you won't like what you have to do | UNIFIX::HARRIS | Juggling has its ups and downs | Mon Apr 07 1997 08:51 | 43 |
| Anything is possible, but I suspect that they way to do it is not what
you desire.
What will work.
o Encode the file into a MacBinary file or a BinHex file and transfer
that. Then decode the file once it is on the Mac.
o ASCII text files should be able to transfer without any problems.
o place the file (or files) in a Stuffit archive and transfer that (or
us a Mac aware Zip utility).
o Create a Retrospect back up file and transfer that (or any other
backup utility that can backup files).
All of these except the ASCII file require a Mac to be involved before
the transfer and after the transfer, and even in the case of the ASCII
file you would have limitations on the attribute information.
What will most likely _NOT_ work.
o Trying to transfer a file with a data fork and a resource fork, plus
its type/creator and exact Mac name without encoding it.
Doing this without that aid of a Mac is not impossible, but it is very
difficult. I don't know of any utilities that will do this. Such a
utility would have to know how Windows-NT stores Mac data forks and
resource forks, plus where the Mac attribute information is stored and
how to extract it. It whould then have to encode this information for
transfer. Then on the OpenVMS side, you would have to have a utility
that understand the encoded format created on Windows-NT, be able to
decode it, then it has to know how the PATHWORKS for OpenVMS
(Macintosh) DECshare file server stores data forks, resource forks, and
Mac attribute information. That is a lot to deal with and I don't know
of anything that does.
----
Now if you can tell us the reason for this request, maybe we can figure
out a workable solution.
Bob Harris
|
| 4021.1 | Yes, but I suspect you won't like what you have to do | UNIFIX::HARRIS | Juggling has its ups and downs | Tue Apr 08 1997 00:39 | 44 |
| Anything is possible, but I suspect that the way to do it is not what
you desire.
What will work.
o Encode the file into a MacBinary file or a BinHex file and transfer
that. Then decode the file once it is accessable to a Mac on the
other side.
o ASCII text files should be able to transfer without any problems.
o place the file (or files) in a Stuffit archive and transfer that (or
use a Mac aware Zip utility).
o Create a Retrospect back up archive file and transfer that (or use
any other backup utility that can backup into an archive file).
All of these except the ASCII file require a Mac to be involved before
the transfer and after the transfer, and even in the case of the ASCII
file you would have limitations on the attribute information.
What will most likely _NOT_ work.
o Trying to transfer a file with a data fork and a resource fork, plus
its type/creator and exact Mac name without encoding it.
Doing this without that aid of a Mac is not impossible, but it is very
difficult. I don't know of any utilities that will do this. Such a
utility would have to know how Windows-NT stores Mac data forks and
resource forks, plus where the Mac attribute information is stored and
how to extract it. It whould then have to encode this information for
transfer. Then on the OpenVMS side, you would have to have a utility
that understand the encoded format created on Windows-NT, be able to
decode it, then it has to know how the PATHWORKS for OpenVMS
(Macintosh) DECshare file server stores data forks, resource forks, and
Mac attribute information. That is a lot to deal with and I don't know
of anything that does.
----
Now if you can tell us the reason for this request, maybe we can figure
out a workable solution.
Bob Harris
|
| 4021.2 | | GIDDAY::COOK | Matt Cook , CSC Sydney Australia | Tue Apr 08 1997 22:07 | 10 |
|
The reason the customer wants to do this is that they use the
NT server as a 'HOT' box , this is where some 3rd party apps
write the file too, for some reason it can't write directly to
the VMS machine but they want the users to access only the VMS box
Thanks,
Matt Cook.
|
| 4021.3 | Some ideas | UNIFIX::HARRIS | Juggling has its ups and downs | Wed Apr 09 1997 01:04 | 33 |
| If the application runs on a Mac, there should be no reason why it can
not write the a DECshare volume. Of course if it is an Wintel app,
that is understandable.
Anyway, the best suggestion I have is to create an AppleScript app to
look for the file or files and transfer it from the NT volume to the
DECshare volume via a Mac.
Another approach might be to use DECnet. It is possible to have a Mac
which has DECnet installed on it and also having both the NT volume and
the DECshare volume mounted, then tell the Mac to copy from volume a to
volume b via DECnet
$ COPY MAC::NT_Volume:[folder.folder.folder]file -
MAC::DECshare_Volume:[folder.folder.folder]file
It is a bit rude and crude, but it should work. The Mac in the middle
is the key.
Now if the information to be transferred is data only, then it may be
possible to use something like the PATHWORKS for OpenVMS (LANMAN)
product to transfer the file.
And if it is the same file each time, then if you have an existing file
in the DECshare volume with the correct type/creator and Mac name, then
it may be possible to overwrite the data fork with information obtained
from the NT system. How you get it from the NT system is a different
problem that I don't think should be a Mac file server's problem.
If any of these ideas sound workable, let us know and we'll see if we
can work out the details.
Bob Harris
|
| 4021.4 | | GIDDAY::COOK | Matt Cook , CSC Sydney Australia | Sun Apr 27 1997 21:15 | 10 |
|
Bob,
Sorry for taking so long to get back to you but the customer
went on leave and I am still waiting to hear back from him, as soon
as I hear from him I will let you know.
Thanks,
Matt
|