Gets information about an FZ unit LUN one may which will load the communication area
COMMON /FZSTAT/ INFLUN, INFSTA, INFOFZ(40)
with
INFLUN = LUN if success,
= 0 if unit LUN was not found, in which case
the rest of the information is useless.
INFSTA = a copy of the status word and
INFOFZ = the first 40 data words of the FZ control bank for LUN.
Details about the significance of the returned information are found below.
The lay-out of the control-bank has changed with version 3.66.
link 2 points to the associated text buffer
@: address is LQFy, shortened to '@' y = F or I or X
@ -5 LUNy
@ +0 MSTATy status word of the control bank
MEDIUy bit 1-3: medium: 0 disk, 1 T tape, normal
2 K disk, 3 TK tape, user
4 C disk, 5 TC tape, channel
6 M memory
IFIFOy bit 4-6: file fmt: 0 native
1 X exchange sequential
2 D direct-access
3 M memory
4 A alfa
IDAFOy bit 7: data fmt: 0 native, 1 exchange
IACMOy bit 8-10: access: 0 F Fortran
1 Y special
2 L c library
3 C channel
bit 11: read permission
bit 12: write permission
bit 13-14: NEOF = 0, 1, 2, or 3
bit 15: option S for separate d/ss
IUPAKy bit 16: option U for unpacked d/ss
@ 1 IADOPy Channel: adr of user routine
Memory: current memory pointer
@ 2 IACTVy last activity:
= 0 file unused 10 switch input to output
or: rewind to over-write
or: new output file connected
1 read start-of-run 11 write start-of-run
2 read d/s 12 write d/s
3 read end-of-run 13 write d/s, buffer flushed
4 read Zebra end-of-file 14 write end-of-run
5 read system end-of-file 15 write end-of-file
6 read end-of-data 16 write end-of-data
7 attempted read beyond 17 attempted write beyond EoD
8 rewind after read 18 rewind after write for input
or: new input file connected
@ 3 INCBFy incr. to go to the buffer param.: LBPARy = LQFy + INCBFy
@ 4 LOGLVy logging level
@ 5 MAXREy native mode: maximum logical record size
exchange file format: physical record size
@ 6
@ 8 Memory: LMEM: User memory starts at IQ(LMEM)
@ 9 Memory: NWMEM: Size of the user memory
@+11 number of system file marks
@ 12 number of Zebra EoF signals
@ 13 number of end-of-run records
@ 14 number of start-of-run records
@ 15 number of pilot records
@ 16 number of non-empty d/s
@ 17 number of empty d/s
@ 18 number of errors
@ 19 number of Mwords read/written
@ 20 number of words read/written (up to 1 M)
@ 21 number of good logical records
@ 22 number of good physical records (exchange file format)
@ 23 number of steering blocks (exchange file format)
@ 24 number of conversion problems (exchange data format)
@ 26 input: last read status returned
@ 27 input: LRTYP status of last record read
@ 28 number of pilots printed by last statistic message
@ 29 current run number
@ 30 input: pending: 0 nothing, 1 EoF, 2 st/end of run
@ 31 DsA word 1: record # for current d/s
@ 32 DsA word 2: offset
@ 33 current record number for direct-access
if -ve: FZINXT called, reset from previous
@ 34 saved DsA word 1 of the direct access table
@ 35 word 2
@ 41 NWTB, number of table words
@ 42 NWBK, number of words of bank material
@ 43 LENTRY, entry adr to d/s
@ 50 NWIOI, number of words in I/O characteristic
@ 51 -> 66 I/O characteristic for last user header vector
@ 68 NWSEG, number of words in the segment table
@ 69 ->128 last segment table read
@130 NTBE, number of early table words (only if native file format)
@131 -> 170 early table
buffer parameters in the control bank, LBPARI = LQFI + INCBFI
-9 non-zero if last LR abended
next physical record ready in the buffer if N4ENDI not zero
-7 expected next PhR number
-6 zero if current block is steering,
= 1 if last fast block in burst, =2 if last-but-one, etc
-5 number of fast blocks to follow current block
-4 N4SKII, # of words to be skipped before next transmission
-3 N4RESI, # of words still to be read for current LR
-2 N4DONI, # of words of the current buffer already done
-1 N4ENDI, # of words in buffer before start of next LR
if = buffer-size: record continues in next PhR
LBPARI+0 maximum size of buffer, file words
+1 expected size of PhR, machine words
+2 displacement from LBPAR to start-of-buffer LSTO
+3 off-set from start-of-buffer to read position for packed records
+4 off-set for writing
LSTO = LBPARI + IQ(LBPARI+2)
LSTO -1 space for left half of double-precision number spanning PhRs
LSTO +0 start-of-buffer: read (if 32-bit machine) or unpack into here
@ 37 limit: Mega-words
@ 38 limit: words
@ 39 original parameter from FZLIMI
buffer parameters in the control bank, LBPARX = LQFX + INCBFX
-6 zero if current block is steering,
= 1 if last fast block in burst, =2 if last-but-one, etc
-5 number of fast blocks to follow current block
-4
-3 N4RESX, # of words still to be done for current LR
-2 N4DONX, # of words of the current buffer already done
-1
LBPARX+0 maximum size of buffer, file words
+1 size of PhR, machine words
+2 displacement from LBPAR to start-of-buffer LSTO
+3 off-set for input
+4 off-set for output
LSTO = LBPARX + IQ(LBPARX+2)
-1 free to allow packing with shift
LSTO +0 start-of-buffer for accumulation
last buffer-word + 1:
space for right half of a double-precision number
spanning physical records
To allow files in exchange mode to travel on networks which cannot handle binary file transfer, a conversion to and from card-images is provided. This uses a sub-set of the 64-character ASCII set to represent the binary contents of a file in exchange file and data format.
The easiest way, from the coding point-of-view, would be to generate a hexadecimal dump of the binary file. But this is too simple in several respects:
The file produced or expected by FZOUT/FZIN in 'ALFA mode' consists of card-images of 80 columns exactly, written by FORTRAN formatted WRITE statements. Column 1 of all lines is blank, except for the first and the last line representing the start and the end of an original physical record. Blocking, if any, is under control of the user with the JCL. On an IBM the character set is EBCDIC, on a CDC Display code, on most other machines it is ASCII. Translation, if any, is expected to happen in the network stations. Such files are not written to tape.
An original 32-bit binary word is unpacked onto seven 5-bit bytes:
I(1) = bits 31,32
I(2) = bits 26 -> 30
...
I(6) = bits 6 -> 10
I(7) = bits 1 -> 5
In general this word is represented by 7 characters:
The first character C(1), called the type-character, combines the information I(1) with more information about possible shortening of the representation.
The remaining 6 bytes I(j) are translated into the characters C(j) whose CETA values are I(j)+1:
value 0 1 2 ... 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
char. A B C R S T U V W X Y Z 0 1 2 3 4 5
Small integers contain several leading bytes of value zero (or 31 for negative integers), the number N of such bytes is encoded into C(1), and the characters C(2 to N+1) are not output. A similar scheme is applied to words with trailing bytes I(j to 7) of value zero.
Very small positive integers, with value less than 10, are given a one character representation, and the encoding for C(1) is arranged such that the integers 0 to 9 stand for themselves.
The construction of C(1) is shown by this figure:
I(1) ooooo 11111 22222 33333 ooooo oooooooooo 33333
I(2) xxxxx xxxxx xxxxx xxxxx ooooo oooooooooo -----
I(3) xxxxx xxxxx xxxxx xxxxx xoooo oooooooooo x----
I(4) xxxxo xxxxo xxxxo xxxxo xxooo oooooooooo xx---
I(5) xxxoo xxxoo xxxoo xxxoo xxxoo oooooooooo xxx--
I(6) xxooo xxooo xxooo xxooo xxxxo oooooooooo xxxx-
I(7) xoooo xoooo xoooo xoooo xxxxx o123456789 xxxxx
main type 1 2 3 4 5 0 6
sub-type 01234 01234 01234 01234 01234 01234
type-code 11111 11111 22222 2222333333 33334
01234 56789 01234 56789 01234 6789012345 67890
type-char. ABCDE FGHIJ KLMNO PQRST UVWXY 0123456789 +-*/(
'x' stands for any value not zero, except in Main type 6 where '-' stands for a value of 31, and where 'x' stands for any value not 31.
One can see that main types 1 to 4 cover the general case and also shortening for trailing zero bytes. Main types 5 and 6 cover positive and negative short integers, very small positive integers have main type zero.
This is done by following the first number of the set by the special character '=', not a member of the ordinary type-characters A to Z, 0 to 9, + to (, followed by the short integer N (represented like all other integers). This signals to the reading program that the last number has to be repeated N+1 times.
XBA=YU XBA and YU are the small integers 32 and 20,
hence this stands for 22 words containing 32.
/45=9 /45 and 9 are the small integers -33 and 9,
hence this stands for 11 words containing -33.
0=XMO 0 and XMO are the small integers 0 and 398,
hence this stands for 400 words of all zeros.
This surely is unreadable, but it is not meant for the human eye.
If a set of consecutive numbers all have the same type character, the first number is preceded by the special character '[', the type is omitted for all numbers except the first, and the last number is normally followed by the special character ']' (the characters '[' and '=' also terminate a set of same type-characters).
[XBA MO MP MQ [YU V W A B C X Y Z 0 1 2 3 4 5]
represent the numbers
32 398 399 400 20 21 22 0 1 2 23 24 25 26 27 28 29 30 31
(the blanks are typed for readability, they are not present on the file).
The first line of the dump of each physical record carries the special character '>' in column 2, normally also in col. 1. Column 3 of the first line has '0' or '1' if the record is a fast or a control record. The last line carries the symbol '<' in column 1. The last number of the record, normally on the last line, is followed by '<', followed by the two check-sum numbers. The check-sums are obtained by addition, separately for bits 17 to 32 and bits 1 to 16, of the binary value of each number written. A second '<' could be given instead of the 2 check-sum numbers to suppress the check.
On UNIX machines, and if Zebra has been installed with the FZLIBC option, one can select user I/O for a particular file by giving the K option to FZFILE. As with the L option this causes the I/O requests to be channelled to the routines CFPUT, CFGET, etc.
To code user I/O one has to take the source of these routines and add a new branch, or two, into each one to do what one wants to do.
One finds the source of these routines on the Pam file KERNFOR in P=CCGENCF; there is also the Fortran dummy routine P=TCGEN, D=CFWEOF to write system file-marks. Careful, it is possible that there is a machine-specific implementation of these routines; for example if one wanted to do this on the Sun one should check that KERNSUN does not contain versions of these routines (it does not right now).
The second parameter for each routine is MEDIUM, and on entry its value selects the wanted branch. MEDIUM is 0,1,2,3 for L,TL,K,TK selected with FZFILE for the that file. Be careful not to destroy the existing path.
The problem arises because the VAX, and also DECstation, loads computational registers with bytes of increasing address starting at the right moving to the left, whilst tape, disk, and memory are mapped according to increasing byte address. For example, supposing we had an exchange format record starting with the following numbers:
1 - bit pattern: hex 0123CDEF 2 - integer: 292 hex 00000124 3 - floating: 1.0 hex 3F800000 4 - Hollerith: ABCD hex 41424344 ...
the record would start with the following bytes:
number: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ... value : 01 23 CD EF 00 00 01 24 3F 80 00 00 41 42 43 44 ...
Reading the record to memory will transmit the bytes in this order to increasing byte addresses, but under the VAX optic showing association to registers we have to write it as:
number: ... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 value : ... 44 43 42 41 00 00 80 3F 24 01 00 00 EF CD 23 01
This is right as it is only for Hollerith (for which this scheme has been designed, of course), but it is upside-down for integers and bit patterns; floating-point has to be converted anyway.
Since all the control-information is integer, and Hollerith is relatively rare, FZIN on the VAX for simplicity (and speed) converts the whole record with one call (to VXINVB), inverting the 4 bytes of each word, giving:
number: ... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 value : ... 41 42 43 44 3F 80 00 00 00 00 01 24 01 23 CD EF
Conversion from Exchange Data Format to VAX internal transforms only floating-point and Hollerith, the integers being ready, giving:
number: ... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 value : ... 44 43 42 41 00 00 40 80 00 00 01 24 01 23 CD EF
FZOUT on the VAX goes through the inverse process.
Byte inversion in FZIN/FZOUT operates only for exchange data format; bytes are not swopped for native data format, not even with the exchange file format.
Global CERN library references
/user/goossens/cnasall/cnasbibl,/user/goossens/cnasall/textproc}