Hi Jan,

Something I forgot to ask, but how do you go about loading your SP's?

1. Do you load onto a test box first?
2. How do you test your system once you've gone through a SP upgrade. Do you have a test plan to follow?

We are currently on SP5 so I've got three upgrades to go through and I'm interested to know what procedures other people follow.

Thanks

PJ

Hi,

Maybe someone who has the experience should answer this query,
I have gone through SP6 to SP8 install in our development environment. Apart from the length of time, I encountered issues
that I did not expect.

These included an old porting set and Baan standard program.
The other danger is customisations , if you have alot then these need to be tested, and in many cases recoded depending on the changes

If there is a guideline that you should follow, apart from the notes sent by Baan, then I would appreciate it if someone could document it.

Aidan

Also,

Alot of people (more than 400) have checked out this post probably hoping for a guideline

Based upon the best practices at my customer sites here is what I would do if I was an IT manager at a site that uses Baan:

1. First, the system admins/DBAs need to have a small system to test the OS and DB updates. As these may take down the development server or have a play factor (I wonder what will happen if I turn on NIS+ for example), this should not be on a box used for production or near-production activity. The architecture should be reasonably close to the production environment.

2. All porting set, tools updates or application service packs are tested on a test/development server first. The developers use the new environment for fixes and the data and code on this system is refreshed from production on a regular basis to ensure that parameters, common data, tables, binaries, etc. are the same from the production to development side.

The users have documented their major sessions so that a well-defined set of tests exist for a change. The users participate in the test of their functional area as they can identify a change better than an IT staff person that is less familiar with the app. If you know all of the sessions that are defined as critical to the business process, this step is much easier.

Customizations are reviewed during this step to see if they (1) are no longer necessary due to new functionality, (2) are okay and uneffected by the change or (3) must be recoded. This assumes that all customizations are documented.

If you can afford it, a tool like LodeRunner makes iterative testing much easier.

3. After validation of the update in the test environment, the update is installed on the production server in a test VRC or a seperate test $BSE directory. This test is the final pre-production test of the patch before moving it into production. The users must sign-off on this step and if it is a change to a batch process, a test is run during the production period against a production quality dataset to make sure that the update did not effect performance.

4. The update is moved into production.

5. A regular schedule is set for maintenance (maybe the third weekend of every month) and IT has that time period reserved whether they need it or not. That way no one is surprised by taking the system down and you know that you have a maintenance window available.

I know this sounds tedious but there are no shortcuts available for good testing. It requires a disciplined IT group and good communication with the users to meet this need. Documentation and good change control practices are boring but are the mark of the IT Professional (thus justifying the salaries we are paid and the respect that we want from the business side).

I was a IT manager in a previous life and we did institute this kind of test regimen. We had application functional specialists in the IT department that did the "step 2" tests defined above before turning them over to the users. Was it a lot of work? Yes. Did we reduce our problems? Yes. But it was cost effective as we handled issues in development instead of in production -- it also reduced the stress on the IT staff since they could resolve issues during the normal workday instead of during the upgrade weekend. The upgrades themselves became a non-event.

Due to the cost of the change sometimes rolling multiple service packs into the same change cycle is appropriate -- I have a tendency to only apply SPs when required or on a quarterly basis at most (unless I have a critical production problem).

------

These are my thoughts, how do all of you do this in your companies?

-- Jim

1st - Thanks to Jordan for re-kindling this thread.

2nd - Thanks to James for his detailed reply.

We have three Baan boxes (test, pre-production and production) and intend to carry out our update as in James's recommendations.

We too take the view of not installing SP's unless we really need to. As we are still on SP5 and having to install numerous pre-req's when loading solutions we have decided it's time to bring our system up to date. So we are going through a major upgrade program which will include an upgrade to our current Oracle version of 805, porting set and SP's.

When upgrading SP's would you automatically look at upgrading your porting set and standard tools?

Regards

PJ

PJ,

If you are doing consolidated testing for a major upgrade including an Oracle upgrade (and I would recomend going to 8.0.6 or higher), I would upgrade porting set and tools. While I recognize that tools and porting sets will possible introduce issues with DDC, function servers, or custom apps, I would rather test in one sweep.

-- Jim

Hi ,

The reason I reopened this thread was because we are going from SP6 to SP8 for Baan 4C4 on our Production environment
The pressure is on and I'm concerned
It's about 6 weeks , since I put it into development
We have 2 systems
The application server running : HP-UX 11.0
The database server : As above, Oracle 8.0.5

First, I allocated an extra 2gb to the $BSE mountpoint
I verified that I had about 300mb free in company 000 for both data and index, as this is where the data gets written when installing patches

To check for customisations, I scanned and checked solution to install for SP7 and then for SP8

Check out the following Baan solutions
solution no : 103160, 110657, and 114235

for latest information about SP6, SP7 , and SP8

Also note that solution : 82046 clearly identifies that you require at least port6.1c.05.xx

Basically, while installing SP7, and SP8 : I received an error message regarding bic_open
This wasn't mention in the notes and didn't investigate with Baan before hand
After I installed the latest porting set, It was okay

The basic steps were

(1) Scan the PMC dumps
(2) Process the PMC dumps filtering on uninstalled
(3) Check solution to install
(4) Creatime runtime for tools ,
selecting dump Data Definitions
(6) Exit and Restart the Bshell
(7) Patch objects after error solving
(8) Create runtime data dictionary, select the all fields to reconfigure tables
(9) Restart the bhell

I also set the database in no archivelog mode

Aidan

Ivc4 Sp8
Is anyone running under this in a live environment as yet ?
If yes then how long have you been live and have you had any "issues" (major) ?

Also If yes then did you test in a "test" environment ?

Also If yes then what methodology did you use for migratiing to your live environment ?

If no then is there a "post subject" which discusses issues around SP8?

We are currently testing the above version in a "test" envionment
and are aiming to go live in the New Year

__________________

I have a customer live for 2 months with SP8. He does not have big problems with that release.

I have heard from one of my customers that SP8 collided with some of the automotive extensions...

No details though.

-- Jim

Hi all,

Do you recommend the saving of components for the 'older' service packs (3, 4, 5, 6) ?

In my opinion this shouldn't be necessary since the older ones will never be backed out anymore. It could reduce installation times and disk space requirements.

The PMC directory will get filled in pretty fast - it's the biggest offender under $BSE!

I think Baan needs an enhancement request for PMC: get a session that will get rid of old Service Packs solutions, like, if your on SPx, you should get rid of all untill SPx-2 (keep previous, just in case...).

If you're going for something higher than SP5, I would say to get rid of SP1-4 saves...

On the BGS site you can find a solution what to do with the old patches.

Some inside information: I know that some is going to join Baan solution & services and that his first assignment is to build some software that has to clean up, the no longer needed patches.

Rgrds,
Han