Conference iosg::all-in-1_v30

    Re .0
    
>	Now this is what I would expect if I had done a FOR on CALL_QUEUE 
>	directly, as I am changing what I am looking at, however, when I 
>	do a bind, I do not expect the bound dsab to change with the 
>	original dsab.
    
    When you do a BIND it does not loop through the data set. Think of the
    disastrous consequences if it did with large data sets (such as some
    users' READ folders)! BIND just establishes a connection - the FOR loop
    does the work, and FOR does not know that some records have arrived
    since the original BIND.
    
    There are probably quite a few workrounds for your case. I would be
    inclined to build up a symbol containing specialist names in the FOR
    loop, e.g.
    
    GET #S = ""\
    FOR *CALL DO 
      .IF #S EQS "" 
         THEN GET #S = .%KEY
         ELSE GET #S = #S "," #S
    
    Then do
    
    FOR OA$TABLE:#S DO 
	GET #SPEC = .%KEY\\
	FORM CALL_SPEC
    
    This then ensures your FOR loop will not contain any records created
    since the BIND.
    
    Cheers
    
    Stuart
                 
    

Funny, because the documentation implies that it does create a set in memory:


'The BIND function builds a phantom data set in memory.  This phantom data
set exists until a BIND_BREAK command, or until the end of the ALL-IN-1 
session'


Should read:

'The BIND function builds a phantom data set in memory.  This phantom data
set OR SOMETHING VAGUELY SIMILAR TO IT exists until a BIND_BREAK command, or until the end of the ALL-IN-1 
session'



		Steve

    HI,
    
    
    Please can you elaborate on how the BIND makes the connection to the real
    dataset, if it is not an in-memory structure? 
    
    How does this connection vary depending on which of the BINDW or BIND
    functions is used?
    
    -Trev
    
    

    Re .3
    
    I like to think of a BIND as being akin to a file open, and a
    bind_break to a file close. A BINDW will will open the file in write
    mode rather than read mode.
    
    Cheers
    
    Stuart

	Or think of the BIND as defining the *criteria* for the phantom data set,
as various records in the underlying data set are "touched".  In this respect,
it's not quite like the DATATRIEVE FIND, which will immediately establish a
collection of matching records.

	However, since in the majority of cases, a BIND is followed by some
application that *does* touch all of the records (usually a FOR), it is often a
moot point.  It is only when the BIND is distinctly separated from any direct
record access that you see this anomaly.

	F

    Hi,
    
    	Firstly, thanks for your interest and replies on this note, now
    perhaps you could explain the following for me? As I really need to get
    to grips with exactly what goes on here.
    
    I have an entry form call suggentry that points to suggent.dat.
    
    <bind *foo to suggentry     
    
    It only has 1 record and a,
    
    <for *foo do get .%whole
    
    returns the data.(as expected)
    
    So, If the phantom is only 'criteria' driven like Frank suggests or like a 
    'file open' as Stuart says, to look at the data in the 'real' dataset, and 
    seems to pick up NEW records, why when I do this
    
    <delete_file suggentry.dat
    <for *foo do get .%whole
    
    does it still return the record? If it somehow doesn't know about NEW
    records as Stuart says, it should also not know about the now deleted
    record or file!!! but it seems to have retained an in-memory copy of
    the file.
    
    A <bind_status reveals the name of the file, but this no longer exists
    after the delete_file above.  Surely, this suggests a difference in
    beahvior that what has so far been disclosed?
    
    
    -Trev

    Remeber, a phantom contains an in memory array of RECORD FILE
    ADDRESSES. (Ie pointers onto disk). Plus when the phantom is opened
    the file is opened. When you do a DELETE of a file, the information
    on disk still exist, you have just freed the directory pointer, and
    the diskspace will get reused - ONCE all of the open references are
    closed. So as long as the phantom is open, the diskspace will be
    retained, and the information will remain on disk - so the phantom
    can still return disk records. Even if the file is not deleted,
    someone else may even delete a record in the file, but you could 
    still see that record via the phantom, as the disk space is still 
    present for it. (RMS deletes the record pointer from the index, but
    doesn't free the space until the file is compressed)
    
    Rick

    Hi Rick,
    
    	That seems to answer the case of removing records that had pointers
    already 'stored' in the phantom. How about those records added to the
    RMS file after the initial BIND, i.e. those that didn't have RFA's
    stored in the phantom, how are these suddenly spotted by the phantom?
    Is there some sort of update going on behind the scenes?
    
    -Trev

Hi,

	There seems to be two explanations of the way BIND works:

	One appears to be a list of RFA's which answers the question in the 
	previuos two replies - why the phantom is still there after the 
	data file has been deleted - the other is that the phantom is merely
	'criteria' for finding records,- which doesn't work for the above - 

	but if it were a list of rfa's, then there is no way that the phantom
	should be updated when new items appear in the datafile, but the 
	criteria explanation works in this case.



		Steve

    The new records will be in cache (for a while).
    
    A DUMP_CACHE will get rid of them (possibly preceded by a BIND_BREAK
    asa I suspect the dataset won't be dumped out of cache if there's a
    phantom still bound to it).
    
    D.

    RE: .9
    Are you adding the records to the file or the Phantom?
    
    IE: write add x     or     write add *x   ????
    
    
    
    Also if your adding records to the end of a file, the phantom may
    still find them - as it doesn't preload the memory array of RFAs.
    It only finds what it needs, then stores a pointer to last record
    read. Each time you ask for the next record it picks up from where
    it left off. So new records may or may not show up depending on where
    they fall in sequence with the already searched records.
    
    Rick

	There's really two "classic" ways that an application might ordinarily
create the RFAs in a phantom data set.  The first -- and simplest -- is with a
quick FOR statement.  In this case, the entire data set is processed, and all
records that match the BIND criteria are included in the phantom.  Using this
method, if you were to add new records to the underlying data set, they would
not become part of the phantom.

	The other way is to process records individually...  perhaps where, after
the BIND, you are reading records individually, using something like %NEXT.  In
this case, if you've already begun processing the data set, but are still 
%NEXTing through it (creating the phantom in the process), and new records are
created, they *would* be added to the phantom as you "touched" them.

	F

OK,

	Of the 'two classic ways' which one does ALL-IN-1 use??



		Steve

	Any application can use either way.  In the vast majority of cases where
ALL-IN-1 creates a phantom data set, it is doing it for the purpose of displaying
it on an index form.  As a result, all of the records in the data set are
processed, so that they can be displayed.  In other words, by the time you see
the phantom records displayed on the index form, the entire data set has been
processed.

	BTW, there *is* one case where the BIND itself processes all records, and
that's if you use the BIND/SORT.  In order to correctly process the /SORT
qualifier, all records of the data set must be processed, and evaluated against
the BIND rse; so this causes the phantom records to be established immediately.

	F

    Ah sorry Frank, when used with a INDEX form, the whole file is not
    searched before we display! We only search the file until enough
    records are obtained to fill the screen. Then when you hit next screen
    we read enough records to fill the second screen. SO unless the search
    criteria (or file) results in less records than a screen full being
    selected - you will not have read the entire file before display and
    so new records could show up.
    
    Rick

    Rick is so right in .15.
    
    You can see this behaviour (on V2.4 or V2.3 systems) if you attempt to
    execute a BIND against an alternate KOR. 
    
    For example:
    
    BIND *A TO PROFIL:VMSUSR WITH .VMSUSR = "R" 
    
    will execute as normal and display the first screen of records quite
    quickly. Press GOLD/B to force ALL-IN-1 to build the rest of *A and see
    what happens. Actually, sit back and make yourself a coffee as the
    function will take a long time to execute...
    
    The bug/feature is fixed in V3.0, so BINDs against alternate RMS KORs
    work.
    
    Tony
    

    Hi,
    
    	I tried a DUMP_CACHE after DELETE_FILE and this made no difference,
    as expected the record was still mapped by the phantom.(Rick's
    explanation holding true here.) 
    
    I am not sure, Frank, but you seem to be contradicting your earlier
    note .5 , your .12 seems to indicate the behaviour that I expected,
    i.e. no new records in the phantom (just like a Datatrieve find).
    Whereas .5 was on about 'criteria'! Rick's RFA's are not so much
    criteria but a DIRECT link to a SPECIFIC record on disc.
    
    Either it does locate new records or it does not! Rick's reply seems to
    cater for some records being found and others not being found... a
    rather haphazzard hit or miss mechanism, but it may fit our experiences...
    Is this the design intention or is it something that is likely to change?
    so that you can really be SURE of what will be in your PHANTOM.
    
    -Trev

    Re. 17
    
    Did you BIND_BREAK the phantom before issuing DUMP_CACHE?
    
    Also, please don't use the BIND_BREAK/ALL function (in V3.0) without
    considering the consequences on other applications. For example, CM+
    maintains a number of phantom data sets used to control the context
    sensitive menus. If you blow away all the current phantoms then CM will
    have a very hard time...
    
    Tony

    re .18
    
    No, a BIND_BREAK was not done. This would have lost the RFA's for
    certain. This note is trying to establish the way in which phantom data
    sets are established and maintained, and also to discover what
    relationship they have with the 'real' file contents, after file
    updates have occured(also after the initial BIND).
    
    _Trev

    I've asked the person here who actually _knows_ about this stuff to
    look at this note and, hopefully, add some light to our various
    thoughts.
    
    Dave.

There following descriptions of phantom data-sets are 100% on the mark.


SHALOT::WARFORD "Richard Warford @OPA DTN 393-7495"  14 lines  21-MAY-1992 17:47

    Remeber, a phantom contains an in memory array of RECORD FILE
    ADDRESSES. (Ie pointers onto disk). Plus when the phantom is opened
    the file is opened. When you do a DELETE of a file, the information
    on disk still exist, you have just freed the directory pointer, and
    the diskspace will get reused - ONCE all of the open references are
    closed. So as long as the phantom is open, the diskspace will be
    retained, and the information will remain on disk - so the phantom
    can still return disk records. Even if the file is not deleted,
    someone else may even delete a record in the file, but you could 
    still see that record via the phantom, as the disk space is still 
    present for it. (RMS deletes the record pointer from the index, but
    doesn't free the space until the file is compressed)
    
    Also if your adding records to the end of a file, the phantom may
    still find them - as it doesn't preload the memory array of RFAs.
    It only finds what it needs, then stores a pointer to last record
    read. Each time you ask for the next record it picks up from where
    it left off. So new records may or may not show up depending on where
    they fall in sequence with the already searched records.
    
SHALOT::NICODEM "Who told you I'm paranoid???"       14 lines  22-MAY-1992 13:09

	BTW, there *is* one case where the BIND itself processes all records,
and that's if you use the BIND/SORT.  In order to correctly process the /SORT
qualifier, all records of the data set must be processed, and evaluated against
the BIND rse; so this causes the phantom records to be established immediately.


Trev,

>    Either it does locate new records or it does not! Rick's reply seems to
>    cater for some records being found and others not being found... a
>    rather haphazzard hit or miss mechanism, but it may fit our experiences...
>    Is this the design intention or is it something that is likely to change?
>    so that you can really be SURE of what will be in your PHANTOM.
 
Phantoms will continue to defer reading records from the underlying file
until the latest possible time. This means that in the sort of application
described in .0, it is possible that new records can appear in the phantom.
If you want another type of behaviour then the following trick should suffice.

Create the phantom:

	BIND *FOO TO BAR.....

Read the records until EOF is reached. The phantom data-set will remember that
we found EOF and will never look for any more records.

	FOR *FOO DO OA$NULL

Process a fixed set of records

	FOR *FOO DO ...\\FORM BAR\\...

Cheers,
Derek

	Thanks for clearing that up - its very unclear in the documentation
	that this is what goes on.  What my idea of a BIND used to be was the 
	two statements:


	BIND *FOO TO BAR WITH ETC\
	FOR *FOO DO OA$NULL


	which is what I shall use in the future - the problem was that I was 
	trying to use bind specifically to change a dataset, using it as an 
	unchangeable reference into it.


		Steve 

    Hi Derek,
    
    	So, the golden rule for making sure that new records don't
    unexpectedly appear, is to use read all records until BIND gets the nod
    from the EOF marker. If no EOF then expect new records (sometimes..).
    
    	This seems to explain the other half of my earlier question,
    however, if you have a very large dataset it could take some time until
    this EOF is reached, you may not wish to read all records to guarantee
    that the phantom has ONLY what you want(and no later surprises!). Is 
    there a way of forcing an EOF into the phantom, without having to process 
    all records? Or is this THE ONLY way to guarantee contents of a
    Phantom?
    
    -Trev