Conference iosg::all-in-1

    Bruce,
    
    You seem to have covered most things. You implied that you've checked
    both foreground and background - if that's not the case then that's
    worth a try. 
    
    It looks like a fundamental problem, seeing as everyone is getting the
    error, with every ANSI table. The "printer attribute file error" may
    therefore be a red-herring.
    
    >> Problem is, there is nothing wrong with any of the ANSI printer at-
    >> tribute tables and none of them are working - not even LP11 or A1TEXT.
    
    What draws you to this conclusion? I know it seems unlikely, but
    perhaps a rogue system manager got hold of them ;-). Have they been
    modified recently?
    
    Sorry, I can't think of anything else. 
    
    Russell.
    
    

From the information you have given it looks certain that the error is
coming from the WPS-PLUS formatter.  Try issuing a WPS-PLUS Format 
operation directly, e.g.

    <FORMAT 'FILE.WPL', 'FILE.LIS', 'LP11'

and report what happens.

Is the logical name WPL$PRT which points to the directory which contains 
the WPS-PLUS Printer Attribute files still set up correctly?

Richard

    Hi Fellows,
    
    Russ, to answer your question first, we get the error regardless of
    whether we format in foreground or background.  I tried foreground
    formatting in hopes of getting a better error message, but did not.
    
    Richard, when I issued the <format command, I got the error.  Not
    surprisingly, when I changed the WPS-PLUS FORMATTING field of the
    ASCII EDT format master file record to N and printed an ASCII file
    to it using an ANSI table, it worked.
    
    I checked and found that none of the .FLC files have been modified
    recently.  The customer relinked ALL-IN-1 last nite, but that did
    not make any difference.
    
    Fortunately, a lot of their printer are PostScript, so they are not
    _totally_ dead in the water, but people that have only ANSI printers
    in their offices are pretty unhappy.
    
    Does any of this help?
    
    Thanks,
    
    Bruce in Atlanta

    Some info and suggestions:
    
    Printer Tables are not part of the TXLs.
    
    The NULL_POINTER error occurs with corrupt WPS-PLUS documents. Usually,
    but not always, this error would occur during reading and printing.
    
    The PRINT_ATTRIBUTE_FILE_ERROR error occurs when the Formatter reads in
    a printer attribute file (.PRA) that is not in the correct format. It
    discounts that the PRA can't be found because that would give a
    different error.
    
    You initially mentioned NULL_POINTER errors, but then mentioned a
    printer attribute file error. Are you sure that the "092FF7A2" error is
    the PRINT_ATTRIBUTE_FILE_ERROR? (Perhaps this is something I should
    know!).
    
    If the NULL_POINTER error is being received first then the
    PRINT_ATTRIBUTE_FILE_ERROR may be a duff error following the previous
    one.
    
    To see if a PRA is correctly formatted try to edit it with the PTU
    editor. You can do this either from Customization Management or from
    the Printer Tables subsystem (if you create a temporary PRA). In the
    test I did I got a different error when reading a corrupt PRA, but it's
    still a useful test.
    
    Using the Manage Printer Types subsystem choose a print style you know
    fails and double check which PRA is being selected. Check this PRA as
    described above.
    
    Double check where WPL$PRT is pointing to.
    
    I can't think of anything else to check at the moment.
    
    Russ.
    

    Hi Russell,
    
    Thanks for the reply.  The reason I mentioned the .TXL's is that the
    problem might have been caused by someone modifying one of the script
    files used in printing to allow only PS formatting and then recompiled
    the TXL, thus causing the problem.  I knew the .PRA and .PRC files were
    ok because I could edit them in WP PT without getting blown out and I
    could see the files in the ALL-IN-1 subprocess when I did a directory
    of WPL$PRT - the files had size, a good date and world read/execute
    (basically everything that would make ALL-IN-1 happy).
    
    I initially suspected a corrupt document, but quickly dismissed this
    when I found that the same document would print fine if the PS table
    was used and, when I found that _any_ document would generate the
    error.  I could see one or two documents, but not all and not for all
    users.  This was a global problem.
    
    Turns out, rebooting the system corrected the problem.  Go figure.
    
    Thanks anyway,
    
    Bruce in Atlanta