i used FndStrPdm to identify programs that use MULT 10000.01 to convert the date. i frown upon this, and want to change this process. i converte all of these programs to RPGLE, albeit fixed-format, in 2010.

what argument can i use to convince my boss that it would be a good thing to convert these to either a data structure, procedure, etc.?

i am not certain how to test this, nor am i convinced which NEW method would be best. i have used the data structure method since the late days of the /34 (yes, i'm that old) but i dont have a reference as to which is a faster method.

of course a sub-program or procedure is my preference, but i need ammunition to convince my boss to allow me to change the way that 47 pages of source members function.

thanks for all suggestions, except the one that i seem to get most of all, telling me "where to go." :)

Nah, probably not faster when it comes to just hundreds of iterations.

Converting from/to date formats is expensive--more so than the old MULT method. There is a fix on v7r1 to avoid doing the conversion into and out of the internal date format if nothing's changed, but that requires v7r1 TR4.

The advantage the above method has over MULT is that of implicitly testing for a valid date value. You don't get that with MULT.

The QWCCVTDT API might be something to do a test vs the MULT basis. The values need to be type CHAR so you'd also have to include the time to convert from Zoned to Char (although there is a cheat for that).

Sarge, MULT opcode does not work by doing adds in a loop. You have to go pretty far back to find a CPU that doesn't do multiplication as part of the instruction set (8080, maybe). Timing of a multiply instruction is on par with an addition or subtraction.

Neil, yes, if not validating the actual date is okay, then yes, the data structure method is "best". I would use the built-ins or QWCCVTDT over other methods any time.

I suppose there should be just a flat "convert this 6-digit numeric value from XYZ to ABC format. I could add that to cozTools, but it would be best to have an RPG compiler implementation due to the "overhead" of a subprocedure call in high-performance areas.

I've built a new cozTools subprocedure named CVTDATE that wraps the QWCCVTDT API. I'll test it in a iterative loop vs the %DEC(%DATE()) routine and to the legacy MULT operation code. It should be finished by later this morning.

RESULTS - Performed each task 10000 times in a FOR loop

NOTE: Results shown are for all 10,000 iterations combined. Not an individual execution.

So it turns out that an in-line MULT is the fastest way to convert a 6-digit zoned numeric field from MDY to YMD format. But the other two methods aren't so bad (15 times slower) that it should prevent from using one of them.

NOTE 2: I ran the test again with the Subproc call using two different methods. Here are those results:

To sum up... the MULT legacy method is the fastest inline method for converting a 6-digit numeric date between MDY and YMD format. I did not test larger figures, but I assume it would be similar performance.

For "one off" conversions, any method would be good enough, although I would never use the MULT option or the data structure option. The DS option is okay if hidden inside a subproc, however.

Sadly the one I thought would be good, QWCCVTDT is really not a good choice--probably because it is (A) a dynamic call and (B) an OPM program.

These leads me to conclude that the CEEDAYS/CEEDATE methods are the 'best' for legacy date conversion--you also have to convert from decimal to character format to use these APIs.

For cozTools, there are already methods to do this--most use internal APIs or C runtime. But I've now added the cvtDate() subprocedure. It basically wraps the CEExxxx APIs and adds some ease-of-use options.

The CVTDATE subprocedure assumes the date format is *MDY and should be converted to *YMD, likewise if the optional 2nd parameter is specified as *YMD, it assumes you want to return the value as *MDY, but you can specify the return format as the 3rd parameter.

In addition, any 6-digit or 8-digit day may be specified and it'll convert it. It will not return date formats that include text characters. For that, use on of the other cozTools functions, such as editDate().

Date conversion speed won't matter much once you add in the database I/O - that's the bottleneck of most any business program. Sorta like standing on a chair to get closer to the moon - the net effect is infinitesimal. bm

Yeah Bob. I'm all about coding something the correct way, then determine which method is fastest. Like a few years ago, I had to figure out if a failed CHAIN or a failed SETLL fails the fastest because the logic would normally fail a few times before getting a hit. CHAIN won, it doesn't position the cursor to EOF.

Dale, no. I don't find that technique viable. Traditionally it requires direct manipulation based on data configuration. But I suppose with EVAL-CORR you could modernize it assuming you've setup the data structures properly.