IBM Data and AI Ideas Portal for Customers
This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
IBM Employees should enter Ideas at https://ideas.ibm.com
Dear John, Thank you for submitting this enhancement request.
Our Db2 for z/OS team re-reviewed it and determined that, due to the high impact to the Db2 for z/OS product (CAF Connect, Open, Close and Disconnect functions, and to the DSNALI language interface and changes to the SQL APIs) we will not be considering this idea at this time. Also, our twelve-month roadmap is already booked with other higher priority items.
Looking into the future, our development team provided what they believe may be a more appropriate option, which is to update RRSAF to 64 bit rather than CAF and TSO Attach.
We appreciate your input to the Db2 for z/OS development team. We also hope that you will continue to submit enhancement suggestions for improvements as customer feedback is a key component to shaping the future direction of Db2 for z/OS.
Sincerely,
Db2 for z/OS Team
I am going o create an interim assembler program to deal with calls to DSNHLI and DSNHLI2 to see if I can get my code to link edit. Once that happens, I will see if it actually runs.
I didn't get as far as the regular INSERT, UPDATE and DELETE statements as the program will not Link Edit. This program uses EXECUTE IMMEDIATE for the SQL it processes, The SQL is generated by another of our products that runs as a Started Task and it performs Change Data Capture of transactions from Broadcom's CA IDMS and translates into SQL. The SQL is written to MQSeries and then applied to Db2 on z/OS. To answer your question for the normal SQL processing; YES we would want that it all to be AMODE64 as well as. Unless I know the name of the program called by EXECUTE IMMEDIATE and the parameter list required for that program, writing code to handle that and do a mode switch to call the real interface would be a challenge. It would also mean ensuring that all WORKING STOARGE used would either need to be allocated using the ALLOCATE xxxx LOC 31 in the code or my interim program would need to create new parm lists and move the data back and forth between the 64 and 31 bit storage for every call creating unwanted overhead when there are very large volumes of SQL being processed. The good thing is that the current code does not use much memory below the bar.
It would be preferable to have all calls be AMODE64 directly without interim subroutines to do Mode switches, parm shuffles, etc. Since the emphasis these days is to move to AMODE64, our clients keep asking us to make our code AMODE64, one wonders why the Db2 interfaces are not there to support it. For now, I may use the in-house module to do the Mode switches, etc. As a side note, I waited for 8 years for z/OS MQSeries to support LP64. When that came alone, the customers were extremely happy. Interestingly, in the program for my current request for Db2, MQSeries is used so that makes this situation slightly more frustrating. Fortunately, the DB2/MQSeries code, in this case, uses minimal memory so below-the-bar is not so significant.
Hello John, Db2 development has reviewed this request and is asking for more information.
After having AMODE64 API for CONNECT, DISCONNECT, CREATE THREAD, SIGNON etc.., doo you also need AMODE64 API for SQL statements such as INSERT, UPDATE, DELETE, OPEN, FETCH, CLOSE, CREATE, etc? Those SQL statements are all AMODE31 only. If you are using a workaround for SQL, can you do the same for CONNECT/DISCONNECT?