Planet i

If you were wondering where the next opportunity is in IT then PHP might be just the thing for you.

I was reading a newsletter from another IBM i pundit who was disparaging the future of the IBM i & for RPG programmers using a statistical grid from the job trends section of Indeed.com. Indeed.com is a site that tracks IT job opportunities and has a nifty graph that lays them in so you can make comparisons. The best part is that it is very easy to use. The author of the newsletter was trying to diminish RPG as a language with little future because Indeed.com had very few hits. I was not happy with his assessment and posted a response. Unfortunately he is moderating his postings and chose to not allow mine through, as of this writing. So here is what his graphic looks like as he put it forth:



As you can see from this image, the future for the typical RPG programmer looks pretty bleak. That was what the author was trying to portray. But these graphs can be interpreted in many ways. First of all, the entire RPG job market is not very big to begin with. Also, I had gotten my last 3 RPG opportunities via recruiters and they do not post openings via boards like this. As this graphics is display Percentage of opportunities over all, then yes I would agree that there are not nearly as many job opportunities for RPG developers as there are for Java developers, etc. But I could hardly put this on RPG or the IBM i. Another thing to point out is that some of those Java jobs might be on IBM i. That skews the whole equation. What I did when I read the piece and followed the authors link is I added one more language to the chart. This language is called PHP and look at the graphic it created:



In this graphic we can see that the market for PHP developers is on a steep incline. Are any of these opportunities on IBM i? I am not sure. But I have heard of a few IBM i shops leveraging their significant investment in RPG and COBOL while opening up to the open source continuum with PHP. One can also infer fro the above graphic that PHP job growth is far more explosive than many other contemporary languages and that since PHP runs natively on IBM i there might be a future! I believe there is a future to IBM i and that future is made up of many technologies and third party solutions. All should be evaluated and considered when the traditional green screen shop starts looking to go to a GUI solution. And then in the spirit of the season, you select PHP.

The truth, as many of you already know is that statistics can be manipulated to support or defend nearly any idea or agenda. Please read as much as you can about a certain topic but do NOT accept any one persons view as the truth without first evaluating it creditability with at least a little Googling.

Happy Holiday's!

Mike

Read the original at Mike's IBM i PHP blog and more....

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

Read the original at Pete's Wordshop.

If we look at Indeed.com and their job trends based on evaluation of job openings, we see the graph depicted below with the grim facts.



This graph is based on the number of open jobs for these languages.  If anyone believes that the iSeries and RPG programming has a future, this pretty tells the story.  If you are a business executive in an IBM i based shop you need to act now before you lose you current staff and cannot replace them.

Take a look at what we do and how we go about it at www.rjcancilla.com.  Maybe we can help. 

Read the original at Bob Cancilla on IBM i.

This blog, alanseiden.com, has been named to the “Best i Blog Bets” top 10 list by Alex Woodie, Senior Editor of IT Jungle.

Thank you to Alex for this honor. This site will continue to offer articles, presentations, event listings, and news about PHP, Zend Framework, IBM i, and other topics of interest to the PHP/i community.

Read the original at Alan Seiden's PHP and IBM i Resources.

Last year, I challenged the IBM i community to raise funds for the Al Barsa Memorial Scholarship. Thanks to your contributions and some generous matching grantors, we raised $2,860. I think we can exceed that excellent figure. This time, we have even more matching grantors on board, each one contributing a dollar for dollar match. [...]

Read the original at midrange.com - In My Humble Opinion.

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.

Read the original at Pete's Wordshop.

How to extract the current Year and Month: Define date field: D  ISOdate      S              D   datfmt(*ISO) inz(*SYS)  If...

Visit site to read full content and more

Read the original at ile rpg programming: tips and techniques.

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: com.ibm.lang.management.OperatingSystemMXBeanImpl.getTotalPhysicalMemorySize() error.  Turns out that this was patched for AIX on a previous build but that patch is conditional on the os.name 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 -Dos.name=OS/400-AIX

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)

Read the original at Pete's Wordshop.