Please enable JavaScript to view this site.

XStudio 3

Navigation: Appendices

Generic Log File Specification

Scroll Prev Top Next More

The Generic Log File Specification documents the file naming convention and record structure for logs created for use with XStudio.

This specification was originally published by Computer Concepts Corporation, Lenexa, KS in 1989 and updated to version 1.5 in October 1991. The specification was released to all interested parties, including traffic system vendors and music scheduling system vendors.

This document (the one you are reading) is referred to as:

dcsTools Generic Log File Specification Version 1.6 (Updated 6/28/2010)

It updates and corrects errors in version 1.5 of the specification published by Computer Concepts Corporation.

Log File Structure

The Generic Log File is made up of 69-byte records terminated with a Carriage Return (byte 68) and Line Feed (byte 69).

The first record in the file is an informational record (ID Record) not displayed in XStudio.

All other records include a time field of 4 characters representing military time in hours and minutes, on which the file is sorted. In addition, Commercial Records contain a seconds value field. The time field, including the seconds value field where applicable, must be a unique value for each record, in the range of 00:00:00 to 23:59:59. The log has a maximum of 86,400 records, based on unique time values with one-second resolution.

The original Computer Concepts specification document indicated that the maximum number of records for a log file is 1441. While this number is correct when considering the number of minutes in a day (1440) plus one ID Record, in reality the actual maximum number of records is 86,400 when you consider Commercial Records that contain a seconds value.

Each log file represents one (1) day of programming, 24 hours in length, beginning at midnight and finishing at 11:59:59 PM.

It is not required that a log file contain content for all hours of the day (i.e. records with time fields starting at midnight and ending at 11:59 PM), but the log must not contain content for more than one day. As an example, if the station for which the log is prepared operates between 5 AM and 8 PM only, it is perfectly acceptable that the log file contains content for those hours only.

A typical log, viewed in a standard text editor, might look similar to the example fragment:

 

I           WXST-FM

D0000LR00300                   Load Required Brk

C0000:01T004DIET COKE/Q:Diet Coke!    00059CM

C0000:02T010VERNE & BUBBA'S DONUT     00049CM

C0000:03T110DoubleTree                00058CM

D0020LR00400                   Load Required Brk

C0020:01T118Get Well Games            00059CM

C0020:02T120DENTYNE/reg or sugarfree  00029CM

 

Additional information regarding what the host system expects to see in the finished generic log is contained in the topic Generic Log Construction Guidelines.

Log File Name

Log files are named in such a way as to provide for one unique file for each day of each year for each station. This allows usage of a single file folder location for all stations in a multi-station environment.

Log file names have the form MMDDYYxx.LOG, where:

MM

=

Month (01-12)

DD

=

Day (01-31)

YY

=

Year (00-99)

xx

=

Station Number (any 2 characters in 0..9, A..Z)

.LOG

=

The log file extension

Generic Record Type

All records have a record type value in byte 1 of the record. Bytes 2-67 will vary in format, depending on the record type. All records terminate with a Carriage Return/Line Feed combination in bytes 68 and 69.

Bytes

Len

Description

Possible Values

01

1

Record Type

B = Blank Line
C = Commercial
D = Directive
I = ID Record
L = Log Note
P = Program Title

02-67

66

< Format depends on record type >

68-69

2

CR/LF

Carriage Return/Line Feed

Total

69

 

Record Type Conventions

All record types defined are presented in tabular form and include the byte positions for each field, length of each field, a description of the field and possible values for the field. Here are the conventions used in documenting record types:

All fields in a record are fixed-length. If the field is not completely filled with information, it must be padded with space characters (Decimal 32, Hex 20) to the full length of the field to ensure correct byte alignment. Unless otherwise noted, all fields are left-justified.

In the possible values column, text marked in BOLD are acceptable field vales; all other text is descriptive in nature.

The terms Blanks and Blank are used in the possible values column to identify fields or reserved areas of the record that are to be populated with the space character (Decimal 32, Hex 20).

Original versions of Computer Concepts Corporation documentation specified some fields should be "padded with nulls," meaning using the null character (Decimal 0, Hex 00) to fill unused byte positions at the end of the field. Over time, the accepted method became filling the unused byte positions with the space character (Decimal 32, Hex 20).

The term Freeform is used in the possible values column to indicate that the field value can be standard text of your choosing (i.e. freeform) up to the maximum length of the field.

Some fields in the Commercial Record are noted in the possible values column as Filled in by system or <Not Used>. These fields should be output filled with blanks (Decimal 32, Hex 20).