From:	SMTP%"leichter@lrw.com" 31-MAR-1995 08:45:18.01
To:	EVERHART
CC:	
Subj:	RE: DCL question:  Still passing parameters

From: Jerry Leichter <leichter@lrw.com>
X-Newsgroups: comp.os.vms
Subject: RE: DCL question:  Still passing parameters
Message-ID: <9503311307.AA14713@uu3.psi.com>
Date: Fri, 31 Mar 95 08:02:31 EDT
Organization: Info-Vax<==>Comp.Os.Vms Gateway
X-Gateway-Source-Info: Mailing List
Lines: 97
To: Info-VAX@Mvb.Saic.Com

	Earlier I posted a problem with passing parameter values with spaces
	in them.  Thanks to everyone who replied, but now I'm having the same
	problem on  embedded submits.  Let me explain:

	$! get_loc.com
	$ inquire loc "Enter location"
	$ submit/parameter="''loc'" search_loc.com
	$ exit

	If a variable with spaces is entered, like SHELF 1, it is correctly
	passed to search_loc.com.

	$! search_loc.com
	$!
	$! this is an sql command line that allows the process to run in the
	$! background
	$ sqlplus username/password @search.sql 'p1
	$ exit

	Now, when p1, which is SHELF 1, is passed to the sql script, DCL
	strips the one off.  So, only SHELF, gets passed to sql.  I tried
	modifying p1 with a variety of quotation marks, but nothing seem to
	allow p1 to be passed as SHELF 1.

	Once again, I would appreciate any help.

Rather than asking for information about many individual examples, why not
learn the principles involved?  They are fully documented.  (They are also
simpler than they appear below, since I've included all the exceptions,
which don't occur all that often.)

	If a DCL parameter contains special symbols - including spaces,
	lower-case characters where case is significant, any of the characters
	that have a syntactic significance in DCL (e.g., "/" introduces quali-
	fiers; "," separates list items) then it must be wrapped in quotes.
	One simple way to be safe is to use quotes for any characters that
	could not be part of a file name - keeping in mind that in a file
	name upper- and lower-case are equivalent.

	If a quote must appears *within* a quoted string, double it.

	Quoting of parameters is always legal except for those parameters
	whose syntax explicitly allows them to contain quotes.  The surprising
	case where this comes up is for file specifications (which can legally
	contain quotes to access ANSI-standard tapes with non-VMS format file
	names), as well as in remote file specifications.

	Expansion of DCL symbols occurs when they occur:

		1. After ' (with an optional trailing apostrophe) anywhere
			*except* inside strings;
		2. After '' (with an optional trailing apostrophe) *inside* of
			strings;
		3. As the the first element on a line;
		4. In special contexts (e.g., in the condition of IF)
		5. During parameter evaluation, after &, unless the syntax
			says the parameter involved is "the rest of the line".

	Expansion for reasons 1 and 2 occur before DCL actually looks at the
	meaning of the line.  Expansion 3 occurs when DCL is determining what
	the verb on the line is (which determines the syntax of the rest of
	the line).  Expansion for reasons 4 and 5 occurs when DCL is picking
	out the pieces that the syntax specifies should be there.

So, looking at your example:

	$ sqlplus username/password @search.sql 'p1

p1 is substituted for reason 1, *before* DCL actually looks at the line.  If
it contains spaces, what will appear on the line is two or more separate
parameters, with spaces in between.  Hence, the parameter should be quoted:

	$ sqlplus username/password @search.sql "'p1"

However, now the apostrophe is inside quotes, so reason 1 doesn't apply; we
must instead fall back on reason 2, and rewrite this as:

	$ sqlplus username/password @search.sql "''p1"

Personally, I always include the optional closing apostrophe as well, but
that's mainly a matter of taste:

	$ sqlplus username/password @search.sql "''p1'"

If sqlplus is actually defined as a DCL verb, rather than as a foreign
command (unlikely, since then "/password" would be treated as a qualifier and
"@search.sql" would be replaced in-line with search.sql's contents)) then:

	$ sqlplus username/password @search.sql &p1

would also work.  If that argument were in fact defined syntactically to be a
file specification, then you would *have* to use this form.  On the other
hand, this form does *not* work for foreign commands, or rare commands like
HELP, since in both these cases there is really only one argument defined by
the syntax, and it is "the rest of the line", so rule 5 doesn't apply.

							-- Jerry
