Application entry point identification

We have assessed this requirement. We have no current plans for this to be implemented and so this requirement 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

This is a candidate for a future release. It will not be part of the current release under development.

Hi dear CICS devt,
This seems to be something acceptable ;O)
The set of predefined entrypoint enforces a managemet point, I like the idea. Adding/deleting/updating an entrypoint is not trivial and so the fact that is requires an admin/deploy step is definitly acceptable.
So we consider this would satisfy this requirement.

We must know all the operations supported by an Application up front not only for configuring Policy enforcement today but also for other future cloud capability. The question is how we decide at runtime which operation is being called. With a PROGRAM entrypoint this is implicit. The solution in this scenario where the LINK is to a shared PROGRAM and there is just a COBOL call to the specific entrypoint would be to allow a URM, perhaps using EP, to choose from a set of operations configured in the Application. That way there are no surprises.

When initially creating the application the developer must understand and declare the supported operations. When updating the application they must again update (add/remove) the set of operations. Does this satisfy the requirement?

Hi Hursley,
From a technical point of view changing a CALL to a LINK is trivial. From a customer production point of view this is not so simple. This implies regression tests and funding as it is implies code modification.
Also some customers put a high focus on CICS<>Batch COBOL code transparency, and so avaoid LINKs. We (you and I) may argue on that, but it is a matter of fact.
Also I discussed that with my Guide group and many of these customers use the pattern of more or less generic programs which use private aplication header fields in the message (likely a Commarea) to identify the operation/application. And then reuse more neutral "Cobol Services programs". This RFE targets those customers.
Also a URM is likelly not ASM, while a Glue would be.
Least we have a nice Event technology which is able to capture the LINK message, may be a good start to put the operation in the open..
Last, the native CICS Webservice support like to expose single operation services hich make life easy to use the URIMAP or WEBSERVICE as the entry point name. With multi-operation services this makes life more difficult.

Hi Hursley,
From a technical point of view changing a CALL to a LINK is trivial. From a customer production point of view this is not so simple. This implies regression tests and funding as it is implies code modification.
Also some customers put a high focus on CICS<>Batch COBOL code transparency, and so avaoid LINKs. We (you and I) may argue on that, but it is a matter of fact.
Also I discussed that with my Guide group and many of these customers use the pattern of more or less generic programs which use private aplication header fields in the message (likely a Commarea) to identify the operation/application. And then reuse more neutral "Cobol Services programs". This RFE targets those customers.
Also a URM is likelly not ASM, while a Glue would be.
Least we have a nice Event technology which is able to capture the LINK message, may be a good start to put the operation in the open..
Last, the native CICS Webservice support like to expose single operation services hich make life easy to use the URIMAP or WEBSERVICE as the entry point name. With multi-operation services this makes life more difficult.

Hi,
I have received a mail requesting more information on this rfe...but...
What additional information do you need ?
Cheers. Régis.

By selecting PROGRAM as the first supported means of declaring an operation (and hence establishing a CICS Application context) we hope to allow a large proportion of existing applications to be supported by CICS cloud. Additional scenarios would also be covered should we support TRANSACTION, URIMAP and WEBSERVICE (where we borrowed the term "operation") as we have suggested in various F2F conversations. However, there will be cases that require some small amount of refactoring.

In this situation changing the existing COBOL call to an EXEC CICS LINK would provide the opportunity to declare one or more operations. While this will incur a small performance overhead it's probably no more than would be required to invoke a URM. It also has the benefit of keeping the operation declaration in the open where it can be used in CICS Explorer and other tooling rather than hiding it in a piece of ASM separately lifecycled into each CICS Region.

Thoughts?