Skip to main content

TroubleShooting - Fixing (Rebuilding) Active Project Fone Files

Overview

Over the course of a project's life, the fone file can develop errors that affect dialing performance or sample integrity. Common causes include:

  • Error records that need to be corrected before dialing can resume normally.
  • Fresh numbers not being released because the stacks fell out of order.
  • Excessive hide/reveal operations that corrupted the record number order -- since records are processed sequentially, a record numbered 1001 appearing after record 2432 in the file will never be reached.
  • UITA (Up in the Air) and OTF (On the Floor) numbers left unresolved after a connection loss, survey blow, or dialer/server crash.
  • Missed callbacks that need to be reassigned for the current day.

When any of these conditions are present, the fone file needs to be repaired or rebuilt before the project goes back into production. This article covers three processes for doing so, in order of escalating complexity:

  • Process 1 -- VUXIS via FoneUtil: The fastest option. Runs the sample through five sequential steps that verify, clean, and reorder the fone file. Handles most routine issues and should always be attempted first.
  • Process 2 -- fonerun rebuild: An automated rebuild that converts the fone file to ASCII and reconstructs it, then runs VUXIS automatically on completion. Handles more serious issues that Process 1 cannot fix, but can fail silently if it encounters an error mid-rebuild.
  • Process 3 -- Manual Rebuild: A step-by-step manual replica of the fonerun rebuild, giving the programmer full control at each stage. Errors are surfaced explicitly and can be corrected before continuing. This is the most reliable option for serious fone file problems.

In practice, most situations are resolved by running Process 1 first. If the results are not clean, the typical path is to skip Process 2 and proceed directly to Process 3. Process 2 is documented here as a middle option, but its silent failure behavior makes Process 3 the safer choice when Process 1 is not enough.

Prerequisites & Backup

Before performing any fone file repair or rebuild operation, the following steps must be completed in order. Do not skip or reorder these steps.

Allow a minimum of 20-30 minutes before the project's next scheduled start time. Starting any repair process too close to shift start risks agent downtime if the process runs long.

Step 1 — Confirm the Job is Not Active

From a super/boss session in PuTTY, type:

daiwc jobname <enter>

If agents are shown, the job is live and no repair work can be performed. Stop here and coordinate with Phone Ops before proceeding. If no agents are shown, continue.

Step 2 — Shut Down the Job and Clear Open Files

From the super/boss session, type:

server:clearstudy jobname <enter>

You will be prompted for a 2-digit confirmation code. Enter it to close the study and clear any open files.

Step 3 — Confirm No Files Are Still Open

From PuTTY, type:

whylock jobname <enter>

If nothing is returned, proceed. If files are still showing as open, resolve accordingly before continuing.

Step 4 — Navigate to the Fone Folder

From PuTTY, type:

fone <enter>

Step 5 — Back Up the Fone File and Index Files

Copy the project's fone file and all associated index files into the backup directory by typing:

cp jobname.f* backup/. <enter>

Once the backup is confirmed, you are ready to proceed with the appropriate repair process below.

Process 1 — VUXIS via FoneUtil

VUXIS is the fastest repair option and should always be attempted first. It runs the sample through five sequential steps that verify, clean, and reorder the fone file back to its proper state. It is most effective for minor issues and routine maintenance, but may not resolve more serious fone file errors.

NOTE: This process runs automatically each night during the overnight processing window around 5am. These steps should only be needed if the job is running across shifts, and something happened during dayshift that warrants the repair. 

Step 1 — Launch FoneUtil

From the /cfmc/phone10/phone directory in PuTTY, type:

foneutil <enter>

At the first prompt, you will be asked for a list file name. You have two options:

  • Press <enter> to skip — output will display directly on screen in real time.
  • Type a filename and press <enter> — output will be written to that file instead of the screen, and you will need to read the list file afterward to review what changed.

Step 2 — Load the Project

At the next prompt, type the project name and press <enter>:

jobname <enter>

FoneUtil will confirm whether the project loaded in Read-Write (R/W) or Read-Only (RO) mode. If the project loads as Read-Only, stop here and return to the Prerequisites section to resolve the issue before continuing.

Step 3 — V (Verify)

Type:

V <enter>

Verify checks that all records are in their proper stacks and performs low-level adjustments where needed. The steps that follow are more capable of correcting deeper issues, but Verify establishes the baseline for the process.

Step 4 — U (UITA / OTF Return)

Type:

U <enter>

When prompted for a select statement, type:

all <enter>

This returns "Up in the Air" (UITA) and "On the Floor" (OTF) records back to their originating stacks. Because no status code was ever assigned to these records, they are treated as if the call never happened. For example, a fresh number that was UITA will be returned to the fresh stack.

Step 5 — X (fiX)

Type:

X <enter>

Step 6 — I (Integrate)

Type:

I <enter>

Integrate reassigns missed callbacks so they can be rescheduled for the current day. For example, a callback that was set for 12:00 PM yesterday but was never attempted will be reassigned for 12:00 PM today.

Step 7 — S (Sort Specials)

Type:

S <enter>

When prompted for a select statement, type:

all <enter>

This re-sorts all special numbers back into their designated special stacks, so agents configured as the associated special interviewer type can access those numbers when they start up.

Step 8 — V (Verify — Second Pass)

Type:

V <enter>

This second Verify pass acts as a safety net, catching any UITA records that the initial VU sequence may have missed.

Step 9 — Review Phone Screens

Before exiting, verify the results by typing:

P <enter>

This cycles through the 5-6 phone screens, equivalent to running SPI from a super/boss session. On the first screen, confirm that the UITA and OTF fields show zero. Any remaining values in those fields indicate the issue was not fully resolved by VUXIS alone, and Process 2 or Process 3 may be required.

Step 10 — Exit FoneUtil

Type:

q <enter>

Then type:

q <enter>

FoneUtil will close. If the phone screens confirmed clean results, no further action is needed. If UITA or OTF numbers were still present, proceed to Process 2.

Process 2 — fonerun rebuild

The fonerun jobname rebuild command automates the fone file rebuild process in a single step. It outputs the fone file as ASCII, attempts to rebuild it, and then runs VUXIS on the records automatically upon completion. This will resolve most issues that Process 1 alone could not fix.

Important: fonerun jobname rebuild can fail silently — meaning it may encounter an error mid-rebuild, halt the process, and not make that obvious. As a rule of thumb, any errors reported during the run should be treated as a reason to abandon the result and proceed to Process 3, even if the run appeared to complete successfully.

Note: Running fonerun jobname without the rebuild argument will automatically execute the VUXIS sequence from Process 1. This is documented here for awareness only — Process 1 should always be run manually so the programmer can observe and interpret each step's output firsthand.

Step 1 — Run the Rebuild Command

From the /cfmc/phone10/fone directory in PuTTY, type:

fonerun jobname rebuild <enter>

The process will run automatically. Watch the screen output as it progresses.

Step 2 — Evaluate the Result

When the process completes, review the output for any error indicators. A hard abort will be clearly signaled with an error block similar to:


**********************************
Program fonebuld ended with 11 errors!
**********************************

Whether the run aborted or completed with reported errors, the recommended course of action is the same — do not trust the result. Restore the backup and proceed to Process 3.

Step 3 — If Errors Were Encountered: Restore the Backup

Navigate to the fone directory and restore the backup copy by typing:

cp backup/jobname.f* . <enter>

Once restored, proceed to Process 3 to complete the rebuild manually.

Step 4 — If No Errors Were Reported: Verify the Result

If the run completed cleanly with no errors, verify the result the same way as Process 1 — launch FoneUtil, load the project in R/W mode, and use the P command to review the phone screens. Confirm that UITA and OTF fields on the first screen show zero before considering the job ready.

Verification — After Process Completed

you can edit and view the jobname.fnr file in the /fone folder to see the output of all the steps. This is helpful if there were errors that were missed while it was running.

If any UITA or OTF numbers remain, proceed to Process 3.

Process 3 — Manual Rebuild

The manual rebuild is a step-by-step replica of what fonerun rebuild does automatically, but with full control at each stage. This allows the programmer to identify and correct errors that would otherwise cause an automated rebuild to abort or fail silently. This process should be used when Process 2 encountered errors, or when the fone file condition warrants a controlled rebuild from the start.

Step 1 — Launch FoneUtil and Load the Project

From the /cfmc/phone10/phone directory in PuTTY, launch FoneUtil and load the project the same way as Process 1. Confirm the project loads in Read-Write (R/W) mode before continuing. If it loads Read-Only, return to the Prerequisites section.

Step 2 — Convert the Sample to ASCII

Type:

C <enter>

C is short for Convert -- this outputs the entire sample as a readable ASCII file that will be used as the source for the rebuild. When prompted for a select statement, type:

all <enter>

When prompted for a filename, type:

jobname.asc <enter>

Step 3 — Dump the Header File

Type:

header jobname_hed.spx <enter>

This dumps the project's SPI/MPF/Market settings into a header file that will be read back in during the rebuild, preserving all study configuration.

Step 4 — Exit FoneUtil

Type:

q <enter>

Then type:

q <enter>

Step 5 — Back Up Again Before Deleting

Before deleting the live fone files, take a second backup as a safety net. From the /cfmc/phone10/fone directory, type:

cp jobname.f* backup/. <enter>

This ensures you have a clean restore point before the next step. Do not skip this.

Step 6 — Delete the Live Fone Files

Type:

rm jobname.f* <enter>

This clears the active fone files from the directory so the rebuild can create fresh copies in their place.

Step 7 — Run fonebuld

Type:

fonebuld <enter>

Then follow the prompts in sequence:

ascii <enter>
&jobname_hed.spx <enter>

The & prefix tells fonebuld to load the header from that file.

go <enter>
jobname <enter>
jobname.asc <enter>

Press <enter> two to three more times as prompted until the process completes and exits automatically.

Step 8 — If fonebuld Reported Errors

If errors are shown during the rebuild, do not copy the partially-built files to the backup folder — this would overwrite your good backup copy. Instead:

  • Delete the partially-created fone files from the active directory: 
    rm jobname.f* <enter>
  • Open the jobname.asc file and correct the errors that were reported.
  • Re-run fonebuld from the top using the exact same command sequence in Step 7.

Repeat until the rebuild completes cleanly with no errors.

Step 9 — Verify the Result

Once fonebuld completes cleanly, the rebuilt fone file is considered sorted, verified, and fixed as part of the rebuild process itself. As an optional but recommended final check, run VUXIS via FoneUtil (Process 1) to confirm everything is in order before handing off to Phone Ops for reactivation.

Back to top