Академический Документы
Профессиональный Документы
Культура Документы
TM
CONFIDENTIAL
Copyright 1993-2009 PC-Doctor, Inc. ALL RIGHTS RESERVED. PC-Doctor is a trademark of PCDoctor, Inc., Reno, NV. All other brand and product names are registered trademarks, trademarks or servicemarks of their respective holders and are gratefully acknowledged. Product specifications subject to change without notice. All PC-Doctor products are protected by one or more of the following patents: 6,742,148; 6,792,562; 6,829,726. Other patents pending.
CONFIDENTIAL
Contents
Welcome to PC-Doctor Network Factory...........................................................................6 Before you Begin Tips for Implementing Network Factory ..........................................8
Understanding how Network Factory Works...........................................................................................8 Network Factory Implementation Planning.............................................................................................9 Implementation Planning Worksheet...........................................................................................9 About the PC-Doctor Network Factory Mapping Program Logic.............................................10 About using wild cards for defining mappings..........................................................................12
Installing and Running the Linux Client................................................................................................50 Defining File Association Links.................................................................................................51 Installing the Linux Client..........................................................................................................51 Running from a Network Share Drive...................................................................................................52 About Network Share Limitations.............................................................................................52
How do I make sure that my installation goes smoothly?..........................................................91 UUTs do not show up in the Progress Monitor..........................................................................91 My UUTs are listed as UUT_TIMED_OUT, but the UUTs are still running. ..........................91 Can I use my own serial loopback adapter with PC-Doctor Network Factory?........................92 How do I reduce the amount of time a test script needs to run?................................................92 How do I run a Pattern Test on my system drive?......................................................................92 How do I modify the server port numbers after Network Factory is installed?.........................93 I just upgraded Network Factory but nothing has changed........................................................93 Using Network Factory Features............................................................................................................93 How do I increase the amount of time a UUT is tested?............................................................93 How do I decrease the amount of time a UUT is tested?...........................................................94 Where do I find Network Factory log files?...............................................................................94 Why cant I run video tests on my Linux UUTs?.......................................................................95 PC-Doctor Network Factory Database...................................................................................................95 How do I back up the PC-Doctor Network Factory database?..................................................95 How do I restore the database from a backed-up database file?................................................95 Selecting the ODBC Example under Reports produces the error Database Connection Failed.95 Where can I find more information on databases used with Network Factory?........................96
Script Warnings are not Shown in the Progress Monitor.........................................................120 DOS UUT Environment Variables.......................................................................................................120 Working From the Command Line......................................................................................................121 The ba:xx and ms:xx Command Line Switches.......................................................................121 The rt:nn, rt:nn,x and rt:nn/x Switches.....................................................................................121 The au:Fname Switch...............................................................................................................129 General Command Line Switch Functions..............................................................................129 Determining and Using Bitmap Values................................................................................................139
PC-Doctor Network Factory consists of four major elements: Server software: provides for management of UUTs connected to Network Factory. The server manages diagnostic progress with all UUTs and records the results in the database.
SQL-compliant database: stores all test results and system information reports. The database provides an audit trail that allows you to increase productivity and reduce costs by performing trend analysis. You can integrate the SQL-compliant database into external applications using standard Open Database Connectivity (ODBC). For more information on ODBC, SEE ALSO ODBC Connectivity with Firebird Database on page 97. Unit Under Test (UUT) software: consists of PC-Doctor hardware diagnostics, system information utilities and scripting tools that provide scripting capabilities and connectivity to the server. Monitoring Console: viewed using Firefox 2.x web browser and available from anywhere that is accessible through the network. The Monitoring Console allows users to manage the testing process, track testing progress and create custom reports. The Monitoring Console support various levels of account permission that allow you to restrict or enable features based on account privilege. For more information on available account privileges, SEE ALSO Creating and Managing Accounts on page 72. The main components of the Monitoring Console consist of the following: Progress Monitor: Provides real-time diagnostic progress. SEE ALSO The Progress Monitor on page 53.
Reports: Provides access to reporting tools for generating custom reports such as test result or system information reports. SEE ALSO Generating Reports on page 56. Script Editor: Provides access to diagnostic script composition tools that allow you to tailor your test environment to your specific needs. SEE ALSO Composing PC-Doctor Network Factory test scripts on page 22. Inventory Auditing: provides tools for quickly performing inventory audits of a system hardware configuration to verify it conforms to a standard specification. SEE ALSO Setting Up and Running an Inventory Test on page 31. Network Factory Configuration: Provides access to tools for modifying your Network Factory test environment including script mapping, server and UUT communication and system information report filters. SEE ALSO Modifying PC-Doctor Network Factory Configuration on page 41. User management: Provides tools for adding information to the database, guidelines for maintaining the Network Factory database and complete control over user account access and privileges. SEE ALSO Managing the Database on page 75 and Creating and Managing Accounts on page 72.
8 | PC-Doctor Network Factory Administrator Guide | Before you Begin Tips for Implementing Network Factory
How you organize your test groups is the basis for your script configurations. It allows you to setup Network Factory to send specific test scripts to specific UUTs. For example, one section of your operation (rack1) performs strictly functional testing. Unique functional testing is performed on two UUTs, modelT42 and model886, that are located in this section of the manufacturing floor but have different testing requirements. You can specify this in Network Factory in the following way:
group=rack1, configuration=modelT42, phase=functional group=rack1, configuration=model886, phase=functional
If you have several UUTs per order that require the same test plan, this would allow you to view UUTs in the Progress Monitor by order number. You can apply the same principles in other areas within your operation, providing a wide degree of customizing options for Network Factory. You can even make the group name something specific. For example, if you want to group UUTs by order number XYZ1234, you can specify the group name as the order number. Using the above example, you would specify the following:
group=XYZ1234, configuration=modelT42, phase=functional
PC-Doctor Network Factory Administrator Guide | Before you Begin Tips for Implementing Network Factory | 9
The next step in planning your Network Factory implementation is specifically what hardware components you want to test. Logically, if a UUT does not have a serial port for example, you would exclude serial port testing from the script that you create for that UUT. Consider these key points: What do you want to test? How do you want to test it?
Step 2: Decide how you want to define Configuration Do you test models or types of systems that require distinct testing? Using Configuration, all systems that match the configuration distinction will use the same script. Define each unique configuration of testing required on your implementation planning worksheet. For example: Do a group of systems requiring identical testing run in a specific operating system, such as Windows? You may decide to define this configuration as Windows. Do specific models of systems require identical testing? You may decide to define this configuration by model number, such as T42 or EO656. Do specific types of systems (laptop, desktop, and so on) require identical testing? You may decide to define this configuration by system type, such as laptop or desktop.
Step 3: Decide how you want to define Phase What types of test processes or phases does your test plan include? For each one, define a name on your worksheet that distinguishes it from other types of test processes or phases. For example: Will you require inventory testing that compares components in a UUT against a master system configuration to ensure that a system is built to specification? You may decide to define this phase as Inventory. Will you require functional testing that exercises a system in a particular operating system? If so, you may decide to define this phase as Functional.
10 | PC-Doctor Network Factory Administrator Guide | Before you Begin Tips for Implementing Network Factory
Will you require burn-in testing that performs heavy testing on a system over an extended period of time? If so, you may decide to define this phase as Burn-in.
Step 4: Decide on what tests will run as part of your configurations and phases The next step is to decide what you want to test specifically for each configuration and phase. To help you coordinate this, look at the Add Tests list in the Scripts pane to view the available test selections (for more information on test scripts, SEE ALSO Implementing Your Network Factory Integration on page 22). You will need to specify an operating system to view the available test selections, which are operating system specific. For more information on available diagnostics, SEE ALSO the PC-Doctor Test Descriptions guide for the appropriate operating system. For example, in your test plan, you may want to run an inventory test against a master configuration system before running any other tests. During the Functional test phase of the Windows configurations, you would like to use the following tests: CD-ROM Linear Seek CD-ROM Random Seek All CMOS tests All CPU tests Hard drive Linear Seek Hard drive Random Seek All memory tests
In addition, during the Burn-in phase, you want to run all the tests that you did for functional, add the funnel seek tests for hard drives and CD-ROMs, and run it in 50 test passes. Use a separate sheet for each set of tests you would like to use for each configuration and phase. Step 5: Determine if the tests you select are the same across a group, configuration or phase For example, after checking off which tests you want to run for both the T456 and R42 Windows configurations, you notice the tests selected for the Functional phase of each model are identical. You also notice the tests selected for the Burn-in phase of each model are identical as well. Identifying the similarities in testing is relevant during the mapping portion of implementation. Step 6: Determine if you want to use a batch file to handle command-line entries at the UUT For example, you would like to run the Inventory and Functional tests sequentially, but you want to run the Burn-in test later because that occurs in a separate location of the facility. In this case, you could create a batch file that runs the Inventory and Functional tests. Step 7: Explore mapping options and implement your test plan The next step is to apply your implementation plan to your diagnostic environment within Network Factory. At this point, you may want to refer to the analysis you did in step 5 of this worksheet. Mapping is a method for associating scripts and files to specific groups, configurations, and phases that you define. This is how Network Factory determines the logical association between, for example, a script file and the UUT it should run on. You can save effort in creating mappings by using wild card symbols (*). Wild cards allow you to consolidate common tests within a group, configuration or phase.
PC-Doctor Network Factory Administrator Guide | Before you Begin Tips for Implementing Network Factory | 11
Once these values are defined and applied to a single mapping, you will need to define the following two values for each mapping you create: Script file name with test selections specific to systems associated to this mapping. Inventory file name that is specific to systems associated to this mapping.
The previous example specifies Network Factory to use the: functional_test.xml script file, system_inventory.xml inventory file, with the rack1 group, that has a modelT42 configuration, and entering the Functional phase of testing.
For a logical progression of how mappings work in Network Factory, see below.
12 | PC-Doctor Network Factory Administrator Guide | Before you Begin Tips for Implementing Network Factory
If the UUT is running Windows, you could create a batch script as follows:
pcd uut -s 192.168.31.145 -g rack1 -c modelT42 -p INVENTORY pcd uut -s 192.168.31.145 -g rack1 -c modelT42 -p FUNCTIONAL pcd uut -s 192.168.31.145 -g rack1 -c modelT42 -p BURN-IN
Note: By default, Network Factory uses TCP port 4560 and UDP port 6001 to conduct communication between the UUT and server. If you plan on using a different port for this communication, you will need to specify it in your batch file. For example:
pcd uut -s 192.168.31.145:5555 -g rack1 -c modelT42 -p INVENTORY pcd uut -s 192.168.31.145:5555 -g rack1 -c modelT42 -p FUNCTIONAL pcd uut -s 192.168.31.145:5555 -g rack1 -c modelT42 -p BURN-IN
The tests complete in the order listed in the batch file. The above example is useful for varying configurations and groups. For example, your process includes the above mentioned phases: inventory, functional, and burn-in. You also have 10 different hardware configurations, requiring 10 different inventory tests. At one extreme you could create 30 different mapping sets with a unique test script for all of them or you could use the same burn-in test among all of them and only create 21 mapping sets. An even better solution is using the same functional and burn-in tests for all 10 configurations and then create a unique inventory mapping set for each configuration. This would result in only 12 mapping sets instead of the original 30, demonstrating why it is important to look for common tests during your implementation planning.To take advantage of using the wildcard capability, you could create the following mapping sets. These mapping sets share both the functional and the burn-in test for multiple systems and have unique inventory scripts for each configuration.
*:*:FUNCTIONAL.script - functional_test.xml *:*:FUNCTIONAL.inventory - none *:*:BURN-IN.script - burn-in_test.xml *:*:BURN-IN.inventory - none
PC-Doctor Network Factory Administrator Guide | Before you Begin Tips for Implementing Network Factory | 13
On the UUT, you can create a batch file for this scenario that would look like this:
pcd uut -s 192.168.31.145 -g rack1 -c modelT42 -p inventory pcd uut -s 192.168.31.145 -p functional pcd uut -s 192.168.31.145 -p burn-in
Note: Ensure you include the port number if you are using a port other than 4560 for communication between the UUT and server. Using your understanding of the mapping flow (see Figure 2: Network Factory Mapping Logic Flowchart on page 11), you can see that the first line in the batch file would look specifically for a named group, configuration and phase. The second line in the batch file would look for *.*.functional and the third test would look for *.*.burn-in. This example would apply to any combination of group, configuration and phase. Understanding how systems are designed and the options available to you can greatly reduce the amount of work required to implement Network Factory. For more information on Network Factory mappings, SEE ALSO Implementing Your Network Factory Integration on page 22.
14 | PC-Doctor Network Factory Administrator Guide | Getting Started Installing Network Factory
PC-Doctor Network Factory Server runs on the Windows operating system. Verify that your server is running one of the following: Windows 2003 Server Windows 2000 Server with Service Pack 4 Windows 2000 Pro with Service Pack 4 Windows XP Pro
PC-Doctor Network Factory Administrator Guide | Getting Started Installing Network Factory | 15
Recommended web server configuration: Dual Xeon 3.4Ghz or Dual Opteron 246 processors or a dual-core processor of similar specifications 4GB of RAM 120GB 7200RPM SATA or SCSI hard drive(s) including archive space (SEE ALSO Calculating Space Requirements to Support Archiving on page 15) Important: Mirrored+Striped (RAID 10) is highly recommended. UPS with power management software.
If you require a diagnostic solution that will support more than 150 simultaneous UUTs, consult with your PC-Doctor representative. Important: PC-Doctor Network Factory Server requires the use of HTTP port 8080, TCP port 4560, TCP port 4586, TCP port 3050 and UDP port 6001 by default. Disable any services that may interfere with communication on these ports. For example, virus checkers, firewalls, web servers and application servers. Disable virus scanning for the PC-Doctor Network Factory Server installation directory. Virus scanning in the installation directory may corrupt the Network Factory database.
For example, if you test an average of 2000 systems per week and each system runs an average of three different test scripts, a week of archived data will occupy:
2000 * 3 * .09 MB = 540 MB
16 | PC-Doctor Network Factory Administrator Guide | Getting Started Installing Network Factory
PC-Doctor Network Factory Administrator Guide | Getting Started Installing Network Factory | 17
7. Change the listed IP address to the address of the database server. For example:
database.firebird.host = 192.168.1.40
Optional Procedure for Managing Server Processes The following steps are optional but will prevent unneeded processes from running on both servers. 1. On both servers browse to: <install_directory>\bin\ 2. Open the files start.cmd and restart.cmd. You will need to modify the contents of both files on both servers. 3. On the database server replace the contents of start.cmd with:
cd "<install_directory>\Firebird\bin" instsvc start
7. If you did not reboot after installation, reboot now. Once the servers boot up, start the Network Factory database by selecting:
Start->All Programs->PC-Doctor Network Factory Server->Start Network Factory Server
18 | PC-Doctor Network Factory Administrator Guide | Getting Started Installing Network Factory
Once the database is up and running, use the same procedure for starting the web server.
If your server has multiple IP addresses, use the address that connects to the network containing the UUTs.
PC-Doctor Network Factory Administrator Guide | Getting Started Installing Network Factory | 19
Note: The minimum supported resolution for the Monitoring Console is 1024 x 768. 1. Open a Web browser (Firefox 2.x) on any system connected to the same network as the Network Factory server. Although any standard browser will support the Progress Monitor, Network Factory is optimized for Firefox 2.x. 2. In the Address field, type the server IP address from the previous section and port number specified during installation. For example, http://192.168.25.212:8080. See Figure 5: Typing Server IP in the Address field on page 19.
3. When prompted for a user name and password, type admin for both and click the OK button. See Figure 6: The Network Factory User Login on page 19
The Monitoring Console opens, displaying the Progress Monitor. You are now logged into the Network Factory Server with full administrative privileges. See Figure 7: The Monitoring Console Progress Monitor on page 20.
20 | PC-Doctor Network Factory Administrator Guide | Getting Started Installing Network Factory
Troubleshooting Monitoring Console Connection Issues The Monitoring Console view will refresh periodically, and display a No System Found message on the left side of the window until you connect clients to the server. Note: Leave the browser open as you will use it later. If the Progress Monitor does not appear or an error message displays saying the connection was refused, try these steps: 1. Verify you are using the correct operating system and browser. 2. Verify the Network Factory Server software is running. 3. Verify you are using the correct IP address and port number you specified during installation (default is 8080). Some browsers may require you type http:// before the server address. 4. Verify any running firewall is disabled. 5. Verify that your monitor resolution is set to at least 1024x768. 6. Verify the USB dongle is attached. If you remove the USB dongle while running Network Factory, stop the server, insert the dongle, and restart the server. 7. Stop and Start the Network Factory Server by doing the following: a) Stop the PC-Doctor Network Factory Server by clicking the Stop Network Factory Server short-cut located in the PC-Doctor Network Factory for Windows program directory.
PC-Doctor Network Factory Administrator Guide | Getting Started Installing Network Factory | 21
b) Start the PC-Doctor Network Factory Server by clicking the Start Network Factory Server short-cut located in the PC-Doctor Network Factory for Windows program directory
22 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
After you compose your test scripts, you will map them to their appropriate group and configuration.
For the purposes of this exercise, you will name this script functional. To access the script editor, click the Scripts tab. The Scripts pane will open divided into two sections. You will see a drop-down arrow at the top of the left pane for selecting an operating system, and New and Open buttons at the top of the right pane. See below.
When you select an operating system for the script, the Scripts Test List will open. See below.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 23
When composing a script for a specific operating system, use a file name that is descriptive of the supported operating system. For example, when creating a script for Linux, use LinMyTest.xml as the file name. If you were creating a script for Windows, use WinMyTest.xml as the file name. Descriptive file names are highly beneficial when mapping the script to a group as explained later in this document. Some tests may not be compatible with a particular operating system. If you run a script against the incorrect operating system, the incompatible test in the script will log a false negative. This failure is due to the differences in operating systems instead of an actual hardware failure. Guidelines for Composing a Device Specific Test Script Use the following guidelines for composing a device specific test script. The tests used in this example were chosen specifically because the test times are short. 1. Select the supported operating system for the script by clicking the drop-down arrow. 2. Click the New button. The New Script dialog box opens. See below.
3. Type functional.xml and click the OK button. This opens the Save Script options and places a header for the script you are creating at the top of the Scripts pane. See below.
24 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
4. In the Test List, locate the available CPU test selections. Test categories are listed in alphabetical order. 5. A box with a check mark means a test will be included in the script. Under the CPU test category, select the following tests by clicking the adjacent check box. See below: a) Register b) Cache c) MMX
6. For the Hard Drive, Memory, and System Board (a.k.a motherboard) test categories, select the following tests: Hard Drive: Linear Seek, Random Seek Memory: Pattern System Board: RTC Rollover
7. When you are done selecting tests, click the Add Test button. The populated test script appears in the right pane. See below.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 25
8. Type a description for the script that helps explain its purpose in the Description field. This is different from the file name you entered earlier. 9. Click the Save link at the top of the Scripts pane. See below.
10. Click the Save link. Ensure that the text Script File Saved appears at the top right corner of the Scripts pane. See below. If you save your script successfully, you will see the following indicator (see below):
26 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
To discard any changes you have made to a test script, click the Discard Changes or Remove Selected links. To close a currently open test script, click the Close link. If you click Close without saving, you will lose your changes. Organizing Tests into Test Sets You may find it necessary to organize your test script into succinct groups of tests called test sets. For example, you may want to create a separate test set for motherboard functions. To do this, you will first need to add another test set to the script. 1. Using the functional test script example you created in the previous steps, select the RTC Accuracy Test available in the Systemboard list and click the Add Tests button. This will automatically add another test set. 2. Locate the arrow buttons to the right of the RTCRolloverTest entry in your script. See below.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 27
This will move the RTCRolloverTest down once in the test order, forming a test set with the RTC Accuracy Test. See below. Note: If a test is listed as the first test in a test set, it will move to the proceeding test set when you click the Up Arrow button. If a test is listed as the last test in a test set, it will move to the following test set when you click the Down Arrow button. Your test script pane should look like the above figure.
4. Click the Save link. The resulting script, functional.xml, is saved on the server in the following directory:
<install_directory>\Apache2\htdocs\scripts
Removing Test Selections If you need to remove tests or test sets from your script, you can do so by using the Remove Selected link. For example, if you wanted to remove the Pattern Test from functional.xml: 1. Select the Pattern Test by clicking the check mark next to the test entry. See below.
28 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
3. Repeat steps one and two for the Hard Drive, Memory, and Motherboard test sets. 4. Click the Save link. Now when you run the CoreTests.xml script on a UUT, all four test sets will begin at the same time instead of running in sequential order.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 29
4. Click the Save link. Now when you run the CoreTests.xml script on a UUT, it will run 50 consecutive times instead of just once. Several options are available for modifying script behavior by directly editing Network Factory script files. You can locate these files in:
<install_directory>\Apache2\htdocs\scripts
For more information on editing test scripts, SEE ALSO Composing PC-Doctor Network Factory test scripts on page 22.
30 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
Sample Parameter Modification The CoreTests.xml script that you created in the previous section includes two tests with parameters: the Linear Seek Test, and Random Seek Test. To adjust these parameters: 1. Click the green plus sign next to the Linear Seek Test. This will open the Add Parameter dialog box. See below.
2. In the SectorPercentToTest field, type a value you desire. This specifies what percentage of each sector the test will seek through before moving on to the next sector. 3. In the NumberOfSeeks field, type a value you desire. This specifies the total number of seeks the test will perform.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 31
4. In the MaxErrors field, type a value you desire. This specifies the total number of errors Network Factory will allow before logging a Failed test result. 5. In the StartRange field, type a value you desire. This specifies the starting point (in sectors) for the Linear Seek Test. Specifying start and end ranges for seek tests allows you to cut down on test time, and test specific areas of the drive. You can specify this as MIN (starting sector), any valid sector number, or as a percentage. 6. In the EndRange field, type a value you desire. This specifies the ending point (in sectors) for the Linear Seek Test. Specifying start and end ranges for seek tests allows you to cut down on test time, and test specific areas of the drive. You can specify this as MAX (last testable sector), any valid sector number greater than the start range, or as a percentage greater than the start range. 7. Click the Add button. The Progress Monitor will update to reflect the changes you made to the parameters. See below.
Note: For more detail on PC-Doctor test parameters, SEE ALSO PC-Doctor for Windows 5 Test Descriptions guide.
32 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
1. Run the following command on the system you want to use as the template system:
pcd uut -s <server-IP>
This command gathers the hardware configuration for the UUT and sends it to the server. Note: If using a port other than 4560 for communication between the UUT and server, specify the port number with the server IP. 2. On the Monitoring Console, click the System Info tab. See below.
This opens the System Information pane. 3. Select the system to use as the template system by clicking the System drop-down menu on the top left corner of the System Information pane. See below.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 33
5. Select items you want the Inventory Test to check against by clicking the check box next to a device name in the System Devices list. See below.
34 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
Items you check are items Network Factory will use to check against when the Inventory test is run on other systems. 6. When you are done selecting devices to include in the inventory file, scroll to the top of the System Devices list and click the Create New Inventory File button. 7. Type a name for the inventory file in the New dialog box and click the Ok button. Ensure you include the filename extension (.xml). See below. When you save the inventory file, Network Factory opens the Inventory page. From the Inventory page, you can manage all your inventory files, alter which devices inventory files check against, or provide acceptable threshold values that loosen up inventory test requirements. See below.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 35
36 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
This accomplishes two things: populates the Regular Expression Editor with the associated value (including appropriate syntax), and establishes a device association between the Regular Expression Editor and the inventory file you are editing. Note: If you provide range tolerances in the Regular Expression Editor without first establishing a device association, your changes will not be saved to the inventory file. 2. Place the curser just after the caret symbol (^) and click the PCDR Range button. See below.
This will populate the Regular Expression Editor with a PCDR Range expression. Note: All valid regular expressions begin with a caret symbol (^) and end with a dollar sign symbol ($). Tolerance values must be framed in square brackets ( [] ). 3. Remove the numeric value that was placed in the Regular Expression Editor when you clicked the device property link. Important: Do not remove specified units of measure such as KB, MB, GB and so on. Do not remove the dollar sign symbol ($) that marks the end of the regular expression. 4. You will need to adjust the x and y variables for the PCDR Range expression with appropriate range tolerance values for the device (for more information, SEE ALSO Adjusting Inventory Auditing Criteria Tolerances on page 35).
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 37
For example, if you want to provide a range tolerance of 1.0 GB to 2.0 GB for total physical memory allowed in a system, you would write the regular expression like below:
5. After you have created a regular expression, you can test it by entering a value in the Test Value field and clicking the Test button. See below.
If the value is between the specified tolerances, the Regular Expression Editor will produce a Passed result. 6. If you successfully created a regular expression, you save it to the inventory file by clicking the Save button and clicking the Save link at the top of the Inventory page. If you attempt to leave the Inventory page without clicking the Save link, Network Factory will prompt you to save your changes.
Each Device element includes a name attribute and a specified device type using a type attribute. Each property element includes a key attribute and can include an optional value attribute. Values expressed in inventory files use the Perl
38 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
Compatible Regular Expressions (PCRE) library. For more information on the PCRE library, visit http://www.pcre.org/pcre.txt. Below is an example of specified attributes:
<Inventory-Check> <Device name="AMD Athlon(tm) 64 Processor 3400+ CPU:0" type=CPU> <property key="Family"> <value value="^F H$"/> <property key="Stepping"> <value value="^0$"/> <property key="Model"> <value value="^14$"/> </Device> </Inventory-Check>
Using Logic Elements as Filters In addition to the filtering options covered in the previous sections, you can use three important logic elements to adjust inventory auditing criteria: <and>, <or>, and <not>. These elements are supported anywhere within the inventory file element hierarchy, and do the following: and When an <and> element surrounds two <Device> elements, both devices must be present as part of the matching criteria. This also applies to the <property> element. By default, the inventory script file is generated with an implied <and> element between each <Device> element. So, if you run the inventory test against a system without adjusting the inventory file first, it will look for an exact match on every device in the file. Using an <and> element to specify both devices must be present as part of the matching criteria:
<and> <Device name="AMD Athlon(tm) 64 Processor 3400+ CPU:0" type=CPU> <property key="Family"> <value value="^F H$"/> <property key="Stepping"> <value value="^0$"/> <property key="Model"> <value value="^14$"/> </Device> <Device name="AMD X2 Dualcore 64 Processor 4800+ CPU:0" type=CPU> <property key="Family"> <value value="^F H$"/> <property key="Stepping"> <value value="^0$"/> <property key="Model"> <value value="^14$"/> </Device> <and>
or When an <or> element surrounds two <Device> elements, Device #1 or Device #2 must be present as part of the matching criteria. This also applies to the <property> element. not When surrounding a <Device> element, the device should not be present as part of the matching criteria. This is a way of excluding devices from the matching criteria.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 39
< Specifies the matching criteria can be less than a specific value. Specifies any memory capacity below 256 MB is acceptable.
<property key="TotalPhysicalMemory"> <value value="^PCDR#[<256] MB$"/> </property>
>= Specifies the matching criteria can be greater than or equal to a specific value. Specifies any memory capacity above or equal to 256 MB is acceptable.
<property key="TotalPhysicalMemory"> <value value="^PCDR#[>=256] MB$"/> </property>
<= Specifies the matching criteria can be less than or equal to a specific value. Specifies any memory capacity below or equal to 256 MB is acceptable.
<property key="TotalPhysicalMemory"> <value value="^PCDR#[<=256] MB$"/> </property>
## Specifies the matching criteria can fall anywhere between two specific values. Specifies any memory capacity that falls between 128 and 256 MB is acceptable.
<property key="TotalPhysicalMemory">
40 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
Using Range Tolerance Symbols To adjust inventory auditing criteria in your inventory file using Range Tolerance Symbols: 1. Navigate to the bin directory of your build. By default, inventory files are saved to the bin directory. 2. Use any text editor to open the inventory file. 3. Modify inventory matching criteria using logic elements and regular expressions. Below is an example of a Device element for memory with an adjusted range tolerance for TotalPhysicalMemory. Any system tested with between 128 and 256 MB of memory would pass this inventory test:
<device name="System Memory" type="Memory"> <property key="TotalPhysicalMemory"> <value value="^PCDR#[128-256] MB$"/> </property> <property key="AvailablePhysicalMemory"> <value value="^42.22 MB$"/> </property> <property key="TotalVirtualMemory"> <value value="^2.00 GB$"/> </property> <property key="AvailableVirtualMemory"> <value value="^1.96 GB$"/> </property> <property key="PageFileSpace"> <value value="^617.07 MB$"/> </property> <property key="PageFileLocation"> <value value="^d:\pagefile.sys$"/> </property> </device>
5. Type a description for the script in the Description field. For example, Inventory Script. 6. Scroll down the Test List until you find the DIAGINVENTORY device category. 7. Select InventoryTest by clicking the check box next to it. See below.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 41
8. Click the Add Tests button. 9. Click the Save link. See below.
The -g option is used to generate the inventory file. The -f option is used to save the report to a file that you specify. This will generate an inventory file, listing all the devices that are part of the system configuration with the filename you specify.
42 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
When you add mappings to your Network Factory configuration, the labels you define for group, configuration, and phase appear in the Edit Mappings section. In the top left corner of the Config pane are a group of links for further refining your Network Factory configuration including adding more mappings, deleting mappings, and editing timing values. You may want to take a minute to review your defined groups, configurations, and phases from chapter two. See below.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 43
3. Click the Group field. This will place the cursor in the Group field. 4. In the Group field, type the group name you defined in chapter two and press ENTER. For example, rack1. See below.
This will populate the Group field with the label rack1. 5. Repeat step three for the Configuration field. 6. In the Configuration field, type Windows and press ENTER. See below.
This will populate the Configuration field with the label Windows. 7. Repeat step three for the Phase field. 8. In the Phase field, type Functional and press ENTER. See below.
44 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
This will populate the Phase field with the label Functional. Defining Mapping Values Before you can add your new mappings, you must define the mapping values. To do this: 1. Click the Script field to open a context menu with available scripts and select a script you want to use for this mapping. See below.
2. Repeat step one for the Inventory field. 3. Since the Inventory test will not run as part of this mapping, there is no need to define a value for it. Leave this blank. This will populate the Inventory field with a value of none. 4. Click the Add Entries button. See below.
Your new mappings are saved to the server and will appear in the Edit Mappings and Delete Mappings section. To ensure your mappings are correctly copied to the server, click the Update Mappings button. See below.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 45
Now when you connect a UUT to your Network Factory server that: Belongs to the rack1 group, and Uses a Windows configuration, and Is entering the Functional phase of testing, Network Factory will use functional.xml and will not conduct inventory testing as specified by your mappings.
Guidelines for Editing Timing Values You can modify the timing values for Network Factory by doing the following: 1. Click the Edit Timings link located on the left side of the Configuration pane. 2. Adjust the values with appropriate timings for your configuration. Timing values are expressed in seconds. See below.
46 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
Editing the Sysinfo Filter The SysInfo Filter allows you to adjust how much and what level of information a system information report will generate. If a device or category appears in the Device or Category list on the right, Network Factory will filter out that information when generating system information reports. To add devices and categories to the filter lists: 1. Click the System Info tab. 2. For System, click the drop-down menu and select the system you want to filter. 3. For View, click the Filteringlink. You can also access the SysInfo Filter by clicking the direct link from the Config tab. 4. Click the OK button. See below.
This opens a list of devices and properties with checkboxes you use to define filtering. A check in the checkbox specifies that the selected item is included in system information reports. 5. From the list of devices and properties, select items you want to include in system information reports. 6. Click the Save button. See below.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 47
From this point, when you generate a system information report, it will contain information on the devices you selected. Note: If you make changes to the SysInfo Filter but want to reconfigure the filter back to the default configuration, click the Load Default Filter link. See below.
Figure 49: Loading the default SysInfo Filter for a Linux configuration
48 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
By default, Network Factory will use TCP port 4560 and UDP port 6001 to conduct communication between the UUT and server. If you want to use a different port for this communication, include the port number when running the above command from step 2:
pcd uut -s <server-IP>:<port-number> -g rack1 -c Windows -p Functional
-id
Using the SMBIOS Serial Number as the System ID To specify a UUT system ID using the SMBIOS serial number: 1. For Linux, run the following command:
./pcd uut -s <server-IP> -id \$SMBIOS.SN
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 49
or
./pcd uut -s <server-IP> -id \$SMB.SN
You need to escape the $ with the escape symbol. If you don't escape the $, the server gets the id.SN for the system. 2. For Windows, run the following command:
pcd uut -s <server-IP> -id $SMBIOS.SN
or
pcd uut -s <server-IP> -id $SMB.SN
Using the additional label options, the command for connecting the UUT to the server would look like this:
pcd uut -s <server-IP> -g rack1 -c Windows -p Functional -a CoreTests -id $SMBIOS.SN
On the Progress Monitor, you will see the UUT with all the defined label options. See below.
50 | PC-Doctor Network Factory Administrator Guide | Installing and Running the Network Factory Client
For example:
pcd uut -s 192.168.25.212
The PC-Doctor Network Factory Client will perform license authentication before initiating testing. Once connected, the client will display brief status messages on PC-Doctor Network Factory activity. Test progress will display in the Progress Monitor window. By default, Network Factory uses TCP port 4560 and UDP port 6001 to conduct communication between the UUT and server. If you plan on using a different port for this communication, include the port number with the server IP when running the command from the previous step:
pcd uut -s <server_IP>:<port_number>
For example:
pcd uut -s 192.168.25.212:5555
PC-Doctor Network Factory Administrator Guide | Installing and Running the Network Factory Client | 51
4. Decompress the self-extracting file by doing the following: a) Change directory to where you copied the self-extracting file.
cd <install_path>
For example,
./pcd uut -s 192.168.25.212
By default, Network Factory uses TCP port 4560 and UDP port 6001 to conduct communication between the UUT and server. 2. If you plan on using a different port for network communication, include the port number with the server IP when running the command from step 2:
pcd uut -s <server_IP>:<port_number>
For example:
pcd uut -s 192.168.25.212:5555
52 | PC-Doctor Network Factory Administrator Guide | Installing and Running the Network Factory Client
The PC-Doctor Network Factory Client will perform license authentication before testing begins. Once connected, the client will display brief status messages on PC-Doctor Network Factory activity. Note: For information on configuring a DOS client, SEE ALSO Using the DOS UUT on page 111.
The above option will place all log files, scripts, debug information and so on into client1 data directory. You can specify a relative or absolute directory. When specifying this option, UUTs will not write to the current directory or any other directory except the one specified by -bd. The reason for this is to run multiple UUTs from a net-mount without having the UUTs over-write other UUT logs and scripts. Using -bd also allows you to run the UUT from read-only media. To use the -bd switch: Note: Network Factory does not support spaces in directory paths or the $NF_SYSTEM_ID flag. If the directory path must contain spaces, you will need to place the directory path between quotes. Windows: pcd uut -s <server-IP> -bd "c:\New Folder\client1" Linux: ./pcd uut -s <server-IP> -bd "/tmp/uut logs/client1" You can use the $NF_SYSTEM_ID variable with the uut command to create a log directory that is specific to the client ID. For example:
pcd uut -s <server-IP> -id client1 -bd "c:\New Folder\$NF_SYSTEM_ID"
A sub-directory called client1 is created in New Folder and Network Factory will use the new path to store log files:
c:\New Folder\client1
If you plan to use the $NF_SYSTEM_ID variable in a Linux environment, keep in mind that the $ symbol indicates an environment variable that Linux will substitute with a specified string. This means you will need to escape the $ sign when using the $NF_SYSTEM_ID variable. For example:
pcd uut -s <server-IP> -bd "/var/logs/pcd/\$NF_SYSTEM_ID
Note: When specifying path or file names, keep in mind that the following characters are invalid in most cases:
\ / " : * ? < > |
Just above the UUT, you will see six drop-down menus Group, Config, Phase, Alias, Status and Page and two fields for providing date ranges. You can use the drop down boxes to view UUT details for other UUTs based off of specified Group, Config, or Phase labels. You can also view UUT details for testing that occurred during a specific time period by specifying test date ranges. To the right, you will see test run progress bars that dynamically update as tests complete. Note: The Progress Monitor will only display 200 UUTs one page at a time. If you have more than 200 UUTs in your test environment, use the Page menu to alternate between views. On the UUT, you will see two icons. Click the green plus sign to update the system_extra table for the system (for more information on the system_extra table, SEE ALSO Managing the Database on page 75). Click the red and white icon to abort testing at anytime. When testing completes, this icon becomes a red X. Click the red X to hide or display the system in the Progress Monitor view. See below.
When all test runs complete, the Monitoring Console updates the Status field to display the overall result of the test run. See below.
Using the device links on the right, you can view individual component details. When you click one of these links, Network Factory displays a Component Summary Testing report for the specified device. This report includes a Component Information Summary and a Component Testing Summary. See below.
Note: For more information on Network Factory Reports, SEE ALSO Generating Reports on page 56.
Generating Reports
In this chapter you will find information on: Things You Should Know Before Generating a Report on page 56 Generating a Testing Overview Report on page 58 Generating a Component Overview Report on page 59 Generating a System Information Report on page 60 Generating Custom Reports on page 64 Reports offer an easy way to generate information about test runs and UUTs. When you generate a report, Network Factory will display it in a brief summary view, or a more detailed view. You can print reports by clicking the Show Printable link. See Figure 55: Testing Overview report in Summary view on page 56.
The hide link allows you to temporarily remove the specified system from the Progress Monitor view. When you click this link, Network Factory will remove the specified system from the UUT list. However, the UUT will remain visible in the Reports pane. You will notice that the hide link will turn into an unhide link. Click this link to make the specified system visible though the Progress Monitor view. The delete system link allows you to permanently remove the UUT from the Network Factory database. This includes all files associated with the UUT such as scripts, inventory files, and log files. Danger: Use the delete system link only if you want to permanently remove the UUT and all records of it from your test environment! Once you delete a UUT, all records of it are permanently lost. Network Factory will display a warning prompt if you click this link.
The System_Extra icon allows you to update the system_extra table for the specified UUT. For more information on the system_extra table, SEE ALSO Managing the Database on page 75.The System Information icon allows you to automatically generate a system information report for the specified UUT. When you click this icon, Network Factory switches to the System Info tab and displays a complete system information report for the UUT. For more information on generating system Information reports, SEE ALSO Generating a System Information Report on page 60. The Inventory File icon allows you to generate an inventory template file for the specified UUT. When you click this link, Network Factory switches to the System Info tab and displays the hardware inventory for the UUT. From here, you can select or deselect devices to include in your inventory file. Remember to save any changes you make to this file.
If you want to generate a report for an archived database, the database must be accessible. To verify an archived database is accessible: Note: For more information on archiving databases, SEE ALSO Archiving the PC-Doctor Network Factory Database on page 81. 1. Click the DBAdmin tab. 2. Under the Links menu, click the Manage Archives link. 3. Verify a green check mark appears in the Status field for the database. See below.
The Monitoring Console will display a testing overview report using the filter options you specify. When you click the System link, Network Factory displays a system testing summary and a detailed system testing report.
This allows you to generate reports for systems that were tested within a specific date range. 4. Under View, indicate if you would like to exclude systems that produced a Pass result. You can also indicate if you would like to generate the report from the main Network Factory database or a different database. 5. Under Component Type, select a component and the specific capability that component supports. 6. Click the Generate Report button. Network Factory will display a Component Overview report. See below.
2. Click the System drop-down menu. 3. Select the system you want to view. See below.
4. For View, click the link that represents the system information perspective you want to see outlined in the report. The View links allow you to view system information reports using different methods to organize the data. For example, the Device Category view lists devices in a system according to what category of device it belongs. See below.
The Device Capability view list devices in a system according to the functions the device supports. See below.
The Device Connection view list devices in a system according to its relationship with other devices. Network Factory displays this information in a collapsible tree view. A plus sign (+) next to a device in the Device Connection view indicates other devices connect to the device in a hierarchy. See below.
For the purposes of this exercise, leave the View unchanged. 5. Under Device Types, select All Device Types. See below.
6. For Property Types and Property Tiers, leave the selections unchanged and click the OK button. See below.
Network Factory will generate a system information report for the Device View, Device Types, Property Types, and Property Tiers that you specify.
Any files added to this directory will display as hyperlinks in the Custom Reports section of the Reports pane. The reports are based on PHP, a common web scripting language. You can achieve more complex integration by linking to other web servers and using ODBC to run SQL queries. To quickly familiarize yourself with custom report generation, the file ODBC_Example.php shows a simple report that uses PHP and ODBC. Other reports use the database directly using SQL queries. Caution: Please copy and rename the file and leave in the same directory. The reports should never modify the database except for calling the stored procedures in the system_extra table. For more information on the system_extra table, SEE ALSO Managing the Database on page 75. To view this report, you must perform the steps outlined in ODBC Connectivity with Firebird Database for Creating an ODBC Datasource Name. You must also add a user account with ODBC privileges. The common reports are included in: <Install_Path>\Apache2\htdocs\src For more information on adding and modifying user accounts, SEE ALSO Creating and Managing Accounts on page 72.
PC-Doctor Network Factory Administrator Guide | Managing Components through a Parts List | 65
2. Click the System info tab. 3. At the top of the page, click the Parts link. 4. Click the System drop-down menu and select the system you will use as a basis for your Parts list. See below.
66 | PC-Doctor Network Factory Administrator Guide | Managing Components through a Parts List
When you select a system, a devices list will appear on the right. 5. In the devices list, select device properties that you would like to define for the part. For example, if a system contains an AMD Athlon (tm) 64 3000+ CPU and this is a CPU requirement for other systems you test, you would check the CPU specification property in the devices list. The device properties you select are used by the Parts Verification test to determine if detected components in other systems adequately satisfy Parts list requirements. 6. When done selecting device properties, click the Create New Part button. See below.
PC-Doctor Network Factory Administrator Guide | Managing Components through a Parts List | 67
This will open a dialog window for associating a part ID with the part. 7. Type the part ID and click the OK button.
Network Factory will automatically switch to the Parts tab with the part you just created selected. The description for the part is the part ID by default, which you can change from the Parts page. For more information on modifying part details, SEE ALSO Modifying Part Details on page 68.
68 | PC-Doctor Network Factory Administrator Guide | Managing Components through a Parts List
Managing Parts
The Parts page provides features for you to manage your parts list. When you click the Parts tab, the currently loaded Parts list is shown on the left side of the page. By default, parts list files are saved as parts.xml, which are located in:
<install_directory>\Apache2\htdocs\src\parts
PC-Doctor Network Factory Administrator Guide | Managing Components through a Parts List | 69
To view the XML structure for a part, click the Show XML link. The structure will resemble the following example.
Caution: Editing XML files for Network Factory is an advanced feature. You should only edit XML manually if you have experience working with XML. To modify the details of a part, click the Edit Part button. Network Factory will switch to the part revision page where you can edit component data using regular expressions (SEE ALSO Adjusting Inventory Auditing Criteria Tolerances on page 35). See below.
70 | PC-Doctor Network Factory Administrator Guide | Managing Components through a Parts List
Note: If you save any changes to part details with the exception of the Part ID, you will create a new part revision. If you save any changes to the Part ID, you will create a new part using the properties shown.
PC-Doctor Network Factory Administrator Guide | Managing Components through a Parts List | 71
This command will download a test script defined by Network Factory mappings, the parts.xml file, the extras.xml file and runs the Parts Verification Test as the first test. At this point, the client does the following: a) Parses example_file.pf. b) Looks in parts.xml for all the part numbers found in example_file.pf. c) Pre-pends any device types defined in extras.xml to the inventory file stored in memory. d) Conducts the Parts Verification Test using the pre-pended inventory file stored in memory. The Parts Verification Test will report one of three results: Pass: All the parts found in example_file.pf were successfully found on the UUT. Also, Network Factory did not detect any extra parts defined in extras.xml. Fail: One or more parts found in example_file.pf were not found on the UUT or Network Factory detected extra parts that are defined in extras.xml. Misconfigured: A problem exists with parts.xml or extras.xml that is preventing the Parts Verification Test from running.
Figure 77: The Parts Verification Test as seen in the Progress Monitor.
Network Factory functions are granted through an account privileges tier. There are four default account privilege login accounts, which provides access to the following Network Factory functions:
Account Guest Tester Manager Account privileges View tested systems through the progress monitor and run reports. View tested systems, edit system extra information, and run reports. View tested systems, edit system extra information, run reports, gather system information, generate inventory files, create and modify test scripts, All available privileges.
Admin
Note: We recommend you change the default administrator account for security purposes.
The Monitoring Console will refresh to reflect the modifications to user privileges.
1. Click the Delete Account link or scroll to the bottom of the User Mgmt pane. 2. Select an account by clicking the check box next to the account login. 3. Click the Remove User button. See below.
The Monitoring Console will refresh to reflect that an account was deleted.
Figure 84: system_extra table access through the Progress Monitor pane.
This will open the Extra System Information window. See below.
2. Type the name of the tester in the tester field. For example, Joe Tester. 3. Type the e-mail address for the tester in the tester_email field. For example, joetester@tester.com. 4. Click the Update Record button.
3. Click the Add fields button. This will add a order_number to the system_extra table with a default value of abc123. See below.
There are three ways you can add data to the newly created field: Click the + next to the UUT system ID on the Progress Monitor or Reports pane. On the UUT, use the -e or -eo option with the pcd uut command. For more information on available command line options, SEE ALSO PC-Doctor 5 Command Line Interface Guide. Using the ODBC connection, connect directly to the database and update the field.
Updating the system_extra table using SQL The instructions below demonstrate how to use SQL to call a stored procedure that updates the system_extra table: 1. Connect through ODBC to the PC-Doctor Network Factory Database. 2. Use stored procedures:
insert_system_extra( system_id INTEGER, ...) ... refers to every field defined for the system_extra table, by default ... = tester VARCHAR(1024), tester_email VARCHAR(1024)
update_system_extra( system_id INTEGER, ...) ... refers to every field defined for the system_extra table, by default ... = tester VARCHAR(1024), tester_email VARCHAR(1024) delete_system_extra( system_id INTEGER )
Updating the system_extra table using ColdFusion The example below shows the suggested way to call a stored procedure to update the system_extra table directly using ColdFusion. The field names shown in this example (phase_1_complete, phase_2_complete, and so on) are simply sample fields. These field names will be the field names created when adding additional fields using the DBAdmin tab of the Monitoring Console.
<!--- This first example is using a standard coldfusion SQL query ---> <CFQUERY NAME="updateSystemExtra" DATASOURCE="PCDR"> EXECUTE PROCEDURE update_system_extra 94478, 'false', 'false', 'false', 'false' </CFQUERY> <!--- Second is using the suggested way to call a stored procedure ---> <CFSTOREDPROC PROCEDURE="update_system_extra" DATASOURCE="PCDR" RETURNCODE="No"> <CFPROCPARAM TYPE="In" CFSQLTYPE="CF_SQL_INTEGER" VALUE="94474" NULL="No" DBVARNAME="system_id"> <CFPROCPARAM TYPE="In" CFSQLTYPE="CF_SQL_VARCHAR" VALUE="false" NULL="No" DBVARNAME="phase_1_complete"> <CFPROCPARAM TYPE="In" CFSQLTYPE="CF_SQL_VARCHAR" VALUE="false" NULL="No" DBVARNAME="phase_2_complete"> <CFPROCPARAM TYPE="In" CFSQLTYPE="CF_SQL_VARCHAR" VALUE="false" NULL="No" DBVARNAME="phase_1_email_sent"> <CFPROCPARAM TYPE="In" CFSQLTYPE="CF_SQL_VARCHAR" VALUE="false" NULL="No" DBVARNAME="phase_2_email_sent"> </CFSTOREDPROC>
Updating the system_extra table using PHP The example below shows the suggested way to call a stored procedure to update the system_extra table directly using PHP:
$db = odbc_connect("nf5dsn", "odbc", "odbc"); if(!$db) die("could not open dsn"); // insert a new record into system_extra $sql = "EXECUTE PROCEDURE insert_system_extra 1, 'New Tester', 'NewTester@Testers.org'"; odbc_exec($db, $sql); // update the record with new information $sql = "EXECUTE PROCEDURE update_system_extra 1, 'Other Tester', 'OtherTester@Testers.org'"; odbc_exec($db, $sql); // delete the record because it is boring $sql = "EXECUTE PROCEDURE delete_system_extra 1"; odbc_exec($db, $sql); odbc_close($db);
Important: We highly recommend you perform this procedure once a week. If your test environment includes at least 50 UUTs, this procedure is required. Network Factory does the following when archiving a Network Factory database: 1. Brings the uutUploadServer down. Clients will not be able to connect after this step. 2. Runs a Backup and Restore on the production database. 3. Performs a filesystem copy of the production database to the archive database. 4. Runs the archiving scripts on the new archived database. This deletes all systems that have not been archived. These systems will remain in the production database. 5. Run the archiving scripts on the production database. This deletes all systems that have been archived. These systems are in the archived database in step 4. 6. Runs Backup and Restore on the archive database. 7. Runs Backup and Restore on the production database. 8. Brings the uutUploadServer up. Clients will be able to connect after this step. Note: For information on archiving a database, SEE ALSO Archiving the PC-Doctor Network Factory Database on page 81. Network Factory does the following when backing up and restoring a Network Factory database: 1. Takes the production database offline so that data stays consistent. Clients will not be able to connect after this happens. 2. Makes a filesystem copy of the untouched production database in case Backup/Restore fails. 3. Runs the following command: gfix -mend -full -ignore . This will prepare the production database for backup 4. Runs the following command: gbak -b. This will create the compressed backup file. 5. Runs the following command: gbak -c . This will restore the compressed backup file to a cleaned-up and optimized functional database file. 6. Overwrites the production database with the newly restored database file. 7. Brings the new production database online. Clients can now connect. Note: For more information on backing up and restoring a database, SEE ALSO Backing up the PC-Doctor Network Factory Database on page 84 The following diagram demonstrates the process flow and Network Factory database component relationships when archiving.
You can perform database maintenance manually through the Progress Monitor, command line or schedule a regular maintenance task through the Task Scheduler. For more information on scheduling a task, SEE ALSO Using the Task Scheduler on page 83. Network Factory will backup the database before and after archiving old systems. After the archiving is complete, you will find a newly created archive and a newly created backup in the following directories: For backups:
<installation_directory>\Apache2\htdocs\backups
For archives:
<installation_directory>\Apache2\htdocs\archives
Important: To avoid database corruption, the Network Factory server will halt all testing and cut off communication with UUTs until it completes the archive or backup process. If a UUT is in the middle of testing when a scheduled archive or backup/retore occurs, the UUT will continue to test until completion but will not upload the results to the server. Monitoring Console Archiving Guidelines Caution: Ensure that nothing is writing to the database file before beginning the archive process. To archive the database from the Monitoring Console: 1. Click the DBAdmin tab. 2. Under the Links menu, click the Archive Database link or scroll down to the Archive Database section. 3. For Archive Systems Tested, provide a date range for systems you would like to archive. 4. For Archive name, type a name for the archive that will display in the Monitoring Console. 5. For Archive directory, copy/paste or type the directory path to the archive. 6. Click the Begin Archive button. See below.
A warning dialog will appear pointing out that the changes you are making will influence the database schema. 7. Click the OK button to continue with the archive. An Archive Report window will open. 8. Click the Begin Archive button to complete the archive. See below.
Command Line Archiving Guidelines Caution: Ensure that UUTs are not connected to the server prior to performing this. To archive the database from the command line: 1. 2. 3. 4. 5. Open a command window on the server. Navigate to: <install_path>\apache2\htdocs\src\batches. Run the following command: archive_database.cmd Answer Yes at the prompt. Run the following command: backup_database.cmd -r The purpose of this command is to reduce the size of the main database and optimize performance. Available Archiving Command Line Options You can use the following options with archive_database.cmd: -s Archives the database in silent mode.
archive_database -s
archive_database -h
-name Provides a name for the archive that will appear in the Reports pane. This example runs archive_database.cmd using functional-10.01.07 as the archive name
archive_database -name functional-10.01.07
-from When archiving systems that were tested within a specific date range, this switch defines the start date. This example runs archive_database.cmd, archives systems that were tested between August 1st, 2007 and September 1st, 2007, and copies the archive to C:\recent_archives.
archive_database -from 08/01/2007 -to 09/01/2007 -path "C:\recent_archives"
-to When archiving systems that were tested within a specific date range, this switch defines the end date. This example runs archive_database.cmd, archives systems that were tested between August 1st, 2007 and September 1st, 2007, and copies the archive to C:\recent_archives.
archive_database -from 08/01/2007 -to 09/01/2007 -path "C:\recent_archives"
-keep This switch allows you to archive all systems except for systems tested within the last 0-52 weeks. This example runs archive_database.cmd and archives all systems tested except those tested within the last two weeks.
archive_database.cmd -keep 2
Using the Task Scheduler If you schedule an archive through the Task Scheduler, you must ensure that the task will occur at a time when no other system is connected to Network Factory. Network Factory will disconnect all running systems when the scheduled task starts. To use the Task Scheduler: Note: This feature is only compatible with XP Pro or Server 2003. 1. Scroll to the bottom of the DBAdmin pane or click the Scheduled Task link. Note: PC-Doctor recommends you use the default settings when scheduling an archive. The default settings are to archive the database every four weeks and to keep four weeks of systems in the main production database during each archive. 2. For Scheduled Time, specify the exact time you want the archive to occur. 3. For Day of the week to run, indicate the day of the week you want the archive to occur. The default is Saturday. 4. For Backup and clean database every, indicate the time interval for when this occurs. The default is every four weeks. 5. For On backup, keep in production database the last, indicate how many weeks of data to keep stored for UUTs.
The default is four weeks. Note: The first time this runs, all the systems are preserved since they are all less than four weeks old. 6. For Path for archive directory, indicate the directory path where you will save the archive. The default is: <install_directory>\PC-Doctor Network Factory Server\Apache2\htdocs\archives Using the Archive Scheduler You can setup Network Factory to automatically perform scheduled archives at regular intervals through the Archive Scheduler. 1. For Scheduled time, use the drop-down menus to define the time when the archive is to occur. 2. For Day of the week to run, use the drop-down menu to select a day of the week on which the archive should occur. 3. For Backup and clean database every, use the drop-down menu to select how often Network Factory performs database maintenance. 4. For On backup, keep in production database the last, to specify how many weeks of data to perserve in the archive. 5. For Path for archive directory, specify the directory path Network Factory will use to store archives. 6. Click the Create Windows Task button. Network Factory will automatically perform an archive of the database using the date/time/location you specify. See below.
This example will restore a backed up database (NF5.fdb) and store it in C:\recent_backups.
backup_database -d "<install_directory>\Apache2\htdocs\data\NF5.fdb" -b "C:\recent_backups"
-b Specifies the target directory path where Network Factory will store the backup. This example will restore a backed up database (NF5.fdb) and store it in C:\recent_backups.
backup_database -d "<install_directory>\Apache2\htdocs\data\NF5.fdb" -b "C:\recent_backups"
General Backup Guidelines To backup and restore the Network Factory database: 1. Open a command prompt. 2. Navigate to: <install_path>\Apache2\htdocs\src\batches 3. Run the following command:
backup_database.cmd
4. Locate the database backup in: <install_directory>\Apache2\htdocs\backups The backup will reside in a directory with the current date and time stamp. 5. Copy and paste the database backup to your NF5_BACKUPS directory. SEE ALSO Archiving the PC-Doctor Network Factory Database on page 81.
Note: If the License Server status is anything other than OK, your UUTs will not connect to the server.
Reporting an Issue
If Network Factory encounters a critical error during the course of operation, it will draw attention to the error by producing an alert with a link to the Error Report Form.The Error Report Form is accessible through the Help tab. You can use the Error Report Form to fill out detailed bug reports, attach screenshots, attach all of the applicable client log files and send it all to your PC-Doctor customer representative. Once the form is filled out, Network Factory will compile the server logs along with the form information and any additional files that have been attached into a zip file. See below.
Filling Out the Error Report Form To complete the Error Report Form: Note: All fields marked with an asterisk are required to complete the form. 1. For the Company name field, type the name of your company. 2. For the Engineer name field, type the name of the engineer who discovered the error. 3. In the Detailed description field, provide a thorough description of the error. 4. In the System information field, provide any relevant system information reports. If the error occurred on the server, provide PC-Doctor with the hardware and software configuration information for the server. If the error occurred on a UUT, provide PC-Doctor with the hardware and software information for all relevant UUTs. 5. In the Steps to reproduce field, provide a thorough step-by-step list of actions performed to produce the error. 6. For the Severity of issue/request drop-down menu, select a level of severity that matches the impact of the issue on your production environment. 7. For the Priority of issue/request drop-down menu, select a level of priority that matches the urgency of issue resolution for the error. 8. For the Script file(s) field: a) Click the Browse... button. b) Navigate to the location of diagnostic script file that was used when the error occurred.
<installation_directory>\Apache2\htdocs\scripts
c) Double-click the script file. You can include multiple script files if necessary.
Note: This field is mandatory if the error occurred on a UUT. 9. For the Client UUT log(s) field: a) Click the Browse... button. b) Navigate to the location of the UUT log file for the UUT that produced an error. c) Double-click the log file. You can include multiple log files if necessary. Note: This field is mandatory if the error occurred on a UUT. 10. For the Screenshot(s) field, attach any screenshots that help support issue resolution. Note: Screenshots of the Progress Monitor and UUT screen are mandatory when reporting UUT-specific errors. However, you may want to consider providing screenshots for sever errors too. Although screenshots are optional for server errors, they are still a valuable tool for troubleshooting. 11. Click the Proceed button. Network Factory will process the request and package all necessary files into a zip file. You will need to save the file to a location that can be reached when this file is e-mailed to PC-Doctor. Important: Do not navigate away from the page that appears when you click the Proceed button until after you have saved the Error Report Form zip package. If you do, you will lose your report and will need to repopulate the Error Report Form. See below.
Disabling Critical Error Warnings The critical warning banners at the top of the monitoring console pages can be turned off using the following procedure. This will not prevent the errors from occurring nor will it prevent the errors from logging, it will simply disable the banner warnings. To disable critical error warnings:
2. Locate the file: network_factory.properties 3. Open the file using a standard text editor. 4. Locate the parameter: nf.errors.debug The default value for nf.errors.debug is no, which enables critical error warnings. 5. Change the value of nf.errors.debug to yes. Critical error warnings will now no longer appear when Network Factory encounters a critical error. However, you can still access the Error Report Form and report issues as you normally would.
My UUTs are listed as UUT_TIMED_OUT, but the UUTs are still running.
PC-Doctor Network Factory has configuration settings for how long to wait for a UUT before declaring it as UUT_TIMED_OUT. It may be that your UUTs are slow and the time-out settings are not set high enough. Click the Configuration tab on the Monitoring Console, click on View Configuration, and look for:
[ nf.inactive.uut.timeout ] 120 [ nf.enumeration.uut.timeout ] 120
These values are expressed in seconds. Try to set these values to a higher value. To do this, edit the Network Factory properties file located here:
<install_directory>/Apache2/htdocs/properties/network_factory.properties
Can I use my own serial loopback adapter with PC-Doctor Network Factory?
PC-Doctor, Inc. recommends that you use only PC-Doctor provided loopback adapters. If you need to acquire PC-Doctor loopback adapters, please contact your PC-Doctor Customer Relationship Manager or sales representative.
Guidelines for Decreasing Test Times Using the hard drive test as an example: 1. Open the pcdrharddrive.p5m file. 2. Find the test section in this file for the test you would like to modify. 3. Find the parameters you would like to modify. 4. Open the xml script that you want to modify. 5. Open the harddrivetest.xml in:
<install_directory>\Apache2\htdocs\scripts
In this example, the surface scan test has been modified to scan a percentage of the hard drive instead of the entire hard drive. See below.
<?xml version="1.0" encoding="UTF-8"?> <Script description="Hard Drive tests" passes="1"> <TestSet description="" isParallel="false"> <Test key="LinearSeekTest" module="pcdrharddrive" capabilities="HardDrive"/> <Test key="RandomSeekTest" module="pcdrharddrive" capabilities="HardDrive"/> <Test key="FunnelSeekTest" module="pcdrharddrive" capabilities="HardDrive"/> <Test key="PatternTest" module="pcdrharddrive" capabilities="HardDrive"> <Parameter key="SystemDiskPatternTest" value="true"/> <Test key="SurfaceScanTest" module="pcdrharddrive" capabilities="HardDrive"> <Parameter key="StartRange" value="MIN"/> <Parameter key="EndRange" value="20%"/> <Parameter key="SectorPercentToTest" value="10"/> <Test key="SurfaceScanTest" module="pcdrharddrive" capabilities="HardDrive"> <Parameter key="StartRange" value="80%"/> <Parameter key="EndRange" value="MAX"/> <Parameter key="SectorPercentToTest" value="10"/> </Test> </TestSet> </Script> </Test>
</Test>
Using the same method demonstrated in the previous Q and A, you will need to change the value of the SystemDiskPatternTest parameter from false (the Pattern Test will not run on the system drive) to true (the Pattern Test will run on the system drive). See below.
<Test key="PatternTest" module="pcdrharddrive" capabilities="HardDrive"> <Parameter key="SystemDiskPatternTest" value="true"/></Test>
How do I modify the server port numbers after Network Factory is installed?
To change the license server port number look in:
<install_directory>\Apache2\htdocs\properties\network_factory.properties
Look for the following property and modify it with your license server port number:
nf.authentication.server.port = 4586
Look for the following parameter and modify it with your HTTP port number:
Listen 8080
Note: If you make changes to either of these files, you must restart the Network Factory server.
Passes indicate how many times the script will run on UUTs. This effectively increase the total amount of time the UUT will remain under test. 4. Click the Save link located at the top of the Scripts pane. The next time the script runs, it will run all the tests it contains the number of times indicated by the Passes field.
Firebird Log
<install-directory>/Firebird/firebird.log
To back up the database, first make sure that nothing is writing to it (UUTs are not running and Web-browsers are not pointing to the Monitoring Console). Once you are sure that nothing is writing to the database file, copy the file to your preferred backup destination. For more information on backing up a Network Factory database, SEE ALSO Maintaining the Network Factory Database on page 78
Selecting the ODBC Example under Reports produces the error Database Connection Failed
Guidelines for Using the ODBC Example Report To use the ODBC Example report: 1. Click the User Mgmt tab. 2. Under the Add Users section, type odbc in the User Name field. 3. Type odbc in the User Password and Re-Enter Password field. 4. Select Dbremote. 5. Click the Add User button. For more information on other user account features, SEE ALSO The User Mgmt Tab on page 72.
Where can I find more information on databases used with Network Factory?
You can find additional information through the following resources. Online Resources PHP Manual and Tutorial SQL Tutorial from www.SQLCourse.com SQL Tutorial from www.w3schools.com Firebird/Interbase Manual Available Books The Firebird Book: A Reference for Database Developers (Paperback) SQL In A Nutshell, 2nd Edition (Paperback) Sams Teach Yourself SQL in 10 Minutes, Third Edition (Paperback) PHP and MySQL Web Development (3rd Edition, Developer's Library, Paperback) Beginning PHP 5 and MySQL: From Novice to Professional (Paperback) Web Database Applications with PHP & MySQL, 2nd Edition (Paperback)
PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database | 97
Prerequisites
Before setting up ODBC connectivity, verify that you meet the following requirements: PCDoctor Network Factory installed on local server A Windows workstation where the installation takes place Microsoft Access, PHP, or other 3rd party database application.
4. Save and close the file. Note: Ensure each component in the above line is separated by at least a single space. See below.
98 | PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database
PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database | 99
This will allow you to choose a Firebird data source after the Firebird ODBC driver is installed. The data source name should be nf5dsn to enable the provided ODBC example report. 4. Provide the host IP:database in the database field. For example, if your Network Factory Server is located at 192.168.0.5, the database field would be 192.168.0.1:NF5. If you are performing this step on the system with Network Factory Server installed, you can use the actual IP of the server or the local host IP (127.0.0.1). Note: Network Factory Server installs a Firebird alias that will automatically map a database location NF5 to the physical database file. PCDoctor recommends that you use the alias in the Firebird ODBC setup instead of specifying the full database path, allowing for easy database relocation on the server. The database file is located in:
<NF5_install_directory>\Apache2\htdocs\data\NF5.FDB
Note: If installing this on a separate workstation: a) Copy and paste the fbclient.dll file to a safe location on the workstation. b) In the Client field, type the directory path where fbclient.dll is located on the workstation. 6. In the Database Account and Password fields, type any user name and password that were created through the Monitoring Console. See below.
100 | PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database
To access ODBC, you must specify a user with remote database permissions. Type the username for this account in the Database Account field, and type the password for this account in the Password field. Note: For more information on creating a remote database user account, SEE ALSO Creating and Managing Accounts on page 72. 7. Test the connection by clicking the Test Connection button. Your PC-Doctor Network Factory Server database is now accessible through ODBC connectivity.
Using MS Access
1. Open the ODBC Database in MS Access. See below.
PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database | 101
3. Choose the table you would like to have access to when working inside MS Access. See below.
102 | PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database
Caution: Ensure that you only link to the tables. You do not want to import!
After linking the tables, you are now ready to use Microsoft Access as if the database were any other locally stored database. Below is an image of the Microsoft Access query designer. See below.
PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database | 103
Using ColdFusion
To connect and query from ColdFusion Markup after the data source has been added to the Cold Fusion administrator: 1. Use the following:
<cfquery name = "myQueryName" datasource="myODBCDSN"> SELECT field, field2, field3 FROM table </cfquery>
Using PHP
To connect and query an ODBC data source from PHP: 1. Use the following:
<? $fh = odbc_connect("myODBCDSN","username","password"); if (0 === $fh) die("Could not connect to data base"); $results = odbc_exec($fh,"SELECT field1, field2 from table"); while ($row = odbc_fetch_array($fh)) echo "Field1: ".$row['field1']." Field2: ".$row['field2']."\n"; odbc_close($fh); ?>
For example:
<? $db = odbc_connect("nf5dsn","odbc","odbc"); if (0 == $db) die("Could not connect to data base"); $query = "SELECT s.serial_number, s.product, sa.alias, ts.start_date,
104 | PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database
r.result"; $query.= " FROM system s JOIN test_script ts ON s.id =ts.system_id "; $query .= " join test_result r ON r.id = ts.result_id "; $query .= " join alias sa ON sa.id = s.alias_id "; $query .= " WHERE r.id IS NOT NULL "; $results = odbc_exec($db,$query); if (FALSE == $results) die("Could not execute query"); while ($row = odbc_fetch_array($results)) { echo "<b>Test System</b><br>"; echo "Serial Number: ".$row['SERIAL_NUMBER']."<br>"; echo "Product: ".$row['PRODUCT']."<br>"; echo "System Alias: ".$row['ALIAS']."<br>"; echo "Date: ".$row['START_DATE']."<br>"; echo "Result: ".$row['RESULT']."<br>"; echo "--<br>"; } ?>
You will need to manually create the Firebird directory. See below.
PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database | 105
4. Click the Driver drop-down arrow and select Other. See below.
106 | PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database
SELECT FIRST 5 DISTINCT s.serial_number, s.id FROM system s JOIN test_script ts ON ts.system_id = s.id WHERE ts.end_date > '1/1/2005' AND ts.end_date < '2/1/2010'
Finding tested systems with a specific configuration If you want to find the first five systems by a certain configuration in the same date range, use a query like this:
SELECT FIRST 5 DISTINCT s.serial_number, s.id, c.configuration FROM system s, test_script ts, configuration c WHERE ts.end_date > '1/1/2005' AND ts.end_date < '2/1/2010' AND s.id=ts.system_id AND c.id=s.configuration_id AND c.configuration='*'
Finding values for custom fields If you want to find the first five values for a custom field called "tester" in the system_extra table for all systems, use a query like this: Note: If you specify field names for the system_extra table in SQL, you must contain them in quotes. Field names are case sensitive.
Finding device component information If you want to find all the latest properties and property values for a particular component from a given system using its component id number (component_id) and system id number (system_id), assuming component_id=1 and system_id=1, use a query like this:
SELECT p.name, pc.category, pv.property_value, pvl.component_id FROM property p, property_category pc, property_value pv, property_value_list pvl WHERE pv.id = pvl.property_value_id AND pvl.property_id = p.id AND p.category_id=pc.id AND pvl.component_id = 1 AND pvl.system_id = 1 AND pvl.test_script_id = ( SELECT MAX(test_script_id) FROM property_value_list
PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database | 107
WHERE system_id = 1 )
Finding all tests that result in Failed If you want to find the total number of test failures on each system, use a query like this:
SELECT FIRST 5 system.uut_key,count(*) AS number_failed FROM system, test_script, test_run WHERE system.id=test_script.system_id AND test_script.id=test_run.test_script_id AND test_run.test_result_id!= (SELECT first 1 test_result.id FROM test_result WHERE test_result.result='PASS') GROUP BY system.uut_key
Finding test event messages If you want to find all the test event messages for each system, use a query like this:
SELECT FIRST 5 s.uut_key, t.name, et.event_type, event_message FROM system s, test_script ts, test_run tr, test_run_event tre, test t,event_type et WHERE s.id=ts.system_id AND ts.id = tr.test_script_id AND tr.id = tre.test_run_id AND t.id=tr.test_id AND et.id=tre.event_type_id
Finding dates and test results for test script runs If you want to find the date and result for each test script executed, use a query like this:
SELECT FIRST 5 s.uut_key, sc.script_file, ts.end_date,res.result FROM system s, test_script ts, script_file sc, test_result res WHERE s.id=ts.system_id AND ts.script_file_id = sc.id AND ts.result_id = res.id
Finding the CPU speed for tested systems If you want to determine the CPU speed in megahertz for a system with a unique system ID, use a query like this:
SELECT c.product, p.name, pv.property_value FROM property p, property_value pv, property_value_list pvl,component c, capability cp, capability_list cpl WHERE pvl.property_id = p.id AND pvl.property_value_id = pv.id AND c.id = cpl.component_id AND cpl.capability_id = cp.id AND cpl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.component_id = c.id AND cp.capability='CPU'
108 | PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database
Finding hard drive size for tested systems If you want to determine the size of all installed hard drives for a system with a unique system ID, use a query like this:
SELECT c.product, p.name, pv.property_value FROM property p, property_value pv, property_value_list pvl, component c, capability cp, capability_list cpl WHERE pvl.property_id = p.id AND pvl.property_value_id = pv.id AND c.id = cpl.component_id AND cpl.capability_id = cp.id AND cpl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.component_id = c.id AND cp.capability='HardDrive' AND pvl.system_id = 1 AND p.property_key = 'TotalCapacity';
Finding the total amount of installed memory If you want to determine the total amount of installed memory for a system with a unique system ID, use a query like this:
SELECT c.product, p.name, pv.property_value FROM property p, property_value pv, property_value_list pvl,component c, capability cp, capability_list cpl WHERE pvl.property_id = p.id AND pvl.property_value_id = pv.id AND c.id = cpl.component_id AND cpl.capability_id = cp.id AND cpl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.component_id = c.id AND cp.capability='Memory' AND pvl.system_id = 1 AND p.property_key = 'TotalPhysicalMemory';
Combining queries The three previous queries could be combined into one: Note: The sub-selects for the MAX(test_script_id) ensure that you are getting the latest information.
SELECT c.product, p.name, pv.property_value FROM property p, property_value pv, property_value_list pvl, component c, capability cp, capability_list cpl WHERE pvl.property_id = p.id AND pvl.property_value_id = pv.id AND c.id = cpl.component_id AND cpl.capability_id = cp.id AND cpl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list
PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database | 109
WHERE system_id = 1) AND pvl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.component_id = c.id AND cp.capability IN ('CPU','HardDrive','Memory') AND pvl.system_id = 1 AND p.property_key IN ('SpeedEstimateTSC','TotalCapacity','TotalPhysicalMemory');
Finding what was tested on a system using a serial number The below snippet of code queries the database for a list of modules run against a system with a specific serial number. This would run into problems if a system is tested multiple times against multiple versions of tests as it would grab multiple copies of the same modules distinguishable only by the module_id numbers. With this list of modules, the code queries the database to compare the tests belonging to each module with the tests run on the system, ignoring pass, fail or abort results. It then calculates the percentage of tests run against the number of existing tests per module. To find what was tested on a system using a serial number:
<?php // Count all modules tested against a serial number $serial_number="System Serial Number";$query_modules_sql = "SELECT DISTINCT m.name, m.id FROM module as m, test as t, test_run as tr,test_script as ts, system as s WHERE s.serial_number = '$serial_number' AND s.id = ts.system_id AND ts.id = tr.test_script_id AND tr.test_id = t.id AND t.module_id = m.id";$module_result = ibase_query($db, $query_modules_sql);$rows = Array(); while( $arr = ibase_fetch_row($module_result)) array_push($rows, $arr); $module_number=count($rows); echo "<div>$module_number modules found</div>"; $module_count = 0; foreach($rows as $moduledata){ $module_name = $moduledata[0]; $module_id = $moduledata[1]; // Count all tests per modules $query_testcount_sql = "SELECT DISTINCT COUNT(*) FROM test as t WHERE t.module_id = $module_id"; $testcount_result = ibase_query($db, $query_testcount_sql); $array_result=ibase_fetch_row($testcount_result); $testcount = $array_result[0]; echo "<div>$testcount is the testcount for module $module_id $module_name</div>"; } //Count all tests run per module $query_testruncount_sql = "SELECT DISTINCT COUNT(*) FROM test_run as tr, system as s,test_script as ts, test as t WHERE tr.test_id = t.id AND t.module_id = $module_id AND tr.test_script_id = ts.id AND ts.system_id = s.id and s.serial_number = $serial_number'"; $testruncount_result = ibase_query($db, $query_testruncount_sql); $array_result = ibase_fetch_row($testruncount_result); $testruncount = $array_result[0]; $module_count = $module_count + $testruncount/$testcount; echo "<div>Testruncount is $testruncount and the module_count is $module_count</div>"; } if ($module_count != 0){ $string = "$module_count out of $module_number test modules were
110 | PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database
run on $serial_number"; } else { $string = "No modules or tests were run on $serial_number"; } echo "<div>$string</div>"; ?>
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 111
In general, the DOS UUT starts by attempting to PXE boot from a PXE server. If a DOS UUT successfully boots from a PXE server, it will download all predefined diagnostics, test script files and other necessary components. The DOS UUT then displays a menu of diagnostic choices and periodically attempts to authenticate with the LM using UDP packets. When done testing, the DOS UUT will store the logs on the TFTP server. DOS test scripts are known as overlays and are contained in PDO files. Overlays are equivalent to a standard Network Factory test script. For more information on overlays and PDO files, SEE ALSO Using Test Scripts to Automate DOS Testing on page 118. The DOS UUT sequentially runs the tests specified in the PDO file. When testing completes, the DOS UUT saves the log files on the TFTP server. The following diagram summarizes the basic DOS UUT/Network Factory server communication path.
112 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
Note: Since the DOS UUT does not communicate directly with the Network Factory server, results are not updated in real-time. Results for a DOS UUT are not reflected in the Network Factory Monitoring Console until the logs are uploaded.
Menu batch files: Note: These files can vary widely depending on your configuration.
MENU.BAT: The default menu that provides an interface to various pre-defined test selections and running system
information reports. 1.bat: Runs the diagnostics in overlay 1 of the default PDO file.
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 113
2.bat: Runs the diagnostics in overlay 2 of the default PDO file. x.bat: See above.
TFTP_ADDR, and LOG_LOC. UPDATES.CFG: A file used to define updates for a UUT. Updates are defined as file downloads the UUT will download after booting.
Workflow scripts:
_CONFIG.BAT: Performs configuration of client variables. DOSUUT.BAT: Usually launched from AUTOEXEC.BAT, this file starts the workflow. FIXSPACE.BAT: A utility script used for stripping excess spaces from the ends of environment variables such as the
serial number.
_NFFIELD.BAT: Adds the GROUP, CONFIG, PHASE and other variables to a log file based on parameters passed
into it or available as environment variables. _PARSE.BAT: Uses setenvar.exe to parse a file based on the parameters passed to it. _TIMSTMP.BAT: Sets the environment variables TIME and DATE to the current time and date. These variables can then be placed in the logfile and later used on the server to determine script times during parsing. _UPLOG.BAT: Uploads a log file to the server specified by the variable TFTP_ADDR. The log will be uploaded to the location specified by LOG_LOC and will have the filename DOSLOG__%ID%.LOG, where "%ID%" is the UUT ID specified by the variable ID. UPDATES.BAT: Parses the UPDATES.CFG file and downloads defined update componets _RESULTS.BAT: Uses PSR.EXE to parse log files and display relevant results to users. Internally contains an order of precedence to determine and display only the worst results. For example, if a test reports "Canceled" but other tests report "Fail", only the fail results are displayed.
if you plan to use the results of a test to control a workflow process. The following diagram demonstrates how a typical DOS UUT is configured and operates within a Network Factory environment.
114 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
About DOS_UUT.CFG
The DOS_UUT.CFG file is used to define the initial configuration for the DOS UUT and contains five fields. See below.
# Network Factory DOS UUT # # # DO NOT MODIFY THE HEADER OF THIS FILE! LICENSE=[192.168.31.54] TFTP_ADDR=[192.168.31.54] LOG_LOC=[DOS_LOGS\] BOOTSTRAP=[] UPDATES=[]
LICENSE: Defines the IP address for the LM on your network. This is usually the IP address of the Network Factory server.
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 115
TFTP_ADDR: Defines the IP address of the TFTP server to where the DOS UUT uploads logs. This can be a separate server than the TFTP server from which clients PXE boot. For example, you may want to run a separate TFTP server (such as TFTPD32) for log collection directly on the Network Factory server. LOG_LOC: Defines the directory where the DOS UUT should upload logs. Depending on the type of file system and the folder specified, ensure you use the correct slash or back-slash to define the file path. BOOTSTRAP: If running a custom setup with a bootstrap file, defines the name of the bootstrap file. If using the default process, leave this blank. UPDATES: Defines update components the UUT will download after booting.
4. Copy DOS_UUT.CFG to the root of the TFTP server. 5. Modify DOS_UUT.CFG. For more information on DOS_UUT.CFG, SEE ALSO About DOS_UUT.CFG on page 114.
116 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
2. On the DOS UUT, modify a DOS PDO file. For more information on modifying a PDO, SEE ALSO Using Test Scripts to Automate DOS Testing on page 118. 3. When you are done creating overlays, save the modified PDO on the TFTP server and use the update feature to have the UUT downaload the modified PDO. For more information on the updates feature, SEE ALSO Supporting UUT Updates on page 116. Note: Alternatively, you can save the PDO inside the diagnostic image for the DOS disk image on your TFTP server. Ensure you replace the already present PCDR.PDO file. 4. On the Network Factory server, create a Group/Configuration/Phase mapping (Group=DOS, Config=*, Phase=*). Specify the PDO file name (PCDR.PDO) as the script in your mapping. For more information on creating a mapping, SEE ALSO Implementing Your Network Factory Integration on page 22. 5. Click the Add Entries button. You will see the PDO file name in the Mappings section of the Config pane. 6. On the Network Factory server, copy your modified PDO or create an empty file called PCDR.PDO and place it in the Scripts directory located at:
<install_directory>\apache2\htdocs\scripts
Specify files to download after boot using the Updates feature. This is the easiest method. Use a bootstrap, create replacement files and store them on the TFTP server and/or in the image.
Caution: Do not modify the file header! You can use the Updates feature to automate tasks such as downloading an updated PDO file. If you want to add, remove or change the PDO file, you simply place the modified version on the TFTP server and specify the path and filename in the UPDATES.CFG file.
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 117
The UPDATES.CFG file itself must reside in the root of the TFTP server. (the same location as your DOS_UUT.CFG file). Downloadable files can reside in a sub-directory on the TFTP server. Example of Using Updates Feature In this example, the PCDR.PDO file and the MENU.BAT have been updated to change the tests assigned for one menu option. The modifed files are placed in the UUT directory on a Linux TFTP server. The UPDATES.CFG file is in the root directory of the TFTP server. The file DOS_UUT.CFG has been updated to specify this file. The modifed DOS_UUT.CFG.
# Network Factory DOS UUT # # # DO NOT MODIFY THE HEADER OF THIS FILE! LICENSE=[192.168.29.16] TFTP_ADDR=[192.168.31.22] LOG_LOC=[DOS_LOGS/] BOOTSTRAP=[] UPDATES=[UPDATES.CFG]
Using a Bootstrap
If a BOOTSTRAP file is specified in DOS_UUT.CFG, this file is downloaded after configuring the UUT and downloading any specified updates. The bootstrap is then given full control of the UUT. This is one method of modifying the DOS UUT and makes it possible to completely re-design the test process without the need to modify the DOS image. Sample Basic Bootstrap Procedure A simple bootstrap file might do the following. 1. Download a replacement PDO file to use instead of PCDR.PDO. 2. Download alternate batch files to replace 1.bat, 2.bat, 3.bat and so on. You could alternately download these files using the UPDATES features. 3. Run menu.bat in a loop to call the newly downloaded files. Sample Advanced Bootstrap Procedure A more complex bootstrap file might do the following. 1. Determine the type of system based on: MAC, SN or IP which are listed as environment variables. OR Use setenvar.exe to obtain product name from the SMBIOS information.
For example:
PCDR.EXE /SI:18 | SETENVAR.EXE PRO
118 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
2. Change ID of the system based on the type of the system or the Serial number. Note: The default ID is the MAC address. 3. Based on the type or ID of the system, download a batch file specific to this type or ID. This specific batch file could then: a) Download other files needed for testing this specific unit. b) Start a test overlay (from PDO) running automatically or present a menu for the technician. 4. Finally upload result logs either between running scripts or upload all logs at the completion of testing.
The DOS proxy is responsible for setting the default values for Group, Configuration, and Phase. The values for Group, Configuration, and Phase are initially set to *, then set to the values defined in proxy.p5i if they exist, then set to the values defined in the DOS log if they exist. The DOS proxy is also responsible for defining the polling method. The three polling options are No polling, Local Machine logs, and Network Mount logs.
Table 3: DOS Proxy Polling Options Polling Method No polling Description On install, DOS proxy is in this state with "Network Mount logs" and "Local Machine logs" sections of proxy.p5i commented out. This effectively turns off the polling capability of DOS proxy. To set DOS proxy to poll a local directory for DOS log files, uncomment the section "Local Machine logs" in proxy.p5i. You will then need to define the directory paths where the DOS proxy will look for logs. To set DOS proxy to mount and poll a network directory for DOS log files, uncomment the section "Network Mount logs" in proxy.p5i. You will then need to define the network paths where the DOS proxy will look for logs.
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 119
6. Select a slot to save the overlay and press ENTER. 7. Provide a name or description for the overlay in the Save dialog and press ENTER (the name or description can not exceed eight characters).
Integrating a Custom Test Overlay into your Network Factory Test Environment
Use the following guidelines for successfully integrating custom test overlays into your test environment. 1. Copy your PDO file to a floppy disk or other storage media. 2. Copy the modified PDO to the TFTP server and modify your updates file to include the modified PDO. Alternatively, you can manually copy the modified PDO directly to the image. If you plan on developing and using multiple PDO files, rename the file using a descriptive filename that indicates the purpose of the PDO.
120 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
3. In the Network Factory web interface, browse to the Config tab and create a mapping for the PDO file. Be sure to specify the PDO name correctly including the .PDO extension. Note: Unlike Windows and Linux UUTs, DOS does not download the PDO (test script) from the Network Factory server. The PDO must be contained in the image or downloaded from the TFTP server. For more information on mapping scripts, SEE ALSO Modifying PC-Doctor Network Factory Configuration on page 41. 4. On the Network Factory server create a place holder file in the scripts directory (PCDR.PDO). By default, the scripts directory is located in <install_directory>\Apache2\htdocs\scripts\ Note: The place-holder file is required in order for the DOS UUT to retrieve the PDO file.
Known Issues and Workarounds for Network Factory server and DOS Proxy Communication
The following known issues currently exist for Network Factory servers configured to communicate with a DOS proxy server.
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 121
There are four methods to launch tests from the command line using switches. A space must precede the forward slash that begins each switch. You can use up to 128 characters on a single command line, allowing a variety of switch combinations:
ba:xx: Use this switch to run one of the 10 test sets stored in the test overlay file: PCDR.pdo.
Note: This switch cannot be used in combination with any other ba, ms or rt switch.
ms:xx: Use this switch to run the Maximum System Load for xx minutes.
Note: This switch cannot be used in combination with any other ba, ms or rt switch.
rt:nn: Use this switch to run the specified test with the ID nn. au:fname: Use this switch to specify a script file to run in automated scripting mode.
The rt:nn switch supports up to 10 different rt:nn switch combinations on a single command line, but you can only specify one test category for each rt:nn switch. The au:fname switch runs an automated scripting mode and cannot be combined with other ba, ms, or rt switches. In addition, there are restrictions for using the au:fname switch. This switch specifies a custom ini file you create, including options and parameters you would include on the command line. The following sections detail the available command line switches and provide examples for command line switch use.
122 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
This switch will run all the tests in the CPU/Coprocessor Test Category (cpu&*).
pcdr /rt:cpu&*
rt:nn,x This switch allows the user to specify which device to test. The variable nn represents the test category or subtest to run. The variable x is an integer that identifies the device, where 0 is the first device, 1 is the second and so on. This switch will run the hard disk seek test (hd&4) on the first hard drive (0).
pcdr /rt:hd&4,0
rt:nn/x This switch would run the hard disk seek test (hd&4) on the first and third hard drives (5=00000101).
pcdr /rt:hd&4/5
For more information on bit masks, SEE ALSO Determining and Using Bitmap Values on page 139. Supported Test IDs Diagnostics are generally broken down into individual subtests, with each subtest designed for testing various aspects of a hardware component. Each subtest has a specific test ID which is used to identify which test to run when launched from a command line. The following is a list of diagnostic categories and test IDs supported by the rt:nn, /rt:nn,x and rt:nn/x command line switches. Note: Only one test ID per each use of the switch is supported.
Table 4: CPU and Coprocessor Test IDs Test Name CPU Registers CPU Arithmetics CPU Logical Operations CPU String Operations CPU Interrupts/Exceptions CPU Buffers/Cache CPU C&T/Cyrix Specific CoProc Registers CoProc Commands CoProc Arithmetics CoProc Transcendental Test ID CPU&1 CPU&2 CPU&3 CPU&4 CPU&5 CPU&6 CPU&7 CPU&8 CPU&9 CPU&10 CPU&11
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 123
Test Name CoProc Exceptions CoProc Cyrix/IIT MMX Test CPU Miscellaneous Operations Table 5: Memory Test IDs Test Name Fast Pattern Fast Address Medium Pattern Medium Address Heavy Pattern Heavy Address Bus Throughput Code Test Advanced Pattern Test Memory Fault Test Address Fault Test Random Pattern Test Short Advanced Pattern Test Extended Advanced Pattern Test Table 6: Systemboard Test IDs Test Name System Timer BIOS Timer IRQ Controller DMA Channels RAM Refresh RTC Clock CMOS RAM Keyboard External Cache PCI PCMCIA
Test ID MEM&1 MEM&2 MEM&3 MEM&4 MEM&5 MEM&6 MEM&7 MEM&8 MEM&12 PCDMEM&1 PCDMEM&2 PCDMEM&3 PCDMEM&4 PCDMEM&5
Test ID MB&1 MB&2 MB&3 MB&4 MB&5 MB&6 MB&7 MB&8 MB&9 MB&10 MB&11
124 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
Test Name PCMCIA External Loop USB Port USB Port External Loop (front) USB Port External Loop (rear) Table 7: Video Adapter Test IDs Test Name Video Memory Video Pages VGA Controller Registers VGA Color-DAC Registers VESA Full Video Memory Test Video Memory (non-linear) AGP PCI Express Video Memory Video Pages VGA Controller Registers VGA Color-DAC Registers VESA Full Video Memory Test Video Memory (non-linear) AGP Table 8: Serial Port Test IDs Test Name Registers And Interrupts Internal Loopback External Loopback FIFO Buffers (16550A) Registers And Interrupts Internal Loopback External Loopback FIFO Buffers (16550A) Registers And Interrupts Internal Loopback Test ID COM&1 COM&2 COM&3 COM&4 COM&1 COM&2 COM&3 COM&4 COM&1 COM&2 Test ID VID&1 VID&2 VID&3 VID&4 VID&5 VID&9 AGP&1 AGP&2 VID&1 VID&2 VID&3 VID&4 VID&5 VID&9 AGP&1
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 125
Test Name External Loopback FIFO Buffers (16550A) Registers And Interrupts Internal Loopback External Loopback Table 9: Parallel Port Test IDs Test Name Command And Data Port External Loopback And IRQ Table 10: Fixed Disk Test IDs Test Name Controller Hi-Low Seek Funnel Seek Track To Track Seek Random Seek Linear Verify Random Verify SMART Test Read Test (Surface Scan) Write/Verify (Surface Scan) Write/Read (Surface Scan) SMART Self-Test Short SMART Self-Test Long Inner/Outer Surface Read Full Surface Read Table 11: Diskette Drive Test IDs Test Name Hi-Low Seek Funnel Seek Track To Track Seek Random Seek
Test ID HD&1 HD&2 HD&3 HD&4 HD&5 HD&6 HD&7 HD&8 HD&9 HD&10 HD&11 HD&12 HD&13 HD&14 HD&15
126 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
Test Name Linear Verify Random Verify Linear Write/Read Linear Write/Random Read Hi-Low Seek Funnel Seek Track To Track Seek Random Seek Linear Verify Random Verify Linear Write/Read
Test ID FD&5 FD&6 FD&7 FD&8 FD&1 FD&2 FD&3 FD&4 FD&5 FD&6 FD&7
Danger: The Linear Write/Read and Linear Write/Random Read tests will destroy any data already on the floppy disk. Use only a newly formatted disk for these tests.
Table 12: Other Devices Test IDs Test Name Sound Blaster Sound card test CAS Diagnostic Stacker CD-ROM/DVD CD-ROM/DVD LS-120/240 Drive SCSI Asset ID Alert on LAN Year 2000 Test DIMM/RIMM EEPROM ID SMBUS Hardware Monitoring Temperature Monitoring Table 13: Interactive Test IDs Test Name Keyboard Keys Test ID I_KBD&1 Test ID MSC&1 SBTEST&1 MSC&2 MSC&3 MSC&4 CDTEST&1 LS12TEST&1 MSC&5 RFIDTEST&1 AP_TEST&1 Y2KTEST&1 DIMMTEST&1 SMBTEST&1 LM80TEST&1 LM75TEST&1
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 127
Test Name Keyboard LED's Keyboard Repeat Video Character Set Video Color Palette Video Monitor Quality Video Mode Internal Speaker Mouse Test Diskette Change Signal Diskette Write Protect CD-ROM/DVD Open Tray CD-ROM/DVD Close Tray CD-ROM/DVD Drive Capabilities CD-ROM/DVD Reset Test CD-ROM/DVD Linear Scan CD-ROM/DVD Random Scan CD-ROM/DVD Funnel Scan Joystick Test Maximum load test Printer Test SCSI Devices Test Stereo Speaker Test LCD Panel Test USB Loopback Test Table 14: Zip Drive Test IDs Test Name Controller Hi-Low Seek Funnel Seek Track To Track Seek Random Seek Linear Verify Random Verify
Test ID I_KBD&2 I_KBD&3 I_VID&1 I_VID&2 I_VID&3 I_VID&5 I_SPKR&1 I_MOUSE&1 I_DSK&1 I_DSK&2 I_CDR&1 I_CDR&2 I_CDR&3 I_CDR&4 I_CDR&5 I_CDR&6 I_CDR&7 I_JOY&1 I_MSL&1 I_PRN&1 I_SCSI&1 I_SND&1 I_LCD&1 I_USB&1
128 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
Test Name Eject Disk Table 15: SCSI Fixed Disk Test IDs Test Name Controller Hi-Low Seek Funnel Seek Track To Track Seek Random Seek Linear Verify Random Verify Read Surface Scan Write Surface Scan Table 16: CD-Rom/DVD Drive Test IDs Test Name CD-ROM/DVD Linear Seek CD-ROM/DVD Random Seek CD-ROM/DVD Funnel Seek Table 17: CD-RW/DVD-RW Drive Test IDs Test Name ATAPI CD-RW Drive ATAPI DVD-RW Drive ATAPI DVD+RW Drive ATAPI DVD-RAM Drive
Test ID ZIP&8
Test ID SHD&1 SHD&2 SHD&3 SHD&4 SHD&5 SHD&6 SHD&7 SHD&8 SHD&9
This is an example of how to run all of the non-interactive CPU tests, followed by the Memory Heavy Address test:
pcdr /rt:cpu&* /rt:MEM&6
This is an example of how to run the non-interactive CPU test (CPU Registers), all the interactive keyboard tests and the interactive Diskette Write Protect test.
pcdr /rt:cpu&1 /rt:i_kbd&* /rt:i_dsk&2
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 129
You can also use the au:fname switch to start the script from a specified point. This example will run test001.ini and start the script on line number 10.
pcdr /au:test001.ini,10
Note: For a list of available switches to use with the au:fname command line switch, SEE ALSO The ba:xx and ms:xx Command Line Switches on page 121.
The following switches are ignored when used with the au:fname switch:
eo fd:x,y,z he np
an Enables automatic test log numbering. PC-Doctor will automatically track the sequential order of log files by adding an incremental entry to a PCDR.NUM file. You can edit this file using any standard text editor. PC-Doctor will automatically increment a test log number if the file PCDR.NUM exists (if you have previously used the an switch). To disable this feature you must delete the PCDR.NUM file.
130 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
This example runs all of the CPU tests, logs the results into test1.log and automatically increment the PCDR.NUM file.
pcdr /rt:cpu&* /pr:c:\test1.log /an
ci Assigns an IRQ number for a particular COM port address (expressed in hexadecimal). Up to 8 such addresses are allowed, with a comma separating the COM port address and the IRQ number. A colon separates each COM port address that is specified. Note that COM1 and COM2 are not affected because they are hard coded to use IRQ4 and IRQ3 respectively. The syntax is:
/ci:<HexAddress1>,IRQ:<HexAddress2>,IRQ
This example forces COM port with address 3F8H to use IRQ5.
pcdr /ci:3F8,5
This example forces COM port 3F8H to use IRQ5 and 2E8H to use IRQ11.
pcdr /ci:3F8,5:2E8,11
dj This switch will force Joystick tests to use direct joystick I/O. This will force the test to read joystick status and position directly from the hardware even if the BIOS has functions for the same purpose. This bypasses bugs in some BIOSes and problems that occur with EMM386 on some laptop systems. In some systems, the test will automatically select the use of direct joystick I/O. For those systems, this switch forces the test to disable direct joystick I/O. This example runs the Interactive Joystick test, displaying the position and status information on-screen, which is read directly from the hardware.
pcdr /rt:I_joy&1 /dj
eo If enabled, the test log will only include results for tests that fail. You can use this switch to bypass Passed and N/A test results in order to produce shorter test logs. This example command line runs all the hard drive and floppy drive tests, and records test results for all tests that produce a Failed result in the testlog.log file.
pcdr /rt:hd&* /rt:fd&* /pr:testlog.log /eo
Note: This switch will not filter out N/A or Passed test results that display a warning or informational message.
fd:x,y,z This switch enables you to specify tracks to test in the Linear Verify Test. The variables x,y,z are track numbers specified as decimal values in the range 0-79. You can specify track numbers in any order. You can specify as many tracks as you wish but cannot exceed 256 characters on one line.
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 131
This example will run the Linear Verify test on diskette tracks 0, 12, 34, and 67.
pcdr /rt:fd&5 /fd:0,12,34,67
fnmi This switch forces the memory test to report Failed on any nonmaskable interrupt (NMI). An NMI is issued to the microprocessor only in disastrous circumstances, such as severe memory corruption. Without this switch, if a NMI is caused by a memory parity error, the test will log as Failed and record the number of unexpected NMIs generated. ft:n This switch indicates a failure threshold. This is used with DOS DAPI test modules to indicate the failure level to apply. The variable n sets a failure threshold between 0 and 9 and passes this value to an external DOS DAPI module. For further details, please check the DOS DAPI specification, or SDK. he This switch enables halt-on-errors mode. If a test fails, it prompts the user to indicate if it should continue or abort testing. In this example, all of the hard drive tests will run but will stop and prompt the user if any test fails. If all tests pass, the test results are logged in test11.log.
pcdr /rt:hd&* /pr:test11.log /he
id:nnnn This switch adds the text string nnnn to the top of the test log for identification purposes. If you want to use spaces in the text string, you must encapsulate the entire switch in quotes. This example will run all of the video adapter tests and will display the string Video Device Log at the top of the log.
pcdr /rt:vid&* "/id:Video Device Log"
mr:type:start:end This switch specifies the memory type and the memory range to be tested. The memory range must be valid. If you specify incorrect memory range values, the test display the error as incorrect values in both hexadecimal and decimal and will exit.
Table 18: Memory Range Switch Components Switch Component type Description Specifies the type of memory for which to set the range. Supported values are: start end B: Specifies base memory X: Specifies legacy memory P: Specifies expanded memory U: Specifies upper memory
Specifies the new starting memory location in hexadecimal. Specifies the new ending memory location in hexadecimal.
132 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
This command line runs the Fast Pattern Memory Test on the first available memory module for base memory in the range 0000 to 9FFF.
pcdr /rt:mem&1,0 /mr:b:0000:9FFF
In rt:mem&n,x, if you do not specify the value for x, the test attempts to run on all available memory modules. The following charts show you what you must code on the command line to test different ranges of memory
Table 19: Command Line Arguments for Testing Different Ranges of Base and Legacy Memory Test Fast Pattern Fast Address Medium Pattern Medium Address Heavy Pattern Heavy Address Bus Throughput Code Test Base rt:mem&1,0 /mr:b:xxxx:xxxx rt:mem&2,0 /mr:b:xxxx:xxxx rt:mem&3,0 /mr:b:xxxx:xxxx rt:mem&4,0 /mr:b:xxxx:xxxx rt:mem&5,0 /mr:b:xxxx:xxxx rt:mem&6,0 /mr:b:xxxx:xxxx rt:mem&7,0 /mr:b:xxxx:xxxx rt:mem&8,0 /mr:b:xxxx:xxxx Legacy rt:mem&1,1 /mr:x:xxxx:xxxx rt:mem&2,1 /mr:x:xxxx:xxxx rt:mem&3,1 /mr:x:xxxx:xxxx rt:mem&4,1 /mr:x:xxxx:xxxx rt:mem&5,1 /mr:x:xxxx:xxxx rt:mem&6,1 /mr:x:xxxx:xxxx - - - - - - - rt:mem&8,1 /mr:x:xxxx:xxxx
Table 20: Command Line Arguments for Testing Different Ranges of Expanded and UMB Memory Test Fast Pattern Fast Address Medium Pattern Medium Address Heavy Pattern Heavy Address Bus Throughput Code Test Expanded rt:mem&1,2 /mr:p:xxxx:xxxx rt:mem&2,2 /mr:p:xxxx:xxxx rt:mem&3,2 /mr:p:xxxx:xxxx rt:mem&4,2 /mr:p:xxxx:xxxx rt:mem&5,2 /mr:p:xxxx:xxxx rt:mem&6,2 /mr:p:xxxx:xxxx rt:mem&7,2 /mr:p:xxxx:xxxx rt:mem&8,2 /mr:p:xxxx:xxxx UMB rt:mem&1,3 /mr:u:xxxx:xxxx rt:mem&2,3 /mr:u:xxxx:xxxx rt:mem&3,3 /mr:u:xxxx:xxxx rt:mem&4,3 /mr:u:xxxx:xxxx rt:mem&5,3 /mr:u:xxxx:xxxx rt:mem&6,3 /mr:u:xxxx:xxxx rt:mem&7,3 /mr:u:xxxx:xxxx rt:mem&8,3 /mr:u:xxxx:xxxx
ms:xxxx This switch runs a batch-mode Maximum System Load Test for xxxx minutes. The number of minutes must be in the range of 2-9999. The Maximum System Load Test will automatically start and exit when complete. At the end of testing, one of the following ERRORLEVEL return codes is returned: 0 = Errors were not detected 1 = One or more errors were detected 2 = Testing was canceled by the user Note: Refer to your DOS documentation on how to use the ERRORLEVEL feature for branching in batch files.
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 133
na2f This switch will force a test to log as Failed if it is unable to detect the appropriate device. This example runs the Floppy Diskette Hi-Low Seek test and logs the results in testlog.log. If the test is unable to detect an installed floppy diskette drive, it logs as Failed.
pcdr /rt:fd&1 /pr:testlog /na2f
ncd This switch will configure optical disc tests to not recognize CD-ROMs. If you use this switch, you can not run CD-ROM tests. You may need to use this switch if you are attempting to test DVD drives and want to limit acceptable test media to DVD discs only. This example will run the CD-ROM/DVD Linear Seek test and log the results in testlog.log. If the user attempts to run the test using a CD-ROM disc, the test will not recognize the disc.
pcdr /rt:msc$7 /pr:testlog /ncd
nf This switch disables floppy drive detection, allowing you to save test time or narrow the focus of testing. When this switch is used, all floppy drive detection and tests are disabled. This example runs the CD-ROM/DVD test and logs the results into testlog.log.
pcdr /rt:msc&4 /pr:testlog /nf
nn This switch disables enumerating network cards. Use this if your system hangs while enumerating network cards. This example disables enumeration of network cards, runs all of the serial port tests, and logs the results into testlog.log.
pcdr /rt:com&* /pr:testlog /nn
nomouse This switch disables mouse functionality. This example disables enumeration of pointing devices, runs all of the serial port tests and logs the results into testlog.log.
pcdr /rt:com&* /pr:testlog /nomouse
np This switch disables all user dialog prompting. When a test prompts the user for a response, all testing is paused until the user responds to the prompt. This switch makes unattended automated testing possible.
134 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
This example will run test overlay #1, disabling all prompting and log the results into testlog.log.
pcdr /ba:01 /pr:testlog /np
nps2m This switch disables BIOS calls that attempt to determine the presence of a PS/2 mouse. Some BIOSes have bugs that might otherwise cause the system to hang. This switch is automatically used if the system has a Phoenix BIOS. This example disables the BIOS calls to determine the presence of a PS/2 mouse, runs all of the parallel port tests and logs the results into testlog.log.
pcdr /rt:lpt&* /pr:testlog /nps2m
ns This switch disables enumeration of sound cards. This example disables enumeration of sound cards, runs the modem test and logs the results into testlog.log.
pcdr /rt:msc&6 /pr:testlog /ns
nsc This switch disables enumeration of SCSI cards. This example disables enumeration of SCSI cards, runs the modem test and logs the results into testlog.log.
pcdr /rt:msc&6 /pr:testlog /nsc
nv This switch bypasses an internal virus check on PCDR.exe when it is initially launched. This example disables checking for internal viruses, runs all the hard drive tests and sends the results to testlog.log.
pcdr /rt:hd&* /pr:testlog /nv
ol:xx This switch will load a test overlay where xx specifies a value of 1-10 (up to 10 overlays are stored in the PCDR.PDO file). When you run this switch, the main screen appears but the overlay does not immediately run. If you then go to any diagnostic test and press F5, the overlay you specified on the command line will run. This example will run overlay #7 when you press the F5 key from the Diagnostic window.
pcdr /ol:07
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 135
pc:xx This switch defines a test pass count ranging between 1-9999 as specified by the xx variable. Upon completion, the test will re-run for the indicated number of passes. This example will run all the hard drive tests 100 times and log the results into testlog.log.
pcdr /rt:hd&* /pr:testlog /pc:100
This switch can also be used with script files and will repeat the script the number of times indicated. This command line will run the entire script file config001.ini four times.
pcdr /au:config001.ini /pc:4
pi:n This switch specifies a directory path where ini files are stored. If a test is unable to locate an ini file in the specified directory path, it looks in the default directory. This switch must be used every time you run tests from the command line if your ini files are in a different directory from the default directory. This example will look in the directory c:\otherdir for the ini file associated with the cpu tests.
pcdr /pi:c:\otherdir /rt:cpu&*
pr:nnnn This switch configures a test to record all test log information in a log file. The filename is specified by the variable nnnn. The test will automatically send test results to the file nnnn. The name of the file can optionally include a path. When you send the results to a file, this file can be viewed in any text editor and printed out. Note: If you do not specify a filename extension for your log file, the test will save the log as a plain-text file without a file extension. You can still use any standard text editor to view a log file. However, if you plan on viewing the log file on a Windows-based system, you will need to append a txt filename extension to the filename. This example runs all the hard drive tests and records the results to testlog.txt.
pcdr /rt:hd&* /pr:testlog.txt
pause This switch allows the user to interact with system info reports. This example will run Memory Info and PCI Info system information reports and cause the GUI window to appear.
pcdr /si:2 /si:15 /pause
ri:fn&tn This switch launches external test modules (PDI files) from the command line, where fn is the name of the PDI file and tn is the subtest to run. You can only run one external module at a time and cannot run them in combination with other tests.
136 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
This example will launch the external module LED.PDI and run all tests.
pcdr /ri:led.pdi&*
You can also use this switch to run specific tests from an external module. This example will launch the external module LED.PDI and run the second available test.
pcdr /ri:led.pdi&2
ri:nnn This switch launches external test modules (PDI files) from the command line, where nnn is the name of the PDI file either with or without the file extension. You can only run one external module at a time. You can combine this switch with rt:nn on page 121 and np on page 133. This example will run the PDITEST external module and record the results to the test log file testlog.txt. The test log file will also report that np was not set.
pcdr /ri:PDITEST /pr:testlog.txt
This example will do the same as the previous example, but the test log file, testlog.txt, will now report that np was set.
pcdr /ri:PDITEST /pr:testlog.txt /np
si:xx This switch will generate the system information report which corresponds to Hardware Info menu items as specified by xx. The supported values for xx is determined by the available Hardware Info menu selections. The value 1 represents the first item in the menu, 2 represents the second and so on. If a value for xx is not specified, the system information report will default to using the 1st available menu selection. This example runs the system information module which corresponds to menu selection #2 on the Hardware Info menu and records the results in testlog.log.
pcdr /si:02 /pr:testlog.log
You can also run multiple system information reports using multiple instances of the si switch on one command line. This example will generate separate system information reports for items #1 and #2 on the Hardware Info menu, and save the output to the file Info.log.
pcdr /si:1 /si:2 /pr:info.log
Note: The System Info reports are generated in the order specified. Redundant switches are not ignored and will generate duplicate reports if the same switch is used more than once.
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 137
sl:n This switch will start the program in the language specified by the variable n, where n specifies a numeric language code. The language codes are:
Table 21: Available Language Codes Language Simplified Chinese Dutch French German Italian Japanese Portuguese Spanish Traditional Chinese Code 2 4 7 8 14 15 18 20 24
st This switch will force a test to report all hardware bugs. When this switch is enabled, all devices that a test determines has a known hardware defect is noted in the test log as Failed. If a hardware defect is found when this switch is enabled, it does not mean the equipment is defective. The hardware in question may contain a bug which does not hinder its performance. This example runs all the hard disk tests and records the results in testlog.log. If a hardware defect is found on the hard disk, the recorded test result is Failed.
pcdr /rt:hd&* /pr:testlog1.txt /st
stl:xx This switch specifies the amount of RAM to reserve for use with the test log buffer as specified by the variable xx. Supported values range from 7,000 to 32,000 bytes. You can use the Memory contents system information module to verify the available memory for use. This example will reserve 15,000 bytes of RAM for the test log buffer:
pcdr /stl:15000
tm:nn This switch defines the minimum test time for tests and scripts run from the command line specified by the variable nn. If a test has not finished when the specified time has elapsed, it will complete before exiting back to DOS.
138 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
When using this switch with script files, any specified passcount defined by the iPasscount parameter in the script is ignored. This switch cannot be used with pc:xx on page 135. When tm:nn on page 137 is used with a script file, the minimum time specified applies to each test set defined in the ini file. When the pc switch is used with a script file, the entire script file runs for the specified number of times. This example runs all of the cpu tests for a minimum of ten minutes and records the results in testlog.log.
pcdr /rt:cpu&* /pr:testlog.log /tm:10
This example runs the script file Script.ini and repeats each test set it defines for 10 minutes. The first test set runs for 10 minutes then the second test set runs for 10 minutes and so on.
pcdr /au:script.ini /tm:10
This example runs all the CPU tests until 10 minutes have elapsed. The final test will finish its run before exiting back to DOS.
pcdr /rt:cpu&* /tm:10
This example alternates running all the subtests of the CPU test set and the Track to Track Seek subtest of the Fixed Disk test set until 20 minutes have elapsed. After 20 minutes have elapsed, the currently running tests (from both sets) will finish their runs before exiting back to DOS.
pcdr /rt:cpu&* /rt:hd&4 /tm:20
tmx:y This switch will run a test set from a script file ranging from 1-9 specified by the variable x. The tests will run for the amount of time specified by the variable y. In the script file, the names of the test sets do not matter. The first test set following the RUN command in the script file is always test set one and the second test set following RUN is always test set two and so on. This switch supports up to nine test sets on one command line. After the specified time has elapsed, the test currently in progress will finish its run before exiting back to DOS. When using this switch with script files, any specified passcount defined by the iPasscount parameter in the script is ignored. This example runs the script file script.ini and repeats test set one for 10 minutes. All other test sets defined in the script file run the number of passes specified with the iPasscount parameter in the script.ini file.
pcdr /au:script.ini /tm1:10
This example runs the script file script.ini and repeats test set one for 10 minutes, test set two for 20 minutes and test set three for 25 minutes. All other test sets defined in the script file run the number of passes specified with the iPasscount parameter in the script.ini file.
pcdr /au:script.ini /tm1:10 /tm2:20 /tm3:25
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 139
This example runs the script file script.ini and repeats test sets one and two for 10 minutes each and test set three for 15 minutes. All other test sets defined in the script file run for 10 minutes each as specified by /tm:10.
pcdr /au:script.ini /tm:10 /tm3:15
tx:n This switch defines the maximum test time for tests and scripts run from the command line specified by the variable n. If a test has not completed in the specified amount of time, the test aborts and records Failed in the test log. This example runs the sixth test of the Fixed Disk test set (the Linear Verify test) for 10 minutes and sends the result to the file testlog.log. If the test does not complete after 10 minutes, the test aborts and records Failed in the test log.
pcdr /rt:hd&6 /pr:testlog.log /tx:10
txx:y This switch specifies the maximum time duration allowed for test sets in a script file, where x specifies the test set defined in the script file and y specifies the maximum test time duration. In the script file, the names of the test sets do not matter. The first test set following the RUN command in the script file is always test set 1, the second test set following RUN is always test set 2 and so on. This switch supports up to nine test sets on one command line. In this example, tx1:10 causes the first test set defined in the script file to run for a maximum of 10 minutes, tx2:20 causes the second test set to run for a maximum of 20 minutes and tx3:60 causes the third test set to run for a maximum of 60 minutes.
pcdr /au:script.ini /tx1:10 /tx2:20 tx3:60
ver Displays the current version of the application. This example displays the version number at the DOS prompt.
pcdr /ver c:\ 2.0.788
140 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
Bits are numbered from right to left in a bitmap. The far right bit is bit number 0. The next bit to the left is bit number 1, the next bit to the left of bit number 1 is bit number 2 and so on. This is an example of bit order. Bit values are read from right to left.
76543210
Starting from bit number 0, each bit has a value that is half the value of the bit on its immediate left (the bit value is not the same as the bit order). Bit number 0 has a value of 1, bit number 1 has a value of 2, bit number 2 has a value of 4, bit number 3 has a value of 8 and so on. This is an example of bit values.
128 64 32 16 8 4 2 1
Each bit in a bitmap can be used to represent a subtest in a test category or an installed hardware device. You can also use bitmaps to indicate features or devices that you want to use or mask. For example, in the PCDR.INI file a bitmap can disable specific subtests in a test set. Bitmaps can also be used on the command line. For example, a bitmap can be used with the rt switch (SEE ALSO rt:nn on page 121) to define a device count (four hard drives, four serial ports, two USB ports and so on). The first subtest or device represented in a bitmap is designated with a value of 0. Bit number 0 represents the first subtest or device, bit number 1 represents the second subtest or device, bit number 2 represents the third subtest or device and so on. The effects of a bitmask depend on how it is used. A bitmask can be used to prevent specific subtests from running or to designate specific devices for testing. To enable a subtest or device in a bitmask, you would switch its assigned bit to 1. For example, using the bitmap in the PCDR.INI file, to indicate that you do not want to run the first and third CPU subtests their assigned bits (bits 0 and 2) are set to 1. Used with the rt switch, the same bitmap would run tests on the first and third hard drives in a system with four hard drives. This is an example of a bitmap that is defined to filter out the first and third subtests or running available tests on the first and third device.
00000101
Specified subtests and devices are defined by the sum total of the bit values for bit numbers set to 1. The above bit map can be defined by an integer value of 5. Bit number 0 contains a bit value of 1, bit number 2 contains a bit value of 4. The sum total of the bit values for bit number 0 and bit number 2 is 5.
00000101 = 4+1 or 5