Db2 Connect NULLID packages should be shipped in Db2 zos PTFs for BIND

This is a historic and on-going problem with the design of binding the NULLID packages on Db2 zOS from the Db2 Connect client installer.

For high-security mainframe platforms, the Db2 Connect installer will not have authority to bind on a production system. It's a risk to the platform and security controls prevent it.

Subsequently, the Db2 Connect bind design causes an incident and interferes with the customer working environment. This should be recognized and addressed.

Here is an example.

Large medical and/or govt sites will NOT allow the Db2 Connect installer to bind on production.
The company users, programmers, business analysts, etc., need Db2 Connect to function in their jobs.

Because the Db2 Connect installer cannot bind on production, the customer systems staff have to navigate their systems to a situation where the Db2 Connect installer can do the bind (like the sandbox), then the customer systems staff will rebind it with the correct authorities, then COPY BIND across all the platforms. If there are 92 data sharing groups, the systems staff has to COPY BIND 92 times.

The designers of Db2 Connect should be shipping the DBRMs (or whatever Db2 Connect code is required for the bind) with Db2 zOS in PTFs to eliminate the gyrations it takes to get Db2 Connect to work on high security mainframe systems. The Db2 Connect binds can be done as part of Db2 zOS regular maintenance and this solves the current gyrations required on high security systems.

Note: mainframe Db2 Systems staff does not reverse engineer the DBRMs; they use a shipped Db2 command to copy the bind to other systems.