Archive for Synon/CA 2E

Make It Zero

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.

New Features in CA 2E r8.7

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:’

New Features in 2E 1

 

And one for ‘Undefined Parameters:’

New Features in 2E 2

 

CA 2E r8.7 also adds the ability to filter out all parameters that have been set to NLL:

New Features in 2E 3

 

These new features should make development easier and represent a good case for considering an upgrade soon.

Using IBMi APIs Part 3

This post will be the final post in a series on IBM APIs.  Since you have had a chance to run though some basic APIs we are going to go through a more complex example that gives you a chance to tie everything together.

In this example we are going to create a list of users that are signed on to an IBMi.  The list will be dynamically created at the time the API is called.  These examples are RPGIV based

Create a Structure file called API Functions. This structure file will be the place to put all the API definitions.  Create two User Source functions.  One is to CVT BIN to DEC and the second is to CVT Dec to BIN. E into each function if found and add the source code below for the respective function.

Convert Binary to Decimal source code.

Binary to Decimal

Convert Decimal to Binary source code.

DecToBin

Create an API Call Wrappers for each of the three APIs that will be used.

In the API Functions file add the needed functions. The source name for each of these should be the IBMi native program name.

1. API:List Signed on Users

LstSIUser

2. API: Create User Space

CrtUsrSpace

3. API: Delete User Space

DltUsrSpace

 

Create three Arrays for managing parameters.

1. P:API Error Structure

APIErrorStruc

2. P:API List Entry Value

LstEntryVal

3. P:API List LoggedIn Users

ParLogInUsr

Now, create the internal functions that will be called in the 2E programs.

These Internal Functions will contain the steps necessary to call the API programs. You will need functions to do the following actions.
1. Create User Space

CodeCrtUsrSpace

2. Delete User Space

CodeDltUsrSpace
3. Retrieve User Space Header

CodeRtvUsrSpcHdr

4. Retrieve User Space Details

CodeRTVUsrSpcEntry

5. List Active Users

CodeInitLstActUsrs

Assemble the Functions and Create Display

Now all the functions are created that need to be assembled a way to display the contents of the User Space. We are going to use a temporary file that only contains a sequence number. We will write sequence numbers to this file in QTEMP and then use the file to display the actual contents of the user space written for the List Active Users API. In our demonstration, we will do the following:

1. Create External function that will put the results file in QTEMP. The function needs to copy the DSR Display Results file into QTEMP. Call our Display File to display the List of Active Users and then delete the User Space and DSR Display Results file from QTEMP.

CodeRunLstActUsr

2. Create a Display File over DSR Display Results with a screen display similar to this.

ScrnListActUsrs

3. Add the following actions in the Initialize.

Call the List Active Users API.
Call the RTV User Space header API.
Set the LCL DSR Sequence to Zero.
Perform a loop to and create records in the DSR Display Results file. The LCL DSR Sequence will indicate the number of users to list.

DsfInitLstUsr
4. In the initializes sub file user point, do the following:

a. Retrieve the User Space Entry.
Check to see if there is a value in field Userspace Entry 1-250. If there is a value we have a good record so we must substring the values.

DsfInitSfrLstUsr

b. Substring the Display station

SbsDspStation

 c. Substring the User ID

SbsUsrId

 d. Substring the User Job

SbsUJob

e. Substring the Activity

SbsUAct

 

5. Compile the programs and test. The first time the API runs, it can take a bit of time. You should get a display of all the active users on the IBMi at the time you run the program.

 DSPFileUserList

This was a quick walk through of using IBM APIs with 2E.  It can give you a basic framework to use in developing applications that use APIs.  Once you integrate the API to 2E any developer can now use what you have created and be up and coding.

Using IBMi APIs Part 2

In part one of this series, we looked at calling an IBMi API with an RPG user program.  It would be nice to call the same API directly from 2E but in this case, it does not work. That is because the API is not a program we can call directly.  You can see this by the name of the API – access().  For us to call it simply with 2E, we need it to be a program.

Let’s look at another simple example of an API called QUSCMDLN.  This API can be added to 2e and allow you to call a command line within a program.  If you do a WRKOBJ on this API, you also find it in SYS and a type of Program.  Since we find it as a program, we know it will be an API that can be called directly in 2E.

In order to set this up in 2E, there are a few simple steps to follow:

1. Create a User Program.

2. Z into the User program and change the Program to QUSCMDLN.

3. Define any parameters that are needed.  In the case of this API, there are no needed parameters.  Once you have defined the API in 2E, it can be called from a function.

QUSCMDLN Window

We will use a Prompt Record as our sample program. Create a simple prompt record similar to the illustration below.

QUSCMDLN Window 2

Add code into the action diagram user point User defined action.  The code should call the API QUSCMDLN function.  There are no parameters to include in this call.

QUSCMDLN Window 3

Now, generate and compile the function and call it from the command line.

QUSCMDLN Window 4

Finally, use the F10 command key or the key you defined in your action diagram to call the API.  The API will create a popup window command line.  With this API, you are easily able to add command line capability from within functions in your application.

QUSCMDLN Window 5

Using IBMi APIs with 2E Part 1

IBM APIs provide many tools that a 2E programmer might need. There are also different ways a programmer can interface with the APIs. The first method is to write a native RPG program as a user program and include that program within the 2E model. Once it is written any programmer can call the user program from their 2E function.

api1

Lets look at the advantages verses the disadvantages of using this method.

Advantages
1. API interface normally is written in fewer functions..
2. Native code bypasses any limitations of 2E.

Disadvantages
1. Someone on the team needs to have sufficient experience to write the native RPG or COBOL.

Lets look at a sample of using a user program to interface with an IBM API. In our example we will write a program that will verify the existence of a file on the IFS. We will also check the security level of the object on the IFS.

Here is the RPGLE source code needed to call the IFS API:

h option(*nodebugio) dftactgrp(*NO)
*
daccess PR 10I 0 extproc(‘access’)
dpathptr1 * value
dmode1 10I 0 value
*
*IFS API Constants
*
DF_OK S 10I 0 inz(0)
DR_OK S 10I 0 inz(4)
DW_OK S 10I 0 inz(2)
DX_OK S 10I 0 inz(1)
*
* Working variables
*
dFile_exists S 10I 0
dpathptr S *
dpathname S 101

d$filename s 100A
d$path s 50A
d$file s 50A
d$found s 1A
d$read s 1A
d$write s 1A
d$execute s 1A
*
* Main —
*
c *entry plist
c parm $path 50
c parm $file 50
c parm $found 1
c parm $read 1
c parm $write 1
c parm $execute 1

* Set a character pointer to the file name string
c eval $filename = %trim($path)+’/’+%trim($file)
c eval pathname = %trim($filename)+x’00’
c eval pathptr = %addr(pathname)
c eval $found = ‘N’
c eval $read = ‘N’
c eval $write = ‘N’
c eval $execute = ‘N’
* Call the IFS API
c eval File_Exists = access(pathptr:F_OK)
* Did we find it?
c File_exists ifeq 0
c eval $found = ‘Y’
c endif
* If file is found !
c if $found = ‘Y’
* Call the IFS API
c eval File_Exists = access(pathptr:R_OK)
* Do we have Read access ?
c File_exists ifeq 0
c eval $read = ‘Y’
c endif
*Call the IFS API
c eval File_Exists = access(pathptr:W_OK)
* Do we have Write access ?
c File_exists ifeq 0
c eval $write = ‘Y’
c endif
* Call the IFS API
c eval File_Exists = access(pathptr:X_OK)
* Do we have Execute access ?
c File_exists ifeq 0
c eval $execute = ‘Y’
c endif

c endif

c move *on *inlr
c return

In the *entry section you see the values that will need to be included for the parameters of this function. These parameters provide the interface 2E needs to the function.

Path 50 characters I
File 50 characters I
Found 1 character O
Read 1 character O
Write 1 character O
Execute 1 character O

ibmapi2

Once you have created the user program and added the correct parameters to the user program it is simple to call the function from within any 2E function. In this example a prompt record was created with the fields needed on the screen to send and receive the parameter values.

ibmapi3

In this article you have seen one example of creating a user program as an interface to an IBM API. For the next blog entry lets see if we can call this same API directly with 2E.

The RPG code was borrowed from this site: Sample RPG code

2E/Plex Conference

We just finished the 2E Plex conference yesterday. I found it to be an outstanding event.  For those of you that could not attend I will be sharing some of the ideas that I taught in the Advanced 2E Workshop in future posts.  I also want to share some of my impressions of the conference.

I have to say that I found the culture to be changing at CA.  During the last couple years I have seen some change but the change was more exposed at the conference. I found the 2E / Plex teams at CA to be very open and approachable about what we, the customers, want to see in the products.  One session involved all of us customers, getting the opportunity to vote on what features we want to see next.  So we are having a voice in the future of 2E and Plex.

CA also seemed to be more motivated to make the products better now and into the future.  There is commitment in the CA teams to make 2E and Plex better work with current technologies and to adjust to technology changes in the future.

Finally, congratulations to Simon for his excellent work in making the changing Agile process a successful process for 2E and Plex.  I believe his successful adaptable application of Agile to 2E and Plex will help CA produce quality products for us to use years into the future.

10 Easy Steps to Webify Your CA 2E Application

 

Got a great CA 2E screen you’d like to use for the web?  Though there are many tools that can turn your CA 2E screen into a web page, each has plusses and minuses.  One stands out – get the best integration with CA 2E with Web Option, allowing you to do more while working less.  Life doesn’t have to be that hard.

If you know how to generate ‘green screens’ with CA 2E, you can make a web page just as easily.  Don’t worry about CSS, JavaScript or HTML – you don’t have to know any of this to be a web superstar.

Follow the 10 steps after installing the Web Option on your IBM i and see what you can do!

easybutton

10 Easy Steps to Web Magic

 

1. Create the Web Option Server.

The Web Option server provides the link between the generated web skeletons and the actual web pages displayed on the browser.

2. Create the HTTP server

The HTTP server displays your screens a HTML web pages.

3. Configure the Web Option server

The web option server has quite a few items you can customize based on your specific needs.

4. Customizing Web Server Configuration Easily

Simply point to the proper environment and IFS directories.

5. Creating the Web Environment

The web environment is the location on your IBM i where you will build and configure your web application.  It contains the files, data areas and server configuration for your specific web application.

6. Customizing Pages Globally

You can customize individual pages by modifying generated HTML or you can customize global values that will allow pages to generate with the same HTML, Javascript and CSS customizations.  The latter is the most effective  way to globally customize the skeleton creation.

7. Generate Skeletons for 2E pages

Once you have determined the customizations then skeletons must be generated for each page.  Each page that is generated will need a screen identifier.  You can customize your current header footer to include the screen id or use the provided header footer with the screen id.

When the skeletons are generated they use the global skeleton customizations to provide the look and feel you have defined.  In most cases, you will not have to do any more customization.

This is the step the most 2E developers will use. You simply place an H on the function and generate the HTML.

8. Run the generated screens

Once the skeletons are generated, they can be run in the web server.  Go to the appropriate url for your environment and run the web page. At this point, you have a fully functional web application.

9. Element Level Customization

In some cases you may want to provide element level customizations.  This could as simple as setting all date fields to display as calendars and telling all Yes/No fields to display as selectors.

10.Customize navigation

Finally, if you want to make your application navigate optimally for a web page, Web Option Scripting lets you modify navigation.  For example, you may want to skip a couple of screen but you want to keep the parms on the last screen.  The script can remember the parms you pass so the last screen you open has all the necessary parameters.

You can even provide users with the ability to create and run their own macros.  This can be a time saver for users and possibly a great way to add short cuts to your application.

 

That is all there is to creating a web application from your green screen.  If you need more a more detailed understanding about this process, we do offer beginner and advanced level training on Web Option. Contact us for more information.

 

CA 2E Modernization – One Step at a Time Conquering the Modernization Mountain

“The journey of a thousand miles begins with a single step.”

Lao Tzu

The push to modernize has made people believe they have to leap from the base to the top of the IBM i modernization mountain.  At the basecamp, you find you can’t deliver on key business requirements.  The framework simply won’t get you there.  So, you are motivated to climb.  Some possible approaches include:

  1. Rewriting the application in Java, .Net or PHP
  2. Replacing the application with a commercial applications
  3. Migrating the code using automated tools
  4. Rewriting the user interface with a modern html/css/javascript front-end
  5. Utilizing a screen scraper to modify the existing user interface into a modern html/css/Javascript front end.

They’re each viable options.  But every one of them comes with some good and bad characteristics.  In truth, there is no silver bullet.  But it doesn’t have to be as daunting as it looks.  The mountain can be scaled in steps.  At CM First, we have found this the most cost-effective and business-effective approach.

Ideally, you will want your entire application to be migrated to CA Plex because then you can reap significant benefits.  From atop this new mountain, the development ‘vista’ includes:

  • Cross-platform code generation
  • A customizable web front-end
  • Mobile app generation from existing code
  • Simple web services implementation

But the CA Plex move is another huge leap; not everyone is equipped to scale the mountain in this way.  Moving to CA Plex is the right move, but, by planning a simpler course, you can get where you want to be with lower risk and less cost.

Mountain

First migrate application to the web with Web Option.    Web Option is tightly integrated with 2E and is a flexible approach to web-enable your screens to give you a strong corporate web presence.  Any CA 2E programmer can generate web pages/applications with Web Option with no additional skills needed.  Then, having achieved one key goal, you can begin to  migrate the model to CA Plex.  The final leg of the journey will bring you to the summit where you can build full-feature web and mobile applications with CA Plex and CM WebClient.  Prevent altitude sickness for your users and developers by taking a measured approach to modernization.

 

Add User Macro Capability to Web Option Screens

Web Option allows you to set up screens so users can record their own macros. This is a great way to give users more control over what they do on their screens on the Web.

In order to add this capability to a specific screen follow these simple steps.

1.   Add a one character field on to a screen. This allows you to place the macro drop down any place on the screen you want.  The field will not contain any data. It is used only as a place holder. womacro01

2. Next you need to add and element customization to the screen.  Web Option allows you to customize any element on the screen in this case we only need to customize the new field you just added.  The customization will change how the field displays in the web.

womacro02

 

3. Now you need to look for file YSCRIPT in your Web Option environment.  By default it has one member in it. You will need to add a new member to the file for each user that will have the ability to create macros.  The member you add for each user must be the same as their login id. So if your user’s log in id is BILLB the member needs to be called BILLB in YSCRIPT.  You will also need to set the authority in the member to *ALL.

womacro03

 

4. Regenerate the Function and the HTML for the function.

5. Now it works best to end the Web Option server and the Web server and then start them back up again.  Any time a new member is added to Y2SCRIPT the Web Option server needs to be restarted.

6. Go to the screen that contains the macro drop down from your Web Option URL. You will see the field that has the macro capability added to it.

womacro04

Interview Question 6 Answer

Parameters can be passed between functions as Field (FLD), Record (RCD) or Key (KEY).  Each one has a different meaning in the program and can effect such how your program is called. For example, if you call an external function from a native RPG program you will need to pass the parameters as a FLD.  

CA defines each method of passing values as: 

FLD 

Each specified field is passed as an individual parameter. This must be specified for *FIELD or *NONE parameter lines. 

RCD 

A single parameter with the length of the specified access path is passed. The parameter contains space for all the fields associated with the access path, which can individually be specified as parameters. 

KEY 

A single parameter with the length of the combined keys of the specified access path is passed. The parameter contains space for all the key fields that can be individually specified as parameters. 

(CA 2E 8.6 Manual)

 
 
© 2013 CM First Group - All rights reserved