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.
IBM Enterprise COBOL for z/OS is a continuous delivery offering, and aims to satisfy the needs of a rapidly evolving market segment. Product strategy evolves and requirements are continuously evaluated against that strategy. This RFE has recently been reappraised against the wider product strategy and does not fall into IBMs delivery plans for the next 12 month. Whilst this RFE might be valid and we might look to deliver longer term, this RFE is being rejected at this time. The requirement will be kept in our internal RFE backlog and might be reassessed in the future.
Thank you for the reply. We are evaluating your response.
sorry I posted it twice.
A new special register JSON-ERROR-LOCATION or JSON-ERROR-OFFSET or something similar would be fine for exception conditions.
However, this is a little more complicated than a simple single value register.
There are non-exception conditions that I would like to also know the offset on. These are reported through JSON-STATUS and are warnings. There can be multiple of them.
A single value register for non-zero JSON-CODEs is a good start and I would accept that as an initial delivery.
It would be nice if this were available in V6.2 when it becomes available.
However, a more robust solution is needed to be able to know the offset for multiple non-exception conditions and multiple occurrences of each. We would need to know the offset for each condition occurrence, and be able to know which condition relates to which offset. Some of the non-exception conditions are much more serious to us and we need to treat them like exception condition and know where in the JSON text the condition occurred.
One possible solution:
A special register table named JSON-CONDITIONS
JSON-CONDITIONS could be implicitly defined similar to:
01 JSON-CONDITIONS.
03 JSON-CONDITION
OCCURS 1 TO UNBOUNDED
DEPENDING ON JSON-COND-COUNT.
05 JC-MSG-ID PIC X(8). *> ex. 'IGZ0328I'
05 JC-OFFSET PIC 9(9) COMP-5.
05 JC-MSG-txt PIC X(256).
*> Complete msg text as it would normally appear in LEMSG
And an additional special register for the number of messages:
01 JSON-COND-COUNT PIC 9(4) BINARY.
Populating these special registers could be done always, or controlled by extending the WITH DETAIL phrase of the JSON PARSE statement
WITH DETAIL TO JSON-CONDITIONS
This would suppress messages in job output, but write them to the special register instead.
A new special register JSON-ERROR-LOCATION or JSON-ERROR-OFFSET or something similar would be fine for exception conditions.
However, this is a little more complicated than a simple single value register.
There are non-exception conditions that I would like to also know the offset on. These are reported through JSON-STATUS and are warnings. There can be multiple of them.
A single value register for non-zero JSON-CODEs is a good start and I would accept that as an initial delivery.
It would be nice if this were available in V6.2 when it becomes available.
However, a more robust solution is needed to be able to know the offset for multiple non-exception conditions and multiple occurrences of each. We would need to know the offset for each condition occurrence, and be able to know which condition relates to which offset. Some of the non-exception conditions are much more serious to us and we need to treat them like exception condition and know where in the JSON text the condition occurred.
One possible solution:
A special register table named JSON-CONDITIONS
JSON-CONDITIONS could be implicitly defined similar to:
01 JSON-CONDITIONS.
03 JSON-CONDITION
OCCURS 1 TO UNBOUNDED
DEPENDING ON JSON-COND-COUNT.
05 JC-MSG-ID PIC X(8). *> ex. 'IGZ0328I'
05 JC-OFFSET PIC 9(9) COMP-5.
05 JC-MSG-txt PIC X(256).
*> Complete msg text as it would normally appear in LEMSG
And an additional special register for the number of messages:
01 JSON-COND-COUNT PIC 9(4) BINARY.
Populating these special registers could be done always, or controlled by extending the WITH DETAIL phrase of the JSON PARSE statement
WITH DETAIL TO JSON-CONDITIONS
This would suppress messages in job output, but write them to the special register instead.
Hi, we do agree this is a valid RFE. Would updating a special register be a sufficient solution?