[Info-vax] RMS internals?

[Howard S Shubs]

In article <0036d9be$0$5027$c3e8da3 at news.astraweb.com>,
 JF Mezei <jfmezei.spamnot at vaxination.ca> wrote:

> You have files created on Windows. Transfered to VMS in some fashion,
> but transfered in binary mode.

Only after I requested it.  They were originally transferred using ASCII 
mode, which is what our end users will actually do.  With what I saw, 
I'm not going to worry about it.  If the users transfer using binary 
mode, the program they're using just won't work properly.  If my client 
wants me to fix it, I'm sure they'll let me know.


> And you then want to write an application that can parse the file's
> internal structure.

I've done it for UNDEFINED and VARIABLE, yes.


> This may soun stupid, but what is wrong with doing standard file IO and
> letting RMS parse the file ? This will give you your records and you
> don't have to worry about whatever internal structure the file was
> stored in.

Actual record length of this file is 33097 bytes.  I don't know why.  
I'm neither the 3rd party who wrote the software emitting it, nor my 
programmer who needs to update the software to read it.  I'm just trying 
to help him out.  If I'd understood ahead of time how the records were 
being written, I'd have told him, and he'd have dealt with it, but now 
I've given him this little library and he doesn't have to mess with it.


> Also, if, once in production, you always use the same type of file
> transfer software, then the files on VMS will always be created the same
> way.

Yes.  Twenty-twenty hindsight is wonderful, isn't it?  RMS encodes the 
long records in a form which I had to figure out.  And that's the key.


> For records that are too large to fit in the $GET buffer, if I remember
> correctly, you can stecify that the rest of the record be provided in
> the next SYS$GET call, or that it be truncated (lost).

I suppose we could have done it with two $GETs, yes.  Unfortunately, 
without knowing for sure how the file was being written by FTP, we 
didn't know that.  FTP is saving it as two records, one of 32767 bytes, 
and one of 330 bytes.  I only found that out once I looked at the blocks 
while debugging my routines.  And I can't be sure it'll always work this 
way.  We're using MULTINET.  What if we switch to UCX (unlikely) and it 
does things differently?  I like the idea of having a library around 
which will read any record length, anyway.

I'd suggest that RMS get with the times, but honestly this is the first 
time I can think of where this has been an issue.  And RAB64 helped, so 
I've got no kick.

The upshot of all this is that I will likely speak to the programmer, 
tell him this, and see if he wants to continue using this library or 
not.  If not, so be it.  If so, I'll fix the padding thing.  Otherwise, 
I'll probably not bother with the rest of the record formats.  Either 
way, I've had fun writing it, and it seemed like a good idea at the 
time.  If it ends up being set aside for now, fine.

-- 
Don't bother with piddly crap like "gun control".
Life is 100% fatal.  Ban it.