Conference 44.370::system_management

 Sorry, forgot to clarify,

     Steve Green, Ex 2689

>After copying the application startup commands file & modifying it to
>start the environment using DISK$CUR_DATA#, it failed due to not having the
>required privs for shareable logical name table definition.

Do not do the above.
What we have done with AQS on perky is just change the systartup to do an

	@disk$fut_data?:[aqs???]aqs_startup.com

Thus when the machine starts up the logical name tables you require are set up.
The logicals are defined properly as the startup procedures sence where they are
running from.

Three points to note are
1) Change your ???p_disk logical to concealed and then modify your CMS reference
directory to use this logical (replacement fails if you have a ref directory 
otherwise)

2)If you intend to assign to the app environment form the lavcs and main 
clusters remember this will create two sub directories. A little command file
setting directory to the correct area can cure this one.

3)Time difference on the main clusters and lavc causes havoc with cms. I quite 
regularly lock out other members of my team until the clocks catch up. Bring
on the distributed time service for which a request has be lodged.

>After copying the application startup commands file & modifying it to
>start the environment using DISK$CUR_DATA#, it failed due to not having the
>required privs for shareable logical name table definition.

Creating a logical name table does require privileges but so does adding the 
startup command. I think your kindly IS people could do this one.

>Does this impact the memory on the workstations ?

Might do, but I would of thought not.

>What I think we would need is a modified startup.com for each application
>in its environment, which gives the DFS device name etc.

As mentioned above, no change is required

I have been running with the dfs settup for some weeks now with no problems. 
If anybody gets stuck give me a call I might have already had the same problem

Mark

I've also come across another quirk.

I haven't yet found a way of granting myself an application resource identifier
on my workstation account, such that the clusters recognise that as the
correct identifier to allow me access to the application on that cluster.

The identifiers used for application resource identifiers are assigned as
a negative number, and any value explicitly requested in AUTHORIZE must be a
postitive number !

If anyone knows how to get around this, so that I can use DFS to access an 
application from my workstation, I'd appreciate the information...

J.

dfs uses proxy accouts for its protection so identifiers are used  from the 
account you proxy to on the main cluster.

Identifiers cannot be used outside the node/cluster they are defined on so
don't bother trying to assign them on your mc.

Also, do not use the ACL feature within CMS. It doesn't work properly with DFS.

Mark

Slight change to -.1 you need application identifiers granted to your account
on a lavc to enable you to use the logical name table created by the application
startup on the lavc.

But, the numbers do not have to tie up.

Mark

	The LAVC's must have your project identifiers added to their
rightlist.dat files for the application environment startup to work, and the 
logical name tables need to be created by a privileged account at boot
time, so a slight change to LAVC boot procedures is needed.
	Let me know which projects you want to start up where.

	CMS and time differences is a problem.
	I looked at DTSS, a product which purports to synchronise system
times across the network, installed it on NECK, started it up and got an
instant machine crash. I must admit I'm none too keen to try again as I
havn't got the foggiest idea why it behaved like this. So in the meantime
I suggest we try and keep system times reasonably close to each other and
ask IS to adjust them when necessary.
	Of course, we'll all be in a mess on 29th October, but that's a long
standing tradition.