🚀 go-pugleaf

> Hello All
>
> I ran traces on the successfull bind(from CICS) and the one that fails
> (from APPC/MVS). I've narrowed down the difference to bytes 23 & 24 of the
> bind. These bytes are 00 4F for CICS and 10 23 for APPC/MVS.  According to
> the SNA formats manual, byte 23 specifies parameters for security and byte
> 24 carries info about the type of session/conversation. So, for CICS byte 23
> is set to all zeroes. Byte 24 for CICS says CONFIRM,SYNCPOINT,BACKOUT and
> PARRALELL supported while for APPC/MVS it only sets CONFIRM on.
>

The bytes mean the following:

CICS: no security fields accepted (byte 23, bits 0-3 <> x'1')
      confirm, syncpoint, backup supported (byte 24, bits 0-3 = x'4')
      parallel sessions, CNOS supported (byte 24, bits 6-7 = b'11')

MVS:  security fields accepted (byte 23, bits 0-3 = x'1')
      confirm, supported (byte 24, bits 0-3 = x'2')
      parallel sessions, CNOS supported (byte 24, bits 6-7 = b'11')

The only practical differences are 1)  MVS accepts security fields
(user ID and password) in received attaches (FMH5s) but CICS does not;
2) CICS supports syncpoint but MVS does not.  If the DG application
requires syncpoint and backout protocols then APPC/MVS cannot be the
server because MVS does not have a Resource Recovery Manager capable of
handling the syncpointing.  (CICS/ESA, APPC/VM, DB2/ESA, OS/400 V3, and
SNA Server/6000 (w/ Transarc's Encina) are the only platforms to my
knowledge that have syncpoint support.  CM/2 with DB2/2 will have
syncpoint in a future release.)

If the DG application does not require syncpoint services then
practically speaking the two Binds are the same.

What is the sense code in the Unbind sent by the DG box back to MVS?
What is the Bind response that the DG box sends back to CICS?  Perhaps
that can shed more light on the problem.  Many products incorrectly
echo the reserved bits in the Bind instead of making them b'0'.  It's
possible the DG SNA code is doing something like that.  That's why the
returned DG sense code and bind image will be useful.

It's possible that the mode name you are using is not in the mode table
associated with the APPC/MVS APPL statement.  That would result in three
flows - a bind from MVS to DG, a bind response from DG, an Unbind from
VTAM to DG.  If this is the sequence, just put a mode entry in the
APPC/MVS mode table (the one specified in the MODETAB entry on the APPL
statement).  This is just speculation on my part, though, since I don't
have a trace to look at.

> My problem now becomes, how do I get bytes 23&24 of the APPC/MVS bind to
> look the same as the CICS bind, given the fact that CICS overrides some
> of the parameters on the logmode by using values defined on the CONNECTION.
 >
> Please, anybody with ideas?

There is no way to make the APPC/MVS bind match the CICS/ESA bind
because of the syncpoint support.  You can make APPC/MVS not accept
security subfields but there's no advantage to that since what you have
should work anyway.  To turn off