PL/1 Pointer support creating CICS Business Events

This requirement has been re-assessed. It is not likely that this will be implemented in the next 12-24 months and so it is being declined at this point. The requirement will be kept in the RFE system and might be reassessed in the future. You also have an opportunity to resubmit in twelve months time if you wish it to be reconsidered then.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

Any application developed on the Install/1 architecture in the mid 90s would likely need this capability and would likely need filtering based on offsets as well as capture.

Actually, it's even worse than that as the areas that are pointed to contain tables of messages, and one may need to trigger an event if any of those table entries contain a particular message. However, it may be possible to handle this (with some overhead presumably) by scanning an area for any occurrence of a string within the table.

Another point is that it may be necessary to capture multiple areas pointed to by multiple pointers.

E.G. program A links to program B, passing 8 pointers (ptr0-ptr7, for simplicity). Emit an event if A links to B and the string "MSG12345" appears somewhere in the 1400 bytes at ptr3. If emitting an event, capture x bytes at ptr1, y bytes at ptr 3, and z bytes at ptr 6.

1.Ian J. MitchellDec 21, 2012 11:11 AMSo what we're talking about here is extending the ability to examine and capture data at a capture point to data pointed to by fields in the data area associated with the command ("indirect data") - specifically pointed to by addresses in the commarea given on an EXEC CICS Link command.

It would be nice to know whether they require both the ability to filter on the contents of pointed-to data areas and to capture those contents - I could imagine the sizing being different (even if only from the testing point of view) if they did not need to be able to specify filter predicates including indirect data and only need to include it in the event data. 2.Andy WharmbyJan 3, 2013 4:06 PM From a brief discussion myself and Catherine had with representatives of Danske Bank at the recent CAF in Hursley they were only looking to CAPTURE indirect data.

While adding runtime support to capture indirect data should be relatively straightforward  adding filtering support will more than double the changes required in the runtime
as we would need to code new model filter predicates for the new data types (ptr and ptr64) we would need to add. 3.Ian J. MitchellJan 3, 2013 4:24 PM A crisp proposal with just the bare minimum function that they need should be the next step (probably just ptr(31)) to get agreement on what we would consider doing (i.e. no commitments!)  4.Andy WharmbyJan 4, 2013 10:36 AM I have taken a closer look at the code and I take back what I said in comment 2 about adding filtering support; it will be much more than double the
effort of adding capture support

We will need to either modify each of the current 13 model predicates for COMMAREA data; one for each data type we currently support; or create new
versions of each to support indirection. Same again for CONTAINER. So changes to 26 model predicates or 26 new model predicates to write. Which ever
we do this increases dev and test effort by many orders of magnitude over just supporting capture. Also as the models are in ASM so this will reduce
list of developers who could pick up the work to implement any change.

Adding capture should be < 50 lines of PLX code in one refstep in DFHECEC.


To keep changes to a minimum in  runtime I suggest we go back with a proposal to support CAPTURE only of data via 31 bit pointer indirections in COMMAREA and CONATINER. 

We could minimize changes in Explorer by proposing that we DO NOT support pointer types in imported data structures, i.e user will have to
figure out the offsets and lengths themselves.

@catherine_moxey@uk.ibm.com
Catherine, During the brief discussion we had with Danske I believe they said they are already working out offsets/lengths by hand anyway due
to problems using the imported data structures functionality in the Event Binding editor with their data structures.Is this your recollection
or is my memory playing tricks !






5.John TillingJan 7, 2013 10:20 AM Andy, it would be worthwhile hash publishing a comment on what you are proposing and changing the state to More Information Required to send it back to Marianne to get feedback from the customer. 6.Catherine MoxeyJan 7, 2013 10:47 AM Andy and I discussed our recollection of the customer requirement.  As suggested in comment 5, we should publish a simple proposal and get feedback on whether that will meet the customer's needs.  However, I suspect they would really want to filter on the indirect data, and although I think they might be hardcoding offsets in the PoC, they might prefer to import copybooks in the future (even if it means editing the copybooks a bit to meet the restrictions). 7.Ian J. MitchellJan 7, 2013 11:04 AM I'm beginning to wonder whether there might be a case for offering an option for customers to code filters and collection routines for requirements like this. Declarative is fine while things are simple. Just mentioning it so we can shoot it down!  8.Andy WharmbyJan 7, 2013 1:58 PM

To enable us to scope/size this requirement so it can be considered for possible inclusion in a future release of CICS TS could you please let us
know whether Danske Bank need the ability to both filter on and capture indirect data or whether they just need the ability to capture the indirect
data in emitted events ? . That is do they need to refer to this indirect data when defining Application Data predicates (see the Filtering tab in
CICS Event Binding Editor) to control when events are to be emitted, e.g.only emit an event if the character string at offset X in the control block addressed by a pointer at offset Y in the COMAREA equals "ABC" ? 9.Hursley RFE Bridge IDJan 21, 2013 6:15 AM Marianne Heltborg wrote:

In the PoC where we discovered this issue, we tried to do both. So the requirement is for both. But if it will be a 2 step implementation, we could probably do the filtering in IBM Business Monitor, but then again, we would capture more data than actually needed to be able to do that. 10.John TillingJan 23, 2013 3:58 PM #publish
The two step implementation will be considered separately. These are candidates for inclusion in a future release. 11.Andy WharmbyJan 28, 2013 10:35 AM 2 EPIC's raised to cover this requirement as follows

EPIC 64680: Event Processing: Capture of data indirectly addressed by pointer in COMMAREA or CONTAINER
EPIC 64686: Event Processing: Event filtering using data indirectly addressed by pointer in COMMAREA or CONTAINER