CLI$ROUTINES.H

[Antoniov.]

Hi Ram,
I wrote too hurry ...
INVREQTYP ia new status; it means "Calling process did not have a CLI to perform
this function, or the CLI did not support the request".

My code is merely an example. It show you:
1) Using of $DESCRIPTOR macro, instead of using VMS structure;
2) Using of symbolic code instead of numeric codes;

Personally I don't like CLI interface, because is too complex. For my purpose, I sue standard argv and argc parameters.

Antonio Vigliotti

[ram_47]

Maybe even I should use the argc & argv for the command line :)

[Antoniov.]

If you want to use argc & argv, you have to run your application in this way:
$! Define symbolic name of my application
$ MYAPPL="RUN
$! Now I run my appl with parameters
$ MYAPPL PARAM1 PARAM2 ...

Antonio Vigliotti

[Willem Grooters]

Slightly off topic, but I must react on John's remarks.

Sure it's easier to use the Unix-style of parameter passing, and it may mean less overhead. In some cases, I'd agree, and not just in C programs.
But I think I speak for a lot of people when I disagree:

A. VMS <> UNIX.
B. In a DCL-style interface, options are NAMED, not just an abitrary letter that could mean anything. /EXECUTE is clearer the -e, or, even worse, -E
C. When well done, a lot of validity checking is done during image activation (by DCL!). /EXECUTE= where is required will immediately signal an error when it's missing. -e would be checked by the program itself - when already activated.

I would prefer to avoid image activation when options and required parameters are missing, in stead of activating it anyway and then finding the parameters don't mix.
At lkeast, the error messages are standard VMS so tell me what's wrong, where an activated image can spit out rubbish that doesn't tell anything at all. (well, it can deliver the right message but quite likely, that will not be done).

There are enough examples, formerly from Unix, both commercial and freeware, that use the Unix-style interface where a DCL-style interface would be much, much more appropiate: HP TCPIP, Apache, SSL, Java, and MySQL, to name a few (The ones I have experience with).

[ram_47]

I get an error -
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=010E0009,
PC=0001B78D, PSL=03C00020
break on unhandled exception at SHARE$LIBRTL+106893


how did you conclude that it was this stmt 'status = CLI$PRESENT(entity);' which was causing the problem? Am just curious...

[Jan van den Ende]

@Willem:


B. In a DCL-style interface, options are NAMED, not just an abitrary letter that could mean anything. /EXECUTE is clearer the -e, or, even worse, -E


Willem,
even YOU give them *NIXians too much credit!
About 1 in 5 will probably already have some other meaning for -e, (or the author has some private conventions) and so they choose - x for eXecute), -P ( = Perform ) or -d ( = Do ), or (use your imagination). Of course, randomly choose upper- or lower case.

Proost.

Have one on me.

jpe

[Volker Halle]

Ram,

I ran your program with the debugger until it failed with ACCVIO. Then I did a

DBG> SHOW CALL

module name routine name line rel PC abs PC
*STR$ANALYZE_SDESC
str$analyze_sdesc
4358 0000000000000300 0000000000030AA0
----- the above looks like a null frame in the same scope as the frame below
000000000002031C 000000000003031C
*ITRC_944542 main 22134 0000000000000124 0000000000030124
*ITRC_944542 __main 000000000000009C 000000000003009C
FFFFFFFF8031DFFC FFFFFFFF8031DFFC

Then I looked at the first routine call inside your program:

DBG> set scope ITRC_944542
DBG> ty 22134
module ITRC_944542
22134: status = CLI$PRESENT(entity);

Easy, isn't it ;-)

Volker.

[Galen Tackett]

Willem and others,

This too is a bit o.t. but here goes...

Willem wrote:

There are enough examples, formerly from Unix, both commercial and freeware, that use the Unix-style interface where a DCL-style interface would be much, much more appropiate: HP TCPIP, Apache, SSL, Java, and MySQL, to name a few (The ones I have experience with).


There's also at least one example of a program that impressively handles both DCL and Unix style command lines. It's GAWK. Best of all, it's free.

Galen

[Galen Tackett]

I wrote some simple jacket routines that ease the interface from C to the CLI$ routines. Here's a snip:


#pragma inline(cli_present)

unsigned cli_present(char *s) {
$DESCRIPTOR1(s_desc, s);

return cli$present(&s_desc);
}


So I don't have to deal with manually creating a descriptor every time I want to do this.

There's also a cli_get_value() that uses LIB$SGET1_DD() to dynamically allocate storage for the string returned by CLI$GET_VALUE() and then copies that string to a user buffer(with null termination) using LIB$MOVC3(). (Hey, I just noticed a small memory leak in my code. The dynamically allocated storage never gets freed!-)

cli_parse() is another jacket routine that wraps LIB$GET_FOREIGN(), CLI$DCL_PARSE(), and CLI$DISPATCH() in one neat package.

Despite some limitations (like the memory leak :-), I've found them usable enough for a number of small applications I've written.

Here at work this all lives on a system with no Internet connections or removable media so I can't easily attach it (security rules.) And I'd probably make too many typos if I tried to transcribe it.

I have an older version of it at home and perhaps will remember to post it here or elsewhere.

(Side note: the version at home is stored in a VMS disk image on my Mac OS X system. I'll have to boot up my copy of simh running VMS to retrieve it, unless someone has an OS X tool to read VMS disk images!)

[Willem Grooters]

@Jan

Me, giving credit to Unixionians? No way:
-d, -e, -p, -x (or their uppercase counterparts) can all be used where in VMS /EXECUTE might be used. This is just one example. And I know it's even worse:
In another context, -d may mean /DISPLAY or /DESCENDING, -e could mean /EXTENDED, /EXTERNAL or /ERROR; read /PRINT or /PREFIX for p, and -x may be translated to /EXTERNAL, or, what I've seen /DEBUG or /VERBOSE.
And: case matters. Sometimes the uppercase version is a more expanded version of the lowercase one. Sometimes it's the opposite. Somethimes it's something completely different. Sometimes, the counterpart doesn't even exist.

No credit for Unixonians. Nor for OpenVMS engineering that seems to persuade it's clients to use the very same rubbish, no matter where it comes from: from within HP (Tru64's TCPIP stack!) or OpenSource (Apache, SSL). Porting is more than just getting code compiled and linked. It also means that the code is adapted to comply with the OS's standards and methods.

New users like ram take the challenge to master "the VMS way of doing things". This should be encouraged and supported. Not just by this community but by HP as well.

[Martin Vorlaender]

>>>
Porting is more than just getting code compiled and linked. It also means that the code is adapted to comply with the OS's standards and methods.
<<<

A very good resource that has all the VMS programming aspects is "How to Write a Native VMS Command": http://members.fortunecity.com/twirlip/vms_command.html

cu,
Martin

[Jan van den Ende]

New users like ram take the challenge to master "the VMS way of doing things". This should be encouraged and supported


Oh yes! Absolutely.

ram, take this as encouragement, it IS intended to!
And we are here to help you with it.

Proost.

Have one on me.

jpe

[Brian Reiter]

Ok sorry it so off topic - the appeal of OpenVMS is its conistency in its approach, especially in DCL - no need to remember various switches across commands etc., the system service interface and so on. These tend to impress unix and windows folks.

Martin - thanks for that link, now if only I could award you points. :)

cheers

Brian

[Antoniov.]

Martin,
your linked web site is fantastic.
Ram carefully at that page because it can help you.

Antonio Vigliotti

[ram_47]

Martin-

The website is great. Thanks again.