Re: Native way to lock an object in RPG?

On 24-Aug-2016 13:31 -0700, Bob Cagle wrote:

Is there a native way to lock an object in RPG, and test for failure
if unable to obtain the lock?

I did find this:
(http://i5toolkit.sourceforge.net/rpg/page_obj_lck.html)

But just wondering if there's a native solution?

Might be worth explaining what is the origin for a desire to effect the locking, and what needs to be locked; i.e. what is the scenario in which that is required?

Typically an operation will be attempted, and if the necessary level of allocation can not be established [within the timeout; e.g. the Default Wait Time (DFTWAIT) for the job, or the Maximum File Wait Time (WAITFILE)], then the requested operation fails with an "unable to allocate"; i.e. the code presumes there will be success for the requested operation, and if instead there was a failure with that request, then the code would respond to whatever was the failure -- including the possibility that the error was an inability to allocate the resource [be that an object or record].

I am not sure what about _LOCK is not /native/ [enough], as that is the nearest to a direct invocation of the MI LOCK instruction; and I expect would be little different than what a %lockMIobject() might do as a /native/ BIF, if such existed. That feature is not generally helpful however, as most object types are in the System Domain, so a User State program would be unable to use the instruction against such objects, and would need to defer to the Allocate Object (ALCOBJ) command for object that are not User Domain. That protection from the /LOCK/ activity prevents [somewhat well] the ability of user-programs to break locking protocols established by the OS for specific object types.

The CL command ALCOBJ is an effective API, and CL participates in ILE, so a CLLE procedure can be written to access that capability. That would not be much different than if an API for that function had been made available instead as an OPM program. The CPP for ALCOBJ, the program QWCCALOC, operates in the system-domain, so can access\lock any of the supported object types [of their respective Special Value] that are presented on the Object Type element of the Object Specifications (OBJ) parameter; presented, when F4=Prompt is requested there.

The RPG provides /native/ implicit locking both for the Data Area (DTAARA) object type via the operations that perform actions on that object type and for the various attribute\type of the File (FILE) object type for the [implicit or user] OPEN.

For most everything else I can think of, the locking would be provided by whatever is the API being used to access whatever object type; e.g. requests like the open() API to open a STMF or QWCRDTAA API to Retrieve a Data Area, would perform the necessary locking to effect the requested action\operation against that object.