Posted: 12 years 2 months 17 days 3 hours 7 minutes ago
Just a hunch, but you have the file and member names Quoted on the prompter, but not on the Command line version. Perhaps case-sensitivity plays a role here.
Try quoting the file and member names (making them all upper case of course) on the command line version.
Posted: 12 years 2 months 17 days 47 minutes ago
I had tried doing the quoting before, and that didn't seem to make a difference.
As it turned out, in the end I found that when doing it as a command, I could only receive it as the person to whom the file was sent; even QSECOFR couldn't receive someone else's file in that fashion from the command line.
What I had to do was send the file to a specified user; then I had to submit the RCVNETF to batch and define the USER in the SBMJOB command as the user to which I sent the file.
Bob, thanks for taking a shot at it.
Posted: 12 years 2 months 15 days 17 hours 30 minutes ago
I created a little SNDOBJ CL command (we don't have savrstobj ability on our systems) that does a save then FTP's the save file and issues the restore on the other end. I use it to distribute programs to our remote locations. I had been FTP'ing source, then telnet'ing over and compiling the source, but then thought if I could simply restore the *PGM object itself, why not do that.
Posted: 12 years 2 months 13 days 13 hours 15 minutes ago
Hi Curtis,
Isn't SNADS going the opposite way and SNADS itself in the process of being replaced by more current techniques?
Anyway, as it seems to handle about getting RPG (and possibly other types as well) source members across to other IBM i servers within the network, you might wanna have a look at DDM files. A simple CPYF to the DDM on the source system and the source is available on the target side.
Good luck,
Paulster
Posted: 12 years 2 months 13 days 5 hours 54 minutes ago
Edited: Tue, 14 Feb, 2012 at 07:24:25 (4455 days ago)
I can see the attraction of SNADS over FTP.
FTP is a very simple protocol, with no recovery capabilities, and pretty much everything you do is manual. You might create a !--script-- and do the overrides, so that you can run it from a program, but it's still really an interactive process. How many of you actually have a program that processes the OUTPUT file, making sure the !--script-- was successful? Or, better yet, have a custom FTP client that processes the protocol directly, so that the program can handle the errors on its own?
SNADS queues have built-in error recovery, retries, access to an address book, and so on. The main limitation of SNADS is that it runs on SNA. You can get around that with HPR/IP or the older AnyNet, but you need to have access to both ends of the connection to be able to do that.
It would be great if we had a *IP type queue in SNADS (hint, hint, IBM). Or a true batch version of FTP, something that returned monitorable messages instead of, or in addition to, OUTPUT.
Posted: 11 years 11 months 16 days 16 hours 44 minutes ago
Curtis, I've discovered that using CPYSRCF for Source file members works great.
To use it, first create a DDM file (I create mine in QTEMP) and point it at the source file on the remote system. Specify the remote system name, and then use CPYSRCF to copy any or all members from that remote file to your system. I assume it will work the other direction as well.
The great things is, all source file attributes which CPYSRCF preserves locally are also preserved using this technique.
I'm about to write an article on wrapping these two steps up into a CL Command, but you can certainly figure out the details from here.