× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



And I do all that, but the killer is that an RPG program called in the
same job as the ALCOBJ is called cannot update the data area.

I found an interesting technique at 
http://archive.midrange.com/midrange-l/199909/msg01519.html, but this
really starts to get into unchartered (unsupported?) territory.  If I were
brave enough to use this in a production environment, I would have
allocated the program this way to ensure only one "copy" of the program
was ever running at the same time.  

Oh well.

GA

--- "York, Albert" <albert.york@xxxxxxxxxxxxxx> wrote:
> The problem of ensuring only one instance of the job running is a common
> one. The solution that I have finally decided works the best is to
> create a
> data area with the same name as the job and lock it in my CL. You can
> even
> go one step further and have your C/L program put the job name, user ID,
> job
> number, starting and ending times, etc in the data area for easy
> reference
> later. 
> 
> Albert York                          
>       
> 
>       At 07:57 AM 9/5/2003 -0700, you wrote:
>       >This seemed logical to do, but am getting RNX0432 "*LOCK for data
> area
>       >STUJRNEPRA was not granted" after (in the CL program):
>       >1) ALCOBJ OBJ((PRQJRN/PRJRNEPRA *DTAARA *EXCLRD)) WAIT(3)
>       >2) called RPG-IV program does an IN *LOCK on this data area so that
> I can
>       >update it on the OUT op.
>       >
>       >The reason for the ALCOBJ is that I want to ensure that there is
> only one
>       >job running this program at any given time.  I am not using any
> files, so
>       >I can't allocate that.  And I don't want to set an Active/Inactive
> status
>       >flag in the data area to make the determination of whether this is
> running
>       >elsewhere in the system, because this NEP job will be subject to
> being
>       >ended via ENDJOB, ENDSBS, PWRDWNSYS, etc.
>       >
>       >Since I was allocating the data area, I tried taking out the *Lock
> from
>       >the In statement, but I got a runtime error when the Out statement
> tried
>       >to update the data area.
>       >
>       >Advice / suggestions welcomed.
>       >
>       >GA


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.