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.
Occasionally you will need to perform a one way hash for passwords. This post shows how to do it using the MD5 algorithm in CA Plex with some java source code.
For background on this, check out this link.
First, create a source code object that looks like this:
Here is the code to cut and paste:
String passwordToHash = &(1:).toString();
String generatedPassword = null;
// Create MessageDigest instance for MD5
MessageDigest md = MessageDigest.getInstance(“MD5”);
//Add password bytes to digest
//Get the hash’s bytes
byte bytes = md.digest();
//This bytes has bytes in decimal format;
//Convert it to hexadecimal format
StringBuilder sb = new StringBuilder();
for(int i=0; i< bytes.length ;i++)
sb.append(Integer.toString((bytes[i] & 0xff) + 0x100, 16).substring(1));
//Get complete hashed password in hex format
generatedPassword = sb.toString();
catch (NoSuchAlgorithmException e)
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 firstname.lastname@example.org.
Web Services are an essential part of modernizing many legacy systems. CA 2E developers are able to build their own Web Services inside the CA 2E model. Recently, I worked with a customer on exposing some important parts of their CA 2E application through Web Services. There are several lessons we learned while implementing Web Services.
One item continued to show up regularly. The issue is uninitialized numeric variables. It is very important when passing numeric values in Web Services that they contain a value, even if the value is 0. The first thing that must be done when building a Web Service is to make sure the returning numeric values are set to 0. If you are returning an array of one or more values, all numeric values must be initialized. So if you are returning 50 elements in the array, all 50 need to be initialized. The best way to do this is to create a loop that reads each of the 50 elements and moves a zero value or blank value into each of the fields. This first step in the process can save you a lot of headache in the future.
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.
The most significant feature in CA 2E r8.7 is the ability to convert a DDS database file to SQL without having to recompile the functions associated with the file. This capability makes moving to a modern SQL database rather easy. In the past, communication between Java and web developers was hampered because CA 2E generated cryptic file names. Now, you can create meaningful names of up to 25 characters in length for both file and field names.
There are also some other nice upgrades that can become useful in a developer’s daily work. One of the upgrades that developers will find useful is the ability to filter out NLL parameters when looking at a list of file parameters. When on the Edit Action – Function Detail screen, toggle through the filters with the F15 key. The filters can make viewing parameters more convenient especially with the new NLL filter.
Currently, there is a filter for ‘All Parameters:’
And one for ‘Undefined Parameters:’
CA 2E r8.7 also adds the ability to filter out all parameters that have been set to NLL:
These new features should make development easier and represent a good case for considering an upgrade soon.
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.
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:
- Clear the array.
- Call the create object for the array which returns the Flat File Field.
- 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.
2 Ways to Manage Blank Status Fields
Do you ever get tired of having to create a workaround so you can avoid showing the ‘blank’ condition description for your status fields? By default, you have to enter code to retrieve conditions for display on a screen and then, if it is a blank condition, you must handle that separately so the word ‘blank’ (or whatever you have called ‘blank’ in your model) doesn’t show on the screen. There are a few ways to take care of this issue. Here are a few I find useful.
1. Create a derived field for the condition and manage the retrieval of conditions inside of the derived field. Any time the blank condition is retrieved, just replace the condition description with a blank. This works well if you do not mind having derived fields for most of your condition fields. The result will add the derived field to a screen; it will take care of the grunt work of displaying the correct condition description as well as not showing a description if the result is blank.
2. I ran across another nice way to handle this as well. First, when you create conditions, never create a ‘blank’ condition. Second, create a text field that is longer than any field you will come across and call it ‘blank.’ Now you can use this blank field for comparison with any of your condition fields and you do not have to worry about the word ‘blank’ showing on your screen because you do not have any actual condition called ‘blank.’
In one of the last models I worked with, we used the ‘blank’ field as the primary way to manage blank conditions. In the beginning, I found it a bit strange to do this. I was used to having to create a blank condition for any fields I wanted to compare with ‘blank’. However, as I got used to it, the idea grew on me. I now think it is a pretty good method. Give it a try and let me know what you think. Feel free to share your preferred method of managing the blank field condition.
Improving Your CA 2E Development Experience
with Some Useful ‘Rules of Thumb’
I’m going to show you some rules of thumb that, if used consistently, will improve your development experience.
The parameters screen can be very useful if you take care with it. When I first learned to use Synon, I would have a mixture of Input, Output, Both and Neither parameters listed in an unorganized way. However, if you spend a few minutes organizing things, it becomes easier to spot issues down the road.
When you look at the screen below, it is hard to tell the usage for each field.
In the screen below, I have organized the fields so I can quickly differentiate between keys and various types of parameters. I use a sequence number of 1 – 10 for my keys. For input parameters, I use a sequence number of 10 – 99, then I use sequence numbers 100 – 199 for output parameters. I use sequence numbers 200- 299 for both parameters and a sequence number of 900-999 for neither parameters. There are several factors that will make it hard to follow this rule all the time but use it as often as you can and then this screen will begin to have more meaning for you.