Conference iosg::all-in-1_v30

    What baselevel is installed?
    
    Tony

    BL 123
    
    Cheers
    
    Jill

    Hello,
    
    I have exactly the same problem. Looks like:
    
$ SHOW QUE *CR*/full

Server queue OA1$SCRIPT_ENGLISH, on LABALL::, mounted form DEFAULT
    /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) /NOENABLE_GENERIC
    /LIBRARY=ENGLISH /OWNER=[SYSTEM] /PROCESSOR=OA$SCRIPT_SYMBIONT
    /PROTECTION=(S:E,O:D,G:R,W:W) /RETAIN=ERROR /SCHEDULE=(NOSIZE)

  Jobname         Username     Entry  Blocks  Status
  -------         --------     -----  ------  ------
  SM_QUOTA_SUBMIT ALLIN1_V30     259      16  Starting
    Submitted 25-MAR-1992 15:30 /FORM=DEFAULT /NOTE="SM_QUOTA_SUBMIT"
    /PARAM=("MANAGER","Disk Quota Report For: JENNY","SM_QUOTA_MINFO",
    "SM_QUOTA_MHDR",
    "User ,Listing of Quota Entries,========================,JENNY,Device",
    "USER3,ID,JENNY,VMSUSR") /PRIORITY=100
    File: _LABALL$DKB100:[SYSCOMMON.SYSEXE]OA$SCRIPT_SYMBIONT.EXE;2 (processing)
        /SETUP=("MANAGER",)

$ show sys
00000602 OA$SYMBIONT_007 HIB      4       17   0 00:00:00.44       237    151
00000691 _OA$0602_000000 LEF      4      389   0 00:00:03.83      1131    265
    

    Found it.
    
    The Script Symbiont is running the primary system on a CO-EX
    configuration.
    
    Adding $ @oa$lib:setoa 1
    to sylogin.com fixed the problem.
    
    Don't forget to:
    
    $@OA$LIB:SCRIPT_QUEUES_ALL delete
    $@OA$LIB:SCRIPT_QUEUES_INIT ENGLISH
    $@OA$LIB:SCRIPT_QUEUES_ALL start
    
    Jan

    Hi Jan,
    
    Thanks for the solution. You suggest putting setoa 1 in sylogin. What
    account really needs this - is it A1$SCRIPT?
    
    Cheers
    
    Jill

    We have managed to get the Script Symbiont going now but by putting
    the SETOA command in SYLOGIN we are forcing all users on the system to
    use the coexistent system.
    
    We tried just putting the SETOA command in the LOGIN.COM for the
    account submitting the script but this did not solve the problem.
    
    My knowledge of VMS is not too good at this level but am I right in
    assuming that when the script is submitted to the Script Symbiont only
    SYLOGIN is executed and not the user's LOGIN.COM?
    
    Looks like another problem report on its way!!
    
    Cheers
    
    Jill

    Hello Jill,
    
    >My knowledge of VMS is not too good at this level but am I right in
    >assuming that when the script is submitted to the Script Symbiont only
    >SYLOGIN is executed and not the user's LOGIN.COM?
    
    The first time a script is submit to the Script Symbiont,
    a slave process is created (_OA$muble). This process will
    run scripts in for all users in there own context. 
    
    It looks like the process is created with 
    PRC$m_NOUAF bit set, which means: don't use
    UAF values (no sys$login logical, no execution of login.com).
    
    I don't think the A1$SCRIPT VMS account is used for login at all.
    
    I am afraid we will have to wait for a reply from the 
    Script Symbiont Internals specialist to be sure...
    
    
    Regards,
    
    Jan

    The Script Symbiont is supposed to understand co-ex systems and execute
    the bit of code during initialisation that switches the logicals to the
    co-ex ones.
    
    A1LINK should produce a special .EXE for the co-ex script symbiont
    with the OA1$ version of OALNM.MAR linked into it. I suppose all of
    this is happening, and the right image is being used by the symbiont?
    
    I'll try and persuade the "Script Symbiont Internals specialist" to
    have a look at this and see what he thinks!
    
    Graham

    Graham,
    
    The symbiont being run was called OA$SCRIPT_SYMBIONT. (i.e /PROCESSOR =
    on the oa1$script_symbiont queue. Is this what you meant?
    
    Jill

    Ok, I guess I don't understand enough about symbionts!! I don't see how
    the queue processor name (/PROCESSOR=OA$SCRIPT_SYMBIONT) maps onto an
    image to be executed. The image must be the standard OA$IMAGE, but it
    needs to be the one that's been built by the co-ex version of A1LINK so
    that it knows about the right logicals.
    
    Waiting for the expert,
    
    Graham

    Graham,
    
    >A1LINK should produce a special .EXE for the co-ex script symbiont
    >with the OA1$ version of OALNM.MAR linked into it. I suppose all of
    >this is happening, and the right image is being used by the symbiont?
    
    No thats not what' happening.
    
    My symbiont looks like:
    
                    image name: "OA$SCRIPT_SYMBIONT"
                    image file identification: "ALL-IN-1 V3.0"
                    link date/time: 12-MAR-1992 03:56:08.55
                    linker identification: "05-09"
    
    IN BL123, this file is pulled out from A1030.B :
    
    [DIAMOND.A1DI$KITS123.BB]OA$SCRIPT_SYMBIONT.EXE;1          16 12-MAR-1992 10:20
    
    So A1LINK is not involved.
    
    Regards,
    
    Jan                                                                        

    RE .11, See my .10
    
    Looks like we may have missed something by not linking it at
    installation time.
    
    (Still) waiting for an expert!
    
    Graham

	The problem here is that the script symbiont (OA$SCRIPT_SYMBIONT.EXE)	
	is running up the OA$IMAGE for the 2.4 system rather than the 3.0
	system. In 2.4 OA$IMAGE does not know how to talk to a script symbiont
	and so hangs. The solution is to make sure the script symbiont runs
	up the 3.0 OA$IMAGE.

	The normal action taken by the script symbiont when creating a slave
	process to execute scripts is to create a mailbox containing the 
	command "$ ALLIN1" and supply the mailbox name as SYS$INPUT to the 
	slave process. This leads to the system-default OA$IMAGE being 
	executed, which in your case is the 2.4 image.

	Solution:

        Create a file called OA$SMB.COM and place it in SYS$SYSTEM. The
        file should contain DCL commands for setting the correct 3.0
	system and running ALL-IN-1.

	$ 
        $ set 3.0 system
	$ 
        $ alli

        Now do the following for the OA$SCRIPT script queue (and any others)

        $ stop/queue/reset OA$SCRIPT
        $ init/queue/dev=server/sep=res=oa$smb OA$SCRIPT
        $ start/queue OA$SCRIPT
        $ submit/queue=OA$SCRIPT <test-script>


	What happens now is that on seeing the "/sep=res=something" applied 
	to the queue the script symbiont creates a slave process and 
	defines SYS$SYSTEM:something.COM as SYS$INPUT. The rest is up to
	your command procedure.

	Cheers,
	Derek

	PS. You only need one OA$SCRIPT_SYMBIONT.EXE no matter how many 
	co-existant systems you have. The one that comes with the kit does 
	not need re-linking

    
    Hi Derek,
    
    Now all these notes concern about a Co-Ex system. However, I have the
    same problem on my cluster (as soon as the job is submitted, the
    OA$SCRIPT_ENGLISH queue gets in a 'Stopped' state). The only thing
    which makes the cluster different is that we have 3 versions of
    ALL-IN-1 V3.0 and 2 version s of ALL-IN-1 V2.4 running, but all on
    different nodes. Ofcourse the Script symbiont currently works on 1
    node (and it used to), but suddenly I encounter this problem.
    
    Any resemblense?
    
    Ciao,
    
    	Simon