Archive for General 2E/Plex

Those pesky F7 & F8 keys.


Sometimes in 2E developers just assume that there is an aspect of 2E that cannot be customized. For years we just work around items when really those items can be changed and adjusted. One of those items are the F7 & F8 keys. By default 2E is shipped with the F7 & F8 keys as page up and page down, but, that default can be changed. This frees up these keys to be able to be used in your Edit File and Display File functions for other purposes.

First we need to start at the Edit Database Relations screen as in the following screen shot.

Screen Shot 09-21-16 at 08.09 AM

From the Edit Database Relations screen take the F7 function key to take yourself into Fields as in following screen shot.

Screen Shot 09-21-16 at 08.16 AM

Now search for a field named *CMD key as in the following screen shot.

Screen Shot 09-21-16 at 08.18 AM

Now Zoom into the details of the *CMD key field as in the following screen shot.

Screen Shot 09-21-16 at 08.20 AM

Now even though it’s not on the screen use the F9 key to go into the Conditions for the *CMD key field as in the following screen shot.

Screen Shot 09-21-16 at 08.22 AM

OK now what we need to do is adjust the entries in two Conditions lists. The first list we will work with is the *Next page list. So once we find the *Next page list Zoom into the details as in the following screen shot.

Screen Shot 09-21-16 at 08.25 AM

As you can see the F8 key is highlighted in this list along with (if you page down) the ROLLUP key. What we want to do now is remove the F8 key using the – . as in the following screen shot.

Screen Shot 09-21-16 at 09.09 AM

Now that the F8 key has been removed, this frees up the F8 key for use in other purposes for Edit File or Display File functions.

Now we would do the same process for the *Previous page list. But, for that list we would remove the F7 key. This then frees up the F7 key for use in other functions.

And, there you have it! It’s a very simple change, but something that a lot of 2E shops out there don’t know about.

Happy Coding!








Break Down your Application into Small Chunks

Mark Schroeder, Senior CA 2E Consultant

Most CA 2E applications have gotten quite large over the many years they have been in use. In order to navigate more easily through the application, CA 2E offers some nice options. The obvious feature we see is the positioning lines on the top of the Edit Database Relations Screen.  Files can be found rather quickly by entering the first few characters of the file description.  This works especially well when you enter DFN for the Relation Level. I seldom enter the Edit Database Relations Screen without filling in the Relation Level.


It can become slightly more difficult to manage things if you have a group of files that are related to a specific business function. CA 2E offers a simple method to group files together in this situation as well. Some shops I have been to use this regularly while other shops are very inconsistent.

The method I am speaking of is Application Areas. Application Areas can be a great tool to group related files together. This functionality has been included in CA 2E for years, but it is easy to overlook. I find my productivity increases when I constantly use Application Areas because I spend less time looking for related files. It allows me to have most of the files in front of me that I need for a project.

If you have not created and used Application Areas for a while it can be a bit frustrating to figure out.

First, search with a “?” in the positioning field.


Second, F9 to add an application area.

Third, use a + to add files.


This provides a nice subset of the files in an application.


In summary, we all probably learned about using application areas in CA 2E training. Different shops tend to emphasize them less often than others. If you have the freedom to use application areas and use them regularly in your shop, you will end up having fewer issues with locating files that work together. Application area can help you spend more of your time being productive for your team.

Altering the 2E Generated Source.

Oftentimes it’s necessary to alter the 2E generated source before your function is compiled. In this case what I really wanted to do is add my own H Specs in before the program is compiled. This article will outline how I was able to do this with some user source and the YSCNRPLSRC command provided by 2E.

Note! In order for this to work you will need to have the 2E preprocessor setup. If you don’t have this setup there is a manual provided by 2E to do so.

OK so first thing we need to do is establish a user source that will hold all of the H specs that I want to include in my function. I’m going to setup this source in my QRPGLESRC source member in my generation library.

Screen Shot 02-01-16 at 11.43 AM

So now I have a member in my QRPGLESRC source file called OPS00CB00 which will hold my custom H* Specs.

Next what I need to do is go into my *Template 2E provided file and create a Execute User Source. I’m going to call this new function Add Custom H Specs.

Screen Shot 02-01-16 at 11.48 AM

When I Zoom into this new function I’ve renamed the program OPS99R01 to hold the code that I want to insert into my Function. The Code is going to look like the following.

Screen Shot 02-01-16 at 11.50 AM

As you can see this is going to insert into my Function’s generated code a Y* CALL OPS99C01 statement. This new program OPS99C01 is going to hold the code for the YSCNRPLSRC. Now let’s code up OPS99C01. It will look like this.

Screen Shot 02-01-16 at 12.04 PM

This simple program will figure out the name of the program being generated and compiled using the job name. As you are probably aware the batch compiles are always the same name as the generated program name. Then the program uses the YSCNRPLSRC command to look for the statement,


And replace it with a insert of a copybook as,


This is the OPS00CB00 which holds my custom H* Specs.

OK now that we have all the setup completed. Let’s insert a call to our Add Custom H* Specs function in a simple Display File function. We will be putting this call in the user point of USER: Initialize program.

Screen Shot 02-01-16 at 11.57 AM

Now we just generate/compile our function as normal.

Once that is complete you should see the following in the generated source member.

Screen Shot 02-01-16 at 12.00 PM

You’ll see from the above screen shot that my Y* CALL OPS99C01 has been inserted in the source code. Now let’s look at the compile listing.

Screen Shot 02-01-16 at 12.05 PM

Screen Shot 02-01-16 at 12.06 PM

As you can see my copybook was used and now my custom H* specs are now included in the generated code.

I find this most useful when putting a program into debug when the function is using SQL for record access instead of the default RPG record level access. The statements that are included to run the SQL statements are removed in debug so that you can just see the executed SQL statements. Makes running 2E programs in Debug MUCH easier.

This same technique can also be used to do other things if you wish to replace what the generated RPG code looks like, but you may need to run a combination of programs if you wish to scan and replace multiple lines of code.

One reason I like this technique so much is that I don’t need to mess with the generated code at all. Each time this function is going to be generated these H* Specs will always be included. And, if you combine the use of a template with this technique, you will never forget to put the line of code in the Initialize user point.

If you have any questions or comments please feel free to let me know! Thanks! Jason


Looking for CA:2E Documentation?


Just a quick note to remind everyone that if you are looking for the online documentation for 2E it can be found here,



Subfile Drop/Fold within 2E.

When I train people to who are new to 2E, but have been RPG developers for sometime, one question I’m asked about is how to perform subfile drop/fold within 2E. This is actually pretty simple to do, just follow the following steps.

First let’s work with a screen in which we want some fields on the second line of the subfile. In my case this is going to be the record stamp fields. Normally you would see the following when you go into a simple display file function.

Screen Shot 10-14-15 at 10.02 AM

OK so now let’s put our cursor on the Create User field and press F9 to move all those audit stamp fields to the next line.

Screen Shot 10-14-15 at 10.07 AM

OK so what I have done in the above screen shot is move the stamp fields to the second line, and I have cleaned up the column headings and positions. Now if I want the subfile to be drop/fold enabled I need to do the following,

First press Shift + F5, F17 to go into the Display Screen Formats display.

Screen Shot 10-14-15 at 10.09 AM

From here use option Z over the Subfile control format.

Screen Shot 10-14-15 at 10.10 AM

You’ll notice that in the upper section of the screen there is a new option called Command key for SFLFOLD..:. Here you would specifiy which command key you want to either fold or drop the subfile. In my example I’m going to use F23 or Shift + F11.

NOTE! If you do not have multiple lines on your subfile this option will now show on the display!

OK once you have saved that you can gen and compile the function. The subfile will be initially folded and you can use the F23 command key to drop.

However, Normally we want the subfile initially dropped, and then we can fold using the F23 command key. To do this we need to insert a line of code into our action diagram. See below.

Screen Shot 10-14-15 at 10.15 AM

In the user post Initialize program I’ve added a line of code to set *Subfile mode at the Program context to a condition of *Truncated. This will cause the subfile to be initially dropped, and then when I use my F23 key it will then fold. That’s all you need to do.


Happy Dropping and Folding!



Issue with SQL Created Tables and Date/Time Fields.

Hello all!

Yesterday I was creating some new tables within my personal model, and these tables are being created with SQL DDL and not DDS. I have the Table or Physical File still the generated name, but I wanted a table with the longer field names. The table itself created normally, and has 4 date and time fields to hold record stamping information. When I tried to create an Edit Record function to maintain the data in the file, I could not get the program to compile. The error that I was receiving was,

*RNF7506 20      4 Padding is not allowed for a MOVE or MOVEL to a Date, Time, or Timestamp field.

Changing the MOVE(P) to a MOVE statement worked, but obviously we want things to be regenerated at some point. So I wrote Ragu at CA and asked if this happened to be a known issue. He said it is and the fix is to change the compile options for the *CRTSQLRPGI inside the model.

To make this change you need to do the following.

First you will need to go into the model as a designer. Then you would subset your field list by using an * to show the 2E supplied tables. I also happen to use the DFN option on the screen so that I just receive a simple file list.

Screen Shot 10-14-15 at 09.39 AM

From here we are looking for the *Messages file. Use option F to go into the *Messages file. From here scroll down until you find *CRTSQLRPGI as shown in the following screen shot.

Screen Shot 10-14-15 at 09.42 AM

From here use option Z to go into the message details.

Screen Shot 10-14-15 at 09.44 AM

Then use your F7 Function Key to work with the second level text of the message.

Screen Shot 10-14-15 at 09.45 AM

At the end of the second level message text add OPTION(*CVTDT) as shown in the above screen shot.

Once you save that second level message text you can try to generate and compile your function. It should then gen and compile normally.

I have written Ragu again to ask if this is going to be the permanent fix or if there is going to be another solution in the future. I’ll post and update when I have one.





WCF Service Design

In this post, I want to outline two concepts that may help you to create a better service architecture for CA Plex WCF services. First, we should make sure the interfaces are decoupled from the business logic in order to make sure that a change to business functions will not affect the interface used by clients. The second suggestion will make your WCF service more compatible with REST principles and will allow for easier transformation to REST-based services.

Decouple interfaces from business logic

In order to decouple the business logic, we use an adaptor pattern. We create a wrapper function for each method on the interface and define separate input and output parameter fields scoped to the wrapper function.


The following images show a simple example using the “SalesSystem” model shipped with CA Plex. On the IOrder interface, we define a method “GetOrderHeader”. This method is implemented by Function “Order.Header.Adaptor.GetOrderHeader”.




Design for stateless operation

Make sure the exposed methods do not require a session (server application state per client). The standard BlockFetch pattern relies on server state (open cursor).

To get more than one instance from a collection, we still have to hard code the number of instances that will be returned as a page from a service (CA Plex limitation). A PageFetch pattern’s interface has to be designed similar to the one shown below:


Navigation through pages is by PageNumber.

If there are any questions regarding this post please feel free to contact me at

Create Great CA 2E Code with A Few Simple Tricks

Good coding in CA 2E takes some effort. A key aspect of creating good code is to make the action diagram simple to read. It is always good to include comments in code so the next programmer can read your intent. It is also very helpful to divide your code into separate sections of related code. Then you can use the H key to hide that section of code. When you want to look at your code, use Z to zoom into the section or us an S to show the expanded section of code. These concepts are probably old news to the seasoned 2E professional.

One of the ways that I have often used to divide my code into sections is by using IS or ISF to Insert a Sequence. This works great and allows you to divide code into sections and add some comments to a section of code. When looking at the source code, you will see that in RPG or COBOL, a separate sub-routine is created for this code.

Sub-routines are not a problem, but sometimes it is easier during debugging to not have to go back and forth between sub-routines.  I found a great trick that helps you deal with this more smoothly – ‘insert a case statement.’ Insert a Case Statement then insert an’ otherwise in the case.’ Finally, delete the ‘New Condition’ statement of the Case Statement. It sounds sort of strange to have a Case Statement with no conditions but in effect, it is creating a section of code that will always be executed. Plus no sub-routine is generated in the source code.





2E/Plex World Wide Developer Conference

It’s Time for the 2015 CA 2E/CA Plex 7th Developers Conference
Join the CA Community, Partners and Customers for this Premier Developer and Analyst Event in Austin, TX
Hello again to the Worldwide CA 2E/Plex Community,

Early Bird registration for only US$249 is now open for the 7th CA 2E/CA Plex Developers Conference, to be held at the AT&T Conference Center in Austin, Texas. June 1-4, 2015

Visit the conference site to complete your registration.

Create Export Files the Easy Way

One of the challenges in any data system is how to share data with other systems. There are many times you need to create a data file that can be exported into other systems. This can be anything like from an ACH file that goes to the back, a Skip Trace file or any other kind of data file.

The challenge in building these files is finding a way to convert all the required fields into text data for the flat file. CA 2E provides multiple ways you can do this. The first is to use the built-in function, *CVTVAR, to convert each numeric field type into a text field type then concatenating all the fields together. This works but it takes a while to code.

The process can be greatly simplified if you use an array. Here are the steps:

1. Create an array with all the fields you plan to export. The fields can be both numeric and text fields.


2. Create a CRTOBJ function for the array. The input parameters will be the fields for the array and the output parameter will be the text field for the new flat file you plan to build.


3. In the ‘Processing after Data’ update section of the Action diagram, add a CVTVAR. The input will be the ELM context. This sends in all the elements of the array. The output is the Flat File field that is the output parameter.


4. Now you are ready to build the export file. Build a retrieve that will read though the data that you want to export. In the example, we are reading the customer file. For each record in the customer file:

  1. Clear the array.
  2. Call the create object for the array which returns the Flat File Field.
  3. Create a record in the flat file.


That is all there is to it. There is no need to work with individual fields or concatenate a string of fields together to make a flat text record. The array does the grunt work for you with ease.

© 2013 CM First Group - All rights reserved