Allocate resources

Objects are allocated on the system to guarantee integrity and to promote the highest possible degree of concurrency.

An object is protected even though several operations may be performed on it at the same time. For example, an object is allocated so that two users can read the object at the same time or one user can only read the object while another can read and update the same object.

i5/OS™ allocates objects by the function being performed on the object. For example:

If a user is displaying or dumping an object, another user can read the object.
If a user is changing, deleting, renaming, or moving an object, no one else can use the object.
If a user is saving an object, someone else can read the object, but not update or delete it; if a user is restoring the object, no one else can read or update the object.
If a user is opening a database file for input, another user can read the file. If a user is opening a database file for output, another user can update the file.
If a user is opening a device file, another user can only read the file.

Generally, objects are allocated on demand; that is, when a job step needs an object, it allocates the object, uses the object, and deallocates the object so another job can use it. The first job that requests the object is allocated the object. In your program, you can handle the exceptions that occur if an object cannot be allocated by your request.

Sometimes you want to allocate an object for a job before the job needs the object, to ensure its availability so a function that has only partially completed would not have to wait for an object. This is called preallocating an object. You can preallocate objects using the Allocate Object (ALCOBJ) command. To allocate an object, you must have object existence authority, object management authority, or operational authority for the object.

Allocated objects are automatically deallocated at the end of a routing step. To deallocate an object at any other time, use the Deallocate Object (DLCOBJ) command.

You can allocate a program before it is called to protect it from being deleted. To prevent a program from running in different jobs at the same time, an exclusive lock must be placed on the program in each job before the program is called in any job.

You cannot use the ALCOBJ or DLCOBJ commands to allocate an APPC device description.

The following example is a batch job that needs two files members for updating. Members from either file can be read by another program while being updated, but no other programs can update these members while this job is running. The first member of each file is preallocated with an exclusive-allow-read lock state.

//JOB  JOBD(ORDER)
  ALCOBJ  OBJ((FILEA *FILE *EXCLRD) (FILEB *FILE *EXCLRD))
  CALL  PROGX
//ENDJOB

Objects that are allocated to you should be deallocated as soon as you are finished using them because other users may need those objects. However, allocated objects are automatically deallocated at the end of the routing step.

If the first members of FILEA and FILEB had not been preallocated, the exclusive-allow-read restriction would not have been in effect. When you are using files, you may want to preallocate them so that you are assured they are not changing while you are using them.

Note: If a single object has been allocated more than once (by more than one allocate command), a single DLCOBJ command will not completely deallocate that object. One deallocate command is required for each allocate command.

The WAITRCD parameter on a Create File command specifies how long to wait for a record lock. The DFTWAIT parameter on the Create Class (CRTCLS) command specifies how long to wait for other objects.