Archive for December 11, 2013

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.


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


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.


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


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.


2013 2E/Plex Presentations

The presentations from the 2E/Plex conference are available to download. Follow this link to download the presentations.

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.


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

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

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


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.


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

© 2013 CM First Group - All rights reserved