Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
"$ SET VERIFY" obsolete
383 views
Skip to first unread message
VAXman-
Apr 21, 2013, 10:55:39 AM4/21/13
to
During last month's OpenVMS Bootcamp, I presented a session titled: D.See.L,
in which I unveiled a DCL debugger. I am now announcing to comp.os.vms that
the "beta test" version of this DCL debugger is being made available to the
denizens of comp.os.vms.
To obtain a copy of this DCL debugger, point your web browser to the domain
of 'tmesis' within the top level domain of 'net' and then, a slash followed
by 'dcl-debugger' and from that URL you will be able to download an instal-
lation kit as well as a temporary PAK to use and test this DCL debugger.
There are some other bits of information available at that URL as well.
Please, review that too.
This DCL debugger will run on OpenVMS VAX V7.0 and up, OpenVMS Alpha V7.0
and up, and on OpenVMS Integrity V8.3 and up.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
in which I unveiled a DCL debugger. I am now announcing to comp.os.vms that
the "beta test" version of this DCL debugger is being made available to the
denizens of comp.os.vms.
To obtain a copy of this DCL debugger, point your web browser to the domain
of 'tmesis' within the top level domain of 'net' and then, a slash followed
by 'dcl-debugger' and from that URL you will be able to download an instal-
lation kit as well as a temporary PAK to use and test this DCL debugger.
There are some other bits of information available at that URL as well.
Please, review that too.
This DCL debugger will run on OpenVMS VAX V7.0 and up, OpenVMS Alpha V7.0
and up, and on OpenVMS Integrity V8.3 and up.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Michael Unger
Apr 21, 2013, 1:34:07 PM4/21/13
to
On 2013-04-21 16:55, "VAXman- @SendSpamHere.ORG" wrote:
> [...]
> [...]
Michael
--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.
> [...]
>
> There are some other bits of information available at that URL as well.
> Please, review that too.
| You don't have permission to access / on this server.
> There are some other bits of information available at that URL as well.
> Please, review that too.
> [...]
Michael
--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.
MG
Apr 21, 2013, 2:08:03 PM4/21/13
to
On 21-apr-2013 19:34, Michael Unger wrote:
> On 2013-04-21 16:55, "VAXman- @SendSpamHere.ORG" wrote:
>
>> [...]
>>
>> There are some other bits of information available at that URL as well.
>> Please, review that too.
>
> | You don't have permission to access / on this server.
>
>> [...]
>
> Michael
>
It worked for me.
> On 2013-04-21 16:55, "VAXman- @SendSpamHere.ORG" wrote:
>
>> [...]
>>
>> There are some other bits of information available at that URL as well.
>> Please, review that too.
>
> | You don't have permission to access / on this server.
>
>> [...]
>
> Michael
>
- MG
Jan-Erik Soderholm
Apr 21, 2013, 3:57:45 PM4/21/13
to
Michael Unger wrote 2013-04-21 19:34:
> On 2013-04-21 16:55, "VAXman- @SendSpamHere.ORG" wrote:
>
>> [...]
>>
>> There are some other bits of information available at that URL as well.
>> Please, review that too.
>
> | You don't have permission to access / on this server.
>
>> [...]
>
> Michael
>
http://tmesis.net/dcl-debugger/
> On 2013-04-21 16:55, "VAXman- @SendSpamHere.ORG" wrote:
>
>> [...]
>>
>> There are some other bits of information available at that URL as well.
>> Please, review that too.
>
> | You don't have permission to access / on this server.
>
>> [...]
>
> Michael
>
works just fine here.
MG
Apr 21, 2013, 4:22:18 PM4/21/13
to
On 21-apr-2013 21:57, Jan-Erik Soderholm wrote:
> http://tmesis.net/dcl-debugger/
>
> works just fine here.
There was perhaps a reason why he didn't want to include the URL
> http://tmesis.net/dcl-debugger/
>
> works just fine here.
in this thread...
- MG
VAXman-
Apr 22, 2013, 7:56:52 AM4/22/13
to
Jan-Erik Soderholm
Apr 22, 2013, 8:22:37 AM4/22/13
to
VAXman- @SendSpamHere.ORG wrote 2013-04-22 13:56:
> In article <kl1gbp$v9j$1...@news.albasani.net>, Jan-Erik Soderholm <jan-erik....@telia.com> writes:
>> Michael Unger wrote 2013-04-21 19:34:
>>> On 2013-04-21 16:55, "VAXman- @SendSpamHere.ORG" wrote:
>>>
>>>> [...]
>>>>
>>>> There are some other bits of information available at that URL as well.
>>>> Please, review that too.
>>>
>>> | You don't have permission to access / on this server.
>>>
>>>> [...]
>>>
>>> Michael
>>>
>>
>> http://tmesis.net/dcl-debugger/
>
> :rolleyes: I was hoping to avoid that being harvested.
>
Sorry.
> In article <kl1gbp$v9j$1...@news.albasani.net>, Jan-Erik Soderholm <jan-erik....@telia.com> writes:
>> Michael Unger wrote 2013-04-21 19:34:
>>> On 2013-04-21 16:55, "VAXman- @SendSpamHere.ORG" wrote:
>>>
>>>> [...]
>>>>
>>>> There are some other bits of information available at that URL as well.
>>>> Please, review that too.
>>>
>>> | You don't have permission to access / on this server.
>>>
>>>> [...]
>>>
>>> Michael
>>>
>>
>> http://tmesis.net/dcl-debugger/
>
> :rolleyes: I was hoping to avoid that being harvested.
>
My guess was that Michael had tried the root URL (that gives
the error he got). But yes, I could have expressed what I
ment verbaly instead of giving the correct URL.
I should have known better, "Security through obscurity" is
what VMS often is accused of, right? :-)
If it's serious, I guess you could change the URL.
Jan-Erik.
VAXman-
Apr 22, 2013, 8:33:12 AM4/22/13
to
from getting the URL only to bang on the site with stupid hacks that will
degrade my bandwidth even more.
George Cornelius
Apr 21, 2013, 10:06:11 PM4/21/13
to
VAXman- @SendSpamHere.ORG wrote:
> It's not so much a security thing as it is just trying to keep harvesters
> from getting the URL only to bang on the site with stupid hacks that will
> degrade my bandwidth even more.
I guess since I don't have a website to protect I don't think about that
> It's not so much a security thing as it is just trying to keep harvesters
> from getting the URL only to bang on the site with stupid hacks that will
> degrade my bandwidth even more.
particular kind of harvesting.
When using Eisner to post to Usenet I have noticed a pattern: you
get a burst of spam a short time after posting, but within a week or
two it drops back down to background levels. Not quite as bad as the
old days, when Usenet was important enough that spammers could buy CD's
with addresses harvested from the newsgroups.
George
VAXman-
Apr 22, 2013, 11:29:21 AM4/22/13
to
is certain to bury the signal in a cesspool of noise. Maybe, I'd have been
better off announcing this debugger to the LinkedIn crowd or on the VMS-sig
mailing list instead of comp.os.vms.
Bill Gunshannon
Apr 22, 2013, 11:39:53 AM4/22/13
to
In article <00AD22D5...@sendspamhere.org>,
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
VAXman- @SendSpamHere.ORG writes:
> In article <517537f6$0$75661$815e...@news.qwest.net>, George Cornelius <gcorn...@charter.net> writes:
>>VAXman- @SendSpamHere.ORG wrote:
>>
>>> It's not so much a security thing as it is just trying to keep harvesters
>>> from getting the URL only to bang on the site with stupid hacks that will
>>> degrade my bandwidth even more.
>>
>>I guess since I don't have a website to protect I don't think about that
>>particular kind of harvesting.
>>
>>When using Eisner to post to Usenet I have noticed a pattern: you
>>get a burst of spam a short time after posting, but within a week or
>>two it drops back down to background levels. Not quite as bad as the
>>old days, when Usenet was important enough that spammers could buy CD's
>>with addresses harvested from the newsgroups.
>
> It's moot now. Besides, this dialog concerning perfidy WRT posting the URL
> is certain to bury the signal in a cesspool of noise. Maybe, I'd have been
> better off announcing this debugger to the LinkedIn crowd or on the VMS-sig
> mailing list instead of comp.os.vms.
You think LinkedIn is safer. Hahahahahahahaha......
> In article <517537f6$0$75661$815e...@news.qwest.net>, George Cornelius <gcorn...@charter.net> writes:
>>VAXman- @SendSpamHere.ORG wrote:
>>
>>> It's not so much a security thing as it is just trying to keep harvesters
>>> from getting the URL only to bang on the site with stupid hacks that will
>>> degrade my bandwidth even more.
>>
>>I guess since I don't have a website to protect I don't think about that
>>particular kind of harvesting.
>>
>>When using Eisner to post to Usenet I have noticed a pattern: you
>>get a burst of spam a short time after posting, but within a week or
>>two it drops back down to background levels. Not quite as bad as the
>>old days, when Usenet was important enough that spammers could buy CD's
>>with addresses harvested from the newsgroups.
>
> It's moot now. Besides, this dialog concerning perfidy WRT posting the URL
> is certain to bury the signal in a cesspool of noise. Maybe, I'd have been
> better off announcing this debugger to the LinkedIn crowd or on the VMS-sig
> mailing list instead of comp.os.vms.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Johnny Billquist
Apr 22, 2013, 11:55:51 AM4/22/13
to
see in there from people probing it for known Unix vulnerabilities. And
it's been going on for almost a year now. No end in sight. Glad I have
enormous bandwidth though...
Johnny
Bill Gunshannon
Apr 22, 2013, 12:11:53 PM4/22/13
to
In article <kl3mi7$a3p$1...@iltempo.update.uu.se>,
I would not be surprised to see people still trying all the old sendmail
vulnerabilities even though I exepct there are very few people still
trying use it today.
vulnerabilities even though I exepct there are very few people still
trying use it today.
VAXman-
Apr 22, 2013, 12:12:27 PM4/22/13
to
In article <atl3u9...@mid.individual.net>, bi...@server1.cs.uofs.edu (Bill Gunshannon) writes:
>In article <00AD22D5...@sendspamhere.org>,
> VAXman- @SendSpamHere.ORG writes:
>In article <00AD22D5...@sendspamhere.org>,
> VAXman- @SendSpamHere.ORG writes:
>> In article <517537f6$0$75661$815e...@news.qwest.net>, George Cornelius <gcorn...@charter.net> writes:
>>>VAXman- @SendSpamHere.ORG wrote:
>>>
>>>> It's not so much a security thing as it is just trying to keep harvesters
>>>> from getting the URL only to bang on the site with stupid hacks that will
>>>> degrade my bandwidth even more.
>>>
>>>I guess since I don't have a website to protect I don't think about that
>>>particular kind of harvesting.
>>>
>>>When using Eisner to post to Usenet I have noticed a pattern: you
>>>get a burst of spam a short time after posting, but within a week or
>>>two it drops back down to background levels. Not quite as bad as the
>>>old days, when Usenet was important enough that spammers could buy CD's
>>>with addresses harvested from the newsgroups.
>>
>> It's moot now. Besides, this dialog concerning perfidy WRT posting the URL
>> is certain to bury the signal in a cesspool of noise. Maybe, I'd have been
>> better off announcing this debugger to the LinkedIn crowd or on the VMS-sig
>> mailing list instead of comp.os.vms.
>
>>>VAXman- @SendSpamHere.ORG wrote:
>>>
>>>> It's not so much a security thing as it is just trying to keep harvesters
>>>> from getting the URL only to bang on the site with stupid hacks that will
>>>> degrade my bandwidth even more.
>>>
>>>I guess since I don't have a website to protect I don't think about that
>>>particular kind of harvesting.
>>>
>>>When using Eisner to post to Usenet I have noticed a pattern: you
>>>get a burst of spam a short time after posting, but within a week or
>>>two it drops back down to background levels. Not quite as bad as the
>>>old days, when Usenet was important enough that spammers could buy CD's
>>>with addresses harvested from the newsgroups.
>>
>> It's moot now. Besides, this dialog concerning perfidy WRT posting the URL
>> is certain to bury the signal in a cesspool of noise. Maybe, I'd have been
>> better off announcing this debugger to the LinkedIn crowd or on the VMS-sig
>> mailing list instead of comp.os.vms.
>
>You think LinkedIn is safer. Hahahahahahahaha......
WHO said anything about safety. However, when it some to S/N ratio, the
LinkedIn forums, save for then Renee hits them, have better figures than
c.o.v. Again, the message is lost...
Simon Clubley
Apr 22, 2013, 12:57:02 PM4/22/13
to
On 2013-04-21, George Cornelius <gcorn...@charter.net> wrote:
>
> When using Eisner to post to Usenet I have noticed a pattern: you
> get a burst of spam a short time after posting, but within a week or
> two it drops back down to background levels. Not quite as bad as the
> old days, when Usenet was important enough that spammers could buy CD's
> with addresses harvested from the newsgroups.
>
There's a reason why I use a email address for a civilization which will
>
> When using Eisner to post to Usenet I have noticed a pattern: you
> get a burst of spam a short time after posting, but within a week or
> two it drops back down to background levels. Not quite as bad as the
> old days, when Usenet was important enough that spammers could buy CD's
> with addresses harvested from the newsgroups.
>
not exist for another ~150 years. :-)
IOW, is there any reason why you cannot anti-spam your posting address ?
Simon,
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
VAXman-
Apr 23, 2013, 9:50:23 AM4/23/13
to
FWIW, The DCL Debugger was originally only Alpha and Itanium. I recently
backported it to VAX. A minor annoyance, introduce in the backport effort,
was discovered. It concerns "injecting" commands into the process running
the command procedure being debugged. I have corrected this and there are
new builds (2013.113) available at: http://tmesis.net/DCL-debugger/
There have been well over 100 downloads of this DCL Debugger. I do hope it
is being tried and tested out. Enjoy!
backported it to VAX. A minor annoyance, introduce in the backport effort,
was discovered. It concerns "injecting" commands into the process running
the command procedure being debugged. I have corrected this and there are
new builds (2013.113) available at: http://tmesis.net/DCL-debugger/
There have been well over 100 downloads of this DCL Debugger. I do hope it
is being tried and tested out. Enjoy!
Bob Koehler
Apr 23, 2013, 11:31:06 AM4/23/13
to
In article <kl3mi7$a3p$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>
> You should see the logs for my RSX system. It is funny how much crap I
> see in there from people probing it for known Unix vulnerabilities. And
> it's been going on for almost a year now. No end in sight. Glad I have
> enormous bandwidth though...
Gee, my VMS system was logging those decades ago. How'd you get so
>
> You should see the logs for my RSX system. It is funny how much crap I
> see in there from people probing it for known Unix vulnerabilities. And
> it's been going on for almost a year now. No end in sight. Glad I have
> enormous bandwidth though...
lucky?
Michael Unger
Apr 23, 2013, 10:52:23 AM4/23/13
to
On 2013-04-22 14:22, "Jan-Erik Soderholm" wrote:
> Sorry.
>
> My guess was that Michael had tried the root URL (that gives
> the error he got). [...]
> Sorry.
>
> My guess was that Michael had tried the root URL (that gives
Yes, because of "[...] There are some other bits of information
available [...]" in [1].
> [...]
Michael
Message-Id <00AD2207...@SendSpamHere.ORG>
Michael Unger
Apr 23, 2013, 10:52:49 AM4/23/13
to
On 2013-04-22 18:57, "Simon Clubley" wrote:
> There's a reason why I use a email address for a civilization which will
> not exist for another ~150 years. :-)
>
> IOW, is there any reason why you cannot anti-spam your posting address ?
There are about two or three mails sent to my "Reply-To:" address from
> There's a reason why I use a email address for a civilization which will
> not exist for another ~150 years. :-)
>
> IOW, is there any reason why you cannot anti-spam your posting address ?
senders commonly called "Nigerians" -- within a quarter. The "From:"
address is simply a spam sink.
MG
Apr 23, 2013, 11:10:04 AM4/23/13
to
On 23-apr-2013 16:52, Michael Unger wrote:
> There are about two or three mails sent to my "Reply-To:" address from
> senders commonly called "Nigerians" -- within a quarter. The "From:"
> address is simply a spam sink.
Maybe HP should outsource VMS Engineering to Nigeria? I mean, at
> There are about two or three mails sent to my "Reply-To:" address from
> senders commonly called "Nigerians" -- within a quarter. The "From:"
> address is simply a spam sink.
least they know how to e-mail and I bet they're even cheaper than
the current 'dream team' miracle workers in India.
- MG
Johnny Billquist
Apr 23, 2013, 12:00:44 PM4/23/13
to
online a year ago.
Johnny
David Froble
Apr 23, 2013, 12:51:12 PM4/23/13
to
VAXman- @SendSpamHere.ORG wrote:
> In article <kl1gbp$v9j$1...@news.albasani.net>, Jan-Erik Soderholm <jan-erik....@telia.com> writes:
>> Michael Unger wrote 2013-04-21 19:34:
>>> On 2013-04-21 16:55, "VAXman- @SendSpamHere.ORG" wrote:
>>>
>>>> [...]
>>>>
>>>> There are some other bits of information available at that URL as well.
>>>> Please, review that too.
>>> | You don't have permission to access / on this server.
>>>
>>>> [...]
>>> Michael
>>>
>> http://tmesis.net/dcl-debugger/
>
> :rolleyes: I was hoping to avoid that being harvested.
>
I caught that, but you can count on some not doing so. Next time be
> In article <kl1gbp$v9j$1...@news.albasani.net>, Jan-Erik Soderholm <jan-erik....@telia.com> writes:
>> Michael Unger wrote 2013-04-21 19:34:
>>> On 2013-04-21 16:55, "VAXman- @SendSpamHere.ORG" wrote:
>>>
>>>> [...]
>>>>
>>>> There are some other bits of information available at that URL as well.
>>>> Please, review that too.
>>> | You don't have permission to access / on this server.
>>>
>>>> [...]
>>> Michael
>>>
>> http://tmesis.net/dcl-debugger/
>
> :rolleyes: I was hoping to avoid that being harvested.
>
explicit, "please do not post the exact URL".
And even that is no guarantee ...
:-)
Saar Klein
Apr 25, 2013, 8:02:56 AM4/25/13
to
You can always use a dedicated dropbox for hosting the files you want, they will get the hits and worst you loose is the files...
Thanks for the debugger! I will give it a try next week
Saar
Thanks for the debugger! I will give it a try next week
Saar
VAXman-
May 12, 2013, 6:51:09 PM5/12/13
to
I'm looking for somebody to give my DCL Debugger a go on OpenVMS VAX V5.4
or V5.5. I have do have two MicroVAX-2000s which could run V5.4 or V5.5,
but I'm not looking forward to installing it and running these if there's
no reason to. All of my other remaining VAX hardware requires newer VMS
versions for support. I also have no interest in configuring SimH unless
there is some issue with the DCL Debugger on these older VMS versions.
If you would like to give the DCL Debugger a whirl on V5.4 or V5.5, let
me know. email: VAXman at the domain tmesis with the top level domain of
dot org.
Thanks.
or V5.5. I have do have two MicroVAX-2000s which could run V5.4 or V5.5,
but I'm not looking forward to installing it and running these if there's
no reason to. All of my other remaining VAX hardware requires newer VMS
versions for support. I also have no interest in configuring SimH unless
there is some issue with the DCL Debugger on these older VMS versions.
If you would like to give the DCL Debugger a whirl on V5.4 or V5.5, let
me know. email: VAXman at the domain tmesis with the top level domain of
dot org.
Thanks.
VAXman-
May 24, 2013, 1:03:59 PM5/24/13
to
FYI, I've made a new DCL Debugger kit available. It has some fixes and
some new features. It's available from the same location I'd posted in
the first entry of this thread <http://tmesis.net/DCL-debugger>
I do hope some of you are using it. There have been over 500 downloads
but I've received very little feedback. What feedback I have gotten has
be very positive and helpful. Thanks.
some new features. It's available from the same location I'd posted in
the first entry of this thread <http://tmesis.net/DCL-debugger>
I do hope some of you are using it. There have been over 500 downloads
but I've received very little feedback. What feedback I have gotten has
be very positive and helpful. Thanks.
VAXman-
Jun 7, 2013, 10:08:15 AM6/7/13
to
Here's hoping that this message doesn't get buried in the morass of all of
these VMS lamentations...
I have put up for download (http://tmesis.net/DCL-Debugger/) the latest of
my DCL Debugger. There are a number of new features, commands and command
qualifiers incorporated into this release thanks to a few of you who have
actually installed and used it.
Because the DCL Debugger was engaged at process creation, the SYLOGIN.COM
and LOGIN.COM were always debugging candidates. One of the newer features
allow the user to bypass the SYLOGIN.COM and or LOGIN.COM, if there is no
need to debug those procedures.
This DCL Debugger is supported on OpenVMS VAX V6.0 and up, OpenVMS Alpha
V6.1 and up and OpenVMS Itanium V8.3 and V8.4. I'll support it on i4 if
HP comes around to their senses. ;)
these VMS lamentations...
I have put up for download (http://tmesis.net/DCL-Debugger/) the latest of
my DCL Debugger. There are a number of new features, commands and command
qualifiers incorporated into this release thanks to a few of you who have
actually installed and used it.
Because the DCL Debugger was engaged at process creation, the SYLOGIN.COM
and LOGIN.COM were always debugging candidates. One of the newer features
allow the user to bypass the SYLOGIN.COM and or LOGIN.COM, if there is no
need to debug those procedures.
This DCL Debugger is supported on OpenVMS VAX V6.0 and up, OpenVMS Alpha
V6.1 and up and OpenVMS Itanium V8.3 and V8.4. I'll support it on i4 if
HP comes around to their senses. ;)
VAXman-
Jul 4, 2013, 12:07:23 PM7/4/13
to
FYI, An updated DCL Debugger is available from http://tmesis.net/DCL-debugger/
Change make to installation to support a unique build for OpenVMS Alpha V7.3-2
which had a few minor symbol differences in DCLDEF.STB making a build against
the DCLDEF.STB from OpenVMS Alpha V7.2 incompatible with OpenVMS Alpha V7.3-2.
Change make to installation to support a unique build for OpenVMS Alpha V7.3-2
which had a few minor symbol differences in DCLDEF.STB making a build against
the DCLDEF.STB from OpenVMS Alpha V7.2 incompatible with OpenVMS Alpha V7.3-2.
VAXman-
Aug 1, 2013, 2:17:02 PM8/1/13
to
The latest beta test of my DCL Debugger is now available for download from:
http://tmesis.net/DCL-debugger/
The VMSINSTAL kit is available as a ZIP archive as well as self-extracting
ZIP archives for VAX, Alpha and Itanium. A new "BETA TEST" PAK has been
created as well, good through 1-Oct.2013.
This release has a number of new features suggested by those who have been
beta testing the DCL Debugger since it was first announced and released.
1. The DCL Debugger's no longer defaults to debugging the SYLOGIN.COM and
LOGIN.COM when the debug session is started. A command line qualifier
"/DEBUG=([NO]SYLOGIN,[NO]LOGIN" has been added to override the default
behavior of NOT debugging these two process initialization procedures.
2. In conjunction with the #1, an internal DCL Debugger command has been
added to permit debugging of the SYLOGIN.COM and LOGIN.COM procedures.
This command is "SET DEBUG/[NO]SYLOGIN/[NO]LOGIN" and it can be places
in the user's DCL Debugger initialization file to establish a personal
preference for debugging these procedures. The command line qualifier
"/DEBUG=([NO]SYLOGIN,[NO]LOGIN" was given preferential control to over-
ride the "SET DEBUG/[NO]SYLOGIN/[NO]LOGIN" command.
3. The "/SPAWN" qualifier has been added to the DCLDBG command. "/SPAWN"
will create a DCL Debugger session that is automatically logged into a
users account as a sub-process; thus, simplifying procedure debugging.
Modeled after the DCL "SPAWN" command, the qualifiers "/[NO]SYMBOLS",
"/[NO]LOGICAL_NAMES" and "/[NO]SYMBOLS" exist with the same meaning as
with the equivalent DCL "SPAWN" command qualifiers.
4. A "/DETACH" qualifier has been added to the DCLDBG command. "/DETACH"
will create a DCL Debugger session that is automatically logged into a
users account without requiring username and password to be provided;
again, simplifying procedure debugging.
5. The DCL Debugger will now recognize terminals configured with greater
than 24 rows.
6. A "/GEOMETRY" qualifier now exists to create the DECterminal with with
greater than 24 rows. DECterminals up to 66 lines can be specified.
7. The DCL Debugger now treats DCL procedure source more akin to the high
level language debugger. GOTO, CALL and GOSUB scans do not display as
if single stepping through the source. IF-THEN-ELSE-ENDIF clauses now
skip over the clause which does not execute. This new default behavior
can be overruled with the new "SET SCAN" command.
8. Nonexecutable lines in DCL procedures will be stepped over. Comments
and blank lines will be treated more like the level language debugger
treats comments and blank lines in source files.
9. A new command qualifier "/NEXT" for the "GO" command will allow users
to continue to the next executable line at the current procedure level
without stepping into a procedure. ie.:
$ {current-line}
$ @procedure
$ {next-line}
The procedure is still executed but the DCL Debugger will not display
its source. Certain breakpoints, if established and encountered while
executing the procedure, will be honored and then, if there is a break-
point in the procedure, its source will be displayed.
10. A new qualifier, "/ENTRY" for "SET BREAKPOINT/FILE=procedure-spec" has
been added. Because the debugger will no longer "step" on comment or
whitespace lines, a "/LINE=#" that is a command will not cause the DCL
debugger to breakpoint. The "/ENTRY" qualifier was added to allow the
equivalent of "SET BREAKPOINT/FILE=procedure-spec/LINE=1" meaning to
breakpoint on the first executable statements encountered upon entry
to a procedure.
There are now several more specific builds for specific versions of OpenVMS
due to incompatibilities with symbolic offsets in DCL. Most of the "bugs"
that were reported were due to the DCL Debugger being built against OpenVMS
versions that were incompatible with the version of OpenVMS where the DCL
Debugger had been installed. There is now an IVP in the DCL Debugger kit
to check for such incompatibilities.
http://tmesis.net/DCL-debugger/
The VMSINSTAL kit is available as a ZIP archive as well as self-extracting
ZIP archives for VAX, Alpha and Itanium. A new "BETA TEST" PAK has been
created as well, good through 1-Oct.2013.
This release has a number of new features suggested by those who have been
beta testing the DCL Debugger since it was first announced and released.
1. The DCL Debugger's no longer defaults to debugging the SYLOGIN.COM and
LOGIN.COM when the debug session is started. A command line qualifier
"/DEBUG=([NO]SYLOGIN,[NO]LOGIN" has been added to override the default
behavior of NOT debugging these two process initialization procedures.
2. In conjunction with the #1, an internal DCL Debugger command has been
added to permit debugging of the SYLOGIN.COM and LOGIN.COM procedures.
This command is "SET DEBUG/[NO]SYLOGIN/[NO]LOGIN" and it can be places
in the user's DCL Debugger initialization file to establish a personal
preference for debugging these procedures. The command line qualifier
"/DEBUG=([NO]SYLOGIN,[NO]LOGIN" was given preferential control to over-
ride the "SET DEBUG/[NO]SYLOGIN/[NO]LOGIN" command.
3. The "/SPAWN" qualifier has been added to the DCLDBG command. "/SPAWN"
will create a DCL Debugger session that is automatically logged into a
users account as a sub-process; thus, simplifying procedure debugging.
Modeled after the DCL "SPAWN" command, the qualifiers "/[NO]SYMBOLS",
"/[NO]LOGICAL_NAMES" and "/[NO]SYMBOLS" exist with the same meaning as
with the equivalent DCL "SPAWN" command qualifiers.
4. A "/DETACH" qualifier has been added to the DCLDBG command. "/DETACH"
will create a DCL Debugger session that is automatically logged into a
users account without requiring username and password to be provided;
again, simplifying procedure debugging.
5. The DCL Debugger will now recognize terminals configured with greater
than 24 rows.
6. A "/GEOMETRY" qualifier now exists to create the DECterminal with with
greater than 24 rows. DECterminals up to 66 lines can be specified.
7. The DCL Debugger now treats DCL procedure source more akin to the high
level language debugger. GOTO, CALL and GOSUB scans do not display as
if single stepping through the source. IF-THEN-ELSE-ENDIF clauses now
skip over the clause which does not execute. This new default behavior
can be overruled with the new "SET SCAN" command.
8. Nonexecutable lines in DCL procedures will be stepped over. Comments
and blank lines will be treated more like the level language debugger
treats comments and blank lines in source files.
9. A new command qualifier "/NEXT" for the "GO" command will allow users
to continue to the next executable line at the current procedure level
without stepping into a procedure. ie.:
$ {current-line}
$ @procedure
$ {next-line}
The procedure is still executed but the DCL Debugger will not display
its source. Certain breakpoints, if established and encountered while
executing the procedure, will be honored and then, if there is a break-
point in the procedure, its source will be displayed.
10. A new qualifier, "/ENTRY" for "SET BREAKPOINT/FILE=procedure-spec" has
been added. Because the debugger will no longer "step" on comment or
whitespace lines, a "/LINE=#" that is a command will not cause the DCL
debugger to breakpoint. The "/ENTRY" qualifier was added to allow the
equivalent of "SET BREAKPOINT/FILE=procedure-spec/LINE=1" meaning to
breakpoint on the first executable statements encountered upon entry
to a procedure.
There are now several more specific builds for specific versions of OpenVMS
due to incompatibilities with symbolic offsets in DCL. Most of the "bugs"
that were reported were due to the DCL Debugger being built against OpenVMS
versions that were incompatible with the version of OpenVMS where the DCL
Debugger had been installed. There is now an IVP in the DCL Debugger kit
to check for such incompatibilities.
0 new messages