Callerlog: Difference between revisions

Latest revision as of 05:11, 16 February 2026

BBS Operation - The Caller Log System

The Caller Log is stored on disk as a sequential file named “√caller log”. Its behavior and size limits are controlled by the parameters you defined in SETUP.

Due to BASIC memory limitations, the Caller Log must always reside on drive 0. This restriction applies only to this file type and should not present any operational issues for your BBS.

As the BBS runs, the variable LG$ is automatically updated with log information whenever a program performs a GOSUB to line 8003 (for i$) or 8004 (for a$). The LG$ variable can hold up to 250 characters before it is written to a special memory buffer. This buffer can store two such entries before the data must be transferred to disk.

When the buffer becomes full, or when the BBS explicitly forces the operation, its contents are written to a temporary file named “√l” on the Caller Log drive. If multiple buffer dumps occur, additional information is appended to the same “√l” file.

When the BBS returns to the Wait-For-Call screen, the contents of “√l” are appended to “√caller log”. At this point, the message “Appending to Caller Log” appears on the screen. This same message will also appear during a proper shutdown or after a crash recovery. This mechanism ensures that caller activity is preserved and written safely to disk.

During the append process, a duplicate file named “√l.tmp” is created. This file is an exact copy of “√l” and is not scratched. It provides a snapshot of the most recent call. When you view the Caller Log, you will be asked “View Last Call?”. If you answer “Y”, the system displays the contents of “√l.tmp”. If you answer “N”, the full Caller Log is displayed instead.

After viewing the complete Caller Log, you will be prompted to scratch it. If you answer “Y”, the log will be erased and restarted. If you answer “N”, it will remain intact. The ability to scratch the Caller Log is access-level definable in SETUP. If you intend to maintain historical records, simply avoid scratching the file.

Caller Log maintenance is handled by lines 28500–28770 in “√bbs.init”. This routine automatically trims the Caller Log when it exceeds the maximum size defined in SETUP. The file is also governed by the “minimum UL space” setting. If either the maximum log size is exceeded or the minimum free space threshold is reached, the system trims the Caller Log by the number of blocks specified in SETUP.

By default, the maximum Caller Log size is 50 blocks and the default trim size is 8 blocks. The trim size does not mean that exactly 8 blocks are always removed. Instead, the routine reduces the file to the required size and then removes an additional 8 blocks to provide working space for future entries.

The entire process is automatic and designed to prevent disk-full conditions. If, in a worst-case scenario, trimming cannot free sufficient space, the system will scratch the Caller Log entirely to avoid a Disk Full Error.

Next Section: MCI Commands

BBS Operation

@@ Line 1: / Line 1: @@
-[[bbs operation|BBS Operation]] - <strong>The Caller Log</strong>
+{{DISPLAYTITLE:Caller Log}}
+[[bbs operation|BBS Operation]] - <strong>The Caller Log System</strong>
-The caller log is stored on disk in sequential file format.  The filename is “√caller log" and it is maintained through the parameters you defined in SETUP.  The caller log must always be stored on drive 0 because of BASIC programming space limitations.  This is the only type of file that has this limitation, so it should pose no threat to a BBS system.
+The Caller Log is stored on disk as a sequential file named “√caller log”. Its behavior and size limits are controlled by the parameters you defined in SETUP.
-As the BBS system is running, the variable LG$ is automatically updated with log information whenever a program GOSUB's line 8003 (for i$) or 8004 (for a$).  LG$ can hold a maximum of 250 characters before it is dumped into a special buffer in memory.  This buffer can hold two "dumps" before the information has to be transferred to disk.
+Due to BASIC memory limitations, the Caller Log must always reside on drive 0. This restriction applies only to this file type and should not present any operational issues for your BBS.
-When the buffer is full, or when the BBS program forces the command, this buffer is transferred to a temporary file called "√l" on the Caller Log drive.  If more than one file dump is made, the information is appended to the "√l" file.
+As the BBS runs, the variable LG$ is automatically updated with log information whenever a program performs a GOSUB to line 8003 (for i$) or 8004 (for a$). The LG$ variable can hold up to 250 characters before it is written to a special memory buffer. This buffer can store two such entries before the data must be transferred to disk.
-When the BBS program returns to the wait-for-call screen, the "√l" file is appended to the "√caller log" file.  This is when the message "Appending to Caller Log" appears on the screen.  This message also appears when you shut down the system or the system crashes.  This ensures that the caller log information is secure and complete.
+When the buffer becomes full, or when the BBS explicitly forces the operation, its contents are written to a temporary file named “√l” on the Caller Log drive. If multiple buffer dumps occur, additional information is appended to the same “√l” file.
-In the process of appending to the caller log, a file called "√l.tmp" is created, which is an exact duplicate of "√l".  This duplicate is not scratched and can be used to look at what occurred during the most recent call.  This is taken advantage of with the "View Last Call?" question displayed when viewing the caller log.  If you answer "Y", you will view a log of the last call.  If you answer "N", then you will see the caller log in its entirety.
+When the BBS returns to the Wait-For-Call screen, the contents of “√l” are appended to “√caller log”. At this point, the message “Appending to Caller Log” appears on the screen. This same message will also appear during a proper shutdown or after a crash recovery. This mechanism ensures that caller activity is preserved and written safely to disk.
-After viewing the full-length caller log, you will be asked if you wish to scratch the caller log.  If you answer "Y", then the caller log will be scratched and restarted.  If you answer "N" then the caller log will be left alone.  If you wish to maintain daily records of the caller log, then do not scratch the log.  The "Scratch Caller Log" option is level definable in SETUP.
+During the append process, a duplicate file named “√l.tmp” is created. This file is an exact copy of “√l” and is not scratched. It provides a snapshot of the most recent call. When you view the Caller Log, you will be asked “View Last Call?”. If you answer “Y”, the system displays the contents of “√l.tmp”. If you answer “N”, the full Caller Log is displayed instead.
-Lines 28500-28770 in "√bbs.init" act as the caller log maintenance routine.  This routine trims the caller log when it exceeds a designated size.  The maximum size of "√caller log" is defined in SETUP.  The file will also be limited by the "minimum UL space" setting in SETUP.  If either the max size is reached, or the minimum amount of space is reached then the "√caller log” file will be trimmed by the number of blocks designated in SETUP.
+After viewing the complete Caller Log, you will be prompted to scratch it. If you answer “Y”, the log will be erased and restarted. If you answer “N”, it will remain intact. The ability to scratch the Caller Log is access-level definable in SETUP. If you intend to maintain historical records, simply avoid scratching the file.
-The default maximum caller log size is 50 and the default trim size is 8.  The 8 doesn't mean that only 8 blocks will be trimmed in all cases, but it means that the file will be trimmed to the necessary length, then 8 blocks will be removed to allow for more filling.  The process is completely automatic and attempts to compensate for even the worst possible case.  If all attempts at reducing the size of the caller log fail, the routine will scratch the caller log to prevent a Disk Full Error.
+Caller Log maintenance is handled by lines 28500–28770 in “√bbs.init”. This routine automatically trims the Caller Log when it exceeds the maximum size defined in SETUP. The file is also governed by the “minimum UL space” setting. If either the maximum log size is exceeded or the minimum free space threshold is reached, the system trims the Caller Log by the number of blocks specified in SETUP.
+By default, the maximum Caller Log size is 50 blocks and the default trim size is 8 blocks. The trim size does not mean that exactly 8 blocks are always removed. Instead, the routine reduces the file to the required size and then removes an additional 8 blocks to provide working space for future entries.
+The entire process is automatic and designed to prevent disk-full conditions. If, in a worst-case scenario, trimming cannot free sufficient space, the system will scratch the Caller Log entirely to avoid a Disk Full Error.
+Next Section: [[mcicommands|MCI Commands]]
 [[bbs operation|BBS Operation]]