Re: Casino switches to AIX

[Trevor Perry <trevor@xxxxxxxxxx>]

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 ).