"Craig A. Berry" <[EMAIL PROTECTED]> wrote:
> Where Perl can really slaughter DCL is not surprisingly in text
> processing. If you have procedures that make heavy use of F$ELEMENT,
> F$LOCATE, or do text substitutions and such then hundreds of lines
> of DCL can sometimes be reduced to a handful of lines of Perl
> (sometimes even one line).
Amen! I learned Perl to get a free Web search engine going. When it
_really_ earned its keep, though, was my first honest-to-God one-liner in
combat conditions.
We had some application or other go into sorcers' apprentice mode. I have
forgotten the exact details (except the obvious one that we were _not_ out
of process slots), but I remember that I had to do a STOP/ID on all
processes whose name began with a certain string (say, 'fubar' for purposes
of illustration). I couldn't do iterative SHOW SYSTEM and STOP/ID fast
enough to keep up, so in desperation, I did something like
perl -e "for (`sho sys`) {m/^.{8}\s+fubar/ and `stop/id=$1`}"
yes, I know this is terrible Perl, but it did the trick.
Actually, though, I find myself these days having to make a conscious
decision whether to use DCL or Perl. Some of the issues are:
* A Perl script is almost always shorter;
* A DCL script works on any VMS system;
* Perl does lists and hashes _much_ better than DCL;
* If you're compute-intensive, Perl is at least an order of magnitude
faster;
* A Perl script can be made to work under multiple OSes;
* DCL requires fewer processes (or at least no more);
* Perl is still missing a few things that DCL will do.
An example of the last item is the functionality of F$FILE_ATTRIBUTES.
There is to my knowledge no way to get this information into Perl other
than spawning a subprocess, e.g.
$val = `write sys\$output f\$file_attribute ($file, $attr)`
Tom Wyant
