Very Computer

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?

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

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

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.)

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/

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

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

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

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

[...]

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...

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

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.

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

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

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

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.
<

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