DSXchange

We need to be able to put DataStage in a restricted mode when we perform upgrades and/or import/exports. This will lock all users out except for the "admin" user.

1stpoint wrote:We need to be able to put DataStage in a restricted mode when we perform upgrades and/or import/exports. This will lock all users out except for the "admin" user.

Please contact me directly to give me more detail on this requirement. I am especially interested in the workflow around this.

Cheers

Steve

This is closely related to the inability of Datastage to have 'read-only' access to jobs. Its very annoying when you try to open a job, get the annoying message 'locked by another user' and then you have to wait a minute for the control to be returned to your screen. Read-only of locked jobs would be very useful. Assuming you can make jobs read-only you could then go on to allow admin to lock jobs this way as in the enhancement required above.

Its very annoying when you try to open a job, get the annoying message 'locked by another user'

agreed.

1stpoint, you'll need to get the developers off the jobs when you want to export/import, and i believe the only way is to ask them to get off the server jobs (ok, perhaps not the only way).

a possible way to go around implementing the restricted mode is have the administrator restrict the permissions of the group of developers to <none> for the particular project in DS administrator. I dont know what will happen should this change occur while they are developing (perhaps this is not a good time to do the change!), but will definitely prohibit them from going into the project once attempting to reconnect. This will give you time to do the import/export.

you should propose downtime if this is a recurring event, communicate it to the developers and have them agree that it is the best way forward.

1stpoint, you'll need to get the developers off the jobs when you want to export/import, and i believe the only way is to ask them to get off the server jobs (ok, perhaps not the only way).

That is not exactly what I am requesting. What I would like to see is a lockout capability so that we can perform an upgrade and lockout the developers until we decide the environment is ready.

You should manage this via user groups. Let Unix level admin persons take a group out of access, because as DataStage has ZERO functionality in this regard. The closest you have is to use Admin and revoke all of the groups with access. Then, you have to go back and add them again when you're finished.

That admitted, I think what 1stpoint is seeking is something like Prime INFORMATION's MAXUSERS command, where an administrator can limit the maximum number of logins to a particular number, including zero.

This was never implemented in UniVerse (for reasons never satisfactorily explained). Some UniVerse administrators implemented it themselves, by replacing the uv command with a uv shell script that was earlier in everyone's command search path, thereby providing whatever functionality was required before (maybe) invoking the real uv command.

Renaming the true uv and placing the uv shell script in the UV account's bin directory was sufficient to thwart those who elected to invoke the command using its full pathname.

Ray

Why couldn't you do this in UV.LOGIN in the UV account?

Because uvcs processes bypass UV.LOGIN afaik. Plus, you don't really want to have to get into the UV environment only to be kicked out; far better to prevent getting in at all.

You could, of course, simply stop or pause the RPC daemon; it would have a similar effect, but prevent your using the Administrator client.

You should manage this via user groups. Let Unix level admin persons take a group out of access, because as DataStage has ZERO functionality in this regard. The closest you have is to use Admin and revoke all of the groups with access. Then, you have to go back and add them again when you're finished.

This is a nice solution for, say Unix/Linux. How about a platform-independent solution?

DSXchange commandment #7:

Thou shalt fill out all of the fields when posting a question, so that responders can give specific answers to thine own platforms.

Since most DS installs are on Unix, I gave you a reasonable response. You can handle access via the DS Administrator route as I suggested for Windoze.

Except for the word Unix, Ken's "solution" is platform-independent.