| re: ZPOVC::HINSIONGTAN
It has been the same problem using VMS to copy from UNIX to VMS.
Once you start quoting anything on VMS, the destination path
should be made explicit. When I had to do much copying, I would
build up a list of individual files in "source destination" format
and use spool copy on VMS.
/Bill
|
| Just FYI, FAL on PATHWORKS 32 will accept VMS directory syntax. This is old
DOS FAL functionality, and customers didn't want to lose it in PW32, so we
implemented optional VMS directory syntax in the new PW32 FAL. This allows
copies with no quotes (so you don't have to list the file name on both source
and destination) and wildcard copies:
For these commands ...
.0> $ copy nthost"account password"::"test1.txt" test1.txt/log
.0> $ copy nthost"account password"::"test*.txt" *.*/log or
.0> $ copy nthost"account password"::test*.txt *.*/log
... you can do this:
$ copy ntv40"account password"::test1.txt */log
$ copy ntv40"account password"::test*.txt */log
Plus, you can add a directory spec. If your files are in \msdev\projects\foo,
$ copy ntv40"account password"::[msdev.projects.foo]*.c */log
Directories containing embedded spaces are a problem on the VMS command
line. VMS will not like this...
$ dir ntv40"account password"::[program files]
If you quote the directory, the DIR command works, but you can't to the
wildcard copies with quoted directory.
Also, if there's a dot in your directory spec, forget it. This works...
$ dir ntv40"account password"::"c:\test.alpha\files"
... but there's no way to specify the directory so the translation works.
This will fail, because there's no c:\test\alpha\files:
$ dir ntv40"account password"::c:[test.alpha.files]
-Steve
|
| > Just FYI, FAL on PATHWORKS 32 will accept VMS directory syntax. This is old
> DOS FAL functionality, and customers didn't want to lose it in PW32, so we
> implemented optional VMS directory syntax in the new PW32 FAL.
Also FYI, the PWNT FAL (32-bit version, the one you get by default
on V4.1B) also has latent support for accepting VMS directory
syntax (latent support I had put into ULTRIX FAL, which then became
DEC OSF/1 FAL, and then I ported to PWNT). Except you have to
turn it on. I forget how to turn it on however :-)
Also, at least in V4.1A, we also shipped a FAL16.EXE (ie. the DOS
FAL), I don't remember if we still did in V4.1B (if we didn't, you
can just grab it from a V4.1A kit, or from a PW for DOS system)
and use that, *after* making sure to disable the 32-bit FAL:
ncp define object fal number 0
and rebooting should do it. Do note however that FAL16, being
a 16-bit app, does not understand anything but 8.3 names (though
if you know how NT mungs non-8.3 names into 8.3 names you may
still be able to fetch those files, though VMS won't like the ~'s
in those names). FAL16.EXE requires that you be logged in, and
you run it from a DOS Command prompt window, and there is no
security checking.
|
| Also FWIW, the real problem with not being able to do wildcarded
copies to pull files off a non-VMS system using a foreign filespec
(ala the quotes around the name) from a VMS system, is really a
VMS problem. Even ULTRIX FAL 10+ years ago returned what is called
DAP 3-part NAME messages that has the filenames broken down into
parts usable by even VMS (ie. the base filename, which is all that's
needed in these cases for generating an output filespec in a pull
operation).
But VMS never had a goal of more seemless integration with non-VMS
systems, never mind getting them to fix bugs in their code that
is only seen when talking to non-VMS systems (to this day their
mail-11 server still identifies it's OS type as the same as
the client, so it was even hard to implement workarounds based
on the remote sides OS type in some cases :-(().
|