This portal is to open public enhancement requests against IBM Z Software products. 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).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
See this idea on ideas.ibm.com
Requirement:
Our customer requires to enable to create the programs in PDS strongly.
Requested Completion Date:
2014/03/31
Background:
The program modules, which are compiled by Enterprise COBOL V5, should be reside in PDSE. Then our customer faces the problem for the development and the test environment. Because they cannot share PDSE.
Our customer understands the advantages of using PDSE over PDS. But PDSE can be shared in the same SYSPLEX only. This is a critical restriction for our customer.
Each test environment, the compiling system, some regression test systems and long-running test systems, is MONOPLEX or individual SYSPLEX separately. Additionally, to release the programs into the production systems, the libraries are shared between the compiling system and the production systems. Off cource there are not in the same SYSPLEX.
It is too difficult to use PDSE because of following reasons.
- They must change the program release procedure, the operation guides and so on.
- They must revice some tools which check the PDS library and modules.
- They must develop new tools, RESERVE/RELEASE of the PDSE volumes etc.
- There are risks to damage the shared PDSEs.
- Thare are many APARs about PDSE of z/OS DFSMS now.
- They must examine and change the PDSE system parameters for a lot of systems.
- They must migrate existing programs from PDS to PDSE
So, IBM must provide the improvement that Ent COBOL supports PDS again.
Idea priority | Urgent |
By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Programming Languages
Product - COBOL Compilers
For recording keeping, the previous attributes were:
Brand - Rational
Product family - Design & development
Product - COBOL Compilers
IBM understands well the challenge of migrating from PDS load libraries to PDSE load libraries, and we have received other feedback about COBOL for z/OS V5 and its requirement for PDSE load libraries. We even looked into the possibility of changing COBOL V5 to support Load Modules and PDS load libraries, but it is not possible. The need for PDSE datasets and Program Objects are built into the very core of COBOL V5. Just a few examples of features that COBOL V5 uses and will use that require Program Objects(PO) and this PDSE datasets for executables are:
- QY-con requires PO
(That's a performance improvement for RXY (long displacement) instructions. )
- Condition-sequential RLD support requires PO
(Performance improvement for bootstrap invocation)
- PO can get page mapped 4K at a time for better performance
- Common reentrancy model with C/C++ requires PO
- XPLINK requires PO and will be used for AMODE 64
Having said all that there are a couple of solutions to the problem of shared PDSE datasets across SYSPLEX boundaries.
One way is to not do it anymore, by using multiple copies of the dataset as PDSE for each SYSPLEX.
If PDS load libraries are shared across SYSPLEX boundaries today, in order to move to PDSE load libraries, customers can use a master-copy approach
- One SYSPLEX can be the writer/owner of master PDSE load library (development SYSPLEX)
- When PDSE load library is updated, push the new copy out to production SYSPLEX systems with XMIT or FTP
- The other SYSPLEX systems would then RECEIVE the updated PDSE load library
Another way is to request from IBM DFSMS and z/OS that IBM extend the capabilities of PDSE datasets to allow them to be shared
across SYSPLEX boundaries. To do this, please submit a requirement against PDSE and z/OS operating system.