Setting Up Job Monitor using Management Central

It's very easy to setup the monitor for Jobs in the system. This monitor once configured and started can provide details pertaining to Job Name,Number, Start and end time and severl other required metrics like Disk I/O used, number of threads etc. Following are the steps for implementing the same.

1. Open iSeries Navigator
2. Click on Management Central to expand (Make sure Management Central Job is on your system otherwise connection to Management Central server will end.)

3. Right click on Job and select New Monitor, New Monitor dialog box will appear. Provide a name to Monitor and under tab Jobs to monitor, add the kind of jobs to be monitored one by one and proceed to next tab of Metrics.

4.  Select the metrics and proceed to Collection interval tab and specify the time interval for collection of different jobs metrics.

5. On the actions tab, select the available actions and proceed for Systems and Groups, and add the systems to be monitored. Once done, click ok and you will see a monitor created for you having a stopped status. Right click over monitor and select Start, once started, you can have the details based on the collection interval selected for all kinds of jobs.

Determining How Many Users Are Registered for Licensed Products

To determine the peak usage of licensed products, do the following:
1 To get to the license information, on the operating system command line, type the following:
   WRKLICINF  & Press the Enter key.
2 Select the product desired and use option 5 to display the information.
3 The Display License Information screen shows the current number of users registered, the threshold configured prior to sending warning messages, and data on the peak usage number and date reached.

Special Authorities

Special authority is used to specify the types of actions a user can perform on system resources. The SPCAUT parameter in the user profile is where the special authorities are given.

All Object (*ALLOBJ) Special Authority
All-object (*ALLOBJ) special authority allows the user to access any resource on the system whether or not private authority exists for the user. Even if the user has *EXCLUDE authority to an object, *ALLOBJ special authority allows the user to access the object.
Risks: *ALLOBJ special authority gives the user extensive authority over all resources on the system. The user can view, change, or delete any object. The user can also grant to other users the authority to use objects.
A user with *ALLOBJ authority cannot directly perform operations that require another special authority. For example, *ALLOBJ special authority does not allow a user to create another user profile, because creating user profiles requires *SECADM special authority. However, a user with *ALLOBJ special authority can submit a batch job to run using a profile that has the needed special authority. Giving *ALLOBJ special authority essentially gives a user access to all functions on the system.

Security Administrator (*SECADM) Special Authority
Security administrator (*SECADM) special authority allows a user to create, change, and delete user profiles.
In addition, *SECADM special authority gives the user comprehensive authority to manage IBM® OfficeVision®/400 objects and users. A user with *SECADM special authority can:
 o    Add users to the system distribution directory. This includes the right to create and change user profiles for OfficeVision®/400 users.       
 o    Display authority for documents or folders.       
 o    Add and remove access codes to the system.      
 o    Give and remove a user's access code authority.       
 o    Give and remove permission for users to work on another user's behalf.      
 o    Delete documents and folders.      
 o    Delete document lists.       
 o    Change distribution lists created by other users.   
Only a user with *SECADM and *ALLOBJ special authority can give *SECADM special authority to another user.

Job Control (*JOBCTL) Special AuthorityJob control (*JOBCTL) special authority allows the user to:
 o    Change, delete, hold, and release all files on any output queues specified as OPRCTL(*YES).       
 o    Change the running attributes of a job, such as the printer for a job. end, and copy all files on any output  queues specified as DSPDTA(*YES or *NO) and OPRCTL(*YES).      
 o    Hold, release, and clear job queues specified as OPRCTL(*YES).       
 o    Hold, release, and clear output queues specified as OPRCTL(*YES).       
 o    Hold, release, change, and cancel other users' jobs.       
 o    Start writers, if the output queue is specified as OPRCTL(*YES).       
 o    Change the running attributes of a job, such as the printer for a job.       
 o    Stop subsystems.      
 o    Perform an initial program load (IPL).     

Spool Control (*SPLCTL) Special Authority
Spool control (*SPLCTL) special authority allows the user to perform all spool control functions, such as changing, deleting, displaying, holding, and releasing spooled files. The user can perform these functions on all output queues, regardless of any authorities for the output queue or the OPRCTL parameter for the output queue.
*SPLCTL special authority also allows the user to manage jobs on job queues, including canceling the jobs and changing their priorities. The user can perform these functions on all job queues, regardless of any authorities for the job queue or the OPRCTL parameter for the job queue.
Risks: The user with *SPLCTL special authority can perform any operation on any spooled file in the system. Confidential spooled files cannot be protected from a user with *SPLCTL special authority. The user with *SPLCTL special authority can also control jobs waiting in job queues. The user could run jobs out of sequence or cancel jobs that update critical files.

Save System (*SAVSYS) Special Authority
Save system (*SAVSYS) special authority gives the user the authority to save, restore, and free storage for all objects on the system, whether or not the user has object existence authority to the objects.
Risks: The user with *SAVSYS special authority can:
 o    Save an object and take it to another system to be restored.       
 o    Save an object and display the tape to view the data.       
 o    Save an object and free storage, thus deleting the data portion of the object.      
 o    Save a document and delete it.   

Service (*SERVICE) Special Authority
Service (*SERVICE) special authority allows the user to start system service tools using the STRSST command. This allows the user to debug a program with *USE authority to the program and to perform the display and alter service functions. The dump function can be performed without *SERVICE authority.
Caution: A user with *SERVICE special authority can display and change confidential information using service functions.   

Audit (*AUDIT) Special Authority
Audit (*AUDIT) special authority gives the user the ability to change auditing characteristics. The user can:
 o    Change the system values that control auditing.      
 o    Use the CHGOBJAUD and CHGDLOAUD commands to change auditing for objects.       
 o    Use the CHGUSRAUD command to change auditing for a user.   
Risks: A user with *AUDIT special authority can stop and start auditing on the system or prevent auditing of particular actions. If having an audit record of security-relevant events is important for your system, carefully control and monitor the use of *AUDIT special authority.

System Configuration (*IOSYSCFG) Special Authority
System configuration (*IOSYSCFG) special authority gives the user the ability to change how the system is configured, such as adding or removing communications configuration information. Most new commands for configuring communications, such as TCP/IP commands and OSI commands, require *IOSYSCFG special authority. In most cases, existing communications commands have not been changed to require *IOSYSCFG special authority. Appendix D of the Work Management Guide shows what special authorities are required for specific commands.
Recommendations for Special Authorities: Giving special authorities to users represents a security exposure. For each user, carefully evaluate the need for any special authorities. Keep track of which users have special authorities and periodically review their requirement for the authority. In addition, control if user profiles with special authorities can be used to submit jobs and if programs run using their authority (adopted authority).

Security Levels

The system provides the following levels of security:

10    No system-enforced security

Note: For V4R3, IBM® is dropping support for security level 10. IBM will not accept APARs for problems that cannot be re-created at security level 20 or higher. In addition, you can no longer set the QSECURITY system value to 10.   

  
20    Sign-on security      
30    Sign-on and resource security      
40    Sign-on and resource security; integrity protection      
50    Sign-on and resource security; enhanced integrity protection   

Security Level 10

At security level 10, you have minimal security protection. When a new user signs on, the system creates a user profile with the profile name equal to the user ID specified on the sign-on display. If the same user signs on later with a different user ID, a new user profile is created.

The system performs authority checking at all levels of security. Because all user profiles created at security level 10 are given *ALLOBJ special authority, users pass every authority check and have access to all resources. To test the effect of moving to a higher security level, remove *ALLOBJ special authority from user profiles and grant those profiles the authority to use specific resources. However, this does not provide security protection. Anyone can sign on with a new user ID, and a new profile is created with *ALLOBJ special authority. This cannot be prevented this at security level 10.

Security Level 20

In addition to the functions provided at security level 10, security level 20 provides the following additional security functions:

o    Both user ID and password are required to sign on.      
o    Only a security officer or someone with *SECADM special authority can create user profiles.       
o    The limit capabilities value specified in the user profile is enforced.   

Security Level 30

In addition to the functions provided at security level 20, security level 30 provides the following additional security functions:

o    Users must be specifically given authority to use resources on the system.      
o    Only user profiles created with the *SECOFR security class are given *ALLOBJ special authority automatically.   

Security Level 40

Security level 40 prevents potential integrity or security risks from programs that could circumvent security in special cases. Security functions at level 40 include:

o    Preventing the use of unsupported interfaces      
o    Preventing the use of restricted instructions      
o    Protecting job descriptions      
o    Preventing signing on without password      
o    Enhanced hardware storage protection      
o    Protecting a program's associated space      
o    Protecting a job's address space   

Security Level 50

Security level 50 provides enhanced integrity protection for installations with strict security requirements. Security level 50 is designed to meet the requirements defined by the U.S. Department of Defense for C2 security. It provides enhanced integrity protection in addition to what is provided by security level 40. Running your system at security level 50 is required for C2 security.

Determining Which System Values Have Been Changed, When They Were Changed, and By Whom

A message CPF1805, CPF1806, CPF1815, CPF180F or CPF1823 is written to the history file (QHST) each time a system value is changed. Additionally, a message CPF1807, CPF1808, or CPF1824 is written to the history file to indicate that a system value may or may not have been changed. To capture this information, do the following:

1  On the operating system command line, type the following:  

     DSPLOG & Press F4 to prompt.      
2 Select the starting and ending dates to search (based on the amount of history information kept on the system).      
3 Press F10 for additional parameters and page down. On the parameter called MSGID, type CPF1805, CPF1806, CPF1807, CPF1808, CPF1815, CPF1823, CPF180F and CPF1824.      
4 All occurrences of these messages are displayed.      
5 Bring the cursor to the message showing the desired system value that was changed, and press the F1 key for additional message information. Then, press the F9 key for message details. The qualified job name of the job that changed the system value is shown.   

Creating a Subsystem

A subsystem can be created using one of the following methods. You can copy an existing subsystem description and change it, or you can create a new description. Use one of the following methods.

Copy an existing subsystem description and customize to your needs:

1. Create a duplicate object, CRTDUPOBJ, of an existing subsystem description. (The WRKOBJ or WRKOBJPDM commands can also be used.)

2. Change the copy of the subsystem description. The most common changes to make are to remove the existing job queue entries from the duplicate object so that it will not try to allocate the same job queues as the  original subsystem. Use the Remove Job Queue Entry (RMVJOBQE) command for that. Then, create one or more new job queues for the new subsystem using the Create Job Queue (CRTJOBQ) command and attach them to the new subsystem via the Add Job Queue Entry (ADDJOBQE) command.

Create an entirely new subsystem description:

1. Create a subsystem description (CRTSBSD).

2. Create a job description (CRTJOBD).

3. Add work entries to the subsystem description.

o ADDWSE (Add Workstation Entry)
o ADDJOBQE (Add Job Queue Entry)
o ADDJOBQE (Add Job Queue Entry)
o ADDCMNE (Add Communications Entry)
o ADDAJE (Add Autostart Job Entry)
o ADDPJE (Add Prestart Job Entry)

4. Create a class (CRTCLS).

5. Add routing entries to the subsystem description (ADDRTGE).

Creating a Storage Pool

To create a private storage pool, use the POOLS parameter on the Create Subsystem Description (CRTSBSD) or Change Subsystem Description (CHGSBSD) commands.
Shared pools simply need to have storage defined for them using the Change Shared Pool (CHGSHRPOOL) or the Work with Shared Pool (WRKSHRPOOL) commands.

Deleting Licensed Programs No Longer Needed

If there are Licensed Programs on the system that are no longer needed, delete them from the system by typing the following command on an operating system command line:

GO LICPGM

Press the Enter key. This shows the Work with Licensed Program Menu. Select Option 12 to delete licensed programs. This displays a list of the Licensed Programs on your system. Type 4 next to the programs to be deleted.

Preventing Job Logs from Being Produced

To prevent a job log from being produced at the completion of a batch job, specify *NOLIST for the message level text of the LOG parameter
on the Batch Job (BCHJOB), Submit Job (SBMJOB), Change Job (CHGJOB), Create Job Description (CRTJOBD), or Change Job Description (CHGJOBD)
commands. If *NOLIST is specified for the message text value of the LOG parameter, the job log is not produced at the end of a job unless
the job end code is 20 or greater. If the job end code is 20 or greater, the job log is produced.

SBMJOB LOG(4 0 *NOLIST)
CHGJOB LOG(4 0 *NOLIST)
CRTJOBD JOBD(QGPL/JOBD) LOG(4 00 *NOLIST)
CHGJOBD JOBD(QGPL/JOBD) LOG(4 00 *NOLIST)

For an interactive job, the value specified for the LOG parameter on the SIGNOFF command takes precedence over the LOG parameter value specified
for the job.

SIGNOFF LOG(*NOLIST)

Restricting Users From Using the Command Line

To limit users from using the command line, do the following for each user profile:
1. Issue the CHGUSRPRF command () to prompt the command, then select for additional parameters.
2. Change the Limit Capabilities to *YES. This will prevent users from using the command line.
 Users will still be authorized to their commands; however, they will only be able to use those commands from a menu. Every command has an "Allow Limited User" parameter. By default, this is set to *NO. The following commands are an  exception and are shipped with *YES. These commands are SIGNOFF, SNDMSG, DSPMSG, DSPJOB, DSPJOBLOG, STRPCO, and WRKMSG.
To view what the 'Allow Limited User parameter is set to for a specific command, use the DSPCMD  command and enter the  command in question.

   Note: The limited capabilities apply only to the IBM command line. If limited capabilities for the user profile is set to *YES and Allow Limited User is set to *NO for the command, but the user is still able to run the command, they may be using a third-party command line. You should try CALL QCMD to get to the IBM command line and issue the command again.

Erasing DASD

In some cases, a customer may wish to erase all data off their system. They may want to do this because they are sun setting the system and want to destroy or remove all data on the system.

If this is to remove the data from a system upon completion of a Disaster Recovery test and the test was done on a secondary partition, follow the steps as outlined in the section No Partitions on the partition that was used for the test to erase the data from that partition. It is not necessary to run this procedure on any other partition other than the one where the test was performed.

No Partitions:

The procedure for doing this follows:

1. Do a D Manual IPL using a SAVSYS, full system save, or LIC Install CD.

2. The first menu will give an Option 1 to Install LIC, and Option 2 to use DST. Select Option 1.

3. The Install LIC menu will provide 5 options. Select Option 2 to Install Licensed Internal Code and Initialize System.

   Note: Data still remains on the disk units until the following steps are completed.

4. After the installation of LIC is complete, the systems will IPL to the DST primary menu (IPL or Install the System).

5. Configure all the disk drives by adding them into system ASP (ASP 1). This writes zeroes on the disk drives so only the LIC is loaded.

    a Select Option 3 - Use DST.
    b Work with Disk Units.
    c Work with Disk Configuration.
    d Work with ASP Configuration.
    e Add units to ASPs.
    f Type 1 in front of all the available units.

   Note: If using the LIC Install CD (I_Base) to install LIC, the default password for QSECOFR will be uppercase QSECOFR.

6. When that is complete, power off the system by pressing the power button two times.

        The system is clean and ready to go.


Partitioned System: (This will remove all partitions and erase all data on drives from all earlier partitions.)

The procedure for doing this follows:

1.  Do a D Manual IPL using a SAVSYS, full system save, or LIC Install CD of the primary partition.

2.  The first menu will give an Option 1 to Install LIC, and Option 2 to use DST. Select Option 1.

3.  The Install LIC menu will provide 5 options. Select Option 2 to Install Licensed Internal Code and Initialize System.

4.  After the installation of LIC is complete, the system will IPL to the DST primary menu.

    Note: If using the LIC Install CD (I_Base) to install LIC, the default password for QSECOFR will be uppercase QSECOFR.

5.  Take the option to Work with system partitions.

6.  Take the option to Recover configuration data.

7.  Take the option to Clear non-configured disk unit configuration data.

8.  Exit back to the DST primary menu.

9.  Configure all the disk drives by adding them into system ASP (ASP 1). This writes zeroes on the disk drives so only the  LIC is loaded.

    a  Select Option 3 - Use DST.
    b  Work with Disk Units.
    c  Work with Disk Configuration.
    d  Work with ASP Configuration.
    e  Add units to ASPs.
    f  Type 1 in front of all the available units.

10.  When that is complete, power off the system by pressing the power button two times.

    The system is clean and ready to go.

AS/400 Concepts and Terminology

AS/400 Architecture

The AS/400 is a very complex integrated system that includes hardware, software, security, a database and other components. The AS/400 Advanced Architecture is unique in that it is extremely adaptable and can easily incorporate new technologies. This is important in today’s fast changing computer marketplace. The AS/400 is designed to separate the software and hardware so changes in one have little effect in the other. This is accomplished through the Machine Interface (MI) which is a software programming interface between the application, the operating system and hardware. The MI is a complete Application Programming Interface (API) set that all applications must use in order to get to the to the hardware. This is how the AS400 achieves the software independence.

OS/400 Operating System

The Operating System for the AS/400 is called OS/400. The OS/400 resides above the MI. This allows the operating system to be independent from the hardware.  Most operating system components handle functions such as memory, process, program, and I/O management. On the AS/400 these lower level functions are handled by the Licensed Internal Code (LIC) which is the operating system software below the MI. The LIC protects application programs and OS/400 from hardware changes. Thus again, keeping the software separate from the hardware.

Integrated File System

The AS/400 contains an integrated file system (IFS). This means applications written on other file systems, PC, Unix, etc., can access data stored on the AS/400.  The IFS integrates all file systems on the AS/400 with one interface and one set of rules. How the AS/400 developers accomplished this was to use a single root, like a PC file system, and put all other file systems under it.  From a Windows client the AS/400 would appear as a network drive. Under that drive you would have PC-like subdirectories for all the file systems the AS/400 supports. Currently there is support for PC file systems, Unix file systems, OS/400 libraries, and others.  The IFS provides access to the data. The data must be in compatible format for the requesting application.

DB2/400 Database – The Integrated Database

The AS400 contains a relational database called DB2/400. DB2/400 is integrated into the AS/400 partly above the MI and partly in the LIC. Conventional databases are separate software components that reside on top of the operating system. Since DB2/400 is integrated throughout the entire system it can achieve a higher level of efficiency because it is tightly integrated with the components with which it communicates. The database management system (DBMS) is a framework for storing and retrieving data. A DBMS must have an interface so users can access and manipulate the data. There are two interfaces to the AS/400: The Data Description Specifications (DDS) and Structured Query Language (SQL).  The DDS, or the native interface, was carried over from the IBM System/38. It has a look and feel similar to IBM’s Information Management System (IMS). The second interface for the AS/400 is SQL. This is the industry standard for relational databases and is an optional product that you must purchase separately.

Data Warehousing

DB2/400 supports data warehousing. The four main components that DB2/400 utilizes for data warehousing are:  transformation and propagation tools to load the data warehouse, the data warehouse database server, analysis and end-user tools, and tools to manage the information about the data warehouse. Transformation and propagation tools are used to move and manipulate data into a form more appropriate for the warehouse. It transforms operational data into informational data.
IBM introduced special models of the AS/400 that are able to handle the types of workloads use in data warehousing applications. These database servers utilize parallel processing and multidimensional databases. The AS/400 uses parallel I/O processing (IOP). This allows parallel processing at the I/O level for a single job.  By doing this it helps increase I/O processing time. The AS/400 also can take a single query and break it down to independent queries and these are run in parallel across the multiple processors in the system. This can increase performance for the original query.
Most relational databases are organized as two-dimensional tables.  A multidimensional databases has one or more additional dimensions. DB2/400 can create a three-dimensional data structure. These structures have three axis’s and look like a three dimensional spreadsheet.
The DB2/400 uses business intelligence tools to analyze the data in the data warehouse. These include: Decision support (DSS) tools, executive information systems (EIS), and data mining tools. DSS tools allow the user to create questions, in the form of queries, to get answers to the questions. They enable the user to create ad hoc queries and build reports. EIS’s combine DSS tools with some extended analysis capabilities. Data mining tools allow for the discovery of information with little or no direction from the user. The system searches through the data to determine patterns or associations.

Objects

The AS/400 is sometimes described as an object based system because objects are a fundamental part of the design of the system. Almost everything in the AS/400 is an object. These include data files, user profiles, job queues, message queues, print queues, compiled programs, word processing documents, menus, etc. On the AS/400 objects are categorized by type, which allow the user to specify what type of objects are required for a given task. There are OS/400 objects and MI system objects. Some OS/400 objects map one to one with MI system objects, but other have a one to many mapping. This is because some OS/400 objects need to map to multiple MI system objects. All OS/400 objects map to at least one MI system object. The 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.

Libraries

A library is an OS/400 object that is used to find other OS/400 objects in the database.
The library is organized as a single-level hierarchy, unlike the directory structure found on PCs which have a multilevel hierarchy. To find an OS/400 system object you need the name of the library and the name of the object.  The AS/400 identifies objects by their qualified name, which takes the form of LIBRARY/OBJECT.   For example, to find the object MONEY in the library PAYROLL you would reference this as PAYROLL/MONEY. Two or more objects can have the same name but they must be different types of objects. For example you could have a program named TEST and a data space named TEST, but not two programs named TEST. An object can exist in only one library. A library cannot reference other libraries except for the library called QSYS. This is the only library that can access other libraries.

Physical Files

A physical file holds the actual data. The physical file record has a fixed set of fields. Each field can have variable lengths. A physical file has two parts. The first part contains the file attributes and field descriptions. The file attributes include the file’s name, owner, size, number of records in the file, key fields, and other attributes.  The field descriptions hold the attributes for each field in the record. The second part of a physical file contains the data.

Logical files

Logical files allow a user to access data in a format that is different from the way it is stored in one or more physical files. The logical file contains no data records. It contains the corresponding record number of the data record in the physical file. The logical file will contain the index to the physical file. Logical files provide the path to the physical file. There are four types of logical files. The first is the simple logical file. This maps data from a single physical file to another logical record definition. The second is the multiple-format logical file.  This logical file allows access to several physical files. The third type of logical file is the join logical file. The join logical file defines a single record definition that is built from two or more physical files, tables, logical files, or views. The total number of physical files and tables cannot exceed 32. The forth type of logical file is the SQL view. These are similar to join logical files but SQL view logical files locate the access path at run time by use of the Query Definition Template and are not maintained by each join.

Collections

A collection is a grouping of related SQL objects. This is the SQL name for a library in the native interface.

Resetting QSECOFR Service Tools Password

On the AS/400, log onto a session as QSECOFR. It will not work with any other profile.
At a command line, type CHGDSTPWD (Change IBM Service Tools Password) and on the Password Parameter type *DEFAULT. Press Enter.
On the front of your AS/400, you need to change the mode of the box to MANUAL - which the LED panel should now display 02 B.
Use the white toggle switch and go up until 21 is displayed in the LED panel. Press Enter.
You should now have a DST (Dedicated Service Tools) screen on your CONSOLE. Go there now.
Sign onto DST as QSECOFR with the password being QSECOFR. Please note that you cannot use the Cap locks but must use the Shift Key and the password must be capitalized and is case sensitive.
Change the password to DST now. Please note a few gotchas about the new password:
     a. Has to be 6-10 characters long
     b. Cannot have repeating characters
     c. It is case sensitive
     d. Cannot be one of a previous 18 passwords used
Please note that you should create a "backdoor" userID and password to get into SST. In the event that this happens again, you have a profile to log on and re-enable profiles.
Change the LED panel on your AS/400 back to NORMAL mode.

Latest PTFs Index

Requesting PTFs and Cover Letters Using the Internet

Internet access is an alternative connection method between the AS/400 system and the RETAIN system that houses PTF information. On the Internet, users can:

• Browse PTF information

• Request shipment of a CUM package

• Request shipment of selected PTFs

Enabling Internet access over using ECS to request delivery has an advantage for many customers in the U.S. due to the cost, availability of modems, and higher speed transfer. Internet access provides a graphical interface and has the potential for faster access and download of PTF information. This is a result of higher speed modems that are available through some Internet service providers and the possible use of T1 lines. ECS PTF delivery is limited to a SDLC 19.2 kbps synchronous connection. For some customers, ECS remains the preferred method to request PTFs. In other cases where ECS is not available, Internet access provides a faster and more efficient solution than delivery of the PTF information through the “mail.”

Internet delivery does not replace or affect the traditional PTF order process. If you do not have access to the internet, continue using the ECS PTF order function with the SNDPTFORD command. To print cover letters for PTFs for a product installed on your system, enter the command:

DSPPTF LICPGM(57nnxxx) SELECT(yyyyyyy) COVERONLY(*YES) OUTPUT(*PRINT)

In the command, xxx is the licensed program number, and yyyyyyy is the PTF ID. The output can be viewed in the spooled file named QSYSPRT. To print a cover letter of a PTF for a product not installed on your system, enter the following command:

CPYF FROMFILE(QGPL/QAPZCOVER) TOFILE(QGPL/QPRINT) FROMMBR(Qxxxxxxxyy)

In this command, xxxxxxx is the PTF ID, and yy is the language ID. English PTFs do not have a language ID.

Applying CUM Packages

Cumulative packages can be applied at the same time as individual PTFs.
If you receive the individual PTFs on tape, follow these steps:
1. Place the tape containing the individual PTFs in the tape drive.
2. Enter GO PTF and select option 8 (Install program temporary fix package).
3. Specify Automatic IPL N on the Install Options for Program Temporary Fixes display.

If you receive the individual PTFs through ECS, perform these steps:
1. Enter GO PTF and select option 8 (Install program temporary fix package).
2. Specify *SERVICE for the device parameter, and select N for Automatic IPL.

When the GO PTF command is used to install PTFs from *SERVICE, all PTFs in *SERVICE not already installed are installed.
*SERVICE means that the PTF exists in a save file in the QGPL library and that the system checks for these PTFs during the installation process.

Cumulative PTF Package

Not all PTFs produced are included in a cumulative PTF package. The following criteria help determine if a given PTF is incorporated into a subsequent cumulative package:

· The number of customer orders for a particular PTF

· The severity of the associated APAR

· Whether the PTF is designed as HIPER

· Problems that crash a system and require an IPL

· High availability options (mirroring or checksum, for example)

· Problems that require a reinstall or restore

· Save and restore problems that prevent data recovery

· Problems affecting installability of a product or feature

· Problems affecting a product¢s major useability function

· Problems requiring an unnecessary replacement of hardware parts

· Pervasive customer satisfaction problems

· Data integrity and security problems

· If the PTF has a corresponding PTF in a previous release package (to minimize the rediscovery)

PTFs that have special instructions, which might break the system if they are not followed, are not usually incorporated into the cumulative package.

Applying PTFs without an IPL

Beginning in V3R1, PTFs are built to produce PTFs without requiring IPLs to apply them whenever possible. PTFs that can be applied immediately have additional activation steps, which are described in the cover letter. Updateable and non-updateable actions exist.

Updateable action PTFs are shipped with an action-exit program to verify the actions required to activate the PTF. The action-exit program is called by the DSPPTF command to list the actions necessary and verify whether the actions are completed. The exit program is called when the details for the PTF are shown using option 5 on the DSPPTF status panel or when you specify SELECT(*ACTRQD) on the DSPPTF command. The status of the PTF is updated if the actions are complete. The status changes from Temporarily applied—PND to Temporarily applied after the required actions are complete.Non-updateable action required PTFs do not have exit programs to verify that the actions have been done. These PTFs remain in a Temporarily applied—ACN status until the next IPL when the status changes to Temporarily applied.

LIC PTF Apply and System Availability

To apply LIC PTFs, the system must be able to access the A-side. If the system IPLs from the B-side, a message appears indicating the wrong copy of LIC is in use. To apply LIC PTFs, we recommend that you use the following command:

PWRDWNSYS OPTION(*IMMED) RESTART(*YES) IPLSRC(B)

This command performs an IPL to the A side to apply the LIC PTFs and then to the B side to apply the rest of the PTFs. Since the Job Scheduler can only perform IPLs on the B-side, LIC PTFs are not applied. If these LIC PTFs are the prerequisite of any OS/400 licensed program PTFs, the latter is not applied.

To increase the number of immediate PTFs for LIC, the apply procedure for nucleus modules was changed to fixes for nucleus modules beginning with V4R2.

Space usage allows more PTFs to be built for an immediate apply. Changing the apply process for nucleus modules and minimizing the space usage enable the building of more PTFs as immediate, thus shortening or completely removing downtime caused by IPLs required to apply fixes.

Applying and Removing PTFs and IPLs

To progress toward 24 x 365 system availability, it is necessary to reduce or eliminate maintenance operations that cause the system to be off-line. These days, a primary cause of downtime is the application of PTFs, especially fixes that are applied to the Licensed Internal Code (LIC). More and more PTFs need to be, and are, built to apply immediately to help reduce downtime. When applying a microcode PTF on systems prior to V4R1, the system performs an IPL from the A-side to the apply PTF stage. That includes up to the C6nn nnnn set of System Reference Codes (SRCs). Microcode PTFs are applied. Before OS/400 is started, the system powers down and perform IPL again using the B-side. The IPL is selected using the control panel or the defaults of the PWRDWNSYS command. This process is fairly lengthy, and requires the LIC to be loaded for each IPL. On V4R1 and later systems, if the microcodes PTFs do not affect the MFIOP microcode, the system does not reload the MFIOP when applying the PTFs. This process avoids the need for a second IPL.

For example, a user may apply a delayed microcode PTF while on the B-side, and issue a PWRDWNSYS with a RESTART(*YES) and TYPE(*SYS). The system powers down and performs a mini-IPL without reloading the code into the MFIOP. The microcode PTF subsequently is applied during the SLIC part of the IPL. After the PTF is applied, the system IPLs again without reloading the MFIOP code. If the PTF affects the MFIOP code, the MFIOP code is reloaded during the IPL. The advantage of this approach is that the system does not have to IPL all the way up to OS/400 on the A-side, before coming down and performing IPL again on the B-side. This way, the IPL time is considerably reduced, and the PTF application is faster than it was prior to V4R1. This process is pictured below:

PTF Terminoloy

PTF

A PTF is a set of program modules meant to replace an earlier version of a program module. PTFs are first loaded onto the AS/400 system as save files.

Superseded PTF

A superseded PTF has its program modules replaced by a PTF that was released at a later time. The superseded PTF is not installed on the system. The superseded PTF is included in a PTF that was produced later and is installed on the system.

Prerequisite & Co-requisite PTFs

Prerequisite PTFs must be applied before or at the same time as the PTF, which requires them, is applied. Co-requisite PTFs must be applied at the same time as the named co-requisite PTF that needs them.

PTF Cover Letter

Each PTF consists of program modules and a text file that describes both the problem fix and any activation instructions to affect the installation of the PTF. The cover letter also documents co-requisite PTFs, prerequisite PTFs, superseded PTFs, and PTFs that are distributed together.

RETAIN

RETAIN is the worldwide database for IBM problem management and the central repository of PTF files. You access this database with any and all PTF orders, no matter which ordering method is used.

Preventive Service Planning (PSP)

Preventive service planning (PSP) is a collection of information regarding PTFs applicable to AS/400 hardware and software problems. PSP information should be investigated on a regular basis by using ECS or the Internet.

High Impact or Pervasive (HIPER) PTF

High impact or pervasive (HIPER) PTFs correct serious system problems. These problems usually relate to data integrity, system, and communication processing problems that the IBM AS/400 engineers suspect all or almost all customers experience. These PTFs should be proactively applied. You can find them by reviewing the PSP package or using the ALERT/400 service offering.

Cumulative (CUM) PTF package

Cumulative (CUM) PTF packages are a regularly released set of PTFs that contain all the HIPER PTFs and selected non-HIPER PTFs. The selection criteria changes over time, but generally the PTFs that have had a certain number of download through ECS are selected for the next CUM package.

Electronic Customer Support (ECS)

Electronic customer support (ECS) is an integrated set of functions designed to help service and support the AS/400 system. ECS provides:

1. Hardware & Software Problem Analysis,reporting and Management
2. Copy screen image
3. Question & Answer Support
4. IBM Technical and product information access

Immediate versus Delayed PTF

Some program modules cannot be replaced while in use. Immediate PTFs are those that can be activated while the system is up and performing normal work, where delayed PTFs are activated during a normal IPL. Delayed PTFs can be loaded in groups during a single apply function. Some immediate PTFs do not require an IPL but do require that the product they affect is not in use. Some require a restart of the IOP or a vary off and on of a network description.

A-side and B-side of Licensed Internal Code (LIC)

On the AS/400 system there are two copies of Licensed Internal Code (LIC) known as the A-side and B-side. When a LIC PTF is temporarily installed, it is only installed on the B-side. When a LIC PTF is applied permanently, it is applied to both the A-side and B-side copies of the LIC. If all the LIC PTFs are applied permanently, the system can only be IPLed on the A-side.

Note: Most AS/400 systems should use the B-side copy of the LIC unless otherwise directed by IBM support representatives.

Temporary versus Permanent PTF

When a PTF is temporarily applied, the original program module is renamed and the new module replaces the original one. If the new module proves to be defective, the original module can be reactivated simply by removing the new PTF containing the program module with the Remove PTF (RMVPTF) command. When a PTF is permanently applied, the original module is destroyed. There is no easy way to go back and use the old module. Nonetheless, there are two reasons for applying a PTF permanently:

1.  To Save Disk space
2. A New PTF require the older one to be permanently applied.

Clearing ASP without tampering Disk Protection during System Scratch

1. Note down the existing disk configuration with information of Load Source Disk.
2. IPL the system in Manual mode to launch DST Menu.
3. In DST menu, On Work with ASP configuration,select option 4 Delete ASP data.
4. A message will be prompted in bottom of screen "ASP have been marked for deletion"
5. Go back to DST Main Menu
6. Choose Option 7
7. Again choose Option 7 (Operator Panel Functions)
8. Choose Shutdown (F10 - Power off the systemv- This will change the IPL attributes and bring the server to power down)
9. Now IPL again wth IPL source as A and mode as Manual
10. System will IPL to DST screen
11. Check for disk configurations, the disks protection will remain Intact.
12. Perform IPL, Message will be prompted "system asp has been cleared which requires install of OS load the media"
13. Load the I_Base_01 CD in drive and hit enter key to install OS.
14. LIC IPL in process will be displayed on screen.
15. Mirroring Sync. will be performed.( Incase Disks have mirrored protection)
16. Directory Recovery will be displayed (This step may take 30-60 mins time)
17. Once Load next volume message in displayed, continue the installation with next volume in cd drive)

Moving System i Boxes

For any number of reasons, you may sometime have to move a System i, iSeries, or AS/400 from one physical location to another. The move may be caused by a company sale or spin-off, or you may have a high availability machine that needs to be hosted off site. Whatever the reason, this week I'll present a practical checklist of items to address when moving a System i box.

Checklist is short and simple. It can be divided into the following three categories that cover the majority of moving issues that you'll run into:

1. Physically moving the box--What's needed to physically move the box out of your computer room and into its new home

2. Internal changes--What changes need to occur inside the System i box that you are moving

3. Changes outside of the box--What configuration changes need to be made to peripherals and other items that are physically and logically attached to your System i

Once these items are considered, you can be fairly confident that you've prepared the box for a successful move and residency in its new home. For the remainder of this article, a detailed breakdown on each of these items has been listed below.

Step 1: Physically Moving the Box

Moving the box can be fairly expensive but your best bet is to contract out with IBM to perform the move. If IBM moves your box, they will detach the cables, contract with the moving company to physically move the box, pack up the system, reassemble the box at the new location, and make sure that it's still working. In addition, you can contract with IBM to insure the box and to be responsible for any mishaps that may occur during the move.

If you do find someone else to move the machine or you decide to move it yourself, there could be problems if the machine doesn't work when it gets to the new location. It also may be difficult to find someone with the expertise to move your machine.

Step 2: Internal Changes

This part of the checklist deals with any possible configuration changes that you'll have to make in order to move the System i to a new location. These changes include the following critical items:

• Changing the IP address on the box--If you're moving the box to a different location that resides on a different subnet, you'll probably need to change or create a new IP address for the system. If necessary, retrieve the new address from your system administrator and add another IP interface to your communications line.

On the green screen, you can add another interface by entering the "Configure TCP/IP" menu (GO CFGTCP), and selecting option 1, "Work with TCP/IP Interfaces". On the "Work with Interfaces" screen, enter "option 5=Display" in front of the existing IP interface that you want to copy as the basis for your new interface. Print out all the options contained under that interface. Then go back to the "Work with TCP/IP Interfaces" screen, enter "option 1=Add", and create a new interface by using the machine's new IP address and the parameters that were in force for the old interface. Make sure that you set the autostart parameter (AUTOSTART) for the new interface to *NO before the move, and then reset the parameter to *YES after the move (AUTOSTART tells i5/OS whether or not to start the interface when starting the system). For the existing interface that you are changing, go into the interface description and make sure that the AUTOSTART parameter is set to *YES before the move, and then reset it to *NO after the move. By doing this, you can automatically start your old interface while the machine is in its old location and then activate the new interface after the machine moves to its new location.

If you want to add the new interface and change the existing interface under iSeries Navigator (OpsNav), right-click on the Network→TCP/IP Configuration→IPv4→Interfaces node under your server. To add a new interface, select New Interface→Local Area Network off the pop-up menu that appears. This will bring up the "New IPv4 Interface" wizard, which will guide you through the ins and outs of creating a new IP interface.

To change the "Start interface when TCP/IP is started" parameter for an existing interface (the equivalent of the AUTOSTART parameter on the green screen), locate the interface in the right-hand pane that appears when you select Network→TCP/IP Configuration→IPv4→Interfaces in OpsNav. Right-click on the interface and select "Properties" from the pop-up menu that appears. This will bring up the "Interface- Properties" screen for that interface. You can find the "Start Interface when TCP/IP is started" check box under the "Advanced" tab on this screen.

• Change the DNS setting for your System i, if necessary--If this server will reside on a subnet where it needs to use different DNS servers than it used on its old subnet, be sure to change those DNS IP addresses through the green screen or through OpsNav. You can find and change your System i's DNS setting by entering the "Change TCP/IP Domain" command (CHGTCPDMN). These settings can be changed in OpsNav by right-clicking on the Network→TCP/IP Configuration node under your server and selecting "Properties" on the pop-up menu.

Step 3: Changes outside the Box

Before you move the box, you'll need to consider what peripheral items the system needs in order to keep functioning at its current levels. These items may include the following.

• What media drive will the machine use for backup? If the machine is currently sharing a tape drive, you may need to make adjustments in your backup routine and cabling so that it points to the new physical drive that will be used during backup. If the new backup drive uses different backup media type, make sure to order enough of the proper media in advance of the move.

• What cables will the machine use for connectivity? When reconnecting the machine after moving, will you be using the same cables that were connected to the machine in its old location? You may or may not be able to use all the cables for reconnection. Some of the existing cables may be too long for the new location or the cables may be difficult to remove from the current setup. You may discover that it is easier to buy new cables for running the System i at its new location, rather than to try and salvage the existing cables. Make sure you have enough media cables (fiber optic or SCSI), Ethernet cables, phone line cables, and any other cables to completely reassemble the machine after its move.

• Does the existing machine have an entry in the current or new environment's DNS servers? If an external DNS server entry needs to be modified to point to the server's new IP address, make the modification as soon as possible after beginning to move your System i. You should quickly perform this function because DNS entry changes may take a while to ripple through your system, and if a companion server relies on DNS to access your System i, the server may have trouble reaching the box at its new location until the changes are complete.

• What non-System i servers are communicating with your box? If there are Windows, Linux, or other non-System i servers collaborating with your box at the moved location, make sure that they are using new DNS entries to reach your box at its new IP address after the move. If the server's IP address is hard-coded into the collaborating server's application software, make sure that you change the IP address in the software.

• What other System i, iSeries, or AS/400 servers are communicating with the moved server? After the server moves, make sure that any companion i5/OS or OS/400 servers are still able to reach the moved box at its new IP address. Check the following places on your System i-based servers to locate and change any references to the moved server's old IP address:

1. The server's host table--On the green screen, check out and change any of the server's host table entries by using option 10 off the GO CFGTCP menu, "Work with TCP/IP Host Table Entries". Delete and re-enter any entries that refer to the old IP address. To use OpsNav to modify or add entries to the Host Table, right-click on Network→TCP/IP Configuration under your server and select Host Table off the pop-up menu that appears.

2. The Work with Relational Database Entries Command (WRKRDBDIRE)--This command shows all the entries in the relational database directory for an i5/OS or OS/400 server. If any entry is pointing to the old Ethernet address of your moved machine, change the entry to point to the new IP address.

3. Any devices or remote output queues that point to the old IP address--Check to make sure that there aren't any printers or devices that are using the old IP address. Otherwise, these devices will stop working after the move.

• Will you need security? If you're moving your System i to an external hosting center, the vendor may require you to implement cabinet security on your box. If required, you would need to put locking doors on the cabinet frame and you may also elect to put in locking slide bars on the side cabinet walls to prevent unauthorized entry from that direction. Depending on who you contract with, installing locking doors may be a system requirement for running the box at the new location.

IBM AS/400, iSeries & System i - Commercials

 IBM System i advertisement (No Stress)

IBM Server iSeries

It's IBM

History, CPU in AS/400, iSeries, i5 & Models

History

The IBM System i, then known as the AS/400, was the continuation of the System/38 database machine architecture (announced by IBM in October 1978 and delivered in August 1979). The AS/400 removed capability-based addressing.[3]  The AS/400 added source compatibility with the System/36 combining the two primary computers manufactured by the IBM Rochester plant. The System/36 was IBM's most successful mini-computer but the architecture had reached its limit. The first AS/400 systems (known by the development code names Silverlake and Olympic) were delivered in 1988, and the product line has been refreshed continually since then. The programmers who worked on OS/400, the operating system of the AS/400, did not have a UNIX background. Dr Frank Soltis, the chief architect, says that this is the main difference between this and any other operating system.
The AS/400 was one of the first general-purpose computer systems to attain a C2 security rating from the NSA (Gould UTX/C2, a UNIX-based system was branded in 1986[4]), and in 1995 was extended to employ a 64-bit processor and operating system.
In 2000 IBM renamed the AS/400 to iSeries, as part of its e-Server branding initiative. The product line was further extended in 2004 with the introduction of the i5 servers, the first to use the IBM POWER5 processor. The architecture of the system allows for future implementation of 128-bit processors when they become available. Existing applications can use the new hardware without modification.

Hardware

The AS/400 was originally based on a custom IBM CISC CPU which used a CPU architecture known as Internal Micro Programmed Interface (IMPI) and an instruction set similar to the IBM 370. It was later migrated to a POWER-based RISC CPU family eventually known as RS64.

CPU in AS/400, iSeries, i5

The System i5 uses IBM POWER CPUs. These CPUs are developed and manufactured by IBM. The POWER 4/5/5+ chips contain two cores. There are Multi-Chip Modules (MCM) available. They have 2 CPUs (4 cores) or 4 CPUs (8 cores) in one MCM.

Models : AS/400, iSeries, i5

IBM System i

The IBM System/38 was introduced in July 1980 as a minicomputer for general business and departmental use. It was replaced by the AS/400 midrange computer in 1987 and later re branded as the eServer iSeries in 2000. It was renamed in 2006 as the IBM System i until April 2008 when it was replaced by the IBM Power Systems line. It uses an object-based operating system called IBM iOS. The operating system has undergone name changes in accordance with the re-branding of the IBM server line. Initially, it was called OS/400 (following the name schema that gave birth to OS/2 and OS/390). Later on became known as i5/OS in line with the introduction of the eServer i5 servers featuring POWER5 processors. Finally, it was called just IBM i coinciding with the 6.1 release. Features include a DBMS (DB2/400), a menu-driven interface, multi-user support, dumb terminal support (IBM 5250), printers, as well as security, communications and web-based applications, which could be executed either inside the (optional) IBM WebSphere application server or in PHP/MySQL[1] using a native port of the Apache web server. While in Unix-like systems “everything is a file”, on the System i everything is an object, with built-in persistence and garbage collection. It also offers Unix-like file directories using the Integrated File System.[2] Java compatibility is implemented through a native port of the Java virtual machine.

Features
The IBM System i platform extended the System/38 architecture of an object-based system with an integrated DB2 relational database. Equally important were the virtual machine and single-level storage concepts which established the platform as an advanced business computer.
Software
The IBM System i includes an extensive library-based operating system, i5/OS, and is also capable of supporting multiple instances of AIX, Linux, Lotus Domino, Microsoft Windows 2000 and Windows Server 2003. While i5/OS, AIX, Linux and Lotus Domino are supported on the POWER processors, Windows is supported with either single-processor internal blade servers (IXS) or externally-linked multiple-processor servers (IXA and iSCSI). iSCSI also provides support for attachment of IBM Bladecenters. Windows, Linux, and VMWare ESX(VI3) are supported on iSCSI attached servers.
LPAR (Logical Partitioning), a feature introduced from IBM's mainframe computers, facilitates running multiple operating systems simultaneously on one IBM System i unit. A system configured with LPAR can run various operating systems on separate partitions while ensuring that one OS cannot run over the memory or resources of another. Each LPAR is given a portion of system resources (memory, hard disk space, and CPU time) via a system of weights that determines where unused resources are allocated at any given time. The operating systems supported (and commonly used) under the LPAR scheme are i5/OS, AIX, and Linux.
Other features include an integrated DB2 database management system, a menu-driven interface, multi-user support, non-programmable terminals (IBM 5250) and printers, security, communications, client-server and web-based applications. Much of the software necessary to run the IBM System i is included and integrated into the base operating system.

The IBM System i also supports common client-server-based technologies such as ODBC and JDBC for accessing its database from client software such as Java, Microsoft .NET languages and others.The IBM System i also provides an environment for AIX applications to run natively on i5/OS without the need for an AIX LPAR. AIX programs are binary compatible with OS/400 when using OS/400's PASE (Portable Applications System Environment). PASE is essentially "an operating system within an operating system", supporting the most recent stable version of AIX. Binaries need to be re-compiled on the AIX system, with 16-byte (quadword) pointer alignment enabled. Once the program is compiled with this option, it can be executed under the PASE Korn Shell.