Re: Allocating memory for QWDRJOBD (Retrieve Jobd)

Hi Charles,

> d RtvJobDesc      pr                  extpgm('QWDRJOBD')
> d  pReceiverVar              65535a   option(*VARSIZE)
> d  pReceiverLen                 10i 0 const
> d  pFormatName                   8a   const
> d  pQualJobd                    20a   const
> d  pError                     8192a   option(*VARSIZE)

This prototype looks good.  The other prototype where you attempted to
pass a pointer by value as the first parameter will not work, however.
You cannot pass data by value when you're calling a program -- that
technique only works with subprocedures.


> Looking at the DS for the returned data, I believe that given the use of the
> "Offset" and "Number of Library List Entries" fields for the initial library
> list I shouldn't hardcode anything past pos 434 of the DS.  Or at least I
> should not hardcode the initial library list as starting at that point.  I
> suppose I could add a big character buffer at the end, say 3000 bytes or so.

That sounds good to me... I believe the max number of libraries allowed in
a library list is 250.  250 x 11 is 2750...


> Problem with that, is that the buffer would be static.  It would work now,
> but what about the future?

Well, if IBM should increase the number of possible entries in the library
list, or for some reason increase the size of the "Reserved" parameter to
a very large value (I can't see why they'd do that, though) you might get
only a partial library list -- that would be the risk you'd take.

The API knows how big your buffer is (thanks to the pReceiverLen
parameter) so there's no risk of clobbering additional memory.

> The only thing I can think of is make the buffer huge, but I'm not
> particularly fond of that idea.

That's what I'd do... I'd say something like "3000 bytes is safe now, but
I'll make it 10000, just in case."  The only downside that I can see to
that scenario is that you'd use an extra 7000 bytes of memory, which is
utterly insigificant...

If you're really worried about it, then the ALLOC approach that you
suggested is the way to go.  Here's how you implement that approach:

1) Note that in the API documentation under "Length of Receiver Variable"
it tells you that the receiver variable's minimum size is 8 bytes.  What
that means is that it's perfectly legal to pass a receiver variable that
looks like this:

     D Needed          ds
     D   BytesRtn                    10I 0
     D   BytesAvl                    10I 0

2) Call the API with that 8-byte data structure above as your receiver
variable.  The "BytesAvl" member will tell you EXACTLY how big of a buffer
you need.

3) Allocate the buffer with pointer = %alloc(BytesAvl)

4) Have a second data structure, this one will use the BASED keyword to
put it into the memory that you allocated to the pointer.  The data
structure itself can be any size you like, since the amount of memory
allocated is unrelated to the size of the data structure itself.
Obviously, it'll have to be at least long enough to get the offset to the
libl, and the number of entries in it.

5) After you've read the library list, DEALLOC the pointer, and don't
refer to the contents of the data structure again.

This approach should guarantee that you get all of the entries in the
library list... the next question is, what are you going to do with them?
If you're going to take those entries and store them into a fixed length
field, then you might as well have used a fixed length buffer at the end
of the data structure in the first place, since either way you're limited
to that length... :)

But, if you're only going to use them with ALLOCed memory, or with a file
or something that can "grow" as you add more to it, then the ALLOC
approach will certainly be more robust.

Another alternative would be to use a user space instead of allocating the
memory.  Get a pointer to that user space with the QUSPTRUS API, and base
your data structure on that.  Off the top of my head, I can't see why this
would be better than ALLOC -- it would be more complex, and possibly
slightly slower -- but some people are more comfortable with user spaces
than they are with ALLOC...

HTH