Re: Reading a *DTAARA as SHRRD, not EXCLRD.

Thanks Vinay.

Both the PDF and the online documentation for 7.4, and what you said, are misleading. They appear to state the the *AUTO parameter of the DTAARA keyword is what makes it a data area data structure, but in fact it is the DTAARA keyword that does that, not the *AUTO parameter. The PDF is particularly bad in that it does not explain what the *AUTO parm actually indicates.

The .pdf version of the IBM i 7.4 RPGLE Reference manual says on page 421

"Free-form DTAARA keyword for a data structure

The parameters of the DTAARA keyword for a free-form data structure definition are

*AUTO
The data structure is a data area data structure. If *AUTO is specified, and you want to use the data
area with the IN, OUT, or UNLOCK operation codes, you must also specify the *USRCTL parameter."

The online version is also misleading:

"A data area data structure is identified in a free-form definition by the*AUTO <https://www.ibm.com/docs/en/ssw_ibm_i_74/rzasd/ddtaarafreeds.htm>parameter for the DTAARA keyword, or identified in a fixed-form definition by a U in position 23."

But the following sentence kind of hints what you said:

"This indicates to the compiler that it should read in and lock the data area of the same name at program initialization and should write out and unlock the same data area at the end of the program."

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx
pdow@xxxxxxxxxxxxxx /

On 2/21/2023 12:09 PM, Vinay Gavankar wrote:

Using *AUTO makes it a data area data structure, which is automatically
read and locked at program initialization.

https://www.ibm.com/docs/en/i/7.4?topic=structures-data-area-data-structure

Vinay

On Tue, Feb 21, 2023 at 3:03 PM Vinay Gavankar<vinaygav@xxxxxxxxx> wrote:

Removing the *AUTO/*USRCTL keywords will not lock the data area.

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

Or define it as a variable

dcl-s userdft char(10) DTAARA('WEB/default');

Vinay

On Tue, Feb 21, 2023 at 2:56 PM Peter Dow<petercdow@xxxxxxxxx> wrote:

Jon,

Don't you have to specify *LOCK on the IN operation for a lock to occur?

Gavin,

Are you sure the lock is from your program? Does WRKOBJLCK show it's
your job/program locking the data area?

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx
pdow@xxxxxxxxxxxxxx

/
On 2/21/2023 9:26 AM, Jon Paris wrote:

The simple answer - I don't think you can.

But why would you want to?

If you want a lock so that you can update the area then simply unlock

it via an out operation after the update or issue an unlock if not updating.

If for some reason this is not viable perhaps explain what you are

trying to do and we can perhaps suggest an alternative solution.

Jon P.

On Feb 21, 2023, at 12:14 PM, 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.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a messageemail:MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:https://lists.midrange.com/mailman/listinfo/midrange-l
oremail:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
athttps://archive.midrange.com/midrange-l.

Pleasecontactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email:MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:https://lists.midrange.com/mailman/listinfo/midrange-l
or email:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
athttps://archive.midrange.com/midrange-l.

Please contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.