I need to pass multiple versions of unique user data to the same MAI application without the need of users having to do this manually in their Logon Request field for the application. Can this be done?
Article ID: 42240
Updated On:
Products
Issue/Introduction
Question:
I need to pass multiple instances of unique user data to the same MAI application without the need of users having to do this manually in their Logon Request for the application. Can this be done?
Answer:
Yes! Multiple DEFLOGON definitions can be created for the same APPLID with different Session IDs, each referencing unique user data to be passed to the application.
First let's have a look at the basic format for the DEFLOGON command used to define an application session to Solve:Access:
DEFLOGON INPUT=session_id_name APPL=vtamappl DATA=INPUT|INPUT1|NOEASINET|userdata DESC=session_description
I mentioned that the above is a basic format because there are a total of 18 parameter fields possible for the DEFLOGON command. Let's keep it simple for the sake of describing the concept we're trying to present. The parameters shown above are self explanatory except for DATA. There are 4 entries possible for the DATA field described below:
1. DATA=INPUT - pass the entire Logon Request string from the user's Session Definition panel for the application. A user can define a logon request string by entering an M (modify) or a U (update) next to a Session ID in their MAI Primary Menu (session list). A common example of a Logon Request is something like:
CICSA &USERID &USERPW
The first word of the Logon Request string is always the Session ID that points to the corresponding DEFLOGON entry for the application. Variables &USERID and &USERPW contain the user's ID and password they used to log into the Solve:Access region. It is not common to pass the entire Logon Request string because there is usually no need to pass the Session ID (CICSA) to the application, but rather just the user ID and password or any other user data required.
2. DATA=INPUT1 - pass the user's Logon Request string to the application excluding the first word which is the Session ID. This is the most commonly used format, as it starts the session to CICSA and only passes the user ID and password to the application.
3. DATA=NOEASINET - Not related to this discussion, but if this is a session pointing to another Solve:Access product region, it indicates that the Easinet front-end procedure should be bypassed.
4. DATA=userdata - This is the format to be used if we want to pass multiple instances of unique user data to CICSA via multiple DEFLOGON entries without need of the user manually entering it in their Logon Request field for the application. If the user data contains spaces, then it must be enclosed in single quotes.
So, let's set up a scenario continuing on with our CICSA example. The applid for CICSA is A03CICSA. We need to give users three CICS selections in their session list that will log them directly into transactions TRN1, TRN2 or TRN3 available from CICSA. We'll do this by creating three DEFLOGON entries with separate Session IDs each pointing to the same A03CICSA applid with unique user data as follows:
DEFLOGON INPUT=CICATRN1 APPL=A03CICSA DATA='&USERID &USERPW TRN1' + DESC=CICSA Production TRN1DEFLOGON INPUT=CICATRN2 APPL=A03CICSA DATA='&USERID &USERPW TRN2' + DESC=CICSA Production TRN2DEFLOGON INPUT=CICATRN3 APPL=A03CICSA DATA='&USERID &USERPW TRN3' + DESC=CICSA Production TRN3 S or /=Select L=Logon H=Hide U=Update M=Modify C=Cancel ?=Action List---ID--- Status Application CICATRN1 <-> CICSA Production TRN1
If the user selects CICATRN1, they will be logged into A03CICSA passing their user ID, password and the TRN1 transaction, selecting CICATRN2 will log them into the TRN2 transaction and so on.
Additional Information:
The complete description of the DEFLOGON command and associated parameters can be found here:
Environment
Component:
Feedback
