Conference 44.370::system_management

re:- .0
>    So, the ADG hardware configuration will be:
>    
>        -   Development cluster of 3 x VAX 11/785s (running VMS V4.3)
>             to  be  used   for  all  development  work  (including  that
>             currently being done on various production machines),
>             and all personal accounts (for VAXmail, NOTES etc),
>             and UK support (including call handling, SID for UK)
>    
>        -   European Support machine (Vulcan)
>             to be used for all Euro Support work (including SET HOSTing,
>             call handling, SID, testing, etc)
>    

In fact, Euro Support should do their SET HOSTing from their personal 
accounts on the cluster. Sorry about the error.


Tony.

The software to be installed on the development cluster will be as set
out in Ian Hayes' note #18.0.

Any problems?

    -< Possible problems >-
    
    Several applications are currently beging developed using RDB version
    1.1 .  I have recntly been on the RDB support course and apparently
    RDB V2.0 is very different to V1.1. These differences include a
    change in some of the data types used in the system relations! Thus
    converting from V1.1 to V2.0 could become a significant task for
    the larger applications under development. Further to this RDB V2.0
    does n't really work properly regarding ALG withthe NOWAIT transaction.
    This bug is fixed in V2.1 so it would be good to use this version
    if possible. It was due to be released at the end of August but
    some people have it already in field test versions. 
    
    Yours
    P. Platt

    Is there a more detailed plan showing how various accounts are to
    be moved?
    
    My reason for asking is that support have test accounts spread over
    several machines and they are therefore not straight forward backup
    the disk on one machine and restore on another...
    
    This also applies to many other accounts.
    
    Dave Kerrell.

>    Is there a more detailed plan showing how various accounts are to
>    be moved?
    
You'll have to wait for Vicky to return (Monday) for a definite answer 
to this one, Dave. 

Do you mean that you have accounts on separate machines doing the same 
thing, and want them moved to a single account, or that support (in 
general) have accounts on several machines. If the former, you should 
get Vicky a list of the accounts and give her some idea of how you 
want them reconstructed; if the latter, I believe Vicky has covered
the issue.


Tony.

			<<<<  Euro Support >>>>


		Hi , I know that I was away for the SMF last week, but I have
	just read the plans for ADG hardware and I have the following questions:


	o	Why does support get a NON-clustered machine ?

		Most of our VAX based applications are now running on clusters
		out in the field and we can not correctly reproduce the 'live'
		environment with out a cluster !

		We also suffer should our processor crash for what ever reason
		because all our disks are standalone, if our disks were clustered
		then all we would need to do is use a different processor !

	o	Are there any migration plans ? Ie who's responsible and who
		is expected to do the work .

	If I could expand, I think that VULCAN could be use as a specialist
	machine Ie. Geneva are already running OUR applications on VMS V4.4
	and we have no test machine . This could go hand in hand with EURO
	support being based on the main ADG cluster, allowing us the freedom
	also to migrate our applications on to higher versions of the operating
	system with out effecting any one else.

	Anyway I am rattling, so what do you think ??

  <---(.5)--( we have accounts for different applications spread
  over ADGV02, RDGE28 and VULCAN.
  
  Dave.

  <---(.6)--(I think Iain is absolutley right here, we should be
  in the cluster. However instead of excluding VULCAN, cluster
  it as well. We already have a specialist machine in KV3 for VMS
  v3.7, which presumably will not remain on that version for much
  longer, and can subsequently be used for other 'exceptions'.
  
  Dave.

    Tony,
    
    I finally found my way into this thing !!!!!
    
    Please could you or Vicky detail what impact this planned move around has
    on the PDP's if any? Will they be unavailable, or not on the Network
    for any period of time?
    
    Thanks
    
    Carolyn
    

re:- < Note 19.6 by HEWIE::HAYWARD >

>	o	Why does support get a NON-clustered machine ?
>
>		Most of our VAX based applications are now running on clusters
>		out in the field and we can not correctly reproduce the 'live'
>		environment with out a cluster !

Vulcan was considered adequate for the current needs of Support. This
machine is not clusterable. When we can get hold of a bigger machine
for Support, we can look at adding it to the cluster. 


>	o	Are there any migration plans ? Ie who's responsible and who
>		is expected to do the work .

Vicky has drawn up detailed plans and is responsible for the total 
project. She will work with IS Resources and FS people to get the job 
done, no doubt calling on others to help as required.


>	If I could expand, I think that VULCAN could be use as a specialist
>	machine Ie. Geneva are already running OUR applications on VMS V4.4
>	and we have no test machine . This could go hand in hand with EURO
>	support being based on the main ADG cluster, allowing us the freedom
>	also to migrate our applications on to higher versions of the operating
>	system with out effecting any one else.

An interesting idea. In the meantime, if you have a need for a
'special' environment (for whatever reason), have a word with Vicky
and she'll look into assigning one of the microvaxen to build that
environment. 


>	Anyway I am rattling, so what do you think ??

I agree!!! (joke)


Tony.

re:- < Note 19.9 by RDGE28::OASBOPS >
    
>    I finally found my way into this thing !!!!!

Congratulations!

    
>    Please could you or Vicky detail what impact this planned move around has
>    on the PDP's if any? Will they be unavailable, or not on the Network
>    for any period of time?

This will have to wait until Vicky returns on Monday.


Tony.

> Vulcan was considered adequate for the current needs of Support. This
> machine is not clusterable. When we can get hold of a bigger machine
> for Support, we can look at adding it to the cluster. 

Presumably 'adequate' did not include the need for maximum uptime in order
to maintain the quick problem resolution that a cluster would give us, I find
this disappointing ;-(

Why is VULCAN not clusterable? Is it a hardware limitation?

Are they're plans to get support a larger machine, if so when?

Dave.

    Re: VULCAN
    
    The idea was to provide support with a system  for its test systems
    which was isolated from the development environment. In this
    way,there would be no possibility of interaction/side-effects between
    the two environments. VULCAN would in effect provide a 'production'
    environment for support.
    
    At the same time, the sources for the applications will still remain
    on the cluster where they will be accessed by support whenever
    modifications are needed.
    
    In the longer term, I think support should obtain another CPU (probably
    8200) which should be clustered with the 11/750 to provide a clustered
    production environment for test systems while still maintaining sources
    on the main cluster.

    What do you think?                

    Re: .3 -< RDB worries >-
    
    My information about Rdb V2.0 came from the release notes which
    certainly didn't suggest there would be any conversion problems
    once the database itself had been converted.
    
    > Further to this RDB V2.0
    > does n't really work properly regarding ALG withthe NOWAIT transaction.
    > This bug is fixed in V2.1 so it would be good to use this version
    > if possible.    
    
    My knowledge of Rdb is somewhat limited so I cannot answer your point
    specifically with regard to how important that bug really is. However,
    there hasn't been a release of any software yet which is bug-free
    so waiting till V2.1 could only introduce another...ad infinitum!
    
    Maybe Jerry Kew can add more detail - he is somewhat more knowledgable
    on Rdb - Jerry?
                                                                        

re:- < Note 19.12 by ADGV02::KERRELL "Do not disturb" >

> Why is VULCAN not clusterable? Is it a hardware limitation?

Yes, Vulcan requires extra hardware to cluster it. If we get a further
support machine this may be possible (see .13). 

> Are they're plans to get support a larger machine, if so when?

No scheduled plans at the moment but with the imminent arrival of BASE
Reference support, this could change. We'll be working with Paul to
sort this out. 


Tony.

<--(.13)--( The 'isolated test environment' is a good point, especially
as layered products in the development environment move away from the
production enviroment.

So hows about a more flexible environment where we have the bulk of our
test systems on VULCAN but have access to the cluster should the need
arise for a clustered environment?

This would of course require that the cluster never be allowed to reach
capacity :^)


Dave.

re:- < Note 19.16 by ADGV02::KERRELL "Do not disturb" >

> So hows about a more flexible environment where we have the bulk of our
> test systems on VULCAN but have access to the cluster should the need
> arise for a clustered environment?

Good thinking, Dave. I'll look into the possibility of this (or 
something similar) to address Support's need for a cluster test 
environment. We need to further define the requirements and the 
probable  impact but I'll ask Vicky to look at this after she's 
sorted out the re-configuration. 


Tony.

_ refer note 19.2 -

    	Yes, there will be problem. I have a user commitment to meet by using
DEXTRA to do Contract Population extraction from SMART database. The operation
won't be completed for another three/four weeks. Therefore it is important that
DEXTRA should  be installed on a clustered machine in order to continue the 
extraction and to be used for any further development.
    	
- refer note 19.0 -

    	One  thing bothered me is that, why we were not told earlier about the
plan  for  clustering. We  have so much problems the past three weeks trying to
get an agreement to use a VMS V4.3 machine in another group in order to do some 
development work on it. I was told  that the  current  V4 machines could not be 
upgraded to V4.3 because several projects are near completion. What has changed
all that over night ?

    	Is this just another communication problem ?

    	Why couldn't we keep Vulcan to support RDB V1.1 projects ?

Rose Tan.

re:- < Note 19.18 by VULCAN::TAN >

>     	Yes, there will be problem. I have a user commitment to meet by using
> DEXTRA to do Contract Population extraction from SMART database. The operation
> won't be completed for another three/four weeks. Therefore it is important that
> DEXTRA should  be installed on a clustered machine in order to continue the 
> extraction and to be used for any further development.

I don't understand the problem. If you need DEXTRA on the development 
cluster, it will be provided, unless it won't work under the 
environment being set up. Is there a problem?
    	


>     	One  thing bothered me is that, why we were not told earlier about the
> plan  for  clustering. We  have so much problems the past three weeks trying to
> get an agreement to use a VMS V4.3 machine in another group in order to do some 
> development work on it. I was told  that the  current  V4 machines could not be 
> upgraded to V4.3 because several projects are near completion. What has changed
> all that over night ?
>     	Is this just another communication problem ?

The cluster plan was only developed recently, and was only approved 
last week. I'm sorry it caused you problems but I thought it unwise to 
announce the plan before I was sure we could deliver.



>     	Why couldn't we keep Vulcan to support RDB V1.1 projects ?

Vulcan is allocated to European Support as an application test 
machine and has the environment that they require. If you have a 
problem with products that really cannot be converted to Rdb V2 then 
let me or Vicky know and we'll try to work something out.


Tony.

    Tony,
    		Thanks for your prompt reply. I am concerned about DEXTRA
    because it is not listed on the suggested list in note 18. I have
    checked with the DEXTRA implementor and it should be compatible.
    		Regarding retaining Vulcan machine, please refer to
    Pauline Tabrett's mail. She has more information on this subject.
    
    Rose.

re:- < Note 19.20 by VULCAN::TAN >
>    		Thanks for your prompt reply. I am concerned about DEXTRA
>    because it is not listed on the suggested list in note 18. I have
>    checked with the DEXTRA implementor and it should be compatible.

Note 18 only referred to DEC products. I'll see that DEXTRA is 
included, as will any other products used for development (FTSV, 
Tektronix tool, ...).


Tony.

re:- < Note 19.20 by VULCAN::TAN >

>    		Regarding retaining Vulcan machine, please refer to
>    Pauline Tabrett's mail. She has more information on this subject.
    
Rose, I've checked all my (VAX & DEC)mail and have found nothing from 
Pauline. It's either got lost or I've mislaid it; could you ask her to 
resend it? Thanks.


Tony.

    Please put all correspondance about these issues in here.
    
    Let's have no 'behind the scenes' negotiations...
    
    Ian
    

    I have a problem in converting my application, SDPTS, which is live
    using RDB V1.1 to run under RDB V2.0. This application makes extensive
    use of Segmented strings for handling textual information. These
    strings are of a non standard length, namely 132 characters, which
    is perfectly allowable under RDB V1.1. RDB V2.0 however has a bug
    in it which does not allow the creation of segmented strings of
    length other 512 chars. Apparently it can be overcome by editing
    the RDB systems relations, by this is a) tacky and b) highly
    undesirable on a production system. It is also unsupported. Speak
    to Jay Feenan in the Database Products (US) group if you think I'm
    kidding.
    
    I am in the process of finding out if my USer's machine can upgrade
    to RDB V2.0, just supposing I can convert, but obviously this depends
    on what other applications coreside on here. If it can't, what do
    I tell my user, soory chum your support just ran out!
    
    One of the main differencs between RDB V1.1 and V2.0 for the other
    projects to consider is the storage of dates, which I believe used
    to be stored as a quad word and in RDB V2.0 the data type has become
    a record format! (very upward compatible) See RDB notes file for
    more info). Anyway this means that all date routines will have to
    be rewritten. So you can see it's not just a simple case of bacjkup
    and restore.
    
    Anyway, hope this has elaborated on some of the problems, some of
    us down here will be encountering.
    
    Debbie
    

-< RE. note 19.23 >-

This is a copy of the text Pauline sent to Tony and Vicky.


	The cluster configuration proposed for the 30/31 August , although
welcome , does not include any plans for supporting the RDB 1.1 applications
currently in support and development.To my knowledge there are 4 systems
in the UK which will need to be converted to RDB 2 if they are to be resident
on the cluster namely:-

			Application	Disk Space	Developers

			SDPTS		53,000		( support )	
			SPID  		80,000		     2
			CPS		100,000		     3
			DLME		130,000		     2

	Thus we will require continuing access to a machine for conversion of 
these systems.With this number of systems , amount of disk space and developers
it does not seem possible or desirable to utilize the microvaxes.
	It would be preferable to retain VULCAN until a planned conversion
schedule can be put into place.I hope you will be able to inform me of suitable
contingency plans so that we may continue our support and make plans for a 
timely and convenient conversion schedule.
	From this Friday 22nd August I will be on holiday sa can you contact
Annettte Oneill.

re:- < Note 19.24 by VULCAN::DSMITH >
re:- < Note 19.25 by VULCAN::PLATT >

The only solution I can come up with is as follows:

    The four applications  would be (RDO) backed up and then installed
    on the cluster where Rdb V2 would be running. 
    
    The KV1 11/730 (ADGV01)  would have  Rdb  V2  removed and Rdb V1.1
    installed together with the four  applications  from  VULCAN.  The
    Training  Admin  System  being developed on KV1 would move to  the
    cluster.
    
The  cluster versions should  become  the  new  development  accounts.
Obviously the 730 would not  take 7 people doing development with Rdb,
so all applications should only use the 730 if they encounter problems
which cannot be resolved on the cluster.    Effectively,  the  730  is
strictly a contingency machine.

I understand that this will impact the four  projects  but  KV1 is the
only machine which can be diverted.

KV1 will  revert  to  the  Services  machine  and  will  have  Rdb  V2
re-installed around the end of September, unless someone has very good
reasons for keeping it longer.

Is this a suitable compromise?


Tony.

    Appart from the Known bugs in Rdb v2.0 (segemented strings etc)
    we have had no problems running it on the EUC cluster. This is
    a twin 785 environment running V4.3.
    
    Just thought I'd give some feedback.
    
    PS We are going VMS 4.5 and Rdb 2.2 in October so we will keep you
       informed of any problems.
    
    Chris...

This memo  will  (hopefully) explain the impact of the changes in the
configuration of ADG  hardware  on the European Support group and the
way it works.   The  memo will be issued directly to Support and also
posted in the SYSTEM_MANAGEMENT notes conference.


European Support Group - Proposed H/w Use
-----------------------------------------

Several members  of the European Support group have expressed concern
about the impact  of  the forthcoming re-configuration on their work.
This was probably my  fault  for not explaining how support will work
in the  future in more detail.  As a result of the concerns expressed
a meeting was held with support reps, the consultants who helped draw
up the plan, Vicky and myself.  This clarifying memo is the result.

First I'd like to make  it  clear  that  support  are not expected to
conduct  all  their  activities from Vulcan.    Vulcan  will  provide
support  with  a  NEW  (but  frequently  requested)  facility  -    a
stand-alone  test  machine  which  is  completely  separate  from the
environment in  which  an  application  was  developed.

This  is  IN  ADDITION to the normal facilities provided:    personal
accounts,  the  ability to SET HOST to remote machines, accounts  for
maintaining  source  code;    ALL  of which will be done on/from  the
cluster.  Since it was considered that the  load  on Vulcan would not
be too heavy, the call handling and SID facilities  will  also be run
from Vulcan.

The  contingency  for  Vulcan  being down for a long period  is  that
application  testing  will be conducted from the cluster (either from
within the development  accounts, or by loading the test account from
tape).

The load on all  machines will be continuously monitored and if there
are any problems, we will act to resolve them.

I hope this clears  things  up.    The picture (with more explanatory
words) is attached.    Again, if there are still questions, post them
in the SYSTEM_MANAGEMENT notes conference.



The ADG hardware configuration will be:

    -   Development cluster of 3 x VAX 11/785s (running VMS V4.3)
         to  be  used  for all development type work (including  that
         currently being done on various production machines),
         and all personal accounts (for VAXmail, NOTES etc),
         and UK support (including call handling, SID for UK),
         and Euro Support (source maintenance, SET HOSTing)

    -   European Support application test machine (Vulcan)
         to be used for all Euro Support application testing together
         with call handling & SID

    -   ADGV01 will be admin support machine  (after  end  September,
         before which it will be used to back up Rdb V1.1 projects in
         UK Dev group)

    -   ADGV02 will be VMS V3.7 development and support machine

    -   Compact VAX will be used as installation test machine

    -   all  MicroVAXen will be used as 'specialist' development  and
         support  machines  (ie, cannot use cluster or Vulcan), their
         use to be assigned by the system manager as required



                                HARDWARE PLAN 1
                                _______________



Development & Support Cluster:



 --------------          --------------          -------------- 
|              |        |              |        |              |
| VAX 11/785   |~~~~~~~~| VAX 11/785   |~~~~~~~~| VAX 11/785   |
|     U9       |~~~~~~~~|     U28      |~~~~~~~~|     U?       |
|    16 MB     |        |    16 MB     |        |    12 MB     |
 --------------          --------------          --------------
      |                         |                       |
      |                         |                       |
       \                        |                      /
        \                       |                     /
         -----------------------|---------------------
                                |
                              ____
                             | SC |
                              ----
                               /\
                              /  \
                             /    \
                   ---------       ---------
                   |                       |
                   |                       |
               ----------               ----------
              |  HSC50   |             |  HSC50   |
               ----------               ----------
                   |                       |
                   |                       |
                   |                       |
    --------------------------------------------------------------------------------------------
   |              |                           |                           |         |          |
   |          ----------           -----------------------------          |         |          |
   |         |          |         |        |         |         |          |         |          |
 ------   ------     ------     ------   ------    ------    ------     ------     ------     ------ 
/ RA81 \ / RA81 \   / RA81 \   / RA81 \ / RA81 \  / RA81 \  / RA81 \   / RA81 \   / RA60 \   / RA81 \
|      | |      |   |      |   |      | |      |  |      |  |      |   | LCL  |   | VOL  |   |      |
| SYS  | | USER |   | USER |   | APPL | | APPL |  | APPL |  | APPL |   | SUP  |   | TEST |   |      |
\      / \      /   \      /   \      / \      /  \      /  \      /   \      /   \      /   \      /
 ------   ------     ------     ------   ------    ------    ------     ------     ------     ------ 
            <- BOUND ->            <--------BOUND------------->


















European Support Application Test (& CH & SID) Machine:

                 -------------- 
                |              |
                | VAX 11/750   |
                |  VULCAN      |
                |    6 MB      |
                 -------------- 
                       |
                       |
                       |
              ---------------------
              |         |         |
            ------    ------    ------
           / RA60 \  / RA81 \  / RA81 \
           |      |  |      |  |      |
           | SYS  |  | APPL/|  | APPL |
           \      /  \ CH.../  \      /
            ------    ------    ------


ADGV02 Development and Support for Version 3.7 Projects:

                 -------------- 
                |              |
                | VAX 11/730   |
                |    KV3       |
                 -------------- 


ADGV01 Administration Functions (Rdb V1.1 backup until end-Sept)

                 -------------- 
                |              |
                | VAX 11/730   |
                |    KV1       |
                 -------------- 


FOOT Application installation Testing

                 -------------- 
                |  Compact     |
                | VAX 11/730   |
                |   FOOT       |
                 -------------- 


For sometime now VULCAn has had an incomplete and out-of-date DECnet
database, will this be rectified when VULCAn comes up as a support
engine?

Dave.

    Once all the support work is on VULCAN I can arrange it so the
    complete network database is on it and is regularily updated OR if
    someone from support can let me know which nodes are required I
    can put all these into the volatile database and update them regularily
                                 
    Vicky

    The short answer is yes however it is not important. VULCAN should
    not be used for set-hosting 'cos if everyone does that the poor
    old 11/750 will sink!
    
    Set hosting should be done from personal accounts on the cluster,
    VULCAN is purely intended for test systems, call handling and SID.
    
    Ian.

    When I start to swap all the files around I will endevour to make
    sure everyone has all their own directories and files in the correct
    place BUT it would be WONDERFUL if people could tidy up their own
    directories and accounts and have all files etc on one machine ie
    if you have an account on U9 and U28 copy everything to U28 and
    empty the U9 directories.
    
    Everything will be backed up so if things seem to be missing next
    week I will be able to restore from tape.
    
    
    Any help will be appreciated 
    
    Love
    
    Vicky
    

Re. DECnet database on VULCAN.

>    The short answer is yes however it is not important. VULCAN should
>    not be used for set-hosting 'cos if everyone does that the poor
>    old 11/750 will sink!
    
Yes, but what about copying files from live systems over the net to run here
on the test machine? If we rely on the cluster we will be copying across
Europe and then again locally, increasing both the overall load and the time
it takes.

Dave.

    The move this weekend to cluster our machines should not having
    any affect on the PDP's or the Network.
    
    Regards
    Vicky
    

re:- < Note 19.26 by RDGE28::TLINDE >
                            -< Rdb V1.1 compromise >-

>KV1 will  revert  to  the  Services  machine  and  will  have  Rdb  V2
>re-installed around the end of September, unless someone has very good
>reasons for keeping it longer.

I'd like  to restate the above.  The plan is for KV1 to be reconverted
around the end of September.  If, however, the systems being supported
are still running under Rdb  V1.1,  then  I consider that to be a good
reason for keeping KV1 for supporting them.   I  provided the end-Sept
date as a goal for people to work towards.

I've spoken to Kim and he has agreed that next week he will provide me
with dates for when UK  group  can  convert the Rdb V1.1 applications.
Vicky and  I will then ensure that IS Resources convert the production
machines in line with UK plans.

And good luck to all!


Tony.

    Re .33
    >    Yes, but what about copying files from live systems over the net
    >    to run here on the test machine?
    
    Fair comment, but I *did* say Yes!