Midrange News for the IBM i Community


Posted by: CurtisB
Making RCVNETF Work
has no ratings.
Published: 10 Feb 2012
Revised: 23 Jan 2013 - 1783 days ago
Last viewed on: 11 Dec 2017 (3828 views) 

Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.

Making RCVNETF Work Published by: CurtisB on 10 Feb 2012 view comments(6)

I am seriously looking at replacing the FTPIng of save files with SNADS. I am working on automating the receive process. The files get sent very nicely, and I can receive them without a problem, except:

 

When I go intoWRKNETF on the remote IBM i, and prompt appropriately, I get the following screen:

 

                          Receive Network File (RCVNETF)                 

                                                                        

 Type choices, press Enter.                                             

                                                                        

 From file  . . . . . . . . . . . > 'QRPGSRC'     Character value       

 To file  . . . . . . . . . . . .   *FROMFILE     Name, *FROMFILE       

   Library  . . . . . . . . . . .     CURTLIB     Name, *LIBL, *CURLIB  

 Member to be received  . . . . . > 'AM0719'      Character value, *ONLY

 To member  . . . . . . . . . . .   *FROMMBR      Name, *FROMMBR, *FIRST                   

 

When I enter the above screen, I receive the source member (or save file when I am receiving that) appropriately to the proper destination.

 

When I enter the following command from the command line (or generate it in a program I am writing to automate the process), I get an error:

 

                                                                                

 Selection or command                                                           

 ===> RCVNETF FROMFILE(QRPGSRC) TOFILE(CURTLIB/QRPGSRC) FROMMBR(AM0719) TOMBR(*FROMMBR)                                                                         

 F3=Exit   F4=Prompt   F9=Retrieve   F12=Cancel   F13=Information Assistant     

 F23=Set initial menu                                                           

 No files compare to the specified selection.             

 

This is CPF0860:

                 

                         Additional Message Information                        

                                                                               

 Message ID . . . . . . :   CPF8060       Severity . . . . . . . :   30        

 Message type . . . . . :   Diagnostic                                         

 Date sent  . . . . . . :   02/09/12      Time sent  . . . . . . :   15:28:37  

                                                                               

 Message . . . . :   No files compare to the specified selection.              

 Cause . . . . . :   There were no network files that compare to the file,     

   member, and number values you specified.                                    

 Recovery  . . . :   Use the Work with Network File (WRKNETF) command to find  

   out what files exist.                                                       

     Specify a file using one of the following:                                

     --The FROMFILE parameter on the Receive Network File (RCVNETF) command.   

     --The FILE parameter on the RCVNETF command.                              

     --The FILE parameter on the Delete Network File (DLTNETF) command.        

     Use the member (MBR) parameter and the number (NBR) parameter on the      

   DLTNETF command to specify one or more file members that exist in the       

   network files.  Then, try the request again.                                

                                                                         Bottom

 Press Enter to continue.     

 

Entering the file number does not make any difference; putting the file name in quotes, as in the prompted screen, doesn't either. Neither does logging on as security officer.

 

Any ideas why the command line version does not work, but the prompted one does? 

 

Thanks for your help.                                                      

Return to midrangenews.com home page.
Sort Ascend | Descend

COMMENTS

(Sign in to Post a Comment)
Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Making RCVNETF Work
Posted: 5 years 10 months 1 days 10 hours 40 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 by: CurtisB
Premium member *
Comment on: Making RCVNETF Work
Posted: 5 years 10 months 1 days 8 hours 20 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 by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Making RCVNETF Work
Posted: 5 years 10 months 1 hours 2 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 by: Paulster
Premium member *
Sweden and The Netherlands
Comment on: Making RCVNETF Work
Posted: 5 years 9 months 28 days 20 hours 48 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 by: DaleB
Premium member *
Reading, PA
Comment on: Making RCVNETF Work
Posted: 5 years 9 months 28 days 13 hours 27 minutes ago
Edited: Tue, 14 Feb, 2012 at 07:24:25 (2127 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 by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Making RCVNETF Work
Posted: 5 years 7 months 3 days 16 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.