It's come a long way...maybe.
With each new release of the operating system in which it runs, RPG has kept growing by leaps and bounds. RPG/400 was little more than the S/38's RPG III when the AS/400 was announced in June 1988. With the new release of OS/400, V2R2M0, RPG/400 has grown again: you can now specify hexadecimal constants, quickly determine the length of a string, use four-digit years and eliminate the source of common errors while manipulating strings. This article will give you a quick tour of these new, unexplored features.
Hexadecimal Constants
One of my pet peeves with RPG has always been that it could not incorporate hexadecimal constants in the code-something other languages like CL have been able to do since yesteryear. This function can be very useful. For example, your interactive programs can change the display attributes of certain fields by placing 5250 data stream control characters such as hex '20' for normal video or hex '22' for high intensity.
Up until now, you were forced to use BITON and BITOF to create these two important bytes. Now you can simply MOVE a hexadecimal constant to the appropriate field, as shown in 1.
Up until now, you were forced to use BITON and BITOF to create these two important bytes. Now you can simply MOVE a hexadecimal constant to the appropriate field, as shown in Figure 1.
It couldn't be clearer! The hexadecimal constant is specified just like in CL. You can use hexadecimal constants anywhere a character constant is allowed, except in edit words (O-specs) or in Factor 2 of the ENDSR operation. These limitations are understandable and should not present any real obstacles. You can also use hex constants as named constants or in compile-time data for arrays and tables.
The RPG/400 Reference Guide (SC09-1349-01) describes the uses and rules of hexadecimal constants. It includes a lengthy discussion of coding for embedded single quotes which frankly seems silly. The single quote character is X'7D'. Compare the two methods to define field QUOTE in 2.
The RPG/400 Reference Guide (SC09-1349-01) describes the uses and rules of hexadecimal constants. It includes a lengthy discussion of coding for embedded single quotes which frankly seems silly. The single quote character is X'7D'. Compare the two methods to define field QUOTE in Figure 2.
Notice that the first method requires you to double up the embedded quote, while the hex constant doesn't require that. However, I still prefer the first method because it's more explicit. Unless I keep an EBCDIC chart next to me (or I memorize it-and knowing my memory, that wouldn't work), the second method leaves me in the dark as far as what it's doing. I'd have to use comments to document it.
A few rules you need to remember when using hex constants:
The constant must begin with a letter X and contain the hex value enclosed in single quotes.
The hex value must have an even number of characters-in other words, it must have whole bytes. Thus, X'3A7' is invalid, but X'03A7' is valid.
The letters A-F within the hex value can be entered in upper- or lowercase. Therefore, X'C4' and X'c4' both yield a character D. The X that initiates the whole constant must be in uppercase, however.
String Length
I've always wished there was a LEN opcode to calculate the length of a character field-not the allocated length, but the used length. For example, if I do a MOVEL 'A' to a 10-byte character field, the allocated length is still 10, but the used length is one, since I have moved only one character into it. That's what I have always wanted, but IBM didn't provide-until now.
There's no LEN opcode, but there's CHEKR, which checks a character field in reverse (from right to left). Like its older sibling CHECK, CHEKR requires the comparator string in Factor 1 and the source string in Factor 2. An example is shown in 3.
There's no LEN opcode, but there's CHEKR, which checks a character field in reverse (from right to left). Like its older sibling CHECK, CHEKR requires the comparator string in Factor 1 and the source string in Factor 2. An example is shown in Figure 3.
When this code executes, POS will have a value of 3. This is because character field DATA contains 'ABC', left-justified, and seven blanks. The CHEKR operation finds the first character not equal to the blank specified in Factor 1-beginning from the right-hand side! Pay attention to the fact that CHECK wouldn't have done you any good; it would have returned a value of 1 because CHECK starts checking from the left-hand side.
Like CHECK, CHEKR also lets you use a result indicator instead of a Result field, or a numeric array as the Result if you want to find all occurrences at once instead of just the first one.
The CHEKR technique should replace your one-byte string handling routines quite effectively. Maybe I'm near-sighted (in fact, I wear glasses), but I can't see other practical applications for CHEKR. But when the need arises, the tool will be there waiting for you.
Four-digit Year
With 2000 just around the corner, it was about time RPG/400 supported more than the few years left in this century. This support is provided not only by new data types in the DDS of externally defined files, but by new reserved words for RPG that you can start using right away:
*DATE. Like UDATE, *DATE gives a numeric value containing the job date. Unlike UDATE, however, *DATE provides a four-digit year. If your date format is MDY, for example, *DATE would give you 12251992 for December 25, 1992.
*YEAR. It works like UYEAR, but it shows the year with all four digits.
*MONTH and *DAY are exactly the same as UMONTH and UDAY-they're completely interchangeable. For consistency, however, consider using *MONTH instead of UMONTH if your program uses four-digit years.
It is important to notice that these new reserved words can be used anywhere the old ones are valid, and that they yield numeric values. As such, they can be edited with edit codes or edit words. In particular, edit code Y has been expanded so it supports complete dates using four-digit years.
Just as in many other cases, there are incompatibilities and circumventions you need to learn. Consider that data with the new "date" type in DDS is interpreted in your RPG/400 programs as character data since RPG/400 doesn't directly support the date data type yet. Therefore, you can't easily compare a date field (from an externally defined file) against *DATE, because *DATE is numeric. If you try to compare them with IFEQ, for example, you'll get compiler error QRG7052 ("The entries for Factor 1 and 2 are not of the same type. Specification ignored"). This message has a severity of 30, so you can't override it with the GENLVL parameter of the CRTRPGPGM command.
The TIME operation code supports the four-digit year too. All you need to do is code a 14-digit field (with no decimal places) in the Result field. When coded like this, the TIME operation assigns the time and date to the Result field, in the following format:
HHMMSSMMDDYYYY
Of course, the date portion of this result varies in format depending on which date format you're currently using. The format listed above holds true for programs with the MDY date format.
Relief for String Manipulation Opcodes
The SUBST and CAT operations have been around for a while, but Factor 1 has always been mandatory. Now it's optional. Let's see what this means.
For the SUBST operation, eliminating Factor 1 results in a very dumb operation-it does nothing, because SUBST will extract the whole length of the string, beginning with position 1. In other words, the Result field will be equal to the source string. You might as well replace SUBST with MOVEL; I wouldn't be surprised if MOVEL performed better than SUBST in this particular case. Is this a great feature, or what?
On the other hand, the CAT opcode features some substantial advancements. When you're splicing together several short strings into a long one (such as when building a CL command string so it can be executed with QCMDEXC), it's always been annoying having to repeat the string you're building in Factor 1 and Result of each CAT statement. It's like in the early days of RPG II, when Factor 1 was mandatory in the ADD operation!
The CAT operation now works like ADD. If you omit Factor 1, the compiler assumes that Factor 1 is the same as the Result field.
Another great improvement is that now you can code a P in column 53 (the operation extender) for the MOVE, MOVEL and MOVEA operations. This causes the system to clear the Result field before performing the move operation. As a result of this improvement, you no longer have to CLEAR the Result field yourself. Just remember to code the P in column 53 and you can rest assured that the Result field won't have any garbage left over from previous operations.
Other Improvements
There are a few other improvements, but these are system improvements that apply to other languages as well. For instance, RPG/400 can now recognize database files that have keys of up to 2,000 characters.
As far as the future is concerned, what's in store for RPG/400? Who can really tell? Much has been said about the New Program Model (NPM) and the possibility of getting free-format statements. We don't know if that will happen, but it's been rumored that new versions of RPG will offer at least some of the following features:
Local variables in subroutines, and the ability to pass parameters to subroutines.
Longer field names (10 characters).
Parenthetical expressions in the IF statement and a new "evaluate" statement (EVAL), similar to COBOL's COMPUTE.
Support for pointers. Pointers are confusing beasts if you've never used them before, but you won't have to use them for everyday business applications.
Multidimensional arrays.
Some of these improvements will make it necessary to revamp the format of the now familiar specifications-particularly the C-spec. This is still at least a year away, however. Chances are you can keep RPG/400 as you know it now without ever having to switch to the new format, anyway. IBM will probably provide these enhancements only in a different RPG compiler which would be separately licensed.
Whether we like it or not, RPG will remain the main programming language on the AS/400, due to its incredibly widespread use and the oceans of software that have been written in it. With the V2R2 improvements, RPG is coming closer to becoming a modern language. Let's therefore wait and see what the NPM brings us.
V2R2 RPG Enhancements
Figure 1 Creating hex constants
Figure 1: Creating Hex Constants ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 C MOVE X'20' HEX20 1 C MOVE X'22' HEX22 1 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6
V2R2 RPG Enhancements
Figure 2 Alternative methods of creating a single quote
Figure 2: Alternative Methods of Creating a Single Quote ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 C MOVE '''' QUOTE 1 * C MOVE X'7D' QUOTE 1 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6
V2R2 RPG Enhancements
Figure 3 CHEKR example
Figure 3: CHEKR Example ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 C MOVEL'ABC' DATA 10 C ' ' CHEKRDATA POS 20 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6
V2R2 RPG Enhancements
Figure 4 Equivalent CAT operations
Figure 4: Equivalent CAT Operations ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 C CMD CAT XYZ:0 CMD is now identical to: ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 C CAT XYZ:0 CMD
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