Skip to main content

Authorization List on IBM i

Authorization List (AUTL):

Managing Authorities is the key part for any application. Authorities can be provided by User profile or associated Group Profile. One other way to do this is by using Authorization List

Authorization List allows multiple User profiles and/or Group profiles to be setup with the required authorities (*USE, *CHANGE, *ALL...) and add Authorization List to the corresponding Libraries or Object. 

This makes it easier to manage authorities to setup or change the authorities at one place rather than having to change on multiple libraries or objects. 

Apart from the fact that Authorization List makes it easier to manage authorities, There are couple of other major advantages of using Authorization Lists. 
  • Authority can be granted or revoked even if the file is locked by adding or removing the user on Authorization List. Same cannot be done directly on a File even if it is open for Read.
  • Authorization List provide a way to remember authorities when an Object is saved. And, Object will automatically be linked with Authorization List on Restore on to the same system. Only exemption to this is if ALWOBJDIF(*ALL), ALWOBJDIF(*AUTL) or ALWOBJDIF(*COMPATIBLE) is specified on the Restore command. 
It is advised not to maintain private authorities on the objects directly along with an Authorization List. Having this might affect system performance (by checking for authorities both on Object and Authorization List). 

How to setup Authorization List? This can be done in the 3 simple steps. 
  1. Create the Authorization List. 
  2. Add Users to Authorization List.
  3. Attach Authorization List to Objects.
CRTAUTL (Create Authorization List) is used to create Authorization List. 

CRTAUTL AUTL(DATAAUTL) TEXT('Authorization List for Data Objects')

Existing authorization list can be seen by using WRKAUTL (Work with Authorization Lists)

Option '2' from 'Work with Authorization Lists' or 'EDTAUTL' (Edit Authorization List) are used to add or remove users and/or user's authorities. 

To attach Authorization List to Objects, one of the below commands can be used. 
  • GRTOBJAUT (Grant Object Authority) - Use parameter 'AUTL' to add the Authorization List to Object.
  • CHGAUT (Change Authority) - Use parameter 'AUTL' to add the Authorization List to IFS Object. 
  • EDTAUT (Edit Authority) or EDTOBJAUT (Edit Object Authority) - Both these commands would display a screen and Authorization List to be entered against 'Object secured by authorization list'.


Popular posts from this blog

All about READ in RPGLE & Why we use it with SETLL/SETGT?

READ READ is one of the most used Opcodes in RPGLE. As the name suggests main purpose of this Opcode is to read a record from Database file. What are the different READ Opcodes? To list, Below are the five Opcodes.  READ - Read a Record READC - Read Next Changed Record READE - Read Equal Key Record READP - Read Prior Record READPE - Read Prior Equal Record We will see more about each of these later in this article. Before that, We will see a bit about SETLL/SETGT .  SETLL (Set Lower Limit) SETLL accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Corresponding Record (or Next Record if exact match isn't found).  SETGT (Set Greater Than) SETGT accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Next Record (Greater Than the Key value). Syntax: SETLL SEARCH-ARGUMENTS/KEYFIELDS FILENAME SETGT  SEARCH-ARGUMENTS/KEYFIELDS FILENAME One of the below can be passed as Search Arguments. Key Fiel

What we need to know about CHAIN (RPGLE) & How is it different from READ?

CHAIN READ & CHAIN, These are one of the most used (& useful) Opcodes by any RPG developer. These Opcodes are used to read a record from file. So, What's the difference between CHAIN & READ?   CHAIN operation retrieves a record based on the Key specified. It's more like Retrieving Random record from a Database file based on the Key fields.  READ operation reads the record currently pointed to from a Database file. There are multiple Opcodes that start with READ and all are used to read a record but with slight difference. We will see more about different Opcodes and How they are different from each other (and CHAIN) in another article. Few differences to note.  CHAIN requires Key fields to read a record where as READ would read the record currently pointed to (SETLL or SETGT are used to point a Record).  If there are multiple records with the same Key data, CHAIN would return the same record every time. READE can be used to read all the records with the specified Ke

Extract a portion of a Date/Time/Timestamp in RPGLE - IBM i

%SUBDT Extracting Year, Month, Day, Hour, Minutes, Seconds or Milli seconds of a given Date/Time/Timestamp is required most of the times.  This can be extracted easily by using %SUBDT. BIF name looks more similar to %SUBST which is used to extract a portion of string by passing from and two positions of the original string. Instead, We would need to pass a value (i.e., Date, Time or Timestamp ) and Unit (i.e., *YEARS, *MONTHS, *DAYS, *HOURS, *MINUTES, *SECONDS or *MSECONDS) to %SUBDT.  Valid unit should be passed for the type of the value passed. Below are the valid values for each type. Date - *DAYS, *MONTHS, *YEARS Time - *HOURS, *MINUTES, *SECONDS Timestamp - *DAYS, *MONTHS, *YEARS, *HOURS, *MINUTES, *SECONDS, *MSECONDS Syntax: %SUBDT(value : unit { : digits { : decpos} }) Value and Unit are the mandatory arguments.  Digits and Decimal positions are optional and can only be used with *SECONDS for Timestamp. We can either pass the full form for the unit or use the short form. Below i