grails jtopen plugin 0.2 is out: groovy record level access

GORM is a fantastic tool, it's especially good with tables it creates. When you have legacy tables (without generated IDs, without version field, with composite keys), it's not that good.

Of course, you can fall back to groovy sql support which is very good, but, once again, with legacy tables, SQL is not always the ideal tool.

If you spent several years coding in RPG, you probably sometimes miss the classical but so efficient traditional RPG file access, as I do. Of course it's possible to use the toolbox record level access, but it needs even more boilerplate code than bare metal JDBC.

That's where the jtopen grails plugin 0.2 new feature comes in handy: "groovy record level access".

You can now access files from groovy almost like you would do from RPG:

def file = ibmI.getFile(name:"FILE")

file.setll("KEY1","SKEY1")

def rec = file.reade("KEY1")

while(rec != null){

// Do something with rec...

rec = file.reade("KEY1")

}

Let's have a closer look:

def file = ibmI.getFile(name:"FILE")

This will create a file object, reading the file "FILE". By default, the file will be opened read only, it will be accessed by key if it has a key, otherwise, it will be accessed by arrival order.

file.setll("KEY1","SKEY1")

As the RPG SETLL opcode, this will set the cursor position with the given composite key.

def rec = file.reade("KEY1")

This will read the next record with the partial key equals to "KEY1".

while(rec != null){

// Do something with rec...

rec = file.reade("KEY1")

}

These lines will iterate through the records with the partial key equals to "KEY1".

RPG coders will be happy to have the read, readp, chain, setll, setgt, reade, readpe, write, update and delete methods that are almost identical to the RPG opcodes.

The record object returned by the read* and chain are dynamic POGO with properties from the file fields (case insensitive). For example, if your file has an ITEMCOD field, it can be accessed by rec.itemcode, rec.ItemCod or rec.ITEMCOD or even rec.iTeMcOd.

You can also use groovy iteration methods (each, eachWithIndex, collect, any...) on file objects. In this case, the iteration will process the next records from the current cursor position. It's possible to process the previous records from the current position with:

file.reverse.each { // Do something with the record }

If the file is accessed by key, it is also possible to process a subset of the file based on the key, for example:

file.setll("KEY1") // Iteration function always start from the current cursor position

file.key("KEY1").each { // Do something with the record }

To process the records in reverse order:

file.setgt("KEY1")

file.reverseKey("KEY1").each { // Do something with the record }

For the latest jtopen plugin release, please go to the plugin page.

Program call: a practical example

In this post, I will show a practical example of using the jtopen plugin to call a program on the AS/400.

We will create a grails service to execute commands on the AS/400.

We assume we have a grails application with the jtopen plugin installed.

We first have to set the AS/400 host, user and password. We will edit the grails-app/conf/Config.groovy file and add the three following lines:

jtopen.as400 = 'as400'

jtopen.user = 'user'

jtopen.password = 'password'

Of course, you should customize the values to your environment. As they are typically per-environement values, we will set them with the grails.serverURL variable.

We then create a new service:

grails create-service Command

This will create the file grails-app/services/CommandService.groovy, we will change it to:

import org.codehaus.groovy.grails.plugins.jtopen.types.*

class CommandService {

boolean transactional = false

def ibmI

def executeCommand(String command) {

def cr = ibmI.call('QCMDEXC',[

new IChar(command),

new IPacked(command.length(),15,5)] as Type[])

cr.success?:cr.messageList

}

}

And that's it!

Let's have a closer look.

import org.codehaus.groovy.grails.plugins.jtopen.types.*

We import the parameter types used to call the program.

def ibmI

This line creates a property named ibmI. It will automatically be injected with an IbmI object.

def cr = ibmI.call('QCMDEXC',[

new IChar(command),

new IPacked(command.length(),15,5)] as Type[])

Here is the heart of the service. This will call the QCMDEXC API with the two parameters it expects:

• The command to execute as a CHAR variable
• The command length as a (15,5) packed decimal

You can see that the QCMDEXC parameters are surrounded by [ and ] as Type[]. This is necessary because of a bug in groovy. This bug has been fixed in the groovy trunk and this circumvention shouldn't be necessary in future grails releases.

cr.success?:cr.messageList

This line makes the service return true if the command execution is successful or the array of messages returned by the command will be returned.

Now let's create a controller using this service:

grails create-controller DataArea

This will create the file grails-app/controllers/DataAreaController.groovy, change it to:

class DataAreaController {

def commandService

def create = {

def result = commandService.executeCommand("CRTDTAARA ${params.name} TYPE(*CHAR) LEN(10)")

render result==true?"Data area ${params.name} created":result.inspect()

}

}

We now start the application:

grails run-app

Now point your browser to:

http://localhost:8080/yourAppName/dataArea/create?name=grails

You should see the message "Data area grails created". On your AS/400, you should have a data area named grails in the jtopen.user user current library (or QGPL).

That's all for this example.

jtopen grails plugin 0.1.2 available

Earlier today, the jtopen grails plugin 0.1.2 was released, here's what's new:

• A bug with IbmI bean injection was fixed
• The IBin2 and IBin8 parameter types were added to handle 2-byte and 8-byte integers
• The IByteArray parameter type was added. This type is useful when a parameter does not have a fixed layout that can be handled by IDataStructure

jtopen grails plugin 0.1.1 available

The 0.1.1 release is available on the grails site.

The only change is that the IbmI object is now a bean that can be injected. You must define the jtopen.as400, jtopen.user and jtopen.password variables in the Config.groovy file.

jtopen grails plugin 0.1 available

The first release of the jtopen plugin for grails is now available on the grails site.

Enjoy!

The grails jtopen plugin is coming

Later today I will release version 0.1 of the grails jtopen plugin.

Here is a list of what's included:

• jtopen 6.5.1
• injection of an AS400ConnectionPool bean
• the IbmI class
• easy program call
• easy data area access

The IbmI class is a wrapper around the jtopen AS400 object and other objects from jtopen.

The jtopen classes are very well designed and give access to a wide range of functions, but its use is very verbose. The IbmI class gives a more groovy way of using some of these functions in a more natural way for CL and RPG developpers:

• Easy program call with handling of input and output parameters
• Easy access to character and decimal data areas
• Possibility to use traditionnal object names (OBJECT or LIBRARY/OBJECT)

Any comment or suggestion will be appreciated.

My first post: Why?

Welcome to the i-grails blog.

For my first post I will answer the self-asked question: Why? Why this blog? Why the AS/400? Why grails?

First, why this blog? Looks like a simple question, but I don't have simple answer. There are actually several reasons for creating this blog.

The first one could be that it seems fun. Many people nowadays blog, I hope I will enjoy it.

Next, is that because of internet and open source software I learned a lot. Communication and sharing opened so many possibilities for anyone, that's just great. I've been a consumer for many years, now it's time to be a producer too. If I can help one single person, I will be glad.

Finally, I like what I do, it's a passion, I like to talk about it, a blog is a great way to do it.

Why the AS/400? OK, we're not supposed to call it AS/400 anymore, but after so many years, I just can't switch every 6 month for the new name IBM invents, so AS/400 it will be. It can seem odd to talk about open source software and the AS/400 which is a very closed system. Well, I work with the AS/400 for almost 15 years now and it's very good at its job. Dr Frank Solstis, his team and IBM did a wonderful job by creating the IBM 38 and then the AS/400. TIMI and single-level-storage are nothing but brilliant ideas. There are lots of old applications running on AS/400 and lots of new things to do. That's my job and I like it.

Why grails? I've coded using many languages, from basic on an Apple II to grails, I've worked with RPG, C, Java and many others. For business apps, RPG is really efficient, you can produce quickly efficient and maintainable code. It is ideal for batch and 5250 programs, but whether it is a good idea or not, 5250 is not the future, the browser is. Of course you can make browser screens with RPG but I don't think it's the best way to go. Java is good, it is a clean and efficient language. There are very nice frameworks for web applications. For a multi-million $ project with lots of collaborating developers, that's probably the way to go.

That's not my world. I found Ruby on Rails, it is very efficient, fast, totally suitable for my needs. The problem is that they started from scratch, so it's perfect for use with mySql, but with an AS/400, things don't go that well. It's getting better, but not enough for me.

I then found groovy and grails: the power of Ruby on rails with the power of the java universe.

My current project is creating the grails jtopen plugin. This plugin will make the jtopen library more groovy. I'll give more information on the plugin on this blog.