Skip to Main Content
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
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. 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.

Status Not under consideration
Workspace PL/I Compilers
Created by Guest
Created on Sep 19, 2013

New EPLI INDEX-like builtin

For ad-hoc lookups it is possible to store data, padded with suitable non-occuring fillers in a VAR CHAR variable. Checking if the data is present can subsequently be done using INDEX(haystack, needle) / POS(needle, haystack)

However, both of the above will do a linear search through "haystack".

Assuming that there is a need to look up a 4-character needle "BAD_" in the haystack and the filler is '@', and the haystack contains 'AAA _@AQ__@BCD_@QWER@BAD_@', the current INDEX builtin do a scan starting at every position of the haystack, although the presence on non-occuring '@' fillers would allow the scan to start only at positions 1, 6, 11 etc, in a similar vein to the fact that incrementing typed pointers increments them with the size of the underlying type.

Note that the use of a non-occuring filler will remove the need to check that the value returned by INDEX/POS needs to be checked for a proper multiple plus 1 of the size of the needle! It is required to prevent false matches of needles on consecutive earlier stored needles in the haystack, i.e. a haystack containing "AAABBB" with a needle "ABB".

Idea priority Low
  • Guest
    Reply
    |
    Oct 19, 2015

    while this might be a useful function, it could be written by a user with existing PL/I language. Moreover, there are many more pressing requirements, and hence since we are not likely to do this in the near future, it is fairer in terms of setting expectations for this to be rejected

  • Guest
    Reply
    |
    Sep 14, 2015

    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 - PL/I Compilers

    For recording keeping, the previous attributes were:
    Brand - Rational
    Product family - Design & development
    Product - PL/I Compilers

  • Guest
    Reply
    |
    May 20, 2014

    Rather than creating a new builtin, as suggested initially, another option would be to enhance the existing INDEX() builtin with a fourth parameter (that defaults to 1) that tells the builtin that the search should use discrete intervals of "x" characters, i.e.

    index(haystack, needle,1,4)

    would only compare needle to haystack at the discrete locations of 1, 5, 9 etc, in essence doing nothing more than a

    match = '0'b;
    do i = 1 by 4 to length(haystack) until(match);
    match = (substr(haystack, i, 4) = needle);
    end;

    Easy to program in normal PL/I, but as a builtin the resulting code would quite likely rather more efficient.

  • Guest
    Reply
    |
    Oct 10, 2013

    this could have benefit in some situations