1. Why is TIRSLEXT written in Assembler?
Assembler skilled resources are VERY hard to find. Could it be changed to some other, more widespread, programming language?
2. Why does the security checking (userid/password) need to be done in TIRSLEXT?
Can it be done before TIML/TIRSLEXT is executed?
How do other customers do this?
3. Any future plans for changes in this area?
Release : 8.6
Component : GEN TCP/IP DIRECT CONNECT OPTION FOR CICS
Gen Engineering/Product Management provided the answers below:
1. Why is TIRSLEXT written in Assembler?
Assembler skilled resources are VERY hard to find. Could it be changed to some other, more widespread, programming language?
Gen Engineering:
TIRSLEXT is part of the CICS Sockets Listener and IBM dictates that this listener is written in assembler, so changing the language is not possible.
2. Why does the security checking (userid/password) need to be done in TIRSLEXT?
Can it be done before TIML/TIRSLEXT is executed?
How do other customers do this?
Gen Engineering:
The way TCP/IP implementation works is that the connection is established in the same flow as the application data is passed. There is no way to provide security data separate from the application data.
Gen passes the security data in the CFB and so it is only available when the buffer is received by the listener. TIRSLEXT is called as soon as the CFB is received so the security data can be validated at the earliest opportunity.
Customers use different options - some use no security, some use standard security and verify the password in TIRSLEXT, others use enhanced security and do the validation in the TIRSECVX exit, and yet others use encryption/decryption.
One customer also wanted to use the port the listener listens on as part of the validation, so that has been added to the data passed to TIRSLEXT.
Other customers have a Gen cooperative application as the SIGN ON application and pass security data in the application views and do validation in the server. Some do this in addition to standard security, some do it instead of.
Most customers do not tell us what they do with security checking unless they have an issue.
3. Any future plans for changes in this area?
Gen Engineering:
a. The Gen security options for Distributed Processing and in particular for z/OS, are documented in the Gen 8.6 Techdocs here:
Gen™ 8.6 Distributed Processing > Working With Distributed Processing > Security in Distributed Processing
Gen™ 8.6 Distributed Processing > Working With Distributed Processing > z/OS Security
b. Gen supports a variety of security options and customers select what is best for their organization. Rules vary by company, so Broadcom can't recommend a "best" option. It's possible the Broadcom Services team can be engaged on a consultation basis to work with any company to assess their needs and help with implementation. Your account manager can arrange a Services consultation contract.
Gen™ 8.6 > Reference > User Exits > z/OS User Exits
Gen™ 8.6 > Reference > User Exits > z/OS User Exits > z/OS Middleware User Exits - CICS TCP/IP Direct Connect Exits > TIRSLEXT - CICS Sockets Server Listener Exit
Gen™ 8.6 > Reference > User Exits > z/OS User Exits > z/OS Server User Exits - CICS > TIRSECVX - Server Client Security Validation Exit