Conference iosg::all-in-1_v30

>BUT what I don't understand is....
>
>1)	The entries for formats RTF1 and RTF2 in the FORMAT DSAB have a FOREIGN 
>	DSAB.  To me this has always meant that you can store these documents 
>	in the File Cab but ALL-IN-1 doesn't understand them - so you can't 	
>	read them or print them. 
>
>	BUT, I find that I CAN read these documents!  It appears that the 
>	LIST_DOCUMENT function converts them into plain text.  HOW?  Is this 
>	done by an "RTF" TEXT DSAB or is the CDA converter called?

The term 'FOREIGN' came into use when the only integrated method of
understanding the contents of documents was the ALL-IN-1 Text Dataset
mechanism.  Therefore if the Text Dataset mechanism could not understand
the document then you could also say that ALL-IN-1 could not understand the
document.  At this time the only thing the FOREIGN text dataset did when
asked to read a file in record mode was to generate an informational message. 

Since ALL-IN-1 V2.4 other mechansims for understanding documents have been
integrated into ALL-IN-1.  These are CDA, and in V3.1 KEYpak will also be
supported but not bundled.  Therefore today the term 'FOREIGN' means that
the text dataset mechanism cannot understand the document, but it does not
mean ALL-IN-1 cannot understand the document because one of the other
integrated mechanisms may be able to.  Application Programming functions, 
such as CDA_CONVERT, invoke these converter mechanisms directly.

However, what I have just said about the FOREIGN text dataset is not
entirely true because it has also been extended.  The FOREIGN text dataset
will also try to use CDA and/or KEYpak to read the file.  It uses the .type
or .ext part of the file specification to determine which CDA (or KEYpak)
converter to use.  The file is 'converted' to text to generate text dataset
conformant records.  The CDATYPES table in OAET.MAR defines which formats 
can be supported by CDA and the mapping between the the file .type and the 
CDA front-end name.  A similar table will be used for KEYpak.



>2)	Why have two FORMAT entries for RTF?  As far as I can see RTF1 and RTF2 
>	are identical.

Because RTF had a version 1 format which is now superceded by a version 2 
format.


>3)	The WPCORP entry in FORMAT has "WPCORP" in its DSAB field - not FOREIGN
>	like all the other CDA Cnvlib V2.x formats (this is on a system without 
>	the WPCORP integration).  The LIST_DOCUMENT function does not seem to 
>	understand this - when reading a WPCORP document (remember - no WPCORP 
>	integration on this system) it comes out blank.  I can then convert 
>	this document into WPS-PLUS (using the CD option) and all the text is 
>	there. 
>
>	So, what is different with the way that ALL-IN-1 handles WPCORP on a 
>	non-WPCORP-integrated system (with CDA Cnvlib V2.x)?  Why does the 
>	LIST_DOCUMENT function work with other CDA formats (like RTF) and not
> 	with others like WPCORP?

This will use the FOREIGN text dataset mechanism, which uses the file .type 
to select the CDA front end.  Does the file type (.e.g. .WPC) as defined in 
the OAET.MAR table match the the file type you are using?



>4)	Why can I read RTF documents (as described in 1) on my system - but a 
>	customer with the same version of ALL-IN-1 (3.0A), CDA Base (1.6), CDA 
>	Cnvlib (V2.2), same actual DDIF$READ_RTF.EXE image (same id) cannot 
>	read identical documents???

Are any error messages displayed?
    


Richard

    
    Richard,
    
    	Thanks for your reply.
    
>>	So, what is different with the way that ALL-IN-1 handles WPCORP on a 
>>	non-WPCORP-integrated system (with CDA Cnvlib V2.x)?  Why does the 
>>	LIST_DOCUMENT function work with other CDA formats (like RTF) and not
>> 	with others like WPCORP? 
    >
>This will use the FOREIGN text dataset mechanism, which uses the file .type 
>to select the CDA front end.  Does the file type (.e.g. .WPC) as defined in 
>the OAET.MAR table match the the file type you are using?
    
    	I still don't see why the WPCORP FORMAT has a DSAB of "WPCORP" and
    	all the other new CDA V2.x formats have "FOREIGN".  WPCORP (.WPC)
    	does appear in the CDATYPES table in OAET.MAR so I would expect 
    	exactly the same behaviour as I get for RTF when I try to read the
    	document; namely, an "ascii" version of the text is displayed. 
    	With WPCORP documents all I get is a few blank lines.
    
    	My files have a .WPC extension and I am transferring them into
    	ALL-IN-1 using the RVC option (resultant document has DSAB=WPCORP
    	and file extension of .WPC).  I can subsequently convert these docs
    	to ASCII and WPS-PLUS (using CD) and the text is all there.
    
>>4)	Why can I read RTF documents (as described in 1) on my system - but a 
>>	customer with the same version of ALL-IN-1 (3.0A), CDA Base (1.6), CDA 
>>	Cnvlib (V2.2), same actual DDIF$READ_RTF.EXE image (same id) cannot 
>>	read identical documents???
>
>Are any error messages displayed?
    
    Interestingly yes - but only when they try a $CONVERT/DOCUMENT from DCL.
    They create a one-line text file using EDT then try to convert it with
    
    	$CONV/DOC simple.txt/format=TEXT simple.rtf/format=RTF
    
    They get the error message...
    
    	%CONVERT-W-STYNOTREADABLE, Can't open style guide file: defstyle
    
    but the file is still created.
    
    (and yes Andrew, I know this is probably one for the CDA conference but
    you can hear a pin drop in there these days... in both the conferences
    on GALVIA and ISVNET - so I kinda need any help I can get on this one!)
    
    Thanks, Andy

We added WPCORP entries into the V3.0A (and V3.1) OAET.MAR and FORMAT
master tables so that WordPerfect documents are identified as WordPerfect. 
This means that if some time later WordPerfect is integrated into ALL-IN-1
all existing WordPerfect documents will have the required File Cabinet 
information to be handled using WordPerfect.  Until WordPerfect is 
integrated the documents will be regarded as Foreign.

If the OAET.MAR and FORMAT entries did not exist WordPerfect documents
would be identified as FOREIGN.  If WordPerfect is integrated some time
later into ALL-IN-1 only newly created WordPerfect documents will be
correctly identified and processed as WordPerfect. 


I cannot reproduce the problems you have reading .WPC and .RTF files on my 
systems.  

Are you able to perform CDA operations from ALL-IN-1 using the CDA_CONVERT 
API function?

Are there any customizations to the document handling scripts?


Richard

    I've done the following tests on both the customer's machine and my own
    and got different results...
    
    $ view/form=rtf sys$common:[systest.cdacvtlib]cvt$ivp_rtf.rtf
    
    This is a sample RTF doc that comes with the CNV LIB kit - the "View"
    works on both systems.  This proves (to me at least) that the RTF doc
    is okay.
    
    $ copy sys$common:[systest.cdacvtlib]cvt$ivp_rtf.rtf -
    		bla:[allin1.mgr]test.rtf
    
    $ install add ddif$read_rtf.exe /head
    
    $ set watch file/class=all
    
    $ allin1/user=manager
    
    <LIST test.rtf
    
    On my system, this works.  There's a bit of a pause while the convert gets
    done and then the document is displayed.  The SET WATCH shows that 
    the RTF front-end converter DDIF$READ_RTF.EXE is used.
    
    On my customer's system all I get is about six blank lines.  This happens
    almost instantaneously.  SET WATCH shows that DDIF$CC_VIEWSHR.EXE is
    being used - NOT the RTF front-end.
    
    The customer has IOS V3.0A, CDA base V1.7, CDa converter V2.2.
    
    Could this be that the customer has not linked ALL-IN-1 to use CDA?
    
    
    Andy
    CSC Sydney
     

>    Could this be that the customer has not linked ALL-IN-1 to use CDA?
    
The A1LNKDRV procedure outputs informational messages which say if CDA is 
or is not beling linjed into ALL-IN-1.


If you execute the function <CDA_CONVERT what error message do you get?

    Function "CDA_CONVERT" not implemented in this version

indicates that CDA was not included when ALL-IN-1 was linked.



Richard

    
    Re .-1
    
    I'm pretty sure that CDA has been integrated but I've not had a chance
    to check yet.
    
    I guess what I'm really asking is under what circumstances would the
    LIST function take a different code-path when the same test is done on
    two systems....??
    
  >  On my system, this works.  There's a bit of a pause while the convert gets
  >  done and then the document is displayed.  The SET WATCH shows that 
  >  the RTF front-end converter DDIF$READ_RTF.EXE is used.
  >  
  >  On my customer's system all I get is about six blank lines.  This happens
  >  almost instantaneously.  SET WATCH shows that DDIF$CC_VIEWSHR.EXE is
  >  being used - NOT the RTF front-end.
    
    Andy