- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: DCL anomaly
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 05:32 AM
тАО02-25-2008 05:32 AM
Re: DCL anomaly
He must have been responding to your first suggestion of
Just use
"This is " + bagger
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 06:17 AM
тАО02-25-2008 06:17 AM
Re: DCL anomaly
$ lInstantie = "VO85A"
...
$ OutString = "This is version ''lInstatie'"
Mind the missing "n" in the second line....
In large, and/or dense DCL code, such a typo is very easily overlooked - it took some time before it was found: by accident!
Of course - defensive programming would require the use of F$STRING or other methods to be sure symbols were properly defined. But what programmer would use it for symbols defined, prepared and used internally only?
("Dicipline, MR. G, is the answer to your question". I know :D) but I still would like some help by DCL)
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 01:14 PM
тАО02-25-2008 01:14 PM
Re: DCL anomaly
See OpenVMS User's Manual, Section "12.13.5 Undefined Symbols". It's true of all versions of OpenVMS past and will remain so in all future versions (so get used to it!).
I'd expect any serious DCL programmer to be very familiar with all of Chapter 12 "Defining Symbols, Commands, and Expressions" and especially Sections "12.12 Understanding Symbol Substitution" and "12.13 The Three Phases of Command Processing".
There are many uses for this behaviour, the simplest being implementing flags with symbol existence:
$ IF "''flag'".NES."" THEN ...
This will be FALSE if the symbol is undefined or null and TRUE if non-null.
Another use is for code paths where you can accept a preexisting value, or define a default without having to code an explicit test for existence:
$ IF "''outfile'".EQS."" THEN outfile="DEFAULT.DAT"
A less obvious mechanism is to avoid to initialising a loop variable. This is especially useful to reduce the number of labels required for loops in subroutines.
For example:
$ mysub:
$ item=F$ELEMENT('c'+0,delim,string)
$ ... do something with item
$ c='c'+1
$ IF c.LTS.limit THEN GOTO mysub
$ RETURN
A somewhat contrived example, and a bit dangerous because you don't know the value of c at the start. Perhaps a better example is a self initialising mechanism for generating F$SEARCH stream IDs to guarantee streams are unique across the process:
$ ssid=='ssid'+1
$ loop1: f1=F$SEARCH(filespec,ssid)
(note global symbol definition).
Since DCL is interpretive, minimising labels and eliminating additional checks or commands can improve performance.
There are many options for symbol substitution in DCL. See section 12.12 referenced above. To write good quality, defensive code, you need to be especially careful what mechanism you choose in a particular context. In general, it's usually safer to write:
$ s="quoted string" + symbol
than
$ s="quoted string ''symbol'"
UNLESS you want the code to substitute a null if
$ symbol=""""
$ s="quoted string ''symbol' xxx"
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
\XXX\
$ s="quoted string" + symbol + "xxx"
$ show sym s
S = "quoted string"xxx"
In most languages, the architect has carefully chosen and documented rules. Most of them have very good reasons for existing, especially in a language as mature as DCL. In general, rules have good points and bad points (and which is which can vary depending on circumstance). DCL is no exception. The secret is to understand and exploit language rules to your advantage, rather than work against them and complain.
Please make sure you've familiarised yourself with the language definition before claiming a bug or anomoly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-27-2008 02:57 AM
тАО02-27-2008 02:57 AM
Re: DCL anomaly
I know it all (well, most). I don't doubt the intentions, and sure, it will have a reason. Nevertheless, the absence of detection of undefined symbols in some string assignments compared to other contexts is different, no matter it's intentional and well documented - hence "Anomaly". It doesn't mean it's wrong or bad. At least, it is documented. That's good.
The consequence however is that a simple typo in symbol name may now go undetected, so will an now symbol that would normally be defined that is - for some reason) undefined - causing a whole set of applications fail to start or run properly, and finding out what causes it can be a hell of a job, if possible at all. Not just in development of test - it can happen in a production environment as well.
Therefore, it would be a nice thing that undefined symbols were signalled in these assignments - on request only, of course.
Alas, DCL lacks that ability, built in many, if not all compilers.
One should just be aware. (and hopefully, there will be such facility some day :))
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-27-2008 04:15 AM
тАО02-27-2008 04:15 AM
Re: DCL anomaly
If you have ever worked with a Cisco router, they have debug built in for all kinds of things, for example, if you use the commands: (NOTE WELL don├в t do this on a production router unless you know what you are doing! It is show here as an example of how cisco debug output looks, as a one possible way DCL substitution tracing could be handled, although with 8K symbols, it could be quite verbose :-)
# term mon
# debug ip nat detailed
IP NAT detailed debugging is on
3w6d: NAT*: i: tcp (172.30.205.81, 2283) -> (192.168.122.22, 23) [14207]
3w6d: NAT*: s=172.30.205.81, d=192.168.122.22->192.168.221.22 [14207]
3w6d: NAT*: o: tcp (192.168.221.22, 23) -> (172.30.205.81, 2283) [20258]
3w6d: NAT*: s=192.168.221.22->192.168.122.22, d=172.30.205.81 [20258]
#undeb all
All possible debugging has been turned off
#
You will see the address translations in action; before and after they are applied to source and destination addresses. It is similar in output to what set watch file produces.
And although these are substitutions are documented, I am not as sure as John G that they were all intentional behaviors, there are some extremely bizarre interactions. Can they be exploited? Possibly. Should the default behavior change? No. I am quite sure if it was being redone as a clean slate project, it would be done differently.
Unfortunately, I don't think much will change in DCL, at least not at the low level. If you have ever looked at the code written by D Cutler in Macro, it is not easy to follow for someone that isn't very familiar with Macro.
Perhaps Guy will chime in. His name is sprinkled through the source.
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-27-2008 01:42 PM
тАО02-27-2008 01:42 PM
Re: DCL anomaly
> I am quite sure if it was being redone
>as a clean slate project, it would be done
>differently.
I beg to differ. This behaviour is definitely deliberate. There are numerous things that can be done with the existing implementation that could not be done in a strict "IMPLICIT NONE" type environment. Understanding the rules, you can decide at the time you make a reference to a symbol which behaviour you want.
If you're worried about typos use 3rd phase references (always fail) rather than first phase (substitute null string). It's always possible to choose, for example, use concatenation rather than substitution. Alternatively, use F$FAO to format strings, rather than quoted strings with double apostrophe substitution of symbols.
DCL is interpreted and very loosely typed. This has advantages and disadvantages. One of the disadvantages is the lack of debugging tools - many of the debugging techniques of compiled languages simply aren't possible. For example, no compiler could check for definitions of symbols referred to like this:
$ P'i'=P'i'+1
Back in early V5 days there was some support added in DCL to make it stricter, as a debugging aid (for example, forcing all verbs and qualifers to be spelled out completely). There are remnants which can still be accessed today, but they no longer work. I believe the project was dropped because it broke far too many things to be useful.
If you want stronger typing, there are plenty of other languages available, both compiled and interpreted.
Lamenting that langage X isn't like language Y is only productive if a change to "fix" the complaint is peripheral enough to be made without serious consequences. In this case we're talking about fundamental behaviour of a foundation object within the language. That this question was asked at all indicates a misunderstanding of the documented rules.
>Perhaps Guy will chime in. His name is
>sprinkled through the source.
No disrespect to my good friend Guy, but I think you'll find most of the fundamental design decisions in DCL were made before he was born!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-29-2008 05:42 AM
тАО02-29-2008 05:42 AM
Re: DCL anomaly
[quote]
Lamenting that langage X isn't like language Y is only productive if a change to "fix" the complaint is peripheral enough to be made without serious consequences.
[/quote]
You missed my point. This is NOT a lamentation on shortcomings of DCL. I just signalled a situation where this behaviour can cause a problem, potentially UNNOTICED until damage is done:
$ P'i'= P'i'+1
Where P is already defined as a symbol and i is undefined, P's value will be 1 after execution of the assignment.
UNNOTICED is the keyword in this.
It would only be a nice thing if DCL would have a facility to signal undefined symbols in these assignement, _on_specific_request_, of course, so exsiting DCL code would not break.
OpenVMS Developer & System Manager
- « Previous
-
- 1
- 2
- Next »