Appendix H. Testing Tips and Hints

This appendix is available to help in identifying problems encountered with installation or execution of the PCM Testkit Version 4.7. Please read this appendix for testkit section you are having problems with.

Other or updated tips files are available on the OS/2 PCM Compatibility Test Program Web Site.

Problem Isolation

Provides information on general problem isolation.

The OS/2 Compatibility testkit is made up of testcases from the OS/2 FVT and SVT test groups.

The testkit focus is on hardware compatibility and designed to exercise the OS/2 interfaces to the hardware components in a system unit.

The testcases are run from combinations of Presentation Manager programs, command files, and controlling processes (switch.exe and dswitch.exe).

The controlling processes run testcase script files (.scr) that contain the controls for starting sessions and running executables with parameters.

Most testcases in a test group can be run independently from an OS/2 full screen or window session, in many cases the individual executables can be re-run separately without re-running the entire testcase.

As with most testcases, there may be timing instances when a failure is generated that is not due to an error in either the hardware or OS/2. This is why the recommendation for failures noted is to first re-run the failing testcase by itself.

Intermittent fails typically point to transient timing problems in the test tools and/or testcases and will typically pass on individual re-run of the testcase.

Consistent fails with individual re-runs MAY point to problems with the hardware, BIOS, or OS/2 device driver timings.

If attempts at re-running the individual testcase or executable consistently result in a failure, then you should next re-install the testcase group from the CDROM and re-run the failing test again.

If you still get failures, then check the CDROM to be sure there are no scratches or smudges on the CDROM that may be resulting in a file being copied incorrectly.

To copy an individual executable from the testkit CDROM, follow these instructions:

Then re-run the testcase to see if the failure is cleared.

For information on how to re-run individual testcases, refer to the main PCM Testkit Documentation.

For information on how to re-run individual executables, refer to the Tips Documentation for that testcase group.

Stress Testcase Help

Provides information on the stress testcase and information on re-running individual executables and updating of the testkit results files.

The STRESS testcase consists of a group of executables that are run under a controlling processes (switch.exe and dswitch.exe). The switch program takes in a script file (pcmmed01) which contains the controls for starting the various screen groups (sessions) and testcase executables. The main switch.exe is invoked through RUN.CMD and takes in the script file and creates the different screen groups and controls testcase execution.

The script PCMMED01 is setup to create 8 screen groups and start/stop the testcases in the different screen groups. The screen groups are used for grouping testcases as follows:

Screen Group

Session Type

Testcases

1 - DSwitch.exe

MVDM DOS window

DOS VDM File/Video tests

2 - Switch.exe

Vio Window Session

File System

3 - Switch.exe

Vio Window Session

File System

4 - Switch.exe

Vio Window Session

Pipes/Queues

5 - Switch.exe

Full Screen Session

NPX/Pipes

6 - Switch.exe

PM Session

PM Exercisers

7 - Switch.exe

Vio Window Session

Memory Exercisers

8 - Switch.exe

Vio Window Session

Memory Exercisers

With version 4.7 of the testkit, many of the testcases were updated and now include a timer parameter that specifies how long the individual executable will run, others are setup to run until all work is completed. The MVDM testcases will run until they complete, and no other tests can be started in that screen group until the testcase prior has finished.

To see the list of executables in each screen group, you can print the file \SCRIPT\PCMMED01 which contains a breakdown at the top, along with an indicator of whether the executable is timed, or runs to completion.

The PCMMED01 script also creates several working directories that are used by the various testcases, and at the end, the directories are cleared and deleted. Some directories are created on the testcase drive, and some on the scratch diskette in the A: drive. In the script, the directories are all assumed to be at the root of either the testcase drive or diskette.

Several testcases require predefined input files located in the TEXT directory for correct test execution, which are provided as parameters.

The STRESS testcase can be started in two ways, the first is the PM Test icon in the Testkit Folder on the desktop. The second is to open an OS/2 full screen session, go to the \LOG directory on the testcase drive and type RUN and enter. In both cases, you will be prompted for a scratch diskette in the A: drive (unless already inserted).

At the end of the script execution, the RUN.CMD calls LOG.CMD to create the PCMMED01.SUM file in the \LOG directory with PASS/FAIL information for the various testcases. This summary file is used during results processing. You can view the file by going to the \LOG directory and entering the command "type pcmmed01.sum".

If you have a lot of missing testcases, first check that stress testcases were installed, and that there is at least 10MB of free space on the disk. If the disk is full, there are testcases that will either fail or not run properly. Also, verify that the config.sys was updated correctly to setup the dpath/path/text statements to point to the testcase drive and directories, and that the PCM environment variables are at the bottom.

If the config.sys is not correct, you can re-run the program PCMSETUP from the Testkit folder, select the 1st checkbox and verify that the OS/2 and Testcase drive information is correct, then hit the RUN button, when completed, shutdown and reboot, then re-run the STRESS testcase.

Typically, you will see a lot of missing testcases if the config.sys was not setup properly and the system rebooted, or not all the stress testcases were installed. You may also see this if one of the testcases had a problem where it caused a system lockup, thus preventing the remaining testcases from executing.

If you have only a couple testcases that have failed, and re-running the entire STRESS testcase does not change this, then you may need to run the failing tests individually. To run an individual testcase, follow this procedure:

  1. Open OS/2 full screen session

  2. "D.CMD" (changes to \LOG directory on testcase drive)

  3. "grep xxxxxx.exe \script\pcmmed01" (were xxxxx.exe is testcase to run)

  4. Write down the parameters you see listed on the line.

  5. If there are any directories needed, you will need to create those from the root of the testcase drive or A: drive as needed. The directories used are the following:

  6. (testcase drive):

  7. \SeqDir

  8. \RanDir

  9. \Tmp1

  10. \Tmp2

  11. \Tmp3

  12. \Tmp4

  13. (A: drive diskette):

  14. A:\SeqDir

  15. A:\RanDir

  16. A:\WrkDir

  17. Note if the testcase uses a timer variable, you will want to change the timer value so that the testcase runs approximately 10-15 minutes.

  18. In the \LOG directory, enter the testcase and variables noted from the grep output done in step 3 above, only changing the timer variable if applicable.

  19. After all the individual testcase have been rerun, enter the command "strlog q pcmmed01" to recreate PCMMED01.SUM summary file.

The following is section provides information on individual testcase executables and their associated parms. Also provided is the sequence/command in order to re-run the testcase as outlined on page-2 of this document.

BSEQMP (timer ends)

This will spawn instances of child process BSEQMPC.EXE during execution.

usage: BSEQMP [-u qx] [-u P] [-u cxxx] [-u Zxxx] [-u Nxxx] [-u nxxx] [-u mxxx]

[-u ixxx] [testlog flags]

? Help info

-u qx Type of queue for this test FIFO/LIFO/PRIORITY(default is FIFO)

-u P Use SYNCHRONOUS processes (default is ASYNCHRONOUS)

-u cxxx Run for xxx seconds or until error. (14400 sec is default)

-u Zxxx Sem timeout on thrds & processes (900,000 ms default)

-u Nxxx Number of queue processes to kick off(2-30, default=4)

-u nxxx Number of queue items to start with(default=10)

-u mxxx Max number of queue items to test(default=250)

-u ixxx Number of queue items to increase by each pass(default=10)

-u vxxx Number of times to run the iterations

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: BseQMP.exe -u c300 -u n10 -u m80 -u i5 -u N10 -u qPRIORITY -fBSEQMP -l5 -o

CLOCK32 (timer ends)

To view additional information on the clock32 testcase open an OS/2 session and change to the \STRESS directory and type "clock32" enter. This will start the program on the desktop, then use the EXTENDED HELP option.

usage: Clock32 -u kxxx [-u AUTO] [-u ICON] [-u NOLOGO] [-u RESTORE] [-u SINGLE]

[-u TYPE:pstype]

-u kxxx Number of seconds xxx to run the program

-u AUTO Starts the program in AUTO mode and handles input to the logo dialog box if necessary.

-u ICON Starts the program in MINIMIZED state.

-u NOLOGO Causes the logo dialog box to NOT DISPLAY.

-u RESTORE The program is restored to the state that was saved when last WM_SAVEAPPLICATION message was received.

-u SINGLE Runs program single-threaded instead of multi-threaded.

-u TYPE:CACHE Makes a Cached PS the initial presentation space.

-u TYPE:MICRO Makes a Micro PS the initial presentation space.

-u TYPE:NORMAL Makes a Normal PS the initial presentation space.

-u TYPE:RETAIN Makes the Retained PS the initial presentation space.

-u TYPE:AVIO Makes the AVIO PS the initial presentation space.

-u TYPE:BITMAP Makes the BITMAP DC the initial device context.

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: Clock32.exe -u k300 -u nologo -u type:bitmap -fCLOCK32 -l5 -o

CUBE (CC or F3 to end)

To view additional information on the cube testcase open an OS/2 session and change to the \STRESS directory and type "cube" enter. This will start the program on the desktop, then use the EXTENDED HELP option.

usage: CUBE [/AUTO] [/NOLOGO] [/DIM:dimension]

/AUTO Starts the program in AUTO mode and handles input to the dialog box if necessary.

/NOLOGO Causes the logo dialog box to NOT DISPLAY.

/DIM:2 Makes cube size of 2x2x2

/DIM:3 Makes cube size of 3x3x3

/DIM:4 Makes cube size of 4x4x4

/DIM:5 Makes cube size of 5x5x5

/DIM:6 Makes cube size of 6x6x6

-s***** Logfile Nmae

-l5 Logging level 5 -> 9

re-run: Cube.exe /auto /nologo /DIM:5 -sCube -l5

Wait approximated 5 minutes then end with F3 key, or Ctrl-C.

CUBE32 (timer or CC or F3 to end)

To view additional information on the cube32 testcase open an OS/2 session and change to the \STRESS directory and type "cube32" enter. This will start the program on the desktop, then use the EXTENDED HELP option.

usage: CUBE32 -u txxx [-u AUTO] [-u NOLOGO] [-u DIM:dimension]

-u txxx Time in seconds xxx to run testcase.

-u AUTO Starts the program in AUTO mode and handles input to the dialog box if necessary.

-u NOLOGO Causes the logo dialog box to NOT DISPLAY.

-u DIM:2 Makes cube size of 2x2x2

-u DIM:3 Makes cube size of 3x3x3

-u DIM:4 Makes cube size of 4x4x4

-u DIM:5 Makes cube size of 5x5x5

-u DIM:6 Makes cube size of 6x6x6

-f***** Logfile name

-l5 Logging level 5 -> 9

rerun: Cube32.exe -u t300 -u nologo -u auto -fCUBE32 -l5 –o

EXCEPT32 (switcher KS, CC, or alt-F4 to end)

usage: Except32 [-c##] [-u##] [-z##] [-o] [-m##] [-n##] [-t##]

[-ICON] [-HELP] [-ABOUT]

-c## # of invalid-opcode threads 0-128 (default 2)

-u## # of unwind threads 0-1 (default 1)

-z## # of divde-by-zero threads 0-128 (default 2)

-o turns on stack overflow test

-m## # of milliseconds to suspend threads 1-300000 (default 300)

-n## # of miliseconds before resume threads 1-300000 (default 300)

-t## how ofter in seconds to redisplay status 3-60 (default 5)

-ICON minimizes the window on startup

-HELP display help dialog box on startup

-ABOUT display about dialog box on startup

-s***** Logfile name

re-run: Except32.exe -sExcept32 -l5

Wait approximated 5 minutes then end with Alt-F4, or Ctrl-C.

FLTxxx (run until finished) (VDM tests)

usage: fltxxx

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: Flt002.exe -fFlt002 -l5

Flt004.exe -fFlt004 -l5

Flt005.exe -fFlt005 -l5

Flt009.exe -fFlt009 -l5

Flt010.exe -fFlt010 -l5

Flt012.exe -fFlt012 -l5

Flt013.exe -fFlt013 -l5

Flt015.exe -fFlt015 -l5

Flt016.exe -fFlt016 -l5

Flt017.exe -fFlt017 -l5

Flt018.exe -fFlt018 -l5

FS32COPY or FSCOPY (runs till finished)

usage: FS32COPY -u n## -u m#### -u iINSPEC -u oOutPath

FSCOPY -u n## -u m#### -u iINSPEC -u oOutPath

-u i***** Input path/file specification with wildcards.

This is a Required field. No ending '\'.

-u o***** Output path must be a directory. No ending '\'.

-u n## The number of threads 1-14 copying. Default is one.

-u m#### Copy open mode flags for output files.

-f***** Logfile name

-l5 Logging level 5-> 9

prep: FS32CPY1 Create directory \SeqDir on A:

FS32CPY2 Create directory \TMP4 on testcase drive

FSCOPY01 Create directory \RanDir on A:

FSCOPY02 Create directory \SeqDir on testcase drive

re-run: FS32Copy.exe -u n7 -u i\stress\*.sym -u oA:\SeqDir -fFS32CPY1 -l5 -o

FS32Copy.exe -u n7 -u i\stress\* -u o\Tmp4 -fFS32CPY2 -l5 -o

FSCopy.exe -u n14 -u i\stress\*.sym -u oA:\RanDir -fFSCOPY01 -l5 -o

FSCopy.exe -u n5 -u i\stress\* -u o\SeqDir -fFSCOPY02 -l5 -o

FS32DEL or FSDEL (runs till finished)

Usage: FS32Del [options]

FSDel [options]

-u H Display This Help Summary

-u C<Number> Number of Creation Threads (default 4)

-u D<Number> Number of Deletion Threads (default 4)

-u E<Number> Number of EA Threads (default 4)

-u k<Number> Maximum Number of Files (default 100)

-u m<Number> Maximum File Size (default 512)

-u n<Number> Maximum File Name Length (default 8)

-u o<Number> Maximum EA Size (default 65495)

-u p<path> Path for creating files

-u txxxxx Time in seconds to run testcase

-f***** Logfile name

-l5 Logging level 5 -> 9

prep: FS32DEL1 Create directory \WrkDir on A:

FS32DEL2 Create directory \TMP3 on testcase drive

FSDEL Create directory \SeqDir on testcase drive

re-run: FS32Del.exe -u t300 -u C2 -u D2 -u E1 -u k20 -u m512 -u o256 -u pA:\WrkDir -fFS32DEL1 -l5 -o

FS32Del.exe -u t300 -u C3 -u D3 -u E2 -u k100 -u m1024 -u o1024 -u p\Tmp3 -fFS32DEL2 -l5 -o

FSDel.exe -u t300 -u C3 -u D3 -u E2 -u k100 -u m1024 -u o1024 -u p\SeqDir -fFSDEL -l5 -o

FS32DIR or FSDIR (runs till finished)

usage: FS32DIR [options]

FSDIR [options]

-u H? Display help summary

-u N# Number of nodes in tree (default 100)

-u E# Maximum EA data size (default 65495

-u T# Number of transformations (default 20)

-u D# Maximum size of directory's name

-u P<path> Path for creating directory tree

-f***** Logfile name

-l5 Logging level 5 -> 9

prep: FS32DIR1 Create directory \RanDir on testcase drive

FS32DIR2 Create directory \TMP1 on testcase drive

FSDIR Create directory \RanDir on testcase drive

re-run FS32Dir.exe -u n40 -u t50 -u e2048 -u p\RanDir -fFS32DIR1 -l5 -o

FS32Dir.exe -u n50 -u t10 -u e512 -u p\Tmp1 -fFS32DIR2 -l5 -o

FSDir.exe -u n50 -u t10 -u e512 -u p\RanDir -fFSDIR -l5 -o

FS32LOCK or FSLOCK (runs till finished)

Tests the systems ability to handle multiple file accesses to the same file.

usage: FS32LOCK -u iINPUTFILE -u oOUTPUTFILE -u n99 -u Pthreadprty

FSLOCK -u iINPUTFILE -u oOUTPUTFILE -u n99 -u Pthreadprty

-u i***** Path\Name of a single input file.

-u o***** Path\Name of a single output file.

-u n99 The number of threads (1-10) updating the file. (default 1)

-u p***** Thread priorities (0-9, A-V) for each thread executing.

(A-V is priority 10-31) The default is all 0 priority.

Each digit position represents a single copy thread.

(Example: 0VA94T1U7C, for 10 threads.)

-f***** Logfile name

-l5 Logging level 5 -> 9

prep: FS32LOCK Create directory \TMP4 on testcase drive

FSLOCK01 Create directory \TMP1 on testcase drive

FSLOCK02 Create directory \TMP2 on testcase drive

re-run: FS32Lock.exe -u i\Stress\DSwitch.exe -u n9 -u p02123456A -u o\Tmp4\FSLock.dat -fFS32LOCK -l5 -o

FSLock.exe -u i\Stress\DSwitch.exe -u o\Tmp1\FSLock.dat -u n10 -u p012345ABCD -fFSLOCK01 -l5 -o

FSLock.exe -u i\Stress\DSwitch.exe -u o\Tmp2\FSLock.dat -u n8 -u p3 -fFSLOCK02 -l5 -o

FS32RAND (runs till finished)

usage: FS32RAND -iInSpec -oOutPath -n## -m####

-u i***** Input path/file specification, wildcards allowed.

-u o***** Output path, must be a directory.

-u n## The number of threads 1-14 copying. (default 1)

-u m#### Copy open mode flags for output files.

-f***** Logfile name

-l5 Logging level 5 -> 9

prep: Create directory \RanDir on A: drive

re-run: FS32Rand.exe -u n14 -u i\Text\* -u oA:\RanDir -fFS32RAND -l5 -o

FS32SEQ (runs till finished)

usage: FS32SEQ.EXE -u iINPUTFILE -u oOUTPUT -u n## -u m#### -l# -sname

-u i***** Input path/name with wild cards allowed

-u o***** Output directory

-u n## Number of threads 1-14 (default is 1)

-u m#### Copy open mode flags for output files (default is 0x00A1)

-f***** Logfile name

-l5 Logging level 5 -> 9

prep: Create directory \SeqDir on A: drive

re-run: FS32Seq.exe -u n14 -u i\Text\* -u oA:\SeqDir -fFS32SEQ -l5 -o

GP232 (timer ends)

usage: GP232 -u txxx -u auto

-u txxx Number of seconds to run testcase

-u auto Run in automatic mode

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: Gp232.exe -u t300 -u auto -fGP232 -l5 -o

GPFLOOD (timer ends)

usage: GPIFLOOD -u txxx -u xPATHNAME [-u m] [-u ICON] [-u HELP] [-u ABOUT] [-l#] [-fname]

-u x***** Filename of Bezier and obstacle points

-u m Run in automatic mode (default is manual)

-u ICON Minimize window at startup

-u HELP Display help dialog box at startup

-u ABOUT Display about dialog box at startup

-u f***** Output logfile name

-l5 Logging level 5 -> 9

re-run: GpiFlood.exe -u t1500 -u x\text\bezidata -u m -fGPIFLOOD -l5 -o

LSDLL (timer ends)

usage: LSDLL [-u c#####] [-u d##] [-u e##] [-u n##] [-u t##]

[-u xDLLUSE] [-u yDLLDISABLE] [-l#] [-fname]

-c##### run time in seconds (default 14400 seconds)

-d## module status display interval (default 30 seconds)

-e## clock update interval (default 1 second)

-n## number of loader threads (default is 2)

-t## sleep time between freeing DLL's (default is 3 seconds)

-xDLLNAME Name of DLL to test if given (default is all DLL's)

-yDLLNAME Name of DLL to disable

-fname Logfile name

-l5 Logging Level 5 -> 9

DLL's:

LS32ICON.DLL

32bit icon DLL

LS32STRN.DLL

32bit memory DLL

LS32BIG.DLL

32bit memory DLL with code > 64KB

LS32BAD.DLL

LS32PROT.DLL

re-run: lsdll.exe -u c300 -u n2 -fLSDLL -l5 -o

LSTHRD (CC ends)

usage: lsthrd -nxx -slogname -lx

-nxx Number of threads to start

-s***** Logfile name

-l5 Logging level 5 -> 9

re-run: lsthrd.exe -n4 -sLSTHRD -l5

Wait approximated 5 minutes then end with Ctrl-C.

M32LCK (timer ends)

Usage: M32Lck [-u ?] [-u axx] [-u bxx] [-u cxx] [-u dxx] [-u exx]

[-u fxx] [-u gxx] -lxx

-u ? Help message

-u txx Number of seconds to run testcase

-u Axx Number of GDT Selectors [default 50]

-u Bxx Size of Phys Mem allocated for GDT selectors [default 100 bytes]

-u Cxx Number of Private Objects [default 100]

-u Dxx Size of Private Objects [default 100]

-u Exx Type of memory lock [default ML_SHORT + ML_ANYMEM + ML_NORMAL]

0000 ML_SHORT 0010 ML_HIMEM

0001 ML_LONG 0000 ML_NORMAL

0000 ML_ANYMEM 0100 ML_VERIFY

-u Gxx Number of threads to span [default 10]

-u Hxx Flag AllocPhys Below/Above 16Meg [default ABOVE_1_MEGABYTE]

-u 0000 ABOVE_1_MEGABYTE 0001 BELOW_1_MEGABYTE

-u Jxx Wait flag for memory lock [default MW_BVALID]

-u 0000 MW_BVALID 0001 MW_TEST

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: m32lck.exe -u t300 -u a25 -u b100 -u c50 -u d100 -u g5 -u E1 -u H1 -u J0 -fM32LCK -l5 -o

M32NAME (timer ends)

usage: M32Name -u Axxxx -u Bxxxx -u Mxxxx -u Nxxxx -u Sxxx -u ksmp -Lx

-u a Max number of shared given selectors to allocate (1-6144) [128]

-u b Max segment size (12-65536) [1024]

-u c Time period in Secs. after which the program terminates[14400]

-u m Max number of named shared selectors to allocate (1-30) [16]

-u n Max number of subbing processes to start (1-254) [2]

-u s Statistics logging file path [stdout]

-u v Number of iterations that the child will process.

-u ksmp SMP Kernel is being used.

-f***** Logfile name

-l5 Logging level 5 -> 9

Statistics format

YYYY/MM/DD HH:MM:SS.TH M32Name AAAAAAAA BBBB CCCCCCC DDDD EEEEEEEE FFFF GGGGGGGG HHHH IIII

AAAAAAAA 
          

Total size Allocated memory (hex)

BBBB

current total # of r/w selectors allocated (hex)

CCCCCCCC

Total size of r/w selectors allocated (hex)

DDDD

current total # of named selectors allocated (hex)

EEEEEEEE

Total size of named selectors allocated (hex)

FFFF

current total sub-allocations (hex)

GGGGGGGG

Total size of sub-allocations (hex)

HHHH

Total number of 1st level Suballoc failures (hex)

IIII

Total number of 2nd level Suballoc failures (hex)

re-run: m32name.exe -u c300 -u a16 -u b800 -u m10 -u n10 -fM32NAME -l5 -o

M32PAGE (Ctrl_c ends)

usage: M32Page -l# [-F##] [-M##] [-N##] -L#

? Help Summary

-F## Flag for memory lock (default VMDHL_LONG | VMDHL_16M)

-M## Maximum size of objects (default 16384)

-N## Number of children/objects (default 16)

-L5 Logging level 5 -> 9

LOGFILE NAME DEFAULTS TO M32PAGE

re-run: m32page.exe -n2 -m1024 -l5

M32SHR (timer ends)

Usage: m32shr [options]

-u h Help summary

-u a<Number> Number of NameChld objects (default 10)

-u b<Number> Number of GetChld objects (default 10)

-u c<Number> Number of GiveChld objects (default 10)

-u m<Number> Maximum size of Memory object (default 10)

-u t<Number> Number of Seconds a Child process runs (default 600)

-u ksmp SMP Kernel is used

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: m32shr -u t300 -u a5 -u b5 -u c5 -u m224 -fM32SHR -l5 -o

M32SUB (timer ends)

Usage: m32sub [options]

-u h Help Summary

-u a<Number> Number of threads (default 15)

-u m<Number> Maximum size of Memory object (default 65535)

-u n<Number> Total number of Memory objects (default 255

Number should be greater than One

-u t<Number> Time out to run in Seconds

-u v<Number> Number of times each of the Threads Suballocate

the Memory Objects (default 10)

-u ksmp SMP kernel is used

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: m32sub.exe -u t300 -u a14 -u m512 -u n16 -fM32SUB -l3 -o

MCLK (runs until finished)

usage: MCLK -l# [filename] [-r##] [-i##] [-n###] [-d##] [-fname]

[filename] name of file containing control string

-r## number of times to repeat the control string (default 10)

-i## seconds between repetitions (default 1000 seconds)

-n### Frequency of tone to sound (default 300Hz)

-d## Duration of tone sounded (default 1 sec)

-l# Output logging level 1-9

-fname Output logfile name

re-run: mclk.exe -r2 -i1 -d2 -n440 -fMCLK -l5

MEMCODE (timer ends)

usage: memCode -u Lxxxxx -Lx -u Mxxxx -u Nxxxx [-u X]

-u Lxx Statistics logging file path [optional]

-L Logging level (0-9)

-u M Max amount of memory per selector (1-65535) [128]

-u N Max number of unshared selectors to allocate (1-2050) [256]

-u D Disable VIO status monitoring

-u T Number of seconds to run (Approximate)

-u X Turn on extended memory alloc retry

-f***** Logfile name

-l5 Logging level 5 -> 9

Statistics format: YYYY/MM/DD HH:MM:SS.TH MemCode AAAAAAA

re-run: memcode.exe -u t300 -u n32 -u m512 -u D -fMEMCODE -l5 -o

MEMFREE (timer ends)

usage: memfree -u Lxxxxx -Lx -u Mxxxx -u Nxxxx [-u X][-u Txxx][-u D]

-u Lxx Statistics logging file path [optional]

-u M Max amount of memory per selector (1-65535) [128]

-u N Max number of unshared selectors to allocate (1-2050) [512]

-u D Disable VIO status monitoring

-u T Number of seconds to run (Approximate)

-u X Turn on extended memory alloc retry

-f***** Logfile name

-l Logging level 5 -> 9

Statistics format: YYYY/MM/DD HH:MM:SS.TH

re-run: memfree.exe -u t300 -u n40 -u m160 -u x -u D -fMEMFREE -l5 -o

MEMHUGE (timer ends)

usage: memhuge -u lxxxxx -Lx -u Mxxxx [-u X][-u D]

-u lxx Statistics logging file path [optional]

-u M maximum memory size allocated [67108864]

-u X Enable extended retry

-u D Disable VIO status monitoring

-u t Number of seconds to run.

-f***** Logfile name

-l5 Logging level (0-9)

Statistics format:

YYYY/MM/DD HH:MM:SS.TH MemHuge AAAAAAAA BBBB CCCC DDDDDDDD

AAAAAAAA Total size Allocated memory using (get memory) (hex)

BBBB current total

re-run: memhuge.exe -u t300 -u m69000 -u x -u D -fMEMHUGE1 -l5 -o

memhuge.exe -u t300 -u m262114 -u x -u D -fMEMHUGE2 -l5 -o

MEMLOCK (timer ends)

usage: memlock [-u a#] [-u b##] [-u d] [-u e] [-u c##] [-u h?]

-u A# Type of memory lock 0 = short term (default) 1 = long term

-u b## Size of segments to lock 1-65535 (default 64K from 16K)

-u c## Numbr of segments to lock 1-2048 (default is 2048)

-u D Disable statistic screen display

-u E## Sharing attributes of allocated segment

0 = private (default)

1 = sharable through DosGiveSeg

2 = sharable through DosGetSeg

4 = discardable

8 = sharable, shrinkable

-u h? display help message

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: memlock.exe -u t300 -u D -u b9 -u c200 -u A1 -u E0 -fMEMLOCK -l5 -o

MEMSEL (timer ends)

usage: memsel -u lxxxxxxxx -Lx -u Mxxxxx -u Nxxxx -u Oxxxx [-u X]

-u lxx Statistics logging file path [optional]

-u M Maximum memory per segment (1-65535) [128]

-u N Number of shared segments to allocate (1-6144) [4096]

-u O Number of unshared segments to allocate (1-2050) [2000]

-u X Enable extended retry

-u D Disable VIO status monitoring

-u t Seconds to run(appr.)

-f***** Logfile name

-l5 Logging level 5 -> 9

Statistics format:

YYYY/MM/DD HH:MM:SS.HH MemSel AAAAAAAA BBBB CCCCCCCC DDDD EEEEEEEE

AAAAAAAA - Total amount of memory allocated (hex)

BBBB - Number of unshared segments allocated (hex)

CCCCCCCC - Total size of unshared segments (hex)

DDDD - Number of shared segments allocated (hex)

EEEEEEEE - Total size of shared segments (hex)

re-run: memsel.exe -u t300 -u n175 -u m500 -u o25 -u D -fMEMSEL -l5 -o

MEMSUB (Ctrl-C ends)

usage: memsub -l# [statlog] [-M####] [-N####]

statlog Statistics logging file path [optional]

-M#### Max number selectors to allocate (1-512) (Default 128)

-N#### Max number subbing threads to start (1-10) (Default 2)

-f***** Logfile name

-l5 Logging level 5 -> 9

Statistics format:

YYYY/MM/DD HH:MM:SS.TH MemSub AAAAAAAA BBBB CCCCCCC DDDD EEEEEEEE FFFF GGGG

AAAAAAAA Total size Allocated memory (hex)

BBBB current total # of r/w selectors allocated (hex)

CCCCCCCC Total size of r/w selectors allocated (hex)

DDDD current total sub-allocations (hex)

EEEEEEEE Total size of sub-allocations (hex)

FFFF Total number of 1st level Suballoc failures (hex)

GGGG Total number of 2nd level Suballoc failures (hex)

re-run: memsub.exe -m128 -n4 -l4

MEMSUBGR (Ctrl-C ends)

usage: memsubgr -u lxxxxx -Lx -u Mxxxxx

-u Lxx Statistics logging file path [optional]

-u D Disable VIO status monitoring

-u T Number of seconds to run (Approximate)

-u M Max starting memory size (2048-67108864) [67108864]

-f***** Logfile name

-l5 Logging level 5 -> 9

Statistics format:

YYYY/MM/DD HH:MM:SS.TH MemSubgr AAAAAAAA BBBB CCCCCCC DDDD EEEEEEEE

AAAAAAAA Total size Allocated memory using (get memory) (hex)

BBBB current total # of unshared s

re-run: memsubgr.exe -u t300 -u m1048577 -fMEMSUBGR -l5 -o

NMPIPE (runs until finished)

usage: nmpipe [options]

-u H display this help summary

-u SP Short name for pipe

-u I<file-spec> input file specification (default *.*)

-u O<path-spec> output path specification (default \util)

-u PC<pipe-name> client pipe name (default \pipe\pipe1)

-u PS<pipe-name> server pipe name (default \pipe\pipe1)

-u TC<threads> client thread type #s (default 011)

-u TS<threads> server thread type #s (default 0123)

-u PL<pipe-len> pipe length

-f***** Logfile name

-l5 Logging level 5 -> 9

Server Thread Types:

Type Mode Pipe Access Technique

──── ──── ──────────────────────

0 msg Blocking, Nrml R/W

1 byte Blocking, Nrml R/W

2 msg NonBlocking, Nrml R/W

3 byte NonBlocking, Nrml R/W

Client Thread Types:

Type Read Mode Pipe Access Technique

──── ──── ──────────────────────

0 byte stream Blocking, Nrml R/W

1 byte stream NonBlocking, Nrml R/W

NOTE: To re-run NMPIPE1S or NMPIPE1C, you must run both, starting

NMPIPE1S first, then NMPIPE1C. One is server, one is client.

prep: NMPIPE1S or NMPIPE1C - Create directory \TMP2 on testcase drive

NMPIPE02 - Create \TMP1 directory on testcase drive

NMPIPE03 - Create \TMP2 directory on testcase drive

NMPIPE04 - Create \TMP3 directory on testcase drive

re-run: nmpipe.exe -u I\stress\*.sym -u O\Tmp2 -u PC\pipe\Med01a -u PS\pipe\Med01a -u TS0123 -fNMPIPE1S -l5 -o

nmpipe.exe -u I\stress\*.sym -u O\Tmp2 -u PC\pipe\Med01a -u PS\pipe\Med01a -u TC0011 -fNMPIPE1C -l5 -o

nmpipe.exe -u I\stress\*.sym -u O\Tmp1 -u PC\pipe\Med01b -u PS\pipe\Med01b -u TC01 -u TS12 -fNMPIPE02 -l5 -o

nmpipe.exe -u I\stress\*.sym -u O\Tmp2 -u PC\pipe\Med01c -u PS\pipe\Med01c -u TC010101 -u TS0123 -fNMPIPE03 -l5 -o

nmpipe.exe -u I\stress\*.sym -u O\Tmp3 -u PC\pipe\Med01d -u PS\pipe\Med01d -u TC011 -u TS123 -fNMPIPE04 -l5 -o

NPX (timer ends)

usage: npx [-u txxx] [-u ixxx] [writelog flags]

-u nxxx number of threads to do calculations. max of 16.

-u txxx run for xxx seconds or until error.

-u ixxx run xxx iterations through the loop.

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: npx.exe -u t300 -u n2 -fNPX01 -l5 -o

npx.exe -u t300 -u n4 -fNPX02 -l5 -o

npx.exe -u t300 -u n2 -fNPX03 -l5 -o

PIPES (timer ends)

usage: pipes [-u p][-u c][-u nxxx][-u mxxx][-u ixxx][-u Pxxx]

? Help summary

-u p echo progress to the screen

-u c run forever

-u Pxxx number of pipes per process 2-256 (5)

-u nxxx initial size of pipes 1-65535 (100)

-u mxxx maximum size of pipes 1-65535 (65535)

-u ixxx pipe size increment each iteration 1-65535 (1007)

-u txxx Number of Seconds to run

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: pipes.exe -u t300 -u n100 -u m2000 -u i50 -fPIPES01 -l5 -o

pipes.exe -u t300 -u n50 -u m3000 -u i50 -fPIPES02 -l5 -o

pipes.exe -u t300 -u n100 -u m32000 -u i100 -fPIPES03 -l5 -o

SWP232 (runs until finished)

usage: swp32 [options]

-u n## Number of windows to create/process

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: swp32.exe -u n35 -fSWP32 -l5 -o

VIDEO (timer ends)

usage: video

-u t### Number of seconds to run testcase

-u ***** Input file specification

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: video.exe -u t300 -u \text\short1.vid -fVIDEO -l5 -o

VSMAIN32 (Alt-F4 or switcher kill signal)

usage: vsmain32 inputfile

inputfile File containing test control sequences

-s***** Logfile name

-l5 Logging level 5 -> 9

re-run: vsmain32.exe /a\text\vsmnlrg.vsm -sVSMain32 -l5

VSPS32 (Alt-F4 or switcher kill signal)

usage: vsps32 inputfile

inputfile File containing test control sequences

-s***** Logfile name

-l5 Logging level 5 -> 9

re-run: vsps32.exe /a\text\VSPSlrg.VSP -sVSPS32 -l5

VVDCHRIO (runs until finished) (VDM test)

usage: vvdchiro -m#

-m# mode to run 1 -> 9

-f***** Logfile name

-l5 Logging level 5 -> 9

re-run: vvdchrio.exe -m4 -fVVDCHRIO -l5 -o

WIND32 (Alt-F4 or switcher kill signal)

usage: wind32 -u n500

-u n### Number of windows to create/process

-f***** Logfile name

-l5 Logging level

re-run: wind32.exe -u n500 -fWIND32 -l5 -o

Device Driver Information

Provides information on what device drivers should be tested, and a suggested sequence of where to look for updated drivers, and how they should be noted in the PCM Testing report(PCM_HDW).

When testing systems with the PCM OS/2 Compatibility Testkit, is important to get the correct device driver for your system.

WHENEVER YOU TEST A SYSTEM WITH THE PCM TESTKIT, AND USE A DEVICE DRIVER THAT WAS NOT ON THE OS/2 PRODUCT CDROM, YOU SHOULD NOTE IN THE COMMENTS PAGE OF PCM_HDW (PANEL 3) WHERE THE DEVICE DRIVER CAME FROM, THE DRIVER NAME, DATE/TIME STAMP, AND SIZE OF THE DRIVER.

Some Adapter/Device Driver Manufacturers may not have the most recent versions of the device drivers available from their web sites.

When a PCM manufacturer gets a new chipset, some device manufactures will also be provided a specific device driver for that PCM's system that will differ from the device drivers available on the device manufacturers WEB site.

They also may get a copy of the source code for the device driver and make changes to it that are specific to the various system models they make. Even if a PCM offers 2 different system models using the same chipset number, the device driver for each may be different system model.

Typically, when a device driver is tailored for a specific PCM system model, the PCM will provide that unique device driver in the system models ship group of documentation and software, and usually placed on the PCM's WEB site noting the specific system model they work with.

Which means, if the system is shipped with a tailored device driver that is the one that should be used for PCM Testing, since it is the device driver the customers will receive and be expected to use.

If a new or updated device driver is needed, there is a sequence that you should go through in looking for the correct updated device driver for the specific system you are testing.

  1. The first place you should look for an updated device driver, is on the WEB site of the company the manufactured the system unit. If they have a tailored device driver, they usually ship it with their system, but will also probably have it, or an updated version of it on their WEB site for that specific system model and chipset combination.

  2. The second place you should look, if the PCM's web site does not have any tailored device drivers for that system available, would be the IBM OS/2 DDPAK on the WEB.

  3. Note: There is a link to this from the PCM Testkit WEB pages.

  4. Finally, if it's impossible to find a device driver either on the PCM's WEB site, or the IBM OS/2 DDPAK WEB site, then you need to look at the WEB site of the manufacturer of the device/chipset.

PCM_TEST PM Interface

The program PCMTEST.EXE is a PM Graphical User Interface that provides selection and execution control for PCM Testkit testcase groupings.

The user has the ability to select whether to run manual intervention testcase first, or last after all automated testing has completed.

For PCMCIA testcases, the program requires you to enter the drive letters assigned to the PCMCIA slots. The number of slots and drives assigned is dependent on config.sys entries. You can check the DRIVES FOLDER to verify what drive letters were assigned.

The program automatically reboots the system and continues at certain points depending on which testcases have been selected to run.

The program flow is the following:

  1. If Manual FIRST was selected:

    1. If ACCEPTANCE selected

    2. If FVT selected

    3. If MME PCM_REXX was selected, run PMREXX Testcase.

  2. If ACCEPTANCE Selected:

    1. Runs SNF002, SNF005, SNF006, SNFBPB, SNFREXX Testcases

    2. Runs ACC_SUMM.CMD Summary for ACCEPTANCE

  3. If FVT Selected:

    1. Runs FVTDISK, TIMERDD Testcases

    2. Runs FVT_SUMM Summary for FVT

  4. If MULTIMEDIA Selected:

  5. (reboots if ACCEPT or FVT were also selected)

    1. if PCM_VGA Selected, Runs PCM_VGA Testcase

    2. if PCM_SVGA Selected, Runs PCM_SVGA Testcase

    3. if PCM_HPFS Selected, Runs PCM_HPFS Testcase

    4. if PCM_FLC Selected, Runs PCM_FLC Testcase

    5. if PCM_CD Selected, Runs PCM_CD Testcase (SEE NOTE-1 BELOW)

  6. If PCMCIA Selected:

  7. (reboots if ACCEPT or FVT or MMEDIA were also selected)

    1. Runs SLOT-1 testcase selected (ATA, FLASH, SRAM)

    2. Runs SLOT-2 testcase selected (ATA, FLASH, SRAM)

  8. If SMP Selected, runs SMP testcase.

  9. If STRESS Selected:

  10. (reboots if ACCEPT or FVT or MMEDIA or PCMCIA were also selected)

    1. Prompts for diskette in drive A: if not found.

    2. Runs STRESS testcase.

  11. If FVT Selected:

    1. Prompts for diskette in drive A: if not found.

    2. Runs FORMAT testcase.

    3. Runs FVT_SUMM.CMD summary for FVT.

  12. If Manual LAST was selected:

    1. If ACCEPTANCE selected

    2. If FVT selected

    3. If MME PCM_REXX was selected, run PMREXX Testcase.

NOTE-1:

With CDROM Drives connected directly to a sound card, the program may not be able to run the PCM_CD testcase from the PM GUI. There are 2 symptoms of this that require the PCM_CD testcase to be run from an OS/2 Full Screen session instead of the PM GUI.

Symptom-1

Start PCM_TEST and select PCM_CD and have a MUSIC CD in the CDROM drive. Press the "RUN" Button, the program will start, then end before running any testcases. In the file \PCMLOGS\PCMTEST.LOG you will see a return code of 87 from DosQueryFSAttach for the CD Drive Letter. and a return code of 253 from the request for a Music CD in drive.

Symptom-2

Start PCM_TEST and select PCM_CD without any CD in the CDROM drive. Press the "RUN" Button, the program will start, and you will be prompted to insert a Music CD in the CDROM drive, and then press "OK", again the program starts, then ends before running any tests. In the file \PCMLOGS\PCMTEST.LOG you will see a return code of 21 from DosQueryFSAttach for the CD Drive Letter. and a return code of 87 from the request for a Music CD in drive.

NOTE-2:

If you have problems with running from the PM GUI, always check the file \PCMLOGS\PCMTEST.LOG for error return codes. The return codes will usually provide some indication of what the problem is, such as 2041 which indicates the path could not be found. To find out what a return code is, type the command "HELP SYSxxxx" where xxxx is the return code (with leading 0's if needed) that was displayed in the PCMTEST.LOG file.

NOTE-3:

The PM GUI returns "file not found" whenever attempting to run a test group from the GUI. This typically happens if an installation has not been completed correctly and environment variables are not placed in the config.sys.The first step would be to check the file \PCMLOGS\PCMTEST.LOG as was mentioned earlier. The next step is to determine what could account for the files not being found after the PCM testkit installation had been completed and files have been seen on the D: drive from an OS/2 window. There are a few suggestions to try:

Suggestion-1

Many SCSI controllers have a setting for support of disk drives greater than 2GB - if you are using a drives larger than 2GB with this set incorrectly there can be problems. Some SCSI cards provide a key sequence such as a CTRL-A prompt during boot to enter setup, or a diskette/CDROM with software for configuring SCSI controller.

Suggestion-2

If there is a large amount of software installed, the environment variables may not all be set properly as there may be too many set in config.sys and exceed the environment variable space.(OS/2 has an limit on the amount of data that can be stored in the OS/2 environment space). In this case move the PCM set statements in the config.sys from the bottom to the top of the file.

Suggestion-3

If you have a SCSI adapter and use base VGA and all looks ok, then you switch to a video SVGA device (embedded or adapter) and now the files on drive D: cannot be seen, then you should check your config.sys first. In this case, you probably have a large SCSI disk drive, and you will probably see both an IBMINT13.I13 and the specific device driver for the SCSI adapter in config.sys, this would occur during OS/2 installation. Since VGA works ok, but the SVGA driver while the video works, you cannot see files on Drive D:, most likely the SVGA driver activating the video chipset has conflicts with the SCSI chipset or adapter settings, and the system reverts to using IBMINT13.I13 to access the disk. To verify this, you will note that if the system has a SCSI CDROM, it is now not available since IBMINT13.I13 only provides access to the disk drives (and SCSI adatper setting for > 2GB may need to be set). Another way to verify this is to issue the command "RMVIEW >rmv.out", then check the rmv.out file and see which device driver is loaded for the SCSI disk support. If you have this situation, you need to verify the settings of both adapters or chipsets, and then configure the system so no conflicts exist.

Equivalent System Information

The following information supercedes the PCM Testkit V4.1 Documentation and lists the criteria for determining if a system model can be considered equivalent to a model under test and listed as an equivalent system in the WEB report for that model, and if any re-testing is needed.

A system model IS EQUIVALENT without any addiitonal testing needed, if any of the following changes occur to the shipped configuration:

Covers / Frame of the system

No Re-test required

Number of slots on a riser card

No Re-test required

Number of bays for disks, cd-roms, diskettes

No Re-test required

Sizes of Disk / Diskette drives

No Re-test required

Number of installed disks / diskette drives

No Re-test required

Amount of system memory installed

No Re-test required

Power Supply used in system

No Re-test required

No Sound Support if tested system had one

No Re-test required

Network Adapter (tested system can cover 2)

Test 1st/role 1, 2nd/role 2

A system IS NOT EQUIVALENT if any of the following changes occur to the shipped configuration. Re-run the tests indicated, and submit a separate results diskette (COPY OF 1st/ORIGINAL) updated with the re-run tests, and updated PCMHDW system and model specifications.

Planar or component design

Run all BASE/LAN tests

CPU Manufacturer

Run all BASE/LAN tests

CPU Speed (same manufacturer)

Run all BASE/LAN MAX speed, Stress MIN speed

Sound Support - Adapter / MFG

Run Multimedia / Speech tests

CDROM or DVDROM

Re-install Testkit, run Multimedia PCM_CD

Processor or BIOS levels

Run all BASE/LAN tests

Video chipset/adapter

Run ACCEPT and STRESS tests

Disk subsystem Chipset/Interface

Run all STRESS and FVTDISK tests

PCMCIA Chipset / Level

Run PCMCIA tests

APM Interface / level

Run APM and STRESS tests

SMP system - # of Processors

Run all BASE & LAN tests with Min & max # CPU's

NOTE-1:

When you are testing a system, the PCM_HDW panel-5 provides that ability to list equivalent system models. This information is included in the WEB listing for the results diskette submitted.

It is not necessary to submit a separate results diskette for each equivalent system, however the testing is required. This results in only 1 model listing on the WEB with the eqivalent systems included in the report.

If your intent is to have both systems model names listed with reports, thenyou need make a DISKCOPY of the 1st/Original Results Diskette, then re-run the required testcases on the 2nd system with the sub-system changes. Use PCM_HDW to update the system model name, configuration, and equivalency information on

panel-5. Then UPDATE the 2nd (copy) Results Diskette, and submit both results diskettes for processing. Send results images via email as outlined on WEB.

The choice of how to list equivalent systems is up to you, but if the equivalency information indicates that some tests must be re-run due to a single subsystem change, then those tests should be re-run on the system with the subsystem change, whether you are submitting only 1 results diskette or 2.

NOTE-2:

The Celeron line of processors should be treated as a completely different processor line and will require a complete test of the system since they are functionally a different CPU line from the Pentium or Pentium II processor lines.

For different speeds of a Celeron version (300A,333A), you can treat them as equivalent systems and make a copy of the original results diskette for the system tested with the highest speed, and for lower speeds of the same Celeron version you need to run the tests outlined in equivalency information for CPU's with different speeds, and submit either 1 or 2 results diskettes depending on how the manufacturer wants the systems listed on the WEB. If you want different entries, 2 results diskettes need to be submitted, if you only want 1 entry, then you need to be sure to enter the equivalent model information on panel-5 of PCM_HDW and submit 1 results diskette.

For the different versions of Celeron, (333, 333A) ,this would be similar to testing of systems that had Pentium, Pentium II processors and need to have complete testing performed and a different results diskette submitted. This is because the different versions have different features, not just different speeds.

The only time CPU speed equivalency information can be used to define the amount of re-testing needed is with a CPU of the same version where only the speed is different (Celeron 300A, 333A).

LAN TESTING

LAN testing contains a combination of command files and manual test scripts.

The command file testcases are started from the PM GUI "Testcase Selection and Control LAN" icon in the Compatibility Testkit Folder on the desktop.

The command files can also be run individually from the command line. The LAN Testing GUI is started on all systems in the test environment and a target system is selected to test. The same system to exercise should be selected on all systems in the test environment. The individual systems then begin running testcase commands (.CMD's) to exerise the target system selected.

The testcases rely on the systems in the test environment having been installed and configured as outlined in the PCM Compatibility Testkit V4.7 Documentation.

The following section covers potential problems that can occur when running the various testcases.

Testcase: ITLLS56(domain test) ITLLS57(server test) LAN Exercisers

These testcases exercise the LAN environment by copying files to/from the system being tested and comparing the files after each copy. The testcase uses 1MB, 2MB, 4MB, 8MB. Also there is an xcopy of all 4 files (15MB) with a compare of each file after the xcopy finishes.

If testcase appears to hang almost immediately when trying to either delete the old logfile on the target system or on 1st copy attempt. This usually only happens with ETHERNET environments. There is an OS/2 fixpack that will correct this. The latest MPTS fixpack for the OS/2 server product you are using needs to be downloaded and installed on the domain and server systems.

You can see this problem when you start one of the testcases, and when the session hangs, open an OS/2 window and try "NET VIEW" of the target system, you will probably see this hang as well. Sometimes when this is done, the testcase will go one step further, then both session appear hung.

NOTE: There are different fixpacks for OS/2 WARP Server, ADVANCED, and SMP. Be sure to get the correct one for the version installed.

In most cases, the fixpack is all that is needed to correct this problem.

Another problem that can occur with ITLLS56, ITLLS57, and ITLPEER is that you get an access denied failure. If you open an OS/2 window and manually attempt to copy a file to the target system, you will get an error code, use the command "help NETxxxx" to get expanded information on the problem.

However this is usually due to access control problems where the target system's access control is not setup properly. Sometimes a re-run of LANSETUP on the target system then rebooting can correct this problem.

If that does not work, then you should manually open add the access by using the "LAN Services File and Print" folder and then going through LAN Server Administration to add a resource definition and then set

the manage access permissions to add the group USERS with all access privledges granted. To verify, you can then manually try a copy to the target system from another in the environment to verfiy the access denied problem is cleared.

Testcase: ITLMSG (lan messaging) and ITLLD (LAN Distance - with messaging)

There is a known problem with messaging with LAN Server on SMP machines that will cause this test case to fail. The problem is the SMP system will only see the first message it is sent and nothing after that until the system is rebooted. The log file for this test (ITLMSG.R01 or ITLMSG.D01) will indicated there were unsuccessful attempts at sending messages.

This is only a problem when testing a Warp Server SMP system and affects messages sent to the server specifically, broadcast messages are not affected by this and will be received on the Warp Server SMP system.

The testcase ITLMSG.CMD and ITLLD.CMD have been updated in the version 4.7 to use broadcast messages for sending to either the domain controller D01 or additional server S01, while still using single messaging to the clients R01 or R02.

Testcase: ITLSV00 (Group Management)

If the IT01D01 and IT01S01 Netbios system are not detected (i.e. you do not see their icon in the group after doing a discovery) check to see that the Netbios protocol is enabled. Do this from the Netfinity configuration icon in the Netfinity folder.

After enabling that protocol, be sure to also provide the network address, AC010001 for the domain controller, AC010101 for the Additional server.

You will need to close all Netfinity windows and then restart Netfinity for the changes to take effect. Restart Netfinity by double clicking the Netfinity Server Service icon in the Netfinity folder.

Testcase: ITLSV06 (Monitor Remote Systems Resources)

If testing WARP SERVER or WARP SERVER ADVANCED (not SMP) after selecting "Export to Database", you will need to specify the monitor that was used since there will not be a default selection. After highlighting the monitor, click on ok and the filename/directory panel is presented. Change the directory to the ROOT of C:\ (OS/2 Boot Drive example) and enter a filename of IT01xxx.DBF (where xxx can be anything) and then click on OK.

This is due to differences between the SystemView and TME10 defaults for the system monitor utility.

The file IT01xxxx.DBF must be in the root of the OS/2 boot drive (C:\) for results processing to pick it up for processing.

Results processing was looking for only one occurrence in the .DBF file for the system names IT01D01, IT01R01, IT01R02. Monitoring and saving to datafile of more than one activity or interval results in the PCMSCORE.TXT showing a fail.

The results processing routines have been updated to correct this problem. Download the V4.1 FIXPACK to apply the updated routines.

Testcase: ITLSV07 and ITLSV08 (hardware and software inventory)

If you see failing messages in the view log for IT01R02 check to see that system is not configured as a Remote workstation. It is easiest to run this test while IT01R02 is a "Lan Attached Workstation". If it is a Remote attached workstation, one needs to dial in to the LAN Distance connection server to establish the connection to the LAN and for these test cases to work. If these tests fail while dialed in through LAN Distance it might be due to phone line quality. Try running the tests with IT01R02 as a LAN Attached workstation. Use the command:

LDSHUTTL LAN

to switch to a LAN Attached workstation.

NOTE: The LAN Distance Testcase ITLLD.CMD is stared by invoking the command LANRBOOT.CMD which renames startup.cmd to startup.hld. A new version of startup.cmd is created that will automatically run ITLLD.CMD on reboot. The testcase ITLLD.CMD restores startup.hld to startup.cmd when it has completed, shuttles back to LAN Attached and reboots to restore the LAN Attached testing environment on IT01R02. If the testcase ITLLD.CMD does not complete, you will need to copy the file startup.hld to startup.cmd before manually issuing the LDSHUTTL LAN command and rebooting.

Test case TIMER (in the base test cases)

If the timer test case failed rerun the test case after shutting down any "extra" applications that are running. Reboot may be necessary depending on the application that is closed.

Test case ITLLD on R02

If this test case fails the first thing to look for is to determine if the workstation can connect to the LAN Distance connection server. If you are using a nullmodem cable, be sure you have followed the setup instructions on the IT01S01 found in the test kit documentation (section on setting up the additional server).

If the requester connects to the LAN Distance connection server but can not see the domain controller to logon (you see a "Domain not found" message) it is often due to the adapter card used in IT01S01. Not all adapter cards support the functions LAN Distance needs in an adapter, and some adapters require

additional entries in the WAL\WCLLOCAL.INI file in order to be used in a LAN Distance connection server. Check the adapter and driver documentation to verify if any additional entries are required.

Be sure you have followed the setup instructions for the additional server.These instructions tell you how to configure the adapter card with LAN Distance. If you followed these instructions and the requester still can

not see the domain, see if IT01S01 itself can logon to the domain. If neither system can, try using another adapter card in IT01S01 (and be sure to update WCLLOCAL.INI per the documentation).

System hangs while starting LAN Distance (on Server)

After the system has been completely loaded and the LAN test cases have been installed, the system hangs with the "Starting LAN Distance" pop up. This could have been caused by an error when updating the WCLLOCAL.INI file for the adapter being used in the system. Check to see if the NIF file entered in the WCLLOCAL.INI file is correct. Check to see the file specified in the ini file is in the c:\ibmcom\macs directory.