Conference iosg::all-in-1_v30

Hello Hong,

Can't reproduce the problem.

$   oashrbld DDIF$VIEWSHR a1$work:oaDDIF$VIEWSHR
Error in secondary activation:
%RMS-E-FNF, file not found

DDIF$VIEWSHR is linked against a number of images that are part of
Motif. 

		1)  "DECW$XMLIBSHR"
		2)  "DECW$XTSHR"
		3)  "DECW$DWTLIBSHR"
		4)  "LIBRTL"
		5)  "MTHRTL"
		6)  "DECW$XLIBSHR"
		7)  "DECW$TRANSPORT_COMMON"
		8)  "DECW$DXMLIBSHR"
		9)  "LBRSHR"
		10)  "VAXCRTL"

Perhaps one is missing/tailered off.

Regards,

Jan

  Re: .1
  I thought CDArt did *not* require Motif??

  Re: .0
  Though CDArt installed OK, can it be used by other users?
  Did you logout between installing CDArt and relinking ALL-IN-1?
  Is `DDIF$VIEWSHR' defined as a logical name?

  Cheers,
    Paul.

     Re: .1
    
    >  I thought CDArt did *not* require Motif??
    
    Correct. But IF DECwindows is installed it must be Motif 1.0
    or higher. 
    
    I had a look at the release notes of CDART...

              In order to allow the CDA components to be installed on
              systems where DECwindows is not installed, the CDA Viewer
              has been restructured and two new shareable images have
              been created:

                 DDIF$DECW_VIEWSHR.EXE
                 DDIF$CC_VIEWSHR.EXE

              By using LIB$FIND_IMAGE_SYMBOL to reference the entry
              points to these images, an application can dynamically
              determine whether it can execute in a given environment.
              The DDIF$VIEW.EXE application now does this.

              The old shareable image (DDIF$VIEWSHR.EXE) is still
              included to maintain compatibility with applications linked
              against it. New applications (and older applications that
              wish to take advantage of new features) should use the new
              shareable images.
                                                                                
    So it looks like ALL-IN-1 links against DDIF$VIEWSHR.EXE, which
    might still need DECwindows.

    Regards,
    
    Jan
    

Jan

Thanks for the info, as always being informative ...

This system must have been tailored somehow from a DECWindows to a non-Windows 
system since today I found out the customer, prior to installing CDArt, renamed 
DECW$DWTLIBSHR to something else to get the instal to work

As pointed out in your repply, CDArt did supply a version of DDIF$VIEWSHR, a 
history of which was supplied in note 2000.6 of DDIF::CDA as follows:

================================================================================
Note 2000.6                      CDART and Motif                          6 of 6
CSOA1::LENNIG "Dave (N8JCX), MIG, Cincinnati"        41 lines 20-APR-1993 14:19
--------------------------------------------------------------------------------

......................

    DDIF$VIEWSHR support DDIF$VIEW and is also what old applications linked
    against for viewer service (for example A1MAIL for VT & DECWindows)
    and I believe is also used during convert-to-text processing. [I believe
    new applications are supposed to link against either or both of the new
    CC/DECW libraries (see below), rather than ddif$viewshr.]

    In the CDA RT kit, a new DDIF$VIEW is supplied, and DDIF$VIEWSHR is now
    split into three pieces; DDIF$CC_VIEWSHR, DDIF$DECW_VIEWSHR and a xfer
    image DDIF$VIEWSHR for backwards compatibility. This image accepts
    calls and activates either of the other images as needed, rather than
    all the code being in it. As far as I can tell the only place the Motif
    libraries come into play with CDART is with DDIF$DECW_VIEWSHR.

...................

however, since the CDArt-supplied DDIF$VIEWSHR is still making ref to other 
DECW$*LIBSHR.EXEs, the IOS relink on a non-Windows system would obviously fail 
with "error in secondary activation".

I looked at DDIF$CC_VIEWSHR and saw these modules were used during its linking

		1)  "CDA$ACCESS"
                2)  "LIBRTL"
                3)  "MTHRTL"
                4)  "IMG$SHRLIB_NOX"
                5)  "VAXCRTL"
                6)  "SMGSHR"
 
i.e. no DECWindows stuff involved.

The customer is now trying to re-link IOS with DDIF$CC_VIEWSHR instead of 
DDIF$VIEWSHR and I'm waiting for the outcome.

Any other problems you can see even if the relink does work ?

Thanks

Hong

Hong,

>The customer is now trying to re-link IOS with DDIF$CC_VIEWSHR instead of 
>DDIF$VIEWSHR and I'm waiting for the outcome.

Me too. 

>Any other problems you can see even if the relink does work ?

Yes. A non-supported configuration... The ALL-IN-1 SPD contains the formal
truth:

===========================================================================

 ALL-IN-1 provides an interface to CDA support on a VMS system. DECwin-
 dows provides basic CDA support; full CDA support is provided by the
 installation of the optional ALL-IN-1 CDA Interoperability Kit.

 VMS has basic CDA support for DDIF, TEXT, and PostScript[R].

 DECwindows (separate kit) must be installed to use CDA.
                                                                                
===========================================================================

But. CDART only support Motif...

I think we have to wait for a reply from IOSG on this issue...

Regards,

Jan

    Hi
    
    Relinking IOS with DDIF$CC_VIEWSHR seemed to produce working images and
    the system involved has been running IOS with no noticeable problems.
    
    The only exception was OA$FORMATTER start-up being aborted because of:
    	... file not found...
    
    As a temporary work-around, the old image prior to CDArt instal was
    used and seemed to work for now.
    
    Is this new problem having anything to do with missing DECW$* or DDIF*
    images, required by the startup of OA$FORMATTER ?
    
    Hong

    Hi Hong,
    
    >Is this new problem having anything to do with missing DECW$* or DDIF*
    >images, required by the startup of OA$FORMATTER ?
    
    Not the startup, but the link... Have a look at A1LINK.COM...
    
    $wo "! CDA modules"
    $ if a1$cda
    $ then
    $    wo "SYS$LIBRARY:CDA$ACCESS.EXE/SHARE"
    $    wo "SYS$SHARE:DDIF$VIEWSHR.EXE/SHARE"
    $ endif
    $       close opt
    $
    $       LINK /NODEBUG /NOTRACEBACK /NOMAP /NOCROSS -
             /EXECUTABLE=a1$work:'a1$prefix'formatter -
                    a1$build:OAFORMATTER, a1$build:OAFORMATTERX, a1$work:OALNM, -
                    a1$work:OAFORMATTER.OPT /option, -
                    a1$build:IMAGEID.OPT /option
    Regards,
    
    Jan
    
    

    Jan
    
    Again, many thanks for the observation, but ...
    
    in .4 when saying "...link IOS with DDIF$CC_VIEWSHR ..." the customer
    was asked to $COPY DDIF$CC_VIEWSHR.EXE DDIF$VIEWSHR.EXE before the relink; 
    i.e., both copies of DDIF$CC_VIEWSHR and DDIF$VIEWSHR were identical and
    remained so after the relink.
    
    As a result, upon OA$FORMATTER startup, this DDIF image should be there
    but somehow not seen by the startup.
    
    Will check it out EXACTLY what she had done when I return to office 
    
    Any other idea ?
    
    Thanks
    
    Hong

    I did the relink , again, today and OA$FORMATTER started up OK
    
    The customer believed she must have done numerous relinks and file
    renamings, so confused when choosing a 'correct' image for start-up.
    
    To summarize, DDIF$CC_VIEWER seemed a good replacement...
    
    
    Hong