Pseudo Floppy:

Hard disk "pseudo" tapes. These devices are removable or fixed hard disks or regular Unix files.

back

Overflow Table

Refers to the area that contains a list of unused frames.

The overflow table is handled as a b-tree, rather than as a finite set of overflow table entries.

It is possible to set a "reserve" block of overflow, in case the system runs out of disk (see "set-ovf-reserve").

Most importantly, the overflow table can be rebuilt if it should become necessary

A "full file-save" is a complete logical backup of the D 3/AP  file system.

Invokes the procedure to perform a full backup of each file in the D 3/AP file system. This verb is usually invoked from "dm" account.

back

File Control Block:

Every file on the system has a special frame (or frames) attached to it called a "file control block"

or "fcb". These frames contain information about the file, including index pointers and their

compiled a (algebraic) processing codes, the file "d-pointer" information for editing, pointers and

workspace used by the system when calling FlashBASIC subroutines from file dictionaries.

Also contained in this "file control block" are important flags and fields indicating that the file is

open, closed, in the process of being deleted, etc. This provides the ability to protect the system

from potentially disastrous situations, such as the case of one process deleting a file while another

process is using the same file.

back

is used as the opposite of a "full save" or "file-save". A "full restore" is the process of reloading the

entire file system from either a file-save tape or from the original sys-gen media provided with

your system.

The full restore is usually performed from the "options" prompt, where the choices are typically:

"a" for ABS load, "f" for full restore, or "x" to coldstart.

back

The System Debugger gives the user total control of all the

virtual file space and internal control tables used by the system. This is a lot of power, and it is

recommended that caution be used by the person examining or changing spaces containing critical

structures.

used for D 3 assembly code debugging, has the capability of accessing and changing data directly

on the disk.

A thorough familiarization with the virtual assembler is recommended prior to using the debugger,

as it can be very destructive.

tool for recovery in case of a system crash, following, for instance, a power failure.

The Monitor Debugger allows:

- Display and change D 3 virtual memory.

- Display and change ’real’ memory (remember that ’real’ memory is, in fact, Unix virtual memory).

- Force a flush of the D 3 memory space back to disk.

- Display, change the status of the system semaphores, to remove a dead lock situation.

- Get access to a locked system.

- Terminate processes, including doing a shutdown.

- Trace modifications to a memory area.

- Put low level break points in the virtual code.

MDS:

Only one per system. Items within the system dictionary (mds) point to account master

dictionaries. The "mds" file can only be accessed on the dm account.

Base and Modulo:

Files are stored on disk in blocks called frames. The frames are uniform in size (1048 bytes). The

primary file space physically consists of a contiguous set of disk frames. The beginning frame is

the base frame and the number of contiguous frames or groups (including the base frame) is the

modulo of the file. The modulo is defined at the time the file is created or resized. The system

automatically adds or removes frames to or from groups as the amount of data (number and/or size

of items) within the group expands or contracts. The frames added automatically by the system are

added to what is called the secondary file space. This means you do not need to re-dimension a file

as the amount of data in that file increases or decreases.

High Water Mark:

The highest address on the system that has held data.

back

MaxFid

The highest address on the system

back

Contains statistical information for each file on the system. Whenever a file is created, restored or deleted, this file is updated. "File-of-files" items are created when a file is restored or created.

This file is also used to locate files on the disk during restores from incremental and transaction-log tapes.

The item-ids are sequential file numbers assigned when the file is created. File number one (1) is always the "file-of-files" file and file number two (2) is always the "mds" file. The numbers of the other files are determined by the order in which they are restored or created. On a file or account restore, the files are recreated in the order in which they were saved on the file save media.

The item "restored" in the dict of the "file-of-files" contains the time in attribute 1, and the date in attribute 2 of the last full restore. This item should not be deleted or modified.

"fof" and "stat-file" are synonyms (q-pointer) of "file-of-files".

The attributes in the "file-of-files" file are:

ac attribute-name description

0 f-fms Total number of frames in the primary file space as of last file save.

0 f-size Total number of bytes in the primary file space as of last file save.

0 file# Item-id assigned in order in which file was created.

0 t-frames Total number of frames in the file space as of last file-save.

0 stat.acc Sum of all reads and writes

0 stat.ovf Sum of all overflow group accesses

0 sug.mod Suggested modulo for this file, based on file-of-files

information.

1 md Name of the md owning the file.

2 file-name File name stored in the master dictionary (md) of the account.

3 data-name One dictionary may have many subsidiary data files each with its own unique name. The default data section name is

identical to the file name as stored in the md.

4 base Base of file.

4 mod Modulo of file. The number of contiguous frames comprising the primary file space.

4 modulo Modulo of file. The number of contiguous frames comprising the primary file space.

5 items Total number (including pointer items) of items in file from last file save.

6 ptr-items Number of pointer items saved in last file save.

7 ovf-itms Number of item which were partially or wholly stored in secondary file space during the last file save.

8 bytes Total number of bytes in file as of last file save.

9 ptr-bytes Total number of bytes in all pointer items as of last file save.

10 frames Total number of frames in file as of last file save. (Does not include index frames).

11 ptr-fms Total number of frames of pointer items as of last file save.

12 svdate Date when file was last saved.

13 reel# Tape, diskette, etc. number in a multi-’reel’ file save where this file begins.

14 seq# Decimal sequence number indicating the order in which the file was saved on the file save media.

15 opendate Date when file was last opened (update at save-time).

16 stat# Number of last file save on which this file was saved.

17 mask Masks desired operations from being logged in attributes 18-

20. Currently supported masks are: "c" clear file; and "d" delete-file.

18 file-code Valid file statuses are: "c" clear file; "d" delete file; "n" new file; "r" rename file; "t" restored from tape. 

This attribute controls attributes 19 (timedate) and 20 (user).

19 timedate Time-date when file activity occurred. This attribute is dependent on attribute 18 (file-code).

20 user User id concatenated with account id causing the associated file action.

 This attribute is dependent on attribute 18 (file-code).

21 dx/dy-date Date when dx/dy file was skipped on save.

25 save-list Contains list of specific items to be saved for this file. Used to selectively save items in a file. Each item name is a

value. To save all items in a file, use an asterisk (*).

29 stat.date Contains the date when the file access statistics were last cleared.

30 stat.rdu Number of READU operations on the file.

31 stat.rdub Number of blocked READU operations on the file.

32 stat.rdul Number of READU LOCKED operations on the file

33 stat.rdulb Number of blocked READU LOCKED operations on the file.

34 stat.rdptr Number of pointer items read.

35 stat.rd Total number reads on the file.

36 stat.wtu Number of WRITEU operations to the file

37 stat.wtb Number of blocked writes to the file

38 stat.wtptr Number of pointer items written.

39 stat.wt Total number of writes to the file.

40 stat.sel Total number of selects on the file.

41 stat.dels Total number of deletes to the file.

42 stat.clr Total number of clear-file’s done on the file.

43 stat.open Total number of open’s on the file.

44 stat.ovf Read overflow group accesses.

45 stat.wtovf Write overflow group accesses.

46 read-date Last date the file was read.

47 write-date Last date the file was written.

60 Seg.Bas Segment bases for resized files.

61 Seg.Mod Segment modulos for resized files.

back

validates the integrity of "file-save" or "account-save" backups.

The process can compare the contents of the backup media with the corresponding data on disk, or

simply check the media to ensure that it has the correct backup format.

This process first attempts to attach to the tape. If it is already attached to another process, the

following message appears:

tape attached to line {port.number}

[1144] the tape is not available for use now.

"port.number" is the port with the tape attached. See the "where" command. The process with a "t"

under the "stat" column has the media attached.

Items displayed are in file hierarchy format:

mds > account > dictionary > data section

By default, only account names are displayed. All errors found are displayed. The display pauses at

the bottom of each screen and disk and tape comparisons are made.

The "t-verify" is an option provided during the "file-save" process. If it is selected, errors are

logged to the "tv.log" file.

back

TCL

The Pick System Terminal Control Language (TCL) is a system-level command language with

system-defined or user-defined statements that can be executed individually or sequentially.

System-defined statements are called TCL verbs or commands. User-defined statements are:

macros, menus, PROC’s, and cataloged FlashBASIC programs. The first word of a TCL statement

must be either a system verb, macro, menu, PROC or cataloged FlashBASIC program.

TCL commands can be typed in when the TCL prompt ":" (colon) (or ">", when a select list is

active) displays. The completed command is entered for processing by pressing <return>, <enter>,

<linefeed>, or <ctrl>+m. Because mistakes do occur, the TCL editor (UP) and TCL command

stack facilities are provided. The UP/TCL editor allows corrections to commands after they are

entered, but before they are executed. The "tcl-stack" file stores every TCL command, so that they

may be recalled for correction and/or execution.

Semaphore Lock

A semaphore lock is a lock set on a process so that the owner of the lock is
the only owner that that can access that process until it is released.
B!s* <cr> shows all the semaphore locks.
Pick uses semaphore 
0 = allocation of port logon
This numbers is a HEX number. Convert this number to decimal to get 
the pib# --- then type 'ps -ef|grep <converted number> -- if not
found then add '1' as the first number, convert and then grep
again. if not found add 2 as the first number, convert and grep
again. ......
3 = write queue -- process is writing to disk. If you convert this hex
number to decimal you will have the pib#
S3- clears semaphore 3
S*- clear all semaphore locks

TAS Locks
A TAS lock override how I understand it is a Test And Set where the system is 

trying to protect a section of memory and cannot. The section of memory is
tested to see how long a process has locked this location. If the lock has 
been set for 5sec or a specified amount of time. The system says that the process 

should not have that section of memory that long and issues a TAS lock
override and takes it anyway. We typically will see this on multi processor
machines. Make sure that this system is running the current release of D3 

with all current patches.

Threads
Threads are objects within processes that run program instructions. They all are concurrent 

operations within a process to run different parts of its program on different processors simultaneously.

QCB
It is the queue where the system reads from to assign a port to anyone who is attempting to log to the 

VM.]]Queue Control Blocks (QCBs) are frames which are attached to the PCBs. Each PCB gets a QCB. 

The QCBs are kept in a linked chain. I don't know why that data structure is used, but we are locked into it. 

Each time someone logs on to the machine, the first semaphore is locked while the user gets his workspace, qcb, etc. 

There was a window of time, where it was possible that 2 or more users logging in at the same time or almost exact same time, might corrupt this chain of QCBs. The results of this would be that the next person trying to get onto the system 

would get that -1100 error; however, all those already logged on to the system would be fine and could stay on. 

This QCB structure (linked list) does not lend itself to being repaired easily. 

That is why a shutdown and reboot is necessary.

FlashBASIC

Converts Pick/BASIC source code into a list of binary instructions
called object code. 

The "run" verb initiates a program called an interpreter which reads
these instructions one at a time and executes the desired actions.
Taking this interpretive approach provides swift translation from
the Pick/BASIC source, platform independence, small object size, and
reasonable performance.

If better performance is desired, the Pick/BASIC compiler can
produce "FlashBASIC", or native assembly code from a standard
Pick/BASIC object. This FlashBASIC code may subsequently be run in
the Pick environment in the same manner as a regular Pick/BASIC
program with the exception that FlashBASIC code runs significantly
faster.

The "o" option with the "compile" or "basic" verbs invokes
different platform. Furthermore, FlashBASIC code cannot call
interpreted code, or vice-versa. In other words, if a mainline
program is compiled with the "o" option, all of its subroutines or
"entered" modules must also be created as FlashBASIC.

Choosing a FlashBASIC Level:
increase object size by as much as 100% over that achieved with
level 1, and increase compile time exponentially. Furthermore,
levels above 1 yield relatively small performance increases for most
applications. High levels also tend to use very large amounts of
Unix swap space. If the system runs out of swap space, FlashBASIC
retries with a lower level. Line numbers (for error messages) and
different platforms or releases.
string manipulation and lack significant amounts of screen or disk
I/O. Using a level of 9 can cut in half such programs' run time as
Producing FlashBASIC without source:

"as-is". However, it is suggested that future applications be
shipped with a Pick/BASIC program, PROC, or macro, that
the code to run on a single platform, and when media size is not an
issue.

Compiler Options for use with FlashBASIC:
f Uses floating point arithmetic

h By default, the FlashBASIC compiler attempts to create native
code that can be shared by all users. Using the "h" option forces
k This option, when used without the "h" option, forces shared
code to remain loaded until the machine is shut down. This option
should be used for programs needed by most users of the system. It
reduces memory usage and load time drastically when applied to
multi-user situations. See the "shpstat" program for monitoring the
Performance Tips for FlashBASIC:

To obtain the best possible run-time performance and compile-time,
The Pick/BASIC "@(x,y)" function speeds up from 10-20 times if the
"term" definitions are compiled with the "o" option. For instance,
driver. This creates a hidden module for use with FlashBASIC code.
For best results, use this feature with high baud rates and/or fast
display devices.

Avoid user exits. Standard Pick/BASIC routines compiled with
Notes:
In R83 and OA/RT, Pick/BASIC source code is compiled to a tokenized
object code which is then interpreted when run.
In AP and D3/Unix, Pick/BASIC source code may be compiled in the
traditional way, or it may be optimized, or "Flash'ed". When
optimized, the Pick/BASIC source code is translated to C source
code, and then compiled using the host machine's C compiler,
producing machine-specific assembly language object code. 
In D3/NT, Pick/BASIC source code may also be compiled in the
traditional way, or it may be optimized, or "Flash'ed". In this
sense, though, the Pick/BASIC source code is compiled to an
"optimized" tokenized object code which is then interpreted when
run. This object code runs considerably faster than the original
tokenized object code, but not quite as fast as the assembly
language code of the C compiler. 

Since the advent of Flash-able source code, the language is referred
to as FlashBASIC, and the term "Pick/BASIC" is obsolete.