Hacked By GeNErAL
Archive for 2E Tip
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.
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.
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.
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.