Convert from PCOMM to HIS RRS feed

  • Question

  • Client is currently using PCOMM to connect Z/OS Mainframe Enterprise Extender and getting data back by initiating CICS transactions.  Front-end Visual Studio C++ application contains APPC calls such as Allocate, Send,  Receive and wait, Confirm and End.  They are planning install non-microsoft product and develop new front-end application. But I want use existing application with HIS and get the data from mainframe with minimum changes. For proof of concept, I want to show few screens with existing front-end and back-end application using HIS. Is it possible to do that without making any changes in mainframe side?.  If someone provide the steps/procedure to install and use HIS to request and receive data from mainframe using CICS trans, that will be very helpful for me. I appreciate your help. Thanks. Jay.
    Monday, November 21, 2011 5:31 AM


  • Hi,

    If you're already using IPDLC with Enterprise Extender, you only need to set up your VTAM CICS Definition. Please find attached several really good whitepapers available :

    Please feel also free taking a look at my blog :

    Best Regards,

    Steve Melan - BCEE My Blog :
    Monday, November 21, 2011 10:15 PM

All replies

  • Hi,

    If you're already using IPDLC with Enterprise Extender, you only need to set up your VTAM CICS Definition. Please find attached several really good whitepapers available :

    Please feel also free taking a look at my blog :

    Best Regards,

    Steve Melan - BCEE My Blog :
    Monday, November 21, 2011 10:15 PM
  • Steve

    > Please find attached several really good whitepapers available :

    As any subscribers who have seen my posts in the past will know I'm here not at all as a HIS specialist but as a VTAM/SNA/APPN/Enterprise Extender specialist. Specifically I am here to combat the nonsense I see in this post.

    Long ago (2008) I attempted to point out to Microsoft how inaccurate the treatment of Enterprise Extender (IP-DLC) is in the "Configuring IP-DLC Link Service for IBM Enterprise Extender White Paper" document and you now have the effrontery, after all my efforts to have it corrected, to describe as "really good"!!!

    It may be some flavour of "good" as regards whatever is said about configuring the HIS side of the configuration but it is very misleading and confused and a lot more besides regarding the VTAM side of the configuration - and at least one prompt in the HIS panel which imagines it knows something about the VTAM side but is quite wrong! This confusion can be seen in a fairly recent thread in this forum "Biztalk 2010 Host Integration Server - Printer setup" which, incidentally - "softe" are you listening? - we have yet to hear has been resolved.

    In order to deal with the inaccuracies and infelicities in the HIS panels regarding the interface with the Enterprise Extender protocols and the way VTAM works, I created a thread '"Starter" HIS/VTAM IP-DLC/Enterprise Extender Notes'. If you use the "Configuring IP-DLC Link Service for IBM Enterprise Extender White Paper" be sure to stay sane by combining it with what is covered in the final post in this thread.


    > you only need to set up your VTAM CICS Definition.

    What is this actually supposed to mean. The only "VTAM Definition" which definitely relates to CICS is the single APPL statement, in VTAM terminology a "minor node". It may be that some mode table entries are created in order to set up SNA session parameters to match what CICS expects, perhaps in connection with "autoinstall" models.

    I can see no need whatsoever to change anything to do with the parameters relating to the definition which informs the CICS-VTAM API, namely that APPL statement, when the platform supporting the partner SSCP-dependent or SSCP-independent LU entities supporting LU type 6.2 (APPC) protocols changes.

    Which reminds me. Jay will avoid a lot of the confusion in the "White Paper" if his application uses only SSCP-*in*dependent LU entities.


    Incidentally 2 does not equate to several in my lexicon.


    I did take a look at the "Legacy Modernization with BizTalk Server 2006 and Host Integration Server 2006" document and it looks quite handy as a description of a particular project.

    It all looked just fine until I got to the Glossary and I found a most perniciously untrue statement:


    System Network Architecture (SNA) is the IBM proprietary networking architecture created in 1974.


    What utter tosh!!!!!

    There wouldn't be a HIS if SNA was a proprietary protocol. Think about it! For a company that relies upon logic, how the <expletive deleted> does someone from within Microsoft manage to come up with such a bigoted evidently illogical statement?

    Chris Mason
    Tuesday, November 22, 2011 2:47 PM
  • Not wanting to start a flame war, BUT, typing "sna proprietary" into Bing, leads to this (second link on the first page, the first link was to Wikipedia):

    Which states in its first sentence:

    Systems Network Architecture (SNA) is a proprietary network architecture developed by IBM.


    Maybe Chris could inform IBM that they are wrong. :-) <-- note the smiley.


    Rob :-)

    Wednesday, November 23, 2011 5:15 PM
  • Rob

    "At home", "at work" or "at leisure" and smiley or no smiley, the anti-SNA bigots of whatever vehemence can be found within IBM as well as outside. For "outsiders" often it is a deliberate stance taken in the hope that, by slinging mud at the IBM products, their own products will be seen in a kinder light.

    This is the Cisco approach and can be seen time and time again, for example in the Wikipedia articles:

    And now that I have looked up that first article I see that this is from where the Microsoft document definition comes.

    So I guess I have now to reflect that the document simply allowed itself to be duped by the Cisco propaganda.

    The aberration you found is in an interesting set of web pages. I imagined at first it was actually an IBM redbook. IBM redbooks are essentially informal documents as much authored by customers - where the anti-SNA bigotry is almost obligatory if you want to appear "cool" - as by IBM folk - where being an anti-SNA bigotry is probably considered just as "cool" within much of the company.[1]

    It's not actually a redbook but a set of web pages supposedly constituting education material and very probably from the same "stable" as redbooks. (It's rather coy over the matter of authorship - to protect the guilty no doubt!) What is evident is that the focus of this material is z/OS and I notice, whenever I review a redbook where the focus is z/OS, SNA and VTAM get short shrift and even the IP-based protocols can get a mangled treatment. It's all down to excessive specialisation - and probably a bit of bigotry thrown in!

    For example, recently the following redbook was produced "Considerations for Transitioning Highly Available Applications to System z"[2] which precisely illustrates the disdain for SNA/VTAM and the utter inability to describe the IP-based "availability" functions.


    While checking on this topic of "SNA" and "proprietary" I found this particularly virulent strain of the plague:


    Systems Network Architecture - (SNA) IBM's proprietary high level networking protocol standard, used by IBM and IBM compatible mainframes.

    Also referred to as "Blue Glue", SNA is a bletcherous protocol once widely favoured at commercial shops. The official IBM definition is "that which binds blue boxes together." It may be relevant that Blue Glue is also a 3M product commonly used to hold down carpets in dinosaur pens.


    It looks like "The Free Dictionary" is going to have to be set up as a blocked, tainted site!

    I thought I'd include that just to indicate how corrosive this tendency can become.


    But also while searching I got a hint over why people - especially those who just do a bit of searching in order to find some text to support their previously taken position - could try to claim that "SNA" is "proprietary".

    The point is that, initially back in the mid-70s significantly through to the late 80s, *part* of SNA was indeed proprietary to the extent that IBM retained control over the design of the architecture.

    I'm going to oversimplify a bit to keep a relatively clear messages given that the water is muddied if one recalls that there used to be non-IBM Communication Controllers out there.

    The implementation of the SNA subarea nodes within the original - to become described as "subarea" - SNA, namely TCAM, VTAM and NCP, were *not* according to an architecture which any old software organisation - or indeed hardware organisation - were invited to offer alternatives to the IBM products, hence that part of SNA, the key part at the time, was "proprietary". The subarea nodes were responsible either side of 1980 for actually allowing something which could be described as a "network" to be created - as long as it consisted wholly of subarea nodes.

    On the other hand, the implementation of the SNA *peripheral* node which attach to subarea nodes, its data link controls, its link station function, the SSCP-dependent PU entity and the SSCP-dependent LU entities, were for any vendor to undertake. I can't recall whether or not there was any Microsoft product which implemented, to give it its formal architectural name, the type 2.0 node.

    From the time that the "Low Entry Networking" (LEN) architecture was introduced in the late 80s through to APPN being introduced shortly afterwards, the type 2.1 node, again these designs were open to any vendor and that is how it stands today. Microsoft provided an implementation of LEN, rather famously so, and has only relatively recently got onto the APPN wagon with the very poorly explained so-called "IP-DLC Link Service" add-on product.

    Obviously it is the APPN "flavour" of SNA which concerns HIS and so is the "flavour" of SNA which logically should have featured in that document I mentioned.

    Describing a protocol as "proprietary" these days is considered to be a slur and so I sat on this unwarranted insult.

    Getting back to the IBM web pages, it may well be ignorance as well as bigotry which has caused them to position the word "proprietary" in the wrong section, the introductory section rather than the section which covers traditional subarea SNA - as long as it is made clear that the peripheral node was "open".

    I had a quick glance at the rest and actually it's pretty awful, probably about as bad as the "White Paper"!


    But now we return also to my "think about it" appeal. Don't you think it's rather dishonest to propose that I am wrong about SNA, the "SNA" relevant to HIS, not being "open", being "proprietary", without providing some explanation how HIS can include implementations of the architecture - almost[3] - specifically a LEN node and a Branch Extender Node - although the Microsoft documentation tends to try to avoid having to strain their poor customers' brains by keeping that level of complexity all rather quiet?

    Perhaps you do have an explanation how both Microsoft - and indeed Cisco and perhaps other who are or have been participants in the APPN Implementers' Workshop[4] - has managed to offer an SNA-based product, even calling the product "SNA Server" when it first appeared, while the design is deemed to be "proprietary".

    I'm all ears!


    [1] Redbooks are actually supposed to be moderated but just aren't these days and, in any case, the "moderation" extends only to proper American English - even, according to a colleague of mine, resplitting infinitives, an ugly practice which he had strenuously avoided.


    [3] There are a few bits and pieces missing between what I take to be the Microsoft panels which feed the underlying APPN Branch Extender Node "engine" supplied by the well-known software house. This makes for an incomplete rendition of a proper APPN solution.



    Chris Mason
    Thursday, November 24, 2011 12:53 AM