× 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.



This is happening on V7R2 and V7R4 systems using freeform RPGLE.

Your test is what I expected, but I'm seeing *EXCLRD lock on the dtaara.

I'm doing some testing with Unlock now.

On 2/21/2023 1:08 PM, Mark Waterbury wrote:

Gavin,

I missed that line ...  an "IN" without "*LOCK" should not lock the data area, AFAIK ... what version/release of IBM i are you running?   (I do not know what effect that *AUTO stuff on the declare might have on this.)

I ran this simple test:

     D CRL             S             60    DIM(1) CTDATA PERRCD(1)
     D                SDS
     D  JOBNAM               244    253
     C                   TIME                    TIMOUT            6 0
     C                   MOVE      JOBNAM        WSTOUT           10
     C                   MOVEA     CRL           @CRLIN           60
     C     *DTAARA       DEFINE    XYZZY         @CRLIN
     C                   IN        @CRLIN
     C                   RETURN
     C                   SETON                                        L
**
This is a test.   This is only a test.

Then after calling it, I ran DSPJOB option 12.  No locks on that data area.

Only when I add *LOCK to the IN opcode do I see the *EXCLRD lock.

This was run on IBM i 7.3 ...

Mark

Well, one could always use the API QWCRDTAA  to have total control of the process, rather than relying on some RPG runtime routine behaviors.

All the best,

Mark S. Waterbury


On Tuesday, February 21, 2023 at 12:48:35 PM EST, Gavin Inman<midrangelist@xxxxxxxxxxxxxx> wrote:

Hi Mark,

Original message included the  "in" Code.    (after the line "First lin in the program is:)

My code is as follows:

in userdft;                        // read *DTAARA with no locks)

If I wanted to lock the *DTAARA, I would code.

in *lock userdft;

I never thought I would have to use the Unlock opcode unless I used *LOCK for the read.

I could add the unlock and see if it solves the issue.

Thanks,

Gavin.


On 2/21/2023 12:33 PM, Mark Waterbury wrote:


Gavin,
    >>>---> private reply off-list <---<<<

I think you should post this question to the RPG400-L list.


Also, you did not show the "code" that uses this declaration ... e.g. there should be an "IN" opcode somewhere?   Did you specify *LOCK on that opcode?  :-o   If you want *EXCLRD or *EXCL, you need to specify *LOCK on the IN opcode.

If your program then does an OUT opcode to update the data area, you can specify *LOCK on that to retain the lock ...

There is also an UNLOCK opcode ...

RTFM (the RPG IV manuals).

Hope that helps,

Mark


  On Tuesday, February 21, 2023 at 12:14:49 PM EST, Gavin Inman<midrangelist@xxxxxxxxxxxxxx> wrote:

One for the group

I have a RPGLE Free form definition of the following *DTAARA.

DCL-DS userdft DTAARA(*AUTO:*USRCTL:'WEB/default');
    Dftuser char(10);
END-DS;


First line in the program is:

in userdft;


an *EXCLRD lock is used and locking out other jobs.  How can I get this
to be a shared Read?


Thanks,

Gavin Inman.






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.