Conference iosg::all-in-1_v30

2113.0. "Lotus V1.5 and reserved files" by OASS::BURDEN_D (Well, it sure beats raising cattle) Mon Jan 18 1993 20:49

Here is a draft copy of the STARS article I've written for this
problem.  Any comments or corrections are welcome:

----------------------


"Cannot perform requested operation, document is reserved" when printing
Lotus 1-2-3 V1.5 under ALL-IN-1 V3.0

VMS V5.x

PROBLEM:      When a user prints a Lotus spreadsheet they get the message:

	      Cannot perform requested operation, document is reserved

	      displayed at the bottom of the screen.

	      The file is printed without a problem, but if they look in their 
              Lotus system folder (usually LOTUS 1-2-3 SYSTEM DOCUMENTS) they 
              will see a document with a title of TEMPORARY PRINT RANGE FILE, 
              with them as Author and a Status of RESERVED.  This is the file 
              the error message is referring to.  

INFORMATION:  The print operation tried to delete this file after sending the 
              job to the queue, but since it was RESERVED it could not delete 
              the file.

CAUSE:	      The user has shared the drawer that the Lotus documents are in 
              with another ALL-IN-1 user.  The temporary print files that 
              Lotus creates during a print operation are not being closed 
              properly (not abiding by proper ALL-IN-1 standards) so they do 
              not get taken out of their initial RESERVED status (see Note 
              below.)

	      This problem does not happen in a 'normal' ALL-IN-1 file 
              cabinet, one that is not shared.

	      Note: 

	      When a file is created by ALL-IN-1 it is initially set to a 
              status of RESERVED until the file has been saved by the user.  
              This is true for most file types under ALL-IN-1, not just Lotus.  
              This RESERVED status means that users who have access to the 
              file may only read the file.  The owner needs to Un-RESERVE it 
              in order to edit or delete the file.

ALTERNATIVE:  Currently the alternatives are to:

	      - manually un-RESERVE these files and delete them

	      - do not use the shared file cabinet feature in ALL-IN-1

	      - move the folder containing the Lotus spreadsheets to a drawer   
                that is not being shared with other users

	      - do nothing, ignore the error messages and let the TEMPORARY 
                PRINT RANGE FILE documents accumulate

	      

This is a minor point but your article should distinguish between
"documents" and "files" correctly, because to the user:

    o   A user creates and edits documents

    o	ALL-IN-1 reserves documents

    o	ALL-IN-1 prints documents - the fact that to do this it may 
    	create files is largely hidden from the user.



When ALL-IN-1 prints a document it always creates a temporary file, which
for some types of documents will be a direct copy of the file cabinet file.
It does this so that the print operation can be performed without having to
be concerned with what the user may subsequently do to the document (e.g.
delete, archive, re-file) before the print operation completes.  The
temporary files are FILES; they are not documents which would also require
making entries in the ALL-IN-1 file cabinet. 

What LOTUS 1-2-3 seems to be doing is creating a temporary document, and 
not just a temporary file.  The ALL-IN-1 print sub-system is able to delete 
temporary files but is not able to delete temporary documents.

I don't know why LOTUS 1-2-3 needs to create temporary documents, or if
whether this is strictly necessary.  It certainly adds some additional
overhead to a print operation. 


Richard

    You are quite right that there is a general problem here.
    
    For a pfr I am currently changing the way a 'noedit' document creation
    occurs. This will no longer reserve the file cabinet entry for the
    document so there is less of a burden on existing applications and
    customisations.
    
    Before V3.0 creating a document 'noedit' was a straightforward
    procedure. You just called DOCCREATE with #p1 = "NOEDIT" and then
    arranged for oa$curdoc_filename to point to the file of your choice, eg
    by doing a rename. In V3.0 things aren't so simple - the document could
    be remote, or even if it is local it is possible to create a file with
    the wrong ownership. I am therefore considering providing a small,
    generally available, script which will make the file of your choice
    become the content file of the current document and will generate
    correct ownership, handle cross-node copying etc.
    
    Regarding your alternative workarounds, I would recommend a combination
    of 1 and 4, rather than impose restrictions on the use of shared
    drawers.
    
    For the specific Lotus problem, I am trying to track down exactly what
    needs to be done there.
    
    Dick