TomLiotta   7670 pts.  |   Oct 26 2009  9:31PM GMT

As noted, it isn’t a TCP/IP server, so it isn’t controlled like a TCP/IP server.

But there might be more to consider. Personally, I would not make this change. If I was directed to make the change by a supervisor/boss, I’d push hard to do it in a test environment to ensure that the system did not use the *Database server on startup for its own processing. Note that even if it was not used by my system at startup today, I’d want to be prepared in case a future PTF or upgrade changed the system to have it use the server at startup.

In many (most?) systems, you can see a variety of QSQSRVR requests being run under QSECOFR during system startup. QSQSRVR handles various JDBC and SQL CLI server mode requests. However, it apparently may connect to the DRDA/DDM and/or *DATABASE server for data retrieval. (Note many PTFs for QSQSRVR that require *Database pre-start jobs to be ended/restarted before the QSQSRVR PTF becomes effective.)

Also, if the intention is to stop client ODBC connections, be aware that some ODBC connects go through the DRDA/DDM database server instead. A primary example is DB2 Connect.

I would recommend that the *Database server be allowed to start with TCP/IP normally. And then, after the system is fully started, end the *Database host server and pre-start jobs. This still might not accomplish whatever you’re trying to do, but it should help avoid unintended consequences today and in the future.

Tom

Batman47   505 pts.  |   Oct 26 2009  9:56PM GMT

Tom,

Thank you for your input. I have avoided this for a long time by doing as you say… let everything come up and then end the *Database server. However, I’ve got servers that are constantly trying to access the system at all hours of the day, including during backups and processing in the wee hours of the morning. I’m told their agents on these servers have to run that way, since they can not control the scheduling. The problem is these connections can and have caused object locks during this critical time. We run a single partition system, so we need to stop all activity for the backups and processing. I can’t have ODBC connections during this time, and I do have start and stop jobs for the *Database server that work fine during the other 6 days of the week and now I have a solution to prevent them from going active after an IPL. Thanks Wilson.

TomLiotta   7670 pts.  |   Oct 27 2009  12:30AM GMT

Wilson:

The problem is these connections can and have caused object locks during this critical time.

A possibility is that the pre-start jobs haven’t been ended when the server was ended. Are they allowed to stay active when you end the *Database server? If you don’t also do the ENDPJ/STRPJ for related pre-starts, that might be where one trouble comes from.

Tom

DanD   1880 pts.  |   Oct 27 2009  3:03PM GMT

I think it would be better to start a host server later than to let it autostart then end it manually and restart it. If you don’t want the job to start, SQL or DFU the file QATOCSTART which looks like this:

SVR Server Auto Library of Program to Exte
TYP Start Program Call
T *CIMOM *NO QSYS QYCMCTLCIM QSYS
U HOSTCENTRAL *YES *NONE QSYS
U HOSTDATABASE *YES *NONE QSYS
U HOSTDTAQ *YES *NONE QSYS
U HOSTFILE *YES *NONE QSYS
U HOSTNETPRT *YES *NONE QSYS
U HOSTRMTCMD *YES *NONE QSYS
U HOSTSERVERS *YES *NONE QSYS

Change HOSTDATABASE entry Start Program to *NO.
Then when your processing finishes do the STRHOSTSVR (*DATABASE) cmd to bring it up.

TomLiotta   7670 pts.  |   Oct 28 2009  12:32AM GMT

Also, note the ENDHOSTSVR ENDACTCNN( *DATABASE ) parameter for closing connections when the server is ended.

Tom