| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 824.1 | Well, don't use TU... | IOSG::TALLETT | Arranging bits for a living... | Mon Jun 08 1992 16:19 | 42 |
| Hi there!
> 1. Is there a tool that helps in bulk transfers of ALL-IN-1
> accounts, say in batches of 30-40 accounts.
No, not really. Transfer User is not really suited to this
kind of operation. If you have knowledge of ALL-IN-1 file
structures, you could probably do the merge "by hand" with
disk copies and creating new shared areas/users etc.
> 2. What happens to the transferred documents on the target
> ALL-IN-1 cluster ?
> Are they still shared or they end up as documents with single
> ownership ?
The transferred documents end up in the shared areas but with
one copy per user transferred.
> 3. How to increase the number of disks that is provided in account
> creation templates ? Presently, restricted to 3 only. Can this
> be customised ?
>
Yes, don't see why not. You'd have to modify the code that reads
the template too of course.
Care to comment Dave (T)?
> 4. Why is the total number of SDAF's restricted to 5 ?
> Can this be increased ?
>
See a previous note on this one.
> We would like to complete the merge in max. 4 weeks. Any help/advise
> is highly appreciated.
It might take 4 weeks for the transfer user routine to run on
300 users... :-) Sorry, couldn't resist!
Regards,
Paul
|
| 824.2 | Use DCL . . . | IOSG::SHOVE | Dave Shove -- REO-D/3C | Mon Jun 08 1992 18:37 | 7 |
| This can be done by copying and merging the appropriate files with DCL
utilities. I have a feeling that someone once wrote a step-by-step
procedure for it - it may be in one of the old versions of this
conference. Or someone with a better memory than mine will tell you
where to find it.
Dave.
|
| 824.3 | If you can't find the proc mentioned in .2 ... | UTRTSC::BOSMAN | We're just sugar mice in the rain | Tue Jun 09 1992 08:03 | 14 |
| Hi,
Once I wrote a procedure to copy x ALL-IN-1 accounts, where x is as
large as you want. Also the UAF record and the ALL-IN-1 profile are
copied. It as based on standard DCL (BACKUP etc.).
(Ofcourse) there ara a few restrictions:
1) Archived documents are not handled correctly.
2) The user must have read all the new mail messages.
I'm not sure about the NETWORK record, and have to check on that one (I
don't have the procedure on line).
Regards, Sjaak.
|
| 824.5 | DAF limit discussed in 766.* in ABBOTT::A1INFO | IOSG::TALLETT | Arranging bits for a living... | Tue Jun 09 1992 19:23 | 1 |
|
|
| 824.8 | Don't really need A1INFO membership (for SDAF Qn) | IOSG::SHOVE | Dave Shove -- REO-D/3C | Wed Jun 10 1992 14:14 | 11 |
| However, the answer in A1INFO wasn't especially secret.
Basically, it's "NO" (The number of SDAFs can't be increased). It's
firmly embedded in the Bliss code, and would have to be changed in a
good few places.
The reason was, as usual, a compromise. Each SDAF stream uses up a fair
amount of buffer space in the image - 5 was chosen as the largest
number without this space getting excessive.
Dave.
|
| 824.9 | Not good enough | UTROP2::BEHARI_A | Ajay Behari @UTO | Thu Jun 11 1992 15:19 | 17 |
| >Basically, it's "NO" (The number of SDAFs can't be increased). It's
>firmly embedded in the Bliss code, and would have to be changed in a
>good few places.
Does it mean we sell "NO" to customers because it's hardcoded in our
software ?
Can it be regarded as a 'wish-item' for a future release or a patch ?
The question is not new (having read the note in A1INFO) & is bound to
come back.
However you look at it, it is considered a limitation - & maybe
frustrating for customers who have enough disks to spread the SDAF's
around & keep them small as well.
Ajay.
|
| 824.10 | Sorry - I think I was misunderstood | IOSG::SHOVE | Dave Shove -- REO-D/3C | Thu Jun 11 1992 18:25 | 18 |
| When I said "NO it can't be increased" I meant it can't be increased by
anything that _you_ can do, on site, without sources.
Of course _we_ can increase it, as part of our development cycle. After
all, we increased it originally (from 1 to 5).
As you say, several people have said that it might be useful to allow
it to be further increased, so we should look at doing this as an
enhancement. We'd need to make the limit adjustable (probably by a
re-link, as it invoves setting up _lots_ of data structures), so sites
that didn't need lots of SDAFs wouldn't get lumbered with all the data
structures.
As usual, although we do trawl these notes files for "wish list" items,
you should mention it to our Product Manager if you want to be sure
that it gets on the list for a Possible Future Release.
Dave.
|
| 824.11 | Chapter 3 of ATO | SIOG::T_REDMOND | Thoughts of an Idle Mind | Tue Jun 16 1992 19:20 | 8 |
| There is a step-by-step section on how to merge ALL-IN-1 systems
together to form a cluster in "ALL-IN-1: A Technical Odyssey". This
advice is OK for V2.3 or V2.4, but needs to be updated for V3.0 as
items like the PARTITION and FILECAB need to considered now. So far I
haven't had the chance to merge systems under V3.0 so I haven't done
any work to update the steps.
Tony
|