By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
There's a few things that may not help us in the long run. Do we need to override the Program/Procedure? Do we need to override the initial Menu? How about change our Current Library? All of these items aren't necessary on ALL of our screens. Always keep it the same on the console. The source for your sign-on screen has been located in QGPL under QDDSSRC for years. Let's look at that file for a moment and see what trouble we can get into!
As always, copy the original so it doesn't get mucked up while we're playing with its "twin brother."
From the above figure, look at the following edits I've already made:
A. Notice that I changed "Sign On" to "Put Something Here" -- yes -- everyone that sees the words "User ID" and "Password" are lulled into entering that information on their own -- why have "Sign on" taking up precious room we can use for something like our company name.
B. I commented out the "Program/Procedure" with four (4) asterisks (*). No need to display this -- 99% of the user community has never changed this. Please also note that I added DSPATR(ND) and DSPATR(PR) to protect and NOT display the input field. The field MUST be on the display, however, no need to see it nor enter anything within them.
C. Same treatment as in the example I gave for B.
So, what do we put in the normally open space? How about "Contact Help Desk at extension 1234?" Communicating before you signed into the system, great idea! Once these edits are in place, you can compile the display as you normally would compile a DSPF source type, and then perform the following command to utilize that sign-on display instead of the one shipped from IBM. What else can we do? We can use a message file to display different messages for the users that sign in. How? Well, it's just a display file, so let's look at the following.
D. See B
E. Under no circumstance change the above.
F. I added some elements that are dynamic that could change from a message file called "SIGNONMF" from a message number of SON 1000 (Signon 1000?)
So, where did they come from? From the two CL commands!
CRTMSGF MSGF(library of your choice/SIGNONMF) TEXT('Sign-on Message File') And to add the message to the file…
ADDMSGD MSGID(SON1000) MSGF(SIGNONMF) MSG('To Contact Help Desk;')
ADDMSGD MSGID(SON1001) MSGF(SIGNONMF) MSG('Tel: 123-456-7890')
ADDMSGD MSGID(SON1002) MSGF(SIGNONMF) MSG('Internal: Extension 1234')
The last thing, let's modify which display we see.
CHGSBSD SBSD(QINTER) SGNDSPF(library of your choice /QDSIGNONNW)
Where QDSIGNONNW is the name of the file edited within my examples.
Now to be 100% SAFE, – do NOT edit the QCTL subsystem's Sign-on – NOR do you replace the existing QDSIGNON located in QSYS).
Like what you see? I found this information on line, visit the Astradyne site for more information.
About the author: Andrew Borts is webmaster at United Auto Insurance Group in North Miami, Fla. He is often a frequent speaker at COMMON and is past president of The Southern National Users Group, an iSeries-AS/400 user group based in Deerfield Beach, Fla.