NRS6316: Mixed case difficulties after TND42332 and TND42351 applied

Commentary

Thursday, July 1, 2010 at 08:48:25 am    After the Client applied PTFs to support mixed case passwords, CICS SSI fails with TND3422 and TSO/E fails to bypass the prompt.

Friday, July 2, 2010 at 08:21:40 am    For TSO: We've validated that a LOGON APPLID(TSO) DATA('userid/password') works successfully as a USS Command. TNDEFLD1 appears to be installed as IKJEFLD1 and was last assembled in 1998 (so..pretty old). But, as the USS command works, it's time to investigate what The Director is formatting and sending to TSO.

Friday, July 2, 2010 at 08:23:42 am    For CICS: SSI=YES is in effect on the CICS APPLICATION definition. I believe as a result of how we "encrypt" the password and detect the same in TNDGMMSA, this will fail half the time. I had the Client change to SSI=EXTENDED (which should resolve the encryption logic flaw in TNDGMMSA for mixed case), but client reports an AEI1 failure (Transid error). TNDGMMSA is as the 4.0.1 level and it appears to incorrectly determine whether or not to start an initial transaction. In fact, it picks up an SSI based offset to identify the first TRANSID when the SSX has it at a different offset. I have recommended to the client that TNDGMMSA be upgraded to 4.2.3 and we try SSI=EXTENDED again

Tuesday, July 13, 2010 at 12:47:45 pm    Client reassembled and reinstalled TNDGMMSA from 4.2.3 DATA library, changed the Director's APPLICATION to SSI=EXTENDED and all seems well on the CICS Front. Am still researching, but believe the solution for TSO is to remove TNDEFLD1 and permit standard RACF logon to operate. There may be something special to permit CLSDST PASS from the Director to contain the Password.

Wednesday, July 14, 2010 at 04:48:38 am    For TSO, efforts to automate the Logon through TNDEFLD1 were being greeted with a TND603I Installation Exit Error 060 message. Essentially, TSO was complaining about the exit providing the "wrong password". Technically, this was true because TNDEFLD1 was automatically forcing all incoming USERDATA buffer commands to UPPER case (which didn't compare very well with lower case passwords). I modified TNDEFLD1 (dubbed Version 4.2.4) to test the RACF CVT for whether SETROPTS PASSWORD(MIXEDCASE) was in effect or not and skipped the upper case translate, when mixed case was being used. Sadly, RACF still seems to require that we translate to UPPER case the Userid and Password when SETROPTS PASSWORD(NOMIXEDCASE) is in effect (so TNDEFLD1 logic had to adapt to both circumstances. Emailed the Client with the new source code and we'll see if it resolves the problems on his system like it did on ours.

Thursday, July 15, 2010 at 12:37:51 pm    Client has indicated that the 4.2.4 Version of TNDEFLD1 appears to have resolved the TSO related MixedCase issues. However, while the automated SIGNON to CICS is working properly with the new TNDGMMSA, the initial transaction is not receiving the INITIAL-DATA buffer properly. I'm suspicious that we're testing 8 characters in storage that don't compare favourably because the INITIAL-DATA length is only 6 characters. Have shared this with the client and will see how the next step goes.

Monday, July 19, 2010 at 04:58:47 am    Client reports they converted to the new system with the revised TNDEFLD1 and TNDGMMSA installed on 7/17/2010 and all seems well thus far. Will wait for a week or so to close this (if we have no further queries, etc.).

Thursday, July 29, 2010 at 10:24:11 am    Migrated code provided to client into Update 4.2.4 for TNDGMMSA