[Info-vax] DCL's flaws (both scripting and UI)

[VAXman- at SendSpamHere.ORG]

In article <467a46c3-867e-40e0-814c-f23c4ae5529e at googlegroups.com>, John Reagan <xyzzy1959 at gmail.com> writes:
>On Monday, January 19, 2015 at 3:40:48 PM UTC-5, Simon Clubley wrote:
>
>> You would keep f$parse for compatibility with existing DCL code and
>> it would continue to return individual strings, but you could also
>> have a (say) sys package with a differently named f$parse returning an
>> object containing all the parsed fields in one go.
>
>You mean like SYS$FILESCAN?  What's your issue with multiple calls to F$PARSE?  The overhead?  You are writing in DCL after all...
>
>And you want the lexical to populate all the fields even if you aren't going to use them?  Isn't that more expensive?  Imagine the overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields?  Ugh.

The everything and the kitchen sink approach to DCL coding... just in case
I decide to want something later on, get it all for me now!  I'll step out
for lunch while you get it for me. 


 
>> It would also be nice to be able to write something like:
>> 
>> $	queue_list = sys.o$getqui(<whatever>)
>> $	for queue in queue_list
>> $		write sys$output "queue_name = ", queue.name
>> $	end for
>> 
>> That's a _lot_ cleaner than the current mess which is f$getqui()
>> especially when you start working on the entries within those queues
>> as well.
>
>But probably slower...

But, those people that are pining for that will also (stupidly) do:

$ CALL A
$ ...
$ CALL B
$ ...
$ CALL C
$ ...
$ CALL D
$ ...
$ EXIT
$ A: SUBROUTINE
$ ...
$ EXIT
$ ENDSUBROUTINE
$ B: SUBROUTINE
$ ...
$ EXIT
$ ENDSUBROUTINE
$ C: SUBROUTINE
$ ...
$ EXIT
$ ENDSUBROUTINE
$ D: SUBROUTINE
$ ...
$ EXIT
$ ENDSUBROUTINE

Why?  Because they write DCL like it's a programming language.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.