IBM Z Software
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).
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
Hi Michael, thanks for the response. We shall go ahead and close this RFE as you mentioned. Yes, feel free to open a new one if you find things are different during your future testing. Thanks!
Hi,
I have gone through the whole old PMR again.
The original scenario was with legacy COBOL and there (in EOV SB37 processing) the CLOSE in the decarative itself failed driving the declariative again, thus creating a loop.
I had no chance to test this with COBOL V5+, but your L2 did and found that the CLOSE in the declarative was successful. The loop only ensued in their test if the application was retrying to access the file. So yes, this loop could be avoided by setting a flag in the declarative, which the application's main code and future declarative invocations cold test to avoid the loop.
Still I am now wondering why LE dev had encouraged me to open this RFE. They must have believed to protect against this loop (possible without controlling flag of the application) is a benefit. As the loop as it was seen in the underlying PMR would obviously not happen with COBOL V5+, I can understand that your are not willing to invest efforts. So I agree with declining this RFE. The future will show if such a loop will show up in our shop again under COBOL V5+.
Kind regards, Michael Pfannkuche
Hi,
The reason why RFE 129586 was rejected was because the program logic that was described in the RFE appeared to be more of an infinite loop (instead of a recursion)
that can be overcome by altering the user program logic.
From the description, it sounds like the declarative is executed, then the user code in the declarative forgets to set a flag somewhere indicating the file is now closed,
then the program exits the declarative processing and returns to the user application and then incorrectly performs a write to the file
(because the program didn't set and/or check some flag) and then the declarative gets called again, etc. Can you please confirm if this is what is really happening in your program?
Thanks.