Please ensure that the defect Project is correct, the Abstract
is descriptive and follows all standards set out by your
organization, team and sub-team, and the Build Level and
Environment fields in the Testing tab are complete. Also,
please include information about the Install image used if that
is what was used for testing).
1. Problem description
To summarize, there was a bug that existed since 10.1FP1 where
the -p parameter is being ignored by db2icrt because a
validation code is being skipped. This was fixed in 10.5FP9,
hence the customer sees a change in behaviour between their FP8
SB and FP9 SB. However, the change in FP9 exposed another code
issue in the validation code (the code that was being skipped in
previous fixpacks).
I have backed out the changes for now and we will have to
reevaluate the fix to the original bug in future fixpacks.
2. Operating system and level:
3. Client, server, and gateway information
a. Client information, if applicable
Project:
Build Level:
Environment (including Platform and bitness):
b. Gateway information, if applicable
Project:
Build Level:
Environment (including Platform and bitness):
c. Server information, if applicable
Project:
Build Level:
Environment (including Platform and bitness):
4. System setup
(For example, if your database is partitioned, this is where
this information should be included. Provide clearcase view
name, and contents of db2nodes.cfg file, including catalog,
coordinator node information. Also which machine name has which
node number(s) for DPF.)
5. Diagnostic information
(This section should include applicable db2diag.log entries,
stack traces, lineofcode tool output, and formatted dump files.
Also include any other FODC or PD tool output that helped you or
will help Development diagnose the failure you're opening this
defect for. Include the location of all files not attached but
referenced by this defect.)
6. How to reproduce the problem
(Include the name of the bucket and snippet of existing or
planned test unit that exposed the failure described above. A
"repro" should be as small as possible. Also, include the degree
of difficulty of the repro. A repro is Easy if it can be done
on demand, Medium if it can be done after several attempts, and
Hard if it is not possible.)
7. Did anything in particular seem to cause this problem?
8. Is this problem a regression? If so, please provide details
on the last successful build level similar to (3) above.
================================================
The information in the following checklist is required
specifically for defects found during install testing. If you
are opening a defect to track something other than a defect
(e.g., new feature), you can simply delete the template and fill
in the appropriate information
1. FVT Testcase #:
2. Product , OS info and machine name:
3. Image level:
4. Image source(/devinst, ftp site, pruned or other):
5. Steps to reproduce the problem, including the the command
with all parameters for each step:
6. Expected results:
7. Actual results:
8. Other infomation such as trace, log, error files and
screenshots.
See the link
http://db2install.torolab.ibm.com/install_template/?rm=defect to
get the full template.
=============================================
Unit Testing Information
Platform:
Base Level:
Unit Testing Scenarios: |
