RE: Format Level Identifier on display file records

Excellent catch, Simon, and I completely agree with your analysis.

The question that leaves in my mind is how that might cause a failure to
occur at the UPDATE statement. Shouldn't it occur at the second or later
call to QDBRTVFD? Maybe the OP was mistaken about that.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
I talk to myself at work because nobody else here understands me.

d RfFilInf ds 4096
d RfFilInfPrv 10i 0 OverLay(RfFilInf:5)
d Inz( %Size(RfFilInf))

Interesting approach ... but a bit stupid.

c call 'QDBRTVFD'
c parm RfFilInf
c parm RfFilInfPrv

You are using the RfFilInfPrv field for two different purposes. The
first use is on the call to the API where it indicates how much space
YOU made available. The second use is by the API where it indicates
how much data IT could return if you provided sufficient space. So on
the first call to the API you tell it you have 4K of space and it
fills <=4K. It also sets bytes_available to be the lesser of 4k or the
amount it actually returned. In addition, it sets bytes_provided to
the amount of space needed if you want all of the file information.
This may be greater than the amount you provided.

Because you chose to use the same field for indicating both how much
space you gave the API and how much space it could fill the first call
will work but the second and subsequent calls will fail. The actual
failure will depend entirely on what happens to be in storage
following your 4K allocation.

The process is as follows:
RfFilInfPrv = 4096
Call QDBRTVFD
API returns 4K of data but sets RfFilInfPrv to a larger
value
RfFilInfPrv = >4096
Call QDBRTVFD
API returns >4K of data and trashes storage causing kaboom!

Despite the documentation you should think of the three values
involved as follows:
Bytes provided: Space you make available to the API (generally
parameter 2)
Bytes returned: Amount of space filled by the API (first 4 bytes
of
receiver)
Bytes available: Amount of data that could be returned (second 4
bytes of receiver)

Note that in some cases your very unsafe technique will appear to work
so you may have lots of "working" code that uses this technique. If so
I suggest you find and fix it. The cases where it will work without
problems are those where you provide enough space on the first call
for all the information to be returned. In other cases it may be an
"accident waiting to happen".

The fix, and the correct code, is to use a separate field for the
amount of space you make available to the API.

Regards,
Simon Coulter.