[Info-vax] Access to _all_ VMS system services and library functions from DCL ?
Craig A. Berry
craigberry at nospam.mac.com
Sun Jul 9 19:59:27 EDT 2017
On 7/8/17 8:39 PM, Arne Vajhøj wrote:
> On 7/8/2017 4:09 PM, Simon Clubley wrote:
>> On 2017-07-07, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>> On 4/4/2017 2:21 PM, Simon Clubley wrote:
>>>> This is why there really should be a marshalling system for the types
>>>> to convert between the DCL types and the VMS native types so you can
>>>> mostly eliminate this problem. This is also part of why the VMS
>>>> development process needs an automatic interface generator if you
>>>> do this.
>>>>
>>>> As mentioned in my original post, some aspects might be challenging
>>>> in DCL as it stands today. For example, how do you marshall an
>>>> itemlist as seen by DCL into an itemlist directly usable by VMS ?
>>>>
>>>> It would be a lot easier if DCL had a lists within lists data
>>>> structure or a lists within an array data structure. As it
>>>> stands, you would probably need a new DCL intrinsic to allow
>>>> you to manually build a usable itemlist from within DCL.
>>>
>>> It requires some tweaking, but it is possible.
>>
>> Interesting.
>>
>> Now we just need a similar process for DCL (or whatever scripting
>> language is shipped with VMS in the future).
>
> I doubt DCL will be the language for this.
>
> JavaScript as I am using. Or Python. Or something else
> in that category.
>
>> Suggested enhancements in this new future language over the example
>> below would be to see the reference to SYS$PUBLIC_VECTORS dropped and
>> SYS$GETJPIW to be changed from a string to a function/method name so
>> type checking could be done (if the replacement language supported
>> type checking to this level). This _may_ also mean the parameter
>> access method would not have to be declared in the code is it is below.
>
> Anything is possible.
>
> Original version was primarily to show item lists working:
>
> $ type itmlst.js
> importClass(Packages.java.lang.System);
>
> function printf() {
> System.out.printf.apply(System.out, arguments);
> }
>
> importClass(Packages.dk.vajhoej.vms.call.VMS);
> importClass(Packages.dk.vajhoej.vms.call.VMSLibrary);
> importClass(Packages.dk.vajhoej.vms.call.IOSB);
> importClass(Packages.dk.vajhoej.vms.call.lib.VMSCodes);
>
> var pid = new VMS.LongWord(0);
> var usrnamitm = new VMS.Item32CharacterStringOut(VMSCodes.JPI$_USERNAME,
> 256);
> var itmlst = new VMS.ItemList32([usrnamitm]);
> var iosb = new VMS.Block(new IOSB());
>
> var sts = VMS.call("SYS$PUBLIC_VECTORS",
> "SYS$GETJPIW",
> VMS.MISSING,
> VMS.pass(pid).byReference().readWrite(),
> VMS.MISSING,
> VMS.pass(itmlst).byReference().readOnly(),
> VMS.pass(iosb).byReference().writeOnly(),
> VMS.MISSING,
> VMS.MISSING);
>
> printf("sts=%.0f pid=%d usrnam=%s\n", sts, pid.getValue(),
> VMS.createTrimmedString(usrnamitm.getValue()));
>
> $ jsshell itmlst.js
> sts=1 pid=1072 usrnam=ARNE
>
> Getting rid of the string image name and function name is trivial:
>
> $ type itmlst2.js
> importClass(Packages.java.lang.System);
>
> function printf() {
> System.out.printf.apply(System.out, arguments);
> }
>
> importClass(Packages.dk.vajhoej.vms.call.VMS);
> importClass(Packages.dk.vajhoej.vms.call.VMSLibrary);
> importClass(Packages.dk.vajhoej.vms.call.IOSB);
> importClass(Packages.dk.vajhoej.vms.call.lib.VMSCodes);
>
> function SYS$GETJPIW(p1,p2,p3,p4,p5,p6,p7) {
> return
> VMS.call("SYS$PUBLIC_VECTORS","SYS$GETJPIW",p1,p2,p3,p4,p5,p6,p7);
> }
>
> var pid = new VMS.LongWord(0);
> var usrnamitm = new VMS.Item32CharacterStringOut(VMSCodes.JPI$_USERNAME,
> 256);
> var itmlst = new VMS.ItemList32([usrnamitm]);
> var iosb = new VMS.Block(new IOSB());
>
> var sts = SYS$GETJPIW(VMS.MISSING,
> VMS.pass(pid).byReference().readWrite(),
> VMS.MISSING,
> VMS.pass(itmlst).byReference().readOnly(),
> VMS.pass(iosb).byReference().writeOnly(),
> VMS.MISSING,
> VMS.MISSING);
>
> printf("sts=%.0f pid=%d usrnam=%s\n", sts, pid.getValue(),
> VMS.createTrimmedString(usrnamitm.getValue()));
>
> $ jsshell itmlst2.js
> sts=1 pid=1072 usrnam=ARNE
>
> But I don't see the point. For known functions we would want
> a much cleaner API - something more DCL lexical like.
>
> $ type itmlst3.js
> load("vms.js");
>
> var res = syssrv.SYS$GETJPIW(0,["PID","USERNAME"]);
> var sts = res.getStatus();
> var pinfo = res.getResult();
> printf("sts=%.0f pid=%.0f usrnam=%s\n", sts, pinfo.PID, pinfo.USERNAME);
>
> $ jsshell itmlst3.js
> sts=1 pid=1072 usrnam=ARNE
>
> This is a much nicer API. But it does not show the item lists. The
> array of item code get translated to an item list in some of the
> glue code (Java).
It's very nice that Javascript can do this sort of thing on VMS. I
assume anything based on the JVM could do something similar?
I have to say, though, that this is very low-level and frankly looks
like a lot of work. Dealing with item lists in something called a
scripting language doesn't really appeal to me. This can of course be
solved by writing wrapper code, which other languages have already done.
So why not just use DCL or various other solutions so that you do not
have to construct item lists in order to retrieve an item available from
$GETJPI?
More information about the Info-vax
mailing list