July 01, 2014

RCAC: Two Steps Forward ... One Back?

We were recently asked about the impact on existing RPG programs of the new Row and Column Access Control (RCAC) DB2 support in V7.2. For those who haven't yet heard about RCAC, the simplest explanation is that it allows you to control access to data by row (aka record) and by column (aka field). The column control masks specific data from people who don't need (or shouldn't be able) to see it. Think seeing masked data for salary, credit card numbers, etc. The row control simply omits access to the entire row for unauthorized users, much as a select/omit LF with specific user authorizations could do--only it's probably a bit easier to implement.

We haven't fully thought through some of the implications of row control yet. Clearly there is a difference between "These are all the rows that satisfy your query" and "These are all the rows that satisfy your query that you are allowed to see." But how much that matters and its impact on our application design we need to muse on for a while. There appears to be no feedback to tell you that your result set was constrained so we can foresee some interesting debug problems when a user reports that they only received X rows and your tests show Y but I guess we'll get used to it.

Column control is a little different in that you will receive a value--just not the real one. Because you can supply masking values for columns that have limited access rights, this is not much of a problem in handling character fields. We're all used to seeing things like XXXX-XXX-XXX-1057 for a credit card number in an email or report. Character columns can normally be masked with characters that could never otherwise occur in them, and if you wished, these could be standardized for all columns in the shop. As a result testing for a masked column is not that difficult a feature to add to an existing program that processes the table.

Dealing with numeric columns, however, could be a bit more of a problem. While most columns will have some limit (e.g., this column can never contain zero, another can never exceed 50,000, another can never be negative, etc.) they will rarely fit into a single pattern and so a standardized approach won't be possible. In some cases we might need to mask to a negative value, in others to all 9s, etc.

One thing is for sure, you cannot simply apply RCAC to an existing table and program combination and just "let it fly"--particularly if math is involved on the column in question. You need to think through the impact on your code and possibly make adjustments in the logic to accommodate the new situation.

We find ourselves thinking it would be nice if the database returned a status of some kind with each row/set to indicate that some data is "missing" due to RCAC considerations. After all, we've been increasingly using null capable columns to handle situations where a special value in a column just doesn't work. Having to go back to using special values makes it feel as if we have taken two steps forward and one step back, at least from a programmer's perspective.

While this new support is both important and useful, we do feel that the lack of any standardized way to readily detect "lost" data may be problematic. But maybe we just worry too much. What do you think?

June 26, 2014

Tempus Fugit, Don't It?

This week's blog was inspired by a recent trip into the depths of our basement where we came upon ... wait for it ... a brand new boxed set of PC DOS diskettes. How they came to be in our basement, and why they had never been opened remain a mystery, as do much of the rest of the basement's content -- but we digress.

Anyway, after having disposed of the disks in the circular filing cabinet (aka garbage can for the uninitiated) we got to thinking about how far things have come in the years since we entered the computing field. When we first started, punch cards were still the primary input medium for most systems. In fact Jon still recalls the actual hole positions for different characters so well that at one time he had a nasty tendency to use them when creating things like Wi-Fi passwords "because it is easy to remember" -- a sentiment which was not shared by Susan and as a result is no longer used in our household.

But old as we may be, punch cards were around long before we got started in IT. Their initial use for data entry was in conjunction with the U.S. Census of 1890, but they had been in use for controlling looms and similar equipment way back in the early 1700s. They remained a major means of data entry until well into the 1970s.

For a relatively short period of time, starting in the mid-1960s, dedicated data-entry systems such as those produced by Mohawk Data Systems and Canada's CCL strove to replace the lowly punch card by providing direct to disk/tape data-entry systems. IBM's entry into this arena was the 3740 range introduced in 1973 and built in good old Rochester, MN. But good as some of these systems were, for smaller companies the cost benefit was just not there. Perhaps that explains IBM's decision to give the humble punch card one last hurrah in the form of the 96-column card. Introduced with the System 3 in 1969, we've never quite understood why IBM ever thought those silly little things were a good idea. Thankfully, although they still carried over into the S/38 line, they soon died a well-deserved death.

The real end of the punch card's lengthy reign came with the introduction of (relatively) low-cost data-entry terminals such as the 5250 line (1977). And this is the point in time at which things really started to speed up.

No sooner had the IBM PC been introduced in 1981 than "real" 5250s began to be replaced by emulators running on PCs. We then began what in retrospect appears to be the inevitable rise of the browser as a means of data entry. Close on the heels of the rise of the browser came the age of the smartphone and tablets and then, after many false starts, the use of voice recognition for data entry.

All that seems to be left is for the "thought keyboard" to be introduced and that will finally signal the end of any tactile involvement in the data-entry process. Whether that is a good idea or not we leave to the reader to decide, but it does seem to be the inevitable end-point in the game.

As with all things in our modern world, it is the speed with which these changes have occurred that leaves us breathless when we look back.

Try drawing up a few such timelines yourself. For example, the transition from jungle drums, to telegraph, to phones, to cell phones to .... Or disk storage (the latest Mac Books for example don't offer a conventional hard drive as a base option - they are all SSD based), or memory (from core to transistor, to ...), or ....


June 17, 2014

Time to get iThusiastic!

Rousing the IBM i community spirit is not a new theme for us (check out "Kindred Spirits in the IBM i Community" among other posts on the topic). That's why we loved reading the recent posts from Von Enselman and (fellow Canadian) Steve Pitcher.

We love Von's clever term, "iThusiasm," which she defines as "… my vehicle and brand to communicate my opinions and support for the IBM i on Power Systems, the professionals who support it and are supported by it, and the user groups (both local and large) that bring us together." Cool! What a great concept. We've known Von through her work with the Omni User Group for years and love her enthusiasm and dedication to "all things i". Give her new blog a read; it's well worth your time.

Steve's post reminds us of the need to help cross-promote content between communities and streams - for example, sharing content you find valuable with your fellow iThusiasts--whether you wrote it or you just read something particularly helpful somewhere--but not just on your "media stream of choice." He suggests we should try not just tweeting about it or posting it to or Facebook or various i-related LinkedIn groups, but perhaps change the "or" to "and" to help to ensure that more IBM i professionals can benefit from it and the IBM i message gets out there.

Good idea, Steve. Jon has already been doing some of this, but we could certainly do a better job of it. Of course, we're personally a little leery of trying to hit all (or even most) of the plethora of LinkedIn groups, as we discussed recently in our blog. But a few posts on some well-chosen LinkedIn groups never hurts. By the way, Steve has some particularly insightful Tweets; consider following him @stevencpitcher.

So if you see posts from people like us (or Steve or Von or …) promoting our latest article or blog posts in multiple places, we hope you don't think we're reaching for the spotlight. Maybe we're reaching for the spotlight, but not for ourselves. We want a spotlight on a much better target--IBM i.

June 11, 2014

Free-Form RPG Surprises

It is nice to know that we can still be surprised.

When we first heard that IBM intended to release a completely** free-form version of RPG, we braced ourselves for the seemingly inevitable flood of negativism that past history indicated would follow the announcement. And to be sure there were a few comments along the lines of "Why are they bothering - that's already available in XXX (insert language of choice here) so why add it to RPG?" and "If IBM thinks that will make the language attractive to new programmers they are nuts." But overall the noise level was far less than we had anticipated, which was a pleasant surprise.

Since then, we have continued to be surprised by how well this new support has been received. In fact the vast majority of programmers we have talked to at conferences and in our private classes have embraced the changes, as have most who commented on the changes in the various online forums we monitor. At the most recent RPG & DB2 Summit, we had to move Barbara Morris's session on the new free-form support to a much bigger room to handle the number of attendees who wanted to attend.

Even those who claim that they probably won't be using the new support themselves have agreed that it will make life much easier for the new programmers in their shop who "really struggle with the fixed-form F and D specs." And that, after all, is the real point of these changes. We need new blood and we need it fast.

In a few weeks we will be delivering an "Introduction to RPG and IBM i" class to a group of Java programmers. This will be the first time where we be teaching nothing but the free-form version of the language in the initial training. Once they have the basics under their belts their co-workers will (hopefully gently) be initiating them in the dark and arcane art of traditional F specs. They will need to learn D specs as well, of course, but they're at least somewhat simpler. Luckily for these RPG newbies, the shop already owns a copy of Linoma's RPG Toolbox so converting existing code to the new format will be easy for them. We're looking forward to it and are sure that the learning curve will be shorter for them than it was for the COBOL, C++ and Java programmers that we have taught in the past year.

Talking of surprises, we've uncovered quite a few pleasant ones (and a couple of "gotchas") in the new support over the past few months. So in this month's IBM i Extra we've put together a list of those we have discovered to date. If you have found any that we have missed please let us know via the comments here or with the article.

(** Yes, we know that I and O specs are still fixed format but if you're still using those, you really shouldn't be.)

June 05, 2014

Technology and Age

Jon has long been a fan of Douglas Adams (author of all five parts of the Hitchhiker's trilogy) and he recently came across a quote from Adams' "The Salmon of Doubt" relating to technology:

I've come up with a set of rules that describe our reactions to technologies:

1. Anything that is in the world when you're born is normal and ordinary and is just a natural part of the way the world works.

2. Anything that's invented between when you're fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.

3. Anything invented after you're thirty-five is against the natural order of things.

The older we get, the more true this seems to be!

The age of 35 may be a little low, especially for IT professionals, because our jobs tend to force us to be a bit more open to new technologies. Although when you consider the number of RPGers still writing in RPG III (albeit in RPG IV fixed form syntax) perhaps not that low. Certainly the older we get, the tougher it seems to be to imagine how (or sometimes even why) we should take advantage of some technologies that cross our paths. For example, we've puzzled over the value of LinkedIn and Jon has even had a rant about automation in public bathrooms.

But challenging as it may be, it's critical to our own futures and that of our beloved IBM i, that we not allow this tendency to keep us completely in our comfortable stage 3 world without exploring all the new technologies that may at first glance seem "against the natural order of things." Google's proposed self-driving cars are an example where we have seen many friends throw up their hands in horror at the very idea.

We're not just talking about "green screens" here (but if the shoe fits ...). Change just for change's sake is not worthwhile, but sometimes maybe we just need to look a little harder at the advantages.

As an example, Jon worked on a webcast recently with the folks at Lansa and was impressed with the native phone/tablet integration of their LongRange mobile tool targeted to RPGers. It often takes seeing a few examples before we catch on to things like how an integrated camera or GPS and mapping software on a handheld device can be integrated into business processes to dramatically improve RPG-based applications. Perhaps those under 35 inherently understand how the use of such technologies can make life and business easier for our users. Us older folk take a little longer.

This reminds us of another point we've made in "Give the Kids a Chance" and "Educating New RPGers." On several occasions, we've suggested that too many IBM i shops waste time searching for experienced IBM i and RPG staff--sometimes even considering moving off the platform because of an inability to find them. As we've suggested before, you really should focus on finding good, creative and energetic business-oriented developers, regardless of the language or platform they currently have experience on or indeed whether they have much experience at all. Teaching those folks IBM i and RPG (the modern, free-format version) is a piece of cake and you may be surprised how many of them love both the platform and the language.

That doesn't necessarily mean they will be young. There are creative and energetic developers over 35 out there looking for work as well. Some may even have RPG and IBM i experience! But if they do happen to fit within Adams' magic 35-year-old boundary, they may bring the added benefit that they more naturally understand how to harness technology to improve business applications.

By the way, we only mention Lansa because we've worked with the company recently but many other IBM i mobile solution providers offer great products--some of which may be a better solution for your own particular situation. It's the idea, not the specific product, we're talking about. We welcome comments on mobile solutions your shop has used or is considering.