Conference iosg::all-in-1_v30

Hi,

The TRM housekeeping job will fix up problems like this by creating a dummy 
SDAF record. It will not delete the file.

Cheers

Stuart

Hi,


>>>SDAF record for file name: OA$SHARE333:ZVFFOWJ34.PS in Drawer:
>>>     [FOLGADO]PSECTOR Folder: SPD Number: 000033 cannot be accessed by RMS.

Is this a mail message or a private document? Because its a tad
unusual to have a file type of .PS in an OA$SHARE* directory. It looks
like somebody has been playing with docdb pointers or the like.

regards

Alan

    Re .2
    
    <<< Is this a mail message or a private document? Because its a tad
    <<< unusual to have a file type of .PS in an OA$SHARE* directory.
    
    A quick DIR through one of our shared area discs found 88 .PS files in
    the directories.
    
    With people on PCs using TL to file things in shared drawers, it's
    probably quite common.
    
    Graham
    
    PS Also explains why we have no disc space left!
    

Could the SDAF file itself be corrupt? Try analysing it (ANAL/RMS) to see 
if there are any errors, you will need ALL-IN-1 shut down to do this.

If you can not shut down ALL-IN-1 you could try reading the record with DCL 
to see if that gives a more helpful message.

$ OPEN/READ/SHARE DAF OA$SHARE:OA$DAF_E.DAT
$ READ/KEY="OA$SHARE333:ZVFFOWJ34.PS" DAF REC
*** message here ***
$ CLOSE DAF

A record not found type error probably indicates that the record got 
deleted a different error may give you a clue as to what is wrong.

Do the ANA/RMS if you can as this is more reliable and usually more 
informative.

If you do have a corrupt RMS file the CSC has a tool (in the US at least 
and I believe most other CSCs have the tool as well) that should be able to 
fix it.

Terry

Hi Graham

Re .3 Was that a deliberate rat-hole opportunity.....:-)

Because I still dont see how people refiling documents into
Shared Drawers is going to produce .PS files in a Shared Mail
Area. I'd be interested to know the keystrokes to create a 
Shared Drawer that maps to something like 

DSA63:[OA$SHARE.SHARE333]
    
You can certainly have .PS files in the Shared Mail Directories 
but they will more than likely be attachments to mail from remote 
locations, not the actual mail message itself. .0 refers to a mail 
message's SDAF record.

>>>SDAF record for file name: OA$SHARE333:ZVFFOWJ34.PS in Drawer:


cheers 

Alan

    Um, yes you're right, they are quite likely to be attachments.
    
    Continuing the rathole, more deviously, I created a mail message, and
    then tried to GOLD/Get a .PS file into it, but in V3.1, you can't do
    that! So I next tried to create an ordinary message, and "U"pdate it to
    PS, which doesn't work, and then I tried "CD"ing it, but that changes it
    into a document.
    
    Perhaps you can do it from the API? (I've tried MAIL MAIL_DOCUMENT, but
    that doesn't work!)
    
    You obviously need one of these funny PC thingies :-)
    
    Graham (Definitely back in the apprentice class!)
    
    PS Maybe .0's problem is that he has some attachments that have lost
    their parents?

If you do MH on a Postscript document, it becomes a mail message.  However, I
see nothing in the base note to imply the SDAF record is a top-level message
rather than an attachment...

ANALYSE/RMS is still probably the best thing to try.

Or maybe the FCR (what is FCR anyway?) documentation will tell you what "SPD
number 000033" means?  (I know, I'm so na�ve :-)

To me, it simply sounds as though the SDAF record is missing.  What happens if
you try and read the document?  Do you get --TOP-- and --BOTTOM-- markers with
nothing between them, or do you get the "PostScript document type cannot be
displayed" message?  What does SH reveal for these documents?

What does FCVR make of it all?  If FCVR finds files with no SDAF records, it
will created dummy records, which enables the documents to be recovered.  It
should be possible to fix things up without this happening:
>> any repair that I might attempt will probably delete the files

The other alternative is simply to DT the documents into ALL-IN-1 afresh.

This still leaves the question of why the SDAF records are missing.  Are there
any suspect errors in the DAF error log file oa$log:OA$DAF_ERR.LOG?  Are all the
file protections on these drawers correct?

Scott

    FCR is the ALL-IN-1 File Cabinet Report. It's a PASS available from
    ASSETS.  I have no idea what SPD number 000033 means.  But as I wrote
    the program this isn't at all surprising -- the last time I set serious
    hands on the code was late 1991!
    
    Tony

    > SDAF record for file name: OA$SHARE333:ZVFFOWJ34.PS in Drawer:
    > [FOLGADO]PSECTOR Folder: SPD Number: 000033 cannot be accessed by RMS.
    
    I got curious and pulled out the source code... The message indicates
    that a record from DOCDB.DAT is pointing to a file in the shared area
    (OA$SHARE333:ZVFFOWJ34.PS). The file in in the [FOLGADO]PSECTOR drawer,
    folder SPD, document number 33. For some reason or another the FCR
    program wasn't able to read OA$SDAF_E.DAT to locate a record with key
    value OA$SHARE333:ZVFFOWJ34.PS. It could be that the file is an
    attachment, or the body of a mail message, but whatever happened, an
    RMS error was signalled when the BASIC code attempted to read the SDAF
    record. Maybe the SDAF is corrupt, maybe the code is flakey, maybe I
    don't know.
    
    It's hard to be more precise without being able to run the code in
    DEBUG mode against the file cabinet....
    
    Tony

Hi Scott,

>>>If you do MH on a Postscript document, it becomes a mail message.  

If you do MH and then look at SH the VMS filename is then,
not surprisingly for an UNSENT mail, [.MSG]Zmumble.WPL. I dont
think sending that will create a .PS in OA$SHARE*.

>>>  However, I
>>>see nothing in the base note to imply the SDAF record is a top-level message
>>>rather than an attachment...

I guess I'll give you that one....:-)

cheers

Alan.

ps RUI Is any of this being of any use????....unlikely!

    Alan,
    
    I tried doing an MH on a .PS file and I got a nice PS format file in a
    .TXT file in the shared area. I guess it must do the conversion based
    on our default editors. In V3.1, it's sufficiently smart (??) that it
    sniffs the '!PS Adobe' at the front, and won;t let you read it, even
    though it has a .TXT extension!
    
    One of my colleagues in TeamLinks development (or at least our bit of
    it) says that it's easy to create a .PS message and send it, but I
    haven't seen it done yet.
    
    But in answer to your PS (that's the original meaning of Post Script of
    course :-) ) you ask is this of any use? Well I'd say that any
    discussion and technical research like this can only help to increase
    all our knowledge of the way the product works.
    
    Graham