Read only Environments

[Mark_E]

I am a new starter to Datastage.

The company I have recently joined are using Datastage v6. We have a requirement to make one of our "environments" to be read only. This environment is a datastage Project - which we term Production. We also have another environment termed Development.

To move jobs from Development to Production we use the Import Export facility in Datastage Manager. As far as I am aware we do not use Version Control.

My question is: is there any way that we can make the Production Project Read only - so that no jobs could be changed within this environment? If not what would be a recommended way to achieve such a goal.

I hope someone can help

cheers
Mark

[chulett]

I believe the only way to make a job Read Only is from under the covers and not something for the Faint of Heart or those without the secret Universe/DSEngine decoder ring.

The recommened option is to stop doing Export/Import from the Manager and start using Version Control. One of the many benefits it brings to the table is the ability to make your Production jobs (and Test too!) read only as part of the promotion.

[kduke]

Mark

It is not really that hard. You can use normal SQL against these hash files. The main file is DS_JOBOBJECTS which holds all the job designs. This topic viewtopic.php?t=85050 talks about it.

[chulett]

Are you sure that's still the case, Kim? I've had instructions on how to do this that worked just fine up until Version 6, when it seemed to become a wee bit harder to manage. Support wouldn't help me out and tell me how it had changed. Haven't even bothered to try to figure it out with 7.

I've tried to Search for information on seeting the READONLY column to RO or NRO (including the post you linked to) and could only find references to the need to do it, not the how to do it.

[kduke]

Craig

I think it should work in version 6 or 7. Not much protection though. A simple UPDATE will change it. Have not tried it. I wonder if Kevin or Byron will look it up in VC.

[kcbland]

Wow. Your production and development exists within the same server? Didn't anyone find this to be a problem? That's like saying my production database and development database co-exist on the same server. Except in DataStage's case it's worse because only a single version can be installed and executing.

Your problem is that your company has not segmented production environments from development environments. Ideally, you're talking about separate networks and servers. All the eggs are in one basket. Development job execution will steal resources from production job execution. Development work will impact production work, as you'll be sharing so much resources (cpu, disk, memory, etc).

The way to lock-down a project is done via user groups and access granted thru the DS Administrator. Unfortunately, you'll have to setup different users and groups to have access to each project. There's no security allowances like what you require. It's usually solved by having production as a totally separate server, with userids, and procedures in place to deal with your security issue.

[chulett]

Wow. Your production and development exists within the same server? Didn't anyone find this to be a problem?

Nobody else made this inference. The OP simply stated they have two Projects and do Import/Export from the Manager - which doesn't imply anything about the number of servers involved. (unless you can infer this from their OS, perhaps? All of my experience is on UNIX servers, so maybe I'm missing something here) Now, you could very well be correct, I'll give you that - we'll just have to wait and see when Mark comes back.

In the meantime, we were simply trying to answer the question that was asked. We would have gotten around to Best Practices eventually.

[kcbland]

This environment is a datastage Project - which we term Production. We also have another environment termed Development.

Hmmm. Environment sounds synonymous with project in the posters world. Access to servers is handled via userids and passwords, not a problem to lock down a server that way as some companies never give access to all developers in the production evironment. Maybe a stretch on my part, maybe it's my American public education. Just wanted to run it up the flagpole, because I've had this discussion soooo many times.

In the production server environment, you're best option is to use a system account (userid) for your job processes instead of developer accounts. In that case, don't hand out the userid and password, or, setup developers as operators only. Imports and compiles are handled purely under the system account (good practice by the way, let's you tighten umask in prod to just 077 or 007 but leave it wide open in dev). When prod and dev share the same DS server, it's one umask setting for all jobs.

[Mark_E]

This environment is a datastage Project - which we term Production. We also have another environment termed Development.

Hmmm. Environment sounds synonymous with project in the posters world. Access to servers is handled via userids and passwords, not a problem to lock down a server that way as some companies never give access to all developers in the production evironment. Maybe a stretch on my part, maybe it's my American public education. Just wanted to run it up the flagpole, because I've had this discussion soooo many times.
.

Thank you for all your comments, there is quite a lot to digest and think about.

Yes Environment is synonymous with Project - and both "Environments" are on the same server which has meant that we have had to contend with some of the performance issues as mentioned.

We are loath to set up new passwords and user accounts as that could lead to 'messy' issues, but it is something that we will look into. Another option would be for us to Adopt Version Control- if not would the packeger be an alternative ?

I liked the suggestion of changeing the READONLY column in the DS_OBJECTS table to RO/NRO but the thread did not really offer any ideas on how to carry this out.

[ray.wurlod]

From Administrator client Command window or in a telnet session in the DataStage environment in your project, execute the following commands. Commands are case sensitive; you need all upper case as shown.

Job designs

Code: Select all

UPDATE DS_JOBOBJECTS SET READONLY = 'RO' WHERE READONLY = 'NRO';

Routines

Code: Select all

UPDATE DS_ROUTINES SET READONLY = 'RO' WHERE READONLY = 'NRO';

Transforms

Code: Select all

UPDATE DS_TRANSFORMS SET READONLY = 'RO' WHERE READONLY = 'NRO';

Data Elements

Code: Select all

UPDATE DS_DATATYPES SET READONLY = 'RO' WHERE READONLY = 'NRO';

Table Definitions

Code: Select all

UPDATE DS_METADATA SET READONLY = 'RO' WHERE READONLY = 'NRO';

Shared Containers

Code: Select all

UPDATE DS_CONTAINERS SET READONLY = 'RO' WHERE READONLY = 'NRO';

[chulett]

Yes Environment is synonymous with Project - and both "Environments" are on the same server which has meant that we have had to contend with some of the performance issues as mentioned.

Yikes! Not only do you have the problem of mixing Production and Development on one server, you also seem to be missing a Test 'Environment'. You need someplace where testing can be done without impacting either Production or ongoing Development. Doesn't necessarily need to be another server but it should at least be another Project.

I liked the suggestion of changeing the READONLY column in the DS_OBJECTS table to RO/NRO but the thread did not really offer any ideas on how to carry this out.

To me this sounds like a total PITA. A combination of export/import (or the Packager) and having to remember to flip RO flags on everything sounds unwieldy and error prone. This is all built into Version Control, plus it gives you things like... well... version control. No flag flipping, no package installs, it will find 'dependant objects' for you if you are not sure what needs to go up, you can fall back to older versions if the current version has 'issues', source is available for viewing outside of Development (and remains available after you start working on the next version), yada yada yada. It's your call, of course. Different strokes.

Like Aaarnold would say, "You'll be back!"

[kduke]

Ray

DS_OBJECTS should be DS_JOBOBJECTS. Must be tired.

[jreddy]

in version 7.0 DS Administrator, there is a 'Protect Project' option, available for each project. And enabling that will make all the jobs in that project read-only and cannot be modified... dont know if this option is available in ver 6.0

to try it out, connect to DS Administrator, select the Projects tab. Then select your Project from the list and click on Properties. In the new dialog box that results, u will see this option as a button. Click that to protect your project. To see the effect all client sessions should be closed and logged in again.

hope this helps

[chulett]

Protected Projects are a new 7.x concept. Also be aware that it is (apparently) not compatible with Version Control.

[ray.wurlod]

DS_OBJECTS should be DS_JOBOBJECTS. Must be tired.

Was. Duly edited. Thanks for the heads-up.