[Info-vax] Removing the leading $ from commands in a new DCL language

[Paul Sture]

On 2015-05-04, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP>
wrote:
> On 2015-05-03, Paul Sture <nospam at sture.ch> wrote:

<snip>

>>
>> You use $DECK and $EOD for that.  There was one occasion many moons ago
>> where I needed it; it might have been in the context of talking to an
>> IBM via RJE.
>>
>
> I know, but since it's not required most of the time people don't use
> it until it is required (hopefully not as the result of finding out the
> hard way. :-))
>
> Also, if the data has $ EOD in it, then you have to switch to yet another
> variant (and you need to pick a string which doesn't appear at the start
> of any of the lines of data).
>
> In Unix shell land, things work ok with certain syntax shortcuts most
> of the time until you trip over things like filenames with a leading
> dash. At this point you have to switch to another variant to handle this
> (which works in the general case as well, but since it's extra characters
> many people don't bother - at least until they hit one of these issues
> for the first time.)
>
> This is the DCL version of that. I was trying to come up with a way in
> a rewritten DCL to avoid all this faffing around and have the same
> behaviour regardless of what the inline data looks like.


The more I think about this whole area the more I think it's only there
to deal with things we had to deal with 30 and more years ago, when many
of us had migrated, or were still in the process of migrating from,
mainframes.

One typical example might be a program written to accept user input but
not have any other means such as DCL qualifiers to specify that data.

On one project in the 80s for example there was a whole set of report
programs which prompted a user for start and end dates, part numbers or
account numbers etc and then tied up the terminal until finished.  We
changed those to accept the parameters from the user as before, but
submit the job to a batch queue and free up the terminal for other use.
That also gave us the means to submit some of those jobs (e.g. all the
month end stuff) without any operator intervention apart from kicking
off the main job.

What I would like to see in "New DCL" is a more comprehensive set of
functions to get data in, wherever it may come from or whatever
format it is in.  Looking at R[1] (itself based on a 40 year old
language - S[2]) you can import data from whole bunch of file formats
straight into tables and start working with those tables immediately.

And yes, you can read stuff off the web straight into R as well. :-)

Having said that, I have found that the way certain people use R is in
"terminal bashing mode", which I'm not so keen on.  That's fine during
prototyping but what's really needed as well is an easy way to convert
that program into something that can be submitted as a request to
a job scheduler, not necessarily on your own machine.

Moving on to something more recent, IPython has log replay
functionality.  See "Session logging and restoring" at

<http://ipython.org/ipython-doc/stable/interactive/reference.html>

Now *that* type of functionality could be very useful in "New DCL",
whether it be used for simple regression testing[3] or auditing.

[1] <https://en.wikipedia.org/wiki/R_%28programming_language%29>
[2] <https://en.wikipedia.org/wiki/S_%28programming_language%29>
[3] proper regression testing requires more effort than a simple
    replay ability, but we've got to start somewhere :-)


-- 
I like pigs. Dogs look up to us. Cats look down on us. Pigs treat us as
equals.                                            -- Winston Churchill