[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

985.0. "Create user doesn't get to batch queue." by KERNEL::LOAT (Bored....Bored....BORED!!!!) Fri Jul 03 1992 13:08

    
    A customer has just upgraded ALL-IN-1 to 3.0 (from 2.4) and now she
    can't create any user accounts.
    
    When she tries to create an account, ALL-IN-1 fails to submit the batch
    job to the batch queue, and the error message which comes back is:
    
    "Failed to submit job to batch."
    
    This comes back because the value of $STATUS is not equal to a couple
    of symbols which translate to known values, so it falls through to a
    generic message.
    
    The value of #DCL_STATUS is 229712. How can I find out what message
    this represents?
    
    Steve.

T.R	Title	User	Personal Name	Date	Lines
985.1	Not very helpfully...	IOSG::PYE	Graham - ALL-IN-1 Sorcerer's Apprentice	`Fri Jul 03 1992 13:17`	12
	$ write sys$output f$message( 229712 ) gives the error message insufficient parameters to command. Having done the ususal checks that the OA$SUBMIT image is owned by the same UIC as the ALLIN1 (sic) account, and that all the command procedures in OA$LIB are too, then.... You'll have to put a set verify somewhere in the command file to see what the missing parameter is. Perhaps the account name being used has a "'" or something in it that is causing the parsing to break. Graham
985.2	Seen this one before - system policies wrong	IOSG::TALLETT	Arranging bits for a living...	`Fri Jul 03 1992 17:54`	12
	It is probably that either the account name in system policies for submitting batch jobs is blank, or the queue name is blank. See SM MSY SSP You could also do a GET OA$DCL='set verify' and re-try the submit. That way you will be able to see the command in error. If you still can't figure it out, post the a1submit command here and we'll help. Regards, Paul
985.3	usually the submission	IOSG::TYLDESLEY		`Mon Jul 06 1992 09:57`	10
	Sorry - just catching up - the most common cause we see of this one is, as Graham says, the ownership of MUA_CREATE.COM which must be the same as OA$SUBMIT.EXE. Check also the identifiers and access on OA$SUBMIT (Oa$admin, read+execute). Failing that, check the queues that the batch job is submitted to - I usually set trace just before releasing SM$CREATE to see what is happening in these cases. (Enter Command: SET_TRACE(script,term,symbol). Cheers, daveT
985.4	Fixed!	KERNEL::LOAT	Bored....Bored....BORED!!!!	`Mon Jul 06 1992 10:03`	9
	Got it. The Account field in SM MSY SSP was blank. Thanx for all the ideas. Steve.
985.5	How did it happen?	IOSG::MAURICE	Ceci n'est pas une note	`Mon Jul 06 1992 10:28`	8
	Hi Steve, Do you have any idea how the account field managed to be blank? It doesn't seem that you can blank it with the SSP form. Cheers Stuart
985.6	Very Common at upgrade Sites	XLII::FDONOHUE		`Mon Jul 06 1992 13:49`	17
	Stuart, Unfortunately, we (at the CSC) are seeing alot of sites that upgrade to V3.0 that have several of the fields on the SSP form blank. This results in failure to be able to successfully submit lots of MUA/MHP procedures to batch. This is a VERY common problem already, If your lucky maybe it will make the TOP TEN this month! There must be something in the post-installation procedure that is either not working or is absent in populating these new field! Faith Donohue