Communications Server for Data Center Deployment

The answer is Yes, it can provide an SSCP component, but under specific conditions that are more legacy based than the modern SNA over IP connectivity. 

The LUA API, documented in the LUA Programmers manual (https://www.ibm.com/support/pages/communications-server-data-center-deployment-linux-library) has a "Primary LUA" interface that will drive a SSCP session, like VTAM. The restriction is that this is for non-APPN (no DLUR/DLUS connections). So, currently, it is for legacy SNA over Ethernet (LLC2, IEEE 802.3 SNA) connections. The purpose is mostly for providing test capabilities, or a pseudo-mainframe presence on a network. Using this feature, one connects a downstream SNA device over Ethernet to the MAC address of the Comm. Server who has a port definition for the interface that will manage connections as a Primary LU (SSCP). The level of SSCP (level 4 or 5 ) is dependent on the code that drives the LUA interface. 

Jeff,

Thanks for your response. 

So, there is a glimmer of hope here.  Let me ask another question.

If we have CICS Transaction Gateway and CSDCD running on a Linux server with no VTAM SSCP in the mix, will we be able to establish LU6.2 APPC connections between CICS Transaction Gateway and remote CICS regions running under z/OS in other SNA networks?  Will CSDCD on its own be able to establish these cross network APPC connections with these remote CICS regions?    

Yes, the Communications Server for Data Center Deployment will connect LU6.2 sessions for CICS between a Transaction Gateway and the TX Series server. This is one of the more popular applications that the CSDCD is used for. CSDCD can support both the dependent LU (SSCP type) and independent LU (LU6.2 type) sessions for CICS. 

The CICS Transaction gateway can be on a server or a container environment and the CSDCD has support for both types of environments. It will provide the LU6.2 connectivity between the gateway and the server. 

Jeff,

I want to be very careful that I understand you.  Are you saying CSDCD can do this across SNA network boundaries? Between the local SNA network controlled by CSDCD with no help from a VTAM SSCP, and a completely different remote SNA network.  I also thought that in order to cross SNA network boundaries that a boundary NCP had to be involved. I thought I read where CSDCD can also host an NCP, can this be a network boundary node NCP?

Thanks,

Wayne

The deeper into your question we get, the more specific the answer is going to need to be. 

The CSDCD can act as a Network Node, in which case it can only support one SNA NetID and not cross a network boundary to connect (directly) to another SNA Network ID. 

The CSDCD can act as an End Node and connect to another NetID (across a boundary) and act as an end point for a LU6.2 connection. However, it can only be an end point in on SNA Network at a time. It cannot be an end point to 2 different SNA Networks at the same time. 

The CSDCD can act as a Branch Extender that provides downstream APPN End Nodes connectivity to upstream APPN nodes of a different Network ID. It looks as an End Node to the upstream Network Node, and as a Network Node to the downstream End Nodes. This provides connectivity using a reduces network flow because it does not exchange topology with the connecting Network Node. This does not provide full SNA access to 2 different networks. It can only provide SNA access to one SNA network at a time. So, it cannot do the cross border capabilities of VTAM. 

You are correct that as a Network Node, the CSDCD cannot connect 2 different SNA networks. It can only connect to other Network Nodes that are in the same SNA NetID. The capability to connect 2 different SNA networks is found in VTAM. 

There is no longer anything like a NCP (a Network Control Program). Connectivity on the VTAM side is now all SNA over IP (Enterprise Extender). VTAM uses the internet protocol to connect SNA to remote SNA nodes.

The CSDCD however supports both SNA over IP (Enterprise Extender) and legacy SNA over Ethernet (LLC2, IEEE 802.3, SNA DIX protocol). It has somewhat of what the same function a NCP had. The CSDCD supports CICS Transaction Gateway connectivity anywhere in the same SNA Network. If the LU6.2 needs to connect to another CICS Region in another SNA Network, a VTAM needs to be involved somewhere in the path to cross from one SNA network to another.  

The CSDCD can support CICS TX server regions connecting to CICS Transaction Gateways in a cloud, where the nodes are remote and may be on containers. However, for the SNA layout, they would be in the same SNA network. 

I hope this is helpful. The CSDCD provides SNA legacy connectivity for VTAM applications, like CICS, but it does not provide any cross border SNA capabilities. It will connect CICS applications to the CICS regions over LU6.2, but not across different SNA networks. To do that, a VTAM needs to be involved.  

Jeff,

Now we are on the same track.  Your latest statement is consistent with my own understanding, as shallow as it is.

One final question.  VTAM is only available as a component of CS either under z/OS or z/VM, both of which only run on IBM z series mainframes.  So, there is no way to have a VTAM SSCP independent of a mainframe.  Is that correct?  And if so, then there is no way to establish SNA connections across SNA network boundaries without a mainframe.  Correct?

Thanks for your time in answering these questions.

Wayne

You are correct Wayne. 

The z/OS Comm. Server VTAM is the only way to connect across multiple SNA networks. Without a mainframe, one cannot connect across different SNA networks. 

Jeff,

Thanks for your responses on this thread.  I really appreciate it.  At this point I have no more questions.

Regards,

Wayne

Jeff,

Well, after thinking about this for a bit I do have another question.

With CSDCD running under Linux, can I have multiple instances of CSDCD active where each one is connected to a different SNA network?

If this is possible, could I then have a separate local CICS TXSeries instance connected to each of the CSDCD instances?  Then each of the local CICS TXSeries instances could have an LU6.2 APPC connection defined to a remote CICS region elsewhere in the SNA network that its CSDCD instance is connected to.

I then should be able to connect all my local CICS TXSeries regions with each other using IPIC connections over TCP/IP.  And in this way be able to route transactions between all of the remote CICS regions in the various SNA networks.

Is something like this possible, or have I had too many cups of coffee?

Regards,

Wayne

You got some strong coffee there, Wayne ;-)

Your question: "With CSDCD running under Linux, can I have multiple instances of CSDCD active where each one is connected to a different SNA network?" 

No, within any Linux server, there can only be one instance (SNA node) of the CSDCD. You would need multiple Linux images, one for each different SNA network. Then, each CICS TX Series would have to somehow connect to other Linux instances of CICS to coordinate like one region (?).  

I have worked with several customers who attempted to get off the mainframe, only to find that the z/OS VTAM is required for any B-to-B SNA connectivity. 

Secondly, I have worked with systems that had a separate CSDCD Linux instance per partner SNA network and the application (LU6.2) that resided on each Linux image connected (using TCP/IP) to a back-end server for database access. This was like a Web application that served UPC pricing data for online retail requests from the multiple partners (separate SNA networks). This worked fine for 2 or 3 partners. When it got to be more, the cost did not justify the setup and using the z/OS CS (VTAM) became the more cost effective method.  

I have never seen anyone actually replace VTAM when the SNA B-to-B connections are required.

Jeff,

This is all very excellent information.  You got ahead of me with the multiple Linux systems, that was going to be my next question.

I now need to review and discuss this with my peers and see where we go from here.

Yep, trying to get off of the mainframe while having to maintain these legacy LU6.2 connections to the remote systems is a hurdle.

Thanks for your responses.  They are very helpful.

Regards,

Wayne