Believe me, if you haven't started your Y2K conversion, and your shop has any kind of size to it, I believe you probably won't finish your conversion before January 1, 2000. That's just my opinion.

If you're one of the lucky, you've moved on to RPG IV with its integrated Date and Time support. You also don't have to worry about date routines anymore. In RPGIII if you want to calculate the number of days between two dates, you would call that "last date routine you'll ever need, Release 3" and maybe you'll get the correct result. In RPG IV, you perform one instruction, SUBDUR (subtract duration) and you're done. And its always correct!

There are  a number of APIs on the AS/400 that provide additional date support beyond that of RPG IV. For example, CEEDYWK is an ILE API that calculates the day of the week using Sunday as day 1, Monday as day 2, etc. It's fairly simple, yet without the proper background, you can't use it correct.

All the CEExxxxx (Common Execution  Environment) APIs that perform some kind of date routine are based on the number of days since October 14, 1582. You might think this is an odd choice, until you realize that prior to October 14, 1582 Julius Caesar's calendar was used. The problem with Caesar's calendar is that it was inaccurate. In fact, by the 1500's the Spring equinox was occurring in the middle of winter.

Needless to say, something needed to be done. So Pope Gregory the 13^th issued an "order" of sorts, creating the Gregorian calendar. Effectively what happened was that on the evening of October 4, 1582 everyone went to sleep and woke up the next morning. The date, however, was now October 15, 1582. You aged 11 days overnight, without the pleasure of actually living those days.

Since there was no October 5^th through October 14^th, 1582, the CEE APIs use the number of days since October 14^th, 1582 as a way of calculating the day of the week.

What's the difference between RPG and Java programmers?

RPG programmers have a job!

I've long had this theory, if you want a career, learn RPG and write applications for the IBM AS/400. If you want a short-term job, jump on the Movie of the Week bandwagon. Throughout the last 21 years that I've been writing RPG code, many languages have become popular. But  most of these languages have been a flash in the pan. They're similar to a 2-part movie of the week. They get hugely publicized, everyone believes they're going to be great, then after watching part 1, you realize that nothing really happened. Effectively, you can wait until the second night, watch the scenes from the previous episode, and still end up feeling like you could have spent your time better reading a book while watching a rerun of M*A*S*H.

I like using RPG, and I love using RPG IV. I like using C++ under the Windows environment, and in some cases, I like using C on the AS/400. But I have never met a C programmer (outside of some IBM employees <g>) who believed he or she can write a C program without any bugs.

Unlike C or C++, most RPG applications are crash proof. That is RPG applications are much more bug free than other languages. You can belief  this or not, but RPG programmers don't have to worry about idiosyncrasies like stepping on the OS kernel, or somebody elses memory leaks.  PL/I and COBOL applications are similar in quality to RPG, but that's another story.

There is only one known instance of a traditional RPG program bringing down an AS/400. And in that instance, the programmer thought he was the "King of RPG", so he could do no wrong. But he didn't take into account that if you perform a never ending DO loop and allocate memory on each iteration, well... Yet another reason to avoid the ALLOC and DEALLOC operations! And aren't you supposed to code Never-end-loops in college and not during your career? I don’t remember ever coding one since college. It was about 1977 in a Fortran Watfor program, as I recall...<g>

Anyway, back to my point. Every few years in our industry something comes along that is allegedly going to replace everything else. If you recall, we never really called RPG and COBOL "3^rd generation languages" until the flash in the pan 4GL phenomenon occurred in the mid 1980s. Then we renamed 4GLs to Query tools, then CASE tools, then IBM decided SAA was the way to go, then Client Server was the cat's meow. All of these events had one goal in mind, to sell us the same old products again and again.

All the while, RPG kept chugging along. The fact is, businesses prefer applications that work. Applications that will last, and applications that don't need to be rewritten for each new release of an operating system.

Now, this last point is important--the rewrite issue. Java is supposed to be a write-once run-anywhere language--the Holy Grail of programming. It doesn't require updates to its application when a new version of the OS is released because it has it's own Java runtime environment. That environment is on all the popular operating systems, including the three most popular operating systems Windows 95/98, Mac OS, and AS/400's OS/400. It is also supported on some not yet as popular OS's such as UNIX, Linux, and Windows NT.

IBM, of course, is all over Java because it gives the IBM developers in Toronto something new to play with. These developers seem to get bored writing RPG compilers, updating PDM and building tool that are supposed to work 100% of the time. It is, apparently, much more fun developing stuff for operating systems where people expect things to crash regularly--not as much stress, I suppose.

Like SAA, Java promises a write-once run-anywhere world. This means that you get the lowest common denominator of features in application, or you have to extend the language so that you take advantage of OS specific features.

Once you take advantage of OS-specific features, the application is no longer portable to another Java runtime environment. Hence the legal issues with Microsoft and it's Visual J++ product.

The idea of Java is okay, but in reality what we need is not a language that does everything and runs everywhere. We need a CL-type language for the Internet/web browser world. Java can be the CL of the Internet. It provides a platform independent language that doesn't require the keys to Atlantis to learn (unlike Pearle). But it, like C, sucks at general-purpose business applications. You can't write a mission critical transaction processing system or a traditional Order Entry application with Java. You can write the user-interface in Java, and then call RPG on the back-end under OS/400, that works. You can write a Java applet for a WebPage and call a C++ application on the back-end under Windows, that works too.

With Java, you can do some really cool things like build a 5250 emulator entirely in Java. Then provide worldwide web access to your AS/400 anywhere, anytime (without Client Access!). Advance Business Link does this with their Strategi product. It works very well. It is a "greee screen" or GUI 5250 emulator, written in Java that is accessed via your web browser. You do not need any software on your PC or Mac, just a web browser and you can get into your AS/400. I use it all the time.

I believe in the near future Java will become two things:

1. It will become one of two user-interface scripting languages for Web applications. The native interface will be one, Java will be the other.
2. It will be the CL language for the Internet and Worldwide Web.

I don't think RPG programmers should ignore Java, I think they need to learn just enough of it so they realize they don't want to use it.

If you want to learn Java, I would recommend Symantec's Visual Café. It provides support for the purest Java code. The others, like Visual J++ and Borland's JBuilder are good too.

The Microsoft Visual J++ is my personal favorite as development environments go, however its GUI layout tool does not support native Java interfaces. The Microsoft Visual J++ environment only supports Windows Foundation Classes (WFC) which map to native Windows APIs. Hence, WFC applications are not portable at all. They only run under MS Windows. In fact you can't even code native Java user interfaces with the Microsoft tool.

Be sure you have a PC with a 133Mhz or better Pentium CPU with 80 Meg or more of RAM and 300 Meg to 1.6 Gig of DASD. The "minimum install" for these products is typically about half these space requirements.

Remember a couple of points before going out and buying a Java development environment.