Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

FTP'ing source members

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

  • #16
    FTP'ing source members

    Ted, "it can't find a route to the remote system" Do you have the name defined in your TCP local hosts table (menu CFGTCP option 10? I know you said you could FTP between the systems, but were you using the IP address or a name for the other system? I won't have real timely access to email for the next few days -- I just traveled to a client site to do a V3R2 to V4R5 (CISC to RISC) side-by-side upgrade. But once all the initial roadmap stuff is done I plan on using SAVRSTxxx to refresh the data file contents on the new machine during the testing phase. So I'll have a chance to set this up again on a new system within a day or two, and I'll pay attention to what I need to make it work. But start by checking the hosts table - that may do it for you. Doug

    Comment


    • #17
      FTP'ing source members

      Doug asked: Do you have the name defined in your TCP local hosts table (menu CFGTCP option 10?) Yes, & it has the correct IP address. Thanks for trying to help me, Doug. I'll keep working on it as I can. I hope the upgrade goes smoothly. Ted

      Comment


      • #18
        FTP'ing source members

        Ted, "Thanks for trying to help me, Doug. I'll keep working on it as I can." Sorry to take so long to reply again -- I've been out of town. But one of the things I did while at the site was to setup ObjectConnect between their old system and the new replacement system. (I was doing a side-by-side RISC migration.) Since I had both systems linked via TCP/IP on a LAN, it made for a *very* easy way to transfer objects between systems to refresh test data, etc. Here are the steps I needed to do to make it work over a TCP/IP link. It was a little more complicated than I thought when I first set up a trial on two other systems, but it turns out that was because AnyNet was already configured on those systems. Anyway, here is what I did:
          [*]Install 57xx-SS1 option 22 (ObjectConnect) -- a no-charge option[*]If one system is pre-V4R3 and the other V4R3 or later, install PTF: V3R2M0 SF45273 V3R7M0 SF45274 V4R1M0 SF45132 V4R1M4 SF45320 V4R2M0 SF45321[*]Check QCMN subsystem communication entries for mode QSOCCT, which should be there if ObjectConnect is installed. Use WRKSBSD QCMN to display the communication entries. If QSOCCT is not listed, use ADDCMNE SBSD(QCMN) DEV(*ALL) DFTUSR(QUSER) MODE(QSOCCT)[*]Enable AnyNet support via CHGNETA ALWANYNET(*YES)[*]Use DSPNETA to find your network ID, which will more than likely be APPN. If it is not APPN, substitute your name for APPN in the remaining instructions.[*]Add TCP/IP host table entries (ie menu CFGTCP option 10) for the other system(s) you will communicate with using SAVRSTxxx using the format name.APPN.SNA.IBM.COM where name is the remote location name you'll use on the SAVRSTxxx commands. EG, on the DALLAS system you'd add the name CHICAGO.APPN.SNA.IBM.COM with its IP address, and on the CHICAGO system you'd add DALLAS.APPN.SNA.IBM.COM to the IP address for its system. (If DSPNETA shows your network ID as other than APPN, substitute it instead.)[*]Create one APPC controller on each system for use by AnyNet. The controller can be named the same as the system name (my recommendation), but you also need to make up another "control point" name for each system. The names just have to be unique across all systems (and also different than the system name). I arbitrarily used CTLPNT01 and CTLPNT02. So on the DALLAS system you'd use CRTCTLAPPC CTLD(DALLAS) LINKTYPE(*ANYNW) ONLINE(*YES) RMTNETID(APPN) RMTCPNAME(CTLPNT01) and on the CHICAGO system you'd use CRTCTLAPPC CTLD(CHICAGO) LINKTYPE(ANYNW) ONLINE(*YES) RMTNETID(APPN) RMTCPNAME(CTLPNT02)[*]On each system, add configuration list entries for each remote system you will communicate with. Use CHGCFGL *APPNRMT to display the table of list entries. You'll have several columns to fill in. In the first, Remote Location, put the name of the *other* system. The second, Remote Network ID, is typically APPN (or other name from DSPNETA). The third column, Local Location, should be the name of the system you are working on. The fourth column, Remote Control Point, is where you add the arbitrary names from the APPC controller descriptions above. Use the cp name which matches the *local* system. EG, in my example above you'd use DALLAS in column 3 and CTLPNT01 in column 4 for all list entries at DALLAS, and CHICAGO in column 3 and CTLPNT02 in column 4 for all list entries at CHICAGO. The fifth column, Control Point Net ID, is typically APPN (again assuming DSPNETA uses APPN as the network ID). Ignore the remaining columns. To add additional cities, add more table entries but note that only the f irst column changes (the name of the remote system). All other columns stay the same on a given system.[*]Vary the APPC controller on at each system. If you used ONLINE(*YES) this will be automatic in future IPL's, but necessary the first time prior to an IPL. VRYCFG name *DEV *ON where name matches the APPC controller name created above (I use the system name).[*]On each system, start mode QSOCCT used by ObjectConnect by issuing STRMOD RMTLOCNAME(targetname) MODE(QSOCCT) LCLLOCNAME(*NETATR) RMTNETID(*NETATR)[/list]Now all the SAVRST* commands should work. Note that all but the last step will survive an IPL, assuming you created the controller with ONLINE(*YES). I added the STRMOD commands to my startup program where I also STRTCP. "I hope the upgrade goes smoothly." It went like clockwork by following the roadmap. It was very smooth, but I had all my ducks in a row before getting there (with apologies for the fowl language ). It is really fun to watch batch jobs litteraly go from hours to minutes.

        Comment

        Working...
        X