Mobile and i

For a variety of reasons we have been increasingly looking at the mobile world of late. We freely confess though that we do not fully understand the need that many people seem to have to be constantly connected. When we were trying to have some down time recently the Facebook app on Susan's iPhone nearly drove us crazy. We really don't care if you have just arrived at the XYZ grocery store and we certainly don't need to have that non-information shouted at us. It does seem to only push notifications for close friends--not all--but we don't want push notifications at all; we did turn of all the push notification options we could find. So if anyone knows how to have the FB app on your smartphone _without_ having the stupid thing keep notifying you of everything please let us know.

That said, we're not complete luddites. We do see a great deal of potential in these devices for personal use and of course for business applications too. We love our iPad. It keeps us entertained and has a big enough screen to allow us to do real work as well, from writing articles to reading emails. We like our iPhone a lot too (not so happy with our Android phone, but that's another story) but can't use it for real work as the screen is just too small for our old eyes. However, it was certainly useful recently when we were shopping for things for our new house. By using the built-in camera and a bar-code scanner app we were able to find reviews of the items we were looking for and compare prices with other stores. That is a useful application of technology.

Similarly many business applications can be enhanced through the use of a mobile application. Consider an insurance assessor being dispatched to view damage to an automobile or house. Using a mobile device he can receive details of the location, navigate there using the built-in GPS, then complete the required forms, attach pictures, voice notes, etc. He can "sign" the paperwork and the whole thing can be wrapped up quickly and efficiently. It would, of course, be foolish to think that our insurance rates would drop as a result but. ...

In our own IBM i world the term "mobile" crops up more often in our mailbox than "cloud" and almost certainly with more justification for the average shop. Just how important is mobile? Well, if you have any doubts take a look at this review of the latest report from analytics firm Flurry. To quote from the review:

" ...  the rate of these smartphones and tablets adoption is 10 times faster than that of PCs in the 1980s. ..."

Ten times! And you thought you had problems when people started demanding to connect their office PCs to the system! Think about it, that was a significant problem for many of us not so many years ago.

If you aren't already looking at mobile applications you should be. For some it could be the thing that helps cement the IBM i within your organization. Oh, and by the way, that insurance company application we mentioned? The majority of that can be handled by free software, and you know how we love free! Lansa's free LongReach tool can provide the mobile underpinnings for much of what we talked about in this blog entry. We won't go into detail as we've covered it before, but check it out. If nothing else it might give you some ideas.

Happy Memories of a Good Friend

We were recently reminded that it is almost two years since our good friend and IBM i guru, Simon Coulter, passed on. This memory was triggered by the appearance of the first of a new series of articles titled, "Simon's Solutions." These columns are being written by Junlei Li, a young software engineer from Tianjin, China.Junlei has been working on the IBM i platform since 2005 and had come to regard Simon as something of a mentor. When he decided to write on topics that Simon had helped him understand in his early days, he asked Simon's partner, Gwen, if she thought it would be OK to remember Simon this way. Gwen was thrilled, and having read the first column, we know Simon would have been happy to see that his work continues to find an audience.

Junlei is definitely a name to watch and his output is prodigious. His i5 Programmer's Toolkit contains not only a number of useful tools, particularly for those with a bent towards system programming, but also contains prototypes for just about every MI instruction you might conceivably want to use from RPG--and indeed a few you'll probably never ever want to use. Check out the site; you're bound to find something of value there. It seems appropriate that this young man honor one of his mentors in this way.

The first column explains the methods that Simon derived for determining which subsystem a job was running in (among other things). If you'd like to read it you'll find it here. Note that at the end it includes a really nice biography of Simon, written in conjunction with Gwen, which revealed a number of things that we didn't know before.

Thanks to our friend, Paul Tuohy, those of you who knew Simon through his posts on Midrange.com or elsewhere but had no idea what he looked like can now fill that gap. This photo was taken in Ireland when Simon and Gwen visited Paul. It is a rarity since they both hated having their pictures taken. In fact the only pictures we have of them are somewhere in the basement on 35mm negatives. It does clearly show Simon's infectious smile, but sadly not his lustrous red hair, which always made Susan just a teeny bit jealous.

We were involved with Simon on many projects over the years. He was one of the non-lab IBMers that were consulted about what later became RPG IV. Simon was also among the well-known RPGers that we interviewed when writing the RPG redbook, "Who Knew You Could Do that with RPG."

The RPG and IBM i community is definitely richer for having had someone as dedicated to the community and the platform as Simon. He was known for his strong opinions and his RTFM-type responses to those developers who didn't do their homework. But even more so, he was known for giving thoughtful and detailed responses to developers who had more complex questions. He was incredibly intelligent and eager to share his talents with anyone who seriously wanted to learn.

Gwen still has quite a number of older RPG and iSeries-AS/400-System i books that belonged to Simon. If anyone is interested in seeing the list of books, let us know. Gwen is happy to give them away to good homes if you can pay for packing and shipping, which could be expensive since Gwen is in Australia.

We are delighted to have had the chance to get to know Simon personally. We've never been so grateful for Skype than late one evening when Simon pinged us and we had a great chat with him. We talked about his illness, among other things. We heard only a few days later that he had died. He was the same old Simon to the end--chatty, opinionated and happy.



 

AMTS: PDM Without PDM

You don't have to have been following our blog for long to know that we love RDP (Rational Developer for Power Systems) and use it every day. That's not to say that we never use PDM. As a matter of fact, we both use PDM quite a lot. We just don't use it to start an SEU edit session, particularly for our RPG, COBOL or DDS code.

We use PDM mostly for source and object management. It's quite useful for moving things around from place to place, doing the same thing to many items in a list via user-defined options, even doing compiles sometimes, especially if we have need to do a mass-recompile of many members at the same time. For some tasks (editing RPG source code _not_ being one of them) we find PDM lists a very productive way to work. Sure we can do all of those things from RDP as well, but often PDM and the green screen response time just works better for us.

Most RPG and COBOL shops have probably had the ADTS product (the IBM product that contains PDM, SEU, SDA, RLU, etc.) on their systems for decades. When IBM changed the licensing scheme with 6.1 to a "per developer" one, most shops had enough developer licenses of ADTS grandfathered to them (what IBM calls entitlement) so that most or all of their programmers could continue using PDM without paying additional license fees for ADTS.

Sadly, no similar entitlement was afforded to cover those of us who used RSE packaged in WDSC--not unless you were one of the tiny number of licensees of the Advanced Edition of WDSC. It does seem a bit strange that the new tool IBM wants us all to use costs extra, but we can keep using the old stuff they want us to give up for free. But we digress. …

There is clearly much overlap in functionality between RDP and ADTS--almost a complete overlap. So what about new development shops? Say you're purchasing a new system where developers will work and so you don't have an entitled (free) licenses of ADTS. Must you buy licenses of RDP and ADTS along with a license for RDP for every programmer?

Some would say no--just let the programmers use RDP for everything. They don't strictly need PDM for anything. But we think developers would really miss having PDM as an object/member management tool. (Note that we're not even considering the option that developers will use only PDM/SEU--a life without RSE is something no developer should be subjected to!)

Enter a new tool from Rational--and a well-kept secret--Application Management ToolSet (AMTS). AMTS is a cut-down version of PDM that does not support editing RPG, COBOL or DDS. But you can edit CL, commands and simple text type members with it using SEU. You can also do most other object/member management type of functions with it. Familiar commands such as WRKOBJPDM become WRKOBJAMT instead, but can still do most everything except editing code--with the notable exception of CL code. Since it doesn't support DDS development, it makes sense that it also does not have support for SDA and RLU, nor does it support ISDB or DFU.

IBM quietly announced AMTS in April of this year. It seems mostly targeted to operations and systems management staff who do a little CL and command development from time to time, but no RPG or COBOL programming. For those folks, RDP would tend to be overkill (and let's face it, as wonderful as RDP is at editing RPG/COBOL/DDS, CL is not its strong suit).

From IBM's perspective, it would seem to be a bit of niche product for those who don't do development for a living. However, we think it will eventually be widely used as a host-based complement to RDP in new shops that don't have entitled licenses to ADTS.

We feel it is important for professional developers to have a full set of tools that allow them to work productively. For editing RPG code and some kinds of management tasks, RDP is by far the best tool. But for those many situations when you just can't beat PDM for productivity, well, you may not have PDM, but there's little reason not to have AMT instead. It's cheap as it's not licensed per developer, as nearly all the other Rational products are. There is a (small) fee per system for AMTS. In the U.S., for a system up to a P20 tier, we understand it costs around $300 for use by everyone. At that price, we suspect nearly every new system will go out the door with an AMTS license.

Welcome to the IBM i development family, AMTS! We can imagine that one of the first things many experienced IBM i developers using AMTS will do is to create their own commands named WRKOBJPDM, WRKLIBPDM, WRKMBRPDM, which simply map to WRKOBJAMT, WRKLIBAMT, WRKMBRAMT, because our fingers as just too well trained to the PDM commands!

The Why and How of Moving From SEU to RSE

We published the first couple of installments of our newly updated "RSE Quick Start Guide" in the IBM i EXTRA newsletter over the last month or so. There we promised to update you when the rest of the guide was available for download. 

It is now available from the System i Developer downloads page. So if you have been looking to get started with RSE yourself, take a look. And for you RSE veterans out there who have been looking for a way to chip away at the excuses from your SEU-laden colleagues, maybe the guide can help.

We wrote the Guide to be very task-oriented, but there is a very small piece near the beginning that discusses why one should consider moving from SEU to RSE. The hardest part about writing that section was deciding which things to highlight from the dozens of reasons that make RSE the obvious choice for us. We were helped by the fact that Susan recently developed a conference session called "My Favorite Things about RSE." She had a lot of difficulty coming up with that list, but at least it was a starting point for paring down the list to 7 favorites for the guide.

Maybe some of you RSE users out there can help us out with future efforts in this area. What are those "killer features" of RSE that make you wonder how you ever managed to write code using only SEU/PDM?

To get the discussion started, here are the 7 features we listed in the Quick Start Guide.

1.  More lines of code on the screen (typically 2 to 3 times what SEU shows)
2.  Filtered source code - by change date, to remove comments, show control flow, etc.
3.  Unlimited levels of Undo & Redo - even after a save and compile
4.  Tab keys work without prompting (and can be customized)
5.  Multiple source members open for edit at once
6.  An Outline view cross referencing all fields (internal and external), subroutines, etc. 
7.  Compile error feedback without closing the source and without spooled file listings

Please let us know via the comments if these features would make your own list of top reasons to code using RSE and which killer features we managed to leave off the list.

 

P.S. If any of you emailed us in the last week or so and didn't get a response, please try again. Our email server recently made some changes to our account and apparently some number of emails just disappeared somehow.