Conference smaug::snagwy

    Re .0
    
    LU.2 on Digital UNIX/CICs talking directly to the LU6.2 implementation
    on the VMS system directly is not possible with the standard out of
    the box products.
    
    Would the customer be willing to pay consulting $s for to do a special
    ie an SI type project? If so send me mail. The reason being is that I
    can see exactly how to extend the APPC product under Digital UNIX to be
    able to talk directly to the APPC implementation on VMS. In this case no
    gateway would be required and all existing interfaces would be maintained.
    
    This note is not a committment to be able to do an SI project. Merely
    an indication to contact me if you/the customer are interested in
    looking into this further.
    
    Regards,
    
    Dave Garrod
    IBM I/C Engineering
                       

>                     <<< Note 7029.0 by TAVIS::JONATHAN >>>
>                    -< CICS UNIX replacing MVS CICS LU6.2 >-

>We are thinking about an Alpha UNIX machine with Digital UNIX CICS with a 
>similar CICS application to what runs today on the mainframe. (The application 
>on the Alpha UNIX would have to access the new VAX for the data required and
>then transmit it back to the customer site.)
>
>1. Can the Digital UNIX CICS replace the current IBM MVS/CICS without requiring 
>* any * changes to the customer's application?

This is 100% dependent on how the applications is written.
If the application is all in C, the chances are pretty good.  IBM Assembler,
your "out of luck".

>2. Do we need a Peer Server or Domain Gwy-ST, or can the DEMSA-ST remain?

See #4

>3. Do we need the UNIX APPC product?

I belive you get this with CICS for Digital Unix.

>4. Can Digital UNIX CICS work with dependent LUs, like VMS APPC/LU6.2?

If you replace the ST with a Peer Server, you remove the need for Dependent
LUs (the one thing you lost when VTAM went away.)  

From an SNA standpoint, you now have what you need.  The CICS APPC 
applications can BIND the VMS LU6.2 SLU.  (CICS must initiate, since your 
now in an all independent LU world _and_ the VMS applications are SLU only
(thus can't send a BIND)).

The catch may be how the VMS LU6.2 & peer server implemented the SNA.
You'll need to check the SPD I guess.  As I said, from an SNA point of 
view, it should.

For example, for reasons which escape me, if you try to use the VMS 3270 
terminal emulator with an independent lu on peer server, peer server will 
reject it.  It forces you to use a dependent lu.

So, if the VMS LU6.2 can use an independent LU on the peer server (and 
CICS already initiates the session or your application can be changed to 
make CICS initiate and stop VMS from initiating), you're all set.  Well,
you've still that small matter of porting the CICS application to CICS on 
Dunix ....

If this doens't work ...  well besides the fact that it is 100% valid 
SNA, there may be other possibilites using OS2 as you've mentioned.  I 
need to play a bit at home on my Warp systems to verify.

MikeC

    RE .2
    
    I'm afraid .2 contains incorrect information.
    
    The APPC product on UNIX can't directly BIND the APPC product on VMS
    because the APPC product on VMS expects to talk to a gateway and can't
    handle the receipt of BINDs until after it has done a GAP connect.
    The UNIX APPC product can't habdle a GAP connect before it sends
    a BIND in other words catch 22.
    
    My .1 proposed a way of adding this functionality as a SI project.
    
    Dave

>      <<< Note 7029.3 by EDSCLU::GARROD "IBM Interconnect Engineering" >>>
>                              -< .2 is incorrect >-
>
>    RE .2
>    
>    I'm afraid .2 contains incorrect information.
>    
>    The APPC product on UNIX can't directly BIND the APPC product on VMS
>    because the APPC product on VMS expects to talk to a gateway and can't
>    handle the receipt of BINDs until after it has done a GAP connect.

I'm afraid EDS doesn't know SNA.....

Re-read what I wrote.  I said to replace the ST with a peer server!
Use an independent LU on the peer server from the LU6.2 VMS product.
Have the CICS on Digital Unix send the BIND to this (using either the 
same or yet another peer server; I don't care.)

VMS LU6.2 
---------
   |
   |
 decnet
   |
   ------- peer server -------/
                             /
                            /--------- peer server  CICS for Digital Unix.


>    The UNIX APPC product can't habdle a GAP connect before it sends
>    a BIND in other words catch 22.

Where did I ever say anything about GAP!  I offered an _all_ SNA solution
to an SNA problem. 

VMS LU6.2 applications don't change.  The ST is replaced by a peer server 
in order to get independent LUs.  The VMS LU6.2 applications now uses these
independenet LUs.  That takes care of the existing stuff.  No gaps, no 
new development etc.. we're all SNA from this point on.

CICS for Digital Unix (and Dunix APPC which comes bundled I belive) 
and (the same or a new) peer server run APPC transactions just as they 
do today on the mainframe.

While the mainframe is still around, you can even start migrating your 
VMS LU6.2 applications over to a peer server.  Once they are running as 
independent LUs, they (as well as any future applications) will not care 
who is binding them.

Mike

    Re .4
    
    SNA may already have solved this problem. But .0 is asking about
    the use of the VMS APPC product.
    
    Your suggestion won't work.
    
    When CICS sends a BIND to the Peer Server the Peer Server will want to
    send the BIND out on a TG. Since there is no SNA network there is no
    TG. Therefore the BIND has nowhere to go. The BIND absolutely will not
    get sent out on a GAP link to the VMS APPC product which is what you
    are suggesting.
    
    If there was an SNA network in the picture your suggestion would work
    I think. But there is NO SNA network for the Peer Server to connect
    to ie no other LEN node, APPN EN node, APPN NN node or sub-area node
    for the Peer Server to establish a TG to.
    
    Try answering the question that was asked instead of one that wasn't
    asked.
    
    Dave

    RE .4
    
    The only way your solution will work using Peer Server is to set up an
    INTRANODE TG in the Peer Server or using two separate Peer Servers.
    
    The problem with this is that the VMS APPC product would then have to
    do a Passive Connect to the Peer Server prior to the CICS product (or
    equivalent) doing a BIND. I'm not sure from the description in .0 whether
    that is an acceptable restriction or not. Also I have a feeling (I'm not
    sure whether this is the case or not) whether Passive connects to an
    Independent LU is an allowed combination in the Peer Server.
    
    Dave

    I have verfied that VMS APPC can do a passive connect to an
    independent LU in the Peer SErver. I was unsure of that in .5.
    
    Given that the Peer Server solution would function as long as the VMS
    APPC application isn't coded to do an ACTIVE connect. It would only
    work if it does a Passive Connect ie the connect mode is
    SNALU62$K_INITIATE_OR_QUEUE rather than the default
    SNALU62$K_INITIATE_ONLY.
    
    In this case the Digital UNIX end would have to initiate the BIND after
    the VMS APPC application is running. The CICS end would also have to be
    set up NOT to use paralell sessions ie not try to start a CNOS
    transaction.
    
    If you need active connects from the APPC VMS product you would need
    changes I discussed in .1 to the APPC UNIX product. With those changes
    a Peer Server would not be necessary and both active and passive
    connections would work.
    
    Regards,
    
    Dave

>      <<< Note 7029.7 by EDSCLU::GARROD "IBM Interconnect Engineering" >>>
>                               -< More details >-
>
>    I have verfied that VMS APPC can do a passive connect to an
>    independent LU in the Peer SErver. I was unsure of that in .5.
>    
>    Given that the Peer Server solution would function as long as the VMS
>    APPC application isn't coded to do an ACTIVE connect. It would only
>    work if it does a Passive Connect ie the connect mode is
>    SNALU62$K_INITIATE_OR_QUEUE rather than the default
>    SNALU62$K_INITIATE_ONLY.
 
I _did_ say all this in my original reply.....

I also said that you may need 2 gateways (as I too wasn't sure if the 
peer server implementation supported what from an SNA point of view others
take for granted. <vbg>)
   
>    In this case the Digital UNIX end would have to initiate the BIND after
>    the VMS APPC application is running. The CICS end would also have to be
>    set up NOT to use paralell sessions ie not try to start a CNOS
>    transaction.
 
Yes these are restrictions in the way the product was built, not in SNA, 
and I _did_ also point this out in my original note.  When they replace 
the EXISTING CICS with ours, this was a given.  The config etc. all should
not change.
   
>    If you need active connects from the APPC VMS product you would need
>    changes I discussed in .1 to the APPC UNIX product. With those changes
>    a Peer Server would not be necessary and both active and passive
>    connections would work.

Or change one call in the VMS application (if this is needed at all.)
If an _active_ connect is being used, you could simply _add_ a passive 
connect after it (which one _should_ do anyway.  Even today, if the MVS 
side is not up, you can be ready once it starts.)

If you want, there are other parties which may willing to do SI work 
to change your VMS applications from active to passive connects .. 
:-)

Mike

    Hi,
    	As you can see, it may be possible to get all of this done,
    but as I may have informed you before in a note you mailed offline,
    it's quite untested.  If you are the individual with the 2 month
    time frame, I would suggest alternatives.
    	A custom SI from EDS could not get support from the CSC.
    You'd have to work out payment for support and maintainance of
    the change with EDS.
    
    	An internal loop back:
    
    	VMS  --> Looped Peerserver---> LU6.2 3.*--> Looped Peerserver---> VMS
    
    	Would require SIGNIFICANT Programming on the LU6.2 side for it
    to be master to two slave VMS systems  - OR - some input from the
    CICS for Digital Unix testers to indicate what would be needed
    to test this configuration.  I will ask them, and I or they will
    get back to you.
    
    	Going VMS-> VMS without SNA is, as I informed you before,
    something you CAN do in 2 months where you Anat, and the customer
    may be able to rest comfortably some time during the 2 month
    time frame.
    
    	The GREAT part about getting it done ( if you can work it), 
    is that Digital Unix, with the peer server, and CICS for Digital
    Unix becomes a REAL replacement for the IBM.  It would be
    a technological VICTORY if it were done and tested.  Everyone,
    EDS, Digital, and your customer could benefit from it.
    As a tester and former CSC rep, I would think 2 months is
    kind of close.
    
    I'll let you know what I hear,
    Cindi
    

First, thanks to all who have participated in this topic up to now.

Going back to the base-note - here are some of my basic assumptions:

1. that CICS for Digital UNIX could act as a replacement for MVS/CICS.

2. that CICS for Digital UNIX, "provides a complete CICS environment, including
   the following features:
       * InterSystem (ISC) communications"   page 2-2 Intro manual to CICS UNIX.

3. that MVS/CICS uses ISC in communicating with VMS/LU6.2, 
   cf DFHTCT TYPE=SYSTEM, macro for the MVS/CICS definition vis-a-vis VMS LU6.2
   page 5-13 of Guide to IBM Parameters for the DECnet/SNA Gateway-ST

If assumptions 2 and 3 are right, why do I need UNIX APPC at all?
It seems that I need the equivalent DFHTCT TYPE=SYSTEM macro for the CICS UNIX.

VMS/LU6.2 works through a DEMSA-ST to the IBM mainframe NCP and VTAM.
What takes the place of the VTAM and NCP now?  If I replace the DEMSA-ST 
with a Peer Server, and have on the UNIX box both CICS UNIX and a Peer Server,
am I set to go?


re .9
    
>    	VMS  --> Looped Peerserver---> LU6.2 3.*--> Looped Peerserver---> VMS
    
>    	Would require SIGNIFICANT Programming on the LU6.2 side for it
>    to be master to two slave VMS systems 
 
I am proposing using something like DMQ for the task-to-task communications
required to get the data from the VMS server system. There will be *NO* LU6.2
on the VMS server.

Schematically,


      ____________         _______________             ________________
        VMS LU6.2 |        | Peer Server |             |   VMS server
         client   | <----> |CICS UNIX ISC|             |    DMQ VMS   
                  |        |     "       |<----------->|       "
        NO CHANGES|        |  DMQ UNIX   |             |   Data Base
      ____________|        |_____________|             |_______________

>    	Going VMS-> VMS without SNA is, as I informed you before,
>    something you CAN do in 2 months where you Anat, and the customer
>    may be able to rest comfortably some time during the 2 month
>    time frame.
 
The customer has 70 sites, and to make software changes in his environment is
out of the question.
    
I know this is a *really* kludgy solution to an otherwise easy problem, 
but the customer is always right .......  Well, most of the time.

Is CICS for Digital UNIX still around???  The notesfile has been very very 
quiet - my note was the first activity there for 3 months and Dave was the 
only person to reply!!

Thanks,
Jonathan

    
    Re:
    
>3. that MVS/CICS uses ISC in communicating with VMS/LU6.2, 
>   cf DFHTCT TYPE=SYSTEM, macro for the MVS/CICS definition vis-a-vis VMS LU6.2
>   page 5-13 of Guide to IBM Parameters for the DECnet/SNA Gateway-ST
>
>If assumptions 2 and 3 are right, why do I need UNIX APPC at all?
>It seems that I need the equivalent DFHTCT TYPE=SYSTEM macro for the CICS UNIX.

    CICS for Digityal UNIX is layered upon the APPC UNIX product when it
    does SNA communication. Since the VMS/APPC is speaking SNA (albeit
    encapsulated in TCP/IP or DECnet) you need something at the other end,
    specifiically the APPC UNIX product to speak those SNA protocols.
    
    Re:
    
>VMS/LU6.2 works through a DEMSA-ST to the IBM mainframe NCP and VTAM.
>What takes the place of the VTAM and NCP now?  If I replace the DEMSA-ST 
>with a Peer Server, and have on the UNIX box both CICS UNIX and a Peer Server,
>am I set to go?

    The combination of the Digital UNIX APPC product and the Peer Server
    takes the place of VTAM nd NCP. And as I discussed with you on the
    phone with the proposed Digital UNIX APPC product modifications the need
    for the Peer Server is also eliminated. As also discussed the UNIX APPC
    product modifications are also required to meet your stated goal of not
    changing one line of code on the client VMS systems. As also discussed
    if you are able to change the VMS client code you would not need UNIX
    APPC product modifications but you would need the Peer Server product
    in addition.
    
    Regards,
    
    Dave
    

    Hi,
    	Dave G. has added some useful information.  If you read
    the pre-requisites for CICS for digital unix, you will find
    APPC 3.0 for Digital unix is what it RUNS on.
    	All the CICS for Digital Unix will buy you is your transaction
    management.  Those transactions would have to be ported form the IBM's CICS
    to the CICS for Digital unix. The guts of it is still LU6.2 for digital 
    unix.  If the LU6.2 for Digital unix won't bind your passively
    connected session like it did in my test a couple of years ago,
    then the CICS for Digital unix (which uses that LU6.2) won't be
    able to do it either.
    
    	If you wish to go with Dave's custom option you will have to
    make sure the customer knows it is an EDS solution, subject to
    EDS rules, and over and above any contract held with Digital.
    When they call in, they will have a special project all their own.
    Make sure you get your separate support contract and rules 
    approved between the external (NON-Digital) customer and EDS
    before you begin.
    
    	===
    
    If you're using DMQ to get the messages back to the VMS system,
    then that removes a part of your problem.  All you need to 
    check is that you can bind (passively) to an intranode transmission
    group, and send a transaction.  If it works, as I informed you
    before, no custom ANYTHING is needed.  If it works, CICS for
    digital unix isn't needed.
    If you MUST have an active connect on independent LU's, or
    direct connects from VMSLU6.2 to DULU6.2 you will contract with
    EDS directly.
    
    Good Luck,
    Cindi

    To add to what Cindi is saying.
    
    My guess is that using CICS for UNIX is overkill here. Whatever path
    you end up taking, in order to get the application on the UNIX serve
    you may well find it easier to layer it directly on top of APPC for
    UNIX rather than CICS for UNIX. As you point out you're going to have
    to use DMQ or something for the UNIX box to talk to the VMS server box
    anyway.
    
    If the function of the IBM application isn't tightly tied into CICS I'd
    forgo trying to get CICS up on the UNIX system. And as you pointed out
    to me on the phone you don't have  access to the former mainframe CICS
    application anyway and thus that application has to be reengineered
    from reading the VAX client code.
    
    Dave