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

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

1013.0. "COPY DDIF via KERMIT?" by JOELS::SAREN (Joel Saren-'Call Me EAR Responsible' ) Sat Jun 24 1989 08:39

    There is a need to copy a ddif file using KERMIT.
    
    When I copy a postscript file using KERMIT the file is received
    fine but not when copying a ddif file.
    
    Does anyone have any ideas.
    
    Joel

T.RTitleUserPersonal
Name
DateLines
1013.1AITG::DERAMODaniel V. {AITG,ZFC}:: D'EramoSat Jun 24 1989 13:367
     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.2STAR::BECKPaul Beck - DECnet-VAXSat Jun 24 1989 23:317
    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.3to set binary modeNORGE::CHADIch glaube Ich t�te Ich h�tteMon Jun 26 1989 09:159
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.4QUARK::LIONELB - L - Oh, I don't know!Mon Jun 26 1989 11:005
You will still have to do a SET FILE/SEMANTICS=DDIF on the file once it
is copied to the VMS system.

			Steve

1013.5Problems with KERMIT and .ddifJOELS::SARENJoel Saren-'Call Me EAR Responsible' Mon Jun 26 1989 11:1714
    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.6For internal use only, a Toolshed option ...STAR::BECKPaul Beck - DECnet-VAXMon Jun 26 1989 16:4012
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.7KONING::KONINGNI1D @FN42eqTue Jun 27 1989 15:535
I saw a (massively kludgy, but using only standard utilities) approach
to doing this recently.  It was probably in the DDIF conference.  

	paul

1013.8Try this...DDIF::BRAMHALLMark Bramhall, CDA architectureTue Jun 27 1989 17:2730
    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.9Also try using SET FILE TYPE FIXED in kermit.IO::MCCARTNEYJames T. McCartney III - DTN 381-2244 ZK02-2/N24Wed Jun 28 1989 14:2111

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.10Trying .8, .9 and FTCTJOELS::SARENJoel Saren-'Call Me EAR Responsible' Thu Jun 29 1989 10:418
    Will give .8 and .9 a try.  
    
    .8 was very well explained you should copyright it.
    
    Thanks
    
    Joel

1013.11Commands to KERMIT ddif files are here.JOELS::SARENJoel Saren-'Call Me EAR Responsible' Fri Jun 30 1989 08:0120
    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