Update processing of inbound LU 6.2 connection to region to detect connection already defined.

If a CICS region not using VTAM Generic Resource initiates an LU6.2 connection to another CICS region that has a corresponding connection defined the two regions connect without issue.

However, if a region using VTAM Generic Resource initiates a connection to a region not using VTAM Generic resource, despite having a connection defined, the connection fails to acquire and the back end CICS issues the following messages:

DFHZC6907 I 05/26/2022 08:56:49 CICSLDZ Autoinstall starting for netname CICSLT5. Network qualified name is USIBMT6.CICSLT5.

DFHZC6921 W 05/26/2022 08:56:49 CICSLDZ Autoinstall for NETNAME CICSLRGE has been disallowed by the autoinstall control program. Code X'FA07'

DFHZC2411 E 05/26/2022 08:56:52 CICSLDZ DUMY CSNE CICSLRGE attempted invalid logon. ((7) Module name: DFHZATA) NQNAME DUMY,CSNE, 8:56:52,USIBMT6 CICSLT5

In the DFHZC6907 and DFHZC2411 messages CICS identifies the front end region's actual applid of CICSLT5 but, I am assuming, then goes looking for a connection to he generic one CICSLRGE (reported in DFHZC6921) and fails to detect a defined one for CICSLT5.

The documentation at https://www.ibm.com/docs/en/cics-ts/5.5?topic=summary-grname indicates that a TOR should not attempt this connection initiation and be defined with AUTOCONNECT(NO).

https://www.ibm.com/docs/en/cics-ts/5.5?topic=lu61lu62-lu62-gr-non-gr-connections reinforces this by indicating the front end region should be started first which is impractical as it would result in a TOR being able to accept terminal logons but having no connected AORs to send the work to.

If both regions are using VTAM Generic resource, either region can successfully initiate a connection to the other using defined connections so the request is that the same detection of the real application id performed there is always performed.