A blog about the things I work with: IBM i (or i5/OS, OS/400, System i, i5, iSeries, AS/400) and grails.

Sunday, June 14, 2009

Practical example: jtopen and webservice

At my job we are currently prototyping a monitoring solution. We use a packaged solution to monitor our Unix and Windows servers, our telecom equipments and our AS/400s.

For the AS/400, we want to check verify that our scheduler is up. The way to determine if it's running is to see if a given data area is locked. If it is locked, the scheduler is running. The question was: how to check this from the monitoring box? The first solution was to create a telnet script that would connect to the AS/400, and check if the data area is locked. Of course, this is not the good way to go, this should be considered as a last resort. The second solution was to create a java program on the monitoring package that would use jtopen (the library, not the plugin) to try to lock the data area. This would work but we would be tied between the monitoring solution program and the scheduler (think about updates...). The third solution was to use a web service. The monitoring solution is able to call a web service and take action depending on the result. With grails, creating the web service is so simple a monkey could do it (even I did it!).

The first step is to create a new grails application:

grails create-app monitor

Then we install the jtopen plugin:

grails install-plugin jtopen

For web service, there are several plugins available. I decided to go with xfire plugin, it is the simplest for me:

If the command did not run successfully, we check the message ID returned by the command processor. If the message is a CPF1002, it means that the data area was already locked, meaning the scheduler is active, so we return true. If we have another message, then something went wrong and we throw an exception.

We just have to specify the as/400 host name, user and password in Config.groovy and that's it.

You can take your favorite soap client (I use Mac SOAP Client) and point it to the wsdl which is created by the xfire plugin at: http://localhost:8080/monitor/services/scheduler?wsdl and test the isSchedulerActive method.

And that's all. No boiler plate code, no infinite xml file to write, just strait to the code.

hi Damien,This looks interesting. Now I'm writing in Java and have certain hassle with dataareas. Our ERP app (written in RPG) uses dataareas to keep last recordnumbers (PKey) for certain tables we also use in Java apps. So we not only need to check the dataaraea to be locked or not, we have to implement a lock-read-increment-write-unlock cycle instead. Do you have any idea how this could work? We found and used the dataarea class in jt400.jar (IBM toolbox for java) for read and write but found no locking functionality..Regards, Stephan