|Editors:||Ted Holt||Managing Editor:||Mari Barrett|
|Howard Arner||Technical Editor:||David Morris|
Some of our iSeries and AS/400 users are not impressed with the Ps, Qs, and other letters that show up at the end of numeric fields when they press the Field Minus key. The only way I know to make the Field Minus key insert a trailing minus sign is to code an S in column 35, which represents the Keyboard Shift in a display file. However, code S does not permit users to enter the decimal point. In order to let users key the decimal point, I have to use a code Y instead. But, code Y changes the last digit of a negative number to a letter. This is frustrating. Can you help?
I understand your problem, and I don't have a great answer. Since you want users to key decimal points (.), you'll have to specify Y in column 35. I suggest that you have users key a trailing minus sign (-) and press the Field Exit or Field Plus key instead. This is one extra keystroke, but it will provide the result you want. Users not wanting to type the minus sign can press Field Minus and live with the letters.
Here's a little DDS to illustrate:
If the coding effort is worth it to you, here's a technique that Midrange Server Technical Editor David Morris has used. You can force an update of the displayed information when the user presses the Field Exit key with the CHECK(ER) keyword. On a fast system, this technique refreshes the display without a noticeable pause; on an overloaded system, you probably don't want to use this technique. Here is a simple program and display file with two numeric fields that will refresh with the minus sign:
The combination of Change indicators and position cursor indicators in the display file causes the cursor to advance to the next field. Because very little processing occurs when a value has changed, the response is usually acceptable.
To unsubscribe, change your email address, or sign up for any of Guild Companies, Inc's free email newsletters, visit http://www.itjungle.com. Hit the SUBSCRIBE button on the homepage and it will lead you to our online subscription system.
When you sign up for one of our e-newsletters, you can be assured that your e-mail address will NEVER be sold to an outside company.
Please see our advertising opportunities and pricing at
Or contact Timothy Prickett Morgan at
Phone: 212 942 5818
When I want to call a CL command from within Interactive SQL, I type "CALL QCMD" or "CALL QUSCMDLN".
Sorry, Ted. I don't mean to be facetious, but this functionality is available
already and does not require any knowledge--which you subtly glossed
over--of where stored procedures are held and registered, or the
implications of backing up on one system and restoring to another.
Dear Andy, You've no reason to apologize. I thank you and Russ Khoury for sharing that valuable information with your fellow readers of this newsletter and me. I didn't know the functionality was there, neither did the tech people who helped me. I assume it's been there all along.
Andy and Russ wrote to me regarding the October 12, 2001 issue of the Midrange Guru, in which I shared two stored procedures that can be used to execute CL commands from within an interactive SQL/400 session. To put it bluntly, I had reinvented the wheel. As Russ and Andy pointed out, you can use the SQL CALL command to call QCMD or QUSCMDLN. What they didnít say, and what I found out, is that you can call any compiled program from interactive SQL. In all fairness, this is not evident from reading IBM's SQL reference manual, which says that CALL invokes "procedures". I don't think many RPG programmers, especially those of us who work with ILE, think of a compiled program as a procedure.
You can also call REXX procedures and Java procedures, but you have to use CREATE PROCEDURE to set them up.
As for glossing over information, I need to explain that my goal is to send out short tips that readers can easily implement, not encyclopedic tutorials. Here's a little more information for those who are interested.
I store scripts that contain the appropriate create and drop SQL statements for every function and procedure on my system. When I need to recreate a procedure or function, I run the script with a user-defined PDM option I call RS that looks like this:
RUNSQLSTM SRCFILE(&L/&F) SRCMBR(&N)
This technique also works on any system with the SQL development kit installed and is easy to integrate with most change-management packages. It also keeps the SQL catalog files that Andy mentions in sync. If you go outside SQL, using save and restore to move procedures and functions does get tricky. Here are some excerpts from the SQL Reference manual:
"When a program that was created for an SQL procedure or a service program that was created for an SQL function or a sourced function is restored, it is automatically added to the SYSROUTINES and SYSPARMS catalogs, as long as the procedure or function does not already exist with the same signature. SQL programs created in QSYS will not be created as SQL procedures when restored. Additionally, external programs or service programs that were referenced on a CREATE PROCEDURE or CREATE FUNCTION statement may contain the information required to register the routine in SYSROUTINES. If the information exists and the signature is unique, the functions or procedures will also be added to SYSROUTINES and SYSPARMS when restored.
SYSPARMS and SYSROUTINES may contain references to external non-ILE programs. Since restores of non-ILE programs do not repopulate these catalog tables, you may wish to regularly save these tables."
One of the great things about the OS/400 community is that it is indeed a community. We may be all working from our cubicles, but we are all connected and trying to figure out how to best employ the computer technology at our disposal. There are more than a few ways to skin any cat, and if you have a clever and unique answer to a problem that one of our Midrange Gurus has solved, we'd love to hear from you. This newsletter is an open dialog, and we value your input as well as your readership.
It goes without saying--but we'll say it anyway--that your hard technical questions pertaining to real world problems are equally valuable as a foundation for this newsletter as are your programming insights. We hope you find all the editions of Midrange Guru valuable, and we are going to work hard to make sure that they are.
If you have a tough problem, our gurus can probably help. Their mailboxes are always open.
* Email Ted Holt at email@example.com
* Email Howard Arner at firstname.lastname@example.org
This document may be redistributed freely and enthusiastically by email, but only in its unedited form. Thanks for your cooperation.
Midrange Guru is a registered trademark of Guild Companies, Inc. IBM, AS/400, iSeries, OS/400, and eServer registered trademarks of International Business Machines Corp. All other product names are trademarked or copyrighted by their respective holders.