[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

1652.0. "non-unique address look up with network" by AIMTEC::BUTLER_T () Thu Oct 22 1992 21:53

Below is a message I received from a specialist.  My instinct tells me
    what is taking place is correct - profile is going to get looked at.
    I also do not think the address length is a problem.  EMHEAD is about
    75.  SMITH is not unique and no where near long enough.
    
    
    First, I need to determine what is being done and then I know what 
    the follow-up question will be .  What can He do to make it work the
    way he wants?
    
    Thanks,
    
    Tim
    
From:	GLDOA::FINKELSTEIN  "Digital Services - Metro Detroit District" 22-OCT-1992 13:09:06.12
To:	AIMTEC::BUTLER_T
CC:	FINKELSTEIN
Subj:	Kellogg

Kellogg Company is running ALL-IN-1 2.4.  We customized forms NETWORK and
NETWORK$CREATE to increase the network address field from 62 to 126 
characters.  No other changes were made to the FMS forms.  NETWORK.FDL was
updated to reflect the increase in size of the record length.  NETWORK.DAT 
was converted by using OA$CNV_CONVERT.

Almost everything is working perfectly.  When the TO: or CC: field is
entered to specifiy a unique user, the network address is correctly
extracted from the new NETWORK.DAT file.  There is a problem however when 
the TO: or CC: field is entered such that the user name is not unique.

On an uncustomized system, if we send a message to SMITH, the directory 
selection screen is displayed containing all users with an account name 
starting with SMITH, for example:

	1 SMITH
	2 SMITHD	It is my understanding that when ALL-IN-1 pulls
	3 SMITHERS	accounts out of NETWORK.DAT, they are not in
	4 SMITHR	alphabetical order for all systems.  Kellogg
	5 SMITHS	performs NETWORK.DAT synchs with 7 VAXclusters.
	6 SMITHSJ	Note (1) and (7): both are SMITH, but on different
	7 SMITH		ALL-IN-1 systems.
	8 SMITHA
	9 SMITHC

On the customized system (as described above), if we send a message to
SMITH, the directory selection screen is NOT displayed.  The first SMITH
that would have been displayed on the directory selection screen is placed 
on the TO: line.  Note that this SMITH is a local user.  Is it possible that 
the account was pulled from PROFILE.DAT?  If we enter SMITH and GOLD-L, the
directory selection screen is not displayed and the second SMITH (from line
7) is placed on the TO: line. 

If from another customized system (as described above), we send a message 
to SMITH, the directory selection screen is displayed containing (1) and (7) 
above since neither of those SMITHs are on the local system.

It appears that the customization affected the lookup logic.  I spoke to 3 
ALL-IN-1 support people and they suggested that I discuss this with someone 
who has access to the source code.  Apparently, having a customized NETWORK 
or NETWORK$CREATE form, affects the logic path.  I performed a DIFF between 
the standard and the customized .FLG files, and the only differences are 
the screen width (80 .vs. 132) and the size of the field (62 .vs. 126).

I'm in the office.  You can call me at DTN 456-1765.

Thanks...

David Finkelstein
Kellogg Project Manager

T.RTitleUserPersonal
Name
DateLines
1652.1Hope we're making money on this projectAIMTEC::WICKS_ABraves Win, Braves Win, Braves Win!Thu Oct 22 1992 22:177
    Tim,
    
    this looks like a continuation of note 1254.
    
    regards,
    
    Andrew.D.Wicks
1652.2Divine Intervention? :-)SCOTTC::MARSHALLFri Oct 23 1992 00:47105
Hi,

>> What can He do to make it work

I don't think even He can help us here :-)

But being serious...

>> if we send a message to SMITH, the directory 
>> selection screen is displayed containing all users with an account name 
>> starting with SMITH

What field terminator do you use after typing SMITH?  FIND, TAB, RETURN, etc?
Do all field terminators give the selection list?
Do you see the selection list if there is a local user (ie profile record for)
SMITH?  Do you see the list if there isn't a profile record for SMITH?
What about if there is a profile record for SMITHxxxxxx?

I expect you've already done all the above, but I just want to be clear about
the results so I know where to look.

>> when ALL-IN-1 pulls accounts out of NETWORK.DAT, they are not in
>> alphabetical order for all systems

They are in alpahabetical order by key.  As the key includes the node, which
is at the "least significant" end of the string, the order will be determined
by the username; the node doesn't matter.

IE: NETWORK records will appear in alphabetical order by name

However, your list has an alphabetical list of SMITHs (items 1 to 6) followed
by a second alphabetical list (items 7 -9).  This means that not all these
records are coming from the NETWORK file.  My guess is that the first six are
profile records (which ALL-IN-1 searches before NETWORK), and the last three
are network records.

>> On the customized system (as described above), if we send a message to
>> SMITH, the directory selection screen is NOT displayed

Again, I need answers to all the questions given above about field
terminators, etc....

>> The first SMITH that would have been displayed on the directory selection
>> screen is placed on the TO: line.  Note that this SMITH is a local user
>> Is it possible that the account was pulled from PROFILE.DAT?

If SMITH is a local user, then it will definitely be pulled from the profile
before NETWORK is even looked at (see comments above about profile records).
Depending on your field terminator, ALL-IN-1 may not even look at NETWORK.

>> If we enter SMITH and GOLD-L, the directory selection screen is not
>> displayed and the second SMITH (from line 7) is placed on the TO: line.

This sounds odd.  More questions:
Is this a different result to performing exactly the same steps on an
uncustomised system, which has identical profile and network file contents to
the customised one?
How do you know you are getting the second SMITH?  I'm not doubting that you
are, I just want to know what ALL-IN-1 does to make you see the difference.
Are you sure that the two SMITHS are different: ie, is the NODE field in the
second SMITH different to the local node?  Is the node in the NETWORK field
different to the local node?  Is it different to the node field in the first
SMITH's NETWORK field?

>> If from another customized system...
>> the directory selection screen is displayed containing (1) and (7) 
>> above since neither of those SMITHs are on the local system

See commenta above about profile records for local users.  Again, what field
terminator was used?  Are you sure the network file on this node contains all
the other SMITH* records?

>> they suggested that I discuss this with someone 
>> who has access to the source code

I have it on the desk in front of me :-)

>> Apparently, having a customized NETWORK or NETWORK$CREATE form, affects the
>> logic path

Not that I can find explicitly.  The only thing that springs to mind is that
if the file was opened via a form in the SITE area, then some customisation
flag gets set which makes things go weird.  But there's nothing apparent,
and it doesn't seem very likely.

At this stage, I think the differences in behaviour are most likely caused
by:
1) Subtle differences between file content between customised and uncustomised
systems
2) Subtle differences in field termination, possibly lost because different
people did testing on different machines and didn't record the field terminators
used, not realising their significance.

I concede that mail address partial recognition is very fragile, and prone to
misunderstanding (I guess that's a bug in itself), but I can't find any more
serious bug to support the odd behaviour described in this note.

If I can get more detailed answers to some of the above questions, I can look
into it in more detail.

>> I'm in the office

So am I, but I think I should go home as it's almost midnight! :-)

Scott
1652.3Let's start all over...GLDOA::FINKELSTEINFri Oct 23 1992 20:5285
Scott, I did some more analysis, so I think it's best that I start from
scratch. 


  1.	On a standard ALL-IN-1 V2.4 system, if I enter SMITHJ terminated
        by RETURN, TAB, or FIND, the selection screen is displayed with all 
	accounts beginning with SMITHJ:

	1 SMITHJ
	2 SMITHJ	.... note: I didn't want to type in the 
	3 SMITHJEFF	.... right half of the selection screen
	4 SMITHJUNE

	There were no local accounts that matched SMITHJ exactly in PROFILE,
	so it displayed everyone beginning with SMITHJ.


  2.	On a customized system, if I enter SMITHJ terminated by RETURN or
	TAB, JEAN SMITH is placed on the TO: line.  This account is local
	to the system, so I'm assuming that it was retrieved from PROFILE.

	If I enter SMITHJ terminated by FIND, the selection screen is 
	displayed with:

	1 SMITHJ AT A1 AT N90BIG
	2 SMITHJEFF AT A1 AT TONY
	3 SMITHJUNE AT A1 AT TONY

	Is this the way it's supposed to be?


  3.	Note that the customized system has AT A1 AT <node> appended to the
	account name, while the standard system does not.  I checked all 3
	customized systems, and 2 standard systems, and AT A1 AT <node> only
	appears on the customized systems.  I checked the contents of the
	NETWORK.DAT files on both the customized and standard systems
	(via <FORM NETWORK) and all addresses were displayed in the form
	<account> AT A1 AT <node>.  I also DUMPed all NETWORK.DAT files, and
	both the customized and standard systems have the network addresses
	in the NETWORK.DAT files in the form <account> AT A1 AT <node>.

	Can you explain this?


  4.	On a customized system, if I enter JONESV, terminated with RETURN
	or TAB, the directory selection screen is not displayed, and
	JONESV AT A1 AT CITVAX is placed on the TO: line.   If I enter
	JONESV, terminated with FIND, the directory selection screen is
	displayed with: 

	1 JONESV AT A1 AT CITVAX
	2 JONESV AT A1 AT N90BIG

	Note: I performed the test from node N92VX2 (in Omaha, Nebraska).
	CITVAX and N90BIG are nodes in Battle Creek, Michigan.  Why did
    	TAB and RETURN display JONESV AT A1 AT CITVAX?


  5.	On a standard system, if I enter JONESV, terminated by RETURN, TAB
	or FIND, the directory selection screen is displayed with:

	1 JONESV
	2 JONESV

	I ran this test from N94VAX (Memphis, Tennessee).


I am definitely getting different results between customized and standard
ALL-IN-1 2.4 systems.  I compared the NETWORK and NETWORK$CREATE forms
between the standard and customized systems, and the only differences were:

  1.	The standard forms are in 80 column mode.  The customized forms
	are in 132 column mode.

  2.	The standard forms define the NETWORK field as 62 characters.
	The customized forms define the NETWORK field as 126 characters.

  3.	The standard form has the field NETWORK in upper case.
	The customized form has the field NETWORK in lower case.
	(Don't tell me this is the reason).
    
    Thanks...
    
    David
    
1652.4Trying to narrow it downSCOTTC::MARSHALLMon Oct 26 1992 09:43152
Hi,

Let's try and eliminate a few things here.  As I said earlier, address
recognition is a weird beast, and some things that look odd are actually
correct (if not perfect :-) behaviour.  So...

>> 1.
>> There were no local accounts that matched SMITHJ exactly in PROFILE,
>> so it displayed everyone beginning with SMITHJ

This is correct behaviour.  If there are no exact matches, ALL-IN-1 gives you
a selection list of partial matches from both profile and network (and other
places too).  In your example, as none of the addresses have "AT A1 AT node"
after the user name, they must have all come from the profile (or be nicknames,
etc, but not from NETWORK).

>> 2. [first half]
>> This account is local
>> to the system, so I'm assuming that it was retrieved from PROFILE

What was in the parentheses after JEAN SMITH?  Was it ( SMITHJ ) or was it
something like ( SMITHJ @ A1 @ node )?  If the former, then the paragraph
below applies.  If the latter, then SMITHJ is not a "local" user.  By which
I mean there is no profile record for SMITHJ: the record was found in NETWORK.

If SMITHJ is a local user, then what you describe is correct behaviour.  Once
ALL-IN-1 finds an exact match, it uses it as the address and stops searching,
even if there may be other exact or partial
matches further on in the search.  One reason for this is that if ALL-IN-1
didn't stop the search, every time you typed a local user, you'd (unnecessarily)
get a select screen with the profile record (eg MARSHALL) and the network record
(eg MARSHALL @ A1 @ IOSG) to choose from.  That would be very irritating!

>> 2. [second half]
>> If I enter SMITHJ terminated by FIND, the selection screen is
>> displayed with:
>> ...
>> Is this the way it's supposed to be?

No.  You should see the *local* SMITHJ (ie the profile record), and *not* the
network one.  This is confusing, and assuming SMITHJ is a local user, looks like
being the root of your problem.  What is the MAIDES of the local SMITHJ?
Is one of the network entries displayed that of the local user SMITHJ?  Is
the NODE in that record the same as OA$PRIMARY_NODE?  What about the node in the
NETWORK field?  Are you using a remote message router?  Is the behaviour
the same if you use the uncustomised network form and file *on that system*?

>> 3.
>> Note that the customized system has AT A1 AT <node> appended to the
>> account name, while the standard system does not

I don't think this is anything to do with customisation, but from where ALL-IN-1
fetches the record.  If the record is found in the profile, ALL-IN-1 just gives
the username.  If the record comes from NETWORK, then the network address (ie
with AT A1 AT node) is appended.  Thus entering SMITHJ on different nodes in
a network will give different results depending on whether you are on the same
node as SMITHJ.

>> I checked all 3 customized systems, and 2 standard systems, and
>> AT A1 AT <node> only appears on the customized systems

See comments above.  As you are doing the tests on different systems, more is
changing than just the customised form, so there could be lots of reasons for
different behaviour.  If you haven't already, try the following tests:

a) Take a customised system.  Perform a series of steps to get a selection list
with "AT A1 AT node" when you don't think it should be there.  Now
OA$CNV_CONVERT (or similar) the customised NETWORK file back to an uncustomised
one, and perform exactly the same set of steps again, on exactly the same
system.  Do you still get the "AT A1 AT node"?

b) The reverse of a.  Start with an uncustomised system, then convert the
network file to your customised format.  See if "AT A1 AT node" magically
appears where it was not before.

The point of these two tests is to see what happens when the network file is
changed in isolation.  A couple of extra points for each test: log in, perform
the test, convert the file, log out (of VMS, don't just exit ALL-IN-1), log in
again for the second part of the test.  This is to make sure that nothing from
the first half of the test affects the second half.  Also, don't do anything in
betweem logging in and performing the test.

>> both the customized and standard systems have the network addresses
>> in the NETWORK.DAT files in the form <account> AT A1 AT <node>

This is correct.

>> 4.
>> On a customized system, if I enter JONESV, terminated with RETURN
>> or TAB, the directory selection screen is not displayed, and
>> JONESV AT A1 AT CITVAX is placed on the TO: line.   If I enter
>> JONESV, terminated with FIND, the directory selection screen is
>> displayed with: 

>> 1 JONESV AT A1 AT CITVAX
>> 2 JONESV AT A1 AT N90BIG

This is correct behaviour.  When you hit RETURN/TAB, ALL-IN-1 found an exact
match, so used that address (for reasons explained above).  When you hit FIND,
ALL-IN-1 gives you all exact and partial matches.

>> On a standard system, if I enter JONESV, terminated by RETURN, TAB
>> or FIND, the directory selection screen is displayed with:

>> 1 JONESV
>> 2 JONESV

>> I ran this test from N94VAX (Memphis, Tennessee)

As explained above, it doesn't surprise me this is different to the first
JONESV test, as it's on a different node.  Unfortunately, as you don't give
the rest of the selection lines, and I don't know from where ALL-IN-1 got the
JONESV records, I can't say why it's different.  For some reason, ALL-IN-1
does not think that either of the JONESV lines displayed are an exact match
for JONESV.  I think if you can find out why that is, youll be nearer to solving
the problem.

>> I am definitely getting different results between customized and standard
>> ALL-IN-1 2.4 systems

Not quite.  From what you've said here, you're getting different results from
different systems, some of which are customised and some of which are not.  It
may be the customisation causing the problem, but it may be something else
entirely.  From your point of view, it would be better if it weren't the
customisation!

>> 1.	The standard forms are in 80 column mode.  The customized forms
>>      are in 132 column mode

This will make no difference.

>>   2.	The standard forms define the NETWORK field as 62 characters.
>>      The customized forms define the NETWORK field as 126 characters

This should not make a difference, and I can think of no way that it would.

>>   3.	The standard form has the field NETWORK in upper case.
>>	The customized form has the field NETWORK in lower case.

I presume you mean the FMS field attribute UPPERCASE.  Our standard form does
not have this attribute.  ALL-IN-1 upper cases all addresses for validation
anyway, so it should not make a difference.  I wonder why your "standard" form
has the field UPPERCASE.  Is this form on a Kellogg site?  As they had an
oddly customised version of the form anyway (which if you remember was the
reason SMNETUPDT didn't work), maybe they'd performed this customisation too?


No magic solution I'm afraid, but I hoped I've helped you eliminate some things,
and given you pointers as to what you should examine next.  Let me know the
results, and we'll see if that brings us any nearer a solution.

Scott