>> No perl for me. My goal is that any VMS system manager can read/understand the script. And perl is not basic knowledge.
I understand and appreciate the sentiment, but respectfully dissagree.
A VMS system manager NOT knowing perl (or python, or awk) is holding him himself, and possibly his company, back.
Over time you may find is easier to find someome with perl skills than intricate DCL skills.
string manipulation with F$EXTR, F$LOC and so on on system data is perfectly reasonable andthe best way to write (maintenance) scripts. However, IMHO, it is often NOT appropriate, or no longer appropriate, to use DCL for basic dataprocessing like rearranging a generic contact list, or summarizing an order file, nor for post processing a VMS audit/error/operator/accounting log
But hey, that's just one opinion. And perl is just an example it will come and go like everything else.
>> A second goal was that nothing had to be installed for using the script. So, dcl was the only thing thats left.
Ah. Fully understood. That's why I still code in macro at times. Sometimes I even embed a macro program in a dcl procedure. That is: The procedure tests for an image. If the image is not there, then it branches out, compiles a source ($DECK), links, deletes object, and goes back to use the freshly created image. This gives a single, ascii distribution kit and no compilers needed.
>> If a program could replace it, I could go on in dcl and generate the program after each modif.
Ah, I mis-understood you all along. I somehow decided you wanted to convert the DCL to a C, or Fortran program. And in that case, perl should be evaluated, as is can be easier to read/maintain.
But you were really talking about a 'dcl compiler' right? Ah... then perl has no relevance.
>> Is there any doc on how command scripts are processed ?
No. But is simply works a line at a time.
No compiling, no P code, no memory (on how to do a line).
The only optimization, if you want to call it that, is that it remembers the labels by RFA addresses in the file. Which reminds me to pick up a discussion I was having with Guy about not doing record IO private block IO when possible. That could speed up DCL.
I'd be interested to know the RMS component for a DCL string manipulating procedure. How much EXEC mode (RMS) vs SUPER (DCL) when you procedure runs?
I'm still interested to know how much DCL diet helped, or an other procedure which removes all comments, all excess spaces, changes the first 26 symbols to single letters, the next 26*38 to letter plus [letter|number|$|_], reduces lexical to minimal string length (f$ex...) and so on.
Re-arranging code slightly to make critical, high-execution count, loops fit in an (512 byte!) internal rms buffer has helped others in the past. Does the procedure do significant IO to the DCL scripts that you can tell? (ask XFC)
If you attempted this repacking for a single important loop in your script, could you see the difference in SUPER:EXEC:KERNEL cpu? Woudl there be an IO count reduction (if there was IO).
Cheers,
Hein.
