Oppolzer - Informatik / Blog

I want to stress again that there is a general problem behind this more technical
point of view; of course it is possible to control the behaviour of the developers
etc., so that the production LPARs are not disturbed.

But: the development people must be enabled to do their work, too;
and if the only way to do it is to do test runs on a production system
or - as in our case - on a special LPAR which is hosted on the same CEC
as critical other production systems, and if the testing time must be planned
weeks before with respect to the critical production runs on those production
systems, you're in a real mess.

The only way to get out of this mess, is:

realistic test data on LPARs on separate CECs,

the volume may be much lower that on the production LPARs, of course,

but you need to make sure that all relevant constellations of data appear in
the test system, too.

My experience is:

you have to think about testing from the start, and you have to provide the
needed resources. If you fail to do so, all your projects will get into serious
trouble - regarding time and budget.

Kind regards

Bernd



Am 08.01.2015 um 09:55 schrieb Bernd Oppolzer:
> There are other ways to prevent the developers and DBA people to
> get their work done, although the test LPARs are fine ... for example:
>
> forbid the access to production data by (legitimate) legal issues, which
> everybody understands, but: the test data provided (which has gone
> through an anonymization process) is so bad, that testing the applications
> is not possible any more, due to inconsistencies and irrelevant test
> data.
>
> So the DBA people and developers find ways to do the tests on
> copies of production data (on special LPARs), which has legal issues,
> and many problems with respect to availability and access time
> (you have to wait weeks !! before you can get a test running there etc.)
>
> like below:
>
> <quote>
>
> it was something like a psychiatric disorder, in corporate terms, even
> though intellectually, rationally, everybody knew this pattern was
> madness.
>
> </quote>
>
> Kind regards
>
> Bernd
>
>
>
> Am 08.01.2015 um 08:53 schrieb T.S.:
>> Also, if they are running things in production that they shouldn't
>> be, find
>> out if they're doing that because they're starved for resources
>> elsewhere
>> (i.e. in development or test). If that's another problem, fix that, too.
>> Maybe solving that problem requires a conversation with IBM and some
>> other
>> parties.
>>
>> People have to get their (legitimate) work done, and that includes
>> developers and DBAs.
>>
>> I recall one customer that starved its non-production users so badly
>> that
>> it was something like a psychiatric disorder, in corporate terms, even
>> though intellectually, rationally, everybody knew this pattern was
>> madness.
>> We ended up working with the customer to come up with a mutually
>> agreeable
>> and very effective solution that kept the customer from repeatedly
>> cutting
>> themselves. :-) It's best not to speculate about the exact solution, but
>> "talk to your doctor" if merited.
>>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN