RC = 12 FROM CSL FUNCTION DMSWRBLK; REASON: 97400
97400 Routine: Common Severity: ERROR Explanation: Sever condition returned from APPC/VM communication request. If your application receives this reason code intermittently, but the file pool is still available and other commands work correctly, the file pool server may be improperly configured. Notify your file pool administrator of this condition. (Ask the administrator to check the USERS start-up parameter value.) OK ... what should I be asking myself about Ask the administrator to check the USERS start-up parameter value.? This FilePool was just created from scratch via FILESERV GENERATE, so it's not a case where the USERS parameter may have been changed, but the server not rebuilt. I definitely get the error intermittently as the not-so-clear explanation states (it's an empty FilePool I'm populating from a backup to tape). The correlation between USERS and WHAT is not correct ... ? JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED]
Re: RC = 12 FROM CSL FUNCTION DMSWRBLK; REASON: 97400
Steve, The formula for determining the USERS is not at all accurate. I once had a small filepool on a system that only had 35 userids in its directory. I found that with a value of 100 for USERS, which was higher than the formula suggested as only 16 of the users were even granted authority to access the single defined filespace, the system would rapidly grind to a halt. By upping the value for USERS to 1000, things ran smoothly. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Imler, Steven J Sent: Friday, July 11, 2008 10:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: RC = 12 FROM CSL FUNCTION DMSWRBLK; REASON: 97400 97400 Routine: Common Severity: ERROR Explanation: Sever condition returned from APPC/VM communication request. If your application receives this reason code intermittently, but the file pool is still available and other commands work correctly, the file pool server may be improperly configured. Notify your file pool administrator of this condition. (Ask the administrator to check the USERS start-up parameter value.) OK ... what should I be asking myself about Ask the administrator to check the USERS start-up parameter value.? This FilePool was just created from scratch via FILESERV GENERATE, so it's not a case where the USERS parameter may have been changed, but the server not rebuilt. I definitely get the error intermittently as the not-so-clear explanation states (it's an empty FilePool I'm populating from a backup to tape). The correlation between USERS and WHAT is not correct ... ? JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED]
Re: RC = 12 FROM CSL FUNCTION DMSWRBLK; REASON: 97400
Hmm ... how embarrassing. I of all people should have known to check the SFS server console for oddness. snip DISCONNECT AT 09:42:44 EDT FRIDAY 07/11/08 DMS4GE3245I 07-11-08 12:06:50 The log is 91% full DMS4GE3245I 07-11-08 12:06:57 The log is 92% full DMS4GE3247W 07-11-08 12:07:04 Automatic LUW rollback processing initiated z/VM Version 5 Release 3.0, Service Level 0703 (64-bit), snip That being said, what's the correlation between the error I got and the LOG filling up? (At least I assume the LOG filled up?) JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED]
Re: RC = 12 FROM CSL FUNCTION DMSWRBLK; REASON: 97400
On Friday, 07/11/2008 at 01:51 EDT, Imler, Steven J [EMAIL PROTECTED] wrote: That being said, what's the correlation between the error I got and the LOG filling up? (At least I assume the LOG filled up?) What was returned in the WUERROR field, if anything? Some error codes (i.e. implicit rollback) are part of the wuerror information. As to why a log that isn't actually full would cause a rollback, I don't know. Is there anything you can commit along the way? Alan Altmark z/VM Development IBM Endicott
Re: RC = 12 FROM CSL FUNCTION DMSWRBLK; REASON: 97400
What I sometimes did in the past for such massive updates that make the log fill faster than log backup can clean: - place the updater in CP SLEEP - issue CP SEND VMSERVx BACKUP to empty the logs - unSLEEP the updater. 2008/7/11 Alan Altmark [EMAIL PROTECTED]: On Friday, 07/11/2008 at 01:51 EDT, Imler, Steven J [EMAIL PROTECTED] wrote: That being said, what's the correlation between the error I got and the LOG filling up? (At least I assume the LOG filled up?) What was returned in the WUERROR field, if anything? Some error codes (i.e. implicit rollback) are part of the wuerror information. As to why a log that isn't actually full would cause a rollback, I don't know. Is there anything you can commit along the way? Alan Altmark z/VM Development IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: RC = 12 FROM CSL FUNCTION DMSWRBLK; REASON: 97400
Don't know about WUERROR ... I'd have to repro and force a DUMP to find what/if there was a value. In the mean time, I got bigger LOG! That appears to have solved the problem. I'll run the test a few more times! JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, July 11, 2008 04:23 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RC = 12 FROM CSL FUNCTION DMSWRBLK; REASON: 97400 On Friday, 07/11/2008 at 01:51 EDT, Imler, Steven J [EMAIL PROTECTED] wrote: That being said, what's the correlation between the error I got and the LOG filling up? (At least I assume the LOG filled up?) What was returned in the WUERROR field, if anything? Some error codes (i.e. implicit rollback) are part of the wuerror information. As to why a log that isn't actually full would cause a rollback, I don't know. Is there anything you can commit along the way? Alan Altmark z/VM Development IBM Endicott
