DCL vs. "real" programming

DCL vs. "real" programming

Post by Phillip Helb » Mon, 03 Jul 2000 04:00:00



For example, when writing an application which processes a lot of MAIL
files, would one achieve much better performance by writing it in
Fortran or whatever and using the callable MAIL interface than by
writing .COM files etc in DCL?
 
 
 

DCL vs. "real" programming

Post by Mark E. Lev » Mon, 03 Jul 2000 04:00:00



Quote:> For example, when writing an application which processes a lot of MAIL
> files, would one achieve much better performance by writing it in
> Fortran or whatever and using the callable MAIL interface than by
> writing .COM files etc in DCL?

If it's a one-time shot, use DCL. If you plan to run this procedure often,
use an HLL like Fortran. The difference in run time (and CPU utilization)
can be dramatic. I had a procedure that scanned text files for certain
strings. It ran over 24 hours. Rewritten in Basic, it ran in under an hour.
--
---------------------------------------------------------------------
Mark E. Levy, President
System Management Associates, Inc.
888-291-5055 x202 (Illinois Only)
847-291-1550 x202 (Outside Illinois)
847-291-3866 fax
www.sysman-inc.com

---------------------------------------------------------------------

 
 
 

DCL vs. "real" programming

Post by Phillip Helb » Mon, 03 Jul 2000 04:00:00





>> For example, when writing an application which processes a lot of MAIL
>> files, would one achieve much better performance by writing it in
>> Fortran or whatever and using the callable MAIL interface than by
>> writing .COM files etc in DCL?

>If it's a one-time shot, use DCL. If you plan to run this procedure often,
>use an HLL like Fortran. The difference in run time (and CPU utilization)
>can be dramatic. I had a procedure that scanned text files for certain
>strings. It ran over 24 hours. Rewritten in Basic, it ran in under an hour.
>--
>---------------------------------------------------------------------
>Mark E. Levy, President
>System Management Associates, Inc.
>888-291-5055 x202 (Illinois Only)
>847-291-1550 x202 (Outside Illinois)
>847-291-3866 fax
>www.sysman-inc.com

>---------------------------------------------------------------------

It's not a one-shot (for which I would certainly use DCL), so it looks
like it's F$ time.  This reminds me, someone once mentioned here a DCL
compiler which would take a .COM file and convert it to the equivalent
FORTRAN with system calls etc and compile that.  Who can point me to
this?

Not to be confused with another DCL ""compiler" which did things like
upcase everything, get rid of spaces etcso that the .COM files would
parse faster (I guess this would be relatively easy to write oneself.)

 
 
 

DCL vs. "real" programming

Post by David J. Dachter » Mon, 03 Jul 2000 04:00:00






> >> For example, when writing an application which processes a lot of MAIL
> >> files, would one achieve much better performance by writing it in
> >> Fortran or whatever and using the callable MAIL interface than by
> >> writing .COM files etc in DCL?

> >If it's a one-time shot, use DCL. If you plan to run this procedure often,
> >use an HLL like Fortran. The difference in run time (and CPU utilization)
> >can be dramatic. I had a procedure that scanned text files for certain
> >strings. It ran over 24 hours. Rewritten in Basic, it ran in under an hour.
> >--
> >---------------------------------------------------------------------
> >Mark E. Levy, President
> >System Management Associates, Inc.
> >888-291-5055 x202 (Illinois Only)
> >847-291-1550 x202 (Outside Illinois)
> >847-291-3866 fax
> >www.sysman-inc.com

> >---------------------------------------------------------------------

> It's not a one-shot (for which I would certainly use DCL), so it looks
> like it's F$ time.  This reminds me, someone once mentioned here a DCL
> compiler which would take a .COM file and convert it to the equivalent
> FORTRAN with system calls etc and compile that.  Who can point me to
> this?

Yeah - that was the problem: it produced FORTRAN source code (rather an
expensive 3GL) instead of MACRO32 (which comes with every OpenVMS
system, even OpenVMS Alpha). Consequently, it never caught on as well as
it could have.

Quote:> Not to be confused with another DCL ""compiler" which did things like
> upcase everything, get rid of spaces etcso that the .COM files would
> parse faster (I guess this would be relatively easy to write oneself.)

You're talking about "DCL diet", right? That removes comments, surplus
spaces, etc. It makes DCL more efficient, but does nothing for the logic
of the proc. itself.

--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial Affordable OpenVMS Home Page and Message Board:
http://www.djesys.com/vms/soho/

 
 
 

DCL vs. "real" programming

Post by Gotfryd Smolik, VMS list » Tue, 04 Jul 2000 04:00:00



+For example, when writing an application which processes a lot of MAIL
+files, would one achieve much better performance by writing it in
+Fortran or whatever and using the callable MAIL interface than by
+writing .COM files etc in DCL?

IMHO - that depends.

 We can think of 3 way:
1. Procedure, where is loop starts the MAIL command.
 Probably you get big overhead.
2. "temporary mail commandprocedure", means file
 with the command for mail for any processed file.
  Then the DCL commandprocedure first creates w file
 with command list and in next step does one MAIL run.
  Because MAIL CLI interface work after error sometime
 can be hard to anticipate, *some* work can't be done
 that way; b.ex. after SELE/FOLDER UNEXISTANT_NAME
 MAIL will operate on the previously selected.
3. One-run MAIL with dynamically generated command, like:

$ pipe open cm/wri mpa0: ; open oo mpa0:                
$ sh log/proc %% ! For check only !
[...]
  "CM" = "_BUK$MPA5"
  "OO" = "_BUK$MPA6"
[...]
$ spa/nowa/inp='f$getdvi("cm","devnam")' -
        /out='f$getdvi("oo","devnam")'-
                                        mail
%DCL-S-SPAWNED, process GS_5 spawned

 ...and in the command procedure:

$ wri cm "dir/fol
$ read oo line
$ sh sym line
  LINE = "%MAIL-W-FILEMPTY, file DISK$USER:[GS]MAIL.MAI has no folders"

 What here look much harder, than with callable interface
is error handling... Missing in code possiblity of unexpected
error can stop you work: MAIL waits with "ennecessary" error
data and you procedure waits in WRITE with next command.

 Regards - Gotfryd

--
=====================================================================
$ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") -
                THEN EXCUSE/OBJECT=ME

=====================================================================

 
 
 

DCL vs. "real" programming

Post by Carl Perki » Tue, 04 Jul 2000 04:00:00



}For example, when writing an application which processes a lot of MAIL
}files, would one achieve much better performance by writing it in
}Fortran or whatever and using the callable MAIL interface than by
}writing .COM files etc in DCL?

Better, almost certainly. "Much better" probably depends on your definition
of "much" and the details of what you are doing.

If nothing else, the non-DCL version will probably only have a single image
activation. The DCL version may have a lot of image activations. Also,
DCL is an interpreted language so you hit the overhead of interpreting
every command every time it is run instead of just once during the compiling
operation.

--- Carl

 
 
 

DCL vs. "real" programming

Post by Hoff Hoffm » Thu, 06 Jul 2000 04:00:00


:For example, when writing an application which processes a lot of MAIL
:files, would one achieve much better performance by writing it in
:Fortran or whatever and using the callable MAIL interface than by
:writing .COM files etc in DCL?

  The answer is, of course, the deliberately ambiguous "yes".  

  There are always trade-offs.  Each application and each customer has
  its own desired/appropriate/expected performance -- there is the
  time-to-run performance, the time-to-solution performance, the
  time-to-fix (support performance), and various other things all
  interchangeably lumped under the heading of "better performance".

  I cover some of the trade-offs involved in the use of DCL in the
  introduction of the Writing Real Programs in DCL book -- DCL is a
  good choice for quick-to-implement (and potentially somewhat
  inefficient use of system resources) solutions, and not so good for
  other classes of problems, or for situations where system resources
  (or time) is tight.  

  The age-old interpreter vs compiler discussions, and the age-old
  "good" vs "good enough" discussions...  Folks have spent days or
  weeks "bumming" instructions out of certain code paths -- the real
  question (at least in the commercial space) involves the expected
  payback...  Payback in the open source and hobbyist spaces often has
  other ways of gaining (potentially different sorts of) payback...

 --------------------------- pure personal opinion ---------------------------
   Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com

 
 
 

DCL vs. "real" programming

Post by Ken Fairfield; SLAC: 650-926-2924; FAX: 926-35 » Thu, 06 Jul 2000 04:00:00




[...]

Quote:> It's not a one-shot (for which I would certainly use DCL), so it looks
> like it's F$ time.  This reminds me, someone once mentioned here a DCL
> compiler which would take a .COM file and convert it to the equivalent
> FORTRAN with system calls etc and compile that.  Who can point me to
> this?

        There is (or  was)  a  company  called Channel Islands Software,
    really  just one guy, who had a product that did this.  I can't  for
    the life of me  remember  its  name.   Something  like  DCLFort?   I
    dunno...   It  did,  in  fact,  read  DCL  command  files and output
    Fortran.  It was a bit pricey, like  US$900 or so for a single small
    system.   Something  for the "big boys" who had huge DCL  procedures
    that needed to be sped up.

        I talked to the  owner/programmer  on  the  phone a time or two.
    One  of  the  issues  was that the source code  it  output  was  not
    particularly "maintainable".  Obfuscated I  take  it.   Another  was
    that  you  needed  the  product's  RTL,  which provided the callable
    replacements for all  the  lexical  functions  that aren't otherwise
    available  (of  course).  In other words, there was a lot more  than
    just calls to VMS RTL and System Services routines.  At the  time  I
    couldn't justify the cost (I mostly wanted to just try it out, but a
    "demo"  was  really  available).   I  think there may have been some
    issues of keeping the product up  to  date with VMS releases as well
    (i.e., adding the new lexicals, etc.).

        If there's interest, I'll see if  I  still have a flier or other
    reference information, but I expect it's a long-dead product.

        -Ken
--

 SLAC, 2575 Sand Hill Rd, MS 46  |  Voice:    650-926-2924
 Menlo Park, CA  94025           |  FAX:      650-926-3515
 -----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...

 
 
 

DCL vs. "real" programming

Post by Michael Austi » Fri, 07 Jul 2000 04:00:00


I seem to recall an internal DEC program that I saw in "the Mill" that would
actually compile the DCL.  At the time I saw it, it would take a complex MVII
almost 20 minutes to boot.  With the compiled DCL, only 3 minutes.  I often wonder
what happened to those neat tools that you only saw as an employee of the
company... and there were lot's of them.  Like FTSV which used VMS copy and if it
got interrupted, you could restart it and it would pick up at the block number
where it left off.  Really great when the only interoffice connection was a
not-so-reliable 56K connection.

Michael Austin
Ex-Digit 156990 1984-1994  -- before being traded to Oracle.. and I didn't even
know I was a free agent!




> [...]
> > It's not a one-shot (for which I would certainly use DCL), so it looks
> > like it's F$ time.  This reminds me, someone once mentioned here a DCL
> > compiler which would take a .COM file and convert it to the equivalent
> > FORTRAN with system calls etc and compile that.  Who can point me to
> > this?

>         There is (or  was)  a  company  called Channel Islands Software,
>     really  just one guy, who had a product that did this.  I can't  for
>     the life of me  remember  its  name.   Something  like  DCLFort?   I
>     dunno...   It  did,  in  fact,  read  DCL  command  files and output
>     Fortran.  It was a bit pricey, like  US$900 or so for a single small
>     system.   Something  for the "big boys" who had huge DCL  procedures
>     that needed to be sped up.

>         I talked to the  owner/programmer  on  the  phone a time or two.
>     One  of  the  issues  was that the source code  it  output  was  not
>     particularly "maintainable".  Obfuscated I  take  it.   Another  was
>     that  you  needed  the  product's  RTL,  which provided the callable
>     replacements for all  the  lexical  functions  that aren't otherwise
>     available  (of  course).  In other words, there was a lot more  than
>     just calls to VMS RTL and System Services routines.  At the  time  I
>     couldn't justify the cost (I mostly wanted to just try it out, but a
>     "demo"  was  really  available).   I  think there may have been some
>     issues of keeping the product up  to  date with VMS releases as well
>     (i.e., adding the new lexicals, etc.).

>         If there's interest, I'll see if  I  still have a flier or other
>     reference information, but I expect it's a long-dead product.

>         -Ken
> --

>  SLAC, 2575 Sand Hill Rd, MS 46  |  Voice:    650-926-2924
>  Menlo Park, CA  94025           |  FAX:      650-926-3515
>  -----------------------------------------------------------------------------
>  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...

  maustin.vcf
< 1K Download
 
 
 

DCL vs. "real" programming

Post by Tim Llewelly » Fri, 07 Jul 2000 04:00:00



> company... and there were lot's of them.  Like FTSV which used VMS copy and if it
> got interrupted, you could restart it and it would pick up at the block number
> where it left off.  Really great when the only interoffice connection was a
> not-so-reliable 56K connection.

Yeah, UK ACademia's Coloured Books used to do the same back
in the 80's, very useful feature, no resend on error, any part of the connection
can fail.

Then we moved to DECNET, and finally IP. Each time features were lost.
 --
Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project
MedAS at the BBC, Whiteladies Road, Bristol, UK.

I speak for myself only and my views in no way represent those of
MedAS or the BBC.

 
 
 

DCL vs. "real" programming

Post by Jan Vorbruegge » Fri, 07 Jul 2000 04:00:00


[resuming interupted transfers]
That's not a TCP/IP problem, it's an application problem. See WGET for help.

        Jan

 
 
 

DCL vs. "real" programming

Post by Hoff Hoffm » Sat, 08 Jul 2000 04:00:00


:This is a multi-part message in MIME format.

  Please turn off MIME when posting.  Thanks!

:I seem to recall an internal DEC program that I saw in "the Mill" that would
:actually compile the DCL.  At the time I saw it, it would take a complex MVII
:almost 20 minutes to boot.  With the compiled DCL, only 3 minutes.

  The tool you likely recall involved using an image to issue a variety
  of lib$set_symbol and related operations.  SMOP.  This tool was in
  rather common use on systems that are as slow as the MicroVAX II.

  I am not particularly aware of any internally-developed DCL compilers,
  but I have seen a few attempts -- baseline DCL isn't that difficult to
  compile, but the image activations and the rather more twisted stuff you
  can do DCL procedures make the compilation task rather interesting.  In
  various cases, you have no idea what command will be invoked until you
  run the procedure -- this makes compiling interesting.  (To be able to
  perform the run-down involved when invoking images, you need to use a
  CLI-style environment, or you need to use a separate process.  This to
  keep from stomping on the currently-executing run-time environment.
  Of course, simple tools that set up a bazzillion symbols or perform
  basic DCL would be fairly easy to compile -- the symbol substitution
  and the innate bizzareness of certain DCL constructs would be rather
  tougher to contend with.)

:I often wonder
:what happened to those neat tools that you only saw as an employee of the
:company... and there were lot's of them.  

  Yep, many find their way onto the Freeware, or into products that are
  available via the Compaq services organizations.

:Like FTSV which used VMS copy and if it
:got interrupted, you could restart it and it would pick up at the block number
:where it left off.  Really great when the only interoffice connection was a
:not-so-reliable 56K connection.

  FTSV and particularly FTSO are available externally.  For details,
  please see:

    http://www.digital.com/info/SP5443/

 --------------------------- pure personal opinion ---------------------------
   Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com

 
 
 

DCL vs. "real" programming

Post by Steve.Spi.. » Tue, 11 Jul 2000 04:00:00


Contact:   Tel: 3063  -  VSSG, 1st Floor, Bridge Street Plaza

I recall (about 5 years ago) coming across a product which claimed it could
compile DCL into Fortran. I don't remember the name of it unfortunately, but
when I'm next at home I'll have a dig around in the attic amongst all my old
paperwork (why on earth do I keep it all...) and see if I can locate it, unless
anyone else can come up with it.

Steve Spires
VMS System Manager
BT/Yellow Pages



cc:         (bcc: Steve Spires/YellowPages)

Re: DCL vs. "real" programming


:This is a multi-part message in MIME format.

  Please turn off MIME when posting.  Thanks!

:I seem to recall an internal DEC program that I saw in "the Mill" that would
:actually compile the DCL.  At the time I saw it, it would take a complex MVII
:almost 20 minutes to boot.  With the compiled DCL, only 3 minutes.

  The tool you likely recall involved using an image to issue a variety
  of lib$set_symbol and related operations.  SMOP.  This tool was in
  rather common use on systems that are as slow as the MicroVAX II.

  I am not particularly aware of any internally-developed DCL compilers,
  but I have seen a few attempts -- baseline DCL isn't that difficult to
  compile, but the image activations and the rather more twisted stuff you
  can do DCL procedures make the compilation task rather interesting.  In
  various cases, you have no idea what command will be invoked until you
  run the procedure -- this makes compiling interesting.  (To be able to
  perform the run-down involved when invoking images, you need to use a
  CLI-style environment, or you need to use a separate process.  This to
  keep from stomping on the currently-executing run-time environment.
  Of course, simple tools that set up a bazzillion symbols or perform
  basic DCL would be fairly easy to compile -- the symbol substitution
  and the innate bizzareness of certain DCL constructs would be rather
  tougher to contend with.)

:I often wonder
:what happened to those neat tools that you only saw as an employee of the
:company... and there were lot's of them.

  Yep, many find their way onto the Freeware, or into products that are
  available via the Compaq services organizations.

:Like FTSV which used VMS copy and if it
:got interrupted, you could restart it and it would pick up at the block number
:where it left off.  Really great when the only interoffice connection was a
:not-so-reliable 56K connection.

  FTSV and particularly FTSO are available externally.  For details,
  please see:

    http://www.digital.com/info/SP5443/

 --------------------------- pure personal opinion ---------------------------
   Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com

 
 
 

DCL vs. "real" programming

Post by Richard B. Gilber » Tue, 11 Jul 2000 04:00:00


        There was and maybe still is.  Last I heard of it, several years
ago, the author was still selling it.

Channel Islands Software
16430 Cattle Drive
Springville, CA

(209) 539-0314

        I believe the name of the author/owner/salesperson/?  was Frank
Noell.

        I believe that the product had/has some limitations.   Since the
meaning of a DCL statement depends on the runtime environment, a compiler
can't guarantee a compiled program that will duplicate the effect of a
piece of DCL in *any* runtime environment.


Quote:>I recall (about 5 years ago) coming across a product which claimed it

could
compile DCL into Fortran. I don't remember the name of it unfortunately,
but
when I'm next at home I'll have a dig around in the attic amongst all my
old
paperwork (why on earth do I keep it all...) and see if I can locate it,
unless
anyone else can come up with it.
<
 
 
 

DCL vs. "real" programming

Post by Mark(un-MA » Wed, 12 Jul 2000 04:00:00



[deletia]

Quote:>  basic DCL would be fairly easy to compile -- the symbol substitution
>  and the innate bizzareness of certain DCL constructs would be rather
>  tougher to contend with.)

On a slightly different tack... Ted asked me about some of his DCL. This caused
me to wonder how many lexical functions can be used on the one line. I came up
with :-

$       ov = f$verify()
$       if p3 .nes. ""
$       then verify = f$verify("yes")
$       else verify = f$verify("no")
$       endif
$       ws = "write sys$output   "
$       pipe mc ncl sho node 'p1' all attr | sear -
          sys$input "aa-00-04",network/mat=and | -
          (read sys$input z ; define/job z &z)
$       b = f$elem(3,":",f$trn("z")) - "-" - "-" - "-" - "-" - "-"
$       deass/job z
$       ws  f$fao("!/DECnet address is !UL.!UL!/",-
                (f$fao("!UL",-
                f$integer(%x'f$fao("!2(AS)",-
                f$extr(2,2,f$extr(f$len(b)-4,4,b)),-
                f$extr(0,2,f$extr(f$len(b)-4,4,b)))))-(f$fao("!UL",-
                f$integer(%x'f$fao("!2(AS)",-
                f$extr(2,2,f$extr(f$len(b)-4,4,b)),-
                f$extr(0,2,f$extr(f$len(b)-4,4,b)))))-((f$fao("!UL",-
                f$integer(%x'f$fao("!2(AS)",-
                f$extr(2,2,f$extr(f$len(b)-4,4,b)),-
                f$extr(0,2,f$extr(f$len(b)-4,4,b)))))/1024)*1024)))/1024,-
                f$fao("!UL",-
                f$integer(%x'f$fao("!2(AS)",-
                f$extr(2,2,f$extr(f$len(b)-4,4,b)),-
                f$extr(0,2,f$extr(f$len(b)-4,4,b)))))-((-
                f$fao("!UL",-
                f$integer(%x'f$fao("!2(AS)",-
                f$extr(2,2,f$extr(f$len(b)-4,4,b)),-
                f$extr(0,2,f$extr(f$len(b)-4,4,b)))))/1024)*1024))
$       exitt 1 + 0 * f$verify(ov)

ANd don't laugh. It actually works. Give it a PhaseV node name and it'll tell
you the DECNet address...

Quote:

[more deletia]
>    http://www.digital.com/info/SP5443/

> --------------------------- pure personal opinion ---------------------------
>   Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com

--

Ooroo

Mark F...
unMASK for e-mail

 
 
 

1. Cache "Total Size" vs. "Kbytes in use" ??

Hi.
A few days ago I raised the VCC_MAXSIZE sysgen param from
the default 6400 to 512000 to make a 256 Mb cache.

Now, I'v seen that the "Kbytes in Use" never reach anyware
near the "Total Size" value. After four days in production
it looks like this :

Virtual I/O Cache
    Total Size (Kbytes)         256000    Read IO Count              
7410675
    Free Kbytes                 247568    Read Hit Count              
4096797
    Kbytes in Use                 8432    Read Hit
Rate                    55%
    Write IO Bypassing Cache     10310    Write IO Count              
901914
    Files Retained                  98    Read IO Bypassing Cache      
958505

During this four days I'v seen "Kbytes in Use" values of up to
aprox 40 Mb (40000 in the output).

Does this all mean that my chache is "to large" ?

Jan-Erik S?derholm.

2. Active directory users dialog box

3. "process crash" vs. "application crash"

4. Forcing browser to display font

5. "unix" vs "vms" code mgt. tools...

6. TaPI

7. LINKING F90 programs leads to "multiply defined" and "undefined" CMA$TIS

8. Use what to close the win2k's opened port?

9. "Watch" and "Assist" program

10. DCL question - changing "AA" to "BB"

11. DCL "feature", MONMODE "bug", Life, etc...

12. F$GETQUI("DISPLAY_JOB","LOG_SPECIFICATION",,"THIS_JOB")

13. """The Art of Debugging"" Was: Compiler Optimisation problems"