One of the things that RPG isn’t particularly good at is string scanning & manipulation.
Many other programming languages support using Regular Expressions (or regex, as they are often referred to). Java, PHP, Node.JS, Python, & Perl have support for regex’s built in.
Regular expressions are a very powerful tools for parsing, analyzing, and manipulating text. It should be noted, however, that with such power also comes the possibility for complexity. Some regular expressions can get VERY VERY complex. See the end of this post for a VERY complex expression.
A true regex master can create a functioning expression that is indistinguishable from modem line noise.
I’ve started a personal open source project. Something I’ve been meaning to do for quite a while.
The project is PCMLTOOLS — utilities designed to make working with the Java Toolkit for IBM i (JT400)’s Program Call Markup Language (PCML) easier to use.
The first tool is a Java class to allow a developer to retrieve a ProgramCallDocument object (which is normally generated from PCML) directly from a *PGM or *SRVPGM object who’s modules were compiled with the PGMINFO(*PCML:*MODULE) option.
This is a general warning about using the CHGCMDDFT command to change the default value of command parameters for commands in QSYS.
There are a number of reasons not to change parameter defaults on commands in QSYS…
Any time you upgrade your systems, those default parameter changes will be lost because the commands are completely replaced.
Although you can identify what commands have had parameter defaults changed, there is no indication of WHAT parameter defaults were changed on a command. To identify what commands have had defaults changed display the command objects description (DSPOBJD) with DETAIL(*SERVICE). If an object has had the parameter defaults changed, the APAR ID will show ‘CHGDFT’.
Third party products may be expecting commands to have the IBM provided default values. Because 3rd party products usually have to work on a number of IBM i versions, it’s impossible for vendors to specify a specific value for every parameter. New parameters are added with almost every release.
A Better Approach
A better approach would be to create a library to hold copies of the commands you want to modify …
Create a specific library to hold customized commands
Add that library to the QSYSLIBL system value above QSYS
Duplicate the *CMD objects into that library
Change the default parameter values on the commands in that library.
This way the commands in QSYS are left with the IBM provided default parameter values. Since the custom command library is above QSYS in the system library list, applications that reference those command (that don’t qualify the command to QSYS), will use the modified command.
I like to create a simple CL program that does the work of deleting existing commands from the custom command library, duplicate the command from QSYS, and modifies the command parameter defaults. Not only does this make it easy to recreate the custom command parameter defaults when you do an OS upgrade, it documents what parameter defaults have been made.
You may be tempted to use the CRTPRXCMD to create a ‘proxy command’, that points to the original command, and change the defaults on the proxy command.
DO NOT DO THAT!
A proxy command isn’t a stand alone object that is independent of the actual command. It’s just a pointer to the real command.
Any real changes you make to a proxy command will actually be made on the real command.
Here’s a very simple example of a CL that will repopulate a custom command library with modified default parameter values.