History of the qio efn issue - VMS

This is a discussion on History of the qio efn issue - VMS ; When I started programming on VMS back in the 80s, I don't recall being told that you needed to have a default efn for the first argument of the qio. And, lots of the examples in VMS documentation (old documentation ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: History of the qio efn issue

  1. History of the qio efn issue

    When I started programming on VMS back in the 80s, I don't recall
    being told that you needed to have a default efn for the first
    argument of the qio. And, lots of the examples in VMS documentation
    (old documentation at least) have no default.

    Just curious, when did that issue emerge?

  2. Re: History of the qio efn issue

    On Oct 24, 1:17*pm, tadamsmar wrote:
    > When I started programming on VMS back in the 80s, I don't recall
    > being told that you needed to have a default efn for the first
    > argument of the qio. * And, lots of the examples in VMS documentation
    > (old documentation at least) have no default.
    >
    > Just curious, when did that issue emerge?



    SYS$QIO is a system service and all arguments have to be supplied.
    Some programming languages fill in the blanks with 0 for you.

    The EFN parameter is required and 0 is a valid value. However multiple
    simultaneous use of a event flag in a program leads to trouble.
    Therefore the advice to use a non zero value to avoid other parts of
    the program that may be using 0.

    In some version of VMS a special event flag (number 128) was invented
    as a better answer.

  3. Re: History of the qio efn issue

    In article <4c506fc9-e35f-4668-8320-b6ffd55180a2@g61g2000hsf.googlegroups.com>, tadamsmar writes:
    >When I started programming on VMS back in the 80s, I don't recall
    >being told that you needed to have a default efn for the first
    >argument of the qio. And, lots of the examples in VMS documentation
    >(old documentation at least) have no default.
    >
    >Just curious, when did that issue emerge?


    It didn't. If you specify no EFN, in most languages and in the Macro32
    macros, the EFN defaults to EFN 0.

    The examples are examples; they're not perfect nor infallible.


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

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  4. Re: History of the qio efn issue

    In article <4c506fc9-e35f-4668-8320-b6ffd55180a2@g61g2000hsf.googlegroups.com>, tadamsmar writes:
    > When I started programming on VMS back in the 80s, I don't recall
    > being told that you needed to have a default efn for the first
    > argument of the qio. And, lots of the examples in VMS documentation
    > (old documentation at least) have no default.
    >
    > Just curious, when did that issue emerge?


    Since the EFN is passed by value, leaving it out tends to get you
    EFN 0. Having lots of things dependent on EFN 0 could lead to
    bugs. If you don't depend on the EFN, or only have one such thing
    outstanding at a time, it's not likely to be a problem.

    OBTW, since the introduction of $SYNC, which synchronous forms
    of asynchronous routines use (like, $QIOW is to $QIO), it is possible
    to share EFNs as long as the IOSBs are not shared.

    This is quite usefull when writing utility routines, so you don't
    have to have a compact with the using code over who will use which EFN.
    Don't forget VMS uses some EFNs.

    Want to make sure no one else is using your EFN? Create your own
    EFN cluster. But you still may have to agree to the EFN numbers with
    other coders.


  5. Re: History of the qio efn issue

    koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:

    >In article <4c506fc9-e35f-4668-8320-b6ffd55180a2@g61g2000hsf.googlegroups.com>, tadamsmar writes:
    >> When I started programming on VMS back in the 80s, I don't recall
    >> being told that you needed to have a default efn for the first
    >> argument of the qio. And, lots of the examples in VMS documentation
    >> (old documentation at least) have no default.
    >>
    >> Just curious, when did that issue emerge?


    It's always been there.

    > Since the EFN is passed by value, leaving it out tends to get you
    > EFN 0. Having lots of things dependent on EFN 0 could lead to
    > bugs. If you don't depend on the EFN, or only have one such thing
    > outstanding at a time, it's not likely to be a problem.


    > OBTW, since the introduction of $SYNC, which synchronous forms
    > of asynchronous routines use (like, $QIOW is to $QIO), it is possible
    > to share EFNs as long as the IOSBs are not shared.


    > This is quite usefull when writing utility routines, so you don't
    > have to have a compact with the using code over who will use which EFN.
    > Don't forget VMS uses some EFNs.


    I believe they use EFNs in the range 24-31.

    > Want to make sure no one else is using your EFN? Create your own
    > EFN cluster. But you still may have to agree to the EFN numbers with
    > other coders.


    Or use LIB$GET_EF and associated routines. Of course your whole program
    has to be coded to get all its efns from LIB$GET_EF or those that
    LIB$GET_EF will never give you.

  6. Re: History of the qio efn issue

    IanMiller wrote:

    > In some version of VMS a special event flag (number 128) was invented
    > as a better answer.


    Which VMS engineer has the patent for that invention ? Does he get
    royalties whenever someone uses it ? :-) :-) :-) ;-)

    Seriously tough, prior to this invention, was "128" blocked from the
    SYS$GETEF service, or was the later able to give a caller that flag number ?

    AKA: if you run a new application that uses the 128 flag onto an old
    version of VMS, it is possible that $GETEF will give the application a
    flag number 128 at which point, there would be a conflict because the
    application would use 128 as a real flag (obtained via $GETEF) as well
    as using it as a NOOP ?

  7. Re: History of the qio efn issue

    In article <490227d4$0$12515$c3e8da3@news.astraweb.com>, JF Mezei writes:
    >IanMiller wrote:
    >
    >> In some version of VMS a special event flag (number 128) was invented
    >> as a better answer.

    >
    >Which VMS engineer has the patent for that invention ? Does he get
    >royalties whenever someone uses it ? :-) :-) :-) ;-)
    >
    >Seriously tough, prior to this invention, was "128" blocked from the
    >SYS$GETEF service, or was the later able to give a caller that flag number ?
    >
    >AKA: if you run a new application that uses the 128 flag onto an old
    >version of VMS, it is possible that $GETEF will give the application a
    >flag number 128 at which point, there would be a conflict because the
    >application would use 128 as a real flag (obtained via $GETEF) as well
    >as using it as a NOOP ?


    The scheduling state changes take place as if an event flag was set
    but there is an ignore on actually setting a flag. I'd have to get
    out the source listings to verify it but I believe that there'd be
    checks in services pre-EFN$C_ENF that would cause a an error to be
    returned to the caller.

    These changes allow event flag waits to function in multi-threaded
    applications.
    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  8. Re: History of the qio efn issue

    In article , moroney@world.std.spaamtrap.com (Michael Moroney) writes:
    >
    > Or use LIB$GET_EF and associated routines. Of course your whole program
    > has to be coded to get all its efns from LIB$GET_EF or those that
    > LIB$GET_EF will never give you.


    Every time I used LIB$GET_EF, it told me all the local EFNs are in
    use, even if that's all the program did. We found you first have to
    tell the RTL which local EFNs to consider free.


  9. Re: History of the qio efn issue

    JF Mezei writes:

    >IanMiller wrote:


    >> In some version of VMS a special event flag (number 128) was invented
    >> as a better answer.


    >Seriously tough, prior to this invention, was "128" blocked from the
    >SYS$GETEF service, or was the later able to give a caller that flag number ?


    Perhaps someone with an old version of VMS could tell us for sure, but
    I'd bet the mortgage it would just give the same %SYSTEM-F-ILLEFC error as
    any other out-of-range event flag number, like -1, or 123456.

    EFN 128 was chosen simply because it was the next one available. 0-63
    are "normal" event flags, and 64-127 are common event flags, in 2
    clusters that can be shared between processes.

    (since they come in clusters of 32, I wonder if any other EF in the 5th
    cluster, other than 128, "do" anything. But I don't wonder enough to
    try)

    >AKA: if you run a new application that uses the 128 flag onto an old
    >version of VMS, it is possible that $GETEF will give the application a
    >flag number 128 at which point, there would be a conflict because the
    >application would use 128 as a real flag (obtained via $GETEF) as well
    >as using it as a NOOP ?


  10. Re: History of the qio efn issue

    koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:

    >In article , moroney@world.std.spaamtrap.com (Michael Moroney) writes:
    >>
    >> Or use LIB$GET_EF and associated routines. Of course your whole program
    >> has to be coded to get all its efns from LIB$GET_EF or those that
    >> LIB$GET_EF will never give you.


    > Every time I used LIB$GET_EF, it told me all the local EFNs are in
    > use, even if that's all the program did. We found you first have to
    > tell the RTL which local EFNs to consider free.


    Works OK for me.

    int main() {
    int status,i,j;
    for (i=0;i<100;i++) {
    status = lib$get_ef(&j);
    printf("ef = %d\n",j);
    if (!(status&1)) return status;
    }
    return 1;
    }

    It does consider low-numbered EFs to be already "reserved" until/unless
    you explicitly free them, but not all of them.

  11. Re: History of the qio efn issue

    On Oct 24, 10:47*pm, moro...@world.std.spaamtrap.com (Michael Moroney)
    wrote:
    > JF Mezei writes:
    > >IanMiller wrote:
    > >> In some version of VMS a special event flag (number 128) was invented
    > >> as a better answer.

    > >Seriously tough, prior to this invention, was "128" blocked from the
    > >SYS$GETEF service, or was the later able to give a caller that flag number ?

    >
    > Perhaps someone with an old version of VMS could tell us for sure, but
    > I'd bet the mortgage it would just give the same %SYSTEM-F-ILLEFC error as
    > any other out-of-range event flag number, like -1, or 123456.
    >
    > EFN 128 was chosen simply because it was the next one available. 0-63
    > are "normal" event flags, and 64-127 are common event flags, in 2
    > clusters that can be shared between processes.
    >
    > (since they come in clusters of 32, I wonder if any other EF in the 5th
    > cluster, other than 128, "do" anything. *But I don't wonder enough to
    > try)
    >
    > >AKA: if you run a new application that uses the 128 flag onto an old
    > >version of VMS, it is possible that $GETEF will give the application a
    > >flag number 128 at which point, there would be a conflict because the
    > >application would use 128 as a real flag (obtained via $GETEF) as well
    > >as using it as a NOOP ?



    If you are really curious you can look though the listings for use of
    event flag 129

  12. Re: History of the qio efn issue

    IanMiller writes:

    >If you are really curious you can look though the listings for use of
    >event flag 129


    That's interesting. Routines like SETEF have additional parameters for
    it that aren't used for any other EF. (And if you don't specify them,
    it assumes you made an error supplying a bad event flag number and returns
    SS$_ILLEFC instead of something like BADPARAM) It's used for threads.

+ Reply to Thread