Modernize DFHPLT - Transition away from assembled table

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.

This is a long overdue enhancement. Our shop has used both a VSAM file based generic PLT, and an extrapartition TDQ based version (reading from a parmlib). Both have the drawback that early PLTPI programs have to go in the "real" PLT--leading to possible multiple flavors of the generic PLT, depending on how many such combinations are in play.

Also, would like to see the enhanced version incorporate a replacement for INITPARM--which currently resides in SIT overrides, and therefore is effectively "decoupled" from the PLT. The INITPARM replacement should both alleviate the current 60-character limit, and allow the SAME PLT program to be invoked multiple times with different parms (not possible with the current INITPARM, other than by cumbersome aliasing).

I see others were more sophisticated than I, but I've used a single user program in PLTPI Stage 2. User program loads an Assembler table containing instructions for things to do at PLT, such as which APPLID this is for, link to another user/vendor PLT program, or execute a TRANSID optional with START options and the INTERVAL at which to START. Same thing for PLTSD. So my less sophisticated method still requires an Assemble of the table, rather than using a better choice of SYSIN or seq. terminal. But I like the idea of CSD-type stuff, just like all the other resources (e.g. terminals) that have been moved there.

This is a candidate for a future release

In various forms, sites have created their own variations. I concur with 2 aspects of the previous comment:
- a provision for parameters to be passed, and
- a product standardized approach.

I am not sufficiently familiar with JSON to opine on that at this time.

So, a JSON file in zFS ? Would need some appropriate security controls. Thinking of JSON in case there's a desire for parameters to be passed to the programs.

(Just floating some ideas... You could do this today for your own stuff, but it would be better if the product standardised a more modern approach.)