Posted by yrangana
When we refer to a user, we mean any person who is signed on to the system. This may include students, programmers, data-entry personnel, operators, and administrators. To perform work on the AS/400, a user needs to be known to the system. A user becomes known to the system when a security officer or administrator creates a user profile object for that user. A user profile not only identifies a user but also describes the user’s authority and is the source of several operational characteristics of that user’s job.
The user ID and password are combined to complete the sign-on process. User IDs and passwords should be kept private. For security reasons, it is recommended that passwords should exceed several digits in length, because longer passwords are harder to guess. The password length is determined by two system values, QPWDMAXLEN (Password Maximum Length), and QPWDMINLEN (Password Minimum Length). A value from 1 to 10 is allowed, but a minimum of five characters is recommended. Like the user ID, the password may not begin with a number. A user’s password cannot be displayed on the AS/400. If the user has forgotten his or her password, the Security Officer or System Administrator can modify the user ID, giving it a new password. For convenience in this situation, the password is generally changed to the same characters as the user ID value; the user should then choose a new password when (s)he next signs on.
Display User Profile
The DSPUSRPF (Display User Profile) command provides such information as the date and time of the previous sign-on, and sign-on attempts that were not valid. This information could assist in verifying unauthorized access. For example, this field may show sign-on attempts during a time period when a user was on vacation or otherwise not available to use the system. To monitor whether an unauthorized person has been attempting to gain access to the system, the number of invalid sign-on attempts is included in the information retrieved by the DSPUSRPF command.
Posted by yrangana
Everything is an Object
On many computing platforms everything is a file, but in contrast on the AS/400 everything is an object.
AS/400 objects share similarities with objects in object-oriented programming, but there are differences as well. There are similarities in that when storage is allocated for something, that something is of a specific type, and only a specific set of programs are allowed to act upon that object. There are differences in that even though the AS/400 supports Java and C++, AS/400 objects cannot be inherited like the classes in those languages. Another difference is that the set of object types in OS/400 (the AS/400’s operating system) is fixed by IBM, and only IBM has the ability to create new ones.
Ownership of Objects
Each object is assigned an owner when it is created. The owner is either the user or the group profile that created the object. When the object is created, the owner is given all the object and data authorities to that object. If ownership of the object is given to another user profile, the original owner has the option to keep all the object and data authorities the same, or to remove all authority to the object. If the creating user has specified that the group profile should be the owner of the object, then all members of the group profile have authority to the object. If the owner of an object is a group profile, then any user assigned to the group may add, modify, or delete records in the object, assuming all data authorities are provided. This feature is helpful when data sharing is necessary.
The number of object types is huge and a small subset of them are available to users. The human readable form of the object type is always a three to six character mnemonic preceded by an asterisk. What follows is a short list of the more commonly used objects and their mnemonics:
- *LIB: Library (where everything below, except directories and stream files, is stored; libraries cannot exist within other libraries)
- *PGM: Program (for compiled languages: CL, RPG-IV, C, C++, COBOL, etc. and there are no interface restrictions between the languages).
- *MODULE: Module (linkable into a program from a compiled language above and here too there are no restrictions on linkability between languages).
- *SRVPGM: Service program (dynamic set of one or more modules, akin to a DLL file in Microsoft Windows).
- *BNDDIR: Binding directory (holds a list of modules and service programs and is used when creating programs).
- *CMD: Command (an object used for calling programs that allows users to prompt for their parameters; can be created with the Command Definition language). See AS/400 Control Language for more information.
- *MENU: Menu (accessed with the GO command).
- *FILE: File (AS/400 files can be used for data, input/output devices, and source code, depending on sub type).
- *DTAARA: Data area (small bits of storage used to store tiny items of data for fast access).
- *DIR: Directory (part of the Integrated File System that is equivalent to Unix and Microsoft Windows hierarchical file systems).
- *STMF: Stream file (traditional file that would be familiar to most Unix and Microsoft Windows users and only stored in directories)
- *JRN & *JRNRCV: Journal and journal receiver (used to journal changes to files, data areas, and stream files).
- *USRPRF: (allows users to sign-on to the system).
- *JOBD: Job description (used when submitting/starting jobs).
- *SBSD: Subsystem description (used when starting subsystems; this is the place where user jobs run).
- *JOBQ: Job queue (used to queue up batch jobs to run in a subsystem).
- *LIND: Line description (communications line: Ethernet, token ring, etc.).
- *CTLD: Controller description (communications controller for lines, workstations, etc.).
- *DEVD: Device description (communications device for lines, workstations, printers tape drives, etc.)
- *DTAQ: Data queue (used to queue up data entries for fast retrieval by other jobs).
- *MSGQ: Message queue (used to send message to users, can also be used like a data queue).
- *OUTQ: Output queue (used to queue up output to a printer).
- *USRSPC: User space – a generic data-containing object of arbitrary size (up to 16T).
A library (*LIB) on the AS/400 is an object that is used as a system directory to keep track of other objects. AS/400 objects are not actually stored in libraries. They’re really nothing more than namespaces, but it’s easier to refer to an object as being “in” or “stored in” a library.
Certain types of the AS/400 object (database file, storage areas and executable program objects) can be compiled, copied, and stored into/from many different libraries concurrently, with the Library List hierarchy determining which instance of the object to use during execution of any application that utilizes that object name. There are AS/400 commands to help move objects around, and objects may be qualified at compile time to point to specific other objects statically at runtime, in order to circumvent the Library List.
Libraries cannot contain other libraries
The AS/400 uses a library in much the same way that personal computers use directories. Libraries and directories are holding areas for related material. For example, one library might be dedicated to payroll programs, another to inventory control. Libraries generally contain many other objects. Unlike directories, however, libraries cannot contain other libraries (with one exception library QSYS, discussed below). AS/400 is structured as a list, the opposite of Windows which has a tree-like structure. To find an AS/400 object requires the name of the library and the name of the object. The AS/400 identifies objects by their qualified name, which takes the form LIBRARY/OBJECT. For example, to reference the EMPMASTER file in the PAYROLL library, you’d usually refer to PAYROLL/EMPMASTER.
Other types of objects, designated as “system” objects cannot be replicated. Libraries are a “system” object, and therefore only one instance of any given Library “name” is possible. They’re made to appear as if they’re stored in the QSYS library. Other “system” objects include user profiles (*USRPRF), configuration objects (*LIND, *CTLD, *DEVD), etc..
On systems with hierarchical filing systems the norm is to have many directories, most of which are contained one within the other, and with a moderate number of files in each directory. Since libraries cannot be stored within other libraries on the AS/400 and because historically the library list was always so small, the opposite became the norm; small numbers of libraries each of which contain large numbers of objects. A library is similar to a folder in Windows. In AS/400 a library is another object that can contain other objects (executable objects, source files, etc.).
Most homegrown applications have between one and three libraries. Some have program, source, and file objects together in one library. With shops that have a huge amount of data and a small backup window they usually split the database files into a separate data library and keep the source and programs in another library. In companies with a separate development systems they tend to split it further by placing the source into its own library.
Generally speaking all libraries created by IBM for use by the operating system begin with the letter ‘Q’.
IBM Standard Libraries:
- QSYS – system library for the AS/400. It contains the programs and other objects that make up the operating system. QSYS must exist on an AS/400 for the system to work. Other libraries on the AS/400 exist within the context of the QSYS library; it is the only library that can contain other libraries. A few special objects, such as user profiles and I/O configurations, can exist only within QSYS. You should never modify or delete any object within the QSYS library.
- QSYS2 – System Library for CPI’s.
- QHLPSYS – Contains on-line help information that is displayed when the Help key or the extended help function keys are pressed.
- QTCP – TCP Connectivity Utilities.
- QSPL – holds the spooled, printed output pages that have not yet been printed.
- QAFP – Advanced Function Printing.
- QGPL – General Purpose Library that contains IBM-provided objects. The system places newly created objects that are not specifically placed in a distinct library in QGPL.
- QTEMP – Job specific temporary Library (deleted when the job ends), Each time a user signs on, the system creates a QTEMP library for this interactive job. If the user submits a job to the batch queue, another QTEMP library is created for the batch job.
In most installations, the system administrator creates user libraries. User libraries are commonly created to hold one individuals work; for example, each programmer should have his or her own user library. The administrator can create as many user libraries as are convenient; the only limit is the amount of disk space available in DASD.
- AS400 Control Language (as400iseries.wordpress.com)