Should QINTER subsystem be used to submit critical batch jobs?

In order to ensure critical batch jobs are not held up, some administrator, programmer and system operator submit batch jobs to QINTER subsystem. Now, the question is should we do this and is this the best solution to ensure critical batch jobs are not held up.

From system point of view, QINTER treats the batch job as any other interactive job and runs them without any concern. All the job scheduler including System native job scheduler, AJS and ROBOT allows to change the job queue of any job. You can change the job queue to any job queue including QINTER job queue. Once, the job queue has been changed to QINTER job queue, the job gets submitted to QINTER subsystem and runs like any other interactive job.

However, batch jobs can affect the interactive jobs by hampering their performance. Once, batch job is run in QINTER, it takes up memory pool that is assigned for interactive jobs. It now used *INTERACT memory pool.

If a batch job is building a large file, then it will take up a large piece of memory from *INTERACT memory pool and there by can cause slow down of other interactive jobs.Usually, batch jobs have run priority of 50 and interactive jobs run priority of 20. This is because, interactive jobs should get the result faster and as you know the lesser the run priority number the higher the priority the system assigns.

So, if a batch job is processed in QINTER, by default the run priority would be 20. So, if a batch job running in QINTER is performing higher CPU functions then it can choke the entire system.

Instead, we can achieve better system performance and run the batch job in a different job queue that feeds to QBATCH subsystem. When you as an administrator see the job waiting for other batch jobs to process before, it you can immediately change the job queue and  let this job feed to QBATCH before other jobs.

Now, lets create a job queue named ABATCH in QBATCH subsystem. The QBATCH subsystem has QBATCH job queue associated with it.

CRTJOBQ JOBQ(QGPL/ABATCH) TEXT('Batch job queue for critical batch jobs)

ADDJOBQE SBSD(QBATCH) JOBQ(QGPL/ABATCH) MAXACT(*NOMAX) SEQNBR(xx)

Note :- The xx in SEQNBR is the next sequence number available and must be unique. You can check this by

DSPSBSD SBSD(QBATCH)

Take option 6 for job queue entries. 

Subsystem description:   QBATCH         Status:   ACTIVE                     
                                                                             
 Seq  Job                       Max   ---------Max by Priority----------     
 Nbr  Queue       Library     Active   1   2   3   4   5   6   7   8   9     
  10  QBATCH      QGPL             1   *   *   *   *   *   *   *   *   *     
  20  QS36EVOKE   QGPL        *NOMAX   *   *   *   *   *   *   *   *   *     
  50  QTXTSRCH    QGPL        *NOMAX   *   *   *   *   *   *   *   *   *     

Now, CRTJOBQ command creates the job queue physically and ADDJOBQE add this job queue to the subsystem logically.

Now, the MAXACT set to *NOMAX allows all the jobs that are feed into this job queue to simultaneously be run in QBATCH subsystem. 

This ensures better performance and enables to run all critical batch jobs.

Deleting Authorization list

In order to delete an Authorization list that has objects that are secured and users which are secured by this Authorization list, you need to follow the below procedure.

First, you have to revoke authority on the objects that are secured by this Authorization list. If you remember the previous topic on Authorization list where, I had created an Authorization list called JOBSC. I had secured one object CRTAUTL command using this Authorization list. And this Authorization list ensured HSDRB user profile had *EXCLUDE authority and *PUBLIC had *USE authority. 

Now, lets delete this Authorization list.

If you press 4 next to this authorization list and press enter. It would not delete this Authorization list, since there is a Object that is secured using this Authorization list. So, at first we need to revoke Authority on this Object i.e. CRTAUTL command.

The command would be  

RVKOBJAUT OBJ(QSYS/CRTAUTL) OBJTYPE(*CMD) AUTL(JOBSC)  

The important parameters are OBJECT , OBJECT TYPE and AUTHORIZATION LIST.

You can also specify USER, but if you use USER and AUTL parameter together, it will not be processed by AS400. Similarly, parameter AUT and AUTL can not be used simultaneously.

After, the authority is revoked. You can check using option 8 next to the Authorization list ( Display objects in list). The screen would be blank in this case as I used only one object. You have to follow this until all the objects secured by the Authorization list are revoked.  When you do not see any objects in the list. You can proceed further.

Now delete the Authorization list.

You can use DLTAUTL AUTL(JOBSC) command or press option 4 next to the Authorization list to delete the same. 

Subsystem

Now lets proceed further with AS400 Subsystem. What is a Subsystem?

The subsystem is where work is processed on the system. 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.

All jobs, with the exception of system jobs, run within subsystems. Each subsystem can run unique operations. For instance, one subsystem may be set up to handle only interactive jobs, while another subsystem handles only batch jobs. Subsystems can also be designed to handle many types of work. The system allows you to decide the number of subsystems and what types of work each subsystem will handle.

The run-time characteristics of a subsystem are defined in an object called a subsystem description. For example, if you want to permanently change the amount of work (number of jobs) coming from a job queue into a subsystem you only need to change the job queue entry in the subsystem description.

What is Controlling Subsystem?

The controlling subsystem is the interactive subsystem that starts automatically when the system starts, and it is the subsystem through which the system operator controls the system via the system console. It is identified in the Controlling subsystem (QCTLSBSD) system value.

IBM supplies two complete controlling subsystem descriptions: QBASE (the default controlling subsystem) and QCTL. Only one controlling subsystem can be active on the system at any time.

It is required to bring the system to restricted state to perform certain tasks. The system must be in this condition for commands such as Save System (SAVSYS) or Reclaim Storage (RCLSTG) to run. This is required before IPL and applying patch or PTF's. Some programs for diagnosing equipment problems also require the system to be in a restricted condition. To end this condition, you must start the controlling subsystem again. The Controlling subsystem would start the system up as normal.

Note: There is also a batch restricted state in which one batch job can be active.
When all of the subsystems, including the controlling subsystem are ended, a restricted condition is created. You can end each subsystem individually or you can use the ENDSBS SBS(*ALL) OPTION(*IMMED).

Important: Before, you end the subsyetm, it is good to ensure your own job is running under QCTL. This can be done by TRFJOB QCTL. When you are logged in using console, it automatically starts your job under QCTL subsystem. The system cannot reach the restricted state until there is only one job remaining in the controlling subsystem. Sometimes it may appear as though there is a single job remaining, but the system does not go into the restricted state. In this case you need to verify that there are no suspended system request jobs, suspended group jobs, or disconnected jobs on the remaining active display. Use the Work with Active Jobs (WRKACTJOB) command and press prompt F14=Include to display any suspended or disconnected jobs. If these jobs exist, you need to end them in order for the system to reach the restricted state. The ENDSYS and ENDSBS functions will send a CPI091C information message to the command issuer when this condition is detected.

What is Subsystem Description?

The run-time characteristics of a subsystem are defined in an object called a subsystem description. For example, if you want to permanently change the amount of work (number of jobs) coming from a job queue into a subsystem you only need to change the job queue entry in the subsystem description.

A subsystem description is a system object that contains information defining the characteristics of an operating environment controlled by the system. The system-recognized identifier for the object type is *SBSD. A subsystem description defines how, where, and how much work enters a subsystem, and which resources the subsystem uses to perform the work. An active subsystem takes on the simple name of the subsystem description.

Like a set of detailed blueprints, each subsystem description is unique, containing the specific characteristics that describe the subsystem. The description includes 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.

You can use a subsystem description supplied with your system (with or without making changes to it), or you can create your own.

The Subsystem description has normal parameters. The two important parameters while creating a new subsystem are Work entries and Routing entries.

Work entries identify the sources where jobs can enter a subsystem. Specific types of work entries are used for different types of jobs. Work entries are part of the subsystem 

description.

The routing entry identifies the main storage subsystem pool to use, the controlling program to run (typically the system-supplied program QCMD), and additional run-time information (stored in the class object). Routing entries are stored in the AS400 subsystem description.

Deleting User Profile's in AS400

I am conclude User Profile topic with this topic until, I come across something that is interesting and important piece of  fact that I am missing to describe.

Deleting user profile's in AS400 is simple but it needs to have a look at many important piece of objects and items before we actually delete a user profile.

Why we need to analyze before deleting a User Profile?

An user can create objects and have access to many files and objects that could be affected the moment we decide to delete an user profile.

What all things we need to consider before deleting User Profile?

As per industry best practices, it is required to meet the audit compliance with SOX (Sarbanese -Oxley) and HIPAA(Health Insurance Portability and Accountability Act). 

If your company follows these standard and needs to meet audit compliance for SOX and HIPAA, then you might need to have proof of when the user left the organization and when the request was raised to remove the user profile. You might need to maintain a document based on the organizational practice. 

Sometimes, you might be required to immediately disable the User Profile after the person left the organization. This can be done by CHGUSRPRF.

CHGUSRPRF USRPRF(user_name) STATUS(*DISABLED)

Before, deleting a user profile it is needed to transfer all the objects that the user profile owns to another user. This is so because AS400 OS will not allow you to delete an User Profile if it has objects that it owns.

You can identify whom to assign the objects after checking with the group to whom this user belongs and then transfer all the objects that is owned by the user profile.

To identify the objects that the user profile owns, you can do

WRKOBJOWN USRPRF(user_name)

This can also be done by i Series - navigator.

You also need to identify how critical the user profile is, before you think of deleting it. There could be many user profiles which can not be deleted at all. Some basic example would be of the programmer or the programming manager who have designed almost all the programs and have setup all the interfaces. The administrator who have setup most of the batch jobs and the operator or user who have been for so long that it is difficult to figure out, which all jobs, objects and interfaces will be affected when the profile is deleted.

Such, user profile just reside in the system forever. 

If the user profile is not critical then get approval to delete the user profile from the departments required and  remember to document it before you proceed to delete the user profile. 

Deleting user profile :- 

WRKUSRPRF USRPRF(user_name)

Option 4 next to the user profile to delete the same. 

If the user profile will not delete that means there must be some objects that the User profile owns. Now, to change the ownership of the objects, use below command.

WRKUSRPRF USRPRF(user_name)

Take  option 12 to find the objects owned.

Take option 9 to change the owner.

Or you could also change the ownership of objects owned at the time of deletion by using the below command.

WRKUSRPRF USRPRF(user_name)

Take option 4 and prompt ( f4)

owned objects value => *CHGOWN

user profile name is *CHGOWN => OBJOWNER (this user will own the objects after deleting the user profile)

This can also be done by iSeries- navigator .Select the user profile and right click and select delete user profile. The below screen will appear where you can change the ownership of objects owned and then delete the user.

AS400 Group Profiles and some points to keep in mind

OS/400 group profiles are a boon to system administrators as they allow them to centralize object authority administration for several users in one place. A Group profile can be created in similar way as an user profile. While creating other user profile that are member of this group profile, mention the group profile name in group profile parameter(*GRPPRF).

Group profiles also have their downside and needs proper administration. Here are few industry best practices that we need to follow to avoid any loop-hole that can be a threat in security of the system.

1- Group profiles should not be allowed to sign-on to the system :- When a user is a member of a particular Group profile it inherits all the level of access that the Group profile has.  Since, group profile provides authority access to all the member user profiles, it has object authority that is fixed for all the member profiles.By changing authority at group level it affects all the member profiles.

 According industry best practices, it is not advisable to provide any user with group profile access. Therefore, the password of Group profile is set to *NONE. This restricts users to access the system using group profile.

CHGUSRPRF USRPRF(group profile name) PASSWORD(*NONE)

If you have a large number of group profiles in your system and you want to check which of them have any password, then use the below command.

DSPAUTUSR SEQ(*GRPPRF) OUTPUT(*PRINT)

2- Group Profiles should not own production objects :- Object owners are super users for all the objects they own. They can change, delete and move objects. Therefore, Group profiles should not own production objects as that would give access to all the member profiles.

This problem is compounded when software package specifies that all authorized users must belong to the group profile that owns the application objects.

3- Group profile should not have ALLOBJ authority :- User profiles like QSECOFR must not be a group profile. Administration profiles that have *ALLOBJ authority when made a group profile will give *ALLOBJ authority to all its users thus enabling them to do anything with all the objects. And this itself violets the purpose of having Group profile to secure objects.

4- Supplemental group profiles :- One user can have more than one group profile. While creating user profile you can specify one name in *GRPPRF parameter and you can specify upto 15 other group profiles in supplemental group profile parameter. *SGRPPRF. This is required when one person can have access to more than one department and would need to have different object authority based on different departments.

How to remove member user profiles from a group profile?

At times, you would be required to remove the group profile from many member user profiles. To perform this when the number of user profiles is more, it is easier to do via Ops navigator than modifying each one through emulator.

Go to iSeries Navigator and expand User ->Group->Group node

Now expand the group profile and highlight the users for which you want to remove the group profile name. Right click and select remove group profile.

Delete Group Profile :-

If you want to delete a group profile , then first you have to remove all the user profiles that are member of this group profile and also check if the group profile owns any object. Once these are cleared you can remove the group profile from the system via 5250 or Ops Navigator.

Adding user profiles to authorization list

After, you create an user profile in AS400, it is required for Admin to ensure this user profile has been added to relevant authorization list.

What is Authorization list and how is it useful?
An Authorization list is a special system level object that resides in QSYS library with object type *AUTL. It simply defines user authority for objects belong to the list. Instead of providing individual private authority to an object when it is created, it is better to associate an object with appropriate Authorization list. The list will control individual and *PUBLIC authority of the object in the list.

It is beneficial in following way:-

1- Individual size of user profile is kept much lower by using Authorization list.
2- System performance is improved when running SAVSYS backup and saving security information by using SAVSECDTA.
3- Security changes can be made to object when the list are open and active. Only objects with private authority needs to be used when not in use.

How to create Authorization list?

Use command CRTAUTL  to create a new Authorization list.
Set *PUBLIC authority level using AUT parameter.

Once this is created you can work on it using EDTAUTL command.

You can grant object authority by GRTOBJAUT command or by adding objects to the list by ADDAUTLE.

Steps to create authorization list and add users is listed below.

1- Create authorization list, example

CRTAUTL AUTL(JOBSC) TEXT('job scheduler job')

When you do this the *PUBLIC authority will get the authority that you have selected, I have selected *CHANGE

Your ID will be added to this authorization list as you are the owner.


2- Add the objects that you want to secure using this AUTL.

The objects that you want to secure needs to be added to this AUTL. This can be done by EDTAUTL command. Here I want to secure CRTAUTL command access. So, I did the following

You can check the objects by taking F15 after entering the AUTL list.

3- Add other users that you want to secure via this authorization list.

ADDAUTLE command would do this

You can check the users added to this AUTL by taking option 5 next to the AUTL.

You can delete the authorization list by DLTAUTL command.

Now lets explore more on User profile security and audit

There are many common scenario's that needs to be taken care of while auditing and ensuring security of the system. Now, lets explore some of the basic one's.

1- Finding user profile's with default password :- While auditing IBM i, the common thing that the auditor would like to check is the list of user profile's that have default password. 

What is default password? When the user profile name and password are same, it is called default password. As you already know, the system defaults to *USRPRF while creating a new user profile and if unless changed would generate the user profile with same password as the user id, it is called default password.

As a responsible administrator, it is required to check periodically if any user profile has default password and the same report needs to be provided while auditing. So, how to generate a report with user profile's that have default password .

AS400 command ANZDFTPWD would do that.

Command is

ANZDFTPWD ACTION(*NONE)

This would generate a spool file QPSECPWD for the user. You can use iSeries navigator to download this report. 

If you want to disable the user profiles with default password , use the following

ANZDFTPWD ACTION(*DISABLE)

You can also expire the password of all the user profiles having default password, 

ANZDFTPWD ACTION(*PWDEXP)

ANZDFTPWD is that it produces a physical file containing all the information from its QPSECPWD listing. Whenever you run ANZDFTPWD, a complete list of all user profiles with default passwords is copied in the QASECPWD file in the QUSRSYS library. This file can be read in other programs or in an SQL query to gather more information.

2-  Password Configuration details :- Sometimes it would be required to check and provide the password configuration parameters for auditing. You can easily achieve this by iSeries Navigator.

Expand the system name under Management Central. Expand the security tab. Click on Password policy.

You can copy these details in General tab, validation tab and Expiration tab and provide it to auditors.

3- Querying User Profile to extract specific details :-  As a system administrator, it would be required to periodically check for users who no longer use the system for more than 6 months. Sometimes, to provide a list of users having a specific special authority. 

In order to do this, first create a physical file of the user profile in your system.  This can be done by

DSPUSRPRF USRPRF(*ALL) TYPE(*BASIC) OUTPUT(*OUTFILE) 

OUTFILE(LIBRARY NAME/FILE NAME) 

Now, this file is the physical file upon which you can query according to the requirement and provide the desired output. 

For generating report of all admin user profile,

SELECT  UPUPRF,  UPUSCL,  UPSPAU,  UPGRPF,  UPTEXT,  UPSTAT,  UPPSOD  FROM LIBNAME.FILENAME DSPUSRPRF  WHERE UPUSCL = '*SECADM' OR UPUSCL = '*SECOFR' OR UPUSCL = '*SYSOPR'   ORDER BY  2 

For user profile that have not used for last 6 months,

SELECT  UPUPRF,  UPGRPF,  UPTEXT,  UPSTAT,  UPPSOD,  UPPWCD,  UPPWEX,  UPLTCP,  UPSPAU,  UPOTQU  FROM LIBNAME.FILENAME SOXUSRPRF  WHERE UPPSOD < 'MMDDYYYY' AND UPSTAT <> '*ENABLED'   ORDER BY  2 

Run this statement to get all user profiles with a user class equal to *SECOFR or *PGMR.

SELECT * FROM LIBNAME.FILENAME WHERE UPUSCL = '*SECOFR' OR UPUSCL = '*PGMR'

To retrieve all user profile records that contain *ALLOBJ or *SECADM authority 
in their profiles, run this SQL statement.
SELECT * FROM LIB/FILENAME WHERE              
UPSPAU LIKE '%ALLOBJ%' OR UPSPAU LIKE '%SECADM%'





To capture all the user records that have command line authority on the system, 
run this SQL statement.
SELECT * FROM LIB/FILENAME WHERE UPLTCP = '*NO'



The hardest part is to determine the field name in this spool file. For that you can use


DSPFFD FILE(LIB/FILENAME) OUTPUT(*PRINT)



Since, these files could be way too big, it is better to use Help systems's  Showcase query as this enables the admin to generate the query output in excel sheet.  Showcase uses normal SQL to query the files.


3- Authority for running commands :-  The Auditors would also like to see the authority to run specific commands, for example SBMJOB, CHGJOB and ADDJOBSCDE command allows the user to make changes to jobs and change the job scheduler. To retrieve the authority information to run these commands, use the following.


DSPOBJAUTH OBJ(lib name/obj name) Objtype(*CMD)


I will discuss the rest security and auditing related parameters in my next post.


Thank you.

Lets get started with User profile in AS400 - Create AS400 User profile(CRTUSRPRF)

Since, we need to have a user profile to get access to AS400, lets now discuss AS400 user profile and all its feature.

Create AS400 User profile :-

The administrator with *SECADM, *CHANGE and *USE  authority has rights to create a new AS400 user profile.

User profiles can be created through two interfaces. You can use the green-screen Create User Profile command (CRTUSRPRF) or you can use iSeries Operations Navigator's (OpsNav) user profile function. For this, I'll use the traditional CRTUSRPRF interface but all of these options are also configurable through the OpsNav interface.

This is how the screen would look when you type in the command CRTUSRPRF and press prompt,

Parameters that are essential :-

1- User profile name :- Provide user profile name this takes up 10 character long user name.

2- User Password :- This is by default set to same as the user profile and can be set to a different one.

3- Set Password to Expire :- This enables Admin to compel the user to change the password after first log in when set to *YES.

4- User Class :- The user class you choose will determine whether the user has normal system authorities or whether they can perform additional tasks normally reserved for higher-level users. Your choices for user class are the following:

• User (*USER) - An ordinary user with no special system authorities.
• System Operator (*SYSOPR) - The user has the ability to perform system backups (*SAVSYS authority) and control system jobs (*JOBCTL authority).
• Programmer - The user has no special system authorities beyond that of a normal user.
• Security Administrator (*SECADM) - The user can create, change, or delete other user profiles.
• Security (*SECOFR) - The user possesses all system authorities, and he can perform any task on the system. But beware. Many shops are too loose with *SECOFR authority. In general, it should be reserved for one or two trusted people in the IT department and that's it. 

5- Intial Program to Call, Intial Menu - Both of these parameters determine which program will be called when the user log in. By providing different INLPGM & INLMNU options users could be restricted to enter the Main menu.

6- Limit Capability :- LMTCPB parameter tells the OS400 two things. First, it tells the OS400, if the user can make changes to ITLPGM, ITLMNU and current library values. Secondly, it says the OS400 if the user has access to command line.

When it is set to *NO, the user can make changes to ITLPGM, ITLMNU , current library and ATTN key values and also it can use the command line to run AS400 commands.

When it is set to *PARTIAL, the USER cannot make any changes to ITLPGM, ITLMNU, current library and ATTN key value but it has access to command line and can run AS400 commands.

When it is set to *YES, the user has neither access to make any changes to ITLPGM, ITLMNU and current library nor it can access command line.

These three parameters ITLPGM, ITLMNU and LMTCPB have ability to restrict users. For example, for the server users who do not require to access the green screen 5250 emulator, can have ITLPGM as *NONE, ITLMNU as *SIGNOFF and LMTCPB as *YES. They can still access AS400 from other server which are connected to AS400. However, if the same user tries to access the AS400 from 5250 emulator, it will immediately bring the user to signoff screen thus restricting access to AS400 and command line.

7- Special Authorities :- SPCAUT - Special authorities work hand-in-hand with the profile's user class. User profiles with a user class of System Operator (*SYSOPR) are automatically assigned the special authority to save and restore system objects and to control system jobs. Users who are designated as Security Officers (*SECOFR) can perform any and all restricted functions on the system. For all other users, you can assign one or more of the following special authorities to a user profile: 

• All object (*ALLOBJ) authority allows the user to access any system resource, regardless of whether or not they are explicitly authorized to use that object. Because *ALLOBJ basically gives users to update any item on the system, this special authority should be given out only on a need-to-have basis.
• Audit (*AUDIT) allows the user to perform all auditing functions on the system, including turning on and turning off auditing.
• Job Control (*JOBCTL) allows the user to perform any function (change, hold, delete, release, etc) on any jobs that are currently running on the system or for jobs that are sitting in a system job queue. In addition, the user has the ability to start OS/400 writers and remote output queues, and to stop active subsystems. Like *ALLOBJ, you may want to restrict access to *JOBCTL authority.
• Save system (*SAVSYS) authority allows the user to save, restore, or free storage for all objects on the system, regardless of whether or not the user has object management authority to those objects.
• Input/output (I/O) system configuration authority (*IOSYSCFG) gives the user the ability to change system I/O configurations.
• Security Administrator authority (*SECADM) allows a user to add, change, or delete user profiles on the system. The user must be authorized to the user profile commands (CRTUSRPRF, DLTUSRPRF, and CHGUSRPRF) to use this authority. The catch here is that a security administrator user cannot assign any special authorities to another user that it does not itself already have.
• Spool control authority (*SPLCTL) allows a user to work with printers and writers.

8- Password expiration interval parameter - (PWDEXPITV) tells OS/400 how often (in days) the user should be forced to change their password. If the user has not changed his password by the end of the PWDEXPITV interval, the user profile password will automatically expire.

• Any number between 1-366 days. If password expiration is set for a user, OS/400 will not allow passwords to remain active for more than one year.
• No expiration date (*NOMAX) tells OS/400 that the password will remain active forever unless the user voluntarily changes it or the system administrator changes it.
• Use the Password Expiration Interval system value (*SYSVAL). This setting tells OS/400 to use the value for password expiration days found in the Password expiration interval system value (QPWDEXPITV). This is the default value for the PWDEXPITV parameter. If you decide to use *SYSVAL, check what value QPWDEXPITV is set to, because OS/400 sets the password expiration interval system value to a default value of *NOMAX.

Silver jubilee for iSeries

IBM - " The Big Blue" and its valuable i Series customer or IBM i shops are going to celebrate this coming Friday 21st June 2013 as the silver jubilee of i Series platform. From system 38 to AS400 to i Series and now IBM i, this is a long journey for this platform has witnessed and we would look forward to it.

In June 1988, IBM introduced the IBM Application System/400 (AS400) a new family of easy to use computers designed for small and intermediate sized companies.It had double the performance of System/38 and five times that of System/36. By the time it was first shipped, more than 2500 application were available.

AS400 was developed and produced at IBM Rochester and the project code name was "Silver lake" named after the downtown lake at Rochester. This building of IBM at Rochester has gained fame for the development of AS400 and since then it is dedicated mostly to Research and Development of AS400.

This is a time to congratulate all those who have been working with IBM i since its evolution.  This is a introduction to IBM i and would expand more on its features in up-coming posts.

Thank you.