Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

User Exit - Structure Fields

Former Member
0 Likes
548

How Do Everyone,

I am adding some code to the user exit EXIT_SAPFP50M_002. This calls the

module ZXPADU02 which is activated for PAI when the HR screen PA30

has been amended. The problem I am having is that I need to refer to

one of the screen fields Q0088-QWKDA which is based on the structure

Q0088. When I run debugger and put a breakpoint in ZXPADU02 I cannot

reference the field Q0088-QWKDA as it does not exist.

Can anyone tell me what I need to do in order to access this field??

Many thanks

Andy

2 REPLIES 2
Read only

Former Member
0 Likes
467

Hi,

Refer th below link:

https://forums.sdn.sap.com/click.jspa?searchID=3719578&messageID=1452134

<b>Reward points</b>

Regards

Read only

Former Member
0 Likes
467

hello Andy

The security user exit in the listener process follows the same style as do existing CICS user exits. Further details on these are available in the CICS Administration Guide and TXSeries for Multiplatforms Administration Reference.

When writing the user exit, take note of the following restrictions and considerations:

The user exit must be written in C.

The user exit must be reentrant.

Threads must not be switched within the user exit.

Multiple copies of the user exit can be invoked simultaneously.

The integrity of the CICS listener must not be damaged.

The user exit must not use EXEC CICS commands.

The supplied user exit prototype must be included in the user exit program.

The supplied exit-specific structure cics_UE115052_t must be included in the user exit program.

The supplied cics_UE_Header structure must be included in the user exit program.

The header structures and function prototypes are defined within the include file cicsue.h.

The entry point for all user exit programs is cics_UE_entry.

The user exit is called with two parameter structures:

A pointer to the cics_UE_Header_t parameter list

A pointer to the exit specific parameter list cics_UE115052_t

Care is required if using system calls from the user exit, because they can block execution of other listener threads.

No specific facilities are provided for handling errors in user exit programs. Any exceptions that are generated are caught, and the exit is disabled.

The exit must set a return code that is defined as being supported for the user exit. Otherwise, the exit program takes the default action, which can result in the user exit's being disabled.

No facilities are provided for accessing CICS resources within a user exit program.

Version numbers are provided on the two structures that are provided to the user exit. You must ensure that the user exit program checks the version number and uses the correct version of the structures.

A task work area is provided for sharing between user exit calls within the listener. You must ensure that no conflicts exist in the use of fields within this work area. The work area is initialized to zeroes before the first user exit call.

The length of the task work area is fixed at 128 bytes and cannot be changed.

Signal handlers must not be included in the user exit program.

The user exit is called with shared memory attached. You must ensure that the user exit code does not compromise the integrity of the CICS region.

The semistatic method of associating exit programs with user exits, based on the UserExitNumber attribute in the Program Definitions (PD), is also used for this exit. The exit number for the IIOP Security exit is 52 and the name is UE115052.

The PD UserExitNumber attribute is used as a generic method for associating a single program with a single user exit. The association is held as a table in the region control area (RCA). A user exit is regarded as active if it has a program associated with it. A user exit is regarded as inactive if no program is associated with it in the RCA table.

This relationship is passed to new processes when they are created. The exit is permanently loaded for the lifetime of the process. The IIOP listener is always running for the lifetime of the region, which means that the user exit must be defined before the region is started; it cannot be changed during the lifetime of the region. If a problem occurs during the loading of the exit at region startup, the exit is disabled for the lifetime of the listener.

The user exit UE115052 is invoked at the following times:

Listener startup (UE_IIOP_INITIAL or UE_IIOP_SSL_INITIAL)

Listener termination (UE_IIOP_TERMINATE or UE_IIOP_SSL_TERMINATE)

Listener IIOP request method invocation (UE_IIOP_REQUEST or UE_IIOP_SSL_REQUEST)

shows the structure that defines the security exit:

IIOP security exit data structure

/* Constants */

#define cics_UE115052_VERSION 1 /* All version number start at 1 */

/* Data Types */

typedef enum UE_IiopType /* Reason for UE invocation */

{

UE_IIOP_INITIAL,

UE_IIOP_REQUEST,

UE_IIOP_TERMINATE,

UE_IIOP_SSL_INITIAL,

UE_IIOP_SSL_REQUEST,

UE_IIOP_SSL_TERMINATE

} cics_UE_IiopType_t;

typedef struct

{

cics_ushort_t UE_Version;

cics_UE_IiopType_t UE_IiopType;

cics_ubyte_t *UE_IiopBufptr;

cics_ulong_t UE_IiopBuflgth;

cics_char_t *UE_IiopBodyptr;

cics_ulong_t UE_IiopBodylgth;

cics_char_t *UE_IiopClassptr;

cics_ulong_t UE_IiopClasslgth;

cics_char_t *UE_IiopMethodptr;

cics_ulong_t UE_IiopMethodlgth;

cics_char_t *UE_IiopPrinptr;

cics_ulong_t UE_IiopPrinlgth;

cics_ulong_t UE_IiopIpaddress;

cics_ushort_ UE_IiopIpport;

cics_ubyte_t UE_IiopFlag;

cics_ulong_t UE_IiopMinor;

cics_char_t UE_IiopUser[cics_UE_USER_MAX+1];

cics_char_t UE_IiopTran[cics_UE_TRAN_MAX+1];

} cics_UE115052_t;

cics_UE_Return_t cics_UE115052(cics_UE_Header_t *UE_Header,

cics_UE115052_t *UE_Specific);

Descriptions of the variables taht are in this user exit data structure follow:

The UE_version field is the version number for this structure and takes the value that is defined in cics_UE115052_VERSION. It is advisable to check this in user exit programs to ensure that the version number that is passed when the user exit is called is the same as that which is contained in the cicsue.h file that was used when the program was generated. If a mismatch is detected, the contents of fields are unpredictable. The user exit program must be regenerated with the correct version of cicsue.h.

The UE_IiopType field identifies the reason why the user exit was invoked. This takes the following values:

UE_IIOP_INITIAL

The exit was called by the non-SSL listener at startup.

UE_IIOP_REQUEST

The exit was called by the non-SSL listener for an IIOP request.

UE_IIOP_TERMINATE

The exit was called by the non-SSL listener at region termination.

UE_IIOP_SSL_INITIAL

The exit was called by the SSL listener at startup.

UE_IIOP_SSL_REQUEST

The exit is was called by the SSL listener for an IIOP request.

UE_IIOP_SSL_TERMINATE

The exit was called by the SSL listener at region termination.

The UE_IiopBufptr field is a pointer to the IIOP request message buffer as received by the IIOP listener from the network. The buffer pointer starts with the IIOP value GIOP.

The UE_IiopBuflgth field is the length of the IIOP request message buffer as received by the IIOP listener from the network. It corresponds to the sum of the size of the IIOP message header plus the message size value from the IIOP message converted to this machine's byte order.

The UE_IiopBodyptr field is a pointer to the request body that is in the received IIOP message. This cannot be a pointer to the first element that is in the body because it possibly is a pointer to an alignment pad that is before the first element in the body. Only the marshaler of the elements that are in the body knows whether a pad exists. The user exit program uses the information that is stored in the UE_IiopBodyptr variable, the UE_IiopBufptr variable, and its knowledge of the method signature to determine whether a pad exists at this location.

The UE_IiopBodylgth field is the length of the request body that is in the received IIOP message.

The UE_IiopClassptr field is a pointer to the class name for the received IIOP message. The class name is determined from the object key that is in the received message.

The UE_IiopClasslgth field is the length of the class name.

The UE_IiopMethodptr field is a pointer to the method name and operation that are in the received IIOP message. The method has a null termination character.

The UE_IiopMethodlgth field is the length of the method name without the trailing null character.

The UE_IiopPrinptr field is a pointer to the requesting principal that is in the received IIOP message.

The UE_IiopPrinlgth field is the length of the requesting principal.

The UE_IiopIpaddress field is the IP address of the requesting client in the byte order of the host as a 32-bit field.

The UE_IiopIpport field is the IP port of the requesting client in the byte order of the host.

The UE_IiopFlag field is the byte order (or flags octet) from the received IIOP message. For consistency between GIOP 1.0 and 1.1, the least-significant bit indicates the byte ordering that is used in subsequent elements of the message. A value of 0 (zero) indicates big-endian byte ordering, and a value of 1 indicates little-endian byte ordering.

The UE_IiopMinor field is the field that is to return the minor code that is to be used in a Common Object Request Broker (CORBA) NO_PERMISSION system exception if the exit returns a value of E_NotAuthenticated. Currently, the ORB can return the value 0 (zero) on a NO_PERMISSION system exception.

The UE_IiopUser field is the user ID that is to be used to execute the requested method. The field is initially set to the configured listener user ID or the CICS default user ID if unset. The exit can modify this field to enable method execution under a different user ID. The modified user ID must have a user definition entry in the region database.

The UE_IiopTran field is the transaction ID that is to be used when the requested method is executed. The field is initially set to the configured listener transaction ID value or CPMI if unset. The exit can modify this field to enable method execution under a different transaction ID. The modified transaction ID must have a transaction definition entry in the region database. Standard CICS transaction and resource level checking apply to the returned transaction ID.

Return codes can be set to the following values:

UE_Normal

Initial call only.

UE_Authenticated

The request is authenticated; continue processing.

UE_NotAuthenticated

The request is not authenticated; reject request.

Any other return code setting from the UE_IIOP_INITIAL or UE_IIOP_REQUEST call is logged, and the exit is disabled for the rest of the region's lifetime. The return code setting for UE_IIOP_TERMINATE is ignored.

For UE_IIOP_REQUEST, the fields UE_IiopUser, UE_IiopMinor, and UE_IiopTran can be updated on return. Other fields can be updated. For example, the IIOP request message can be updated, because the data is not in write-protected storage. However, this practice is not recommended.