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
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online