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).
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 updateson 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
Many times, in existing customers ERPs, there are fields where structured information is stored in a single big CHAR string. Usually the intent is to have a generic data carrying field in the same table, where the type of information is stored in another field, to guide parsing. A similar way to store information is seen in open systems where a generic field containing a json string variable is stored in a string field at the record level. It is a similar thing, but here with fixed plain data.
Reading the information with RPG is not a problem and efficient (just move the field in the proper DS based on the type of information) and easy for this type of thing.
Not so much with SQL (say when one needs to extract data, ETL systems, queries etc.).
So, in practice, many times I see people using a view using a lot of SUBSTRING and casting to parse the row, duplicating the effort greatly, errors etc.
So, please introduce function or a table function, like for example an hypothetic PARSE_USING(string, externalds)
where string is the string to parse
externalds the external data structure to use
A function/table function would suffice, any other functionality is provided by composition capability of the SQL engine (i.e. CROSS LATERAL JOINS subqueries etc.).
SELECT b.field1, b.field3
FROM TABLE( PARSE_USING('CY W9000001NYVZV01900 W05', 'TABWDS' )) b
where field1 and field2 are defined in the external file object TABWDS.
Do not place IBM confidential, company confidential, or personal information into any field.