!AD in F$FAO

[John Gillings]

Uwe,

Questions about F$TYPE

This is exactly what I meant about DCL being polymorphic. DCL will sometimes treat your symbol A as a string, and sometimes as an integer.

The doc for F$TYPE says:

"Returns the data type of a symbol. The string INTEGER is returned if the symbol is equated to an integer, or if the symbol is equated to a string whose characters for a valid integer.

The string STRING is returned if the symbol is equated to a character string whos characters do not form a valid integer"

So, that means F$TYPE is of no use in determining how F$FAO will treat the symbol, sorry! :-(

Consider:

$ a="12"
$ b=a+a
$ s=F$FAO("!UL",a)

in these cases A is treated as a string. On the other hand:

$ s=F$FAO("!UL",'a')

"works", because DCL has interpreted the value of A as INTEGER

Hein is correct that most cases where this trick is used represent "holes" in DCL, but anything left over are cases where someone insists on using DCL where a "real" programming language would be more appropriate.

[John Gillings]

Jan,

> I have difficulty trying to devise a way of breaking it, "on purpose or unintentionally".

That's easy! Someone could decide that the ability to read arbitrary addresses is a potential security risk and decide to filter the FAO control string. Simplest implementation would be to search for the "nonsensical" directives and refuse to call SYS$FAO if any were found.

Another, less likely possibility, would be to completely reimplement F$FAO, not just call the system service. DCL could then attempt to "do what you mean" with directives in the control string, so perhaps !AD could look at the size argument and extract that many characters from the string argument. As I said, unlikely as it would be lots of work for very little apparent return, BUT, as long as the DOCUMENTED behaviour for F$FAO didn't change, it would be fair game!

If engineering wanted users to be able to be able to read arbitrary addresses, the obvious implementation would be a new lexical function (say):

$ contents=F$PEEK(address)

where "contents" is set to the 32 bit value at the specified address. (I'll bet Guy could knock that together in a few minutes).

It's easy enough to do, but some would argue that it's inappropriate use of DCL. That this capability hasn't been implemented, or even requested, in over 25 years suggests that it's not really necessary.

Hein has mentioned the rarely used EXAMINE command, but I've never been able to do anything interesting with it.

[Peter Hofman]

Funny, this discussion has just lead to documenting (part of) this stuff :-)

[Willem Grooters]

I prefer to keep DCL-procedures as simple as possible. If !AS will just do what is expected - put some symbol in a string - that is enough. All extra code is an burdon in maintenance, and especially when the code is to be maintained by others than the original author. When you're used to the VMS-style of parameter passing (thanks for the explanation, John (Jan, hij verdient zijn punten!)) this extra code is obvious and easy to follow. However, you can imagine yourself what would happen if someone is to maintain this code without this knowledge.
Second - what is the benefit of using the explicitly unsupported codes?
Third - DCL is NOT! a programming language, though I know it can be abused that way. It's intended use (interface to the OS)justifies the limitations.

[Jan van den Ende]

John,
Hein is correct that most cases where this trick is used represent "holes" in DCL, but anything left over are cases where someone insists on using DCL where a "real" programming language would be more appropriate.
/quote>

I have a tendency to agree with both.
Yes, a compiled language is "more appropriate", but still, I agree with Hein that it can be considered a "hole" that something can not be done with DCL. And, in my view, "appropiateness" is a relative concept!
I have a (certainly not fully black<->white) tendency to consider compiled languages the right choice for applications, where my gut feelings favour DCL for system manager stuff, like various bootstrap (take that VERY loosely) routines.
I tend to take those from site to site, and a given compiler is certainly not guaranteed at each site.


Simplest implementation would be to search for the "nonsensical" directives and refuse to call SYS$FAO if any were found.

that would break F$FAO and SYS$FAO in the same way, so that does not break the parity in behavior.


... to completely reimplement F$FAO ...

Which would surely imply an eqully complete reimplementation of the documentation.

And, if the past may be considered any guide to the future, VMS Engeneering __DOES HAVE__ a fantastic track record for going to great lengts to __NOT__ break old behavior as side-effect of changes/new features!
I would _EXPECT_ a total redesign to carry a slightly different name, and FAO declared obsolete.
Like the various $LOGICAL things were declared obsolete, and replaced by $TRNLNM, at the intro of VMS V4 (yes, back in 1983 or 1984). I still trip over them, even in MUCH newer stuff by DEC/COMPAQ/HP.
And I DO mean "trip over", because we make as much use as possible of dedicated LNM-tables, entries of which are NOT found by $LOGICAL & friends.


... or even requested, in over 25 years suggests that it's not really necessary.

Touche

Peter:

Funny, this discussion has just lead to documenting (part of) this stuff :-)

And now for the big thing: get this documentation available where it is likely to be found! If you did not stumble over this thread, it would be far away to SUPPOSE there MIGHT be something, and then compose a set of search engine arguments that would bring up THIS thread!

Willem:

and especially when the code is to be maintained by others than the original author.

Agree. I would be somewhat more forgiving, but it definitely can only be maintained only by the more-experienced DCL gurus, and being undocumented just raises that bar by quite a distance!


DCL is NOT! a programming language, though I know it can be abused that way.

Define "Programming language".
DCL allows specifying a sequence of instructions in a formalised syntax to be executed by a processing unit, and in __MY__ definition that constitutes a programming language. Opinions thereoff can vary of course.


(Jan, hij verdient zijn punten!)

translates as: He DOES deserve his points!
You will notice I used his next replies to boost his totals in this thread.

Cheers.

Have one on me.

Jan

[Lawrence Czlapinski]

Jan, I agree with you that system manager stuff should be done in DCL.
1. A system manager is expected to know DCL. 2. A replacement system manager may not know the langauge another system manager picked. Be kind to your successors.
3. Language might become UNSUPPORTED by vendor. [Not enough customers to warrant continued support.] A complied language version could become unsupported by the vendor in the future. An unsupported version might not be a problem till someone has to change it in the future.
4. Customer might SWITCH APPLICATION LANGUAGES. The customer may not be aware of these language usages. The customer may port or even rewrite applications to a different language in the future.
Ex 1: Customer might replace FORTRAN with C (or C++) for instance.
Ex 2: Customer [US Department of Defense]
requires new programs to be in a new language, ADA. Didn't last.
5. LOSE LANGUAGE LICENSE: The customer might move the applications that use the language to a different system.
6. The complied language might exist on the system at some future time if the applications get ported to some new language.
7. The system might be replaced and redeployed without the compiled LANGUAGE.
8. Murphy's Law "If anything can go wrong, it will." If anything can go wrong, it "might".
9. There aren't many programmers left for the language. A programmer for that language isn't available or affordable.
10. The cost of programmers for that language has become too expensive.
11. Language is no longer taught in most colleges/universities. FORTRAN, for instance, isn't taught any more in many colleges/universities.
12. Most programmers don't learn the language that was used. [FORTRAN, ADA or whatever]
13. The cost of a programmer in the language becomes unaffordable for the company. Fine, till code needs to be changed.
14. Some other reason that isn't on this list. [It wasn't even thought of, but it went wrong anyway.]
Lawrence

[Cass Witkowski]

I love reading forum because you learn something new every day. I didn't know about the examine command or forgot it a long time ago. From a DCL programming stand point it's not very useful since you can't easily assign the output to a symbol. (Of course now that I said this someone will prove me wrong) :)

What I find facsinating is the new thinking that this conversation stream opens up. What if you could peek values from memory. Maybe you would need the same privs to do that as you would need to do the analyze/system command. What if you could peek using a symbol? Would that be useful.

If it was readily available could you see some programs to check the status of certain things.

What I like about the DCL programming language is the immediacy of results. Having to compile and link slows down the creativity process

I myself would like to see DCL have a symbol type of datetime. I would love to be able to do simple time comparisions between two dates. Or add a delta time to an absolute.

[Jan van den Ende]

Cass,

Starting with your last question first, because that is easiest:

$ abs_time = f$file("xyz","CDT") ! any timespec
$ delta = "300-12:0:0" !any-valid-deltatime
$ newtime = f$cvtime("''abs_time' + ''delta'")
$ show symbol newtime.

Difference between two abs. times?
-- Coming to this theatre soon! One of the many fantastic new features by Guy Peleg.

Some of your other functionality is probably more redily available (again: coming soon, by Guy Peleg) by way of DCL$CTRLT
Check out:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=761205

I have in this forum already seen quite ingeneous ways of PIPEing to get (a.o.) SDA output.

But, that said:

YES!!!! wouldn't it be GREAT to be able to have SDA values into DCL symbols!

Guy Peleg, still seeking suggestions for new goodies?

Proost.

Have one on me.

Jan

[John Gillings]

Cass,

F$DELTA is in V7.3-2, but in the mean time it is possible to calculate a delta time by successive approximation (see attched DCL procedure)

[John Gillings]

Jan,

You can read any USER READ location in system space, which includes most of the things you can read from SDA. All that's needed is to find the value for the symbol.

Attached is an insane DCL procedure to define a global DCL symbol to the SDA symbol value. Example:

$ DEFSYM EXE$GQ_BOOTTIME

Global symbol EXE$GQ_BOOTTIME will be set to the value of the system symbol. Note I don't recommend this for production use - the overheads are just plain stupid!