[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vmszoo::rms_openvms

Title:	RMS asks, 'R U Journaled?'

Moderator:	STAR::TSPEERUVEL

Created:	Tue Mar 11 1986
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3031
Total number of notes:	12302

3031.0. "Converting sequential file to indexed with /nosort used to work, but not now..." by AIMTEC::SIMPSON_L () Fri May 16 1997 18:14

    Hello!
    
    I have a strange one to see if anyone out there has any ideas about.
    
    This customer has 3 different Vax system.  Two of these systems are
    running OpenVMS V5.5-2.  the other one is running OpenVMS V5.5-2h4. 
    They receive a stream_lf file via Multinet or something like that. 
    This file is sequential with 555 byte records.  This file comes into
    their production node which is one of these 3 systems and is running
    OpenVMS V5.5-2.  Then then take this file and attempt to convert it
    without sorting the records.  The convert command looks something like:
    
    $CONVERT/NOSORT/PAD=%X20/TRUNCATE/FDL=CHECTRAN 164_161932.TRN OUT.TRN
    
    The fdl Chectran defines the file as indexed using 2 keys with 554 byte
    records.  Key 0 begins at position 0 and is 61 bytes long.  I don't
    remember about key 1.  Until recently, for about 8 months, the above
    convert command, with different input and output filenames depending on
    the file they received, worked on the production system.  This period
    was about 8 months.  Suddenly, it does not work.  When the convert is
    done, they receive the error:
    
    "%convert-i-seq, record out of sequence"
    
    The first record is the only one written to the output file.  Their
    file is not sorted.  It has a header record which starts with a set of
    characters, alphanumeric, which shows what machine it came from.  The
    rest of the records are in order and are a mixture of numeric and
    alphabetic fields.  They want this header record to appear first in the
    output index file and the other records to remain in their sorted
    order, the way they appear in the input sequential file.
    
    I have dialed into their system and seen this work on one of the 3
    nodes, which is running OpenVMS V5.5-2h4.  On the other two systems,
    running V5.5-2, it does not work.  When it works, the error is not
    generated, and the file comes out as indexed and the way they want it
    to appear.
    
    Can anyone tell me how this can be posible?  We have dumped one of the
    files on the system where this operation works and the first byte is
    the Hex equivalent of the first physical character in the file, in this
    case, the Hex equivalent of lower-case z.  I thought that maybe they
    used to get files with a space or null character as the first character
    in the key of this first record.  But it appears not.
    
    Help!!!!!
    
    Can anyone explain this?  And/or failing that, can you tell me how to
    produce an indexed output file that is, as far as RMS is concerned, out
    of sequence?  I've tried the convert that they use, produced the output
    file with the first record in it, used an exceptions file to get the
    rest of the records, converted this exceptions file, then tried to
    merge the two with this odd record first.  But I either cannot just
    append them together since they are indexed or I get sequential output.
    
    Can someone help?
    
    Thanks very much!
    
    Laurie

T.R	Title	User	Personal Name	Date	Lines
3031.1	stream record format?	EPS::VANDENHEUVEL	Hein	`Sat May 17 1997 06:28`	46
	> "%convert-i-seq, record out of sequence" Normally, one would convert the file with the /EXCEP switch to catch those records out of order. The gotche in this case seems to be that the first record has a high key value and thuse the rest of the file will be seen as exception. > They want this header record to appear first in the > output index file and the other records to remain in their sorted > order, the way they appear in the input sequential file. No can do. That would be much like being a little pregnant. It is either sorted or it is not. Indexed file are sorted. Period. Now you _can_ influence the sort order through COLLATING SEQUENCES. It might be a solution, but not for your case I suspect. > the Hex equivalent of lower-case z. I thought that maybe they > used to get files with a space or null character as the first character > in the key of this first record. But it appears not. Lower case Z often corresponds with the highest key value for text/printable records/keys. To get the header record to sort first they'd want the first 61 bytes to be either spaces (no garantuee but likely to work) or better still binary zeroes. The binaries zeroes possibly have a desirable benefit of not being 'visible' when the file is typed. Perhaps they should simple edit the input file to get a low value there. At this point, I'm not convinced yet that they have started to deliver them different data causing the problem. The other thing that might just be behind this is STREAM files. Perhaps they changed record attributes from STREAM to STREAM_LF or the other way around? RMS has one peculiar function where it removes leading binarie zeros from a stream file. (See note 1901) Finally, check for VAXCRTL version changes. I seem to recall there was a version which 'inhereted' record attributes from previous versions of a file (contrary to normal VMS behaviour). hth, Hein.
3031.2		AIMTEC::SIMPSON_L		`Mon May 19 1997 18:59`	20
	Hein, Thanks very much for the reply! I could not believe that RMS would allow their situation either unless they have something that designates the first record as a lower key that th ones after it. How would I know if this record had binary zeros in it? What I'm thinking of doing is checking files on the system where they say it still works and see if there is something there that somehow has stopped appearing in the files on the non-working systems. The customer says that nothing has changed about these system since this stopped working, well, who knows. Also they say that the files were stream_lf when it worked and they are still stream_lf now. I know because I've dialed in personally and seen this. Any other thoughts would be greatly appreciated. Thanks again! Laurie
3031.3	Various Ways To Read Indexed File...	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Mon May 19 1997 21:52`	5
	DUMP or to-text CONVERT would be two approaches. A small program would be another -- I've posted C code that reads a sequential file over in the TURRIS::DECC notes conference on a variety of occasions... It would not be very difficult to tweak this C code into reading an indexed file.