Do we need a DCL debugger?
Guy Peleg
The DCL engineering team is currently evaluating new features to be
added in future version of VMS (post V7.3-2).
We were wondering if folks think that developing a DCL debugger will be
useful. It won't be as sophisticated
as the VMS debugger, I was thinking about implementing step,examine and
set break.
Please post a reply with your comments or send me mail.
Thanks in advance,
Guy Peleg
OpenVMS Engineering
** Please note that this note is no commitment for actually developing a
DCL debugger, this is only a survey that will not
necessarily result in actual product.....
Bradford J. Hamilton
!
!The DCL engineering team is currently evaluating new features to be
!added in future version of VMS (post V7.3-2).
!
!We were wondering if folks think that developing a DCL debugger will be
!useful. It won't be as sophisticated
!as the VMS debugger, I was thinking about implementing step,examine and
!set break.
!
!Please post a reply with your comments or send me mail.
!
!Thanks in advance,
!
!Guy Peleg
!OpenVMS Engineering
!
!** Please note that this note is no commitment for actually developing a
!DCL debugger, this is only a survey that will not
!necessarily result in actual product.....
!
Guy,
I would find this feature very useful - please consider adding it in a future
version.
!
__________________________________________________________________________
Bradford J. Hamilton "All opinions are my own"
bMradAhamiPltSon-at-coMmcAast.nPeSt "Lose the MAPS, and replace '-at-'
with @"
Larry Kilgallen
> The DCL engineering team is currently evaluating new features to be
> added in future version of VMS (post V7.3-2).
>
> We were wondering if folks think that developing a DCL debugger will be
> useful. It won't be as sophisticated
> as the VMS debugger, I was thinking about implementing step,examine and
> set break.
This would have the disadvantage of encouraging people to write DCL when
a compiled language should have been used. But then I remember what most
people choose for a compiled language and think it does not matter that
much that they "program" in DCL. Plus, using an interpreted language
helps sell VMS licenses for more and larger machines, so I vote yes :-)
Of the features you list, I think SET BREAK is most important,
particular SET BREAK WHEN (my_iterator .EQ. 639486536), or whatever
other weird value I keep ending up with.
Ken Robinson
>
> The DCL engineering team is currently evaluating new features to be
> added in future version of VMS (post V7.3-2).
>
> We were wondering if folks think that developing a DCL debugger will
> be useful. It won't be as sophisticated
> as the VMS debugger, I was thinking about implementing step,examine
> and set break.
I think that this is a very good idea. With it, I wouldn't need to keep
re-inventing the wheel with each procedure.
Other suggestions for DCL ... (I know you didn't ask, but why not :-) )
1) a for loop construct
2) a switch construct
3) more that 8 parameters
Probably others...
Ken Robinson
Phillip Helbig
> added in future version of VMS (post V7.3-2).
>
> We were wondering if folks think that developing a DCL debugger will be
> useful. It won't be as sophisticated
> as the VMS debugger, I was thinking about implementing step,examine and
> set break.
>
It would be nice to have.
However, your resources are not unlimited. I think that there are
higher-priority items which need to be tackled. I would prefer to have
no DCL debugger IF this means that more resources could be invested in,
say, improving VMS MAIL, improving TCPIP (not so much the features as a)
the command-line interface and b) the on-disk organisation of the files)
etc.
I think most folks don't know what your internal budgeting and
work-distribution policies are, so it's difficult for us to see if
saving resources somewhere would free them up elsewhere etc.
Tom Linden
I would like to see symbolic links.
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003
Guy Peleg
I'm currently in coding stage of a WHILE. Hopefully you may use it instead
of FOR.
CASE statement is next on my plate......
Guy
John Brandon
> added in future version of VMS (post V7.3-2).
>
> We were wondering if folks think that developing a DCL debugger will be
> useful. It won't be as sophisticated
> as the VMS debugger, I was thinking about implementing step,examine and
> set break.
>
DCL Debug? I thought there already was one - or is that just a SYNTAX checker?
Regardless, I have had no real issues debugging DCL scripts.
I would prefer a DCL compiler. I remember that there was a DCL to FORTRAN
converter and I believe I have test-software for that but have not used it.
I did encounter a product on OS/2 called REX (?) - it was intelligent enough to
pre-compile itself and run. If no changes were made since the last compilation
it would run the current compilation.
J*o*h*n B*r*a*n*d*o*n
VMS Systems Administrator
firstname.lastn...@dalsemi.com
Michael Unger
> Hi Ken,
>
> I'm currently in coding stage of a WHILE. Hopefully you may use it instead
> of FOR.
> CASE statement is next on my plate......
"CASE" in conjunction with a "DEFAULT" or "OTHERWISE" option to catch
all the conditions not explicitely thought of?
Michael
--
Real names enhance the probability of getting real answers.
Please do *not* send "Security Patch Notifications" or "Security
Updates"; this system isn't running a Micro$oft operating system.
And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)
Phillip Helbig
> > of FOR.
> > CASE statement is next on my plate......
>
> "CASE" in conjunction with a "DEFAULT" or "OTHERWISE" option to catch
> all the conditions not explicitely thought of?
I STRONGLY recommend modelling the control structures on FORTRAN95 and
not repeating the mistakes made in other languages.
Tom Linden
>-----Original Message-----
>From: Michael Unger [mailto:un...@decus.de]
>Sent: Wednesday, September 03, 2003 6:40 AM
>To: Info...@Mvb.Saic.Com
>Subject: Re: Do we need a DCL debugger?
>
>
>On 2003-09-03 15:31, "Guy Peleg" wrote:
>
>> Hi Ken,
>>
>> I'm currently in coding stage of a WHILE. Hopefully you may use
>it instead
>> of FOR.
>> CASE statement is next on my plate......
>
>"CASE" in conjunction with a "DEFAULT" or "OTHERWISE" option to catch
>all the conditions not explicitely thought of?
Guy, since you are working on the parser you could support both the
C and the PL/I like syntax with little effort, this would make it more
REXX like. Besides SELECT ... WHEN ... OTHERWISE is a lot more powerful
with the ALL and ANY options, (and reads better)
Of course, Larry's comment that you are making DCL a surrogate for a
compiled language is valid, as is his comment that it may be preferrable
to that used by many
>
>Michael
>
>--
>Real names enhance the probability of getting real answers.
>Please do *not* send "Security Patch Notifications" or "Security
>Updates"; this system isn't running a Micro$oft operating system.
>And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)
>
Tom Linden
>-----Original Message-----
>From: John Brandon [mailto:bra...@dalsemi.com]
>Sent: Wednesday, September 03, 2003 6:40 AM
>To: Info...@Mvb.Saic.Com
>Subject: Re: Do we need a DCL debugger?
>
>
REXX developed by Colishaw at IBM Hursley Labs UK
>
>
>
>J*o*h*n B*r*a*n*d*o*n
>VMS Systems Administrator
>firstname.lastn...@dalsemi.com
>
Larry Kilgallen
> Other suggestions for DCL ... (I know you didn't ask, but why not :-) )
>
> 1) a for loop construct
> 2) a switch construct
Presuming you mean a "case" statement, I use "computed GOTOs" for that.
Syltrem
often.
Most of the time for a long procedure, I do a SET VERIFY and a
/OUTPUT=X.LOG, then I can go through the steps in the text editor, and add
some SHOW SYMBOL where required. That's often quicker than executing step by
step.
But there are cases where it would really come handy so I vote YES.
OTOH, I don't see the point for FOR and WHILE or UNTIL loops, that can
easily be made with GOTOs, as DCL should not be considered a language for
creating real applications and thus does not absolutely need all those
constructs.
Thanks
--
Syltrem
OpenVMS 7.3-1 + Oracle 8.1.7.4
http://pages.infinit.net/syltrem (OpenVMS related web site, en français)
---zulu is not in my email address---
"Guy Peleg" <guy....@hp.com> a écrit dans le message de
news:3F55DAA1...@hp.com...
dav...@alpha2.mdx.ac.uk
>added in future version of VMS (post V7.3-2).
>
>We were wondering if folks think that developing a DCL debugger will be
>useful. It won't be as sophisticated
>as the VMS debugger, I was thinking about implementing step,examine and
>set break.
>
I'd rather you improved the control structures in DCL ie
For loop
While
Case statement
and added support for floating point arithmetic.
That's assuming those aren't in V7.3-2 :)
David Webb
VMS and Unix Team leader
CCSS
Middlesex University
Chris Sharman
That works, but you can't do the default/otherwise: the error is
unrecoverable. I have to check with:
$ search 'f$env("procedure")' switch_'value':
$ if ($severity.eq.1) then $ goto switch_'value'
(and that's not fireproof if the label is inside a subroutine, or
there's some similar problem)
Chris
Jean-Luc
--
Jean-Luc RAYON
Système & Réseaux
La Couronne C.E.P.A.P
B.P. 14
16400 La Couronne
http://www.lacouronne.com
"Guy Peleg" <guy....@hp.com> a écrit dans le message de news:
3F55DAA1...@hp.com...
>
> The DCL engineering team is currently evaluating new features to be
> added in future version of VMS (post V7.3-2).
...
> Please post a reply with your comments or send me mail.
>
Keith A. Lewis
>
>The DCL engineering team is currently evaluating new features to be
>added in future version of VMS (post V7.3-2).
>
>We were wondering if folks think that developing a DCL debugger will be
>useful. It won't be as sophisticated
>as the VMS debugger, I was thinking about implementing step,examine and
>set break.
I've usually found editing command procedures sufficient for debugging (i.e.
insert a STOP or a SHOW SYMBOL command). IMHO if the script has a complex
enough state that setting it up is too much work or too much time to repeat
multiple times, you should be using a compiled language.
I once inherited a problem reporting system written in DCL. It tested fine,
but when the database (a text file) was populated with 20-some "records",
and DCL was searching through them for specific values in specific fields,
it started to get really slow. I re-wrote the whole thing in PL/I using a
keyed file and SMG, and now the database contains over 10,000 records and
still works great.
Here's an improvement I'd like to see in DCL -- a way to write to a MBA
device which does the equivalent of IO$_WRITEVBLK | IO$M_NOW |IO$M_NORSWAIT.
DCL's WRITE command seems to wait for the message to be read on the other
end before continuing.
--Keith Lewis klewis$mitre.org
The above may not (yet) represent the opinions of my employer.
Bob Koehler
>
> Guy, since you are working on the parser you could support both the
> C and the PL/I like syntax with little effort, this would make it more
> REXX like. Besides SELECT ... WHEN ... OTHERWISE is a lot more powerful
> with the ALL and ANY options, (and reads better)
I agree with the previous comment: more like Fortran 95, not more
like C. IMHO PL/I doesn't look all that much like C, either.
Keith A. Lewis
>Larry Kilgallen wrote:
>> In article <b23ef1eaaa5aff02...@news.teranews.com>, Ken Robinson <sendsp...@rbnsn.com> writes:
>>>Other suggestions for DCL ... (I know you didn't ask, but why not :-) )
>>>
>>>1) a for loop construct
>>>2) a switch construct
>>
>> Presuming you mean a "case" statement, I use "computed GOTOs" for that.
>
>That works, but you can't do the default/otherwise: the error is
>unrecoverable.
This recovers just fine for me, Chris.
$ dest := bad_label
$ on warning then goto default
$ goto 'dest'
$ exit
$!
$default:
$ write sys$Output "Hello"
>I have to check with:
> $ search 'f$env("procedure")' switch_'value':
> $ if ($severity.eq.1) then $ goto switch_'value'
>(and that's not fireproof if the label is inside a subroutine, or
>there's some similar problem)
You can deal with the label collision problem by making your prefix unique,
e.g. "goto switch_1_'value'".
Stanley F. Quayle
> Here's an improvement I'd like to see in DCL -- a way to write to a MBA
> device which does the equivalent of IO$_WRITEVBLK | IO$M_NOW |IO$M_NORSWAIT.
> DCL's WRITE command seems to wait for the message to be read on the other
> end before continuing.
While we're wishing and hoping -- how about a way to exchange data
with IP sockets on remote hosts? That was a big subject some months
ago, and I don't remember it ever being resolved.
As for someone else's comment that you shouldn't write "real
programs" in DCL: check out "Writing Real Programs in DCL". An
excellent book, worth every penny -- I read it cover-to-cover, and
discovered all sorts of useful stuff.
--Stan Quayle
Quayle Consulting Inc.
----------
Stanley F. Quayle, P.E. N8SQ +1 614-868-1363 Fax: +1 614 868-1671
8572 North Spring Ct. NW, Pickerington, OH 43147
Preferred address: st...@stanq.com http://www.stanq.com
Don Sykes
If addressed to 'THIS' user, respond immediately with NO SUCH USER and
drop link!
Sorry Guy, I know this isn't the direction you wanted to take this
thread...
--
Have VMS, Will Travel
Wire paladin, San Francisco
(paladinATalphaseDOTcom)
Don Sykes
WHILE is great. CASE is good.
--
Don Sykes
open/ip MYSOCK 206.125.32.43:1024
write MYSOCK "connect"
read MYSOCK DATA
close MYSOCK
Maybe also a lexical like f$nslookup(DOMAIN_NAME)
--
Denny Rich
I noted you are working on FOR, WHILE and others. Thanks.
Guy Peleg <guy....@hp.com> wrote in message news:<3F55DAA1...@hp.com>...
Marc Van Dyck
>
> Here's an improvement I'd like to see in DCL -- a way to write to a MBA
> device which does the equivalent of IO$_WRITEVBLK | IO$M_NOW |IO$M_NORSWAIT.
> DCL's WRITE command seems to wait for the message to be read on the other
> end before continuing.
>
> --Keith Lewis klewis$mitre.org
> The above may not (yet) represent the opinions of my employer.
If you need that feature, look at the MBX package on the freeware CD,
which does exactly this. If you do so, some feedback would be much
appreciated.
Marc.
--
Marc Van Dyck
Alan
How about... Making the OpenVMS FTP server work correctly
with all the other OS browsers, such as Microsoft IE, and
Linux browsers (Netscape, Mozilla, Galeon, etc...).
This would be a much bigger step forward for OpenVMS.
Does anybody in VMS engineering test this against any
other OS browser.
Alan
Z
: Please post a reply with your comments or send me mail.
How about a syntax checker?
Z
: 1) a for loop construct
: 2) a switch construct
: 3) more that 8 parameters
foreach would be nice.
And I'd _love_ the ability to write functions.
JBloggs@acme..spamless..com
<st...@stanq.com> wrote:
>While we're wishing and hoping -- how about a way to exchange data
>with IP sockets on remote hosts? That was a big subject some months
>ago, and I don't remember it ever being resolved.
Taking that a step further, a Perl CLI (eg P-Shell) would be a
very handy thing,
if no other reason, than that for lotsa folks not well versed in VMS,
they might well be fluent in Perl.
A set of docs on how to write/install your own CLI/Shell
would be interesting too (even if completely unsupported ...)
Mark Berryman
> The DCL engineering team is currently evaluating new features to be
> added in future version of VMS (post V7.3-2).
>
> We were wondering if folks think that developing a DCL debugger will be
> useful. It won't be as sophisticated
> as the VMS debugger, I was thinking about implementing step,examine and
> set break.
Count this as as strong vote in favor...
> Please post a reply with your comments or send me mail.
>
> Thanks in advance,
>
> Guy Peleg
> OpenVMS Engineering
>
> ** Please note that this note is no commitment for actually developing a
> DCL debugger, this is only a survey that will not
> necessarily result in actual product.....
There were some features in the RSX command interpreter that never made
made it into VMS that would be very useful. Unfortunately, it has been
over 15 years since I touched an RSX system and I can't remember them
all. Two that I do remember are:
o The ability to execute a command procedure directly out of a library
(e.g. @package.tlb/module=doit)
o The ability to execute a command file without actually issuing any
commands (i.e., the DCL code would execute but anything that would
be considered a "command" (something that would activate an image?)
would simply echo, not execute). cf. RSX sysgen procedure
o I also seem to remember an ability to echo "commands" only (again
that vague word, something causing execution outside of DCL?)
without echoing any other part of the command file. Sort of a
set verify light.
I've asked for this before but don't remember if it got to you:
o I'd like a command (SET PROCESS/PARSE=PIPE_ASSUMED ?) that causes
DCL parsing to always assume the command was prefixed with PIPE.
And a few other ideas:
o If line-editing across a line-wrap can't be fixed in the terminal
driver, work around it in DCL.
o Longer prompts, with variable substitution (requested often
by those who use other systems frequently and VMS occasionally).
o More flexibility in symbol limits. I know (and appreciate) what
is coming but, (acting like a typical user here) I want more. Since
RMS can support a 32KB record, I'd like DCL to be able to put the
entire record in one symbol. A SET PROCESS command (or even a
SYSGEN parameter) that specifies the max symbol length would be very
nice if memory overhead is an issue. Maybe moving symbols to P2
space would help.
o An addition to DCL command definition: the ability to define a
translation table between DCL syntax and Unix shell syntax. The
user would then enter the command in standard DCL form; DCL would
translate the command to Unix shell form (i.e. command -switch1
value1 -switch2 value2 etc). and hand that command line off to the
defined image as a CLI Foreign command.
That's it for now.
Comments?
Mark Berryman
Mark Berryman
I thought of another one:
A P0 parameter that contains the entire command that invoked the
procedure, exactly as typed. (If not P0, then a lexical that can
retrieve it.)
Mark Berryman
David J. Dachtera
>
> Mark Berryman wrote:
> > Guy Peleg wrote:
> >
> >> The DCL engineering team is currently evaluating new features to be
> >> added in future version of VMS (post V7.3-2).
> >>
> >> We were wondering if folks think that developing a DCL debugger will be
> >> useful. It won't be as sophisticated
> >> as the VMS debugger, I was thinking about implementing step,examine and
> >> set break.
> >
> >
> > Count this as as strong vote in favor...
> >
> >> Please post a reply with your comments or send me mail.
> >>
> >> Thanks in advance,
> >>
> >> Guy Peleg
> >> OpenVMS Engineering
> >>
> >> ** Please note that this note is no commitment for actually developing a
> >> DCL debugger, this is only a survey that will not
> >> necessarily result in actual product.....
> >
> >
> > There were some features in the RSX command interpreter that never made
> > made it into VMS that would be very useful. Unfortunately, it has been
> > over 15 years since I touched an RSX system and I can't remember them
> > all. Two that I do remember are:
> >
> > o The ability to execute a command procedure directly out of a library
> > (e.g. @package.tlb/module=doit)
I had suggested something similar:
$ DEFINE DCL$LIBRARY SYS$DISK:[MYDIR]
$ @procedure_name/LIBRARY[=libname[.CLB]]
$ INCLUDE[/LIBRARY[=libname[.CLB]]] procedure_name
...where "libname" defaults to the either the translation of DCL$LIBRARY
or SYS$LIBRARY:DCL$LIBRARY.CLB, ala
F$PARSE( libname, "DCL$LIBRARY", "SYS$LIBRARY:.CLB" )
..., or optionally, SET LIBRARY SYS$DISK:[MYDIR] could provide the
secondary default for (F)$PARSE.
The INCLUDE command would execute at the current depth. This is intended
for symbol assignments and other "straight-line" logic, no GOTOs.
> > o The ability to execute a command file without actually issuing any
> > commands (i.e., the DCL code would execute but anything that would
> > be considered a "command" (something that would activate an image?)
> > would simply echo, not execute). cf. RSX sysgen procedure
A DCL syntax checker would be helpful, yes.
> > o I also seem to remember an ability to echo "commands" only (again
> > that vague word, something causing execution outside of DCL?)
> > without echoing any other part of the command file. Sort of a
> > set verify light.
See HELP SET VERIFY, especially the third example.
> > I've asked for this before but don't remember if it got to you:
> >
> > o I'd like a command (SET PROCESS/PARSE=PIPE_ASSUMED ?) that causes
> > DCL parsing to always assume the command was prefixed with PIPE.
That WOULD be cool, yes.
> > And a few other ideas:
> >
> > o If line-editing across a line-wrap can't be fixed in the terminal
> > driver, work around it in DCL.
I've seen many posters want that.
> > o Longer prompts, with variable substitution (requested often
> > by those who use other systems frequently and VMS occasionally).
In light of the long-line editing question, is that advisable?
> > o More flexibility in symbol limits. I know (and appreciate) what
> > is coming but, (acting like a typical user here) I want more. Since
> > RMS can support a 32KB record, I'd like DCL to be able to put the
> > entire record in one symbol. A SET PROCESS command (or even a
> > SYSGEN parameter) that specifies the max symbol length would be very
> > nice if memory overhead is an issue. Maybe moving symbols to P2
> > space would help.
I believe that is an issue of the string descriptor length field. Dunno
if they can do that without breaking a lotta stuff.
> > o An addition to DCL command definition: the ability to define a
> > translation table between DCL syntax and Unix shell syntax. The
> > user would then enter the command in standard DCL form; DCL would
> > translate the command to Unix shell form (i.e. command -switch1
> > value1 -switch2 value2 etc). and hand that command line off to the
> > defined image as a CLI Foreign command.
> >
> > [snip]
> >
> > Comments?
>
> I thought of another one:
>
> A P0 parameter that contains the entire command that invoked the
> procedure, exactly as typed. (If not P0, then a lexical that can
> retrieve it.)
That WOULD be very helpful, yes! ...but would likely exacerbate the
string length issue.
--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Jim Strehlow
> added in future version of VMS (post V7.3-2).
> We were wondering if folks think that developing a DCL debugger will be
> useful. It won't be as sophisticated
> as the VMS debugger, I was thinking about implementing step,examine and
> set break.
What would help us all is to remove some "legacy" restrictions on DCL
statement length and length of variables:
$OPEN/READ xx filename
where the maximum record length is 2048 or when we must use
$WRITE/SYMBOL xx data
when the data string is greater than 1024 bytes
or $ READ/INDEX had a record length limit of 255 bytes (old note of
mine.)
(The debugger will have quite a task with symbol parsing.)
Work on making DCL more user friendly before adding a debugger would
attract more people to become more comfortable with DCL.
JimStrehlow, Data911, OpenVMS Systems and Database Administrator
(18 years+ VMS)
Mike Naime
I heard rumours of a DCL complier several years ago that supposedly
decreased boot time of a VAX system from 30 minutes to 5 minutes.
Guy Peleg <guy....@hp.com> wrote in message
news:3F55DAA1...@hp.com...
>
> The DCL engineering team is currently evaluating new features to be
> added in future version of VMS (post V7.3-2).
>
> We were wondering if folks think that developing a DCL debugger will be
> useful. It won't be as sophisticated
> as the VMS debugger, I was thinking about implementing step,examine and
> set break.
>
dit...@dittman.net
I'd really like to see command line completion.
--
Eric Dittman
dit...@dittman.net
Guy Peleg
I didn't answer every response but I added every request published to my
wish list.
It looks that most people would find DCL debugger useful. This won't be a
priority one
project but more of a midnight project.
We currently thinking about "user written lexical functions". We haven't
figured it out completely but the
idea would be to develop a lexical function that will call a user supplied
routine and possibly supply a list
of parameters. I would like to allow calling Java applets as well. This is
still in the VERY early
stages of development, more on this probably within a month or two.
Other things that are being considered are lexical functions with multiple
item codes and 64bit
support in symbols.
Once the WHILE feature is ready I'll post another message asking for field
test candidates.
Last but not least please look at this as a looking forward statement and
not a firm commitment.
Thank you again for your great feedback and your support in OpenVMS.
Guy Peleg
OpenVMS Engineering
Guy Peleg
Guy Peleg
Guy Peleg
Dave Weatherall
<Mark.B...@Mvb.Saic.Com> wrote:
> Guy Peleg wrote:
> > The DCL engineering team is currently evaluating new features to be
> > added in future version of VMS (post V7.3-2).
> >
> > We were wondering if folks think that developing a DCL debugger will be
> > useful. It won't be as sophisticated
> > as the VMS debugger, I was thinking about implementing step,examine and
> > set break.
First let me add my YES vote. It feels like it was only on Monday I
was thinking 'I only..' In fact it was a month ago. Funny how vacation
days slip from the mind when you get back to work...
> There were some features in the RSX command interpreter that never made
> made it into VMS that would be very useful. Unfortunately, it has been
One that I missed was
@proc/del
It made it much simpler to Create, Execute and Delete procedures on
the fly. Particularly useful when creating input files for compilers
or images where symbol substitution is required. i.e. do the symbol
substution when creating the new command file and then execute/delete
it. Obviously the /DEL qualifier only gets added when one is confident
that the generated code is correct :-)
--
Cheers - Dave.
Bart Zorn
want to find out what those old, badly documented and badly written,
command files actually do. Of course the original author is nowhere to
be found if his/her name is even documented!
Regards,
Bart Zorn
Guy Peleg <guy....@hp.com> wrote in message news:<3F55DAA1...@hp.com>...
> The DCL engineering team is currently evaluating new features to be
> added in future version of VMS (post V7.3-2).
>
> We were wondering if folks think that developing a DCL debugger will be
> useful. It won't be as sophisticated
> as the VMS debugger, I was thinking about implementing step,examine and
> set break.
>
VAXman-
>Thank you all for your feedback.
>I didn't answer every response but I added every request published to my
>wish list.
>
>It looks that most people would find DCL debugger useful. This won't be a
>priority one
>project but more of a midnight project.
>
>We currently thinking about "user written lexical functions". We haven't
>figured it out completely but the
>idea would be to develop a lexical function that will call a user supplied
>routine and possibly supply a list
>of parameters. I would like to allow calling Java applets as well. This is
>still in the VERY early
>stages of development, more on this probably within a month or two.
>
>Other things that are being considered are lexical functions with multiple
>item codes and 64bit
>support in symbols.
>
>Once the WHILE feature is ready I'll post another message asking for field
>test candidates.
>
>Last but not least please look at this as a looking forward statement and
>not a firm commitment.
>
>Thank you again for your great feedback and your support in OpenVMS.
>
>Guy Peleg
>OpenVMS Engineering
Oh well, two more projects to shelve away.
--
VAXman- OpenVMS APE certification number: AAA-0001 VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
Rik Steenwinkel
wrote:
} OTOH, I don't see the point for FOR and WHILE or UNTIL loops, that can
} easily be made with GOTOs, as DCL should not be considered a language for
} creating real applications and thus does not absolutely need all those
} constructs.
They're not necessary, but still they're nice to have and they would
probably clarify quite a few DCL command files.
Instead of
$ counter = 1
$ loop:
$ do_something
$ counter = counter + 1
$ if counter .le. final then goto loop
$ do_some_more
I'd rather write
$ counter = 0
$ repeat
$ counter = counter + 1
$ do_something
$ until counter .ge. final
$ do_some_more
especially when dealing with nested loops that again have conditions
in them, thus keeping the if-statements for different code flow, and
the repeat/until or while/do for the actual looping.
About a for-construct: lexicals such as f$element, f$search and
f$getqui pretty much suggest something like
$ foreach (file = f$search() )
$ ...
$ endforeach
(syntax made up on the spur of the moment; don't shoot)
but because of the assignment of the lexical to a variable, and the
implicit testing of the returned value being empty that could get ugly
fast.
--
// Rik Steenwinkel # VMS mercenary # Enschede, Netherlands
// 1024D/CDBAE5C1
Charlie Hammond
Have you tried my freeware DCL_CHECK?
Email me for most up-to-date copy.
--
Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale FL USA
(hammond@not@peek.ssr.hp.com -- remove "@not" when replying)
All opinions expressed are my own and not necessarily my employer's.
Ken Robinson
news:Ysd2q9KROUC1-p...@news.xs4all.nl:
> On Wed, 3 Sep 2003 14:29:46 UTC, "Syltrem" <syltr...@videotron.ca>
> wrote:
>
> } OTOH, I don't see the point for FOR and WHILE or UNTIL loops, that
> can } easily be made with GOTOs, as DCL should not be considered a
> language for } creating real applications and thus does not absolutely
> need all those } constructs.
>
> They're not necessary, but still they're nice to have and they would
> probably clarify quite a few DCL command files.
>
> Instead of
>
> $ counter = 1
> $ loop:
> $ do_something
> $ counter = counter + 1
> $ if counter .le. final then goto loop
> $ do_some_more
>
> I'd rather write
>
> $ counter = 0
> $ repeat
> $ counter = counter + 1
> $ do_something
> $ until counter .ge. final
> $ do_some_more
>
Or to use the syntax from C or PHP...
$ for (counter=0;counter .le. final;counter++) ! var++ is the syntax for
adding 1 a variable, this would have to be added...
$ do some code
$ endfor
Ken Robinson
kenrbnsn (at) rbnsn (dot) com <--- this time I got it right! :-)
Michael Unger
> The DCL engineering team is currently evaluating new features to be
> added in future version of VMS (post V7.3-2).
>
> [...]
Just another idea for new features: Access to the system services
$BINTIM and $ASCTIM via lexical functions F$BINTIM and F$ASCTIM. That
would it make possible to read/write data records with dates stored as
64bit fields.
Example:
READ file record
datetime_bin_1 = F$EXTRACT(offset, 8, record)
datetime_asc_1 = F$ASCTIM(datetime_bin_1)
...
datetime_asc_2 = [... whatever ...]
datetime_bin_2 = F$BINTIM(datetime_asc_2)
record = [... whatever ...]
WRITE /UPDATE file record
Michael
--
Real names enhance the probability of getting real answers.
Please do *not* send "Security Patch Notifications" or "Security
Updates"; this system isn't running a Micro$oft operating system.
And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)
Farrell, Michael
real math?
Mike Farrell
Guy Peleg
OpenVMS Engineering
Guy Peleg wrote:
> The DCL engineering team is currently evaluating new features to be
> added in future version of VMS (post V7.3-2).
>
> We were wondering if folks think that developing a DCL debugger will be
> useful. It won't be as sophisticated
> as the VMS debugger, I was thinking about implementing step,examine and
> set break.
>
> Please post a reply with your comments or send me mail.
>
Roy Omond
> [...snip...]
> Or to use the syntax from C or PHP...
>
> $ for (counter=0;counter .le. final;counter++) ! var++ is the syntax for
> adding 1 a variable, this would have to be added...
> $ do some code
> $ endfor
*** SCREAM ***
No, no, no, no ...
Please do not foist this abberation on something as clean as VMS.
Roy Omond
Blue Bubble Ltd.
Keith A. Lewis
> o If line-editing across a line-wrap can't be fixed in the terminal
> driver, work around it in DCL.
I second that! Unix and Linux "bash" shells have it already.
Bob Koehler
>
>
> How about... Making the OpenVMS FTP server work correctly
> with all the other OS browsers, such as Microsoft IE, and
> Linux browsers (Netscape, Mozilla, Galeon, etc...).
I don't see how any piece of software can be expected to
compensate for all the bugs in all the other software
out there, including a large number which ignore the RFP.
The bugs are in IE et. al., and they should be fixed.
Bob Koehler
> I didn't answer every response but I added every request published to my
> wish list.
>
As long as you're working in the CLI area:
A generic CLI which would call a user supplied unprivileged
UNIX-style shell (provided it's on a list approved by a privileged
user). Then document it. That would make it a lot easier for VMS
Engineering and the rest of us to port shells to VMS. The current
need to use the undocumented CLI interface is too cumbersome.
Tom Linden
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003
JF Mezei
> We currently thinking about "user written lexical functions".
<font size=2000, style=(hyper-bold, blinking, reverse_video)
YES
</font>
Another thing that would be neat is the ability to build the equivalent of a
shareable image in a library file. In the above case, you'd have a .elb file
(executable library) containing the user written lexical functions, which
would make it easy to add/remove functions.
This way, you could pickup a lexical function from a trusted source and easily
install it on your system without having to recompile and relink everything
else into a single traditional shareable image.
> Other things that are being considered are lexical functions with multiple
> item codes and 64bit
> support in symbols.
Any thought about supporting floating point symbols and arithmetic in DCL ?
JF Mezei
> } easily be made with GOTOs,
If you implement FOR, WHILE , UNTIL loops, you should also implement some
BREAK statement that allows you to break out of the loop prematurely. Or
something less conventional, but more elegant:
JUMPOUT label
This would 1- reset the "I am in a loop", 2-branch to a specific label.
This would make it far more obvious what happens when you want to prematirely
leave the loop, instead of a BREAK statement which isn't so obvious what
exactly happens when it executes.
On the other hand, with nested loops, it could get interesting.
JF Mezei
> > driver, work around it in DCL.
Perhaps on a decterm, you could press a special key which would pop the
current command up in a dialog whcih you could then edit at your heart's
content and when you press OK, it gets executed.
On a character cell terminal, how about popping an rudimentary editor which
would break the command with each qualifier into its own line, allowing you to
edit each line and then when you are done <ctrl-z> to re-assemble the command
and drop it back at the dcl level for you to then press return to execute it.
Adrian Birkett
I haven't had the time to read all the postings so apologies if this is a
repeat.
I used to use the TPU debugger and found it quite good - basic but good. I
would like to see this format of debugger for DCL if there is going to be
one rather than the full blown all singing and dancing one.
Ade
Keith A. Lewis
>Après mure réflexion, "Keith A. Lewis" a écrit :
>> Here's an improvement I'd like to see in DCL -- a way to write to a MBA
>> device which does the equivalent of IO$_WRITEVBLK | IO$M_NOW |IO$M_NORSWAIT.
>> DCL's WRITE command seems to wait for the message to be read on the other
>> end before continuing.
>If you need that feature, look at the MBX package on the freeware CD,
>which does exactly this. If you do so, some feedback would be much
>appreciated.
Looks like a good package, Marc. If I read the source right, it keeps the
I/O channel open between commands. Awesome.
Still, I think the functionality should be added to DCL so that it's there
out-of-the-box.
Keith A. Lewis
Naaah, no reason to fix 'em. If somebody is serious about serving files to
browsers, they'll set up an HTTP server. Apache is an excellent, free web
server which runs on most platforms, including VMS. There's no excuse for
forcing your browser-based customers to use FTP.
The FTP protocol has several problems that HTTP doesn't have, and only one
added feature (multiple transfers using a wildcard), which doesn't work in
any browser I've ever seen.
Tom Linden
>-----Original Message-----
>From: JF Mezei [mailto:jfmezei...@istop.com]
>Sent: Thursday, September 04, 2003 8:55 AM
>To: Info...@Mvb.Saic.Com
>Subject: Re: Do we need a DCL debugger?
>
>
>> } OTOH, I don't see the point for FOR and WHILE or UNTIL loops, that can
>> } easily be made with GOTOs,
>
>If you implement FOR, WHILE , UNTIL loops, you should also implement some
>BREAK statement that allows you to break out of the loop prematurely. Or
>something less conventional, but more elegant:
>
>JUMPOUT label
If you do this, please call it
LEAVE [label] (if label is not supplied it drops to the first executable
after the loop)
so as not to superfluosly introduce yet another term into programming
>
>This would 1- reset the "I am in a loop", 2-branch to a specific label.
>
>This would make it far more obvious what happens when you want to
>prematirely
>leave the loop, instead of a BREAK statement which isn't so obvious what
>exactly happens when it executes.
>
>On the other hand, with nested loops, it could get interesting.
>
Tom Linden
>-----Original Message-----
>From: JF Mezei [mailto:jfmezei...@istop.com]
>Sent: Thursday, September 04, 2003 9:04 AM
>To: Info...@Mvb.Saic.Com
>Subject: Re: Do we need a DCL debugger?
>
>
Or better yet, run it in an emacs command shell with syntax checking done
by dcl-mode (written in lisp, of course)
Syltrem
in DCL rather than having new constructs to make stuff "more readable". I
like to be able to do more, not just different.
Floating point calculations,
Easier access to mailboxes (I once did it all in DCL and sometimes it would
fail - 1 time out of 50 with a message that said it lost track of the stream
or something). Now I use a basic program to interact with the mbx.
Ability to communicate with other processes by the mean of TCP/IP
etc
etc
Others have given other examples in this thread
--
Syltrem
OpenVMS 7.3-1 + Oracle 8.1.7.4
http://pages.infinit.net/syltrem (OpenVMS related web site, en français)
---zulu is not in my email address---
"Ken Robinson" <sendsp...@rbnsn.com> a écrit dans le message de
news:aaf3021892e892ee...@news.teranews.com...
JF Mezei
> >> device which does the equivalent of IO$_WRITEVBLK | IO$M_NOW |IO$M_NORSWAIT.
> >> DCL's WRITE command seems to wait for the message to be read on the other
> >> end before continuing.
I concur. Having a terminal get "stuck" in a write statement requiring that
you kill the process because you can't ctrl-y out of it is extremely annoying.
Same for a READ statement from a mailbox.
(ok, I know the trick to open another window where you open the mailbox for
read and capture the mailbox message the first process has been trying to
write for ages also works but is cumbersome).
JF Mezei
>
> I agree those may be fine statements, but I would prefer having new features
> in DCL rather than having new constructs to make stuff "more readable".
That is a fair point.
> Ability to communicate with other processes by the mean of TCP/IP
> etc
$OPEN/READ/WRITE tempfil "tcpip::www.chocolate.com:80"
would be excellent.
Guy Peleg
Guy
Tom Linden
an interpreter. Regina REXX is also available for VMS and you might
lift some useful things out of there, unfortunately it is written in C.
>-----Original Message-----
>From: Guy Peleg [mailto:guy....@hp.com]
>Sent: Thursday, September 04, 2003 11:54 AM
>To: Info...@Mvb.Saic.Com
>Subject: Re: Do we need a DCL debugger?
>
>
JF Mezei
>
> Why not port bc from unix and pipe to it?
If you really want VMS to take off big time, port Microsoft Office to VMS
(cough, shudder). Disable/remove all the dangerous features and all those that
don't abide by standards and then make it a robust trustable system. You'd be
selling VMS workstations by the tens of thousands to enterprises.
VMS would have a working Office while Linux would be left out to dry.
John Santos
They're not really bugs. The problem is the FTP RFC doesn't specify
the format of the information returned by "DIR" command (actually
the LIST command at the FTP protocol level.) Most Unix systems
implement it by spawning and "ls -l" command, but the format of
its output isn't well-defined, either.
Browsers and graphical FTP clients (i.e. WS-FTP) use a collection
of ad hoc rules to try to parse the directory output (figure out
what part is the file name, what part is the size, whether it is
in bytes of blocks, parse the various dates, etc.)
Interactive character cell clients don't bother, since the let
the user's brain figure it out.
Some FTP servers can be told to present their directory listings
in various formats, to try to make clients happy.
The real cure for this is for "them" to define a standard for
FTP directory listings that everyone can stick to.
Does anyone know if this is fixed in sftp?
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
Paul Repacholi
> o The ability to execute a command procedure directly out of a library
> (e.g. @package.tlb/module=doit)
@FOO/LB:START (.clb defaulted for command libs)
If no starting module is given, one called .MAIN. is searched for and
used.
A command library is a standard text library, so that bit is done.
Oh yes... Because of the way it was done, the library code was in fact
in the IO code, not the comand parser, so there was the undocumented
feature that you could also .OPEN lbr modules :) for free.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Tom Linden
not let some other process handle it rather than expanding dcl
to such an extent.
>-----Original Message-----
>From: JF Mezei [mailto:jfmezei...@istop.com]
>Sent: Thursday, September 04, 2003 12:29 PM
>To: Info...@Mvb.Saic.Com
>Subject: Re: Do we need a DCL debugger?
>
>
Dean Woodward
> The real cure for this is for "them" to define a standard for
> FTP directory listings that everyone can stick to.
>
> Does anyone know if this is fixed in sftp?
Isn't sftp just FTP over SSL? In which case, wouldn't "they" need to fix
the FTP RFC (959) first?
Dan O'Reilly
It depends on what you mean by "sftp". There was a "real" secure-FTP
spec that I don't think ever went anyplace much. SFTP as implemented as
part of an SSH package actually uses the SSH client and server processes
as intermediaries to actually perform things like authentication and
data encryption/transfer/decryption.
------
+-------------------------------+----------------------------------------+
| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |
+-------------------------------+----------------------------------------+
Martin Hunt
<sendsp...@rbnsn.com> wrote:
>Guy Peleg <guy....@hp.com> wrote in news:3F55DAA1...@hp.com:
>
>>
>> The DCL engineering team is currently evaluating new features to be
>> added in future version of VMS (post V7.3-2).
>>
>> We were wondering if folks think that developing a DCL debugger will
>> be useful. It won't be as sophisticated
>> as the VMS debugger, I was thinking about implementing step,examine
>> and set break.
>
>I think that this is a very good idea. With it, I wouldn't need to keep
>re-inventing the wheel with each procedure.
>
>Other suggestions for DCL ... (I know you didn't ask, but why not :-) )
>
>1) a for loop construct
An ElseIF would be handy, too
>2) a switch construct
>3) more that 8 parameters
>
>Probably others...
Command line editing over multiple (ie, wrapped) lines.
Ability to easily change the default SUBMIT behaviour to /NOPRINT - I
know there are workarounds, but it is frustrating to wonder where the
log file has gone, then realise that it has been printed and deleted.
Does anyone actually want their log files doing this?
>
>Ken Robinson
---
Martin Hunt
Systems Administrator
Fairfax New Zealand Limited
Wellington
New Zealand
David J. Dachtera
> [snip]
> An ElseIF would be handy, too
As in:
$ IF condition
$ THEN
$ statement(s)
$ ELSE IF condition
$ THEN
$ statement(s)
$ ENDIF
$ ENDIF
...?
> [snip]
> Ability to easily change the default SUBMIT behaviour to /NOPRINT - I
> know there are workarounds, but it is frustrating to wonder where the
> log file has gone, then realise that it has been printed and deleted.
> Does anyone actually want their log files doing this?
One not-so-obvious work-around for that is to not have a SYS$PRINT
queue.
You can also use the VERB utility to extract the definition of SUBMIT
and change the default value of the PRINT qualifier to be the name of a
non-existant queue.
More than one way to skin that cat...
--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Martin Hunt
<djesys...@fsi.net> wrote:
>Martin Hunt wrote:
>> [snip]
>> An ElseIF would be handy, too
>
>As in:
>
>$ IF condition
>$ THEN
>$ statement(s)
>$ ELSE IF condition
>$ THEN
>$ statement(s)
>$ ENDIF
>$ ENDIF
>
Yes, but without the need for the extra ENDIF - if you indent your
code for each IF, you end up close to the right hand side after a
while.
>...?
>
>> [snip]
>> Ability to easily change the default SUBMIT behaviour to /NOPRINT - I
>> know there are workarounds, but it is frustrating to wonder where the
>> log file has gone, then realise that it has been printed and deleted.
>> Does anyone actually want their log files doing this?
>
>One not-so-obvious work-around for that is to not have a SYS$PRINT
>queue.
We don't, but SYS$PRINT is defined as a logical. At other places I
have worked, this has not been defined for batch jobs. At my present
place of work, it is defined because some procedures want to print
reports to the default printer.
I generally leave it undefined or defined as Null or similar. But I
sometimes submit jobs under other usernames and get caught out.
>
>You can also use the VERB utility to extract the definition of SUBMIT
>and change the default value of the PRINT qualifier to be the name of a
>non-existant queue.
And then remember to do it again after an upgrade. Upgrades are
infrequent, which gives plenty of time to forget about these little
things.
>
>More than one way to skin that cat...
I know. I think I will just define the symbol "SUBMIT" to be
"SUBMIT/NOPRINT".
Dave Weatherall
<djesys...@fsi.net> wrote:
> Martin Hunt wrote:
> > [snip]
> > An ElseIF would be handy, too
>
> As in:
>
> $ IF condition
> $ THEN
> $ statement(s)
> $ ELSE IF condition
> $ THEN
> $ statement(s)
> $ ENDIF
> $ ENDIF
Yeah but more like
$ IF condition
$ THEN
$ statement(s)
$
$ ELSE IF other_condition
$ THEN
$ statement(s)
$
$ ELSEIF further_condition
$ THEN
$ statement(s)
$ ENDIF
ELSIF might be easier to implemement than ELSE IF. The 4 characater
DCL verb parsing rules would still apply.
As Martin indicates in his reply, the indentations, for those that use
them, can get a bit 'heavy' and misleading when you've got 3 or more
ELSE conditions.
--
Cheers - Dave.
Dave Weatherall
wrote:
It's there already JF. It's GOTO label :-) (ducks)
Actually you're right with point 1. It might well also help the
Parser/Interpreter get back to correct the nesting level or is that
foolproof now Guy?
I used to have a nesting problem doing GOTO (backwards) to before the
beginning of an IF/THEN/ENDIF block. I _presumed_ DCL knew where the
label was and loaded the relevant block and line without correcting
the nesting level, which in those days (5.n) was only reset by reading
forwards and checking the ensuing ENDIF statements
--
Cheers - Dave.
Phillip Helbig
> >> } easily be made with GOTOs,
> >
> >If you implement FOR, WHILE , UNTIL loops, you should also implement some
> >BREAK statement that allows you to break out of the loop prematurely. Or
> >something less conventional, but more elegant:
> >
> >JUMPOUT label
>
> LEAVE [label] (if label is not supplied it drops to the first executable
> after the loop)
> so as not to superfluosly introduce yet another term into programming
What language uses LEAVE.
Again, Fortran95 (and 90) got it right. Model this stuff on EXIT {label}
Colin Blake
>>How about... Making the OpenVMS FTP server work correctly
>>with all the other OS browsers, such as Microsoft IE, and
>>Linux browsers (Netscape, Mozilla, Galeon, etc...).
>>
OpenVMS FTP server.
Larry Kilgallen
> On Thu, 04 Sep 2003 22:44:36 -0500, "David J. Dachtera"
> <djesys...@fsi.net> wrote:
>
>>Martin Hunt wrote:
>>> Ability to easily change the default SUBMIT behaviour to /NOPRINT - I
>>> know there are workarounds, but it is frustrating to wonder where the
>>> log file has gone, then realise that it has been printed and deleted.
>>> Does anyone actually want their log files doing this?
>>
>>One not-so-obvious work-around for that is to not have a SYS$PRINT
>>queue.
>
> We don't, but SYS$PRINT is defined as a logical. At other places I
> have worked, this has not been defined for batch jobs. At my present
> place of work, it is defined because some procedures want to print
> reports to the default printer.
> I generally leave it undefined or defined as Null or similar. But I
> sometimes submit jobs under other usernames and get caught out.
So if you fail to remember to use the command
DEFINE SYS$PRINT NO_SUCH_QUEUE
why wouldn't you also fail to remember to use some _other_ command that
DCL provided (at you present place of work where other people need the
default printing behavior) ?
Bob Koehler
> Why not port bc from unix and pipe to it? You will end with quite
> an interpreter. Regina REXX is also available for VMS and you might
> lift some useful things out of there, unfortunately it is written in C.
bc is a PITA when I'm on UNIX and have to use it. For non floating
point DCL is trivial to use compared to learning bc. Let's keep it
that way.
Bob Koehler
> Tom Linden wrote:
>>
>> Why not port bc from unix and pipe to it?
>
> If you really want VMS to take off big time, port Microsoft Office to VMS
> (cough, shudder). Disable/remove all the dangerous features and all those that
> don't abide by standards and then make it a robust trustable system. You'd be
> selling VMS workstations by the tens of thousands to enterprises.
If you "Disable/remove all the dangerous features and all those that
don't abide by standards", you won't have much left.
Bob Koehler
>
> They're not really bugs. The problem is the FTP RFC doesn't specify
> the format of the information returned by "DIR" command (actually
> the LIST command at the FTP protocol level.) Most Unix systems
> implement it by spawning and "ls -l" command, but the format of
> its output isn't well-defined, either.
>
> Browsers and graphical FTP clients (i.e. WS-FTP) use a collection
> of ad hoc rules to try to parse the directory output (figure out
> what part is the file name, what part is the size, whether it is
> in bytes of blocks, parse the various dates, etc.)
That IS a bug. The RFC specifically states that the output is human
readable, not programmatically readable. To then have a piece of
software that tries to read it IS a bug.
Bob Koehler
> Starting with 1.5 beta, Mozilla (on all platforms) will talk to an
> OpenVMS FTP server.
"an OpenVMS FTP server"? Which one? (UCX?)
Tom Linden
>-----Original Message-----
>From: Phillip Helbig [mailto:HEL...@sysdev.deutsche-boerse.com]
>Sent: Friday, September 05, 2003 1:33 AM
>To: Info...@Mvb.Saic.Com
>Subject: Re: Do we need a DCL debugger?
>
>
>> >> } OTOH, I don't see the point for FOR and WHILE or UNTIL
>loops, that can
>> >> } easily be made with GOTOs,
>> >
>> >If you implement FOR, WHILE , UNTIL loops, you should also
>implement some
>> >BREAK statement that allows you to break out of the loop prematurely. Or
>> >something less conventional, but more elegant:
>> >
>> >JUMPOUT label
>> If you do this, please call it
>>
>> LEAVE [label] (if label is not supplied it drops to the first executable
>> after the loop)
>> so as not to superfluosly introduce yet another term into programming
>
>What language uses LEAVE.
PL/I.
>
>Again, Fortran95 (and 90) got it right. Model this stuff on EXIT {label}
>
Colin Blake
>>Starting with 1.5 beta, Mozilla (on all platforms) will talk to an
>>OpenVMS FTP server.
>>
>>
>
> "an OpenVMS FTP server"? Which one? (UCX?)
>
I tested with TCP/IP Services for OpenVMS, TCPware, and MultiNet.
dav...@alpha1.mdx.ac.uk
>John Santos wrote:
>
>> The real cure for this is for "them" to define a standard for
>> FTP directory listings that everyone can stick to.
>>
They did in RFC 959. Its called NLST.
An FTP client uses NLST to return the list of filenames.
The LIST command is ONLY meant to be used as display output.
It is not meant to be parsed by any program. As the RFC states about the LIST
command
"Since the information on a file may vary widely from system to system,
this information may be hard to use automatically in a program, but may be
quite useful to a human user."
David Webb
VMS and Unix team leader
CCSS
Middlesex University
dav...@alpha1.mdx.ac.uk
>Martin Hunt wrote:
>> [snip]
>> Ability to easily change the default SUBMIT behaviour to /NOPRINT - I
>> know there are workarounds, but it is frustrating to wonder where the
>> log file has gone, then realise that it has been printed and deleted.
>> Does anyone actually want their log files doing this?
>
>One not-so-obvious work-around for that is to not have a SYS$PRINT
>queue.
>
>You can also use the VERB utility to extract the definition of SUBMIT
>and change the default value of the PRINT qualifier to be the name of a
>non-existant queue.
>
>More than one way to skin that cat...
>
How about SUBMIT/REMOTE to a queue other than sys$batch on the remote node
together with a /NOLOG or /NOPRINT to stop getting log files printed on the
remote node.
David Webb
VMS and Unix team leader
CCSS
Middlesex University
Patrick Spinler
At least this particular ucx ftp server doesn't appear to support NLST:
$ ucx show version
Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
on a AlphaServer 4100 5/600 8MB running OpenVMS V7.3-1
$ ftp localhost
220 XXXXX.YYYY.edu FTP Server (Version 5.3) Ready.
Connected to LOCALHOST.
Name (LOCALHOST:pjs11):
331 Username pjs11 requires a Password
Password:
230 User logged in.
FTP> quote nlst
425-Can't build data connection for 127.0.0.1,54446
425 connect to network object rejected
-- Pat
Syltrem
news:bja9jn$i2u$2...@news.mdx.ac.uk...
> In article <3F5806A4...@fsi.net>, "David J. Dachtera"
<djesys...@fsi.net> writes:
> How about SUBMIT/REMOTE to a queue other than sys$batch on the remote node
> together with a /NOLOG or /NOPRINT to stop getting log files printed on
the
> remote node.
>
I second that!
--
Syltrem
OpenVMS 7.3-1 + Oracle 8.1.7.4
http://pages.infinit.net/syltrem (OpenVMS related web site, en français)
---zulu is not in my email address---
dav...@alpha1.mdx.ac.uk
>
>At least this particular ucx ftp server doesn't appear to support NLST:
>
> $ ucx show version
>
> Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
> on a AlphaServer 4100 5/600 8MB running OpenVMS V7.3-1
>
> $ ftp localhost
> 220 XXXXX.YYYY.edu FTP Server (Version 5.3) Ready.
> Connected to LOCALHOST.
> Name (LOCALHOST:pjs11):
> 331 Username pjs11 requires a Password
> Password:
> 230 User logged in.
> FTP> quote nlst
> 425-Can't build data connection for 127.0.0.1,54446
> 425 connect to network object rejected
>
You are confusing the FTP client commands such as get, put, ls with
the underlying FTP protocol commands.
LIST and NLST are the underlying protocol commands - EVERY FTP server and
CLIENT has to support those mandated by RFC 959.
Paul Sture
I typically have
$ SUBM*IT == SUBMIT/NOPRINT
in my sylogin on my own systems, in login on other folks' systems.
Another way is, within the batch job itself:
$ define sys$print nla0
The latter is the only way I know of suppressing the printout
with SUBMIT/REMOTE
Bob Koehler
OK, so that's many OpenVMS FTP servers. I don't recall having
a problem with my Multinet server, though, with Netscape or IE.
Patrick Spinler
> In article <bjab0l$65f$1...@tribune.mayo.edu>, Patrick Spinler <pspi...@yahoo.com> writes:
>
>>At least this particular ucx ftp server doesn't appear to support NLST:
>>
>> $ ucx show version
>>
>> Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
>> on a AlphaServer 4100 5/600 8MB running OpenVMS V7.3-1
>>
>> $ ftp localhost
>
> You are confusing the FTP client commands such as get, put, ls with
> the underlying FTP protocol commands.
> LIST and NLST are the underlying protocol commands - EVERY FTP server and
> CLIENT has to support those mandated by RFC 959.
>
Um, not really. The 'quote' command sends the following text as an FTP
protocol command.
With some FTP clients, the QUOTE command is the only way I can do some
actions on our VMS servers.
FTP> help quote
QUOTE
Sends your input directly to the remote host. Lets you use FTP
commands that are implemented by the remote host but not known to
the local host.
-- Pat
Bob Koehler
>
> 425-Can't build data connection for 127.0.0.1,54446
> 425 connect to network object rejected
OK, it's been a few months since I got into that RFC. Are you sure
it isn't case sensitive?
Also, does it respond with the same results to the client commands ls
and dir? Typically clients send NLST for one and LIST for the other.
I never had UCX fail to respond to both ls and dir, but I never had
the version you have.
dav...@alpha1.mdx.ac.uk
>dav...@alpha1.mdx.ac.uk wrote:
>> In article <bjab0l$65f$1...@tribune.mayo.edu>, Patrick Spinler <pspi...@yahoo.com> writes:
>>
>>>At least this particular ucx ftp server doesn't appear to support NLST:
>>>
>>> $ ucx show version
>>>
>>> Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
>>> on a AlphaServer 4100 5/600 8MB running OpenVMS V7.3-1
>>>
>>> $ ftp localhost
>>> FTP> quote nlst
>>
>> You are confusing the FTP client commands such as get, put, ls with
>> the underlying FTP protocol commands.
>> LIST and NLST are the underlying protocol commands - EVERY FTP server and
>> CLIENT has to support those mandated by RFC 959.
>>
>
>Um, not really. The 'quote' command sends the following text as an FTP
>protocol command.
>
Sorry you are correct about quote sending protocol commands.
However all I can say is that not supporting
quote nlst
or
quote list
is fairly common
For instance from my Suse Linux system to an FTP server on a SUN system
ftp> open gold.mdx.ac.uk
Connected to 158.94.5.209.
220 gold FTP server (SunOS 5.6) ready.
Name (gold.mdx.ac.uk:david): david20
331 Password required for david20.
Password:
230 User david20 logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quote nlst
425 Can't build data connection: Connection refused.
ftp> quote list
425 Can't build data connection: Connection refused.
I think quote is usually implemented so that it can only be used for those
protocol commands which are optional in the RFC.
David Webb
VMS and Unix team leader
CCSS
Middlesex University
>With some FTP clients, the QUOTE command is the only way I can do some
JF Mezei
> > 425-Can't build data connection for 127.0.0.1,54446
> > 425 connect to network object rejected
For the VMS (TCPIP services) FTP server:
214-The following commands are recognized:
USER TYPE RETR RNFR NLST PWD ALLO EPSV
PASS STRU STOR RNTO CWD CDUP SYST QUIT
SITE PORT STOU DELE MKD NOOP STAT HELP
MODE EPRT APPE LIST RMD ABOR PASV
214 End of Help.
Now, in the case of NLST and many others, it requires that the client
cooperate because the outpit isn't sent on the "control channel" (not sure of
the actual terminology) but on a separate link established by the remote
server to the client.
When the client software issues the NLST command, it knows to listen for a
connect request for the "data" connection. But when you issue the quote
command, the client has no idea what you are doing and doesn't know to expect
the remote server to try to connect to it to dump some data, hence, the server
compains it cannot connect.
Alan Winston - SSRL Admin Cmptg Mgr
I want to take this opportunity to express my appreciation for Colin's work
on Mozilla. It's _great_ to have VMS releases (at mozilla.org) at the same
time as those for other platforms, and to also have the option of
officially-supported SWB releases at the same time. He's also made a point
of not privileging UCX / TCP/IP Services over other IP products for VMS.
Finally, if he's responsible for introducing support for OpenVMS FTP servers
on _all Mozilla platforms_, he's done VMS webmasters a great service. (And if
he's just responsible for telling us about it, that's not bad either.)
Thanks, Colin!
-- Alan
--
===============================================================================
Alan Winston --- WIN...@SSRL.SLAC.STANFORD.EDU
Disclaimer: I speak only for myself, not SLAC or SSRL Phone: 650/926-3056
Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA 94025
===============================================================================
Marc Van Dyck
> Looks like a good package, Marc. If I read the source right, it keeps the
> I/O channel open between commands. Awesome.
>
Yes - same behaviour as for the files opened, accessed, and closed from
DCL.
>
> Still, I think the functionality should be added to DCL so that it's there
> out-of-the-box.
>
Well, when I wrote it, I considered the idea to add the functionality
of MBX to the existing OPEN, CLOSE, READ, and WRITE commands.
Integration
with VMS would have been better, but it is quite complicated : in the
install kit, I would need to decompile the above commands with the VERB
utility, add my extensions, recompile the commands, and update the DCL
tables. Risk of major system screw-up if anything goes wrong during
that
process ! So I took a step back and decided to introduce my own new DCL
verb instead.
>
> --Keith Lewis klewis$mitre.org
> The above may not (yet) represent the opinions of my employer.
For those interested, there is also a LCK package, written on the same
basis
as MBX, and that gives access to VMS locks from DCL.
Marc.
--
Marc Van Dyck
Marc Van Dyck
- Automatic command completion, like in Bash ;
- DCL language definition for LSE - get the DCl procedures right
from start, rather than have to debug them afterwards !
- Symbol substitution in prompts .