Platform: D DB2 for Linux, UNIX, Windows
DB2 UDB for Linux, Unix, Windows
in z/Linux User Experience
John C. Lendman
DBA/Palm Beach County
School District
Session: D06
May 09, 2006 at 1:00 pm
1
z/Linux and DB2 UDB for Linux,
Unix, Windows User Experience
• Setting up Linux in z/Series LPAR
• Setting up the DB2 for Linux
• Monitoring DB2 using DB2PE
• Scripts for moving data from the
Mainframe(z/OS)
• Testing the Data Warehouse Applications
2
2
DB2 UDB for Linux, Unix, Windows in z/Linux User
Experience
Session: D6
John C. Lendman
Palm Beach County School District
Lendman@palmbeach.k12.fl.us
3
3
Session Abstract
This presentation is a Mainframe DB2 DBA's point of
view on how to set up a z/Linux system running DB2
UDB for Linux, Unix, Windows V8.1.5. It will cover
some of the issues that you have to face in order to set
up the system and copy data from DB2 UDB for z/OS.
At my shop we set this system up for a pilot for a Data
Warehouse application. We also had a dedicated
Integrated Facility for Linux (IFL) engine just for the
z/Linux LPAR of 192 MIP's. I also installed IBM's DB2
Performance Expert to monitor the overall performance
4
4
Background for Palm Beach County School District
400+ schools
187,000+ students in Palm Beach County Schools
11,000+ Adult Education in Palm Beach County
20,000+ employees in Palm Beach County school district
2.4 Billion Dollar a year business.
Fortune 500 company
Z800 with 259 MIPS and 8 GB memory, 4 LPARS
Total DASD farm 3 TB
5
We are the third largest School District in the state of Florida.
We are the 11th largest School District in the United States.
Our Z800 machine is small in comparison to the industry. We have four LPARS,
where one is the production machine, one is a copy of production that we use for
DR testing, one is a system test area for the system programmers and the last one is
the z/Linux system.
Most of our DASD is sharable between LPARS.
5
My Background;
DBA on mainframe for 35 years. (started in IMS, move to DB2)
SAP for z/OS 6 years experience.
Worked at a few different types of industries, my job stayed the
same.
Also worked on DB2 UDB for Linux, Unix, Windows DB2 for
7 years.
6
I have been a DBA for 30+ years. I have worked mostly in the mainframe area.
Most recently I have worked on DB2 UDB for Unix.
6
Project personnel
The core personnel that worked on this project were;
One system programmer
One DBA
One system architect
No one on the project had any Linux experience.
The vendor did assist in installing Linux, but was not on site
during the pilot.
7
This project was staffed with the minimum core personnel. Respective of the people
involved in the project were very experienced in their respect areas. Many different
groups were brought in as needed. Such as:
Operations
Applications Programming
Networking
Security
7
Timing of the Project
Elapsed time for this project was 6 months.
Setup phase was 2 weeks.
Data transfer phase ran over 3 months.
Testing phase ran for 3 months.
8
Setup phase consisted of :
installing z/Linux
installing DB2 UDB for Linux
creating the database and tablespaces
Data transfer phase consisted of;
creating the tables on z/Linux
copy the data from the mainframe
loading the data on z/Linux
creating the indexes
running Runstats
Testing phase consisted of:
accessing the data ad hoc and with static reports
The only phase that was not run concurrently was the setup phase.
During the load phase, I reloaded the data several times for different reasons.
The testing was continuous after the first set of tables were loaded.
Also it should be noted that the three people assign to this project were not working
full time for the duration of the project. Each person would only do what was
needed.
8
Setting up Linux in z/Series LPAR
Testing IFL engine for z/Linux LPAR
Assign the right resources to the LPAR
Create the Userid’s in Linux
Automate the needed parms for DB2
Add DASD
Set up the file system/mount points for DB2
Monitor Linux performance
9
As we start to look at the setting up of the z/Linux LPAR, I would like to remind
you that this was my first experience with z/Linux. As I take you though some of
these steps, some of the steps were completed by other people and I have limited
knowledge of some of these areas.
What I do hope you will be able to take away from this presentation are the scripts
that I have included in this presentation to help you move data between the
mainframe and z/Linux or any DB2 UDB for Linux, Unix, Windows.
9
Testing IFL engine for z/Linux LPAR
Sample of what was in the contract:
Trial IFL Objective:
The objective is to port the support of the School District of
Palm Beach County Data Warehouse test environment to the
z/Linux environment from its current z/Series environment.
The items to be evaluated include the functionality of the
DB2 UDB for Linux environment, its interoperability with
DB2 on z/OS and the performance delivered by the IFL on
the z800.
10
I have pasted a sample portion of the contract we had with a third party vendor to
trial the IFL engine.
Adding this engine to our LPAR and having it dedicated to z/Linux was a great
boost in performance for Linux. It would be my recommendation that if you are
going to run z/Linux in an LPAR, you would use an IFL engine.
10
Critical Success Factors:
1)- Acceptable performance.
2)- Ease of transferring data to the z/Linux system from z/OS.
3)- Functional interoperability of DB2 between DB2 UDB for Linux
and DB2 UDB for z/OS.
4)- Ease of porting applications to the virtual Linux servers.
5)- Integrity of data for the Data Warehouse on z/Linux
6)- Recoverability of the data, ease of use.
7)- Acceptable tools for managing DB2 UDB for Linux..
8)- Operability with Cognos tools (Connections).
9)- Acceptable tools to monitor DB2 for UDB for Linux.
11
As we prepared the contract for the IFL, we developed some Critical Success
Factors.
We had planned on making sure that all of these factors were tested. But as you will
see later on, we were not able to test all the factors.
11
Assigning the Right Resources to the z/Linux LPAR
DASD (we used about 100 Gbytes)
Memory (we started with 256Mbytes, ended with 1
Gbyte)
Number of CPU’s per LPAR (we used 2)
12
One of the major things that we were told by everyone we asked about z/Linux, was
to make sure you do your homework and allocate enough resources. It took some
trial and error, but we did get to the point where we felt that we had optimized
resources.
12
Creating Userids on Linux
We used YaST2, a GUI front end System
Admin Tool for Linux.
We created the userids needed in
Linux.
We created the DB2 userid’s needed.
13
The system programmer used YaST2 to create the user Ids on z/Linux.
The userids that were needed on DB2 were db2inst1 and db2admin
On z/Linux we created the userids.
13
Automating the needed parms for DB2
Created SYSCTL member to be executed when
Linux was brought up.
Contents of this member:
For SuSe Kernel 2.4.x Linux only
Must be done with Root authority
kernel.shmmax=268435456
kernel.msgmni=1024
fs.file-max=8129
kernel.sem=“250 32000 32 1024”
14
In the installation manual for the version of z/Linux we installed there was a note
about the SYSCTL member that had to be modified. The system programmer set up
a script that included the parms listed here to run every time z/Linux came up.
14
Adding DASD
We used YaST2 System Admin Tool to add
DASD.
We started with 6 Gbytes of DASD.
We added about 90 Gbytes during the
project.
15
The system programmer completed this task.
I detailed the amount of DASD that I needed and he was able, using YaST2, to
create the needed DASD pools in z/Linux. Then DB2 UDB for Linux was able to
use them to allocate the databases.
15
Set up the file system/mounts points for the DB2
After creating the File system, the next step is to create a mount point.
A mount point is an external reference, i.e. a directory where the file
system can be accessed.
We created one for the tables
We created one for the indexes
During the project we combined these into one mount point.
16
This was also completed by the system programmer.
Together we decided what directory we wanted to create and he created the “mount
points” for the tables and indexes.
16
Monitor the Linux LPAR
We used TOP, which is tool that came with our
Linux. TOP was able to see the processes that were
running.
We used IBM Tivoli Omegamon II for DB2 Version
540 to monitor the CPU.
We used the Linux command:
ps –x to view the processes that are running
17
During this process of the trial, we needed to monitor the z/Linux LPAR to see what
was happening. Since this was new to us, we were not sure what was the best way.
Top- System monitor Utility listing top CPU “TOP” is a program that will give
continual reports about the state of the system, including a list of the top CPU using
processes.
See Web site http://h30097.www3.hp.com/demos/ossc/html/top.htm
We did try a couple of different ways, but it seemed that the best way we could tell
what was happening was with the IBM Tivoli Omegamon II for DB2 Version 540
monitor. This was because of our degree of comfort and experience with this tool.
17
Example of TOP command;
18
This is an example of the “TOP” command in z/Linux. It shows the amount of CPU,
Processes that are running, as well as the processes in the order that they are
running.
18
Example of IBM Tivoli Omegamon II for DB2 Version 540
19
This is an example of the IBM Tivoli Omegamon II for DB2 Version 540 screen
that we used.
19
Example of Linux command ps –x;
20
This is an example of the z/Linux command ps -x
20
Setting up the DB2 UDB for Linux
Copying the DB2 CD to z/Linux
Run the install
Pull the latest Fixpak down and install
Bring up DB2
Change some of the DBM Config file
Create the tablespaces you are using
Define Federated Databases to the mainframe
Create the Wrappers needed
Load the data
Create the Indexes needed/runstats
21
After the z/Linux system was set up we now had to install DB2 on this z/Linux
LPAR.
Since I have done installs before on Windows, I thought they would be similar.
As it turned out, they were just about identical. The only real problem that I ran
into was a media problem. Once I had solved the problem of copying the DB2 CD
to z/Linux, this rest of the install was a normal install.
The fixpak installation was a bit troublesome, but I think this was because I had not
done this type of fixpak.
Web Site for latest fixpaks
http://www-
306.ibm.com/software/data/db2/udb/support/downloadv8_linuxs390z31bit.html
21
Copying the DB2 CD to z/Linux
We had some initial problems FTPing the CD to
z/Linux.
We used the client FTP and moved all the data
to the z/Linux LPAR.
Make sure you have the right authority, we ran
as “root”.
22
This was the one area where I found there to be some problems. Since neither the
system programmer nor I had never done this before on z/Linux, we had some
problems getting the DB2 Data on the z/Linux LPAR.
It turned out that most errors on our part were in trying to FTP the data to z/Linux.
Also we determined that we needed “root” access.
22
Run the install of DB2
The install was normal, I had to install the
JAVA subset so that I could use the GUI
front end for the install.
During the install DB2 took default values.
Authority needed to be “root”.
23
This install ran normally. The only exception was that the JAVA subset was not
installed on the z/Linux LPAR. I had to stop the install and install the JAVA subset.
I found this in the installation manual for DB2. Once I installed the JAVA subset, I
started the install over again. I used all the defaults and the install ran fine. I had to
use “root” authority.
23
Pull the latest Fixpack and Install
I logged onto IBM Support and downloaded the
Fixpak for DB2 UDB for Linux that I was running.
Not being familiar with applying fixpaks, this
was a challenge. With some help from IBM support I
was able to apply fixpak 8.1.5 to my newly
installed DB2 UDB for Linux V8.
24
This was a matter of getting familiar with the process of putting on Fixpaks. If you
have done this before then this should not be a problem for you.
Here is the WEB site for IBM support for fixpaks.
http://www306.ibm.com/software/data/db2/udb/support/downloadv8.html
24
Bring up DB2
Sign onto Linux with the DB2 ID that owns
the instance you created. In my case the ID
was db2inst1.
Do a DB2START (keyword)
25
When logging on to z/Linux you must remember to use the instance owner
ID.(db2inst1 in my case) Starting DB2 on z/Linux is the same as any other system.
25
Change some of the DBM Config file
After using DB2 for some time, I decided
that the number and size of the active logs
needed to be changed.
I updated the DB config file with a new size
for the log and I changed the number of logs.
26
After some use of DB2 I changed some of the parms for DB2. This was due to
having some problems with the log size and reading some information from the
DB2 ListServe, where these parms needed to be made bigger.
In this case I changed the log size from the default size of 3000 to 6000 and
increased the number of logs from 3 to 6. This was done with an update database
configuration command list below;
‘update dbm cfg using logfilsiz 6000 logprimary 6 logsecond 6’
DB2 ListServe is also known as simply DB2-L or the DB2 Listserve, you can
subscribe to it
by sending a message to the subscription address, LISTSERV@WWW.IDUG.ORG.
The message should read as follows: SUBSCRIBE DB2-L After issuing
this command, the list server will send you a message asking you to
confirm the subscription. Upon doing so, information will quickly begin
flowing into your e-mail box (perhaps at a much quicker rate than you
can reasonably digest). Literally, hundreds of messages may be sent to
you every week. You can post messages asking questions, or read and
answer the questions of others. DB2-L is basically a big, online user
group facilitated by e-mail.
26
Create the database/tablespaces you will be using
Here I ran the scripts that will be discussed in detail later in this
presentation.
Use the mount point that was set up earlier.
Be sure that the size you are coding fits into the amount of space
that is on that file system. The amount I coded was in
Mbytes. You code this unit on the control card. (you will see this
later)
27
In order to create the database and tablespaces that I needed I used the first of my
scripts. If you code a drop on these control statements you can run this one script as
many times as needed.
You will see the scripts later in this presentation.
27
Define Federated Databases
Create a nickname that points to the mainframe.
Update the DBM Config for Federation support.
Use this nickname to access the data to be loaded.
28
Federated capabilities:
Applications can use any supported interface (including ODBC, JDBC, or a
Web service client) to interact with the federated server. The federated
server communicates with the data sources by means of software modules
called wrappers.
The next script is to be able to use Federated databases. You must update the
Database config file to allow Federated databases. This is done with a update dbm
config command list below;
‘update dbm config using federated YES’
By using the federated databases you will create the nicknames that you can use on
the Linux LUW DB2 to access the mainframe databases. This is IBM’s way of
accessing different data sources.
You will use this nickname when you run your load scripts to retrieve data.
This nickname is stored in the SYSIBM.SYSTABLES entry
table type is 't' for "TABLES",
table type is 'v' for VIEWS,
table type is 'n' for NICKNAMES (federated usage).
28
Create Wrappers/Servers needed
Create the Wrapper/Server needed.(see script
later in presentation)
29
A wrapper for the source must be installed, and IBM's federated database
must then be told where to find this wrapper. This is done by means of a
CREATE WRAPPER statement.
Each separate source must also be identified to the system. This is done via
a CREATE SERVER statement.
After the wrapper and server have been defined, the data at the remote
source must be described in terms of the data model of the federated
middleware.
29
Cross Load the Data
Now that all the environment are set up, you can run the load script to read
data from the mainframe and load the data on z/Linux LPAR DB2 UDB for
Linux.
I had a problem where the RLF on the mainframe was not set properly for
my ID. This caused my load to fail with an error message that was not
entirely clear.
The correction was to define in RLF my user id with no limit on DB2 UDB
for z/OS.
I also had a problem where after we took away the IFL engine for z/Linux
and upgraded the mainframe to have two CPU’s, I was getting an abend that
again was not clear why. The correction was to give the z/Linux LPAR both
CPU’s in the complex..
30
Once you have established the environment, you are ready to run the “cross load”.
You will access the tables on the mainframe using the nicknames that you have
establish and loading data into the new tables on the DB2 UDB for Linux. The
scripts to do this “cross load” are included in this presentation.
I ran into two problems with the load, the first being a Resource Limit Facility error
on the large tables. The mainframe DB2 was timing me out, because the Distributed
thread was taking too long to run. Once I updated the RLF table to allow my ID
unlimited time for the read, the load worked.
The second problem I hit was after the trial of the IFL engine was over, we removed
the IFL engine. Also during this time we upgraded our Z800, adding a second
engine. I was running another load and the error message I was getting was not
clear that I was running out of CPU resources. It looked like a load data problem.
The correction was to change the z/Linux LPAR so that it could use two engines
instead of one. Then the load worked. IBM did not have an answer for this, other
than it needed more resources.
30
Create the indexes needed and Runstats
The script that loaded the data did not create any
indexes.
Run the script to create indexes from the mainframe.
Run script to do a runstats on all the tables that were
just loaded.
31
The script to create the tables did not create the indexes. Therefore you have to run
a DB2LOOK command and extract the index information from the mainframe and
then create those indexes on z/Linux.
I like to run RUNSTATS after a load, so I created a script where after the “cross
load” is finished you can run a RUNSTATS ALL for every table.
Both of these scripts are shown later in this presentation
31
Monitoring DB2 using DB2PE
Gateway information
DB2 connect information
Instance information
Monitoring Bufferpools
Monitoring SQL Activity
32
While we were in the middle of the trial of z/Linux, we also ran a trial of DB2PE
for z/Linux on z/Series LPAR. Here I have put together some of the information
showing the information on the DB2PE screens. These screens were taken from
IBM DEMO web site.
32
33
This is what the initial screen looks like. This is called the Gateway information. It
is a logon screen to the server where you are running the DB2PE instance.
33
34
This is an example of the DB2 connect information. The IP address, the Server
Instance Name and Version number are displayed.
34
35
This is an example of the information of the instance that your are monitoring.
As you go down each tab you see information about the instance, Database,
Dynamic SQL statements, tablespaces, bufferpools, etc.
35
36
Here is an example of the bufferpool display. As you see, all of the buffers are
displayed across the screen. This screen shows detail information about each pool.
36
37
This is an example of the bufferpool trace report.
37
38
You can view the SQL Activity for the instance by using that tab. This is just one of
the many tabs you can go to. The next slide will show the detail of the SQL
Activity.
38
39
This is an example of the SQL activity for this instance. The detail of the SQL
activity is shown here.
39
Scripts for moving data from the Mainframe
Script to set-up database/tablespaces
Script to create the federated database definitions
Script to create the nicknames control cards
Script to create the load control cards
Script to create the indexes control cards
Script to grant access to existing users
Script to create runstats control cards
Script to create a reorg on all tablespaces with
primary indexes
40
This is a list of the scripts that do the work to establish, load, runstats and reorg the
new tablespaces on z/Linux. In the scripts if you see USERID or PASSWORD, this
is for you to put your userid and password in these areas.
40
Scripts to set-up database/tablespace
db2 "create database IDWT on /usr/datat"
db2 "connect to IDWT "
db2 "create bufferpool idwttable immediate size 1000 pagesize 8K"
db2 "create bufferpool idwtindex immediate size 1000 pagesize 4K"
db2 "create tablespace userspacei pagesize 4096 managed by database using
(file '/usr/datat/indexcontainer' 2000 M)bufferpool idwtindex"
db2 "create tablespace userspacet pagesize 8192 managed by database using
(file '/usr/datat/tablecontainer' 22000 M)bufferpool idwttable"
41
This first script is to create the database and tablespaces needed. Determine the size
and the mount point before you run this script. At the same time you are also
creating a bufferpool for your tablespace and indexspace. You might want to use a
naming standard for your objects. This will make it easier in the future when you
need to find them or create new objects.
41
Scripts to create federated database definitions.
db2 connect to database IDWT
db2 update dbm config using federated YES
db2 "create wrapper drda"
db2 "create server servername type db2/zSeries version 7.1
wrapper drda authorization userid password password options
(dbname 'dbdname',fold_id 'U', fold_pw 'U',
db2_maximal_pushdown 'Y')"
db2 "create user mapping for instancename server servername
options (remote_authid 'userid', remote_password 'password')"
42
This is the script that will update your DBM config file to turn Federated on so you
can use the federated database. It will also create the wrapper/server you will need
to create your nicknames.
42
Scripts to create nicknames control cards
db2 connect to dsnq user userid using password;
echo db2 \"connect to idwt \" >> xload2out.sh
db2 -x "select 'db2 \"create nickname ' \
concat 'NNQ.' concat strip(name) \
concat ' for pal6dsnq.' \
concat strip(creator) concat '.' concat strip(name) concat '\";' \
from sysibm.systables \
where creator = 'IDWT' " >> xload2out.sh
chmod 755 xload2out.sh
43
This is the script that will read the mainframe database and create another
script(xload2out.sh) that will contain a set of commands. These commands will
create the nicknames.
43
Script to create load control cards
db2 connect to dsnq user Userid using password;
db2 -x "select creator, name \
from sysibm.systables \
where creator = 'IDWT'" |
awk '
BEGIN {CNT=0; print "db2 connect to IDWT \n\n" }
{print "echo \"### Creating " $2 " # “++CNT "\"\n" \
44
This script will create another script(xloadout3.sh) that will contain the control
cards to create all the tables on Linux and “cross load” them using the nicknames
that were created earlier.
44
Script to create Load control cards continued
"db2 \"create table " $1 "." $2 " like NNQ." $2 \
" in userspacet index in userspacei\"\n\n" \
"echo \"### Create cursor\"\n" \
"db2 \"declare C1 cursor for " \
"select * from NNQ." $2 " for read only\"\n\n" \
"echo \"### Load from cursor\"\n" \
"db2 \"load from c1 of cursor insert into IDWT." $2 "\"\n\n" \
"echo \"### Commit work\"\n"\
"db2 commit; \n" }' > xload3out.sh
chmod 755 xload3out.sh
45
This is the rest of the same script.
45
Create control cards for index creations
Use DB2look to capture index from mainframe.
DB2look –d DSNQ –i userid –w Password –e –u IDWT
-o dataset.name –noview
This will give you a dataset with all the definitions of the tablespaces and
indexes. I edited this dataset leaving the index creates.
You then add (db2 “) at the beginning of each statement and you add (“ /) at
the end of each statement.
You can then run this script to create your indexes.
46
This “script” uses the dbB2look command and extracts the information from the
mainframe about all the objects you are trying to move to z/Linux. This will create a
file that you will have to edit to delete all the information you do not need. In this
case you want to keep the statements for creating the indexes. You then have to edit
the same file to add (db2 “) to the beginning of each command and you have to end
each command with (“ /). Then you run this script and create the indexes.
46
Script to grant access to existing users
db2 connect to dsnq user userid using password;
echo "db2 connect to IDWT" >> authorityout.sh
db2 -x "SELECT 'db2 \"GRANT ',\
CASE WHEN SELECTAUTH = 'Y' THEN 'SELECT ' ELSE ' ' END,\
CASE WHEN DELETEAUTH = 'Y' THEN ', DELETE ' ELSE ' ' END,\
CASE WHEN INSERTAUTH = 'Y' THEN ', INSERT ' ELSE ' ' END,\
CASE WHEN UPDATEAUTH = 'Y' THEN ', UPDATE ' ELSE ' ' END,\
47
One of the other things that was not copied to z/Linux was the DB2 security being
used on the mainframe. Using this script you can extract that security from the
mainframe and run the resulting script(authorityout.sh) and create that security in
Linux.
If you choose to keep all the ID’s that were extracted from the mainframe, then you
need to remember to create those ID’s on z/Linux and DB2.
47
Script to grant access to existing users continued
'ON TABLE', STRIP(TCREATOR)||'.'||STRIP(TTNAME) ,\
' TO', GRANTEE, '\";'\
FROM SYSIBM.SYSTABAUTH \
WHERE TCREATOR = 'IDWT'\
AND GRANTOR GRANTEE \
AND SELECTAUTH = 'Y'" >> authorityout.sh
chmod 755 authorityout.sh
48
This is a continuation of the same script
48
Scripts to create Runstats for all tablespaces
db2 connect to dsnq user userid using password;
echo db2 \"connect to idwt \" >> runstats1out.sh
db2 -x "select 'db2 \"runstats on table ' \
concat 'IDWT.' concat strip(name) \
concat ' on all columns and indexes all allow write access' \
concat '\";' \
from sysibm.systables \
where creator = 'IDWT' " >> runstats1out.sh
chmod 755 runstats1out.sh
49
This is the script to create a script(runstats1out.sh) that will run a RUNSTATS for
all the tables you just loaded.
49
Scripts to create Reorg control cards
db2 connect to idwt;
echo db2 \"connect to idwt \" >> reorg1out.sh
db2 -x "select distinct 'db2 \"reorg table ' \
concat 'IDWT.' concat a.name \
concat ' index ' \
concat 'IDWT.' concat b.name \
concat ' inplace allow write access start' \
concat '\";' \
50
This is an optional script to create a script(reorg1out.sh) for reorging all the
tablespaces loaded.
You might not need this right away, since you just loaded them, but sometime in the
future you might need this.
50
Scripts to create reorg control cards continued
from sysibm.systables a\
,sysibm.sysindexes b \
where tbname = a.name and \
b.name like '%0' and \
a.creator = 'IDWT' " >> reorg1out.sh
chmod 755 reorg1out.sh
51
A continuation of the same script.
51
Testing the Data Warehouse Applications
Setting up the gateway connection to access
the z/Linux LPAR
Creating a DB2 connect definition for Linux
Accessing the z/Linux LPAR with our INTRANET Gateway
Accessing the z/Linux LPAR with DB2 control Center
Have the Programmers access the data on Linux with Cognos
IMPROMTO ,POWERPLAY and ReportNet
52
After the data was copied over to z/Linux, we needed to run an application test of
the Data Warehouse. This details some of the steps we took to run this test.
52
Setting up the gateway connection to access the z/Linux
LPAR
The System Admin logons on to our Gateway
Server and changed the IP address to point to our z./Linux
LPAR.
53
We had to change our existing gateway to point to the new z/Linux LPAR. You can
do this by using the DNS name or the actual IP address. We choose the DNS name.
53
Creating a DB2 connection definition for Linux
Using DB2 Configuration Assistant, defined the
following:
1.Protocol = TCP/IP
2.TCP/IP Host name=IP address of Linux box
Service name= DB2_db2inst1
3. Database Database name = IDWT
Database Alias = FLANWRL
4. Data Source Data source name= idwt
5. Node Options Operating System = Linux
Remote instance name = db2inst1
54
You have to define to DB2 connect, the new z/Linux system. The definitions here
are the ones you have been creating during the creation of the instance. Some of the
names come from your mainframe DRDA defines.
This is done using the DB2 Configuration Assistant.
54
Creating a DB2 connection definition for Linux
Continued..
6. System Options System name = Linuxtest
Host Name = IP Address of Linux Box
Operating System = Linux
7. Security Options
Check ‘use authentication value in server’s DBM
Configuration’ Button
55
In this case the “SYSTEM NAME” is the LPAR name.
This is a continuation of the DB2 connection creation.
55
Accessing the z/Linux LPAR with our Intranet Gateway
I logged on to the Intranet, with the address
of our test Gateway server that was pointed earlier to the
z/Linux LPAR
This gave us direct access to Linux using the
intranet Gateway
56
This is showing that you can access our z/Linux LPAR using our intranet gateway.
One of the ways we needed to get to our Data warehouse was thru our intranet. So
after the Gateway server DNS name was changed, we logged on to that server we
were directed to the z/Linux system.
56
Accessing the z/Linux LPAR with DB2 control Center
By using my client on my workstation with DB2 Control
Center, I was able to access the z/Linux LPAR from my
desktop.
I was able to do all the DB2 normal administration work
using this interface.
57
On my workstation I have DB2 Control Center installed. By using the DB2
connection name that I created on my workstation, I was able to access the z/Linux
LPAR directly from my workstation. This showed that we can also access z/Linux
from another source from the intranet.
57
Have the programmers access the data on Linux with
Cognos IMPROMPTU, POWERPLAY and ReportNet
Our programmers tested the z/Linux LPAR
by using each of the above products thru the intranet
gateway.
Three different programmers were able to access the
data and create reports, run existing reports, and cubes
against the z/Linux LPAR’s data.
58
Some of the products that we have in house that we needed to test to see if they
worked on z/Linux were mostly in the Cognos line of products. They were;
Impromptu on-line report writer
Power Play Cube builder
Report Net on-line report writer
( we are replacing our Impromptu with Report Net)
58
Rating the Critical Success Factors:
1)- Acceptable performance. (Yes)
2)- Ease of transferring data to the zLinux system from
z/OS. (not so easy, might get better)
3)- Functional interoperability of DB2 between z/Linux/
(We did not find any problems here)
4)- Ease of porting applications to the virtual z/Linux servers.
(No problem)
5)- Integrity of data for the Data Warehouse on z/Linux.
(No problems)
6)- Recoverability of the data, ease of use. (Not tested)
7)- Acceptable tools for managing DB2 UDB for Linux. (Not easy)
8)- Operability with Cognos tools (Connections). (Mostly OK)
9)- Acceptable tools to monitor DB2 UDB for Linux. (Not as full function
59
as mainframe)
This is a repeat of the Critical Success factors to see how we did.
Well as you can see, we did not get to exercise all the critical factors because of
time and some of the problems we had with the trial.
We felt that the performance was very good as long as we had the IFL engine.
Moving the data from the mainframe to z/Linux was not that easy. I have detailed a
few of the problems in this presentation.
Functional interoperability seemed to be the same to us.
We were able to port applications to access the z/Linux data by just changing the
DNS name.
The integrity of the data was never a question.
We did not have the time or resources to test the recoverability of the data.
We did not find any tools for LUW DB2 that we felt compared to that on the
mainframe.
We had only one problem with the Cognos Tools, some type of Cognos Catalog
definition problem. We were able to code around this.
The monitoring tools were not up to the standard of the mainframe.
59
In Summary
Test was a success, we learned a lot about Linux and DB2 UDB for
Linux.
We feel that most of the tools we looked at were
not as mature as the mainframe tools.
We did not feel comfortable trying to find SQL
problems on the DB2 UDB for Linux platform or
trying to measure system performance..
Right now, in the project, it would require some
training on the Database side that our schedule does not
permit.
Our decision was to……
60
A summary of the test.
We felt that the test was very successful, it showed that as of right now we need to
stay on the mainframe, but maybe sometime in the not so distance future that we
might want to look at moving our data warehouse off to the LUW platform. This
will depend on the tools vendors and the ease of moving the data across.
60
stay on the mainframe for Data Warehouse!
Continue to use Linux and DB2 to see how we can use its
power and lower cost somewhere else.
Reference Material
Redbook Up and Running with DB2 for Linux.
Redbook DB2 UDB Evaluation Guide for Linux and Windows
Web sites
www.ibm.com/software/data/db2/linux
www.ibm.com/db2/linux/validate
www.ibm.com/db2/linux
www.ibm.com/software/is/mp/linux/software
61
We made the decision to keep our Data Warehouse on the mainframe. This was
done for two major reasons.
1. The z/Linux Trial did not meet all the critical success factors.
2. We upgraded our mainframe and alleviated the workload constraints.
Also listed here are some references for you.
61
DB2 for Linux, Unix, Windows in z/Linux User Experience
Session: D06
John C. Lendman
Palm Beach County School District
Lendman@palmbeach.k12.fl.us
THANKS FOR ATTENDING
Please fill out your session evaluations
62
THE END
62