Re: Casino switches to AIX

Steve,

It seems that it is not the i that is causing the problem, but....

1. Poor change management practices

I am making a lot of code changes to a legacy system,
writing and deploying new apps.

2. Poor application development practices

There is a constant battle with system locks.

3. Poor system management practices

The system is way behind on PTFs because we cant afford
the down time ( and lack of knowledge on how to minimize the time
needed in restricted state to apply the PTFs ).

Seems like the complaints you continue to make are all related to bad
practices in your IT shop. For every one of your complaints, there is a
viable and modern solution available. Maybe if you improved your IT
practices, you would stop complaining less about the i.

Trevor



On 11/30/08 9:02 AM, "Steve Richter" <stephenrichter@xxxxxxxxx> wrote:

I am not definitive on this because I am only working on V5R3 .... at
that release for sure, the i is not easy to run 24/7. I am making a
lot of code changes to a legacy system, writing and deploying new
apps. There is a constant battle with system locks. SQL often retains
a lock on a file after the query is completed. I have to run the
ALCOBJ CONFLICT(*RQSRLS) command to free the locks up when replacing
the file. SQL VIEWS also stay locked for some reason, even after the
using job is ended. I use SQL VIEWs a lot to get a handle on legacy
databases. When I replace a view in PRD, the system eventually
releases the lock on the view being replaced, but it takes about 15
minutes. Then of course there are all those locks retained by legacy
code on data and device files ( and database records ). Would help a
lot to be able to tell the system to at least temporarily release
those locks. The system is way behind on PTFs because we cant afford
the down time ( and lack of knowledge on how to minimize the time
needed in restricted state to apply the PTFs ).