Hacked By GeNErAL
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.
From the Edit Database Relations screen take the F7 function key to take yourself into Fields as in following screen shot.
Now search for a field named *CMD key as in the following screen shot.
Now Zoom into the details of the *CMD key field as in the following screen shot.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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,
H DATFMT(*YMD) DATEDIT(*YMD) DEBUG(*YES)
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.
Now we just generate/compile our function as normal.
Once that is complete you should see the following in the generated source member.
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.
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
In my position at CM First Group, I’m often called upon to perform 2E training. It’s actually one of the most enjoyable things I do in my position! However, from time to time I get students who have been RPG or Cobol developers, who are not impressed with the default screen designs in 2E. I understand this well! Before I worked with 2E I was a 3GL RPG developer and understand having full control over screen design.
Fortunately for us we can change the default screen layouts, and we can also make changes to default action diagrams so that new functions can perform to our liking! In this post I’m going to show you how to do just this.
First we are going to concentrate on screen layouts, and then we’ll progress into making templates for the various action diagrams we work with.
First thing we need to do is subset the Edit Database Relations screen, so that we can work with the 2E supplied files. We do this by using an * to subset the files list, and then I also like to use the DFN subset so that I’m working with just the files and not all the files and fields.
From here we want to work first with the *Standard header/footer file, and use our option F to work with the functions built over this 2E supplied file.
OK now from here what we want to do is use option C over *STD SCREEN HEADINGS(CUA) to make a copy.
I’m calling the new function (screen design) Standard FS Screen to say that this is a new Standard Full Size screen. Now I can use my option S to work with the Device Design of this new function.
This probably (could anyway) look familiar as the default that is provided from 2E. From here we are going to change this screen around to customize to what works best in our environment.
From this screen I’m going to use my Shift + F5 (F17) to go into my Display Screen Formats screen. First I’ll use my option Z to Zoom into the details of the screen footer.
Now in my case what I want to do is add into the screen another line of Command Keys. This is the standard I want to implement, so I page down and see that on top of having a field called *COMMAND KEY TEXT 1, there is also a field called *COMMAND KEY TEXT 2. I’ll add this to the screen using option O.
If I use command key F3 back to my screen I’ll now have 2 rows of command keys instead of one.
Now in the past I have seen where it is sometimes advantageous to separate your footer section of the screen, and the detail section of the screen, with a constant field. This could be something like a line of = signs, or it can even include the company name.
To do this I would then use my Shift + F5 key again, and then I would Z or Zoom into the Screen Footer.
From here I want to do 2 things. The first thing I want to do is make the footer of the screen two lines larger, so I do that by saying that the Footer will begin at line 21 instead of line 23. See the above screen shot. The second thing I want to do is use my Shift + F11 (F23) command key to add a constant field to the screen.
What I have done in this case is added a constant field that is all = signs. When I hit enter the screen will look like this. (Note, I have re-positioned the field.)
To redesign the Header portion of the screen is just like the Footer. I would use my Shift + F5, use my Z to Zoom into the Header, and then I can choose which fields I want on my header Display. In my case I decided to design my screen like the following.
The only real tricky part of this is to position the Screen Title at the top of the screen in the right place. For my screen design I needed to tell 2E to put 11 spaces before positioning this field on the screen. I do that by putting my cursor on the field and pressing Enter.
This will vary depending on your own screen design, so you will have to test and see what works best. This allowed me to design the screen I wanted, but the screen title was still centered on the screen.
If I don’t like the default colors, (which I don’t) I can change them by putting my cursor on the field and hitting Shift + F6 (F18). This takes me into the Edit Screen Field Attributes Screen as follows.
From here I’m going to change the output color to white.
Once I’ve made that change and hit Enter you’ll see that the *DATE field is now white.
Then I can change the colors of the other fields in the same manor. Once that is complete I now have a screen that looks like the following.
I like this and it very closely matches to what I would have created as a 3GL RPG developer.
Now I can exit this screen and make sure I save.
OK now we have a new default full size screen, and now I want to create a new Display File function that is going to take advantage of this new screen. I do this by using my F3 key until I’m back at the Edit Database Relations screen.
From here I want to use my option F over the file *Templates to create some new Action Diagram Templates. These will use my new screen, and also we are going to put some common code into the Action Diagram.
First I want to create a new function called WW *Template just like I would any new function. This is going to be a Display File function.
Now I want to Z (Zoom) into my newly created function and then use my F7 command key to take me to the Edit Function Options Display.
Now I want to use my F5 command key to select which Device Design I want to use.
As you can see our new Standard FS Screen is one of the Device Designs we can choose from. We’ll choose that with an X. Hit Enter, and then we can F3 back out to our Edit Functions Display.
If I use my option S to work with the Device Design for this function I’ll see the following screen.
2E is now using our newly created screen template.
From here we can exit and save and then we’ll be back on the Edit Functions Display.
Now we’ll use option F to go into the Action Diagram for our new Template.
From here we want to do a few things. First we want to put in a reload of the subfile after the command keys have been processed, second we want to put in a cursor position-er so that when we come back into this screen, our cursor is automatically put on the record we were working with, and finally we want to put the place holder code for the most common subfile options. In our case that is going to be 2 for Edit, and 4 for Delete.
First I’ll put in the code to reload the subfile in the User Point of Process Command Keys.
Next I’ll put the code in for the common subfile options, and then the cursor position-er. This will be done in User Point Process subfile record (Pre-confirm)
From here I can exit and save the Action Diagram.
Now I can use my option S over my new Template Function to go back into the Device Design.
Now I can exit and save my Template Function.
OK now that we have a new WW Template and a new Screen, we want to use them over a file in our environment. I have created a new Customer file just for this purpose.
If I use my option F to work with my functions I’ll see the following.
Now what I want to do is create a new Display File Function (a Inquiry or WW Function) that is based on our new Template and Screen. I do this by using command key Shift + F9 (F21).
From here I want to select my new WW *Template function that we created.
I then give the new function it’s name of WW Customers and press Enter.
Now if I use my option S to work with the Device Design for this function I should see the following.
You’ll notice that 2E has automatically included the 2 for Edit and 4 for Delete subfile options as those were found in the Action Diagram. Now I can perform my normal screen cleanup. I’ll remove the fields I don’t need and I’ll remove the space in the subfile options. I’ll also remove the F4 Prompt as it’s not needed. Once I’m done with that I should see the following.
I’ve cleaned up my screen and also added more position-er fields by using a different access path. From here I can Exit, Save, and then Gen/Compile my function as normal. When I run my new Program I should see the following.
I had already put records in this file so now we are seeing them on the display. Of course there is no code behind our subfile options 2 or 4, but we can add that in as we create those functions.
If I wanted to do the same thing for an Edit Record function I would follow the exact same steps to create the template. I could then use the exact same Standard FS Screen that I created earlier for my Edit Record template just like I did for my Display File. The same can be said for a Select Record function. The only difference here that you might not be accustomed to is having to use command key F21 to copy from a template vs. just keying the function name on the Edit Functions Display. This is just a matter of habit and can be adjusted with practice.
It’s good to note that I didn’t modify the Templates shipped with 2E. I highly recommend that you don’t modify these templates, but use them as starting points for your own. It might seem like creating templates does not save a lot of time, but it will provide you the ability to use your own custom screen design, and does save some steps in creating Display File functions.
Another question that I’m asked quite a bit by new 2E students is the default window color. By default 2E is shipped to generate windows that will be blue in color, but maybe you want red. I happen to prefer red so we can change that by changing model value YWBDCLR as seen below.
You could then change this model value to *RED and have a default window color of Red. I prefer Red so I normally change any new model I create to Red.
That covers templates for now! I hope this post goes a long way to showing you that you are not stuck with the default 2E screen designs, nor are you shackled down with the default 2E templates. You can redesign and rework using new screens and templates at your will. This alone was a major thing for my own acceptance of 2E, and might just help yours.
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.
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)
Just a quick note to remind everyone that if you are looking for the online documentation for 2E it can be found here,
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.
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.
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.
From here use option Z over the Subfile control format.
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.
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!
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.
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.
From here use option Z to go into the message details.
Then use your F7 Function Key to work with the second level text of the message.
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.
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 email@example.com.