Pete's Wordshop

More (ir)-Rationality

admin — Fri, 13 Apr 2012 17:30:55 +0000

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…..

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

admin — Wed, 08 Feb 2012 04:19:55 +0000

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: http://opensourceoni.com/mobilerem/cgi_punch.pgm

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:

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

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.

JSON

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();
personObj.firstname=”John”;
personObj.lastname=”Doe”;
personObj.age=50;
personObj.eyecolor=”blue”;

But we could also do it like this:
personObj={firstname:”John”,lastname:”Doe”,age:50,eyecolor:”blue”};

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.

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

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

try
{
jsonContent = $.parseJSON(data);
}
catch(err)
{
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:

http://opensourceoni.com/mobilerem/cgi_mobile.pgm?action=getList

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 {
var rec = jsonContent[i];
html = html + ‘’
html = html + ‘’
html = html + ‘’

}

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”)
$.mobile.changePage(“#punches”,’slide’,false,true);

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: http://opensourceoni.com/mobilerem/cgi_mobile.pgm

Have fun!

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

admin — Sat, 31 Dec 2011 20:40:23 +0000

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:

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′).
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).
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 w3schools.com 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 tags along with (table row) and

(table division – think column). We draw a couple of buttons with the tags and we call some javascript (within the