The Austin Challenge!

Bummer if you are not here in Austin for the Common Annual Conference.  Perhaps you have heard of ‘Austin City Limits’ a program that showcases Austin’s music and night life (its all true!) Or maybe you have heard of that intimate gathering of music and tech aficionados  called South by Southwest (SXSW)?  Anyway, Austin is buzzin with IBM i excitement and all it takes for me to get a flare up of creative energy is a fun environment and a little free time.  So when I saw a post by Eric Lehti on Midrange-L that said of the iPhone application: “It does not list the Austin Barbeque restaurants in this release though. Big fail!” I thought “Why not add that to a REAL application like the Common Scheduler Organizer I developed for Android?”  Not hobbled by IOS I went ahead and knocked it out for Eric.  Sorry Eric, I haven’t compiled and deployed it for iPhone yet so you’ll have to use the web application version found here.  If the rest of you happen to be fortunate enough to be running Android, go ahead and download the APK found here (use ‘save as’ or navigate to the link with your Android device).

Downloading the new APK may wipe any additions to your personal grid that you have already added (working on how to do that smoothly).  You might also have to hit F5 refresh on the web application version to get the list of Austin restaurants.   The list isn’t JUST barbeque places but I was in a board meeting all yesterday, out with friends last night, running in the Common Cares 5k this morning so I have only had a few minutes to throw this together.


Posted in Uncategorized | Comments Off on The Austin Challenge!

Common Schedule Organizer 2013

Just in the nick of time, the Common Schedule Organizer, a free mobile app for Android, is now available!  There isn’t much new functionality (always willing to take suggestions) but it has been updated with the latest Phonegap libraries and the latest jQuery mobile.  It is still written for Android 2.1 devices and up so even that ancient Samsung Galaxy Spica I own can run the app.  It is still lean and mean and can be downloaded here.

If this is the first time you have used the app, you will be prompted for your email address that you use to access the Personal Grid on the Common website.  Your personal grid information will be pulled into the app but remember it is a one way street: As you add items to your schedule in the CSO they will NOT update your personal grid info (still working on the best way to handle it both ways).

Once you have entered that info and are on the main app screen, click on the “Load Schedule” button.  It will turn yellow and after 30 seconds or so you will see a “Loading” message appear and flash on the screen.  It took me about 2 minutes to download the initial schedule.  At that point the message should change to “Ready” and you are ready to go.  If you have personal grid items, go ahead and visit your schedule to make sure they downloaded.  From then on you can update the schedules, both the master schedule and the personal grid info and it will update the app with the latest and greatest.

If you have something other than an Android device, you can use the web application version of the app.  It will still save your stuff to the device you use so it is still plenty handy it just won’t be “native”.  You will find the web application available here.

If you have a question or a suggestion you can always email me (you know my name) at the company domain (valadd dot com).  I’ll try to get back to you and patch things as necessary.

See you at the conference!  Enjoy!

Posted in Uncategorized | Comments Off on Common Schedule Organizer 2013

Rational comes through

Or maybe it was just IBM….but in any case I would be remiss if I didn’t post that after multiple emails and phone calls my friends at IBM/Rational found a way to sort through the licensing, notices and documentation and get the SWMA renewals sorted out!  I have put the SWMA dates into my calendar so that I won’t miss the boat the next time around and I can always hope that next year everything will go smoothly…well, I can always hope.

Thanks Rational team!

Posted in Uncategorized | Comments Off on Rational comes through

More (ir)-Rationality

I love Rational tools but as I mentioned to my IBM sales representative “I am beginning to suspect that the Rational Marketing team has never left the 60’s and is still “tripping” when they decide to put their pricing together.  That or they took their sales class from PT Barnum (“There’s a sucker born every minute…”). ”  The source of the pain here is that as a developer enrolled in IBM’s wonderful (and it IS wonderful) developer discount program, I had two primary complaints:

1) You receive no notification of expiring Software Maintenance Agreements (SWMA)

2) Trying to sort out what the final costs will be based on the various discounts and product ID’s is nothing short of alchemy….

#1, I am happy to say, has been “fixed”.  I did receive notification that my SWMA was expiring. But every year is an adventure and this year was no exception! The IBM OS and licensed programs are very simple, I never have a problem with them.  But when it comes to the Rational products, you can never really know how the pricing will come out.  Fortunately, I only have ONE Rational product – RDP (it has been through many naming conventions: WDSc, WDSCi, RDi, RDP and if I can believe what my IBM sales rep says, it is now RDG) but the constant name game leads to confusion every year as to *what* exactly, needs software support.  This year I was finally able to narrow it down to my two licenses of RDG.  “Send me the quote” I said!

What I received first surprised and then confused me.  The quote I *thought* I would receive was $548 for *both* my licenses. You have to remember that this is a developer *discount* program and everything on the i IS heavily discounted.  Everything BUT the Rational tools.  The cost of the OS (nada).  The cost of the supporting OS products, nada!  Cost of the Rational tools? 131% of list!  Yeah, you read that correctly.  For a developer ‘discount’ program the actual tools cost you MORE than if you purchased them retail.  Tis the “Smarter Planet” at work at IBM!  I am just hoping that Microsoft (which *discounts* it’s tools) doesn’t catch wind of this cash cow approachfor IBM…..

My SWMA on *each* copy of RDG is $548.  My cost if I buy a license with 1 year of support from IBM “retail”: $416.00  You would *think* that a developer discount would produce a *lower* cost for the developer.  Gee, I wonder why RPG developers *don’t* move to use Rational tooling?  Hmmm, could it be the (ir)-Rational pricing?

Just once I would love to be surprised in a happy way by Rational pricing.  Developers should get a discount when there is a ‘developer discount’ offering don’t you think?  Apparently the Rational division thinks not…..

Posted in Uncategorized | Comments Off on More (ir)-Rationality

Mobile application development and IBM i (Part four) – Mobilize me!

So we have this great little 5250 application which is now just an ugly web application.  Truth is, this thing is so lightweight that as a web application, it is pretty snappy.  But, not ALL applications are going to be this light weight and unless your standards are as low as mine when it comes to GUI, you’ll want to make this a *little* prettier.  Here is where we are, so far:

The great news is that with CSS3 and HTML5 the road from ugly to beautiful is short and sweet.  We just need to add a bit of css and perhaps a javascript library to improve things.  But there is some redesign needed as well, especially since we are now going to add some more heft to the size of the application.  Our original design had two separate CGI programs which basically presented the two screens of information.  In each case a page is constructed at the server end and sent back to the browser to be rendered.  Not a great design since a large portion of the page really doesn’t change.  And imagine if we had headers, footers and graphics on the page as well.  All that back and forth can eat bandwidth and breaks our “good citizen” rule.  So we need a new approach.

First, we are going to change from multiple pages to a single page.  In jQuery mobile, the “trick” that is used is to define a div and treat it as if it were a page.  With jQuery, jQuery mobile and the css added to the file, we can start to redesign the page like so:


<div data-role=”page” id=”main” data-theme=”b” >


<div data-role=”page” id=”punches” data-theme=”b” >



That creates two “pages” for jQuery mobile to work with.  The library takes care of the heavy lifting of showing and hiding the pages as we “page” back and forth.  Make sense?

For the “main” page, the first page we see that has the last punch and current time and date information as well as the buttons, there really isn’t all that much difference between the “classic” CGI page and our mobile page.  We have a table with our information formatted into it.  The “punches” page, where we list the information on the punches returned from the server, hasn’t changed all that much either except on both pages the /% %/ variable delimiters are gone because we are not making the round trip to the server so our CGI program no longer has to dump the information into the variables.  So how, you ask, are we going to get data into the HTML forms?  Ah! For that we use the magic of AJAX, JSON and the jQuery libraries.


AJAX is the easiest part to understand.  All AJAX does is send a small bit of data to the server (think of it as a miniscule web page) which the server reads and executes.  That execution may return data, or it may not (usually does).  The server packages up the data and sends it back to the AJAX requestor. At that point, the function that called the AJAX deals with the response.


The second piece, JSON, is a little harder to understand.  Basically, JSON is just a string of data in a particular format.  Basically the format is this:  { “name”:value}.  Deceptively simple but very powerful because if you know anything about JavaScript you know that looks very similar to an object definition in JavaScript.  So, as an example, if we wanted to create an object called Person and add some attributes to it you would do it something like this:

personObj=new Object();

But we could also do it like this:

And when we needed to get values from the object we would do it like so:

var first = personObj.firstname;

It shouldn’t take much of your brain’s CPU cycles to think: Hey, wait a minute!  If I had a string formatted like so on the server: ‘{firstname:”John”,lastname:”Doe”,age:50,eyecolor:”blue”}’ and I returned that string to my web page with an AJAX call,  I can create objects of data on the client without much effort!  Pseudocode would be something like:
var personObj = getJsonFromAjax();  Nice!  That is EXACTLY what we will do with a little help from jQuery.


If we want to start hooking some of this stuff up, let’s begin by assuming that we have returned a JSON formatted string to our client application.  jQuery pretty much handles all of the heavy lifting:

jsonURL =  ‘cgi_mobile.pgm?action=getList’;  // URL that calls our CGI program on the server

url: jsonURL,
async: false,
cache: false,
success: function(data){

jsonContent = $.parseJSON(data);
alert(‘(JSON exception)’);
return false;

This code snippet would call the cgi_mobile.pgm and pass the action ‘getList’ and then the program would return that list in a JSON formatted string which is parsed back to an object using the $.parseJSON function in jQuery.  You can take a look at the program source but basically the CGI program simply formats the data using a ‘json’ template and sends back the result which is a JSON string.  It does it EXACTLY the way it would take an HTML template and send back HTML.  You can take a look at the jsonlist.json template but there isn’t anything new except it formats the data as a JSON string.

That string is actually an array of JSON objects (because that is the way I formatted it!) so now I have an array of objects and those objects are “punches”.  It looks like this:

[ { “lastPunch”: “IN”, “punchDate”: “12/30/11”, “punchTime”:”07:40:38″ } ,{ “lastPunch”: “IN”, “punchDate”: “12/30/11”, “punchTime”:”08:07:43″}]  In fact, you can see the “raw” data just by calling that action in your browser:

Nothing special.  AND since we now have an object we can iterate through and format our table on the client side with a little bit of javascript:

for(var i =0;i<jsonContent.length;i++)
var rec = jsonContent[i];
html = html + ‘<tr><td><input type=text name=lastPunch id=lastPunch value=’+rec.lastPunch+’ readonly></td>’
html = html + ‘<td><input type=text name=punchDate id=punchDate value=’+rec.punchDate+’ readonly></td>’
html = html + ‘<td><input type=text name=punchTime id=punchTime id=punchTime value=’+rec.punchTime+’ readonly></td></tr>’


Once we have that HTML constructed, jQuery just let’s us stuff the html into the empty body of the table in our “punches” “page”:

$(“#punchList tbody”).html(html);

And then we change the “page” (basically hiding the div we are on and showing the div named “punches”)

Not a whole lot of magic here.  Just taking advantage of the capabilities of AJAX, JSON, and jQuery.

Believe it or not, the hard part is done.  We can easily take this mobile web application and turn it into a mobile “native” application using PhoneGap.  But, that will have to wait until next week (or so).  Remember that you can get this code right here.

OH!  I missed giving you a link to the actual web application.  You will find that here:

Have fun!

Posted in Programming | Tagged , , , , , , | Comments Off on Mobile application development and IBM i (Part four) – Mobilize me!

Mobile application development and IBM i (Part three) – To the web!

So a lengthy delay in getting to the “webby” part of this post due to the holiday distractions.  This new post should, however, get you going again and get the creative juices going.

When last we met I walked through the “green screen” version of the “timeclock” app.  This would actually make a fairly poor mobile application unless you have a 5250 client for your mobile phone (such things do exists!).  But when it comes to mobile applications, either a native application or a web application is the way to go so we’ll start down the initial path of a web application which will eventually end up as a mobile native application.

We are still keeping it simple so you can get the basics under your belt.  So, a quick review.  The basic “cycle” of our RPG application (which doesn’t use ‘the cycle’) is this:

  1. When we enter the program we set some ‘global’ variables that we will use in the program.  Some of them are just initial variables like the ‘punchdate’, ‘punchtime’, the day of the week and initial indicators.  We also call a procedure to get the last punch of the employee (which is always employee ’55’).
  2. We then enter a loop that set’s a couple of indicators and then displays the 5250 screen (EXFMT) and then the program waits for a key event to continue processing. The code below the EXFMT is executed when the button for “Punch IN”, ‘Punch OUT” or exit is clicked (or alternatively when F6,F7 0r F3 are pressed).
  3. The procedure “Punch” does the heavily lifting.  All of this should be easily (!) discernible from the code if I have done my programming job right.

Again the reason for the sub procedures, which we could have coded more procedurally, is so that we could reuse them when we convert the 5250 program into a CGI web program with CGIDEV2. In our 5250 program we have 25 lines of operable code.  In our CGIDEV2 equivalent web program we have 26 lines, so our coding remains pretty much the same. The big difference? Note the missing DOU loop?  How can this work?  In our 5250 app the program loads and remains running until the exit key is pressed.  In our CGIDEV2 program, the web server calls and executes our RPG program but the program does not continue to run.  It is simply called again if the page is requested again. Web programming is essentially stateless.  It doesn’t retain a “context” between calls.  A user in China could access the page and another user in the states could access the page and the program is really clueless about the two locations.  As HTTP server technologies grew and pages became interactive then state was built into the process using a host of approaches, most commonly using and storing session information to track the users connection to the server.  5250 doesn’t suffer from this design so preserving state isn’t an issue in a 5250 program but it is an issue in Web development and although we won’t jump into the approaches it explains the unusual design of our CGI program.  It runs, it’s done.

So looking at the differences in the code. Let’s start with the “screen design” which in this case is bare bones HTML (well *almost* bare bones).  Lets start with the most important components (look at BASIC.HTML in source file HOSTHTML).  Take time to check out the website to understand the basic HTML directives if you are unfamiliar with them.  I don’t plan to dwell deeply on the HTML:

  • /$thepage – this directive gives a name to the section the CGIDEV2 will read and write to the HTTP server.  This is PURELY a CGIDEV2 directive.  PHP, the FreeMarker and Velocity frameworks and a host of other templating frameworks use different conventions for their directives but in this case CGIDEV2 uses this to denote the start of a ‘section’.
  • /%lastPunch%/, /%punchDate%/,/%doweek%/,/%punchTime%/  – These are all ‘placeholders’ in the HTML that will be replaced with data when the form is processed by the RPG CGIDEV2 program. Think of them as the field definitions in your DSPF.  The replacement is handled very automagically for you in 5250 programming.  In CGIDEV2 you need to be a bit more explicit.
  • The rest of the form has standard HTML.  You’ll notice a “hidden” field in the form called PB2.  We’ll use that to store which button was pushed, much like we did in the 5250 program (for comparison sake). We are writing out a table in the HTML using the <table> tags along with <tr> (table row) and <td> (table division – think column).  We draw a couple of buttons with the <input type=button> tags and we call some javascript (within the <script> tags near the top of the HTML) to process the button click events.

Examining the RPG (CGIDEV2) code (CGI_PUNCH.SQLRPGLE).  We have added some infrastructure for CGIDEV2 (all of the copy statements) and you’ll need all of them particularly don’t forget the prolog3 copybook (don’t ask me why I mention it….).  Outside the inclusion of some additional variables and copybooks, it looks pretty similar to our original.  With the following changes:

  • PunchBtn = %trim(zhbgetvar(‘PB2’)); – Remember that hidden text field? It is updated by the javascript on our HTML form but then read here in the program using the CGIDEV2 procedure zhbgetvar which basically pulls it from the HTML that was read in.
  • gethtml(‘HOSTSHTML’:’MOBILEREM’:’BASIC’); – Grabs the HTML for our page so we can write new data to it before it is sent back to the browser.
  • getLastPunch(employee); We run this procedure here because the “punch” procedures above could have just recorded a punch so we want to retrieve those values before we write them back to the page.
  • updhtmlvar(‘lastPunch’:lastPunch); All of the updhtmlvar calls write the data to the retrieved HTML page into the replacement fields we have identified.  The /%lastPunch%/ directive in the HTML will be replaced with the data in the lastPunch variable found in our RPG.  There is no need to name these the same.  The value on the left (‘lastPunch’) is replaced by the contents on the right (host variable :lastPunch) simple as that. Note that we ALSO update the hidden field PB2 with a ‘0’ so that our ‘button state’ is reset.
  • wrtsection(‘thepage’); Actually in this first iteration we have only one “section” which is the whole page.  wrtsection writes data to the server.
  • exit – just a cleanup routine that tells the server than we are done writing data.  It is flushed out to the browser at this point.

So that is basically it.  A web based app which *could* be called from a mobile device browser if you wanted to. It is pretty lightweight so it should be fairly performant.  In the first post on this subject, I talked about being a good citizen when it comes to data transfer – move as little data as possible.  We can improve this data movement and we will explore those options when we make this app much more mobile friendly.

What does this look like.  Well, like our 5250 app, it ain’t much to look at:












Missing is the “Exit” button.  Simply close the browser window to exit!  You’ll notice I added a small feature improvement in the web version of our timeclock you can now list the punches that have been recorded.  Not much of a feature improvement but, one step at a time!  Here is what that page looks like:


You can check out the code which you can download from here: The code is compiled for V6R1 (IBM i 6.1).  I’ll try to get it recompiled *PRV so it will be happy about a download for V5RM0.

The next step is to use HTML5 to dress up the web pages, add a little JSON and Ajax and make this a bit more mobile friendly!  Coming soon!  Happy New Year!


Posted in Uncategorized | Comments Off on Mobile application development and IBM i (Part three) – To the web!

Mobile application development and IBM i (part Deux)

Running a little later on this second post because I had to write a 5250 green screen version of our timeclock punch program.  Like most new things I do, I try to actually learn something new when I go forward with a new project.  ALWAYS!  So there is rarely any same ol, same ol when I write code.  If you are writing the same code over and over for every application you create you are just a programmer.  If you try a new approach or a new language feature every time you write an application then you are a developer.  If you try new approaches and new language features and wholly new languages every time you develop an application, well, you are a nutcase like I am.  But I thrive on new stuff so…..

OK!  So here is what the application does:

When you run the app you see a screen with a Punch In, Punch Out, and Exit button (Using MOUBTN was the “new” thing for me).  The screen displays the time, the date and the last punch on the clock.  If you click on the ‘Punch IN’ button OR Press F6, an IN punch is recorded and the program exits.  If you click on the ‘Punch OUT’ button OR press F7, an OUT punch is recorded and the program exits.  If you click on the ‘Exit’ button OR press F3, the program exits.

The application screen looks like this:

MOUBTN may not be supported on your 5250 emulator and that is why I include the function keys as well.  Also, you may say, “Where is the security here? Anyone who can run the program can punch in as employee 55”! Yep. You didn’t think I was going to do ALL the work for you did you?  Besides that is a trivial plumbing job and would have to be adapted to your employee master file anyway.

So, where is the code?  You can download the zip that contains the save file here:

The source is included in the save file and it was saved at V5R4M0 ( I am running 6.1 and 7.1 in two partitions).  The text version of the program source can be found here and the text version of the DDS can be found here. It ain’t the prettiest code but the FBU  (functional but ugly) approach always works for me.

Go ahead and run the program a few times to get the gist of it.  It’s pretty simple and I plan to follow the KISS pattern for the remaining steps that take that 5250 stuff to the web and then mobile web world.

So you are still chomping at the bit to write some Mobile app code?  Ok, Ok, I hear you. The next installment will be a web version of our 5250 Punch Clock program and from then on it just gets easier and easier….(honest).

Posted in Uncategorized | Comments Off on Mobile application development and IBM i (part Deux)

Mobile application development and IBM i (part 1)

This is part one of a XX part series on mobile application development for IBM i.  I say XX since I really have no idea of how many parts it will take to make it whole. I’ll just keep going until you say “STOP!”.

Notice I didn’t set the title to be Mobile application development ON IBM i because the i isn’t a mobile device (yet…someday the Power chip will power a mobile device…).  Where the i comes into play of course is in application *serving* and it serves that purpose well.  We will eventually take a look at a CGIDEV2 application, a PHP application, and a Java application. Actually, *just* the IBM i HTTP server could do the job in the simplest of cases.  In other words, any application server language supported by the i could be used which includes Rails and Grails (Ruby and Groovy) and if I can come up with an application that I could write for each language and framework, I will.  Actually, the *server* side of the equation is the easiet to solve because my experience is that the world of mobile application development revolves around HTML5 and Javascript on the client. The server, well, it just serves the application (DUH!).

So let me flesh that out a bit.  I would guess that perhaps 90% of mobile applications that would come out of an IBM i shop would be scaled down versions of the 5250 and web applications that an i would typically be serving.  Of course the 5250 app would be written in RPG (ILE RPG) and would be a ‘classic’ green screen application.  If the shop was delivering web applications to it’s users, then I would again guess that PHP and CGIDEV2 (RPG) would be right up there at the top of the list with Java further down. EGL would probably make a showing on the list and  there would also be a smattering of 5250 modernization applications with a single digit presence like web facing, Look Software, and a host of others (again I am GUESSING so no flames for getting it wrong).  Of the remaining 10% of mobile applications, there might be another 5% that have no 5250/web analog on i because it truly needs to run on a mobile OS (e.g. uses geolocation and/or accelerometer or other function) and the remaining 5% need some “from scratch” in a native language development for some other reason (iPhone, iPad, iDontCare…etc).  So, if you are in the 90% listed above, that is, a shop that needs a mobile web application presence, then I think I’ll be able to help you along.

We still have some legwork to do.  Depending upon the design of the 5250 application and/or the web application that is served on IBM i, the question is, how well designed is the current application?  If it is an RPG app, is it modular with a clear separation of UI, business logic and database I/O?  If not, you will probably want to skip from RPG directly to something like PHP because there won’t be much in  your code that can be leveraged for your mobile web application.  If it IS modular, well designed code, you can probably take it from the 5250 world into the web world using something like CGIDEV2.  With CGIDEV2 you’ll still be writing your code in RPG and you can use existing modules to handle some of the functionality. The alternative to CGIDEV2 would be PHP (which is NOT an RPG derivative) because rumor has it PHP is an easier jump for RPG programmers.  I went from RPG to Java with nary a hiccup so there is no one size fits all RPG to ??? language transition.  I also code in PHP and in Ruby as well.  EGL is cool and has greatly matured over the last couple of years.  But, in any case, I’ll try to give you analogs in as many different languages as I can.  Certainly one will work for you.

One thing you WILL have to learn is HTML5 and Javascript.  On the client side of the equation (the mobile device side) you really can’t avoid learning HTML5 and Javascript.  You can do VERY cool things with these tools and you will soon see the value of investing some time in learning them.  For mobile web applications that are NOT going to use a mobile device’s capabilities like geolocation, accelerometer, etc you can pretty much write, test and deploy using the browser on your PC or laptop with the caveat that you will have very little real estate to play with when you deploy to the mobile device.  But what I like about mobile *web* application development is that it doesn’t take a special IDE to design the application interface, you could do it with a text editor on your PC.

OK! I hope that is enough to wet your appetite.  In the next installment (weekly or better) I’ll take you through some design considerations that should help shape your mobile web application design.

Posted in Uncategorized | Comments Off on Mobile application development and IBM i (part 1)

Glassfish on IBM i

I am a *little* biased in that I think  IBM i on Power is the greatest server platform on the planet but you really can’t blame me since it seems that it can run just about any app you can throw at it (well, any non-Windows based app). Over a year ago I had attempted to get Glassfish running on i because I had heard good things about it and wanted to give it a whirl.  It actually started with a Ruby CMS application called Radiant that I wanted to run to demonstrate that yes, Ruby can run on i.  This particular implementation suggested Glassfish as the web server.  First I tried a full blown copy of Glassfish (3.0.1) but got a couple of very strange errors that seemed related to the IBM J9 JVM and after running them down with marginal success, I decided to install the Glassfish gem, which, surprisingly, ran just fine on i.  I documented the issues to both Oracle and IBM and moved on. (BTW you can check out the Ruby on IBM i site here)

The primary issue with the full Glassfish implementation was that the Admin console wouldn’t display and it was definitely due to the J9 JVM. The actual server would run fine.  You could auto-deploy and run servlets and other apps but you couldn’t manage them.  One of things I liked about Glassfish was the administration console, so not having a console made using Glassfish a non-starter for me.

What a difference a year or so makes.  Oracle released Glassfish 3.1.1 and that seems to have solved the Admin console issue for me.  There is still one open issue now, but there is a workaround, so using Glassfish in production on IBM i is now a reality.  Here is all you need to do:

I downloaded the aix zip version of Glassfish 3.1.1 and just expanded it to the IFS.  I made some changes to the domain.xml file to point to the correct IP and ports I needed and I removed references to the -server and -client java directives (they had given me trouble before, so I
commented them out).  I changed the MaxPermSize as well ( -XX:MaxPermSize=384m ).  That was about it.  I am running Java 6, 32bit
and I am pretty current on Group PTF’s.

I came across one additional issue when running Liferay on Glassfish on IBM i: There was a java.lang.NoSuchMethodException: error.  Turns out that this was patched for AIX on a previous build but that patch is conditional on the system property returning ‘AIX’.  This should work on i except that PASE returns ‘OS/400 ‘ instead of ‘AIX’ so I have submitted a bug report to Oracle (could hack it myself, I guess) but there is a workaround: the Oracle developer I worked with suggested I pass this argument to the Glassfish start command:

asadmin create-jvm-options

That seems to work fine.  With all that info, you should have no problems using Glassfish on IBM  (FYI: I am running 6.1 and use the Java 6 JVM)

Posted in Uncategorized | 2 Comments

Life with Liferay

Summer is long gone and fall is fading fast, so what happened to me?  Been deep into a project (pro bono, alas) using LifeRay portal.  LifeRay  is an Open Source Portal which is pretty cool. The Open Source version has a long way to go in some areas (documentation would be a good starting place) but some of the functionality out of the box is great (some needs work).

My application is a servlet and wrapping a servlet in a portlet, sharing data between them, was not s trivial task.  I had a long learning curve and was heading into a deep technical dive on the framework when an epiphany rescued me from heading down a technical rabbit hole.  I simply wrapped the servlet in an iframe and constructed the URL for the iframe using jQuery and portlet  parameters from within the hosting jsp.  LifeRay *has* a portlet iFrame but it has the same limitations as the html iframe: Moving data between the portlet and the html/app within the iframe is near impossible to do without getting pretty hacky….

I was able to get the hacky solution to work OK, although I wished I could handle things a little more elegantly.  I also wanted to host a message board (aka forum) but I had nothing but trouble getting the email functionality to work.  In fact I am still dead in the water on the emails sent to the board reaching the forum posts.

The support at the LifeRay forum is so-so.  Too many dead ends on posts of similar problems and many, many similar problems exist without resolution.  If I were the LifeRay team I’d handle the posts that are most frequent with either a solution or an intelligible FAQ in the Wiki.  As it is, I still have posts that were never completely resolved.

I’ll probably continue to use LifeRay because 1. This pro bono project requires it and 2. It seems to be the best Open Source portal solution I can find.  I am not completely satisfied, but hopefully one day you’ll be reading this blog from within LifeRay and all will be well.

Posted in Uncategorized | Comments Off on Life with Liferay