Edit/TPU question

[John Gillings]

Ian,

We need to step back a bit and look at the underlying issue...

On DOS, Windows and Unix, files are a stream of characters. Records are delimited by characters in the data stream. Sometimes it's a single LF (typical Unix), sometimes it's CR/LF (typical DOS).

For the DOS case, since the record delimiter is the common carriage control sequence for terminals and printers, you can simply spew the characters out to a terminal and it will *probably* display as intended. The advantage to this mechanism is the reader program does not need to know where records start and stop.

That's also the disadvantage. Since the convention is combining two orthogonal concepts (1-how to delimit records and 2-how to display records on certain devices), every program potentially needs to contain logic that determines record boundaries.

In contrast, files in OpenVMS are a stream of RECORDS. The information that determines record boundaries is NOT in the data stream. RMS keeps the concepts of record boundaries and record display independent.

Programs ask RMS for records, and RMS figures out where the records start and stop.

There are many ways to describe records. RMS uses Record ForMat "RFM" and Record ATtributes "RAT". Formats include "Fixed", "Variable", "Stream", "Stream_LF" and a few more. There may also be a Maximum Record Size (MRS) and Longest Record Length (LRL).

Record Attributes include "Carriage return carriage control". This tells RMS and the reader program how to output the records (ie: add a CR/LF when writing the data to a printer or terminal).

Since RMS deals with all this, your programs don't need to concern themselves with the record format. The same code should work with files of any type.

It sounds to me like your request to add CR characters to the data stream is an attempt to put the carriage control into the data. Although you might be able to get it to work for (say) terminals, you may find that after further processing, and writing the records to a new file, the RMS attributes include carriage control, and you end up doing it twice.

So, you need to look at where the file comes from and how it lands on the OpenVMS system. Check that the RFM and RAT match the data and what you want.

If the RFM matches the binary data, but not what you require, you can CONVERT the file to your desired format. Note that the CONVERT may change what's actually stored on the disk - typically only the RMS metadata, not the actual data stream.

On the other hand, sometimes the RFM and RAT don't match the binary data in which case you can use SET FILE/ATTRIBUTES to change the RMS attributes without changing the data on disk. This just changes the way RMS interprets the data.

In your case it may be as simple as adding "Carriage return carriage control":

$ SET FILE/ATTR=RAT:CR file

as suggested by Hein.

So, have a look at the data stream with DUMP and check out the record format and attributes with DIRECTORY/FULL. Once you've figured out what you're starting with and what you need, it's fairly simple to figure out how to get there.

[Ian Derringer]

As suggested by Hein, here is the record/dump attachment. By the way, the text file was created in VMS with an output command, but I had to moved it to the Wintel side so that I attached with this posting.

Thanks,
Ian

[Jan van den Ende]

Ian,


Thanks for bringing to my attention on the points. I have always submit my points


I am sorry, but I come back to this once more.
Especially, as you are obviously under the impression that you did everything according to Forum Etiquette, while the forum statistics show otherwise.

As far as I can see, you DID assign points to every entry in this thread. But, in the past, some answers to other questions have slipped through.

Via your profile I found this (URD added for your convenience)
http://forums2.itrc.hp.com/service/forums/pageList.do?userId=CA1223413&listType=unassigned&forumId=1

You will be able to find this page via your profile, the link to topics with Unassigned Points.

That page is dynamic: any stream you completely assign will simply vanish from it.

No offence meant!

Proost.

Have one on me.

jpe

[Doug Phillips]

Ian,

The missing piece is still the RMS information obtained with DIR/FULL. However, if you do that command you'll probably see that it says:

File organization: Sequential
...
Record format: Fixed length 512 byte records
Record attributes: None

This is the "Binary" format. Your file doesn't appear to have *any* record delimiters.

Also, if S3RD is the start of each record, it looks like the records are 218 bytes long rather than 210 (unless I've miscounted).

Try this (on a copy of the file):

SET FILE/ATTR=LRL=218 filename.exe

and then do the dump/record again and see if the record breaks are correct. If so, you'll need to tell us how you will be using / accessing / processing the file on VMS so someone can suggest what to do next.

[Hein van den Heuvel]

Ok, now we are getting somewhere.
Looking at the data it appears to me that our records are in fact 218 bytes each (not 210 as you indicated before) but VMS (RMS) is under the impression that the records are fixed length 512 bytes.
All you need to do to bring this file to life is:

SET FILE/ATTR=(RFM=FIX,MRS=218,LRL=218,RFM=RAT=CR)

None of this 'insert CR' is needed.
Once you have done the above set file, then you still may or might not want to do CONVERT/FDL=NL bad_file good_file.
This would not change the semantics, but would just change the file to the more 'normal' (in VMS land) variable length records file where each record happens to be 218. The fixed length format however is probable more true to the intend.

Good luck,
Hein.

[Ian Derringer]

Hein,
When I run your command SET FILE/ATTR=(RFM=FIX,MRS=218,LRL=218,RFM=RAT=CR)
The doesn't seem to like the RFM=RAT=CR - I just removed the last syntax and very worked flawlessly.

AMAZING!! You guys are the BEST in the business!! I will have to tune in to this forum more often, so I can learn more from you guys.

Again, thanks Hein and everyone for your patience and your time.

Regards,
Ian

[Willem Grooters]

Though I did not contribute (and I don't even WANT this to be counted) my two cents.




No. We just happen to work with the best OS in the world...




That's what the forum is for.

Willem