Conference vaxaxp::vmsnotes

    re .0
    
    It sounds as if your customer was relying on an undocumented feature
    (or else please indicate where this is documented).
    
    You are right. The symbol does not appear to be present on Alpha.
    
    What on earth is your customer doing!? Perhaps there is a supported way
    of achieving it.

    
    Under OpenVMS VAX, the customer is depending on an undocumented and
    unsupported procedure -- what the customer is doing here is using the
    standard DCL command tables for parsing commands within an image. The
    DCL$AL_TAB_VEC symbol is exported from the DCLTABLES image, and points
    to the base of the DCLTABLES DCL command table.  Under OpenVMS VAX,
    this can be passed into CLI$ parsing routines such as CLI$DCL_PARSE.
    Under OpenVMS Alpha, this symbol is not exported; it's not made
    visible to user LINKs.  (And I know of no plans to export this
    symbol from DCLTABLES.)

    I'd recommend moving to one of the documented mechanisms.

    If the customer insists on continuing with an unsupported approach,
    they will want to acquire the source listings CD-ROM, and they will
    want to become more familiar with linking against the system symbol
    tables (LINK/SYSEXE, on OpenVMS Alpha) and with the CTL$AG_CLITABLE
    symbol.  This is the address of the base of the currently-mapped
    symbol table, stored in the process control region.

    Support Resources:
	The Internals and Data Structures Manuals
	COMET; the URL is http://comet.alf.dec.com/
	VAXAXP::NOTES$ARCHIVE:ALPHANOTES_V1 note 2086.*

RE: .2

>    I'd recommend moving to one of the documented mechanisms.

For the purpose stated, which ones are those?  How does one
validate a DCL command without actually executing it?

RE: .0

For the still undocumented/unsupported interface, the following
example is provided.  It is unhelpful if you have your own
private copy of DCLTABLES that you are using.

On VAX systems, link with SYS.STB /SELECTIVE.  On Alpha systems, use the
/SYSEXE qualifier.

$ CC /DECC /OBJ=DCL_EXAMPLE SYS$INPUT:
#include descrip
#include <stdio.h>

extern int CLI$DCL_PARSE() ;

main()

{

    int status;
    $DESCRIPTOR(command, "SHOW TIME");

#   pragma extern_model save
#   pragma extern_model strict_refdef
    extern void *CTL$AG_CLITABLE ;
#   pragma extern_model restore

    status = CLI$DCL_PARSE(&command, CTL$AG_CLITABLE);

    printf("Status from CLI$DCL_PARSE of %.*s is: %x\n",
                command.dsc$w_length, command.dsc$a_pointer, status);

}
$ IF F$GETSYI("ARCH_NAME").EQS."VAX"
$ THEN
$   LINK DCL_EXAMPLE + SYS$SYSTEM:SYS.STB/SELECTIVE
$ ELSE
$   LINK /SYSEXE DCL_EXAMPLE
$ ENDIF
$ RUN DCL_EXAMPLE

:For the purpose stated, which ones are those?

   There's no purpose stated...

:How does one validate a DCL command without actually executing it?

   One cannot verify a command without actually executing it.

    re .*
    
    Yes, my question about what the customer is doing was directed at the
    *purpose* of parsing against DCLTABLES which is obviously what is
    achieved by using DCL$AL_TAB_VEC.
    
    Incidentally, there is no guarantee that DCLTABLES in SYS$SHARE matches
    what is in process memory (as is provided by the example hack in this
    topic). My LOGIN.COM executes SET COMM commands.
    
    Since we are into dodgy hack territory ... one way that I have actually
    used to validate the syntax of a command but without executing the
    command (to avoid the side-effect of doing so at the expense of missing
    out on some additional checks that may be made by the command) is to
    ASSIGN a bogus logical name /USER for the image name and then execute
    the command. Strangely, I can't for the life of me remember why I
    wanted to do this. (-: Anyway, the only hack part is knowing what
    logical name to assign - which unfortunately can only definitively be
    obtained from the command tables. [I only wanted to test a single,
    known-in-advance verb with no relevant changes of image so it wasn't
    too bad for me.] Perhaps by SPAWNing the command into an environment in
    which image activation will fail e.g. insufficient quota, even the
    problem of having to know the logical name could be avoided.
             

The customer's application has its own command table.  But it also
allows users to enter DCL commands (by preceeding them with a "$")
and it returns the results.  I think using LIB$SPAWN will work for them.

Thanks

Tim