The classic OS/400 sign-on screen has been around what seems like forever. I first saw it in 1988 when I took delivery...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
of my first AS/400 system, a lowly B10. In the old days, the appearance of the sign-on screen made no difference, since the system was a closed system. With the advent of networks, that situation changed dramatically.
Today, most i5-iSeries-AS/400 systems are networked, and users connect via that network connection. The sign-on screen is projected to terminal emulation software throughout the network and even over the Internet for users that are accessing the system from remote locations. Because of this, the sign-on screen standard context can be easily recognized by people with malicious intent and scrubbed (sniffed) for user ID and password information.
Granted, for many users, this information is encrypted. But with the proliferation of open-access protocols, there are many emulators that do not encrypt this information, such as hand-held terminals and the Telnet capabilities of newer Windows operating systems. For my own system, I access it via my Treo 650 when I travel, and I'm certain no encryption is taking place.
For that reason, it is a good idea to design your own sign-on screen and that you change the standard terminology used to identify the User and Password fields. Making the change is fairly easy, but you need to be careful and you need to test your new screen before rolling it out for general use.
IBM ships the source code for the standard sign-on screen in a source physical file named QAWTSSRC in library QSYS. In this source file, you will find two sets of code for the two possible standard screens on your system, QDSIGNON and QDSIGNON2. The first is used when you have standard 10-character passwords configured; the latter is used when you have set your system up for long (128-character) passwords. I recommend you move the source that you want to use into a separate library, thereby preserving the original source in case you get into trouble.
Once you have the source moved into your own library, you can use Screen Design Aid (SDA, PDM option #17) to make your changes. When working on your screen, make sure you observe the following:
- Do not delete any of the input-capable fields that are on the sign-on screen.
- Do not change the sequence of any of the input capable fields. You can move them around on the screen, but keep their sequence in tact.
- Do not change the characteristics, especially field lengths, for any of the input-capable fields.
- Do not attempt to use any DDS HELP capabilities for the sign-on screen.
Since the objective is to change the reference to "User" and "Password," select suitable replacements and make sure to change the text for those areas. I would suggest alternatives here, but that could just start a new default standard, which would defeat the objective of this tip.
When you are all done, compile the screen into a library other than QSYS. To implement the new screen, you will need to update the subsystem description. You can use the Change Subsystem Description (CHGSBSD) command. Press the F10 key to display all parameters, and you'll find one that controls the sign-on screen in use. You can test your new screen in the QPGMR subsystem to make sure it is right before you roll it out to QINTER and other production subsystems.
If you have any specific questions about this topic, you can reach me at email@example.com, I'll try to answer your questions. All e-mail messages will be answered.
About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.