T.R | Title | User | Personal Name | Date | Lines |
---|
1013.1 | | AITG::DERAMO | Daniel V. {AITG,ZFC}:: D'Eramo | Sat Jun 24 1989 13:36 | 7 |
| Possible problems are not copying the ddif file as a binary
file (I've never looked at one but I doubt that it is all
ascii text), and having to use $ set file xxx.ddif /semantics=ddif
after a copy to VMS.
Dan
|
1013.2 | | STAR::BECK | Paul Beck - DECnet-VAX | Sat Jun 24 1989 23:31 | 7 |
| If you dir a DIR/FULL on a real DDIF file, you'll see references to
some RMS DDIF-related characteristics. I seriously doubt there's any
way you can use KERMIT to preserve these characteristics, just as you
can't use KERMIT to transfer ISAM files.
But I could be wrong; I haven't tried it personally.
|
1013.3 | to set binary mode | NORGE::CHAD | Ich glaube Ich t�te Ich h�tte | Mon Jun 26 1989 09:15 | 9 |
|
A note. The VMS kermit command for setting binary file type is
KERMIT> SET FILE TYPE BINARY
Postscript copies fine 'coz it is all in text format.
Chad
|
1013.4 | | QUARK::LIONEL | B - L - Oh, I don't know! | Mon Jun 26 1989 11:00 | 5 |
| You will still have to do a SET FILE/SEMANTICS=DDIF on the file once it
is copied to the VMS system.
Steve
|
1013.5 | Problems with KERMIT and .ddif | JOELS::SAREN | Joel Saren-'Call Me EAR Responsible' | Mon Jun 26 1989 11:17 | 14 |
| It doesn't work.
Sure you can
KERMIT>SET FILE TYPE BINARY
and send and receive the file .ddif
and even set file/sem=ddif
but if you do anything to that file, i.e. type, edit you get an
error which indicates the header block is messed up.
Still looking for the cure.
|
1013.6 | For internal use only, a Toolshed option ... | STAR::BECK | Paul Beck - DECnet-VAX | Mon Jun 26 1989 16:40 | 12 |
| If this is for in-house use, and not for a customer ...
There is a tool in the Toolshed called FTCT which turns files into ASCII
strings while encoding/preserving RMS header information. The hexified file
is one which can be sent over Kermit safely (I have used it to transfer
savesets over Kermit, for example). The encoded file is larger than the
original (you can somewhat compensate using the COMPRESS option).
I just tried using it (still had to SET FILE /SEM=DDIF after dehexifying),
and the DDIF Viewer seemed to understand the file (a fairly simple one).
|
1013.7 | | KONING::KONING | NI1D @FN42eq | Tue Jun 27 1989 15:53 | 5 |
| I saw a (massively kludgy, but using only standard utilities) approach
to doing this recently. It was probably in the DDIF conference.
paul
|
1013.8 | Try this... | DDIF::BRAMHALL | Mark Bramhall, CDA architecture | Tue Jun 27 1989 17:27 | 30 |
| Here's a guess at what is happening...
First though: DDIF files are simply streams of bytes. They are encoded
in ASN.1. The real RMS attributes of DDIF files is 512 byte fixed
length record with no carriage control -- this is what other binary
files, e.g., .EXEs, are.
So, it would seem that KERMIT's binary transfer mode would do the
trick. But, wait! There's that DDIF semantic tag!!!
If KERMIT does a plain-old-vanilla RMS open on the DDIF file, the RMS
filter will get invoked. It will "lie" to the application and say that
the file's attributes are variable length records (max 2048 byte) with
implied carriage control. It then proceeds to live up to the lie and
filters out the text from the file, building "normal" variable length
text lines.
Try this trick to make it work:
1) Remove the file's DDIF semantic tag using:
$ SET FILE /NOSEMANTICS foo.ddif
This means that the RMS filter will not get invoked -- so the binary
data of the file will be available to KERMIT.
2) Transfer the file using KERMIT using KERMIT's binary mode.
3) Restore the DDIF semantic tag (and/or add the DDIF semantic tag to
the destination copy of the file if that system is VMS also) using:
$ SET FILE /SEMANTICS=DDIF foo.ddif
|
1013.9 | Also try using SET FILE TYPE FIXED in kermit. | IO::MCCARTNEY | James T. McCartney III - DTN 381-2244 ZK02-2/N24 | Wed Jun 28 1989 14:21 | 11 |
|
Also, if the proper format of the binary file is to be fixed-512, then
you should use the SET FILE TYPE FIXED kermit command. This instructs
kermit on the receiving (VMS) end to create the file using fixed records
of 512 bytes (required for .exe files, thus the reason for the command).
SET FILE TYPE BINARY will not cause the record length to be forced to 512.
James
|
1013.10 | Trying .8, .9 and FTCT | JOELS::SAREN | Joel Saren-'Call Me EAR Responsible' | Thu Jun 29 1989 10:41 | 8 |
| Will give .8 and .9 a try.
.8 was very well explained you should copyright it.
Thanks
Joel
|
1013.11 | Commands to KERMIT ddif files are here. | JOELS::SAREN | Joel Saren-'Call Me EAR Responsible' | Fri Jun 30 1989 08:01 | 20 |
| And here is the answer..
This works.
a) make sure you have a copy of your Style file on the new system -
b) foo.doc or foo.ddif
c) set file/noseman foo.doc
c) kermit
set file type fixed (yup not binary, fixed works) binary may work
too, but it gives strange ACLs.
d) after the file has KERMITed to you.
E) SET PROT= W:RWED FOO.DOC
F) SET FILE/SEMAN = DDIF
This worked for me.
Joel
|