Описание программы H7.

Краткая информация о программе.

Первой моей программой, написанной во время работы на S-12, был декодировщик биллинга C-DOP. Потом последовал декодировщик АМА-файла. При написании этих первых программ я имел на руках информацию о формате обрабатываемых файлов. Последующие программы писались без какой-либо вспомогательной информации, либо информации о формате файлов было крайне мало. При написании декодировщика исторического файла C-DOP, информация, содержащаяся в SI300, конечно, помогла, но зачастую она была не верна. Для каждого типа файлов писались отдельные программки, на С под DOS. Через некоторое время у меня возникла идея свести эти программы в одну, так и появилась H7. Вообще-то, она выросла из декодировщика Historical Files (отсюда и буква «H» в названии программы) путем постепенного его расширения. Программа работает только с текстовыми файлами, причем, в результирующих файлах используется кодировка CP866, что существенно упрощает процесс декодировки.

screenshoot of H7

1. Декодировка Detailed Billing (AMA) File (LFILID=800).

В этом случае есть одна фишка программы — возможность вывода мнемоники транкгруппы. Для этого нужно воспользоваться макросом TKG_MNEM, который идет вместе с программой. Макрос запускается без параметров. В результате своей работы он выведет десятичные номера и мнемоники транкгрупп. С помощью любого текстового редактора нужно взять эти строки из логфайла терминальной программы и поместить их в файл tkg_mnem. (без расширения), который, в свою очередь, нужно поместить в каталог к H7.EXE. Впрочем, программа не откажется работать и без этого файла.

Результаты работы:

Я думаю, содержимое файла с результатами комментировать не стоит, благо в начале имеется шапка, поясняющая содержимое столбцов, к тому же, описание 800-го файла имеется в ТУ на станцию.

2. Декодировка C-DOP Billing File (LFILID=3916, 3917).

Здесь ничего примечательного нет, декодировка производится в соответствии с ТУ. ММС комманды для работы ДОПовским биллингом общеизвестны — особых секретов нет.

Результаты работы:
№ столбцаНазвание столбцаСодержимое
1ДатаДата начала разговора
2ВремяВремя начала разговора (запуска тарификации)
3Ном.вызывающегоНомер абонента в поле А (выводится 16 знаков из 18)
4Ном.плательщикаНомер плательщика (выводится 16 знаков из 24)
5Ном.вызываемогоНомер абонента в поле Б (выводится 16 знаков из 24)
6ччммссРеальная продолжительность разговора
7ччммссОплачиваемая продолжительность разговора
(обрабатывается факт корректировки – бит 84)
8Стоим.Стоимость разговора (в у.е. – уругвайских ескудо)
(обрабатывается факт корректировки – бит 91)
9Номер ВРМ (b)Номер, набранный в поле «Б малое»
10Номер картыПишутся названия населенных пунктов
11изврПричина изменения времени.
12ВООК оплате, у нас не используется
13 Приоритет вызова
14 Тип счета
15 Тип оплаты/вызова

 

3. Декодировка File Descriptor Table (LFILID=1).

Дополнительная информация:
File Descriptor Table File (FDTF), файл таблицы описаний файлов. Это специальный файл, который содержит информацию о каждом возможном логическом файле. Эта информация организована в виде File Descriptor Block (FDB) – блока описания файла размером 60 байт. В версии R7.1 FDTF содержит описания (FDB) на 5000 файлов (в том числе и на себя самого), для R7.3 эта цифра равна 9999, а для R7.4 - 32765. Для работы с этим файлом служит FMM FILE DESCRIPTOR TABLE ADMINISTRATOR (FDTA) – администратор FDT, который предоставляет информацию о файлах другим FMM, например IOS File Manager и FDB Maintenance. Для работы с FDT (вернее c FDB) имеются соответствующие ММС команды:
(CRN 0391) DISPLAY-FDB-DIR
(CRN 0392) CREATE-FDB
(CRN 0393) MODIFY-FDB
(CRN 0394) REMOVE-FDB
(CRN 0395) DISPLAY-FDB
(CRN 7281) MODIFY-FDB-PFILNAME
Счастливые обладатели комплекта учебной документации от Мосбелл могут обратиться к 770 00435 6120-VHBR «Том 5. Функциональное описание». Начиная со страницы 569 и далее, до наступления крепкого, глубокого сна.
Результаты работы:
№ столбца/
параметра		Название столбцаСодержимое
01 (04)NLFILID
02 (05)Logic FNLogical file name
03 (18)Physical FileNamePhysical file name
04 (14)FileTypeFile Type see (SI027)
05 (15)DataTyData Type
06 (06)LogRLLogical record length
07 (07)MaxNRMaximum number of records
08 (20)Ini.SInitial size allocation (number) of records
09 (08)RAuthorization key for read
10 (09)WAuthorization key for write
11 (10)MAuthorization key for modify
12 (19)Dev.ListDevice list
13 (13)RARecovery Atribut
14 (22)Ph.RLPhysical block length in bytes
15 (21)CategoryCategory
16 (11)TranslatTranslation format

В первом столбце в скобках приведены номера соответствующих параметров в RRN 336.

4. Декодировка C-DOP Historic File (LFILID=3906-3915, 3918).

Что хочется сказать про обработку исторического файла? Крайне мало информации для обработки в полном объеме. Даже если использовать листинги FMM (хотя, порой, без них как без рук!). Дело в том, что много полей заполняется "умолчальными" значениями при определенных условиях, некоторые поля имеют одно и то же значение на протяжении всего периода эксплуатации (например, номер SOTRACE, 38-й байт записи абонента А (A Record)). Я уже не говорю о значениях некоторых полей, для которых известно только их цифровое значение и общее описание, но что скрывается за конкретным значением непонятно (пример: поле CAUSE, байты 34 и 35 записи данных (Data Record), — причина неудачного завершения попытки сделать автоматический вызов абонента). Есть некоторые приколы с полями, содержащими значения года. На подобные разбирательства со значением одного бита можешь потратить уйму времени, перелопатить листинги, и все равно ничего конкретного не найти. Поэтому, программа не обрабатывает все известные поля. В худшей ситуации я оказался только при орбаботке Security File.

Результаты работы:

Примечание: В системе предусмотрена возможность обнаружения мошеннических (по мнению разработчиков системы) действий оператора. Используемые для этого поля, далее по тексту будут выделены красным цветом. Но особо на них надеяться я бы не советовал, результат может дать только ведение тарификации как для обычных абонентов и сравнение ее с данными из исторического файла. Так же, при объяснении значений полей приведена позиция (биты, байты) исходных данных в записях.

#[717310]Accept=[18/11 07:06]Cancel=[18/11/02 07:06:27]Handling=[01:08]
NA=H'36&28 ICC=1 Out Conv=A-Sub CircType=Auto CallCat=Orig.
SubA[08,01] XX-XXXXXX            OpA*[00,00]
Op:25 AB Pos:12 HistCall Prio=4  Part=2 Mon:02[00:07] CancA
Запись абонента А (A-subscriber record), здесь:
#[717310]Порядковый номер квитанции (байты 36-38).
Accept=Call Acceptance Time. Дата и время принятия вызова [ДД/ММ ЧЧ:ММ] (байты 142-145).
Cancel=Cancel Time. Дата и время отмены квитанции [ДД/ММ/ГГ ЧЧ:ММ:СС] (байты 242-246).
Handling=Call Handling Time. Общее время обработки квитанции (байты 194,195).
NA=H' Номер оборудования. Обрабатыватся байты 12-14, хотя предусмотрено на один байт больше.
ICC=Incoming Call Class, класс поступившего вызова (байт 147).
Out/IncIncoming or outgoing circuit, (байт 46, биты 7 и 6).
Conv=Conversation With. Указывает, какое поле было использовано для установления соединения:
  • A-Sub поле А;
  • A-Op поле а;
  • Undef неопределено.
Обрабатываются биты 5 и 4 байта 46.
CircType=Circuit Type. Тип соединительной линии, использовавшейся при соединении:
  • Man. ручной канал;
  • Auto автоматический;
  • Line не знаю, не встречалось;
  • Undef неопределено.
Обрабатываются биты 3 и 2 байта 46.
CallCat=Call Category:
  • Tranz транзитный вызов (не встречалось);
  • Orig. исходящий вызов;
  • Term. входящий вызов (не встречалось);
  • Undef неопределено.
Обрабатываются биты 1 и 0 байта 46.
SubA[nn,mm]ХХХ-ХХХХХНомер абонента А: ХХХ-ХХХХХ —цифры номера абонента А (байты 48-68); nn — количество цифр в номере (байт 82); mm — число попыток набора номера, после его изменения оператором (байт 83). При модификации оператором номера (бит 7 байта 44) строка выводится как SubA*.
OpA[nn,mm]ХХХ-ХХХХХНомер оператора А: ХХХ-ХХХХХ —цифры номера оператора А (байты 84-104); nn — количество цифр в номере (байт 118); mm — число попыток набора номера, после его изменения оператором (байт 119). При модификации оператором номера (бит 7 байта 45) строка выводится как OpA*.
Op:Идентификаторы операторов, работавших с квитанцией. Так же выводится следующая информация:
  • Am оператором выполнялась корректировка стоимости;
  • AB выполнено соединение абонентов А и Б.
Обрабатываются байты 162-173.
Pos:Last Logical Position Number. Номер последнего рабочего места, на котором обрабатывалась квитанция. Обрабатывается только байт 174, хотя поле имеет размер два байта.
TimRelTimed Release Active. Отбой по таймеру (бит 0 байта 30).
ChgAmCharge Amended. Факт корректировки стоимости (бит 4 байта 41).
HistRetrHistorical Retrieval. Квитанция была исторически запрошена (бит 3 байта 41).
A-BEntCon AB Entered. Соединение АБ было введено? Смысл до конца не понятен, но используется значение бита 5 байта 42.
3thConn3th Connected. Смысл, опят же, до конца не понятен, но используется значение бита 6 байта 42.
WURRetWake Up Retrieved. Побудка (бит 1 байта 43). Прикол в том, что если верить имеющемуся у меня описанию, то значение имеют только первые два бита 43-го байта, но как показала практика, пятый бит тоже используется, для чего — непонятно.
HistCall/CancCallОтпущена в систему квитанция или нет. Обрабатываются только эти два значения байта 124, т.к. другие значения на практике не встречались.
Prio=Call Priority. Приоритет вызова (байт 125).
Part=Number Of Parties. Кол-во сторон (байт 126).
Mon:Number Of Monitoring and Total Time. Мониторинг соединения: сколько раз (байт 158) и суммарное время (байты 160 и 161).
CancA/ CancB/ CancS/ CancOOriginator Of Call Cancellation. Причина отбоя (абонент А/ абонент Б/ система/ оператор)
БНО/ПР1/…Аббревиатура причины отбоя (байты 198-201).
DelayЗадержка квитанции. Байты 222-227. Обрабатывается только задержка по абсолютному времени, т.к. другие варианты операторами на практике не используются. По этой же причине не обрабатываются поля, связанные с отсрочкой квитанций.
-B1 Rec- NA=H'20&14 Conv=B-Op CircType=Auto TaxCat=Nat [ НОМ ВНВ ВОО МСС ]
SubB*[10,01] XXX-XXXXXXX          OpB[00,01]
[Conv start time][Conv end time  ][Interm st. time][Real ][Charg]
[00/00  00:00:00][00/00  00:00:00][00/00  00:00:00][00:00][00:00]
-B2 Rec- Conv=B-Sub CircType=Undef TaxCat=Nat [ НОМ ВНВ МСС ]
SubB[10,00] XXX-XXXXXXX          OpB*[00,00]
[Conv start time][Conv end time  ][Interm st. time][Real ][Charg]
[00/00  00:00:00][00/00  00:00:00][00/00  00:00:00][00:00][00:00]
-B3 Rec- NA=H'30&12 Conv=B-Sub CircType=Auto TaxCat=Nat [ НОМ МСС ]
SubB[10,01] XXX-XXXXXXX          OpB[00,00]
[Conv start time][Conv end time  ][Interm st. time][Real ][Charg]
[18/10  08:49:08][18/10  08:50:22][18/10  08:49:08][01:13][04:00]

Примечание: Программой не обрабатываются поля, связанные с начислением оплаты — все равно тарификация, как правило, не настроена. Так же, обрабатываются только первые три записи абонента Б, в то время как их предусмотренно больше двадцати.

Запись абонента Б (B-subscriber record), здесь:
NA=H' Номер оборудования. Обрабатыватся байты 12-14, хотя предусмотрено на один байт больше.
Conv=Conversation With. Указывает, какое поле было использовано для установления соединения:
  • B-Sub поле Б;
  • B-Op поле б;
  • Undef неопределено.
Обрабатываются биты 5 и 4 байта 108.
CircType=Circuit Type. Тип соединительной линии, использовавшейся при соединении:
  • Man. ручной канал;
  • Auto автоматический;
  • Line не знаю, не встречалось;
  • Undef неопределено.
Обрабатываются биты 3 и 2 байта 108.
TaxCat=Taxation Category:
  • Border значение не известно (на практике не встречалось);
  • Nat междугородний вызов;
  • Inter международный вызов;
  • Undef неопределено.
Обрабатываются биты 1 и 0 байта 108.
[ НОМ ВНВ МСС ]Тип оплаты/вызова, (байты 200-205).
SubB[nn,mm]ХХХ-ХХХХХНомер абонента Б: ХХХ-ХХХХХ —цифры номера абонента Б (байты 34-54); nn — количество цифр в номере (байт 68); mm — число попыток набора номера, после его изменения оператором (байт 69). При модификации оператором номера (бит 3 байта 107) строка выводится как SubA*.
OpB[nn,mm]ХХХ-ХХХХХНомер оператора Б: ХХХ-ХХХХХ —цифры номера оператора Б (байты 70-90); nn — количество цифр в номере (байт 104); mm — число попыток набора номера, после его изменения оператором (байт 105). При модификации оператором номера (бит 4 байта 107) строка выводится как OpA*.
[Conv start time]Conversation start time. Дата и время начала разговора абонентов (байты 122-125).
[Conv end time ]Conversation end time. Дата и время окончания разговора абонентов (байты 134-137).
[Interm st. time]Intermediate conversation start time. Дата и время возобновления разговора абонентов. В случае если разговор абонентов был прерван оператором, а потом начат заново в это поле заносится время возобновления разговора. Если разговор не прерывался, то заносится время начала разговора. Обрабатываются байты 138-141.
[Real ]Real conversation duration. Реальная продолжительность разговора (байты 126-127).
[Charg]Charged conversation duration. Время, выставленное системой к оплате (байты 130-131).
-TextRec1-
1 *** СБОЙ ДОСТУПА ***
Текстовая запись (Text record)

Данный тип записи содержит 6 текстовых блоков. При обработке этой записи, программа каждый текстовый блок (если он не пуст) выводит в отдельной строке. В начале каждой такой строки указывается идентификатор текстового блока присвоенный системой.

-DataRec- XXXXXXXX Attempts= 1 BookTime[06:30] StartDate[21/10]
Ringing[06:25:04:06] Answer[06:25:19:07]
Запись данных (Data record), здесь:
XXXXXXXXТелефонный номер абонента на который заказана побудка (байты 142-151).
Attempts=Number of attempts. Число попыток установления автоматического соединения (байт 32).
BookTimeBooking time for the wake-up. Время, на которое заказана побудка (чч:мм). Обрабатываются байты 160-161.
StartDateStart date for the wake-up. Дата, на которое заказана побудка (дд:мм). Обрабатываются байты 162-163.
Ringing Время, начала посылки вызова абоненту (чч:мм:сс:дес). Обрабатываются байты 40-43.
AnswerВремя, ответа абонента (чч:мм:сс:дес). Обрабатываются байты 44-47.
-AmmendmentRec- OpID[05] PartyIdx[02] ChAm[240]
Запись коррекции данных (Ammendment record), здесь:
OpIDOperator identity. Идентификатор оператора, вносившего изменения (байты 8-9).
PartyIdxParty index. Номер стороны для которой делается изменение (байт 16).
ChAmСharge amendment duration. Истинное значение поля не понятно, но обрабатываются байты 10-11.
-CommentRec1-
1316 БНО
1404 БНО
1545 БНО СНЯТ
Запись примечаний (Comment record)

Данный тип записи содержит 3 строки примечаний, каждая длиной 78 символов. При обработке этой записи, программа выводит эти строки, если он не пусты.

5. Декодировка Security File (LFILID=7-13).

Дополнительная информация:
Security File (SF) – файл надежности. Используется для фиксирования изменений вносимых в БД и для процедур отката (ROLL-BACK/ROLL-FORWARD). Для работы с SF служит SECURITY FILE HANDLER FMM. Записи об изменениях вносятся в SF в хронологическом порядке. Логическая структура SF приведена ниже на рисунке.

Как видно, SF состоит из 7 разделов (каждый раздел физически является файлом с LFILID от 7 до 13). Раздел начинается с заголовка, который содержит управляющую информацию, и последовательности записей. Записи могут быть трех видов:
  • EOSF RECORD: служит для пометки окончания информации в разделе
  • TRANSACTION CHANGE RECORD: информация о вносимых изменениях
  • CONTINUATION RECORD: последующая часть, используется в тех случаях, когда TRANSACTION CHANGE RECORD оказалась больше 2048 байт, т.е. была разбита на две физические записи.
Запись информации в SF идет по кругу: т.е. с первого по седьмой раздел, потом опять первый раздел и т.д. Что же фиксируется в SF? В тех источниках, из которых я черпал информацию о SF, писалось в том духе, что фиксируется вся информация. Но исходя из здравого смысла и того факта что Relation Information Area (RIA) содержит поле B_INF_SEC (Security and Recovery information of the relation) в котором есть байтик, значение которого описывается следующим образом:
    0 : No log in Security File
    1 : Log in Security File
можно сделать вывод, что фиксируются изменения не всех отношений. В принципе эту гипотезу можно легко проверить на практике (мне этого сделать не привелось).
Для работы с SF используются следующие ММС команды:
(CRN 0481) DISPLAY-SECF
(CRN 0415) SAVE-SEC-FILE
Результаты работы:
/* Start Of Information extracted from Security File Header */
SF_STATUS=Previous Partition# 01 FILE_ID=0007 SIZE=32766 REC_CORRUPT=00
/* End Of Information extracted from Security File Header */

RCRD_TYPE=TRANS RCRD_ST=VALID_MEMORY Prev=006 Own=010 INT_TRANS_NO=42783
ORJ_ID[0000 1999-05-08] REC_TIME[21:00:17:01] FMM_ID=01690 PROC_ID=H'0830 H'EC44
LCE_ID=H'8D00 DML_COM_ID=002(MODIFY) DML_COM_OP=000 INF_SEC=H'F8F4
DLS_FILE_ID=2462 RID=01584 REL_PNB=00000 NO_OF_CH=001
RcrdNo=00060 RcrdOffs=01770 ChangeLgth=H'0080
MemSegm=H'0002 MemOffs=H'0298
Old Value
       00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F
H'0298 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02A8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02B8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02C8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02D8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02E8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02F8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'0308 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'0318
New Value
       00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F
H'0298 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02A8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02B8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02C8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02D8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02E8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'02F8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'0308 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
H'0318

И так, начнем по порядку — с заголовка:

SF_STATUS=статус SF: может быть Init/Actual/Previous (B_STATUS Z_M_SF_STATUS)
Partition#номер раздела (B_PART_NO M_PART_NO)
FILE_ID=логический идентификатор файла (B_FILE_ID M_IOS_LOG_FILE)
SIZE=размер в записях (1 запись=32 байт) (B_SIZE INT)
REC_CORRUPT=кол-во плохих записей (B_REC_CORRUPT BIN(8))

Скажу честно – это не весь заголовок, это только наиболее полезная его часть. Продолжим дальше:

RCRD_TYPE=SECURITY FILE RECORD TYPE (B_RCRD_TYPE Z_M_RCRD_TYPE). Тип записи:
  • TRANS TRANSACTION RECORD;
  • CON CONTINUATION RECORD;
  • EOSF EOSF RECORD.
RCRD_ST=SECURITY FILE RECORD STATUS (B_RCRD_ST Z_M_RCRD_ST). Статус записи:
  • VALID_MEMORY
  • VALID_DISK
  • DELETED
  • ROLLED_BACK
  • AUDIT_REQUIRED
  • AUDIT_EXECUTED
  • AUDIT_FAILED
Prev=размер предыдущей записи (в блоках) (B_PREV_LGTH)
Own=собственный размер, опять же, в блоках (B_OWN_LGTH)
INT_TRANS_NO=номер транзакции (B_INT_TRANS_NO M_TRANS_NO)
ORJ_IDидентификатор ORJ — Operator Requested Job (B_ORJ_ID M_ORJ_ID)
REC_TIMEвремячко… (B_REC_TIME Z_M_TIME)
FMM_ID=идентификатор FMM (B_FMM_ID M_FMM_ID)
PROC_ID=идентификатор процесса (B_PROC_ID M_PROCESS_ID)
LCE_ID=логический идентификатор контрольного элемента (B_LCE_ID M_LCE_ID)
DML_COM_ID=идентификатор комманды языка манипуляции данными (B_COM_ID M_DML_COM_TYPE)
DML_COM_OP=опция этой комманды (B_COM_OP M_DML_OPT_TYPE)
INF_SEC=(B_INF_SEC M_INF_SEC)
DLS_FILE_ID=(B_DLS_FILE_ID M_IOS_LOG_FILE)
RID=(B_RID M_RID)
REL_PNB=(B_REL_PNB M_REL_PNB)

Заключение

 В принципе, все возможности программы описаны. Я думаю, стоит отметить, что при декодировании обрабатывались не все существующие поля, а только полезные на практике. По мере своих способностей, я попытался дать некоторые дополнительные сведения по ходу описания. Пока я писал это описание обнаружил несколько ошибок в программе :-). Сырцы не высылаются, но это не касается форматов файлов.

Взять программу.

 

 
Максим Осташов
Размещено на www.s12most.mailru.com 4 апреля 2001
Обновлено 20 декабря 2002
Есть вопросы или дополнения, конструктивная критика? Пишите!
Hosted by uCoz