Re: Terrible time with this repeated error!

Murali wrote:

> Not able to allocate objects needed for file YPOSF1 in
> library QS36F
>
> Checked for object locks and found the following
>
> Opt  Member      Job         User        Type    Lock
>    Status  Share
>
>      GMIPOSF1    RBT_GDBPOS  D_MIRROR    MBR
> *SHRRD    HELD
>
>                                          DATA
> *SHRRD    HELD
>
> RBT_GDBPOS runs for almost one hour , everytime i have
> to wait till it completes  and then take Cancel and Retry...

-snip solutions tried-

> Can some one advise any better solutions how
> to handle this error in production from reoccuring,
> would appreciate your help

I have bad news for you: this is a design issue.  If the program must update
GMIPOSF1, it will have to wait until the RBT_GDBPOS job completes.  Unless
the design of the system is changed, you will have to live with it.  There
are ways of detecting that this file is not available, which will make the
program stop issuing the error message.  You will have to handle the error
yourself.  My suggestion is to change the file to user controlled open, then
use either the (e) operation code extender or an error indicator on the OPEN
operation.  Then you can check the program status data structure and find
out what message is being issued.  All of these things can be found in the
RPG Reference chapter on Exception handling.  You can try an ALCOBJ in the
CL, but that will lock other jobs from using the file, even if only a brief
time.

How you deal with the situation is a big question.  You can send the RPG
back to the CL with a parameter set to flag that the file was unavailable.
Then the CL can do a DLYJOB to wait s bit before trying the RPG again.  You
can simply print a report (or display a screen) saying that the file was
unavailable and to try later.  You can update a copy of the file and somehow
merge the updates with the production file when the production file becomes
available.  There are many possibilities, but you are limited here by the
software system architecture.  Somebody decided that they need to update the
global database at the same time the file is updated by another process.
This decision will be a problem for the RBT_ job as well, because if YEQR1
is running when RBT_ wants the file, RBT_ will get this error!

By the way, SHARE(*YES) absolutely does not have anything to do with sharing
a file between processes.  It means to share the access path between
programs in the same job.  This is pretty clear if you look at the help for
the SHARE parameter.  I can understand how a S/36 programmer might think it
means cross-process sharing because of the file:// FILE FFF SHARE-YES OCL
statement, but that is not the case.

I hope this helps some,
  --buck