Since ftp can ftp to itself I really do not see any reason for dscopy
Using a scripts to put, get and mput (for wild card multiple files) what is
the benefit to continue to use dscopy other than for old classic systems (
which do not know what to do with bytestream type files anyway)
Here is our script for ftpput
I handles multiple retries with a mail message if retry limit reached.
If both systems are hp e3000s the file types and parameters are retained in
the new file.
The logon I do not think is any different of a load than the dscopy logon.

Why continue to use and have to maintain dscopy?

PARM
host_in,user_in,password_in,local_file_in,remote_file_in=!local_file_in,bina
ry="N"
COMMENT ********************************************************
COMMENT * This program uses FTP to send the local_file_in to   *
COMMENT *   the remote_file_in on the host_in FTP server.  The *
COMMENT *   user_in and password_in are used to log on to      *
COMMENT *   the remote FTP server.  Host_in can be any valid   *
COMMENT *   FTP address or host name that has an FTP server    *
COMMENT *   running. Default transfer is ascii. Set binary=Y   *
COMMENT *   to transfer using bin                              *
COMMENT ********************************************************
SETVAR put_cmd_file "PUTFILE"
COMMENT *************************************************
COMMENT * Purge old put command file                    *
COMMENT *************************************************
PURGE !put_cmd_file,TEMP > $null
COMMENT ***********************************
COMMENT * Build the FTP put command file. *
COMMENT ***********************************
ECHO open !host_in                      >  !put_cmd_file
ECHO user !user_in                      >> !put_cmd_file
ECHO !password_in                       >> !put_cmd_file
IF UPS(LFT("!binary",1)) = "Y"
  ECHO bin                              >> !put_cmd_file
ENDIF
ECHO hash                               >> !put_cmd_file
ECHO put !local_file_in !remote_file_in >> !put_cmd_file
ECHO quit                               >> !put_cmd_file
COMMENT pingnm !host_in
COMMENT ***************************************************
COMMENT * Run FTP taking input from the put command file. *
COMMENT ***************************************************
if "!hpjobtype" = "J" then
  limitup1jobq
endif
setvar ftplasterr 65535
setvar ftp_retries 0
while ftplasterr <> 0
  ruN FTP.ARPA.SYS ;LIB=S;xl='ftpxl.arpa.sys'; STDIN=!put_cmd_file
  showvar ftp@
  if ftplasterr <>0 then
    setvar ftp_retries ftp_retries +1
    if ftp_retries>5 then
      mail ,!sysmgremailadr, !sysbmgremailadr, 'ftpput failed',
failure.data.env
      setvar ftplasterr 0
    else
      pause 600
    endif
  endif
endwhile
if "!hpjobtype" = "J" then
  limitdn1jobq
endif
DELETEVAR put_cmd_file


-------------------------------------------------
Larry Simonsen                Phone: 801-489-2450
Flowserve Corporation     Fax: 801-491-1750
PO Box 2200                    http://www.Flowserve.com
Springville, UT 84663      e-mail: [log in to unmask]
-------------------------------------------------
All opinions expressed herein are my own and reflect, in no way, those of my
employer.

 -----Original Message-----
From:   Donna Garverick [mailto:[log in to unmask]]
Sent:   Thursday, December 28, 2000 9:50 AM
To:     [log in to unmask]
Subject:        Re: possible ER: bytestream support for DSCOPY?

Dave Darnell wrote:

> Since MPEX is not considered "cost effective" at our side, I use DSCOPY
for
> wildcarded local copy; don't even need to create a second session.

(a wonderful 'side-effect' of dscopy, imo :-)

> > From: Tracy Pierce [mailto:[log in to unmask]]
> >
> > I'm under the same impression, and it worries me a bit, as I quite
> > habitually use NS er DS ? for multiple sessions on multiple
> > boxes from one
> > terminal (ok, it's a Windoze PC, and this same scenario is
> > being used in 3
> > separate copies of the R1 client).

same here....

> > To what should I be accustoming myself instead?  (It's really
> > quite handy to
> > have 12 different sessions immediately available this way!)

i've got the impression -- but would love for hp to say something
encouraging
-- that while the ds software 'suite' isn't going away, it isn't being
enhanced
either.

and someone else privately asked....

> you mean that there will be no changes to dscopy in the future ?
> what about > 4 Gb files ?

(i don't know if dscopy will handle 4gb+ files (anyone from allegro know?).
i've really got my doubts that it would support ;comp *and* 4gb+ files....)

changes to the ds software?  i don't know about that either.  however (as
we've
all seen :-), if we (3000-l) can convince csy that continued enhancements to
the ds software (not just bug fixes) are important...well...we might see
flying
pigs :-)

i guess this is a good example of how some (a lot, all?) of the newer
(posix-based?) software has a 2nd edge to it's 'sword'.  i mean, if one were
to
call the rc asking about using dscopy to transmit a bytestream file (like
the
original thread asked), i can almost guarantee the response would be -- use
ftp.  it's a reasonably workaround.  ftp, however, doesn't have the
'elegance'
that dscopy has (imo).  wouldn't it be great if ftp knew how to examine your
file's characteristics and adjust itself -- just like dscopy! -- prior to do
the transfer?  ...and dscopy can do all this from the command line!  otoh,
it
would be just as great if dscopy could handle bytestream and hfs files too.
for csy, it boils down to money -- they can spend 'x' dollars to bring the
ds
software up-to-date or they can spend 'y' dollars to (continuously?) repair
ftp.  i suspect that 'y' is a smaller number than 'x'.        - d

--
Donna Garverick     Sr. System Programmer
925-210-6631        [log in to unmask]

"Unix _is_ user friendly.
It's just very selective about who its friends are.
And sometimes even best friends have fights."

>>>MY opinions, not Longs Drug Stores'<<<