Re: Using sftp from OpenVMS to Windows - How to avoid version numbers ?

From: [email]ami.kurtser@gmail.com[/email]
[color=blue]
> I use OpenVMS V7.3-2 on Alpha with TCPIP V5.4 ECO 6.[/color]

Same here.
[color=blue]
> [...]
> put *.* (or even mput *.*)
> It get the names 1.tmp;1 2.tmp;1 3.tmp;1 under Windows, that is: the
> version number gets to be
> part of the file name...
> Is there a way to copy all 3 files without the version number ?
> (I mean: without looping and sending them one by one...)[/color]

I don't see one. "put *.*;" (or "put *.*;0") even puts all versions
of a file:

sftp> put ab1.*;
AB1.TXT;2 | 452B | 0.4 kB/s | TOC: 00:00:01 | 100%
AB1.TXT;1 | 552B | 0.5 kB/s | TOC: 00:00:01 | 100%

I didn't gain anything by adding quotation marks, either. (I can only
imagine how this stuff was implemented.)

I assume that someone did a near-minimal-effort port of some UNIX
code to VMS, and this is the result. If you're paying for software
support, you could try complaining to HP.
[color=blue]
> The ssh installation in the Windows machine is Bitvise's WinSSHD 4.26[/color]

Works the same way with an HP-UX destination (or, probably,
anything).

------------------------------------------------------------------------

Steven M. Schweda sms@antinode-org
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547

On May 1, 5:57 pm, s...@antinode.org (Steven M. Schweda) wrote:[color=blue]
> From: ami.kurt...@gmail.com
>[color=green]
> > I use OpenVMS V7.3-2 on Alpha with TCPIP V5.4 ECO 6.[/color]
>
> Same here.
>[color=green]
> > [...]
> > put *.* (or even mput *.*)
> > It get the names 1.tmp;1 2.tmp;1 3.tmp;1 under Windows, that is: the
> > version number gets to be
> > part of the file name...
> > Is there a way to copy all 3 files without the version number ?
> > (I mean: without looping and sending them one by one...)[/color]
>
> I don't see one. "put *.*;" (or "put *.*;0") even puts all versions
> of a file:
>
> sftp> put ab1.*;
> AB1.TXT;2 | 452B | 0.4 kB/s | TOC: 00:00:01 | 100%
> AB1.TXT;1 | 552B | 0.5 kB/s | TOC: 00:00:01 | 100%
>
> I didn't gain anything by adding quotation marks, either. (I can only
> imagine how this stuff was implemented.)
>
> I assume that someone did a near-minimal-effort port of some UNIX
> code to VMS, and this is the result. If you're paying for software
> support, you could try complaining to HP.
>[color=green]
> > The ssh installation in the Windows machine is Bitvise's WinSSHD 4.26[/color]
>
> Works the same way with an HP-UX destination (or, probably,
> anything).
>
> ------------------------------------------------------------------------
>
> Steven M. Schweda sms@antinode-org
> 382 South Warwick Street (+1) 651-699-9818
> Saint Paul MN 55105-2547[/color]

Hello all,

Thanks for all your responses.

1. To zip is not an option for me.
2. The put command in sftp (e.g. put source target) refers to the
"source target" string as a list of files...
3. The logical that WWWeb suggested does not seem to change sftp's
behavior.

I'll be happy to get another solution.

Thanks again,
Ami

On 1 mei, 16:57, s...@antinode.org (Steven M. Schweda) wrote:[color=blue]
> From: ami.kurt...@gmail.com
>[color=green]
> > I use OpenVMS V7.3-2 on Alpha with TCPIP V5.4 ECO 6.[/color]
>
> Same here.
>[color=green]
> > [...]
> > put *.* (or even mput *.*)
> > It get the names 1.tmp;1 2.tmp;1 3.tmp;1 under Windows, that is: the
> > version number gets to be
> > part of the file name...
> > Is there a way to copy all 3 files without the version number ?
> > (I mean: without looping and sending them one by one...)[/color]
>
> I don't see one. "put *.*;" (or "put *.*;0") even puts all versions
> of a file:
>
> sftp> put ab1.*;
> AB1.TXT;2 | 452B | 0.4 kB/s | TOC: 00:00:01 | 100%
> AB1.TXT;1 | 552B | 0.5 kB/s | TOC: 00:00:01 | 100%
>
> I didn't gain anything by adding quotation marks, either. (I can only
> imagine how this stuff was implemented.)
>
> I assume that someone did a near-minimal-effort port of some UNIX
> code to VMS, and this is the result. If you're paying for software
> support, you could try complaining to HP.
>[color=green]
> > The ssh installation in the Windows machine is Bitvise's WinSSHD 4.26[/color]
>
> Works the same way with an HP-UX destination (or, probably,
> anything).
>
> ------------------------------------------------------------------------
>
> Steven M. Schweda sms@antinode-org
> 382 South Warwick Street (+1) 651-699-9818
> Saint Paul MN 55105-2547[/color]

Write a small DCL procedure that picks up every file using f$search,
and sftp
them one by one, either by starting sftp evrytime again or writing an
sftp batch
file and then starting sftp.

sftp was not written with any other oprating system in mind than Unix,
and as such
is more or less a pain on any other operating system. It's not
completely fair to blame
the people that ported it to VMS for the narrow mindedness of the
designers.

Jose Baars schrieb:
[color=blue]
> sftp was not written with any other oprating system in mind than Unix,[/color]

this doesn't come at a surprise, since TCP/IP and tools on top of it
are basically Unix technology.
[color=blue]
> and as such
> is more or less a pain on any other operating system. It's not
> completely fair to blame
> the people that ported it to VMS for the narrow mindedness of the
> designers.[/color]

You can't blame developers for their narrow mindedness when they never
saw a live VMS system sitting on their desktop.
It's just the consequence of the "... is a server OS only" mantra.

Michael Kraemer wrote:
[color=blue]
> You can't blame developers for their narrow mindedness when they never
> saw a live VMS system sitting on their desktop.
> It's just the consequence of the "... is a server OS only" mantra.[/color]

Anyone who ports software to VMS should be aware of the file system
differences, especially with regards to file versions. They did a fine
job with FTP with the logical TCPIP$FTP_IGNORE_VERSION, so how come they
didn't inplement the same code for SFTP ?

They forgot about intelligent file version handling with NFS, which
makes the NFS package barely usable on VMS.

You can't blame the original developpers. You can blame those who were
responsible for porting it to VMS because they should have provide the
proper handling of file system differences.

"Michael Kraemer" <M.Kraemer@gsi.de> wrote in message
news:fvp1gr$9no$02$1@news.t-online.com...[color=blue]
> Jose Baars schrieb:
>[color=green]
>> sftp was not written with any other oprating system in mind than Unix,[/color]
>
> this doesn't come at a surprise, since TCP/IP and tools on top of it
> are basically Unix technology.
>[color=green]
>> and as such
>> is more or less a pain on any other operating system. It's not
>> completely fair to blame
>> the people that ported it to VMS for the narrow mindedness of the
>> designers.[/color]
>
> You can't blame developers for their narrow mindedness when they never
> saw a live VMS system sitting on their desktop.
> It's just the consequence of the "... is a server OS only" mantra.
>[/color]

I brought up the need for a text transfer method in the SSH (SFTP)
discussion email list, and the narrow minded Unix people said that binary
was good enough and that they didn't want to burden the client with having
to know all of the different text storage methods. They didn't think that
the server could put it in a canonical format. The underlying protocol is a
file access protocol, so binary makes sense, but that's not how people want
to use it.

They decided upon a Unix like file specification as they felt that it was
easier to parse, rather than let the file specification be handled
completely in the context of the system using it. The user interface can
choose to present file specifications in their native format and convert
them to the protocol format.

In article <fvp1gr$9no$02$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes:[color=blue]
> Jose Baars schrieb:
>[color=green]
>> sftp was not written with any other oprating system in mind than Unix,[/color]
>
> this doesn't come at a surprise, since TCP/IP and tools on top of it
> are basically Unix technology.[/color]

ROTFLOL.

That's an old horse. TCP/IP and many off the RFCs were around for
a long time before Berkley put a copy on UNIX. TCP/IP was no more
meant to be UNIX specific than it was TOPS-10 specific. And it
was running on TOPS-10 and several other OS before it was put on
UNIX.

Some of the later RFC, like the one for NFS, are pretty much UNIX
specific, even though their inventors claimed otherwise.

Richard Whalen schrieb:
[color=blue]
>
> I brought up the need for a text transfer method in the SSH (SFTP)
> discussion email list, and the narrow minded Unix people said that binary
> was good enough and that they didn't want to burden the client with having
> to know all of the different text storage methods. They didn't think that
> the server could put it in a canonical format. The underlying protocol is a
> file access protocol, so binary makes sense, but that's not how people want
> to use it.
>
> They decided upon a Unix like file specification as they felt that it was
> easier to parse, rather than let the file specification be handled
> completely in the context of the system using it. The user interface can
> choose to present file specifications in their native format and convert
> them to the protocol format.
>[/color]

Well, I would consider myself a Unix guy as well,
but those arguments are lame excuses IMHO.
Last time I checked, sftp left a lot to be desired
when compared to its ftp predecessor,
text files are just one issue.
Back in the old ftp times, one could use the "nmap"
and "mget" subcommands to transfer version numbered files
from VMS to UNIX.
I can't see the "burden" for modern clients when compared
to the platforms available 20 years ago.
It's beyond me why these guys trashed a couple of useful ftp
features. The main enhancement of sftp over ftp
is the usage of encrypted passwords,
everything else could have been left unchanged.