Mike

You are still ambiguous!

A diagram or two will/would help.

Let me suggest the following:

desktop PC       controller                                3745/NCP       
VTAM/CICS
---------- <---> ---------- <----------------------------> -------- <---> -
--------
            LAN              SDLC or LAN via DLSw over IP

to be replaced by something like

desktop PC       PC with Windows CS      OSA-VTAM/CICS
---------- <---> ------------------ <--> -------------
            LAN                      IP

If this is about correct - and I'd be obliged if you could fill in the 
details[1] - 
then I could suggest a straightforward SNA solution - incorporating Enterprise 
Extender (EE), of course.

Since you want no impact on CICS or the desktop PC, you can be SNA end to 
end. From VTAM to Windows CS, you run an EE link via the Communications 
Server (CS) IP component and the Windows IP logic of course. From Windows 
CS to the desktop PC, you run an 802.2 LAN link.

If the software in the desktop PC support APPN/HPR, the Rapid Transport 
Protocol (RTP) logical link can extend from VTAM to the software in the 
desktop PC - whatever it is.

There will be no need to change LU names and CICS will be unaware of the 
changes you have wrought. Similarly, the application program in the desktop 
PC will be unchanged.

There is another set of new protocols with which you are going to have to get 
familiar. In order to support SSCP-dependent LUs - which I assume applies to 
your LU type 0 LUs - over a purely type 2.1 node to type 2.1 node link where 
the "distributed" type 2.1 node does not/cannot incorporate type 2.0 node 
capability[2] such as is required for EE, you are going to need to become 
familiar with "Dependent LU Server" (DLUS) and "Dependent LU Requester" 
(DLUR). Your Windows CS will need to be the DLUR node supporting external 
nodes.

Now I'm not sure that Windows CS can necessarily do that so it may be 
necessary to review what platforms could support an "external" DLUR node. On 
the other hand, the "LAN environment" may have so far departed from the 
traditional SNA structure that all SSCP-dependent LUs are internal to the DLUR 
node.

However, I won't spend time checking on these topics[3] until I/we are clearer 
over your existing and putative configurations.

Chris Mason

[1] Since you supplied the initials LANDP, I took a look at what that was. An 
initial guess is that it supports moving a 4700 to a PC. I expect the CICS 
transactions are expected not to be able to detect that the 4700 has been 
replaced by a PC running LANDP. Of course I could be wrong but it's that sort 
of orientation that is needed.

[2] The traditional peripheral nodes with which you are probably familiar from 
your experience with NCP.

[3] Time wouldn't be wasted but I'm a bit pushed for time to do that sort of 
research right now.

On Mon, 13 Jul 2009 09:01:41 -0500, Ward, Mike S <[email protected]> 
wrote:

>Chris, sorry to be so ambiguous. What I'm trying to do is get rid of
>some old IBM equipment at remote locations. It is being replaced by
>Windows Communications Server and LANDP. The reason I ask about SNA
>Gateway, etc.. is that in configuring the Windows Comm Server the Wizard
>has a dropdown window that has various configurations that you can
>choose from. I.E.
>
>SNA GATEWAY
>APPN Network Node
>DLUR/DLUS Support for Local LU's
>DLUR/DLUS Support for Downstream LU's
>AnyNet SNA over TCP/IP Gateway
>AnyNet Sockets over SNA
>SNA API Clients Running APPC Applications
>SNA API Clients Running 3270 or other LUA Applications
>3270/LUA Applications
>Focal Point
>AS/400 Shared Folders
>
>Some of these I have heard about, others I didn't even know they
>existed. Either way once windows comm server is set up and talking to
>the mainframe the  desktops at the remote location will talk to the Comm
>server and send info back and forth to mainframe via the comm Server. In
>order to minimize the impact of installation, I have been designated to
>set up communications to this windows server and make it communicate
>with the mainframe CICS system. The LU names currently in use must not
>change. In other words. If you had a 3174 remote with LU A,B,C you would
>need to set up Windows Comm Server in some fashion that would allow it
>to have LU A,B,C connect to CICS just like the 3174 remote did. I am
>confused because I have never had to set up SNA communications with a
>software server. It's always been SNA to another VTAM using a 3745, 3705
>and NCP, or to a remote 32xx device. I think the HPR APPN node is the
>way to go since it offers the most current mode of communications, but I
>may be all wet. That's why I'm asking so many questions.
>
>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:[email protected]] On
>Behalf Of Chris Mason
>Sent: Wednesday, July 08, 2009 8:03 PM
>To: [email protected]
>Subject: Re: Anynet
>
>Mike
>
>I was composing this response before your posts appeared on the IBMTCP-L
>
>list.
>
>> ... is anynet incorporated into z/os vtam like enterprise extender is?
>
>
>Two of the AnyNet components, "SNA over IP"[1] and "Sockets over SNA",
>*used* to be "incorporated" into VTAM (the Communications Server SNA
>component) prior to V1R8 - and unchanged since V1R2 - in the sense that
>you
>did not have to obtain a separate product in order to acquire the
>function.[2]
>
>Note that simply saying AnyNet is ambiguous. The fact that you are also
>interested in Enterprise Extender indicates that it is AnyNet SNA over
>IP in
>which you are interested. The other AnyNet implementation which used to
>be
>supported by VTAM is AnyNet Sockets over SNA which was withdrawn at the
>same time as AnyNet SNA over IP and for which there is - a pause for a
>tear -
>no replacement.
>
>AnyNet products are implementations of the Multiprotocol Transport
>Networking (MPTN) principle and there used to be quite a number where
>one
>protocol suite switched to another protocol suite in principle at the
>level of
>the transport layer of the ISO OSI model. Note that MPTN actually
>incorporates some RFCs.
>
>I suppose AnyNet SNA over IP is "just like enterprise extender" since
>the
>VBUILD TYPE=TCP is available in the same way as the VBUILD TYPE=XCA
>followed by PORT MEDIUM=HPRIP can be coded in a VTAM major node
>definition.
>
>There is a difference in that the AnyNet components were always
>described in
>separate manuals. See
>
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/F1A1BK61
>
>You seem to imply that z/OS V1R7 is your current level. This being so,
>you
>could have answered your first question from your installed VTAM.
>
>Like Pat, I am somewhat puzzled by your terminology. You seem to have
>the
>idea that the distributed platforms are tied to z/OS in some manner
>other than
>that they both implement SNA. It is as if SNA were somehow a feature of
>z/OS that gets exported to distributed platforms in some way. I hope the
>
>IBM "suits'" insistence back in about 1995 that "if it's SNA, whatever
>the
>platform, it has to be a member of the 'Communications Server' family"
>hasn't
>confused you appreciation of the technical truth. The "Communications
>Server" family label makes some sort of technical sense for all the
>products so
>labeled ***with the very specific exception of the z/OS one*** because
>the
>same software house was and is still I believe responsible for them. See
>
>http://www-01.ibm.com/software/network/commserver/library/
>
>and try to ignore the "Communications Server for zOS and CS390" entry!
>
>You also rather mistakenly emphasise the word "gateway". I expect
>by "gateway" you refer to the optional and, to my mind, generally
>unnecessary
>technique of having either LU type 2 (3270) or LU type 6.2 (APPC) data
>streams passed over a typically local IP network to the workstations
>rather
>than extending SNA to the workstations and using an APN Network Node
>server or a Branch Extender Node[3]. Why mix your protocols when you
>don't
>have to?
>
>I guess this is all related to the other thread to which I have given
>you some
>responses. Much as Timothy Sipples suggested, you should just say what
>you
>***really*** want to do - without "prejudice".
>
>Chris Mason
>
>[1] I always drop the "TCP" because, in fact, "AnyNet over IP" also uses
>UDP
>port 397 (by default).
>
>[2] FWIW I even remember that the CM/2 support for the two AnyNet
>components was shipped with VTAM when the function first became
>available.
>
>[3] Your only option when you try to build an SNA network on
>"one-size-fits-
>all" Cisco SNASw.
>
>On Tue, 7 Jul 2009 16:03:10 -0500, Ward, Mike S <[email protected]>
>wrote:
>
>>Hello all, is anynet incorporated into z/os vtam like enterprise
>>extender is? Or is there any way to communicate with an SNA
>>Gateway(Communications Server) from z/os 1.7 using the enterprise
>>extender functions?
>>
>>Thanks. 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to