Comments on: How to easily perform date conversions in RPGLE (Including Substringing!)

By: TomLiotta

TomLiotta — Mon, 11 Mar 2013 04:34:48 +0000

I ran across an old TechTarget article, RPG free-format date-conversion cheat sheet, that might have one or more conversions you don’t have. I didn’t check them all nor compare against yours.

I did find probable typo bugs between statements 31.00 and 45.00 where many 7-digit conversions should be specified as 8-digits. Also, even though the article contains a source module that can be compiled and run, the statements conflict with other statements. As values are changed, later statements are affected.

One technique I don’t see in your examples nor in the linked article is the use of DS subfields. By referencing basic data definitions, operations involving substringing can sometimes be eliminated.

Tom

By: aceofdelts

aceofdelts — Thu, 28 Feb 2013 17:25:59 +0000

Before IBM came out with the DATE type fields and the Duration op codes, we would convert our dates to Day of Century and simply subtract to get duration. A divide-by-7 with MVR would tell you the day of the week.
The ’50-year convention’ for determining century is another one that we did a little differently … had a stand-alone program to call & pass the 6 digit & get the 8 digit return parm. The advantage was the ability to redo the scheme by changing just 1 program.
Yes, these techniques are mostly useless now, but I’ll run into situations now & then where it’s handy. Mostly useful in decifering other peoples code.

By: TomLiotta

TomLiotta — Wed, 27 Feb 2013 13:47:09 +0000

A big reason it’s not as common as the knowledge could be is that those who learn solid SQL techniques tend to go on to better jobs. Those who don’t, tend to stay behind. That leads to a shrinking concentration centered around older technologies such as RPGII and S/36 code.
Effort tends to focus on keeping the old file structures going. There’s no time to put redesigned databases in place because time is taken up with code like subtracting 28 days from 6-digit numeric dates.

Now, you have definitely recognized that category of problem for developers and you decided to build library of code. You’ll be able to reference it for many programs to come. And, over time, more and more of your programs will be using recognizeable code fragments.

One thing I’ve been sarching for is a code library that was made available some 12 or 15 years ago (more?) called something like “The Ulimate Date Routines”. It’s been so long that I can’t remember who put it together. (Bob Cozzi keeps coming to mind, but it only sems partly right for some reason.) I was hoping to track it down to help you out, but I still haven’t hit on it. It’s been update once or twice as new native functions have been released.

For that, it’s something you shouldn’t have to do. But you came to a conclusion that spending the time was valuable. It’s something that’s been done more than once, yet somehow it’s worth doing again. Why?

Because you didn’t already have the routines and you believed it would save more time in the future than the time you spent putting together. It’s a near certainty that you’re right, too.

It does lead to another question, though. If your database didn’t have 6-digit numeric fields or 8-byte character fields or whatever, and instead was converted to use actual DATE fields, and programming was also adapted to expect all DATE (and TIME and TIMESTAMP) fields, how many of the code snippets would be needed?

I’ve been searching for a code library that was published 10 or more years ago called something like “The Ultimate Date Routines”. It was a full set of RPG code snippets covering what you posted. It was updated at least once to include new date functions after they were released by IBM. I haven’t been able locate any references, but I’ll keep looking. (I keep thinking Bob Cozzi might have done it, but it doesn’t seem totally right.)

Anyway, I recognize the problems you’re trying to solve with your collection of snippets. SQL in the right places could handle a lot of it, but it’s your choice not to use it. Considering the performance and other advantages of SQL over native, though, I’ll still recommend that it be investigated farther for its appropriate uses.

Tom

By: ShatteredRaven77

ShatteredRaven77 — Wed, 27 Feb 2013 11:52:06 +0000

I’ve never had a problem getting a programming position with the little SQL knowledge that i have or the lack of experience in embedded SQL. Most companies want their developers to write programs that can easily be maintained by future programmers. At a few places, I’ve been told not to use embedded SQL just because it’s not typically common knowledge with programmers anymore. I don’t think it’s right that you speak with a stigma on those who don’t use SQL and label them as unable to think in terms of you. But thanks for taking this post to a different level. This was really about giving people an easier way to convert dates and use the tools that IBM gives us instead of sticking with the same code that programmers from the S/36 or RPGII days. I thought it would be cool to show people new ways of doing old things.

By: TomLiotta

TomLiotta — Wed, 27 Feb 2013 07:34:47 +0000

I’m not sure I’d hire programmers who weren’t more comfortable with SQL than with RPG except for specific maintenance tasks, so I wouldn’t run into a problem with future developers. Actually, I can’t recall the last time I worked with one who wasn’t comfortable with both; it was at least 15 years ago.

I can understand the reluctance, though. It’s a different mindset to think in terms of sets rather than one-at-a-time. The one-at-a-time design of most legacy programs is what leads to SQL practices that tend to complicate.

Tom

By: ShatteredRaven77

ShatteredRaven77 — Wed, 27 Feb 2013 00:59:18 +0000

I wouldn’t use SQL for something like this. I actually never use SQL in my programs. It can get way to complicated, hard to follow for future programmers who aren’t as versed in it and I have never had the need to. But that’s only my opinion from past experiences.

By: TomLiotta

TomLiotta — Wed, 27 Feb 2013 00:05:43 +0000

I’d look at creating a SQL VIEW that presented all of the same columns except that it would convert any “date” values into actual DATE data types. Then these conversions wouldn’t be an issue at all. Often, the more code you can push below the program level into the database level, the better things will run. As time passes and the original file is replaced program-by-program with the VIEW, eventually the file can be converted to a real SQL table; and many future problems don’t happen. Future code then won’t need overhead of conversions. — Tom

By: ShatteredRaven77

ShatteredRaven77 — Tue, 26 Feb 2013 18:58:38 +0000

BigKat, was really looking for various tips and tricks with date conversions than anything. I was actually only giving examples in the past where I had to do one thing or another. When I said "I'd love to see if I can get the result I need with the least amount of code" I simply meant i normally try to get what i need in the least amount of code lines. I don't really have a specific question other than if anyone wanted to share some of their tips and tricks.

By: BigKat

BigKat — Tue, 26 Feb 2013 18:24:51 +0000

i'd love to see if I can get the result i need with the least amount of code. What is the result you need? At one point you are discussing 6-digit dates and later your code example has an 8-digit date and it seems to do what it should, so I am confused as to what you are looking for.