AS400

System Values
System values (*SYSVAL) are AS/400 attributes that let each installation customize the machine to the organization's needs and specifications. Some system values control system performance; others define security levels; yet others simply provide defaults to command options that are unspecified. **Note : There are total 150 system values as following in the iSeries machine. Below are the few system values QMODEL - Holds the system model number and can't be modified. QSRLNBR - Contains the preloaded serial number. QMAXSIGN - Specifies how many invalid sign-on attempts are allowed. QMAXSGNACN - Specifies the action to take when the QMAXSIGN limit is reached. QSECURITY - Indicates the security level; valid levels are 10, 20, 30, 40, and 50. The system value QTIME contains the system time of day. It comprises three other system values, QHOUR (based on a 24-hour clock), QMINUTE, and QSECOND. The system value QCURSYM determines the currency symbol, which is country dependent; for example, the yen, lira, franc, and dollar use different symbols.

AS400 System Security Levels Level 10: There is no user authentication, or resource protection. No password is required to sign on. This is no longer supported. (Discontinued in OS/400 Version 4, Release 2) Level 20: Password - User authentication through user profile and password checking; no resource protection. (Resource security means object security that provides protection for system objects like programs, files, and libraries, and the data within these objects.) Level 30: Password and Resource - User authentication and resource protection. Users require authority to access objects.

Level 40: Password, Resource and Operating System Integrity - User authentication, resource protection, and machine interface protection. Level 50: Password, Resource and enhanced Operating System Integrity - User authentication, resource protection,and machine interface protection. Security level 50 is intended for AS/400 systems with high security requirements and to meet C2 security requirements. The iSeries are shipped with a default setting of 40. The system can only be set to one level for all users at any given time. The recommended setting for a secure iSeries machine is 40. This level of security is highly recommended for those locations that have complex processing that includes non-IBM system interfaces, network connectivity and processing of external tapes. One may think using 50 would be even better because it would be even more secure. This statement is true, however, there is a 5 to 15 percent performance decrease in going from level 40 to 50 and also a level of 40 provides an adequate level of security for typical companies. User Classes There are five user classes which are hierarchical in authority. The classes represent different roles in the AS400 environment. These are convenient ways to assign the special authorities listed above to different types of users. A higher class can perform all the functions of a lower class; for example, *SECOFR includes the privileges of *SECADM by default. The following are the five user classes. 1. 2. 3. 4. 5. *SECOFR Security Officer *SECADM Security Administrator *PGMR Programmer *SYSOPR System Operator *USER End User

Authorities In AS/400 terminology, an authority is the permission to access an object. The object owner and the security officer (or other *ALLOBJ users) can grant or revoke authority to an object.

Special Authorities All security systems have special user privileges for certain security and system administration functions. Special authorities allow certain users to administer AS/400 security and system tasks. There are eight special authorities. These special authorities are not hierarchical. *ALLOBJ All object authority is granted for accessing any system resource *AUDIT Allows the user to perform auditing functions *JOBCTL Allows manipulation of job and output *SAVSYS Used for saving and restoring the system and data without having explicit authority to objects queues and subsystems *SECADM Allows administration of User Profiles and Office

*SERVICE Allows access to special service functions for problem diagnosis *SPLCTL Allows control of spool functions *IOSYSCFG Allows change of system configuration Specific authorities Specific authorities are further divided into 2 types. 1. Object Authorities 2. Data Authorities It is important to understand the difference between authority to an object and authority to the data in the object. Operations such as moving, renaming, saving, or deleting apply to the object as such. It is possible to have authority for these operations without having access to the data stored in the object. Likewise, one can have full access (read, write, update, delete, execute) to the data in an object without having full authority to manipulate the whole object. 1. Object Authorities : There are 6 object authorities used in AS/400.Those are as follows. a. *OBJOPR ( Object Operational ) b. *OBJEXIST ( Object Existence ) c. *OBJMGT ( Object Management ) d. *OBJALTER ( Object Alteration ) e. *AUTLMGT ( Authorization List Authority ) f. *OBJREF ( Object Reference ) 2. Data Authorities : There are 5 data authorities used in AS/400.Those are as follows. a. *READ ( Read Data ) b. *ADD ( Add Data ) c. *DLT ( Delete Data ) d. *UPD ( Change Data ) e. *EXECUTE ( Run a Program ) The following authorities are independent (not hierarchical). For some operations a combination of authorities is required: *OBJOPR: The object operational authority controls the use of an object and the capability to look at the description of the object. It is needed to open a file and therefore usually assigned in combination with the desired data rights. *OBJMGT: The object management authority controls the move, rename, and change attribute functions for object, and the grant and revoke authority functions for other users or groups. *OBJEXIST: The object existence authority controls the delete, save, restore, or transfer ownership operations of an object. *AUTLMGT: This authority is needed to manage the contents of an authorization list associated with the object. This is a specialized security authorization that is not usually grouped with the other seven object authorities. *OBJALTER: This authority is needed to alter the attributes of data base files and change the attributes of SQL packages. *OBJREF: This authority is needed to specify a data base file as the first level in a referential constraint. *READ: Controls the ability to read data from the object. *ADD: Controls the ability to insert a new entry (such as a new record in a file) into the object.

*UPDATE: Controls the ability to modify existing entries in the object. *DELETE: Controls the ability to remove existing entries (for example, records) in the object. To delete the whole object requires *OBJEXIST authority. *EXECUTE: Controls the ability to run a program, service program, or SQL package, and to locate an object in a library or a directory. Some common combinations of authorities have been given special names as an abbreviated form. For example, *USE is the combination of *OBJOPR, *READ, and *EXECUTE. *ALL Allows unlimited access to the object and its data *CHANGE Allows unlimited access to the data in the object *USE Allows data in the object to be read *EXCLUDE Allows no access to the object or its data *PUBLIC Authority Public authority is the default authority for an object. It is used if users do not have any specific (private) authority to an object, are not on the authorization list (if one is specified) for the object, or their group(s) has no specific authority to the object User Profiles User Profiles A user profile is an object that identifies a particular user or a group of user to the AS/400 system. The user is known in the system by user profile name. When a workstation signs on, the user id is used to find the user profile setting. The password is defined in the user profile. All AS/400 system security functions rely on the user profile to describe each user. The user profile identifies the authorities to that user. User Profiles contain information describing a system user, that user's privileges and limitations when using the system, and lists of objects the user owns or is authorized to use. For objects owned by a user, the profile also contains lists of other users' authorizations to those objects. Group Profiles A group profile is used to provide the same profile for a group of users. This eliminates the need to assign the authority to each user individually. A User Profile may be linked to a group profile. This allows all the members of the group to share common attributes, common access to selected objects, and common ownership of objects. A group profile is implemented as a user profile; that is, it is created just like a user profile, and when granting authority, the AS/400 does not treat groups any differently than user profiles. The two uses may be intermixed. For easy management it is better that user and group profiles be used as separate entities. One way to enforce this is to set the group profile password to *NONE. This prevents any sign on to the profile. User Profile Management: Create User Profile : The create User Profile (CRTUSRPRF) command identifies a user to the system and allows you to customize the way the system appears. Delete User Profile : The Delete User Profile (DLTUSRPRF) command allows a user to delete a user profile from the system. The User Profile cannot be deleted if a user is currently running under the profile The Change User Profile (CHGUSRPRF) command changes the values specified in a user profile. The password validation rules are not verified by the system when a password is changed by this command. The Work with User Profiles (WRKUSRPRF) display shows you a list of user profiles that you have authority to use. Only someone with either system security officer or security administrator authority can set up these user profiles which determine what system displays and functions each person is authorized to use. If you do not have proper authority, only your user profile will be displayed.

You can do the following with WRKUSRPRF command 1. Create a user profile 2. Change a user profile 3. Copy a user profile 4. Delete a user profile 5. Display a user profile Note: You must have one or more special authorities (such as *SECADM) to perform above operations. Managing OUTQ`s and SPOOL Files All the spool files created by the user as well as system goes into a OUTQ. QPRINT is the default outq of the system. Administrator can set default outq for each user so that the spool files created by that users goes to that outq only. To work with all the outq use following command, WRKOUTQ The Work with Output Queues (WRKOUTQ) command allows the user to display and work with either the overall status of all output queues or all output queues that match the qualified generic name specified and to which the user is authorized, or the detailed status of a specific output queue. The status of the queues may change while the command is being run. To clear the outq use the following command , CLROUTQ < outq name > The Clear Output Queue (CLROUTQ) command removes spooled files from the specified queue. The Clear Output Queue (CLROUTQ) command removes all spooled files on the specified output queue if they are waiting to be written on an output device, including files that are in the hold state. Spooled files that are currently being produced by programs or that are being written to an output device are not removed from the queue. To work with spool files created by particular user use following command, WRKSPLF < user id > The Work with Spooled Files (WRKSPLF) command displays a list of all the spooled files on the system or a selected list from them. You can choose to change, hold, delete, display, or release any or all of the entries that are displayed. You can do following activities with the spool file, 1. DELETE 2. HOLD 3. RELEASE 4. CHANGE 5. SAVE User can change the outq of the spool file.Spool file is assign to a printer to print.User can print the spool file pagewise as per the the requirement Message Handling Message is a means of communication between system and user. These are system messages & User Message. In User Messages users can send their own messages. System Messages and Users Messages are put in the users message queue. Messages may be a) Informational (No reply Needed) b) Inquiry (Reply Needed) Even users can send messages to each other using following commands, 1. SNDBRKMSG 2. SNDMSG By default every message given to the administrator goes into QSYSOPR message queue. Administrator can change this default message queue.

To see the messages of any message queue use following command, DSPMSG To check system operators message queue use, DSPMSG QSYSOPR System Operations An administrator continuously requires to Monitor following on the system. 1. % ASP USAGE OF THE SYSTEM: To find out the Percentage ASP utilized use following command: WRKSYSSTS 2. CHECKING ACTIVE JOBS: Use following command to check active jobs as well as CPU utilization, WRKACTJOB 3. CHECKING SUBSYSTEM STATUS: Use the following command to check all the active subsystems, WRKSBS 4. TO CHECK THE LOG: Use following command to find out the log on the system. DSPLOG You can use same command to find log of a fixed time span. 5. TO CHECK STATUS OF *LIN,*DEV,*CTL : Use following commands to find status of Lines, Devices and Controllers respectively, WRKCFGSTS *LIN WRKCFGSTS *DEV WRKCFGSTS *CTL 6. CHECKING DISK STATUS : Use following command to check the disk status, WRKDSKSTS Subsystem A subsystem is a single, predefined operating environment through which the system coordinates the work flow and resource use. The system can contain several subsystems, all operating independently of each other. Subsystems manage resources. The run-time characteristics of a subsystem are defined in an object called a subsystem description. Subsystem enable better performance tuning. A subsystem description is a system object that includes general definitions and storage pool definitions. The general definitions includes subsystem name, description and maximum number of jobs to run in the subsystem. Storage pool attributes determine how the subsystem uses memory for work, where work can enter the subsystem, how much work the subsystem can handle, how much main storage (memory) will be used, and how quickly jobs in the subsystem can run. To create a simple subsystem, we need four elements: * A subsystem description that describes the overall working environment of the subsystem, including the number of jobs it can run at one time and the OS/400 storage pools the subsystem uses * A job queue, where OS/400 submits jobs that are meant to run in the subsystem * A class object that describes the runtime attributes of jobs entering this subsystem * One or more routing entries that tell the subsystem how to process incoming requests To perform the first step for our own subsystem, creating the subsystem description, use CRTSBSD command. To create a MTHEND subsystem, the CRTSBSD command might look like this: Eg: CRTSBSD SBSD(QGPL/MTHEND)

The second subsystem creation task is to make a unique OS/400 job queue where jobs can be queued up waiting to be processed in your new subsystem. Job queues are created by using the Create Job Queue (CRTJOBQ) command. To create a MTHEND job queue, the CRTJOBQ command might look like this: Eg: CRTJOBQ JOBQ(QGPL/MTHEND) Once the job queue is created, it's a simple matter to attach it to your subsystem by using the Add Job Queue Entry (ADDJOBQE) command, as follows: Eg: ADDJOBQE SBSD(QGPL/MTHEND) Our third step is to use the Create Class (CRTCLS) command to create a class object that describes the run priority, time slice, or purge attributes for jobs running in this subsystem. Use the following command: Eg: CRTCLS CLS(QGPL/MTHEND) Our fourth step is to create a routing entry that tells OS/400 what to do with incoming requests for subsystem MTHEND (through a Submit Job, or SBMJOB, command for batch processing). In our case, we merely want the subsystem to invoke the command processor (QCMD) to run any command contained in incoming jobs. To do this, we use the Add Routing Entry (ADDRTGE) command, as follows: Eg: ADDRTGE SBSD(QGPL/MTHEND) THE FOLLOWING IS A LIST OF SUBSYSTEM RELATED COMMANDS: To start a subsystem, use the Start Subsystem (STRSBS) command. To end a subsystem, use the End Subsystem (ENDSBS) command. To delete a subsystem description, use the Delete Subsystem Description (DLTSBSD) command. To use the DLTSBSD command, the subsystem cannot be active. To change subsystem description, use Change Subsystem Description (CHGSBSD) command. To display subsystem description, use Display Subsystem Description (DSPSBSD) command. To start a subsystem using BRMS, use STRSBSBRM command. To work with subsystems, use WRKSBS command. To work with subsystem description, use WRKSBSD command. To work with subsystem jobs, use WRKSBSJOB command The default subsystems are 1. QCTL - Controlling Subsytem, this subsystem will always be up as soon as the system is started. 2. QINTER - All interactive jobs will run in QINTER subsytem. 3. QBATCH - All batch jobs will run in QBATCH subsystem. 4. QCMN - All communication jobs will run in QCMN subsystem. 5. QSPL - QSPL handles spooled file jobs, including placing files or jobs into disk storage for later processing or printing. 6. QSYSWRK - QSYSWRK coordinates system functions that are started automatically at system startup and when the system comes out of restricted state. 7. QSERVER - This is the file server subsystem. All server jobs will run in this subsystem. 8. QUSRWRK - This is the user work subsystem. It executes prestart jobs and jobs that are started by servers to do work on behalf of a user. Menus The menu allows users to select the task they would like to perform without having to use the system commands. This task menus provides users with a more defined group of choices regarding tasks or objects available

Examples: CRTUSRPRF - Create user profile DSPUSRPRF, CHGUSRPRF, DLTUSRPRF - Display, change, and delete user profile DLTLIB - Delete library CRTLIB, DSPLIB, CHGLIB - Create, display, and change a library ADDLIBLE, CHGLIBL - Add to or change library list CPYF, CRTF, DSPF, CHGF, DLTF - Copy, create, display, change, and delete file WRKACTJOB - Work with Active Jobs WRKSYSSTS - Work with System Status STRSST, STRPASTHR, STRSBS - Start System Service Tools, start pass through (remote login), start subsystem VRYCFG - Vary configuration, bring interfaces up or down

 PWRDWNSYS - Power Down System WRKSPLF - Work with spooled files EASY CODE COPY:

If the source code we want to copy consists of a few short lines, copying would be so easy. If the source code consists of several lines (and some lines can be lengthy), it's not so easy to copy. We've came up with a way to make the process a little easier all the way around. The first major step is to transfer those several lines of code you want to copy into an iSeries source member. Once this is done, the only thing you may have to worry about is the proper column placement. If you're lucky enough, the codes will be stored into the correct format. If you're not, don't lose hope, SEU can handle this with ease. So, when I want to copy a program source, here is what I usually do: 1. Copy the whole program source to the clipboard, paste into notepad, and save it to a PC folder. 2. Send the file to the iSeries host using Client Access. In the Data Transfer To iSeries screen, specify the PC filename, iSeries System, and Library/File(Member) Go to the iSeries File Details screen. Uncheck the 'Use PC file description' checkbox and select 'Yes, create member' from the 'Create iSeries object' dropdown list. You may or may not assign a 'Member text'. Click OK. Click on 'Transfer data to iSeries'. 3. Go to the iSeries green screen and locate the member. 4. Specify '2' on the member and press F4 to bring up the STRSEU prompt. 5. Specify the correct source type, press Enter. 6. On the SEU edit screen, determine the number of characters (n) to move (to the right or to the left). Type RRn (block shift n characters to the right) or LLn (block shift n characters to the left) on the first sequence number line, type B at the SEU command line and press Enter. Complete the block command by typing RR or LL (whichever is applicable) on the last sequence number line. Press Enter. That's it, no piece meal work