The issue was the record count:
ftp> get ./STDHAL.1.1 ./STDHAL.1.1;CODE=STORE;REC=-256,,F,BINARY
needs to be:
ftp> get ./STDHAL.1.1 ./STDHAL.1.1;CODE=STORE;REC=-256,,F,BINARY;DISC=16776959
And the transfer completes. Thanks to Doug Smith of Stromasys.
On Thu, December 15, 2022 12:35, Gavin Scott wrote:
> Have you tried pushing the files from the Unix side, rather
> than pulling them from the 3000?
>
> Gavin
>
FTPSRVR does not appear to respond. The JINETD job contains this:
Tue,Nov 29,2022,19:36:00: ftp(tcp nowait MANAGER.SYS port: 21)
Tue,Nov 29,2022,19:36:00: ftp/tcp: Added service, server /SYS/ARPA/FTPSRVR
Tue,Nov 29,2022,19:36:00: Configuration complete
Thu,Dec 15,2022,18:02:29: Received call for: ftp tcp
Thu,Dec 15,2022,18:04:11: Received call for: ftp tcp
Thu,Dec 15,2022,18:04:12: inetd: fork succeeded
Thu,Dec 15,2022,18:04:19: Received call for: ftp tcp
Thu,Dec 15,2022,18:04:19: inetd: fork succeeded
. . .
But this is what I see on the client side:
:ftp 192.168.216.102
File Transfer Protocol [A0012H14] (C) Hewlett-Packard Co. 2002 [PASSIVE
SUPPORT] Connection Failure
Cannot connect to host: (192.168.216.102) (FTPERR 9)
and from a Unix box:
# ftp 192.168.216.102
Connected to 192.168.216.102.
421 Service not available, remote server has closed connection.
I checked SERVICES.NET.SYS, PROTOCOL.NET.SYS, and INETDCNF.NET.SYS. Everything
tallies with the FTP-MANAGER manual.
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
Unencrypted messages have no legal claim to privacy
Do NOT open attachments nor follow links sent by e-Mail
James B. Byrne mailto:[log in to unmask]
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
