Difference between IPCONN and normal MRO connection used with CICS TG

You will need to cover for situations where:
1) userid and password are passed from CICS TG
2) userid only is passed from CICS TG
3) no userid or password is passed from CICS TG

Since the default userid has the access needed to run these tasks, you will need to code USERAUTH=LOCAL or USERAUTH=DEFAULTUSER. You can not code USERAUTH=IDENTIFY as this is policed to only allow a userid to be passed in. It does not allow NO userid to be passed and does not allow userid and password to be passed.

The difference in USERAUTH=LOCAL and USERAUTH=DEFAULTUSER is that LOCAL will also allow you to preset the userid on the link using the coding of LINKAUTH=SECUSER and SECURITYNAME=userid. USERAUTH=DEFAULTUSER will just use the default user period.

When using MRO connections for EXCI (CTG), the only way CICS would allow you to pass userid and password with ATTACHSEC=IDENTIFY is if you also have USEDFLTUSER=YES coded in the Connection definition. Otherwise, you would have the same problem with IDENTIFY and a userid AND password being sent in........OR no userid being passed in.

If the outcome is to have the CICS TG pass userid and the task to run under that userid in CICS, then you will have to code USERAUTH=IDENTIFY as you had before. However, with IPCONN, you can not code USERAUTH=IDENTIFY and have the CICS TG pass NO userid .... OR pass a userid and password (which would require USERAUTH=VERIFY).

As I explained before, in EXCI configuration the odd ball situations were only allowed if USEDFLTUSER=YES was also coded on the associated Connection definition. Which really defeats a purpose of ATTACHSEC = IDENTIFY or VERIFY in an EXCI (or MRO) environment. However, USEDFLTUSER was introduced way back when because of some major changes to security. Many did not like the changes and wanted a way to roll back to the old way before the change so they would not have to change applications. thus, USEDFLTUSER was created to basically allow the rules of IDENTIFY and VERIFY to not be enforced.

IPCONN is newer and the rules are enforced. Thus, applications that want to make use of IPCONN must be written to follow the rules. If you say you want USERAUTH=IDENTIFY then ONLY a userid can be passed and the absence of userid or the presence of a password is against the rules.