chris@cooper.UUCP (10/30/86)
Re: Stream Files again.
Thanks,
Most people sent 'C' code. Normally useful but the site
lacks a VAX C compiler, but I do appreciate them for use at other sites.
Two sent very interesting FDL files for the conversion very much like
ones I had devised myself. Only two of the responses I got were of the form:
"What you must be running VMS 3.1 and are extremely stupid."
Thanks VERY much to all the people who sent helpful suggestions.
I greatly appreciate the time you took to try and solve my problem.
Unfortunately, no suggestion worked. (Well I couldn't try the 'C' code
but it will help later on other sites with a 'C' license.)
So I this time I'll review the whole laborious problem:
We received a tape with a beta-test the latest version of XROFF from
Image Network. XROFF is a ditroff (troff) compatible product which
include TBL,EQN, and PIC (if you pay for it).
Well, they had sent modules compiled for VMS 4.4 which made nasty complaints
about our shared libraries and wouldn't run.
It would have been nice if the executables had worked first shot
but I understand there were massive changes in DEC's support for
'C' which resulted in these incompatiblities. (Well DEC didn't
like UNIX at first either :-)
Since grant season was upon us I was NOT about to upgrade to 4.4 during
paper writing which provides the money to keep the site going.
("Gee, they renamed DELETE to TYPE in VMS X.Y and
all your work is gone, and you did it all today so it wouldn't be on the
backup? No, no, pounding the machine into dust isn't going to help." :-)
So naturally, I relinked all the programs and they worked just fine, except
for a conversion utility CP1.EXE. Unusually the XROFF people neglected
to include the object module for CP1. This utility simply copies their
final stream_lf output file into a more normal fixed file type
which other utilities are much more fond of.
So I tried the previous releases' CP1. No dice. It produced
a very nice fixed file of NULLs. I checked the original stream_lf output file
with DUMP and found it was full of proper HP LaserJet escape sequences.
Okay so now I tried a number of combinations of CONVERT/FDL,
APPEND'ing to an already correctly formatted file (an early VMS trick I
used to use for EUNICE files), and a number of other things.
The new version of XROFF just arrived with a new version of the CP1 object
modules and it seems to work, but I would like to be able to work
with these nasty intermediate files since I want my version of Fortran
Kermit for VMS to be able to handle these nasty buggers.
I think the QIO error results from exceeding some DIO or BIO quota,
but I would rather find a way which avoids changing all the user
quotas. I'm curious about why the ANA/RMS fails on this file.
I suppose I shouldn't let this get to me but I found if I hit a problem
usually I have to help someone with the same problem within a year
or two, so I would like to figure this out. ( I do have a real ugly
way which I used to read funny tapes before I figured out FDL's.
Place the DUMP of the file in a file. Read that file, decode the hex
and place the output it a nice normal file. Talk about ugly.)
Something tells me that the answer to this one is not "Fixed in 4.4".
So finally, here's the problem again. Does anyone have any non-C code or FDL's
or explainations on how or why I can't write this file (K.C) to a
terminal port?
Thanks for enduring all this
Chris Lent
ihnp4!allegra!phri!cooper!chris
(203) 452-1422
(Note: this is being posted from a different site than the original posting.)
Descriptive session log follows:
(Sorry, this is so long but some people requested proof.)
(I removed VMS's formfeeds from the ANA/RMS output so not to upset various
mailers.)
CUPHOA::$ ! This is on VMS 4.2
CUPHOA::$ dir/full k.c
Directory SYS$USERDEVICE:[LENT.XROFF.TEST]
K.C;1 File ID: (19345,18,0)
Size: 27/27 Owner: [VMS,LENT]
Created: 20-OCT-1986 16:10 Revised: 20-OCT-1986 16:10 (1)
Expires: 4-DEC-1986 22:43 Backup: <No backup done>
File organization: Sequential
File attributes: Allocation: 27, Extend: 0, Global buffer count: 0
No version limit
Record format: Stream_LF
Record attributes: Carriage return carriage control
File protection: System:RE, Owner:RWED, Group:, World:
Access Cntrl List: (IDENTIFIER=[VMS,LENT],ACCESS=READ+WRITE+EXECUTE+DELETE+
CONTROL)
(IDENTIFIER=[VMS,TALBOT],ACCESS=READ+EXECUTE)
Total of 1 file, 27/27 blocks.
CUPHOA::$ ana/rms k.c
Check RMS File Integrity 28-OCT-1986 22:47:37.28 Page 1
SYS$USERDEVICE:[LENT.XROFF.TEST]K.C;1
FILE HEADER
File Spec: SYS$USERDEVICE:[LENT.XROFF.TEST]K.C;1
File ID: (19345,18,0)
Owner UIC: [116,005]
Protection: System: RE, Owner: RWED, Group: , World:
Creation Date: 20-OCT-1986 16:10:10.34
Revision Date: 20-OCT-1986 16:10:10.83, Number: 1
Expiration Date: 4-DEC-1986 22:43:07.44
Backup Date: none posted
Contiguity Options: none
Performance Options: none
Reliability Options: none
Journaling Enabled: none
RMS FILE ATTRIBUTES
File Organization: sequential
Record Format: stream-LF
Record Attributes: carriage-return
Maximum Record Size: 0
Longest Record: 0
Blocks Allocated: 27, Default Extend Size: 0
End-of-File VBN: 27, Offset: %X'008A'
Global Buffer Count: 0
*** VBN 16: Last stream record does not contain a delimiter.
*** Drastic structure error precludes further analysis.
The analysis uncovered 2 errors.
ANA/RMS K.C
CUPHOA::$ copy k.c tta1:
%COPY-E-WRITEERR, error writing TTA1:[]K.C;1
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, exceeded quota
%COPY-W-NOTCMPLT, SYS$USERDEVICE:[LENT.XROFF.TEST]K.C;1 not completely copied
CUPHOA::$ type f.fdl
FILE
ORGANIZATION sequential
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL carriage_return
FORMAT variable
CUPHOA::$ conv/fdl=f.fdl k.c k.txt
CUPHOA::$ dir/full k.txt
Directory SYS$USERDEVICE:[LENT.XROFF.TEST]
K.TXT;1 File ID: (19340,6,0)
Size: 27/27 Owner: [VMS,LENT]
Created: 28-OCT-1986 22:49 Revised: 28-OCT-1986 22:49 (1)
Expires: 4-DEC-1986 22:49 Backup: <No backup done>
File organization: Sequential
File attributes: Allocation: 27, Extend: 0, Global buffer count: 0
No version limit
Record format: Variable length, maximum 5469 bytes
Record attributes: Carriage return carriage control
File protection: System:RE, Owner:RWED, Group:, World:
Access Cntrl List: (IDENTIFIER=[VMS,LENT],ACCESS=READ+WRITE+EXECUTE+DELETE+
CONTROL)
(IDENTIFIER=[VMS,TALBOT],ACCESS=READ+EXECUTE)
Total of 1 file, 27/27 blocks.
CUPHOA::$ copy k.txt tta1:
%COPY-E-WRITEERR, error writing TTA1:[]K.TXT;1
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, exceeded quota
%COPY-W-NOTCMPLT, SYS$USERDEVICE:[LENT.XROFF.TEST]K.TXT;1 not completely copied
CUPHOA::$ show dev tta1:/full
Terminal TTA1:, device type LA24, is online, record-oriented device, carriage
control.
Error count 0 Operations completed 22381
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWLP,O:,G:,W:RWLP
Reference count 0 Default buffer size 132
CUPHOA::$ sh term tta1:
Terminal: _TTA1: Device_Type: LA100 Owner: No Owner
Input: 9600 LFfill: 0 Width: 132 Parity: None
Output: 9600 CRfill: 0 Page: 66
Terminal Characteristics:
Interactive Echo No Typeahead No Escape
No Hostsync TTsync Lowercase Tab
Wrap Hardcopy No Remote No Eightbit
Broadcast No Readsync Form Fulldup
No Modem No Local_echo No Autobaud No Hangup
No Brdcstmbx No DMA No Altypeahd Set_speed
No Line Editing Overstrike editing No Fallback No Dialup
No Secure server No Disconnect No Pasthru No Syspassword
No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad
No ANSI_CRT No Regis No Block_mode No Advanced_video
No Edit_mode No DEC_CRT No DEC_CRT2
CUPHOA::$ ! Gee I wonder why one says LA24 and one LA100
CUPHOA::$ create/fdl=f.fdl nice.txt
CUPHOA::$ dir/full nice.txt
Directory SYS$USERDEVICE:[LENT.XROFF.TEST]
NICE.TXT;1 File ID: (19342,5,0)
Size: 0/0 Owner: [VMS,LENT]
Created: 28-OCT-1986 23:29 Revised: 28-OCT-1986 23:29 (1)
Expires: 4-DEC-1986 23:29 Backup: <No backup done>
File organization: Sequential
File attributes: Allocation: 0, Extend: 0, Global buffer count: 0
No version limit
Record format: Variable length
Record attributes: Carriage return carriage control
File protection: System:RE, Owner:RWED, Group:, World:
Access Cntrl List: (IDENTIFIER=[VMS,LENT],ACCESS=READ+WRITE+EXECUTE+DELETE+
CONTROL)
(IDENTIFIER=[VMS,TALBOT],ACCESS=READ+EXECUTE)
Total of 1 file, 0/0 blocks.
CUPHOA::$ append
_From: k.c
_To: nice.txt
%APPEND-W-INCOMPAT, SYS$USERDEVICE:[LENT.XROFF.TEST]K.C;1 (input) and SYS$USERDEVICE:[LENT.XROFF.TEST]NICE.TXT;1 (output) have incompatible attributes
CUPHOA::$ copy nice.txt tta1:
%COPY-E-WRITEERR, error writing TTA1:[]NICE.TXT;1
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, exceeded quota
%COPY-W-NOTCMPLT, SYS$USERDEVICE:[LENT.XROFF.TEST]NICE.TXT;1 not completely copied
CUPHOA::$ ana/rms/fdl k.c
CUPHOA::$ type k.fdl
IDENT "28-OCT-1986 23:30:42 VAX/VMS ANALYZE/RMS_FILE Utility"
SYSTEM
SOURCE VAX/VMS
FILE
ALLOCATION 27
BEST_TRY_CONTIGUOUS no
CLUSTER_SIZE 1
CONTIGUOUS no
EXTENSION 0
GLOBAL_BUFFER_COUNT 0
NAME "SYS$USERDEVICE:[LENT.XROFF.TEST]K.C;1"
ORGANIZATION sequential
OWNER [116,5]
PROTECTION (system:RE, owner:RWED, group:, world:)
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL carriage_return
FORMAT stream_lf
SIZE 0
----------End of session log-----------------------------------------
(Sorry this was so long but I'm trying show to some individuals I'm
not nuts.)
Chris Lent ihnp4!allegra!phri!cooper!chris (203) 452-1522cetron@UTAH-CS.ARPA (Edward J Cetron) (11/01/86)
could this problem be more of the kind seen with GNU emacs where there is no final lf as a delimiter in the last record??? If so, I believe a quick zap can fix that..... you might want to check the archives for several messages from Marty Sasaki et. al. about this same problem re: GNU emacs... -ed cetron
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (11/02/86)
ANALYZE/RMS fails because the last record of the file isn't terminated by a newline. You're trying to output a 5469-byte record to a TERMINAL?????? In a single QIO!!!!!!! Suggestions: Append a record consisting of a newline to the file, and RMS should be happy with the result. Write a program that will read the file with the huge records then send the long records to the terminal in more digestible pieces (say, less than 512 bytes per QIO). You can do this in fortran by opening the file for formatted I/O, using the Q format descriptor to get the recordsize, and reading the record into a buffer using an A format (or a series of buffers using several A formats), being careful to ask for only the number of bytes in the record). You then use several writes, using the $ descriptor (as the last descriptor for the record, as I recall; it's in the manual) to suppress carriage control, to write the data to the terminal.
LEICHTER-JERRY@YALE.ARPA (11/03/86)
Re: Stream Files again.
[The author reports a variety of problems with the following file:]
Directory SYS$USERDEVICE:[LENT.XROFF.TEST]
K.C;1 File ID: (19345,18,0)
Size: 27/27 Owner: [VMS,LENT]
File organization: Sequential
File attributes: Allocation: 27, Extend: 0, Global buffer count: 0
No version limit
Record format: Stream_LF
Record attributes: Carriage return carriage control
FILE HEADER
File Spec: SYS$USERDEVICE:[LENT.XROFF.TEST]K.C;1
RMS FILE ATTRIBUTES
File Organization: sequential
Record Format: stream-LF
Record Attributes: carriage-return
Maximum Record Size: 0
Longest Record: 0
Blocks Allocated: 27, Default Extend Size: 0
End-of-File VBN: 27, Offset: %X'008A'
Global Buffer Count: 0
*** VBN 16: Last stream record does not contain a delimiter.
*** Drastic structure error precludes further analysis.
A STREAM_LF file is, to RMS, a record-oriented file - EVERYTHING is a record-
oriented file! For a STREAM_LF file, records are terminated by linefeeds;
that is, the first record runs from byte 0 to the first LF; the second from
just after the LF to the next LF; and so on. The last record in the file
is terminated by the end of the file, if there are no further LF's.
K.C appears to contain no LF's at all. This produces two problems:
1. Since there are no LF's, the file appears to consist of a single
very long record - about 27*512 bytes long (the final block
may not be full - there's a "first free byte in last block"
value in the header - I think that's what the "Offset " is.
All the usual utilities set up buffers of some "reasonable"
size - 1024 bytes, or whatever. When they then try to read
this file, their record buffers overflow and they die.
Note that there's a field in the header that indicates how
long the longest record in the file is. Programs can and
often do use this to allocate record buffers. In this case,
however, the value is 0, meaning "unspecified", so programs
have to guess. (A value of 0 here is usually the result of
doing block operations to a record file.)
2. I said above that the last record ends at a final LF, or at the
end of the file. Well, that's not QUITE true. There's a
bug in RMS that causes it to die - killing your process -
if you try to read a STREAM_LF file with no trailing LF.
(This bug has been reported many times; I don't know if it's
fixed in V4.4 or V4.5 or V4.?. It's certainly in V4.3.)
Your processes aren't running into the bug apparently because
RMS is running into the "record too long for user's buffer"
problem before reaching the end of the file. ANALYZE/RMS
IS running into the problem, but apparently is able to deal
with it, at least to the point of given you some kind of
description of the problem, rather than dying.
-- Jerry
-------