Я точно не знаю, в этом ли проблема, но я вижу логический поток, который не будет работать очень хорошо ...
Первый: 400-SALESMAN-NAME
читает записи продавцов изфайл в рабочую таблицу хранения SALESMAN-TABLE
.
Файл, вероятно, выглядит примерно так:
01Sales Guy One
02Lance Winslow
03Scott Peterson
04Willy Loman
Когда цикл чтения завершится, SALESMAN-NUMBER
будет равен индексу таблицы из-за способа загрузки таблицы (используя SM-NUMBER-IN
установить нижний индекс таблицы).Пока проблем нет ...
Далее: 500-PROCESS-FILE
перебирает все строки в SALESMAN-TABLE
, выполняя индекс ROUTINE-CHECK
от 1 до 99 и выполняя 510-TABLE-SEARCH
, чтобы выписать отчет для продавцагде индекс равен SALESMAN-NUMBER
...
Далее: оператор SEARCH
.Здесь все странно и никогда не выполняет 520-WRITE-FILE
.Вот почему.
Оператор SEARCH
реализует линейный поиск (SEARCH ALL
- это двоичный поиск).SEARCH
просто увеличивает индекс, связанный с искомой таблицей, и затем проходит серию WHEN
тестов, пока один из них не «сработает» или индекс не выйдет за конец таблицы.Индекс для вашей таблицы TABLE-ENTRIES
: IND-TABLE-ENTRIES
.Но вы никогда не устанавливаете и не ссылаетесь на него (это корень проблемы).Я объясню через минуту ...
Обратите внимание, что WHEN
часть вашего SEARCH
использует индекс ROUTINE-CHECK
.ROUTINE-CHECK
было установлено в 500-PROCESS-FILE
.Также обратите внимание, что вы получаете значение 520-WRITE-FILE
, только если SALESMAN-NUMBER
соответствует значению ROUTINE-CHECK
- что будет, если продавец с таким номером был прочитан из входного файла.Это может работать, потому что вы загрузили таблицу так, что номер строки равен номеру продавца обратно в 450-TABLE-LOAD
.
Теперь, что произойдет, если входной файл не содержит продавца, где SM-NUMBER-IN
равно 01?
Позволяет пройти через это, удар за ударом ...
ROUTINE-CHECK
установлен в 1, вызывается SEARCH
, и потому что индекс IND-TABLE-ENTRIES
, связанный с найденной таблицей, меньше чемчисло встречается в таблице (оно было инициализировано нулем при загрузке программы), выполняются предложения WHEN
.
Первый тест - WHEN SALESMAN-NUMBER (ROUTINE-CHECK) = ROUTINE-CHECK
.Поскольку продавец 1 не существует, SALESMAN-NUMBER
будет равен нулю, и тест не пройден (0 <> 1).
Выполняется следующее предложение WHEN
, и оно успешно выполнено, потому что (0 = 0);но это опция «ничего не делать», поэтому другой цикл ПОИСКА вводится после увеличения IND-TABLE-ENTRIES
.
Те же результаты для этой и всех последующих итераций в списке SEARCH
ed WHEN (ни одно из предложений не соответствует) ... Повторяйте этот цикл до тех пор, пока IND-TABLE-ENTRIES
не будет увеличен за пределами таблицы.
В этот момент SEARCH
завершается, и управление возвращается к следующему циклу в 500-PROCESS-FILE
.Ничего не было напечатано.
500-PROCESS-FILE
, затем увеличивает ROUTINE-CHECK
на 1 (теперь это 2).У нас есть продавец с SALESMAN-NUMBER
, равным 02, поэтому мы должны получить какой-то результат - верно?Неправильно!Но почему?
Если вы прочитаете глагол SEARCH
, вы обнаружите, что он не сбрасывает индекс таблицы (в данном случае: IND-TABLE-ENTRIES
).Он начинает использовать любое значение, которое имеет при вводе ПОИСКА.Вы никогда не сбрасываете его, поэтому оно уже установлено за пределами таблицы.ПОИСК просто завершается и ничего не печатается - когда-либо снова.
Устранение проблемы
Учитывая, что вы сначала загрузили TABLE-ENTRIES
по номеру продавца, я не вижу цели использования ПОИСКА.Просто сделайте что-то вроде:
500-PROCESS-FILE.
PERFORM VARYING ROUTINE-CHECK FROM 1 BY 1
UNTIL ROUTINE-CHECK > 99
IF SALESMAN-NUMBER (ROUTINE-CHECK) = ZERO
CONTINUE
ELSE
PERFORM 520-WRITE-FILE
END-IF
END-PERFORM.
Может также быть хорошей идеей иметь цикл инициализации для таблицы, чтобы каждый SALESMAN-NUMBER был явно установлен в ноль, прежде чем вы прочитаете файл продавца.1091 * Если вам необходимо использовать ПОИСК в этой программе, не забудьте установить и использовать связанную индексную переменную таблицы при обращении к поисковой таблице.