Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

FTP'ing source members

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • FTP'ing source members

    Suppose I have a source physical file called SRCA, in library LIBA, on one system. I want to copy all the members to source PF SRCB, in library LIBB, on another system. Is there a way to copy all the members with one FTP command, and without having to list all the members (i.e., in an MGET or MPUT)? TIA.

  • #2
    FTP'ing source members

    Ted, Would you prefer to not do it through Save Files? Bill

    Comment


    • #3
      FTP'ing source members

      Ted - I don't suppose you'd settle for SAVLIB or SAVOBJ to a *SAVF and FTPing the *SAVF, wouldja? JTTH, Steve

      Comment


      • #4
        FTP'ing source members

        I've FTP'd save files before. That works very well, with one exception. I've had to change the authority on all of the object before I SAVF'd them. I found that if I didn't, when I restored them on the receiving system I didn't have authority on some of the objects.

        Comment


        • #5
          FTP'ing source members

          Thanks, guys, but I already know how to FTP a save file. But doing so requires that I create a save file, FTP the save file, then RSTOBJ from the save file. That's 3 steps, and I was wondering if I could eliminate steps 1 and 3.

          Comment


          • #6
            FTP'ing source members

            I have a silly question. We are talking about 2 AS/400's right? Can you passthrough to the other AS/400? If so why don't you just set up a DDM file to the other source file and use the CPYSRCF command?

            Comment


            • #7
              FTP'ing source members

              why don't you just set up a DDM file to the other source file and use the CPYSRCF command? Good idea! I tried it but got CPF9190, reason code 17.

              Comment


              • #8
                FTP'ing source members

                That is a security issue. If you are not the administrator talk to the administrator about the security set up. If you are try using QSECOFR

                Comment


                • #9
                  FTP'ing source members

                  Ted, This may be a less than intelligent question: Is there any reason why DDM, or ICF can't be used? Dave

                  Comment


                  • #10
                    FTP'ing source members

                    The message says something about passwords and encryption.

                    Comment


                    • #11
                      FTP'ing source members

                      Ted, "That's 3 steps, and I was wondering if I could eliminate steps 1 and 3." What you want to use is the SAVRSTOBJ command (or one of the other SAVRST* commands), which are part of the optional component ObjectConnect (OS/400 option 22). Do not confuse this with OptiConnect, which is different. At one time ObjectConnect was a chargeable option but as I understand it, not very many people bought it so they made it a no-charge option. However, what I can't point you to is the documentation on how to set up the APPN connection between the systems. RTFM Doug PS - You want to use a SAVF or the SAVRST* commands in order to preserve all the other stuff not sent with MPUT/MGET such as member text, source dates and sequence numbers, etc.

                      Comment


                      • #12
                        FTP'ing source members

                        Ted, "I already know how to FTP a save file" Then you'll really like the SAVRSTxxx commands. It gives you all the power and options of the regular SAVxxx commands, but doesn't create a SAVF as an intermediate step. You'd run it just like the first SAVxxx step in the three step process, but it does the communication and restore under the covers. As a follow-up to my other post, I found the ObjectConnect setup instructions are in the Backup and Recovery manual. I just set it up as a trial between two systems, and it is *very* slick. One caveat: if one system (but not both) is pre-V4R3, you need to check apar SA69471 and II1236 for a PTF which varies by release. Actually, just order and apply the PTF from this list:
                         V3R2M0 SF45273 V3R7M0 SF45274 V4R1M0 SF45132 V4R1M4 SF45320 V4R2M0 SF45321
                        If you don't have 57xx-SS1 option 22 already installed, there may be other PTF's on a cume tape. Since I already had ObjectConnect installed, all I had to do was install the above PTF to get it to work. Doug

                        Comment


                        • #13
                          FTP'ing source members

                          Thanks for the info, Doug, but it appears that the SAVRSTxxx commands work only under SNA. There's no way to put an IP address in for the remote location name.

                          Comment


                          • #14
                            FTP'ing source members

                            Ted, "Thanks for the info, Doug, but it appears that the SAVRSTxxx commands work only under SNA. There's no way to put an IP address in for the remote location name." I'm using a token-ring connection running TCP/IP. I didn't use the IP address of the other machine, I used the name I had in my local hosts table (CFGTCP menu option 10). This also matches the system name of the other machine, but what is probably more important is that it matches that machine's "local control point name" in the network attributes, eg CHGNETA ... LCLCPNAME(xxx) ... Try it. SAVRSTxxx works great. Doug

                            Comment


                            • #15
                              FTP'ing source members

                              Doug, the SAVRSTOBJ command fails because it can't find a route to the remote system. I ran DSPAPPNINF & it does not show any connection to the other machine. Shouldn't it?

                              Comment

                              Working...
                              X