Re: More, Re: Weird problem with times.

Correction to earlier information:

It seems that when I removed and reestablished the trigger, the place where the CPF1850 occurs DOES move. So to speak.

After IPL, the exception is thrown by the first TIME statement following a call to the published MailDate procedure. (Incidentally, the MailDate procedure is in the same module.)

But after removing and reestablishing the trigger, it's thrown by the first TIME statement encountered, period.

Also, there's a pattern to where it reports itself as occurring:

Consider:

Procedures FOO and BOZ both call procedure BAR. The TIME statement is in BAR.

In both instances, the error actually occurs in BAR, called by FOO, but in the first instance, the joblog shows a CPF1850 being thrown from QWCCVTDT to QRNXUTIL, immediately followed by an RNQ0202 claiming that "the call to FOO ended in error," while in the second instance, the CPF1850 is immediately followed by an RNQ0202 claiming that "the call to BAR ended in error."

None of the intervening calls are reported, and the only statement number reported in my code is the call to FOO or to BOZ.

Sharon: Thanks for the suggestion, but even saving *and restoring* the entire library seems to have made no difference.

And Scott, your apology is unnecessary, but accepted gratefully. I already added the FC parameter, as per Bruce Vining's message on the sister thread on the MIDRANGE list. No joy, as you might imagine from the above discovery.

--
JHHL