Conference iosg::all-in-1_v30

    Pam,
    
    The jury so to speak is still out on this one. Access technologies who
    produce 20/20 were a Field test site for DIAMOND and we (the CSC) were
    dealing with them. Then Access got taken over by Computer Associates
    and as a legal matter I think the FT license was rescinded until the
    new owners signed it and then things went quiet and our phone calls
    were never returned.
    
    I guess you can try it and see but until it is certified by CA (or
    whoever) it is not covered by the agreement we have to support 20/20
    for ALL-IN-1. I think somebody did do an upgrade of a system with 20/20
    on it and of course somethings didn't work - some messages and
    customisations did not work (of course if we'd run the CART....)
    
    If anyone knows who the 20/20 counterpart from DIGITAL is (probably
    somebody out of TTB) then we can probably pursue it that route.
    
    regards,
    
    Andrew.D.Wicks
    

    From experience gained from running CART on several customer sites it
    seems that 20/20 elements are "dumped" into ALL-IN-1 rather than being
    correctly registered in CM. As such the 20/20 elements are reported in
    the site elements report and not scanned by the CART.  But there are
    several flavours of 20/20 and its integration with ALL-IN-1 so this
    problem may be limited to one or more of these.
    
    As 20/20 deals with the File Cabinet it's very likely that a new
    version will be required to handle ALL-IN-1 V3.0.  For example, the
    current code is highly unlikely to be able to place a model or
    worksheet into a drawer that is shared and located on a remote system,
    especially if the user doesn't have write access!
    
    Tony

Hi, 
I have isolated a problem with the 20/20 Spreadsheet Processing 
ALL-IN-1 Menu, specifically the 20/20 v3 release, running under 
Diamond.  I think is has fixes for most problems mentioned earlier in 
this topic.

In the past, 20/20 would store it's macros in the ALL-IN-1 File 
Cabinet as .WPL files.   They were always actually stored as plain 
ASCII, but were given the User's default file type.  In most cases 
this is .WPL, however the files are not WPS-PLUS format, as the .WPL 
file type should imply to ALL-IN-1.

Now the 20/20 v3 ALL-IN-1 Menu allows any old document to be run as a 
macro.   It now takes notice of the .WPL type and expects the file to 
be WPS-PLUS format.   This gives a "bad filename" error while in 20/20.

The effect of this on the User is that no pre-v3 macros held in the 
file cabinet can be run.  Eek!

A horrid workaround is to rename each .WPL macro file to .TXT, then 
use the document convertor to make it back into a REAL .WPL format file.
I am looking a writing a script routine which will do this in a loop 
for a User's account.   Trouble is, this will wreck a genuine WPS-PLUS 
file; easily done if you run this script twice.  

Does anyone know a way to determine if a .WPL file actually contains a 
valid WPS-PLUS format file.  The TEXT_FILE and COPY functions don't 
seem to set OA$STATUS if there is merely ASCII text inside the input 
file.

Has anyone else encountered this problem?  Any fixes?

Regards,
Robert.

The TEXT_FILE and COPY functions utilize the ALL-IN-1 text dataset
mechanism which supports all file formats for which a text dataset exists
on your system.  These formats include ASCII, WPS-PLUS and DX.  The setting
of OA$STATUS will not be influenced by the format of the file.  'TEXT' in 
this context refers to the Text dataset mechanism and not text files.


Some ways you may be able to determine if your file with a .WPL file type 
is a WPS-PLUS file are:

1.  Use the TEXT_FILE RETURN sub-function.  You may be able to determine
    from information such as the RULER, LINE_TYPE, etc. what type of file
    your are dealing with.

2.  Use the FILE$ dataset to get information about the file.  ASCII files
    normally have a Record format which is variable length whereas WPS-PLUS
    files are fixed length.  This may allow you to distinguish between the
    two types of files. 


Having identified which files need to be converted you could use the
following method to do it:

    copy #FILE_SPEC #FILE_SPEC "" TXT$DSAB_ASCII
    .if oa$status == 1 then get oa$function = 'PURGE_FILE ' #FILE_SPEC

The COPY function normally selects the dataset used to read or write the
files based on the file type (e.g. .WPL for WPS-PLUS).  The fourth
parameter on the COPY function will cause the ASCII text dataset to be used
to read the input file regardless of the file type.  And, since the
original file is unuseable you may as well purge it. 


Richard