Comments on: As400 Daily Backup Error

By: ToddN2000

ToddN2000 — Thu, 28 Mar 2013 12:19:36 +0000

We had some similar issues. Some user would forget to sign off at the end of the day and this would cause lock on files. What to did to eliminate some of the proble was to set the system parm for the inactivity timer to 60 minutes QINACTITV. This may help without the need to end the sub systems.

By: TomLiotta

TomLiotta — Wed, 27 Mar 2013 04:31:40 +0000

…the joblog for the offending job eg 278260/QUSER/QRWTSRVR doesnt exist so cannot interrogate what this DB2CON session was doing at the time the overnight backup was being run.

The joblog probably won’t tell you what it’s doing even if you could find it. The joblog doesn’t record database transactions in any job, not just QRWTSRVR (unless your developers send messages to the joblog). That’s what journals are for, not joblogs.

The QRWTSRVR job is the TCP/IP DDM server handling remote DDM or DRDA database accesses. If you have active server jobs doing important updates during the times you want to run backups, you need to understand that you might not be backing up important database files.

If transactions are being sent and not being committed, the database files are not going to be saved whether you use save-while-active or not. Since you can’t end subsystems, you might as well get used to the idea that your backups will fail from time to time. The best alternative is to get your developers to run their transactions properly and either COMMIT successful transactions or ROLLBACK unsuccessful ones. The next best option is to end database services before starting your backups.

Instead of trying to look at a joblog, use iSeries Navigator to drill into the connection for your AS/400 into Databases-> [databasename]-> Transactions-> Database Transactions. You can sort the list by job name to find any transactions for jobs named QRWTSRVR. From a terminal, you can run the WRKCMTDFN JOB(QRWTSRVR) command.

It only makes sense to do this at the time the message is sent. It probably won’t do any good to look later in the day because everything will be long gone.

Tom

By: Tonks

Tonks — Tue, 26 Mar 2013 23:28:05 +0000

Exactly Jfranz…..
I too have this issue with our backups intermittently.
I cannot shutdown any subsytems whilst our backup occurs so the SWA backup method has been perfect for our requirements ( except when this issue occurs!)
Frustrating thing for me is when i try to investigate this issue it tells me the joblog for the offending job eg 278260/QUSER/QRWTSRVR doesnt exist so cannot interrogate what this DB2CON session was doing at the time the overnight backup was being run.
“This request cannot continue until all commitment definitions with pending changes for job 278260/QUSER/QRWTSRVR are committed or rolled back.”

By: jfranz

jfranz — Thu, 14 Jun 2012 15:25:19 +0000

The whole purpose of Save While Active is to not shut down!
You need to address the parms you are using versus the committment control going on in the user library APDBFA. Save While Active is a wonderful thing to use. IBM has considerable documentation & discussion of the issue in the Info Center.

By: tomliotta

tomliotta — Thu, 14 Jun 2012 00:20:31 +0000

…any suggestions to improve?

Definitely. Don’t use ENDSBS unless you’re going to ensure that the jobs in each of those subsystems has ended first.

Otherwise, a locked job will make the associated subsystem unusable until you can IPL.

Tom

By: markmason

markmason — Wed, 13 Jun 2012 13:15:38 +0000

I am trying to replicate a restricted stated so nightly jobs and backups can run in batch. This is what I have, any suggestions to improve? /* End All Subsystem (COMMENTED OUT) */ /* ENDSBS SBS(*ALL) OPTION(*IMMED) */ /* Replace with Individual SBS */ ENDSBS SBS(MFBATCH) OPTION(*CNTRLD) MONMSG MSGID(CPF1054) ENDSBS SBS(QBATCH) OPTION(*CNTRLD) MONMSG MSGID(CPF1054) ENDSBS SBS(QINTER) OPTION(*CNTRLD) MONMSG MSGID(CPF1054) ENDSBS SBS(QUSRWRK) OPTION(*CNTRLD) MONMSG MSGID(CPF1054) ENDSBS SBS(QSERVER) OPTION(*CNTRLD) MONMSG MSGID(CPF1054) DELAY10: DLYJOB DLY(&SECONDS) ENDHOSTSVR SERVER(*ALL) MONMSG MSGID(CPF0000) ENDSBS SBS(MFBATCH) OPTION(*IMMED) MONMSG MSGID(CPF0000) ENDSBS SBS(QCMN) OPTION(*IMMED) MONMSG MSGID(CPF0000) ENDSBS SBS(QBATCH ) OPTION(*IMMED) MONMSG MSGID(CPF1054) ENDSBS SBS(QINTER) OPTION(*immed) MONMSG MSGID(CPF1054) ENDSBS SBS(QUSRWRK) OPTION(*IMMED) MONMSG MSGID(CPF1054) ENDSBS SBS(QSERVER) OPTION(*immed) MONMSG MSGID(CPF1054) ENDSBS SBS(QPGMR) OPTION(*IMMED) MONMSG MSGID(CPF0000) DELAY5: DLYJOB DLY(&SECONDS) /* delay 10 minutes */ /* NEXT */ STRSBS SBSD(QPGMR) /* MONMSG MSGID(CPF1099) EXEC(GOTO CMDLBL(DELAY5)) */ /* CPF1099 = Subsystem not started because system ending */ STRSBS SBSD(QSPL) MONMSG MSGID(CPF1010) CHGMSGQ MSGQ(QSYSOPR) DLVRY(*HOLD) MONMSG MSGID(CPF2451) /* ********************************************************** */ /* Begin End of Day Process * */ /* ********************************************************** */ STRSBS SBSD(QSYS/QSERVER) MONMSG MSGID(CPF0000) STRSBS SBSD(QSYS/QUSRWRK) MONMSG MSGID(CPF0000) /* Start Communications Subsystem. */ STRSBS SBSD(QCMN) MONMSG MSGID(CPF0000) STRSBS SBSD(QINTER) MONMSG MSGID(CPF0000) DLYJOB DLY(&SECONDS) /* delay 5 minutes */ STRTCP MONMSG MSGID(CPF0000) /* ***************************************************************** */ ENDPGM

By: tomliotta

tomliotta — Thu, 01 Sep 2011 01:29:37 +0000

Also note that ending QSERVER and/or QUSRWRK subsystems might have no effect. The related host server jobs can run in other subsystems.

Further, if any problems are associated with jobs in those subsystems such that the ENDSBS cannot complete successfully, the result can be a required ENDJOBABN or a forced power-down to effect cleanup. Quite possibly, a RCLSTG SELECT(*DBXREF) or RCLDBXREF *FIX would be needed after IPL.

IMO, it is better to end the related host servers with ENDHOSTSVR ENDACTCNN(*DATABASE) than simply to issue ENDSBS. If any job in a subsystem is unable to end, then the subsystem cannot end. The subsystem also can’t be restarted to handle new work until the problem is resolved.

Tom

By: tomliotta

tomliotta — Thu, 01 Sep 2011 01:18:28 +0000

At the moment, there is no reason to believe that any interactive subsystem is involved in the problem except that it is one of the possibilities. If it’s not involved, then ending any interactive subsystem won’t make any difference.

First step is to determine which commitment definitions are involved, and then to determine which jobs created those definitions. ODBC/JDBC jobs through the database server may be more likely causes of interference at that time of day, but there’s no way for us to know.

The recovery steps in message description CPF377F need to be followed. The results of those actions can be posted back here if further help is needed.

Tom

By: jmsci1

jmsci1 — Wed, 31 Aug 2011 21:56:24 +0000

If you are truely doing a save while active backup using brms,

1. shutdown qinter or whatever the interactive subsystem is named (remember to leave a back door or another interactive up that allow you to log in – for troubleshooting purposes.
2. Monitor the msgq that the sync point msg is sent.
3. once the message is rec’d, restart the interactive subsystem.

I do this a lot in large end IT shop.

Try it. heres a link

http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzaiu%2Frzaiurzaiu352.htm

By: is questions

is questions — Tue, 30 Aug 2011 14:59:13 +0000

I suggest you end the QINTER subsystem prior to backup or part of your backup is to end the users. We have also this case before and usually users have a lock on commitment definition.