RPG Speed Dating

Remember Y2K? It is somewhat mind-blowing to realize just how many years have elapsed since then. We were both working for IBM at the time and were heavily involved in IBM's efforts to provide tools and education to remediate the problem. In fact teaching IBMers and ISVs about IBM's Bypass2000 product took both of us around the world including our first (and to date only) visit to China. It was an interesting time.

One thing that surprised us as we discussed remediation plans with various IBM users was how few intended to take advantage of what we came to know as "real date fields" as part of their strategy. By "real" we mean DDS type L (SQL type DATE) as well as type D fields in RPG. When we questioned the rationale, two major reasons were given:

1. It took up more disk space than the four bytes used to hold a fake date in packed format. In fact this is not true. On disk a real date is held as a 4 byte integer. We just don't get to see it in that format in our programs.

2. A performance penalty was incurred every time a record was read to convert the date from the stored integer to the 8 or 10 character representation that we see in our programs. This of course is true, although much of the time bad RPG programming practice caused the performance hit to be far worse than it needed to be. Our feeling then was that for most shops the advantages far outweighed the performance difference in most cases. We still feel that way.

In recent years we have seen more and more people begin to take advantage of real dates. Many factors are at play in this increased uptake. The increase in the use of SQL and DDL-defined tables is part of the picture. The massive performance improvements in processor and disk speed is another.

But things can still get better, and the good folks on the RPG compiler team decided to add their own performance boost to date- and time-handling. This support actually came about some time ago, but since it was made available via PTF vs. a new release boundary, many people missed hearing about this when it occurred.

This support is available via PTF for both V7.1 (PTF SI43157) and V6.1 (PTF SI43156). It's a new H spec (or Ctl-Opt operation) keyword. The VALIDATE(*NODATETIME) option can speed up programs that do significant amounts of date- and time-handling. It achieves the performance boost by bypassing something you probably didn't even know it was doing - validating _every_ date field _every_ time it is used. Yup, _every_ time it is used.

With this option in play, under some circumstances the compiler will just treat the date as a character field and assume that it contains a valid date and bypass the validation. What circumstances? The following are some examples of cases where validation will not be done. Other circumstances may be added to the list later.

• When one date field is moved to another with the same format and separator. This includes the moves that occur when the field is read from the database, assuming the same format externally and internally, which is not always the case, depending on how the I/O operation is done and/or what the default date format is in the program.
• When a comparison, search or sort operation is being made between *ISO or *JIS formatted dates (i.e., YYYY MM DD) and between times in any format other than *USA. Using this option can have significant performance benefit for programs that handle a lot of dates in these categories. However, remember that some risk is still involved since the compiler will not be validating all date and time values. These are the main points to remember to take the biggest advantage of this new support:
• Make sure your code handles dates and times appropriately and that you are confident of all date values--especially any that may be definted in data structures.
• Strive for date formats and separators that are consistent both in your external database definitions and internally in RPG. Use *ISO (or *JIS) as the format of your date fields wherever feasible to gain the most benefit for comparisons, searching and sorting. Avoid *USA for any time fields.
• Watch out for a DATFMT keyword on H specs (or Ctl-Opt operations). This will change the default format for the program and may inadvertently result in non-ISO formats. If you don't specify DATFMT, the default will be *ISO, which is one of the preferred formats.
• When date data will be moved/assigned in the program, use the same date and time formats and separators as much as feasible. Don't forget that this applies not only to Eval (or heaven forbid, MOVE operations) but also to parameters defined using VALUE or CONST or function return values.
• If your external date fields are not *ISO format, then ensure that those fields are defined in Data Structures so that they will retain their external formats. This way the movement to/from I and O specs by the compiler can use the faster "no validation" option.  

You can get many more details about this support from a notice on the RPG Cafe in DeveloperWorks. On that page, you'll see a PDF attachment with many details and helpful advice on how to make the most of this feature.

The compiler team intends to increase the number of cases where validation is bypassed in subsequent releases, so if you use this option make sure to watch for future announcements in the RPG Cafe that may affect your code.

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.

The Importance of Customer Service

Today we have run the gamut of customer service experiences. For the first time in quite a while, We were flying on Air Canada. There was a time when we flew the airline enough to be among their elite frequent flyers, but not so much in the last few years. This is mainly because we found that they offered subpar customer service compared to their competitors and their frequent flyer rewards program is terrible. (FWIW, we fly primarily American Airlines these days but have also found that Jet Blue offers good service--they just don't serve many of the locations we need.)

Lest you think this is all about flight experiences, we encourage you to read on because we'll strive to make it relevant to our lives as IBM i application developers.

Today, we're using up a few of those last few frequent flyer miles we earned years ago. We had pretty low expectations of customer service. But boy have we been proved wrong. Air Canada had a change of equipment on our flight. As a result, we arrived at the boarding gate to find our seat assignments had been changed without warning. Not only that, we had paid extra for seats with enough legroom to be able to actually open our laptops and write this blog post (among other things). Surprise! Our new seat assignments were in the "normal" no-extra-leg/laptop-room seats. Considering we had paid a premium for the "extra room" seats, this seemed a pretty bad example of customer service, right?

When we complained (as nicely as we could manage at 7 a.m.--we don't do mornings!) about this to the gate agent, she initially told us that we'd be refunded the difference in price. Perhaps it was the look of disappointment on our faces at the thought of spending five-plus hours with our knees up under or chins, but for whatever reason she changed her mind and was able to come up with some seats where we could work. Unfortunately, they were not together. So she worked a little more and went the extra mile to find a way to rearrange some other passengers so that we could all get the type of seats we expected and paid for. Plus, we were able to sit together. Nice work!

Then on the plane, we found that the extensive in-flight entertainment offerings were virtually unusable because neither of our seats had properly functioning headphone jacks. We notified the flight attendant who initially apologized and suggested we try their "special" Air Canada headphones, which were worse than our own. We thought this was the end of that part of the story, although we were happy to see that the flight attendant noted the seat numbers to report the issue so maintenance could try to rectify the problem for future flyers.

It was still disappointing though because this was a long flight and while we had some work to do, we had hoped to kill some time by taking in a movie or TV show or two as well.

But things again changed for the better when a little later, the lead flight attendant came by to bring us vouchers as a small compensation for our inconvenience with the entertainment system. She also offered us a glass of wine. It was only 10 a.m. at this point, but we were sure it was 5 p.m. somewhere, so we said "Yes, thanks!"

The result? We're very pleasantly surprised with the customer service we received at Air Canada--both in the airport and in the air. We hope it's not a fluke and maybe we're seeing a new, more customer-oriented Air Canada that is very different from most of our experiences in the years before. We also saw other similar examples on the same flight. For example, flight attendants moved passengers and their bags into empty seats closer to the front because they had very tight connections due to our flight being 30 minutes late.

While we witnessed several examples of problems with Air Canada today, we also saw excellent examples of staff who took the time to see things from the customer's perspective and find a way to make it right. That's the essence of great customer service and we, and the other passengers affected, are clearly much more likely to fly with Air Canada again than if they had been brushed off in the way we have experienced in the past.

So how is this relevant to an RPG programmer's life? We think all of us are in a position to provide excellent service to our customers--who in our case are the users of our applications. Seeing things from their perspective is a good starting point. Being prepared to apologize when things go wrong and to do your best to make things right surely applies to any job, even programming.

Let's face it, we don't always deliver perfect applications the first time and on time, do we? Maybe we can strive to see if we can go beyond just fixing the problems that arise (while muttering darkly about "darned users"). We can strive to write our code in such a way that it's easier to test (thus causing fewer problems) and easier/faster to maintain and enhance. Using modern language features and modular coding techniques come to mind as ways we might do some of those things.

Excellent customer service should not be limited to retail and other service environments. It should be part of every aspect of everything we do in our working environments.

Dealing With Nulls

Our most recent IBM i EXTRA article covers a bit about dealing with nulls when embedding SQL into RPG. But it is by no means a complete study of all the options.

That fact was quickly pointed out to us by reader Rusty Gadberry from Arkansas Data Services, who offered his much simpler solution. So we thought we'd introduce that solution here and start a discussion on when this might be an appropriate way to deal with nulls

Here's the suggested alternative to our logic:

   Exec SQL   

    Select CustID, CustName, ifnull (CustSales,dec(.00,7,2))

     Into :CustID, :CustName, :CustSales

     From Customer

     Where CustID = :InputCust;

Using the IfNull function, this shop avoids the possibility of indeterminate data coming into the program. We've used this approach sometimes, as well as a similar alternative approach using the Coalesce function shown below. In both cases, if the CustSales column value is null, it will be replaced with a value of zero in the result set returned to the RPG program. 

    Exec SQL

       Select CustID, CustName, Coalesce (CustSales,dec(.00,7,2))

         Into :CustID, :CustName, :CustSales

         From Customer

         Where CustID = :InputCust;

Approaches such as these are certainly simpler (and we like simple!) for those cases where the only logic we would have performed once we discovered a null is to replace the associated column value with a "generic" default.

However, neither of these approaches caters to cases where the "nullness" of a value is significant compared to zero (or some other "default" value). If there weren't such cases, then why were the columns made null-capable in the first place? Perhaps by default/mistake? Admittedly, in the very simplified example in the article, such a distinction is a bit of stretch.

It seems to us that it would often be significant in the case of outer joins to know about the presence of nulls, regardless of whether a column were otherwise null-capable or not. And, of course, date columns rarely have an easy or obvious default value to substitute. So we stand by the need to have a way to interrogate the nullness of a column in many circumstances.

Perhaps this is a good time to encourage you to think about null capability in your databases. Traditionally, it has been rare to have null-capable columns, but since there is a definite difference between the concept of "no value" and a zero, blank or other special value, perhaps we should consider more carefully which columns should be null-capable and which should not (i.e., a blank or zero value in this particular column is not significantly different to null).

Many shops these days are "modernizing" their databases, so this makes it a good time to consider making such changes if/when they make sense. Of course, in doing so, we must also potentially add to the logic of all our RPG (and other language) programs that access that data. We would certainly have to add logic to use %Null when using RPG's "native" I/O. Perhaps for such databases we could even mask this additional complexity by using an OA handler? For those programs using SQL to access the data, the techniques shown here or illustrated in the EXTRA article will need to be utilized.

Of course, you may have your own approaches, which we would love to see you share via the comments!

Letters to Santa Bring New RDi Update

In a blog post a few weeks ago we mentioned that we had the opportunity to test the beta version of the new RDi support for fully free-form RPG and were impressed by it. We had originally thought it would be well into 2014 before this new support became publicly available, but apparently Santa--in the guise of IBM Rational--has delivered support for the new free format H, F and D specs now. We RPGers must have been very good this year!

The support was released as part of the latest fix pack for RDi. That takes it to version 9.0.1. You can get the details of the fixes and enhancements here  and the actual fix pack can be obtained here. Alternatively simply load the Installation Manager and tell it to update the product--that worked for us.

But it's not just about free-format RPG support. Much like letters to Santa, some RDi users have been asking Rational for usability enhancements. And at least four of those requests have been granted--early Christmas presents--as the features requested are included in this new fix pack. You see, we told you it pays to share your suggestions with the folks at Rational! This is done via Requests for Enhancements (RFEs) and we blogged about it quite some time ago. In case you missed it, take a look for the details of how to add your own suggestions to the list.

The RFE enhancements in this fix pack include improvements to the automatic removal of error messages after compiles and enhanced block nesting options. This includes the ability to set the color for the nesting indicators shown by Crtl-Shift-O. This is a small, but useful, change that we like because the old default of black just didn't show up that well.  

There are still a few missing features. For example the wizards for D-specs, Java method call and Subprocedures have not yet been released, but frankly we rarely use those so it is not a problem for us. Assumedly these features may be coming in subsequent fix packs. Considering the early indications were that we might have to wait until February for this new support, it is nice to get an early Christmas present! Thanks, Santa!

Editing the New TR7 Free Format RPG

Just a short blog this week as we know that all you really have time for right now is thoughts of turkey and Black Friday sales. Or at least that is true for our American readers. Our Canadian readers  already had Thanksgiving back in October (which, as usual, we missed because we were running the RPG & DB2 Summit at the time). Canadians still get Black Friday sales courtesy of Canadian retailers who are convinced we'll all do our Christmas shopping in the U.S. if they don't offer sales. They may be right!

The real point of today's post, however, is to give you a heads up on the upcoming support in RDi for the new free-form capabilities added to RPG in V7.1's TR 7. The more we use TR7's free-form coding style the more we like it. Jon has even started coding F specs again as opposed to cloning them! But it is not as easy to use as it should be when your editor insists that everything you key is an error! Of course, for SEU users it will go on being an error since SEU is not being updated.

Unfortunately the update to RDi was not available with TR7, but we were fortunate to have the opportunity to beta test the new support and we must admit we're impressed. Not only is the new RPG syntax fully supported, but the content assist feature (initiated by Control + Space) is even better than normal and will be a huge help to those trying to learn the new syntax. In essence what happens is that if you press Ctrl/Space after coding (say) Dcl-F to declare a file you will be told that a file name is needed, type a name and the assist will list the device types available, and so on. Perhaps even more importantly, we have found that this prompting works well even on existing lines and by simply moving the cursor along a line you can see the definitions for all of the keywords appear. Very useful.

We won't go into any more detail as we are aware that this is a beta version and so not everything is currently working fully, but it is promising and we're looking forward to getting our hands on the real thing when IBM releases it-whenever that is.

Eating the Elephant

 

At conferences, during classes and often in our email there's one statement/question that we get asked over and over: "I know I've let my skills get rusty, I know there's a huge list of things I should learn, but where do I start? It is all so overwhelming."

It is a good question, but the answer is really quite simple. When faced with the task of eating an elephant there is only one way to deal with it--one bite at a time.

But there's a problem with that basic premise. With an elephant, of course, there are at least some obvious potential starting points. Nibble your way up from the tail, or gnaw your way from the tip of the trunk, just for starters. With the type of list most of the questioners are faced with, however, the choices are not quite so obvious. SQL, XML, Web services, mobile apps, HTML, CSS, Javascript, Ruby, etc. Where to start?

To an extent it depends on where you are right now, and whether your current job is steering you in a specific direction. Of course if the latter is the case, the answer is probably a lot more obvious. By "where you are right now" we are talking specifically talking about your RPG skills. For example, if you have yet to embrace the use of subprocedures as a way of life-- not just for reusable components but as a vehicle for structuring your programs--then that is clearly an area that you need to address.

But perhaps the choice is actually easier than that? We think we could make an argument that your first step should be to learn a new language. After all, if you haven't got your head around subprocedures yet then perhaps it is because, like many others, you simply can't see the point. You've managed with subroutines and dynamically called programs for years - why bother to change? Our good friend George Farr often recounts that when people tell him how much they enjoyed his "Java for RPG Programmers" book, he frequently asks if they are doing much Java programming. The answer is invariably the same "No, but it made a huge difference to the way I code RPG!"

Java is, of course, a perfectly valid language to learn, as indeed are Ruby (now available for IBM i) and Python among others. But as we've stated many times, we still feel that PHP is the best choice for most RPG programmers. Why? Because you can use it as a procedural language and gently ease your way into object-oriented (OO) programming without have to totally rewire your brain. We know that many reading this will say that learning to program in OO is easy; why the big deal? We're happy for you. We really are. But personally we have not found that to be the case. As Jon has often publicly stated, "I consider myself to be a failed Java programmer." He learned the syntax and can write and read Java code but doesn't _think_ in OO terms. Slowly but surely PHP is helping to remedy that situation. It also also improved his RPG!

Regardless of your choice of language, we want to make one clear cut recommendation. Sign up with Learnable. It is our go-to resource for all new technologies. Learnable offer books and online classes in everything from PHP to Ruby and HTML to Javascript and mobile app development. At $29 a month (or $15 a month if you sign up for a year), it is a bargain basement way to jump start your new skills. That membership gives you access to their entire library plus the ability to download two books a month. Considering most technical books are $40 and up that is worth the price alone. As a minimum sign up for the mailing list where an introductory price of $99 per year is offered from time to time.

So, don't delay: take your first bite!

P.S., while researching the origin of the elephant idea we came upon Mikki's blog and her post on this topic. It has nothing to do with computers, but those of you who feel overwhelmed in your personal lives and professional lives may find it an interesting read.

Totally Free RPG

As you may have already heard, there was a major Technology Refresh (TR) announcement yesterday - check out fellow blogger Steve Will's You and i blog for a summary of the details.

Of course what we are most interested in, apart from the arrival on IBM i of Ruby on Rails, are the major changes that this TR brings to RPG. In fact they represent the biggest changes in the language since the V5 introduction of /Free form calculations specs. That said, it is likely that they will also be among the most controversial. No, it's not Object Oriented RPG--we're on record as saying we don't think that will ever happen. "It" is completely free form H, F D and P specs. That's right--with TR7 RPG becomes a completely free format language. Well, unless you still have a desire to use I and O specs, that is.

So why do we think it will be controversial? Well first of all there are always those who think that RPG enhancements are a waste of time because:
a) Fixed format was good enough for my grandfather, it is good enough for me or ...
b) If I want to write in a modern language I'll use Java/C++/PHP/whatever ...
c) Hardly anyone uses the "new" features like BIFs anyway so why add more ...

We expect those. It happens every time.

But this time there's an additional factor at play. The syntax. As you'll see from the short sample below it more closely resembles CL than (say) C or Java. But unlike those languages, that use curly braces to delimit blocks, RPG decided to stick with a declaration (dcl) based syntax, starting and terminating definitions with markers such as dcl-ds and end-ds. There were undoubtedly many reasons for doing this, not the least being that the compiler team did not want to add another syntactic construct to the language. Plus of course had they done so they would almost certainly have had to revisit the use of braces within the calc specs.

Yes, it may mean a bit more typing for some things, and RPGers as a general rule are famous (or is that infamous?) for their disdain for typing! But in return for the arduous task of keying dcl-f in place of F, for example, you don't have to concern yourself about what column to put the F or the E in (or else copy an F spec from the quickest program you can put your hands on É--come on, admit it, you've done it, right?)

For that matter, you can make up some of those keystrokes by the fact that you don't need to specify the F or E at all. The F (Full procedural) is the only option in this syntax and the E (Externally described) is the default.

And think of the number of keystrokes you'll save from doing away with all the iterations of /Free and /End-Free around your subprocedure logic!

Of course, the end result is potentially more readable code. And a less "lame-looking" syntax for the newest crop of RPGers coming along.

Here's a very short example of the new "/Free-less" RPG, which also illustrates the new relaxed rules about the relative positions of file and data structure declarations (F and D specs in the "old" language).


 ctl-opt option(*srcstmt) dftactgrp(*No);        
 
 dcl-ds employeeDS;                              
   firstName char(16) Inz('James');              
   lastname  char(30) Inz('Joyce');              
   salary    packed(7:2) Inz(12500);             
 end-ds;                                         
                                               
 // Define printer file and associated DS        
 dcl-f qprint printer(80);                       
 dcl-ds prtDs len(80) end-ds;                    
                                                                                                  
 dsply ('Hello to our new employee');            
 dsply ( %TrimR(firstName) + ' ' + lastName );   
                                                 
 // Also write out details to the printer file   
  prtDs = 'The name of our new employee is ' +       
          %TrimR(firstName) + ' ' + %TrimR(lastName) +
          ' his salary is $' + %Char(salary);        
  write qprint prtds;                                
                                                     
  *InLR = *On;                

We'll be writing more about this new totally free RPG in EXTRA this month. We'll post a link to it in the comments when it's available. Until then, what do you think?

                      

Open Access--Oh the Thinks You Can Think!

The more we work with Open Access for RPG the more we realize how much more we can do with it. For example, a couple of weeks ago Jon published an article detailing an RPG Open Access (OA) handler that allows entries to be written to a data queue with a conventional RPG Write operation. He mentioned at the time that while APIs such as those for data queues are not particularly complex, they are complex enough that they are not as frequently used as they should be.

Dan Cruikshank, one of IBM's leading DB2 experts, and a fellow member of the Modernization Redbook team, wrote to us after the piece was published. He pointed out that while data queues were an excellent example of how OA can be used to simplify things, the interface to almost any list API could benefit from the development of an OA handler. For example, wouldn't it be nice to be able to process a list of spoolfiles that meet certain criteria by using SETLL to set up the criteria, followed by a series of READ or READE operations to retrieve the data. Dan is no newcomer to using OA to adapt existing processes and has written several articles on database modernization using OA. For an example see his article on using SQL with OA on Developerworks.

The more we thought about Dan's comments the more we realized that he was right. After all, how many programmers do you know who still persist in using the outfile support from IBM i commands rather than use the more efficient and more capable related APIs? Would they be more inclined to abandon their old habits if there was an OA handler available for the API in question that would allow them to process the results with familiar RPG op-codes? We think the answer is yes.

So we've been busily working on a sample OA handler that supports CHAIN, SETLL and READ operations against a simple list. The idea being that the basic principals can be adapted to processing any list--no matter how it is derived. We'll be publishing the related article in an upcoming edition of IBM i EXTRA so you might want to watch out for that. (Editor's note: If you don't currently receive the IBM i EXTRA newsletter, you can subscribe here.)

Programmer's Block

You probably are familiar with the term "writer's block"--that dreadful feeling that comes when you know you have to write something, but just can't get started. You sit and stare at the blank page (or screen these days) hoping against hope that inspiration will strike. Jon's solution to this is to plug in his headset, fire up the Dragon speech-recognition package, and do a verbal brain dump of all the various bits and pieces that he wants to talk about. Once the page is no longer blank he finds it easier to mold the text into shape. Susan takes a different approach, which is to pick some specific part of the subject that isn't at the beginning, and jump into some part that she can think of something to say about and come back to the beginning after the wheels are in motion. You probably have techniques of your own. If so, please share them with us in the comments.

But one thing that neither of us have been able to find an effective cure for though is "programmer's block." Effectively this is the same thing as writer's block except it is the program editing screen that remains stubbornly blank. This is a case where Dragon can't help Jon. Good as it is, it really doesn't handle programming tasks very well.

Many people deal with this issue by not even attempting to code a program from scratch. Rather they just clone a familiar program with that performs a similar task. Now that the screen is no longer blank they commence hacking away (and we use that term advisedly), attempting to shape the new program from the carcass of the old. Tempting as this approach may be, we are not fans. First, the program you are cloning may well have originally been written (or indeed cloned from) a program that originated on the S/36 or S/38. As such it is likely to use outdated techniques such as numbered indicators, Multiple Occurrence Data Structures and worse. Later they convince themselves that they saved hours by using this approach. But did they?

A better approach is to clone skeleton programs that are intended for the purpose and, perhaps more importantly, are regularly updated to include the latest advances in RPG or indeed in shop standards. That means that everyone is cloning from a common base and all programmers in the shop will quickly learn to take advantage of advances in technique and language.

Sometimes though you come upon a programming task that just doesn't fit any of your current templates. How do you handle programmer's block in those case? Or are you just so excited to be doing something new that you never experience a "block" under those circumstances? If you've found an approach that consistently works for you please share. We'd hate to think we were the only ones out there with this problem.