Conference iosg::all-in-1_v30

    Hi,
    
    Try:
    
    for first cab$ with .folder eqs "XXXX" DO oa$null
    
    Then test symbol oa$sel_count which will contain 0 if the folder does
    not exist.
    
    The other alternative is to purge the error messages using
    OA$MSG_PURGE.
    
    Cheers
    
    Stuart

Stuart,

>    
>    The other alternative is to purge the error messages using
>    OA$MSG_PURGE.
>    

Will this supress the meesage being written
to the log file?

If so, then where would this command be placed? 


Thanks,

Chaim

I am curious how/why you are "creating" folders.  Folders don't exist as a
separate entity; they are merely an attribute of documents within the folder. 
So if you delete all documents in a folder, the folder vanishes; likewise, you
can't create a folder that has no documents in it.

If we have a better handle on what you're trying to do, suggesting the best
solution will be easier...

Scott

Scott,


>                   -< Folders can't be created on their own >-
>
>I am curious how/why you are "creating" folders.  Folders don't exist as a
>separate entity; they are merely an attribute of documents within the folder. 
>So if you delete all documents in a folder, the folder vanishes; likewise, you
>can't create a folder that has no documents in it.
>
>If we have a better handle on what you're trying to do, suggesting the best
>solution will be easier...

The customer is a export company which deals with many countries and companies. 
Each user SHOULD have an explicit folder for each country and company. He does
NOT encourage his users to create the folders by themselves in order to
eliminate typing errors in the folder names. Since during the course of work a
folder could be inadvertantly deleted and because he has new users being
entered into the system, he runs a job periodically which checks each account
and creates the folder(s) needed (with a dummy document).

Actually the customer would be much happier if a folder could exist as an
entity in its own right.

I believe the suggestion using "FOR CAB$ ..." is very acceptable.

Thanks,

Cb.

    
    if you are using V3.0 or later, and if you are talking to a non-MAIN
    drawer. There maybe an easier way to do this, though I don't know how
    much work it would take on your, or your custoemrs part.
    
    As Scott said, folders don't physically exist and usually cannot
    be created by themselves. However, there is a feature of the FCS
    which allows creation of empty folders, with some catches of course.
    
    Empty folders can be created via the FCS with the following
    understanding:
    
    1) They will NOT be visible to VT IOS. They are stored in an internal
    	to the FCS list and don't become "physical reality" until something
    	actually is put into them.
    
    2) if a clustered environment, this list of empty folders is NOT
    cluster wide. What I mean is if you have a cluster made up of nodeA
    and nodeB and connect to the FCS on nodeA, create an empty folder,
    nodeB does NOT know about the empty folder. THere would be no real
    bad side effects to this other than nodeB won't see the folder on a
    lookup and if you later really created the folder (put a doc in it)
    from nodeB, nodeA woudl then have a stale cache entry, there would be
    no problem wiht this (nodeA's entry) since if you ever used nodeA to
    access the now non-empty folder, it will check if it exists before
    checking the empty folder list.
    
    3) If you have a real folder, (again on a cluster), then delete all
    docs in it, but leave the folder, and you do this on nodeA, a later
    check with nodeB would not find the folder (the name would have been
    saved on nodeA's empty folder list, but not on b's)
    
    4) The empty folder list does NOT survive a FCS re-start
    
    So it can be done, but there are some catches. Other options to use
    could be (in addition to what Stuart suggests) use drawers rather than
    folders, put a "dummy document" in each folder etc
    
    --Bob
    

    Re.2
    
    Chaim,
    
>>    
>>    The other alternative is to purge the error messages using
>>    OA$MSG_PURGE.
>>    
>
> Will this supress the meesage being written
> to the log file?
>
> If so, then where would this command be placed? 
    
    There is not an easy answer to this. If you look at some of ALL-IN-1's
    housekeeping procedures you will see an example of an application
    controlling the display of error messages. It uses view$ to display the
    messages so far into its own log, and then purges them with
    oa$msg_purge. I think if an application never purges then they get
    written to a1sub.log on exit. 
    
    Putting oa$msg_purge in will get rid of all messages up to the point it
    is called. If the application is writing messages of its own, then this
    would not be a good thing to do. If so then the for cab$ loop will bne
    better.
    
    Cheers
    
    Stuart