We have several application teams that are looking to do a re-write of large legacy applications.
This is mostly COBOL going against DB2 for z/OS (v11).
The COBOL code was generated using a tool, so we don't have any access to the source. Let's say the SQL cannot be changed for the sake of this question.
They would like environments (dev/test/perf) where they can copy the existing data and test the re-written application (still using the same SQL) while still having a team supporting the legacy system through dev->test->perf->prod.
Current SQL example:
SELECT FOO FROM MYAPP.BAR;
Because the table name was fully qualified with "MYAPP" instead of supplying it later, they cannot simply copy the code that they already have within the same DB2 and just change the schema name. They would like entirely new DB2 subsystems to avoid this issue.
Is there any way to avoid this? Are there any bind parameters or other strategies I could employ to have duplicate schema names running on the same DB2 subsystem?
Best Answer
If the application is hard-coded with the qualifier, then it can only use that qualifier and SCHEMA.table-name is unique.
The best approach is rewrite the application to use unqualified table names. If you do end up considering creating additional subsystems, you might consider zD&T. This is z/OS running on Linux on x86 for dev/test environments. https://developer.ibm.com/mainframe/products/z-systems-development-test-environment/