Blog
iDevelop

July 22, 2014

OCEAN Views

Last week we spoke at the OCEAN User Group's annual conference in Costa Mesa in (normally) sunny California. It was great to see that like several other IBM i events lately, their numbers were up from previous years at the main event. They also had excellent attendance at the dinner and keynote session, featuring Alison Butterill talking about modernization and at a pre-conference workshop on Ruby for IBM i.

This year the group also tried out the idea of running in-depth workshops including hands-on Labs on the Saturday after the main event. We taught an introductory RDi class, IBM's Dan Cruikshank taught SQL topics including IBM Data Studio and Larry Bolhuis taught systems management. We're told that there were approximately 100 attendees at the workshops, which means that 100 people gave up part of their weekend to learn--and that is really encouraging.

OCEAN is a great group and if you live in reach of the Orange County, California-area you should definitely be a member.

OCEAN works with a local technical university to host the main conference and the workshops (the keynote and dinner were held at a hotel to accommodate larger numbers in a single session). We've mentioned this idea of using colleges for conferences before. It really can be a practical solution for local user groups that have considered doing events but found hosting them in hotels expensive and inflexible. In fact it does seem to be a bit of a trend with TUG, our local Toronto user group, holding its TEC event at a local college. We have heard that the OMNI group is working on a similar idea for an upcoming event in the Chicago area.

Other Items

In last week's blog we mentioned punch cards in what reader Bob L. considered a derogatory fashion:

"Don't belittle the punched card. Its legacy lives on: after all, that is why you still have to remind those "young young" programmers that the code must start on or after column 8 and end at column 80!!"

We certainly didn't mean to belittle the punch card (except for maybe those silly little 96 column things) they were really useful for writing notes. Jon remembers that in his early days of presenting, notes on punch cards were a godsend because their very size forced you to keep to bullet points so you were never tempted to just read your presentation. These days he couldn't do that even if he could find a supply as he so rarely wears a jacket to keep them in.

Before we go wanted to thank those readers of our recent article on tools to help you trace program execution, "Tracing Our Steps," who pointed out alternative tools. We haven't had a chance to check them all out yet but we will do so and report back in the article comments and also here in the blog.

We actually get to spend the next two weeks at home, which will be a rare treat this summer. Who knows? Maybe one or two chores around the house might even get done!

July 15, 2014

Programming Highs and Tire Lows

Last week we experienced an interesting mix of high and low points.

The big high for us was teaching a class of Java programmers about the joys of RPG. We also spent a little time on RDi, but since they already used Rational Application Developer for their Java work that was mostly just to introduce them to the IBM i specific features.

Three things helped make this an enjoyable class to teach:

  1. The students were all young--and we don't mean young in our terms (i.e., anyone less than 50) we mean young young.
  2. They were all enthusiastic and asked the right questions, which clearly showed that they were not only understanding the language but also getting a feel for its power and simplicity. We'll be going back to complete their training later this year once the students have had a chance to absorb the initial lessons and we're looking forward to it.
  3. This was our first opportunity to teach the new all-free-form RPG flavor of the language. While it was a lot more work to retrofit our teaching materials than we had anticipated (never thought about how many of the examples have F, D and P specs in them!), what a difference it makes when teaching RPG to Java (or C/C++/C# or PHP, etc) developers. Those pesky columns--even when just for data declarations--always caused so much consternation in past classes. This time, the only hitch was the occasional need to remind them that the code must start on or after column 8 and end at column 80.


This class has reaffirmed our belief that all too often, trying to replace your retiring RPG programmers with experienced RPGers is a waste of time. Not that there aren't good RPGers out there looking for work, but most are too expensive for companies are looking for junior to intermediate level staff. Either that or their "30 years of experience" is actually three years repeated 10 times over because they are so reluctant to learn new skills. Case in point--and one of the lows of the week--we had an email concerning a shop where the staff (we won't dignify them by using the terms "programmers", "developers" or "RPGers") are busily stripping out things like embedded SQL and prototyped program calls whenever they have to maintain a modern program because they can't be bothered to learn this "new-fangled stuff." They probably rue the passing of the tabulator and the punched card too. Sad, so sad. No wonder the shop is moving away from the IBM i.

The other high/low mixture of the week concerned our rental car. Very soon after we set off from the airport a low tire pressure warning appeared. We checked but the tire appeared to be fine. Given that rental car companies often do a lousy job of what would be the PDI (pre-delivery inspection) at your local car dealer we have encountered such false warnings many times before. We kept checking but despite the warning light the tire appeared fine. Until it wasn't. Suddenly it lost pressure so we took it to the local tire store to see if they could fix it. Nope. It had a side wall leak, which couldn't be plugged. No problem, they inflated the tire again and we called the rental car company. "Yes sir - we will happily exchange your car. Just drive to your nearest location and they will help you." Fine except only corporate locations would do and the nearest was a 90+ minute round trip away and it was already getting late in the day. It was a slow leak so hopefully it would last until the next evening when we could drive down and swap the car.

The next morning arrived sunny, hot and humid with the tire completely flat. Changing a tire while in work clothes and 95 degree weather had not been high on Jon's wish list for the day but. ...

Luckily that was the end of the lows. We drove the car back to the rental company and, to cut a long story short, the only replacement vehicle they had available was a Mercedes 350. Not a bad swap for a Chevy Impala! Only problem is that Jon is enjoying driving it so much that he wants to keep it. Sadly that is not on the cards but at least we get to use it for a few more days.

  

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 Midrange.com 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.