Conference iosg::all-in-1_v30

    You could use your workround of changing the VMS account names to
    Pnnnnn, both in the UAF and profile, and allow people to enter ALL-IN-1
    with allin1/u=Name. This can be achieved either by adding a symbol to
    LOGIN.COM, or by defining the symbol from a program executed in
    SYLOGIN, or by some other means.
    
    I think the VMS "restriction" is because it's imposssible to tell if an
    identifer with a numeric name is in the numeric form or the named form.
    
    I'll be interested to see what VMS say.
    
    Graham

    
    
    Hi Graham,
    
    You 're right.
    
    			VMS Point of View
    
    From the VMS Notesfile I understand VMS Username and Identifier 
    Name Spaces are different.
    
    VMS Usernames are limited to 12 characters in length or shorter.
    VMS Identifiers can be 31 characters in length but not 100% 
    numeric.
    
    VMS currently doesn't allow 100% numeric identifiers because of 
    it's parsing mechanism of UIC's to determine the difference 
    between Numeric UIC codes [333,111] and identifiers 
    [ALLIN1, GRAHAM] and the confusion which arises when you are 
    allowed to specify e.g. a numeric identifier which matches a 
    numeric UIC member number.
    
    			Customer Situation Revisited
    
    The customers I talk to want ONE thing :
    
    *************************************************************
    ALL-IN-1 supporting the combination of DIFFERENT VMS Username
    UIC Identifier pairs.
    *************************************************************
    
    So, ALL-IN-1 NOT relying on the VMS Default scheme (VMS    
    Username being the same as VMS UIC Identifier name.
    
    This will minimize impact on their current environment :
    
    - Multivendor naming scheme
      - For example SFB customer can use Numeric VMS Usernames with
        P12345 UIC Identifier names. 
      - User login on OpenVMS systems and UNISYS mainframes stays the
        same and is consistent
    
    - No impact on Accounting & Security packages & Application   
      specific authorization mechanisms currently being used
    
                    ALL-IN-1 (Migration) Point of View
    
    From a product point of view, it's my opinion that ALL-IN-1 should 
    adhere to the VMS Security Mechanism.
    This means ALL-IN-1 IOS must allow different pairs of VMS 
    Usernames; VMS UIC Identifiers !!!!
    
    - Customers moving from ALL-IN-1 V2.4 to ALL-IN-1 V3.0 should NOT 
      be bothered by a product restriction like this. The impact on 
      their current systems is too high.
    
    - ALL-IN-1 IOS and OpenVMS are both very important Digital 
      products.
      These products must be technically in synch. 
    
    			Proposed Solution
    
    Change ALL-IN-1 IOS so that VMS Usernames and VMS UIC Identifiers 
    can be different for a specific user :
    
    - ALL-IN-1 IOS has the internal funtions and DSABs in place to
      cope with this situation
    - Product impact will be in the area of :
      . Disk Quota checking (use UIC Identifier with attrib Resource 
        set)
      . Creation, Modification, Deletion of ALL-IN-1 User accounts
      . File protection (File Cabinet Server)
      . ...
    
    
    			Who can do the fix ?
    
    
    Graham, can you comment on this ?
    
    I understand that Engineering has been aware of the ALL-IN-1 
    restriction mentioned for a while. 
    
    I have done some investigation which shows others have mentioned 
    this restriction before, which resulted in "fingerpointing" 
    between VMS and ALL-IN-1 Engineering.
    
    Until now it resulted in Impact on the Customer sites, that was 
    not received very positively and in some cases even led to 
    customers -- who already thought of leaving ALL-IN-1 -- becoming 
    frustrated... Dangereous, especially during these days...
    
    I'm very in favor of the ALL-IN-1 and TeamLinks concept in the 
    Client-Server space and one of it's promotors. Customers are also 
    very enthousiastic and we should keep them that way by responding 
    in the right way to their problems.
    Customer satisfaction, especially at our large ALL-IN-1 IOS sites 
    is our lifeline. A smooth move to ALL-IN-1 V3.x (combined with 
    TeamLinks) is a must to protect our installed base from the 
    competition.
    
    This is why I would like to see the customer impact to be ZERO 
    regarding this Identifier issue.
    
    Comments are welcome !
    
    Regards,
    
    Martin van Steenis
    DTN 838-832120
    
    
    
    
     
    
    
    
    
    

    Personally speaking I have never encountered this type of problem on a
    customer site before.  Perhaps the problem is quite limited -- to a
    certain group of customers that have "other" computing systems in situ
    along with OpenVMS/ALL-IN-1?   I think that the same discussion might
    have happened in the past with PROFS/DISOSS (8 character account
    names), but can't be sure.  It would be good, however, to get a sense
    of whether this kind of thing is causing lots of problems in the
    installed base or just in a few accounts.  What do others think?
    
    Tony

    RE .2
    
    Yes, Engineering know that having the identifier present is
    pre-requisite for operation of V3.0. However, as Tony says, in the
    absence of a large volume of objections, it may stay that way.
    
    Graham

Tony,

re: .3

Glad SOMEONE is listening!  I entered similar queries in note 2001 and 
VMSNOTES conference note 3087.  You will see the overwhelming response I 
received.  I guess Martin (.0) has the right touch!

Our customer site was forced to change their VMS usernames just over a week 
ago in preparation for the 3.0 upgrade.  Total number of affected users at 
our customer site, including 3 ALL-IN-1 systems is approx. 6000 users.  We
use employee numbers as VMS usernames and do not have any affiliation with
PROFS.  Although we tried to minimize user impact via education, one of the
managers (who signs my contract) at the customer site was less than
"pleased" with the change: 

>Subject: RE: LOGIN CHANGE!
> 
>Thank you for the explanation.
>
>I am sure that the change was not taken lightly.  Please consider how our
>customers are going to react.  They are not going to see any value added, they
>are going to see a change, and now the login is not uniform for machines on
>the network.  I believe this will be seen as another reason why we should get
>off of All-In-One!!  

His quote, not mine.

Hope it's not too late for *other* sites!  FWIW - I'll be happy to submit 
an SPR.

Randy Bailey
LSO
Los Alamos National Labs, New Mexico, USA

p.s.  Tony - glad to see your involvement with TeamLinks!!!

    Hi Randy,
    
    Change causes pain.  That's a generality, but unfortunately it's true.
    Up to now ALL-IN-1 hasn't really paid too much attention to how account
    names are formed and used, except for the small problems that have been
    encountered in the past with accounts that include commas (as
    separators), or the issues around local language characters.
    
    ALL-IN-1 V3.0 introduces a big change. That is, the change to use the
    VMS security model (identifiers, ACLs, and the like) in order to create
    an environment within which it is possible to be secure while sharing
    information between local, remote, and PC users.  No-one expects to
    make a change like this without breaking some eggs, and I think we are
    seeing some eggs getting broken here.  But, in defence of the
    engineers, I think that relatively few eggs have been broken (so far)
    and they have reacted well to issues as they have come up.  For
    example, the provision of the SM$UIC$ALLOCATION data set in 3.0-1 goes
    some of the way to fixing problems with reused UICs.
    
    Looking back it seems to me that we've all been a little lax in many
    ways around account names, identifiers, and the like.  I know I have.
    As systems become more diverse, network aware, and shareable the need
    to have a backbone structure that can be trusted becomes more evident.
    That's where we're at now.
    
    Just some observations on the subject. 
    
    Tony
    
    PS. Who's involved with TeamLinks?  It makes me sound as if I've
    divorced ALL-IN-1 and have taken up with TeamLinks, possibly lured on
    by the fancier front end.  What's next?  An affaire de coeur with
    OBJECTworks?

    
    	I got beaten up at DECUS by two customers with problems with this
    	V3.0 restriction. One customer had built up an application
    	around his use of identifiers and accounting and V3.0 would
    	break it all. The other used employee numbers for the accounts
    	and didn't like having to share drawers with a number (my glib
    	response was something like "Well if you'd have used meaningful
    	names", but I wasn't really serious).
    
    Regards,
    Paul

    Martin.
    
    1. Source code -- no way!  You know yourself (deep down) that making
    changes to source code results in a version of ALL-IN-1 that:
    
    a) You have to support, because the normal support channels won't
    b) You'll have to upgrade each time a new major or minor release
       of ALL-IN-1 is issued
    
    Anyway, what gives you the confidence that the problem can be fixed if
    you had the source code in your hand?  And how long would it take?  And
    how would you establish (test plan, regression testing, etc.) that the
    changes you made wouldn't affect anything else in ALL-IN-1.  Or affect
    anything in a customized system, or in a third party application?
    
    I don't want to offend you by saying that you couldn't work through
    these issues, just illustrate the point that having source code is not a
    universal panacea!
    
    2. Multivendor environment.  How many sites run ALL-IN-1 and UNISYS
    (old mainframe presumably, their new stuff tends to be UNIX based?)
    together?  
    
    3. Investigating the installed base.  How could this be done?  Across
    20,000 installations?  If the problem was that serious wouldn't
    engineering have seen a number of CLDs already?  Just asking...
    
    Clearly a problem exists.  But it seems also, in the context of the
    overall installed base, it's not a very serious problem.  It is, of
    course, serious in the eyes of the customers that are affected as well
    as the local office that has to deal with the customer.  Before anyone
    rushes into doing anything I think it's worthwhile to have some more
    discussion here to gauge the exact extent of the problem (in the
    overall customer base).  If a real problem does exist then the correct
    way to get it resolved is to work though the product manager (to make
    sure that it's fixed in a future release) or the support network (to
    see if engineering can resolve things in a patch).
    
    ALL-IN-1, like many other products, has lots of demands on it for time,
    functionality, problems to be fixed, or things to work a little
    differently.  There's only so much that can be done by engineering. 
    
    
    Tony

    
    
    Hi Tony,
    
    1. 	SCOPE
    
    	The first point I want to make is the fact that introducing 
    	ALL-IN-1 V3.0 at TWO of the three large customers in the 
    	Social Insurance marketplace in Holland experience this
    	identifier problem !
    
    	Is this a coincidence ?
    
    	With this in mind my FIRST step is investigation of the extent
    	of this problem in our installed base using Notes.
    	As you can read from fellow ALL-IN-1 collegues in the field,
    	it's a NASTY problem resulting in LOTS OF WORKS for the 
    	CUSTOMERS involved.
    	CUSTOMER SATISFACTION IS HERE AT STAKE !
    
    	The SECOND step will be to escalate this problem to Product 
    	Management if it is a real problem at MORE customer sites
    	and EFFORTS will prevent CUSTOMERS from LEAVING ALL-IN-1
    	and POSSIBLY TeamLinks.
    
    	Yes, investigation in our installed base is a problem i.e.
    	not possible. But using but my concern is that complex 
    	situations (like more engineering groups being involved etc.)
    	are often difficulty to solve within Digital, take up a lot
    	of internal effort etc. to get things done ! This causes
    	problems not being reported and customers being DISSATISFIED
    	because we as Digital are NOT CAPABLE of ADDRESSING these
    	problems correctly.
    
    	My point is, EVERY PROBLEM will be seen as MINOR if only a 
    	selection of our installed base experiences it. But for
    	these customers it's a real PROBLEM.
    
    	Ok, enough.
    
    2.	Source code
    
    	In the case of SFB a possible workaround is using a different 
    	VMS Username within ALL-IN-1 PROFILE from the one stored in 
    	UAF.
    
    	This gives VMS UIC Identifier "P12345", PROFILE VMS Username
    	"P12345" and UAF VMS Username "12345".
    
    	This only works if ALL-IN-1 IOS doesn't access the VMS 	User 
    	Authorization File directly or accesses the Process Memory
    	Context.
    
    	However, ALL-IN-1 prevents a user from logging on when
    	the hardcoded check at startup determines a difference in
    	UAF VMS Username and ALL-IN-1 PROFILE VMS Username.
    
    	This check is done in SOURCE CODE.
    
    	This means that a very SMALL part of ALL-IN-1 Initializatiopn 
    	Code has to be changed to enable the workaround.
    	I'm not saying that I want to rewrite ALL-IN-1 code !!!
    	I just want to make sure that a solution can be provided
    	at local level, even if a minor change has to be made to
    	a small part of ALL-IN-1 source code.
    
    	If necessary I can work this out with Simon and our local 
    	support organisation and you or Engineering.
    
    	I'M NOT MERELY SAYING THAT SOURCE CODING SOLVES ALL PROBLEMS 
    	!!!!
    
    	
    
    3. 	Multi Vendor Environment
    	
    	As you can read in this Notesfile for yourself, I'm not the 
    	only one with customers in MVE's that experience this problem.
    	Consistant Login Naming is a requirement.
    
    	Yes, lots of customers are thinking of downsizing their 
    	mainframes. Both GAK and SFB do too !!!
    	This doesn't mean this will happen overnight however !!!!!!
    
    	So the customer requirenment is an ABSOLUTE VALID one !!
    
    4.  Action plan
    
    	- I'll discuss the info I have until now internally
    	- We'll investigate the impact of providing a 
    	  workaround (if no support from Engineering we will
    	  have to escalate, but I'm sure we cab work something out)
    	- We'll look at the supportability of the (future) proposed
    	  workaround
    	- We'll talk to both customers involved
    
    Regards,
    
    Martin
     
    	

re.9

>    a) You have to support, because the normal support channels won't

We do have a Application Maintainance Unit for non-standard Software
Application Support. They work closely with us CSC. This will however
require a special support contact....

Regards,

Jan

    Martin,
    
    Maybe the same people worked on the implementation of two of the three
    largest customers in Holland?  Hence the same problem in the sites?
    
    Anyway, it's not me that you have to convince.  You have to convince a
    product manager and the rest of engineering that things need to change.
    As I said, I don't see a lot of other notes clamouring for change, but
    maybe I'm not reading notes correctly ;-)
    
    Or maybe I need to start using the CAPITALS LOCK key to get my point
    across?
    
    Lovingly, T

The final story :

After having gathered all the information regarding this IDENTIFIER story :

- ALL-IN-1 Point of View
  Low priority. Not a lot of (known) sites being impacted etc..
- VMS Point of View
  Different name spaces VMS Usernames and VMS Identifiers, problems you
  would run into if you define Numeric Identifiers which reflect numeric
  UIC numbers (group, member) etc.
- Customer impact (talking to System Management and Office specialists
  within the customer organization)

I visited the customer and spoke to the senior IS manager and two of his
Office specialists.

After carefully reviewing the impact on their system (more than 100 
application autorization files..., accounting package, 1500 ALL-IN-1 Users) 
and discussing alternative "workarounds" (dummy account "P12345" for each
user, code changes etc.), I managed to convince the customer to change their 
VMS Usernames from "12345" format to "P12345" format.
They agreed to go for the default ALL-IN-1 conventions to prevent problems 
now and in the future.

Their steps will be the following :
- Implement the new VMS Usernames and change Application Authorization
  files.
- Implement ALL-IN-1 V3.0 for their three ALL-IN-1 systems
- Start using TeamLinks for the IS department
- Implement TeamLinks for users end CY93

They are very happy with our ALL-IN-1/TeamLinks strategy and are willingly 
to go forward !

Regards,

Martin

P.S.
Thanks for the input !


They will make these changes part