Provide an XPI to inquire on Feature Toggles

This RFE is satisfied by CICS Transaction Server for z/OS V5.5 which is GA today 14th December 2018.

This RFE is satisfied by CICS Transaction Server for z/OS V5.5 which is announced today 2nd October 2018 and which has a planned availability date of 14th December 2018.
For more information see the CICS TS V5.5 announcement letter https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/2/897/ENUS218-352/index.html&request_locale=en

This is something we would like to address. The RFE is being moved into 'Planned for Future release' status. Please note:
IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

The case you are ignoring is the Systems programmer wishing to compare the current values for all toggles on all of the individual CICS regions across the CICSPlex. The scenario of examining the ZFS data is not 'runtime' and might very well be different than what is actually executing at the time a SYSPROG is looking to resolve an issue.

Your answer to that is to force the SYSPROG to look at the JOBLOG for each individual CICS region. This means they will not have a single system image of the CICSPlex configuration. In fact, with what you are suggesting as responses to your use cases, they cannot even generate some kind of report other than by consolidating their CICS JOBLOGs (or DUMPs).

That being the case, even CPSM won't be able to help them to see what is running across the CICSPlex (as it will not have access to an SPI browse).

The basic inquire function in the XPI and SPI is to provide a simple and fast method for programatically making decisions in application or vendor code.

The use case you are describing would be an operator use case of displaying of all toggles in a cicsplex.
This can be done programmatically by getting the value of the SIT parm USSCONFIG. The feature toggle files are in that directory
in the files groupfeaturetoggle.properties and featuretoggle.properties. Therefore this function is already available on 5.4.
Obviously it would require the tool to have read permission for the files in the USSCONFIG directory.

Another use case would be where a developer or service person need to know what is on a single region
The list of toggles defined on a regions is reported on the job log in the same way as with SIT parms. The following is an extract of my job output
DFHPA1927 IYK2ZDL1 SNPRESET=UNIQUE
DFHPA1103 IYK2ZDL1 END OF FILE ON SYSIN.
DFHPA1950I IYK2ZDL1 READING FEATURE TOGGLE FILE: groupfeaturetoggle.properties
DFHPA1951I IYK2ZDL1 FEATURE TOGGLE FILE COULD NOT BE FOUND: /u/penfold/dfhconfig/groupfeaturetoggle.properties
DFHPA1950I IYK2ZDL1 READING FEATURE TOGGLE FILE: featuretoggle.properties
DFHPA1956I IYK2ZDL1 com.ibm.cics.bms.ids=true
DFHPA1956I IYK2ZDL1 com.ibm.cics.bms.ids.cicschecking=false
DFHPA1956I IYK2ZDL1 com.ibm.cics.bms.ids.action=ABEND

The same information is available in a dump.

Regarding your decision to avoid a browse function, I ask that you reconsider this.

Customers will also want to be able to simply find the state of all toggles on the system without having to specifically know which ones to look for (by name). They will be looking to their vendor products to provide that information and I would argue being able to scan ALL available TOGGLES is more desirable than having to code the specific entry into their program and then INQUIRE directly on it. Whether a vendor is reporting on the toggles and the states, or simply setting their own processing bits, they need to be able to simply scan for any available entries and their states.

Customers will also want to be able to simply find the state of all toggles on the system without having to specifically know which ones to look for (by name).

Feature toggles are intended to be temporary features in the current release;
a way of delivering new function quickly without impacting users who don't
need the new function. It is the intention that toggled features are either
enabled by default in the next release, or a configuration option is provided.

The anticipated use case would be for a vendor product or an application
to take a decession based on whether the customer has configured a feature or not.

The list of feature toggles is in the knowledge centre
https://www.ibm.com/support/knowledgecenter/SSGMCP_5.4.0/upgrading/changes/feature-toggle-changes.html

Consequently I can't see the use case for a browse.

An SPI INQUIRE is however something that I can see would be easier than just the XPI.

It would be best if the INQUIRE TOGGLE XPI interface was implemented in the same manner as INQUIRE PROGRAM which provides the ability to INQUIRE a specific instance as well as START_BROWSE, GET_NEXT, and END_BROWSE functions (and is also exposed through the SPI).