Conference iosg::all-in-1_v30

    Sherald,
    
    I would STRONGLY recommend you do not take the approach outlined in .0.
    
    Reasons,
    
    	In all the many merges that the CSC has performed or been involved
    	with (in excess of 40 to my knowledge), we have NEVER encountered
    	a problem with duplicate SDAF entries. 
    
    	Even if duplicates were detected, it is far easier to deal with
    	them on an individual basis than to attempt a massive renaming
    	most of the existing SDAF, DAF and DOCDB entries. Which may well
    	introduce more problems than it solves.
    
    	Also we cannot under any circumstances provide file layouts other
    	than those already in the public domain to customers. Therefore,
    	any program or procedure that the customer writes would be 
    	unsupportable and unsupported by Digital.
    
    	We have a wealth of knowledge and experience around these issues
    	and would be happy to talk to you or your customer about your
    	plans. However, this level of service is not covered by the normal
    	support contract. Ie. Work beyond general discussion may be
    	billable.
    
    	Give me call if you need to discuss this further.
    
    Cheers,
    
    Iain.
    

    What would be the suggested way of getting the current OA$SHARE files
    into the shared area OA$SHARA? 
    
    They definitely want 2 different mail areas by the time we merge the
    district systems with the head quarters system.  We figured doing it up
    front would be the most reasonable thing.
    
    If additional services are needed outside of what you consider normal,
    what kind of time and cost are we talking about?
    
    What would it take (or cost) to get the detailed record layouts if this
    is what the customer wants?
    
    I know they are probably willing to adhere to what is normal and
    reasonable as long as it meets their needs (as with any customer,
    hahaha).  They definitely need 2 mail areas without merging the current
    E areas between districts & headquarters.
    
    
    Sherald T.
    

    Sherald,
    
    We (the CSC) would not suggest or support ANY method of modifying
    OA$SHARE area references to be OA$SHARA references.
    
    I suggest that you call the CSC and ask to speak to Wendy re the merge
    services that we do offer.
    
    Cheers,
    
    Iain. 

    I concur with Iain.  Changing or rewriting records in SDAFs is an
    activity which could seriously affect the brainpower of your ALL-IN-1
    system.  I also agree that the number of occurences of duplicate SDAF
    records is very much lower today.  The introduction of the OA$FCV
    process (V2.3 onwards) made a major contribution towards the
    elimination of the possibility of creating duplicate file names.  Terry
    Porter put a good writeup of how OA$FCV works in this conference some
    time ago (or maybe one of the archived conferences).  I have met
    duplicate SDAF records during merges, but mainly before V2.3 came along
    or on older systems that had been running for many years prior to V2.3.
    
    Close the common areas now (or leave OA$SHARA open on one system and
    not on the other) and strictly enforce MJU/EW right up until the time
    of the merge.  This will both reduce the time taken to merge the SDAFS
    and reduce the number of messages in the mail shared areas which will
    be common after the merge.
    
    Tony

    Hello Sherald
    
    You may have thought of the following method already, but see if it is
    OK.
    
    You can make all the shared documents private (by archiving and
    un-archiving all user document or write a script to do so) and simply
    merge the user disk and profile.dat.  This may use up more disk space
    at the beginning, but old mails will be deleted gradually anyway and
    this is very save and very little work needs to be done.
    
    Regards
    Banquo

    Hi,
    
    	Be VERY careful if you adopt the approach in .-1.
    
    	Each shared document will be duplicated in the private file cabinet
    	as many times as there are user's with references to it and hence
    	this will use that many times disk space (think about SUBSCRIBERS
    	mail for example).
    
    	Also, while documents are archived they will also be using space
    	in the archive area. This could easily be twice (or more) the 
    	original space required (for an average document).
    
    	Further, archiving and then restoring documents can be very time 
    	consuming and is sensitive to existing errors in the document (eg
    	missing attachment body files). Therefore, if you take this 
    	approach, I would recommend that you ensure a CLEAN run of TRM
    	before proceeding.
    	
    	Finally, you could achieve similar results by just unsharing the
    	documents using CAB UNSHARE function. This has the advantage of 
    	cutting out the intermediate steps but still has the drawback of
    	potentially vastly increasing the disk space required.
    
    	I would still advise a careful study of the various systems and then 
    	merge the various components as discussed previously.
    
    Cheers,
    
    Iain.

    I've been wandering around the internals of the DAF files, etc. for a
    few years now, and while I will be the first one to bow down to the
    knowledge of Tony, the IOSG crowd, and the CSC's etc..   Just changing
    the "letter" of the OA$SHARx##:Z....  would not seem too impractical (?).
    
    	Although living dangerously, you don't need to know the structure
    of the DAF records (or PENDING records) as much as correctly handling
    the variable length aspect.  You could even ignore the fact that some
    records are continuations (don't ignore the records, just the fact that
    they are continuations).  If it's an "across the board" change from
    "E" to "A", wouldn't a general string search and replace work?
    Personally, I wouldn't use either COBOL (really?) or FORTRAN
    (much better), but then I've done all my hacking in BASIC.
    
    	If you really want to verify any field you're changing before
    changing anything, then you have to get the field code for each one,
    but it's hard to keep track of all possibilities.  I'm not going to put
    them in here myself to prevent some people thinking it inappropriate
    for this conference.
    
    	As for Digital support afterwards.  That's another question.
    As with anything of this complexity, the probability of missing or
    messing something is high, as the previous notes are cautioning.
    I still say it's a risky venture too, but...
    
    	To the rest of the replies:  What or where would there be a
    problem?  Assuming the programs are written carefully, and ALL
    appropriate files to be changed are considered.
    
    	Bob Halsey, Toronto SWS
    
    	Bob Halsey, Toronto SWS

    Oh, and then how about the pointers to this record as an attachment. 
    Make sure you find them too... Sure you could play with the record keys
    without knowing the structure of the record, but the attachment
    pointers are part of the record and must be changed too. (And the
    attachment pointer could be in any ole persons private daf) Oh, and since 
    the filename is the key to the DAF record, you cannot just 'change' 
    the filename, you have to add a new record and delete the old. 
    
    I'd vote with the crowd not to mess with this stuff. It be too easy
    to leave a broken connection to the document somewhere in the overall
    system.
    
    Rick

    	I didn't really intend to get drawn into this, but since I give my
    opinion too.
    
    	I was presuming that the entire record would be scanned, along with
    every other record in every account (sDAF, pDAF, DOCDB, etc. etc.).
    The point of adding a new record is a good one.  How about converting
    it to a sequential variable length first, scanning, then converting
    back (and the potential mess gets worse...).
    
    	We can't forget renaming the files also...
    
    	The changes will have to be completely global on all related files.
    Yes, I FULLY appreciate the thinness of the ice here.  It needs some
    real careful skating.
    
    	Bob

Hi,

>> I was presuming that the entire record would be scanned

For which you'd need to know the record structure to identify the attachment
pointers (ie filenames)!

>> every other record in every account (sDAF, pDAF, DOCDB, etc. etc.)

This would take so long, and be so risky, that other methods, such as unsharing
every document, look more attractive.

They'd need to look at their ssytem and assess how this would impact disk space:
ie check how many shared-area documents there are with high usage counts.

Scott

    I know it appears like a rather na�ve approach, but searching for the
    string "OA$SHARE" possibly including context verification such as
    ":Z" immediately after, would find them.  Since there is no field length
    change, the type does not necessarily have to be known.  Yes, if
    Sherald wanted, a check for specific field type could be done which
    unless you have a template program, is not fun to do with Remapping,
    etc.  I have a complete DAF record breakdown program if it would be
    useful.
    
    As for time constraints, I also presume that for such a large project,
    that time wouldn't be  problem.
    
    As for unsharing.  Not only does that cause massive redundency in disk
    usage (wastage?), but it also destroys the document attachment
    structure.  For a few users (5-10), maybe ok.  For an entire system!
    Definately NOT reasonable.
    
    Sherald, say something please!  I'm trying to hold a small flag for you
    and am getting it beat up on.
    
    	Bob

Hi,

>> searching for the string "OA$SHARE"

As it's quite unlikely that any other field would have that value (maybe one
of the recipient's username is OA$SHARE? :-), yes I agree it would work.

>> As for unsharing.  Not only does that cause massive redundency

Which is why I suggested they check usage counts: it's surprising how many
"Shared" messages have a usage count of 1 or 2.

>> getting it beat up

Nah, no-one's beating anyone up.  We're just exchanging technical information,
suggestions and viewpoints.  Well, that's what I'm doing! :-)

Scott

    Do we have a convert here?
    
    Yes, another "it would work" for you Sherald (see .0).
    
    As for the 1 and 2 count DAF records, see note 1115.  I've got a little
    package that localizes those single pointer records selectively where
    appropriate (checks for attachments, etc).  You'll find on a mature
    system, 50% - 60% of the records are single pointers!
    
    It's not me being beat up, it's the concept being proposed.  But hey,
    isn't that the *fun* of notes?
    
    Bob
    

    Bob,
    
    	I agree it would work, but ...
    
    	Why take the hit of processing every SDAF, PENDING, DAF and DOCDB
    	file on the system ?
    
    	Surely, it's far quicker and SAFER to stick with documented and
    	supported VMS Utilities ($CONVERT et al) ?
    
    Cheers,
    Iain.

    For the end goal of what is trying to be done here, there are no fully
    supported VMS procedures or Utilities.  Wherever possible, I presume
    one would be used though.  Like CONVERT to scan a sequential file
    instead of an indexed and then CONVERT back.
    
    I don't know if I would trust a standard editor (TPU or otherwise) to
    do the substitution on the various files. Especially the variable
    length record ones.  It would probably work, but my instincts would
    turn away from it.
    
    From my minimal understanding of .0 (the author hasn't replied yet!),
    the sequence is:
    	1.  Convert OA$SHAR*E*....  to OA$SHAR*A* on several of their
    		systems.
    	2.  Merge the NOW OA$SHARA's with a very large OA$SHAR*E* system
    		will less fussing around than with two "E"'s.
    
    In the various mergings I've done over the years, the "A" and "E"
    one was the simplest logistically by far.
    
    Bob

    Sorry it's taken so long for me to respond, but I've been out celebrating
    yet another BIRTHDAY and working with other customers.  I haven't been
    ignoring anyone. (REALLY!!!)
    
    I presented the options to my customer and they decided to merge the
    OA$SHARE directories and files, deal with any duplicates, and create
    another mail area.  Something around not losing their ALL-IN-1 support
    and saving time.
    
    Thanks to all for the responses and the support.
    
    Sherald T.