by Ernie Malaga
You don't have to settle for a boring, ho-hum sign-on display. Add pizzazz, make it interesting!
Making modifications to the sign-on display is as easy as the proverbial piece of cake on the AS/400. All you need to customize the sign-on display is SDA and a few special instructions, since the source code is included with the operating system. Having customized the sign-on display several times, I'd like to pass along a few important details.
The Source DDS
First, you will find the source DDS of the sign-on display as member QDSIGNON in source file QDDSSRC in QGPL. Before you fire up SDA and begin making the changes you ve been dreaming about since your system was installed, let me give you a few warnings:
1. Never change this IBM-supplied source member. Begin by copying the source member into one of your libraries. Whatever changes you make, be absolutely sure to write them in your own copy of the source member. This will save you a lot of headaches if you happen to bungle the original source code irreparably.
2. Never give your version of the sign-on display the IBM-supplied member name QDSIGNON; call it anything else you wish, but not that. This will give you additional assurance that the system will never use the wrong display file.
3. If you happen to sort the fields by image position (a neat feature of SDA which you may be tempted to use), be absolutely sure that field UBUFFER, which has attribute "H" (hidden field) is the last field in the DDS. If it is not, move it to the last statement of the DDS.
4. Never change the relative positioning of the data fields in the DDS (even though you may change their relative row/column positioning). Never change the length of any data field or the conditioning indicators, either.
So, What Can I Change?
Even though the warnings given above may seem restrictive, in reality they re not. You can change quite a bit. Let me give you a few ideas.
1. You can use color or special attributes anywhere you wish. This alone can change the sign-on display from a dull, boring display to something more attractive.
2. You can add DSPATR(ND PR) to input/output fields you do not use, such as the program name, menu name, and library name. DSPATR(ND PR) will make these fields non-display and protected. The captions for these fields can be either deleted or made DSPATR(ND).
3. Even though you cannot change the relative positions of the fields in the DDS, you can still change their relative positions in the screen format by modifying the row and column numbers. So you can end up reversing the order of the User ID and Password fields, for instance, provided that, in the DDS, the description of the User ID field precedes the description of the Password field.
Step-by-Step Instructions
For your convenience, you can follow these steps for a successful customization of the display file. We will use the names MYLIB and QDDSSRC in the following:
1. Determine which library will contain your version of the sign-on display, and which source physical file will have your copy of the source DDS. We will use the names MYLIB and QDDSSRC in this example.
2. Copy the source DDS supplied by IBM into the source physical file you have selected:
CPYSRCF FILE(QGPL/QDDSSRC) TOFILE(MYLIB/QDDSSRC) FROMMBR(QDSIGNON) + TOMBR(MYSIGNON)
This will copy the source DDS to member MYSIGNON.
3. Run STRSDA. Then work with member MYSIGNON in MYLIB /QDDSSRC.
4. Let SDA create the display file.
5. To assign the new display file to a subsystem (e.g., QINTER), you must end the subsystem first, change its description, and then start the subsystem again:
ENDSBS SBSD(QINTER) CHGSBSD SBSD(QINTER) SGNDSPF(MYLIB/MYSIGNON) STRSBS SBS(QINTER)
If you need to reset QINTER to the original sign-on display, you can simply assign QINTER the old sign-on display name: QUSRSYS/QDSIGNON.
More Advanced Stuff
Earlier I mentioned that field UBUFFER in the sign-on display must remain at the end of the DDS. This is a hidden field, 128 bytes long, which can be converted into an input/output field and placed anywhere on the sign-on display; whatever is typed in this field can be retrieved by your application programs.
In addition, this field can be split into several fields as long as the total length remains 128; the resulting fields can be input/output or hidden. Let s see how we could use this feature.
Suppose that your organization is divided into two companies, each one having a separate database in your AS/400, and that your Accounting personnel must have access to both databases. Your database files are located in different libraries depending on the company.
To solve this minor problem, you could train your users to change the current library to the one that contains the database files for the correct company; this would involve running the CHGCURLIB command and remembering the name of the library. An easier way would be to create a display file that would prompt the user immediately after sign-on.
To illustrate, we could handle the situation by creating a different sign-on display for the Accounting department, provided that this department runs in a separate subsystem, which is not difficult to set up. Let s assume that this Accounting subsystem is called ACGQINTER (Accounting QINTER). The sign-on display could look like 1. Field UBUFFER in the DDS would have changed, as shown in 2.
To illustrate, we could handle the situation by creating a different sign-on display for the Accounting department, provided that this department runs in a separate subsystem, which is not difficult to set up. Let s assume that this Accounting subsystem is called ACGQINTER (Accounting QINTER). The sign-on display could look like Figure 1. Field UBUFFER in the DDS would have changed, as shown in Figure 2.
Once you create this sign-on display, the Accounting staff would select the database by keying in a company code (A or B) right at the sign-on display; this value goes into the variable COMPANY in the DDS of the display file.
Notice that the total length is still 128. The initial program for the Accounting department would then have the code shown in 3.
Notice that the total length is still 128. The initial program for the Accounting department would then have the code shown in Figure 3.
The sign-on information is retrieved by receiving the first message (MSGKEY(*TOP)) from the external program message queue, provided that the message received is CPF1124. In its message data, CPF1124 contains the entire 128 bytes of sign-on data, beginning on byte 133. This RCVMSG retrieves the contents of UBUFFER or whatever fields UBUFFER has been split into. The CHGVAR command that follows uses the %SST function to extract the contents of UBUFFER from the message text retrieved. ER. This always begins on byte 133.
Is There a Limit?
Before writing this article, I experimented extensively with this technique, and found the results incredible. I simply could not resist the temptation to customize (once again!) our sign-on display. As a result, ours now has three optional parameters and even a command line! The optional parameters control which steps of our initial program are executed; the command line is provided as a convenient shortcut for experienced users.
This technique can be expanded until the sign-on display becomes as cluttered as the main panel of a badly-designed application program. Resist the temptation, then, of adding too many fields to the sign-on display.
Customizing the Sign-on Display
Figure 1 Sign-on display
Figure 1: Sign-on Display Sign on System SYSNAME Subsystem ACGQINTER Display ACGDSP01 + Type information, press Enter. (Your organization s logo in here) User ID..................: __________ Password.................: __________ Company Code.............: _ (A or B)
Customizing the Sign-on Display
Figure 2 DDS for Sign-on screen
Figure 2: DDS for Sign-on Screen From this: ....1.... ....2.... ....3.... ....4.... ....5.... ....6.... ....7.... A UBUFFER H ...to this: ....1.... ....2.... ....3.... ....4.... ....5.... ....6.... ....7.... A COMPANY 1A TEXT( COMPANY CODE ) A VALUES( A B ) A UBUFFER 127 H
Customizing the Sign-on Display
Figure 3 Initial program code
Figure 3: Initial Program Code PGM DCL VAR(&MSGDTA) TYPE(*CHAR) LEN(260) DCL VAR(&MSGID) TYPE(*CHAR) LEN(7) DCL VAR(&UBUFFER) TYPE(*CHAR) LEN(128) DCL VAR(&COMPANY) TYPE(*CHAR) LEN(1) RCVMSG PGMQ(*EXT) MSGTYPE(*NEXT) MSGKEY(*TOP) + RMV(*NO) MSGDTA(&MSGDTA) MSGID(&MSGID) IF COND(&MSGID *EQ CPF1124 ) EXEC(DO) CHGVAR VAR(&UBUFFER) VALUE(%SST(&MSGDTA 133 128)) CHGVAR VAR(&COMPANY) VALUE(%SST(&UBUFFER 1 1)) ENDDO IF COND(&COMPANY *EQ A ) THEN(DO) CHGCURLIB CURLIB(COMPANYA) ENDDO ELSE CMD(DO) CHGCURLIB CURLIB(COMPANYB) ENDDO . . . ENDPGM
LATEST COMMENTS
MC Press Online