HP 3000 Manuals HP 3000 Manuals
Appendix A Spool File Block Format (SBF)
All regular MPE disk files have one of three logical record formats:
fixed length, variable-length, or undefined length. We usually speak of
a file in terms of its record format, for example, "variable-length
file". Spool files are variable-length files with additional
overhead. Here is a quick review of the essential elements of any MPE
variable-length file.
When you specify a record length and/or blocking factor for a variable
length file, you tell the file system how large the physical record
should be. For MPE V/E systems, the physical record determines how disk
storage is allocated. We limit the present discussion to disk files.
For MPE/iX systems, disk storage is allocated differently, so the
physical record is now more of an abstraction that defines a fixed limit
to variable-length records. In practice this means that if the next
logical record to be added to the file does not fit in the current
physical record, a new physical record must be started for it.
Table A-1 shows a typical physical record consisting of several
variable-length logical records.
Table A-1. Physical Record (Block)
--------------------------------------------------------------------------------------------
| | |
| byte count |.................................... | |
| | |
--------------------------------------------------------------------------------------------
| | |
| ...................| byte count |................ | |
| | |
--------------------------------------------------------------------------------------------
| | |
| : | |
| | |
--------------------------------------------------------------------------------------------
| | |
| .....| byte count |.............................. | |
| | |
--------------------------------------------------------------------------------------------
| | |
| ..................................| -1 |///////// | |
| | |
--------------------------------------------------------------------------------------------
Because each record may have a different length, when you write a record
to the file, the file system prefixes the record with a 16-bit byte
count. The byte count represents the number of data bytes in the record,
excluding itself and (for ASCII files) any unused odd byte at the end of
the record. Within a given physical record, the file system uses these
byte counts to find the start of the next logical record relative to the
start of the current one.
Logical records never span a physical record boundary, so eventually
there comes a time when you write a record that does not fit in the space
remaining in the current physical record. When the file system discovers
this situation, it writes a special byte count of -1 (octal 177777), then
writes your record at the start of a new physical record. The space
between the -1 and the end of the physical record is not used. (Later,
when you read the file, the -1 alerts the file system that there is no
more data in the current physical record and that it should retrieve your
next record from the next physical record).
A spool file is a special case subset of a variable-length file:
* Its physical record (block) length is always 1K (1024) bytes.
* It is always an ASCII (never a binary) file.
* In addition to the byte count shown above, each record contains
four more 16-bit fields (eight more bytes) of overhead (described
below).
* The first byte of the data portion of the record may be a carriage
control (CCTL) byte; if so, it too is considered overhead.
* The last four bytes of each physical record contain a record
count, thereby shortening by four the number of bytes available
for spool file records.
Table A-2 displays a typical spool file block.
Table A-2. Spool File Block
--------------------------------------------------------------------------------------------
| | |
| physical byte count | logical byte count | func | P1 | P2 |.............. | |
| | |
--------------------------------------------------------------------------------------------
| | |
| .........| physical byte count | logical byte count | func | P1 | P2 |..... | |
| | |
--------------------------------------------------------------------------------------------
| | |
| : | |
| | |
--------------------------------------------------------------------------------------------
| | |
| ....| physical byte count | logical byte count | func | P1 | P2 |.......... | |
| | |
--------------------------------------------------------------------------------------------
| | |
| ........................| -1| ////////////////// | 1st record of block | |
| | |
--------------------------------------------------------------------------------------------
Field Description
Physical byte count Same as the "byte count" shown in table A-1. The
new name distinguishes it from "logical byte
count".
Logical byte count The original byte count of the data portion of the
spool file record (nominally everything between the
P2 field and the physical byte count field of the
next record). It was included originally so that
trailing blanks of a record could be left out of
the spool file and reinserted at some lower
printing level such as the printer driver, if
necessary. In practice it has not been used this
way, so its value is usually eight less than the
physical byte count (remember that the physical
byte count does not include itself). Further
discussion is beyond the scope of this description.
Func, P1, P2 These are low-level printer parameters. Originally
they were part of the MPE V/E privileged interface
to ATTACHIO. Although the native mode spooler does
not use ATTACHIO, the position and function of
these parameters have been retained. A complete
description is beyond the scope of this appendix,
but generally speaking, FUNC is a printer function
code (such as write or control), while P1 and P2
("P" for "parameter") vary with function code and
further define the operation to be performed.
First record of This is an ordinal whose value is the record number
block (relative to the start of user data in the spool
file; 0 is the first record) of the first record of
the current spool file block. For example, if the
first block of user data consists of 8 records (0
through 7), the field at the end of the first block
is 0 and the field at the end of the second block
is 8 (because record 8 is the first record in the
second block). This field was added to MPE V/E
spool files to allow pseudo-direct access to any
record in the spool file. It has been retained
in native mode spool files. Ordinarily,
variable-length files must be read serially. This
means that to display record 10000 you have to read
and discard records 0-9999; however, using
multirecord NOBUF access and binary search
techniques, this field allows you to access record
10000 much more rapidly.
______________________________________________________________________________
| |
| PARAMETER VALUE MEANING |
| |
| FUNC 1 Write |
| P1 1 The first byte of the data portion |
| of the record is a carriage |
| control (CCTL) byte, usually the |
| one specified by a user in his/her |
| FWRITE intrinsic call. It is not |
| part of the user data and should |
| not be displayed on the printer. |
| P1 <> 1 P1 is itself the CCTL byte. The |
| first byte of the data portion is |
| part of the user data and should |
| be displayed. |
| P2 Bitmask If the least significant bit (15) |
| is 1, the record is to be printed |
| in prespace mode. |
| If it is 0, the record should be |
| printed in postspace mode. See the |
| note below. |
| If bit 14 is 1, certain printer |
| operations are carried |
| out without regard for the |
| perforation area separating two |
| sheets of Z-fold paper. If bit 14 |
| is 0, these operations skip |
| over the perforation area, if |
| necessary. Refer to the |
| MPE/iX Intrinsics Reference Manual (32650-90028)|
| for details. |
| All other bits are reserved. |
______________________________________________________________________________
Figure A-1. Example: FUNC, P1, P2
In postspace mode, the data in the record is sent to the printer before
the CCTL byte is interpreted and sent. In prespace mode, the CCTL byte
is interpreted and sent first, followed by the data.