Re: RE: shared storage across many jobs

On 10/12/05, Hewitt, Rory <rory.hewitt@xxxxxx> wrote:
> Elvis,
>
> Can you have a single user space which contains pointers to other user
> spaces? When you need to add job information, you go to the 'primary'
> user space and run through each of the pointers in there, accessing the
> related user space (which you treat simply as memory, since you're just
> using a pointer) and checking for a record in each other user space. In
> the 'prmary' user space, you'd simply have an array like this:
>
> D MainDS           DS
> D  Array                           Dim(10)
> D   UsrSpcPtr                  *
> D   NbrOfJobs                10I 0
>
> and in the 'secondary' user space you'd have your array of job
> structures. You'd still only need to use the QUSPTRUS API once to get
> the pointer to the main user space and then have a loop from there. Of
> course you'd need to have processing to create more secondary user
> spaces as needed, but that's not a problem...

It is a problem when you want to duplicate the object, copy it to
another library. You have to account for all the user space objects
with incomprehensible 10 character names.  The do nothings at IBM
reserve a feature of the machine which allow spaces to be linked
together and managed as one object by the higher level OS.  Would be
nice if IBM made this feature available to user apps.

Consider that the 16 byte pointer performed well on the S/38 back in
1982.  What about expanding the pointer size to 64 bytes? That would
provide room for a guid as the object name, which would enable the
pointed to object to be unique throughout the network.

>
> Another option might be to use a user index - it'll certainly be faster
> than file I/O, but maybe slower than using one or more user spaces...

user indexes are very fast.  If performance is the reason not to use a
database file ( possibly the app is running on a geared down iSeries )
then the user index could be the solution. They are very good
performers.

-Steve