FW: Passing large number of arguments to a program

FW: Passing large number of arguments to a program

Post by Ken Robins » Wed, 05 Dec 2007 05:20:27


sol gongola < XXXX@XXXXX.COM > wrote in



DCL only allows 8 arguments, the OP is passing the arguments to a C
program. What the OP is probably running into is the maximum lenght of a
DCL line,

Ken
 
 
 

FW: Passing large number of arguments to a program

Post by sol gongol » Wed, 05 Dec 2007 05:37:17

am still on vms 7.2-1.
vms 8.3 allows more than p1...p8?

Farrell, Michael wrote:

 
 
 

FW: Passing large number of arguments to a program

Post by VAXman- » Wed, 05 Dec 2007 05:51:08

In article <4754650b$0$7446$ XXXX@XXXXX.COM >, Ken Robinson < XXXX@XXXXX.COM > writes:



The OP didn't bother to post his code in plain text making it virtually
impossible for me to bother to decipher it. 2000+ lines of unreadable
code.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

"Well my son, life is like a beanstalk, isn't it?"

http://www.yqcomputer.com/
 
 
 

FW: Passing large number of arguments to a program

Post by Farrell, M » Wed, 05 Dec 2007 05:53:04

o,

The program is called from inside the DCL jacket as a "foreign command". That way, the arg list is supposed to be controlled by the program as far as I know.

See the statement:
$ prog := $$1$DKA100:[IGOR.SPB2ASC.REL_058]TEST_ARGS.EXE
Then:
$ prog 'args'


Mike

-----Original Message-----
From: sol gongola [mailto: XXXX@XXXXX.COM ]
Sent: Monday, December 03, 2007 3:37 PM
To: XXXX@XXXXX.COM
Subject: Re: FW: Passing large number of arguments to a program

I am still on vms 7.2-1.
vms 8.3 allows more than p1...p8?

Farrell, Michael wrote:
 
 
 

FW: Passing large number of arguments to a program

Post by Farrell, M » Wed, 05 Dec 2007 06:04:35

If it is running into the maximum length of a DCL line, then why is it
that varg[1], varg[2], etc., is clobbered but the last arguments (args
144, 156, and 170 in each of the examples is good? Remember that
varg[0] (the program name) is also good.

Secondly, in reading the DCL Dictionary on the section concerning ":=",
it says that the maximum offset to a DCL string cannot exceed 768.
These strings at their worst size do not exceed 720 in the production
program.

In the examples I have shown, they are significantly shorter than that.

Mike

-----Original Message-----
From: Ken Robinson [mailto: XXXX@XXXXX.COM ]
Sent: Monday, December 03, 2007 3:20 PM
To: XXXX@XXXXX.COM
Subject: Re: FW: Passing large number of arguments to a program

sol gongola < XXXX@XXXXX.COM > wrote in



DCL only allows 8 arguments, the OP is passing the arguments to a C
program. What the OP is probably running into is the maximum lenght of a

DCL line,

Ken
 
 
 

FW: Passing large number of arguments to a program

Post by Farrell, M » Wed, 05 Dec 2007 06:38:47

orry about that,

Hopefully this will be better. If not let me know.

Thanks,

Mike


________________________________________
From: Farrell, Michael
Sent: Monday, December 03, 2007 3:11 PM
To: ' XXXX@XXXXX.COM '
Subject: FW: Passing large number of arguments to a program

One of my programmers wrote a program that receives a huge (embarassingly huge) number of arguments. The program is run through a DCL jacket procedure that develops the arguments and calls the program.

If the number of arguments exceeds 143, not the leading argument, (varg[0]) ,but the following leading arguments get clobbered.
(When 144 arguments are used, arguments 1 and 2 get clobbered.)

The program below is a stub program that shows this condition. There are 4 runs shown here. One for 143 arguments where all is fine, and one each for 144, 156, and 170 arguments where an increasing number of the leading arguments starting with argument 1 gets clobbered. (Note that if you run this you can always see that "varg[0]" is correct, always showing the exact version of the program name being executed.)

Yes, passing a ridiculous number of arguments does bring new meaning to the expression "quick and dirty programming". And yes, there is a better way to do it, and yes, that change is being made now.

But, what went on here? Is DCL involved in this problem? Can someone explain what could be involved?

We are running "HP C V7.1-015 on OpenVMS Alpha V8.3". The original program was linked with a "STACK=200" command in the link options file but I'm not sure if this.

Any insight will be greatly appreciated.

Thanks

Mike

Mike Farrell
VoltDelta Resources, LLC


G> cc test_args.c ! Std "cc" command
G> link test_args ! Std "link" command


Directory $1$DKA100:[XXXX]

TEST_ARGS.C;4 0.50KB/34KB 3-DEC-2007 10:59:41.99
TEST_ARGS.COM;3 1KB/34KB 3-DEC-2007 11:11:17.58
TEST_ARGS.EXE;4 3KB/34KB 3-DEC-2007 10:59:45.10
TEST_ARGS.OBJ;4 2KB/34KB 3-DEC-2007 10:59:43.69

Total of 4 files, 7KB/138KB
G>




G> ty TEST_ARGS.COM
$! TEST_ARGS.COM
$! -------------
$! P1 - number of command line arguments to test
$!
$! This test procedure will generate requested number of command line arguments as "1 2 3 ...", and
$! will attempt to run TEST_ARGS.EXE program while passing all those arguments. The program will attempt
$! to simply print the list of command line arguments.
$!
$ if (f$type(P1) .nes. "INTEGER") then exit 4
$!
$ n = 0
$ args = ""
$ max = P1
$LOOP:
$ n = n + 1
$ if (n .gt. max) then goto FINISH
$ args = args + " ''n'"
$ goto LOOP
$FINISH:
$!
$ prog := $ $1$DKA100:[IGOR.SPB2ASC.REL_058]TEST_ARGS.EXE
$ set verify
$ prog 'args'
$ set noverify
$ exit
G>



G> type TEST_ARGS.c
#include <stdio>

main(int narg, char *varg[]) {
int n;
for (n = 0; n < narg; n++) printf(" Arg %d: %s;", n, varg[n]);
}
G>




G> @test_args 143
$ prog 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 10
 
 
 

FW: Passing large number of arguments to a program

Post by Fred Bac » Wed, 05 Dec 2007 06:41:32

en Robinson wrote:


Ken,

You can get DCL itself to input a long line of arguments,
and then get DCL to parse them itself, without using a C
program. Just make DCL think it is inputting P1 as a quoted
string of text. Then the limit of input is simply the length
of the keyboard buffer.

I found the trick of getting DCL to take long lines of
dictation in my DIARY.com suite. I enter the symbol ADDD
several times a day to make entries into my online work
diary. I use a symbol to point to a DCL command procedure,
but the symbol itself is defined as having a single trailing
double-quote.

SO my ADDDIARY.COM (below) grabs a line of text which can
be several elements long (~254 chars max). Then by using
the lexical function f$element you could dig out each
argument just inputted on the command line.

Here is may ADDD (short for ADDDIARY.COM). NOTE AGAIN:
THE TRICK IS IN HOW YOU DEFINE THE SHORTHAND SYMBOL
FOR THE PROGRAM!!! The symbol must be defined with
a trailing double-quotation mark.





Here is how I define the symbol. ( DEFINE.COM runs
inside LOGIN.COM )



This trialling quote is absolutely essential. Unfortunately,
you do pay a price for this functionality. The entry must not
contain single quotes. If you use a single quote, DCL will
try to translate the word following it as a symbol. If you
use a double-quote in your line of text, then the text
following the double quote comes back in all capitals.


First, an example of the single quote:



Note the 't has no translation, and so isn't comes out as isn .
Note that the 's in Fred's has a translation, and the value
of the symbol "s" is placed in the line to be added to the diary.


Next, the example with a pair of lone double-quotes and text
in the middle:



Note that the phrase Weather was poor came out in all caps.
I haven't experimented with various combinations of double and
single quotes, but I figure that if you know the rules then you
actually could add the text you wanted to the diary.


Here is ADDDIARY.COM. Remember that it expects everything on
the first line to be part of the FIRST argument since the symbol
ends with a trailing lone double-quote.





 
 
 

FW: Passing large number of arguments to a program

Post by JF Meze » Wed, 05 Dec 2007 07:40:37

Suggestion:

Instead of running your program, get the arguments into a single string
and do a F$LENGTH of it.

aka:

chocolate:= "$myprogram.exe"

instead of doing:
$chocolate 1 2 3 4 5 ... 143
do

$vanilla = "1 2 3 4 5 6 ... 143"
$write sys$output "Length of argument list is "''f$length(vanilla)'"

You could also include in that length the actual command.
(either "chocolate" or "$myprogram.exe")
 
 
 

FW: Passing large number of arguments to a program

Post by Jan-Erik S » Wed, 05 Dec 2007 07:47:48

Another (third ?) paramater passing method
I often use (at least by COM files calling other
COM files) is to pass the paramaters by logicals
or symbols. No practical limitations.

Jan-Erik.
 
 
 

FW: Passing large number of arguments to a program

Post by Stephen Ho » Wed, 05 Dec 2007 08:50:11


From the documentation of DCL currently available in the OpenVMS User's
Guide at the HP web site: "Include no more than 127 elements
(parameters, qualifiers, and qualifier values) in each command line."

The associated command length and token size limits were increased in
late V7 and in V8 releases, and that much is documented in the new
features manuals.

I don't know that the maximum number of elements has been changed.
(Based on what you are seeing, it would appear not.)

If this documentation holds -- it's what is currently posted, though
whether or not this documentation is the most current in light of the
DCL changes is another question -- then your programmer's code is
depending on unsupported behavior, and you have an enhancement request
(better error reporting, more elements) and not a bug report. (How HP
might choose to respond to any of this is another and open question.)

Me? I'd alter the code to avoid needing a gazillion parameters. I'd
tend to look to pass in the wad of data required here via a file or via
mailbox or other such approach. (FWIW, DCL has mailbox capabilities in
recent releases with CREATE /MAILBOX and such...) Or at least stuff the
wad you have into 127 or fewer elements.

--
www.HoffmanLabs.com
Services for OpenVMS
 
 
 

FW: Passing large number of arguments to a program

Post by JF Meze » Wed, 05 Dec 2007 10:22:28


Is this applicable to a C program that does a unix-like grabbing of
arguments via argc/argv ?

I can understand this limitaion applying to real DCL (eg: application
doing CLI$PARSE $GET_VALUE etc), but would DCL be involved in parsing
any of the stuff after the command ? Or does the C run time just access
a single long string beyond the command and parse it itself ?
 
 
 

FW: Passing large number of arguments to a program

Post by Richard B. » Wed, 05 Dec 2007 10:44:02


<snip>

You are too kind! I'd fire the *** who wrote the program that
required several hundred arguments!
 
 
 

FW: Passing large number of arguments to a program

Post by David J Da » Wed, 05 Dec 2007 11:52:04


Not. Turn off MIME, and make sure to set your news program to post as
plain text only only.

(embarassingly huge) number of arguments. The program is run through a
DCL jacket procedure that develops the arguments and calls the program.
(varg[0]) ,but the following leading arguments get clobbered.
are 4 runs shown here. One for 143 arguments where all is fine, and
one
each for 144, 156, and 170 arguments where an increasing number of the
leading arguments starting with argument 1 gets clobbered. (Note that
if
you run this you can always see that "varg[0]" is correct, always
showing
the exact version of the program name being executed.)
the expression "quick and dirty programming". And yes, there is a
better
way to do it, and yes, that change is being made now.
explain what could be involved?
program was linked with a "STACK=200" command in the link options file
but I'm not sure if this.

(Long lines manually broken into readable form.)

Have you tried:

$ prog "''args'"

...? That may return a single argument of space-separated elements.
Dunno if your code can handle that.

Please consider redesigning the program to accept a more manageable
argument list, or read them in from a file or some other approach.

This may be a lot of work to discover that the original approach was a
candidate for improvement.

My $0.02...

David J Dachtera
DJE Systems
 
 
 

FW: Passing large number of arguments to a program

Post by Farrell, M » Wed, 05 Dec 2007 22:39:31

Hi Hoff,

Can you supply the section number at least of the OpenVMS user's Guide
where you found the reference cited below? I have been searching the
web site now and getting nowhere in my attempt to find and read it.

TIA,

Mike Farrell

-----Original Message-----
From: Stephen Hoffman [mailto: XXXX@XXXXX.COM ]
Sent: Monday, December 03, 2007 6:50 PM
To: XXXX@XXXXX.COM
Subject: Re: FW: Passing large number of arguments to a program



From the documentation of DCL currently available in the OpenVMS User's

Guide at the HP web site: "Include no more than 127 elements
(parameters, qualifiers, and qualifier values) in each command line."

The associated command length and token size limits were increased in
late V7 and in V8 releases, and that much is documented in the new
features manuals.

I don't know that the maximum number of elements has been changed.
(Based on what you are seeing, it would appear not.)

If this documentation holds -- it's what is currently posted, though
whether or not this documentation is the most current in light of the
DCL changes is another question -- then your programmer's code is
depending on unsupported behavior, and you have an enhancement request
(better error reporting, more elements) and not a bug report. (How HP
might choose to respond to any of this is another and open question.)

Me? I'd alter the code to avoid needing a gazillion parameters. I'd
tend to look to pass in the wad of data required here via a file or via
mailbox or other such approach. (FWIW, DCL has mailbox capabilities in
recent releases with CREATE /MAILBOX and such...) Or at least stuff the

wad you have into 127 or fewer elements.

--
www.HoffmanLabs.com
Services for OpenVMS