91d database shutdown issue

First of all 9.1d is ancient, obsolete and unsupported.  The only supported release of version 9 is 9.1e service pack 4 which is now  over 5 years old.  So you really ought to be looking into an upgrade.  AIX 5.2 is fairly long in the tooth as well.

Having said that...

You have mixed in a number of different questions.  Focusing on the thread subject seems like a good idea, one would assume that that is the most pressing issue.  It would be helpful to know what command you are using to attempt to shutdown.  It should be something along the lines of:

  proshut dbname -by

in most cases that would be sufficient.  It might not work if you are not the user who started the database or otherwise lack permission to shut it down.  In some cases you might need to add -F to force a shutdown but that should be an exception -- not the standard.  The error that you are reporting ("no servers are available") is not a typical shutdown related error -- another reason to provide the exact command that you are using.  The tail of the db .lg file right after the attempted shutdown would also be very interesting to see.

Why are you shutting down to do batch processing?  Are you running some sort of single user batch process?  Or is it just that you do a nightly shutdown, restart and then kick off the batch cycle?  If the shutdown fails for some reason and you have scripts that don't deal with that failure effectively then the reported error might be nothing more than a side effect of attempting to restart something things that are already running.  (BTW, if you are doing a nightly restart and part of that process involves offline backups and if my theory about the shutdown failing is correct then your backups are no good.  You don't want to find that out the hard way.)

As for "correct database startup parameters".  It depends.  The parameters that you need depend on the application, it's usage, the hardware resources that are available and, finally, your goals and objectives.  Everyone is different and there a great many parameters to choose from.  There is no "one size fits all" answer -- if there was then the parameters would be eliminated and we wouldn't need to worry about setting them.

Many thanks for the reply.

The age of the OS level, Progress version are application related (highly customized QAD 86e). Decision made several years ago not to invest-upgrade in QAD as an ERP system, as our parent company is starting a global ERP rollout (another product).

Yes, the first part of the batch cycle is a database shutdown, and then an offline backup of qad and sub databases.

The database I'm having an issue shutting down is a holding progress database or interface to qad. Progress, jdbc and odbc clients connect to this database.

I misspoke; the issue is more likely related to the startup parameters vs. the shutdown. Neither a -by or a -Fby will shutdown the database.

If you have any suggestions, they would be appreciated.

Both Progress and the OS can be upgraded in this situation.  You can choose not to but you (or the company) are not doing yourself any favors with that decision.

I do not understand why you think that startup parameters are related to shutdown problems.

I suggest that you attempt a shutdown and then post the actual command used, any errors produced (perhaps in the form of a screen capture) and the section of the .lg file that shows what happens.  That would go a long ways towards helping to understand what is going on here.

What do you mean by "a holding database"?

Is this a new problem that has just started happening?

Or has it been this way for a while?

For what it is worth error 1154 is related to session startup.  It should have nothing to do with proshut.  But on the off chance that there is just a whole lot of confusion on the air what are your current startup parameters?  In particular -n, -Mn and -Ma.  And if you are starting multiple brokers what are their startup parameters?

It acts as a holding database for data from other data sources such as

Oracle and SQL. We update QAD and SQL-Oracle from this database, with

data flow going in both directions. I hope this helps.

This has been going on for some time.

It wasn't noticed until recently.

The only parameters set are -db "database name" -H "hostname" -S "servicename" -N TCP -n 80

I am not running multiple brokers.

We where told by QAD that this was the highest levels of AIX and Progress that could be used running QAD86E. If this is not the case, can you please provide what are the highest levels we can migrate too? Also are there any issues I need to be aware of if we decide to upgrade.

Thank you

When did QAD tell you this?  And what did they actually say?  My guess is that a long time ago someone got information regarding what versions of Progress and AIX had been [b]certified[/b] with QAD at that point in time.  Which is a very different question from which ones will [b]work[/b].  9.1D is [b]no longer supprted[/b].  And QAD has long since moved on to newer releases and probably couldn't care less about recertifying old releases.  So it's certification status is rather pointless.  Upgrading a Progress application from 9.1D to 9.1E04 is a trivial process.  You do not even need to recompile.  Just shutdown, truncate your bi files, download 9.1E and apply the service pack and restart.  Of course, as always, you should backup first and test this in a test environment before you go live.  But it really isn't at all difficult.

Upgrading AIX is more complex but no riskier.  It works fine.

-n 80 is very close to the total number of connections that you have described above.

There are a number of bugs in ancient, obsolete and unsupported releases which are related to bad behavior when the number of connections equals -n.  One of the bugs is that you cannot connect to the database to shut it down.  Or monitor it and so forth.  This *might* be what you are seeing.  Existing connections continue to run without problems but new connections will fail.

Try starting promon.  If that fails to work then kill several connections -- preferably by getting the users to log out or by gracefully shutting down whatever jobs are making connections.  But if you have to use an actual "kill" use "kill -1" first.  Try to avoid kill -9 as you run the risk of crashing the database that way.  If you can get several sessions disconnected you should then be able to run proshut successfully.

(Of course the problem may be something else entirely...)

The -n startup parameter is not the same as the number of licenses.  You can, and should, set it much higher than your expected license count.  Especially if you are running an ancient, obsolete and unsupported release that might be subject to these sorts of problems.

The default values for -Mn and -Ma are 4 and 5 respectively.  This would only allow 20 remote connections (those using -S).  That does not match your reported configuration so they must be being set somewhere other than wherever it is that you are looking.  You should grep the .lg file to determine the actual values in use.  i.e.:

     grep '(\-Mn)' sports2000.lg | tail -1

     grep '(\-Ma)' sports2000.lg | tail -1

In your case I would expect to see something more like -Mn 15 -Ma 5.  And I would set -n to 100.