Conference iosg::all-in-1_v30

Hi,

When RSD creates new directories, it creates them on the disks specified in the
data file(s) mapped by the form SMSAMDIRDEVICES.

This is an entry form, and its .FILE directive uses the logical name
OA$SHARED_DEVICE_FILE to point at the data file.

RSD defines this logical to be OA$DATA_SHARE:OA$SHARx_DEVICE_MASTER.DAT,
where 'x' is the mail area suffix: ie 'A' or 'E' in your case.

So, the first thing to check is that you have two of these files, one listing
the disk(s) for area A, and one listing the disk(s) for area E.  The next thing
to check is their file protection.

If all that's in order, things start to get tricky, as unfortunately, RSD
doesn't check that the logical name creation succeeds.  So it is possible that
it defines the logical for area A, uses it, then defines it for area E, which
fails, so re-uses the file intended for area A, as the logical still has the
old value.  However, I think it far more likely that the file for area E is
either missing or has the wrong contents (although if this is so I'm confused
as to why MMA CDD works).

So: check the data files, and let me know the result.

Scott

Thanks for the quick answer. 

Because of the disk-headers became full, we closed them and opened a 3rd 
mail area also, OA$SHARB. (on the disk "U", unfortunately the user disk, 
which is very bad!)

The protections are interesting. Which is good ?
(OA$SHARE and OA$SHARA were created in 2.4, before the upgrade to 3.0)
(OA$SHARB was created now, in 3.0 with K701)

A1MGR>dire/sec oa$data:oa$shar*_device_master.dat

Directory ALLIN1$DATA:[DATA.DATA_SHARE]

OA$SHARA_DEVICE_MASTER.DAT;9
                     [DESK,ALLIN1]         (RWED,RWED,RE,)
OA$SHARB_DEVICE_MASTER.DAT;4
                     [DESK,ALLIN1]         (RWED,RWED,RE,)
          (IDENTIFIER=OA$MANAPP,ACCESS=READ+WRITE+EXECUTE+DELETE)
          (IDENTIFIER=OA$PRVAPP,ACCESS=READ)
OA$SHARE_DEVICE_MASTER.DAT;25
                     [DESK,ALLIN1]         (RWED,RWED,RE,RE)

Total of 3 files.

The contents of the .DAT files look fine:

A1MGR>type oa$data:oa$shara_device_master.dat
1   ALLIN1$SHAR2:                                                                                                                       

which is disk "A",
                                                                                                                                       
A1MGR>type oa$data:oa$sharb_device_master.dat
1   DISK$USER2                                                                                                                          

which is disk "U",                                                                                                                                       

A1MGR>type oa$data:oa$share_device_master.dat
1   ALLIN1$SHAR:                                                                                                                        

which is disk "E".

SM MMA ISD for OA$SHARE shows: first shared directories are on 
ALLIN1$SHAR:, but the newer ones (after opening OA$SHARA) are also on 
ALLIN1$SHAR2:

Thats all, I can show you as a result.

Kati

Hi,

To answer the question about file protection, I think the protection on
OA$SHARB_DEVICE_MASTER.DAT is the correct one.  I'm surprised the post-install
stuff didn't update the protection on the other two files to match.

I'm afraid I can't think what else might be wrong.  As we haven't had anyone
else report this, I think it's something system-specific rather than a problem
in RSD.  I've had another look at the code and nothing springs to mind, but if
it does I'll let you know.

But in the meantime, a few more questions:
Who is the owner of the DEVICE_MASTER files?  What user account does RSD run
under?  What privileges does that account have?  What disk does RSD use to
create new directories for area B?

Scott

        Hi Scott,
        
        your questions are rightful.
        
        In our inhouse system nobody has nothing to do with ALL-IN-1, 
        only the ALL-IN-1 manager. So the owner is ALLIN1, (UIC [2,1] is 
        system UIC), and she does everything, including all the 
        housekeeping.
        
        RSD - shared dirs of area B:
        In the recent case, when A and E areas are closed, only B is 
        open, the RSD worked correctly, created shared directories for B 
        area on disk "U". 
        I know, that this answer is not sufficient for you. But as B area 
        is new and unfortunately has to much shared directories, opening 
        A and E and running RSD didn't give the expected result, because 
        RSD didn't created new directories for B, only for A and E, on 
        the same manner, as before.
        I have to wait some days, until the shared directories of B get 
        full enough.
        
        On the other hand, I feel, that the key file, which gives the 
        "mail_area" parameter as P1 to the lower-level procedures of RSD 
        is OA$AM_REORG_SHARED_DIRS.EXE.
        As I guess, this .EXE has to switch between the mail areas during 
        RSD. Do you have the possibility to check it's source code ?
        (The newest version of that .EXE comes from K701 patch !)
        
        Thanks in advance !
        
        
        

Hi,

>> So the owner is ALLIN1, (UIC [2,1] is 
>> system UIC), and she does everything, including all the housekeeping.

In ALL-IN-1 V3.0, the housekeeping procedures do not necessarily run under the
same account as the system manager or the person who submitted the job.  There
is a system policies field which defines the VMS account name used for
housekeeping jobs.  Perhaps you should check that.

>> OA$AM_REORG_SHARED_DIRS.EXE.
>> As I guess, this .EXE has to switch between the mail areas during 
>> RSD. Do you have the possibility to check it's source code ?

Yes, I have the source code; I wrote it! :-)  The way the EXE "switches" mail
areas when creating directories is as described in .1: it redefines a logical
that is used by an entry form to point at different files.

It is beginning to look as though this logical name redefinition is failing
for some reason.  Here's why I think this:  When RSD has finished creating
directories for area A. it throws away the list of disk names it has, and
creates a new list of disks to use for the next area (in your case area E).  So
it is not (I hope!) possible for RSD to be accidentally re-using the wrong data.
The only way it can be using area A's disks when it should be using E's is if
it re-reads the DEVICE_MASTER file for area A when it thinks it is reading the
file for E.  The only way this can happen is if the logical name is still
pointing at area A.
(I have nasty thoughts about ALL-IN-1 caching the data set contents, so that the
logical name change doesn't get "noticed" by ALL-IN-1, but I hope this isn't
true!)

Of course, there's still the possibility of incorrect file protections, or
insufficient privileges, messing things up, so please check this too.

Also, if you can give me a pointer to an RSD log file from a run with the A/E
error, I can see if there's anything unusual in there.

Scott

Hi Scott,

the only things I could do this moment is to sho you our index of shared 
directories and the RSD log file.

***** LOG FILE MOVED TO IOSG::NOTES$LIBRARY:ALL-IN-1_2963_6.LOG ******
***** DO NOT POST LARGE LOG FILES DIRECTLY IN THE CONFERENCE.   ******
***** 						Graham.         ******

The newly created shared dirs are:
	for A: 38, 39, for E: 79, 80 on the same disk:allin1$share2.
You can see, that before creating OA$SHARA, the shared dirs of E were on the 
right place. Look dirs from 1 to 54. 

We don't know, how is it possible to check the logical name table. I didn't get 
any error message about that it was full.

Many thanks, I'm hoping....
Kati

Hi All,

I've been working this off-line with Katalin, and here are the results.

The disk-name master files are accessed through the entry form SMSAMDIRDEVICES,
which uses a logical name to point at the file for a particular mail area.

What RSD does is define the logical to point at (say) area A's file, then it
reads the disk names and creates the directories for area A.

It then redefines the logical to point at (say) area B's file, reads the disk
names from that file (or so it thinks) and creates the directories for area B.

However... it seems that ALL-IN-1 is being too clever.  The first time the
entry form is accessed, the code translates the logical name to get the file
name.  This file name is 'remembered', and ALL-IN-1 doesn't retranslate the
logical name on subsequent accesses to the file, even if it has changed.  Thus
ALL-IN-1 always reads the disk names from the first file it has used.

The 'simple' fix for this is for RSD to tell ALL-IN-1 to DUMP_CACHE before it
tries to read the second file, however, I don't think that's the correct fix.
When people use logical names for the .FILE directive on entry forms, it is
because they want to switch files 'on the fly', so I don't think it's right
that ALL-IN-1 caches the file name and thus restricts this functionality.

We'll discuss this here in engineering and work out the best fix.

Scott