This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. 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.
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 - Developer for Power Systems
For recording keeping, the previous attributes were:
Brand - Rational
Product family - Design & development
Product - Developer for Power Systems
Thank you for taking the time to explain your issue with our product. This issue would be more easily resolved by opening a Problem Management Record (PMR), since it appears to be a defect or change in behavior in the product from previous releases. For more information on opening a PMR, please see:
SR tool URL: http://ibm.com/software/support/probsub.html
I take back my comment about this not being an issue any more. I just did more testing to see and I found a senario where this issue causes problems.
I have a new connection configured with my different library list. I open a filter within this new connection and then open a member for edit. I compile the memeber and it compiles with expected references.
Now if I open a member from the original connection (just open do nothing else) and I compile the first member I opened for edit, the compile now uses the wrong references and fails to compile.
I am currently at the highlest of version 8.5 and I have not created a new connection since, so I tried it again.
I can see that my test connection loads the proper library list as I have configured it to use ( seen using the "Commands Log" of my test connection and QSYS/DSPLIBL).
I opened a member in this test connection and compile it and it compiles using the proper library list. Every thing looks like the connections are working like I would have assumed.
When I created the RFE I believe I had an issue compiling source using the proper library list, as though it actually opened using the wrong connection. Now when I open the member in the incorrectly set up connection it fails to compile when it suceeded in my test connection.
I believe this item is no longer an issue and I will re-open if I find it as an issue again.
The expanded file path for the local file storage in the workspace which is shown in the tooltip expansion text when you hover over the editor tab shows the host name, which is used as part of the path.
Multiple connections can use the same host name, so this can get confusing. Its not an accurate portrayal of which connection in those cases.
In theory, if you are trying to edit the same member through two connections, you won't be able to lock the member on the second open.
(But this breaks down if the member was in an edit session open from the previous RDP session, where the host member locks are lost when the previous RDP session was ended.)
A way to check which connection the member was opened from is to check the object lock on the host; which job is it? If you alternate opening the member between the two connections, and check the lock each time, the job number should be different between the two connections.
If its only ever opened by the first connection, then it is a defect which should be reported in a PMR. (Eg . always the same host connection job #)
If its only that the host name on the tooltip is the same, and doesn't truly indicate the connection, then that is a suitable RFE request.
(I checked on RDi 9.0 and it s the latter for me. )
Can you confirm which this is?
This RFE is consistent with our strategy and product roadmap and IBM is continuing to evaluate.