Re: QWCCVTDT causing strange error

[Scott Klement <klemscot@xxxxxxxxxxxx>]

> The following is a mystery to us.. and for now, we are using a work
> around to avoid this problem, but does anyone have any idea why the
> following would occur (while using the QWCCVTDT api. (note: this is
> related to a RPG native program not ILE programs all files in program
> are externally described, and we use this API in many programs and have
> not previously encountered this problem)

If you're passing the same size parameters to them, then it's sheer luck
that you haven't had a problem.  Read on and I'll explain.


> Since this field has nothing to do with the date routine, and no data is
> moved into it, except for within the INZSR subroutine where we move
> 0005 into it, how can it be being changed?

Computers use memory (RAM) to store variables while they run.  You can
think of memory is a large array of 1-byte variables.  You can think of
assigning data to memory as being like the MOVEA operation in RPG.  When
you move 16 bytes to position 5, it will change the values of bytes 5-20.
Read on...

>
> Very strange… any ideas?

Not strange at all.  Observe this code:

> 1113   C                     CALL 'QWCCVTDT'
>        C                     PARM '*YMD'    APIP01 10
>        C                     PARM DATE$     APIP02  7
>        C                     PARM '*JUL'    APIP03 10
>        C           JULDT$    PARM '*YMD'    APIP04  7
> 1118   C           APIERR    PARM APIERR    APIP05 16

The 2nd and 4th parameters to the QWCCVTDT API are variable length
depending on the format given.  For formats '*YMD' and '*JUL', the
parameters must be at least 16 bytes long.  However, you passed 7.

The way that parameters work is that the system passes a memory address of
the caller's variable to the called program.  One address is passed for
each parameter.  The called program writes its values to that memory,
causing your variables to be changed.

But, the API thinks you're passing a 16 byte variables, and you're passing
7 byte variables.  What will it do?  It will overwrite your 7 bytes, plus
9 more bytes right after your variable.

The problem is, what's occupying those 9 bytes?  It may be another
variable in your program -- which it appears is the case here.  It may be
memory used by the system for something else...   it may even be memory
used by another job....   it's just luck that it happens to be VVEND in
this case.

In other programs you could be overwriting memory used by another job, and
that job now starts doing strange things that you can't explain.

Or, it could be overwriting memory that doesn't happen to be in use, in
which case you'd see no ill effects.

Or it could overwrite memory used by another program in the same job, in
which case you might cause problems there.

Frankly, it's lucky that this happened to be an error that showed up in
the same program.  If it weren't, you might have some strange result
somewhere else down the line, and spend hours or days looking for the bug
and not be able to find it.

The moral of the story?  Make sure you always pass at least as many bytes
as the called program expects.