Printable View
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?
On Oct 24, 1:17*pm, tadamsmar <tadams...@yahoo.com> wrote:[color=blue]
> 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?[/color]
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.
In article <4c506fc9-e35f-4668-8320-b6ffd55180a2@g61g2000hsf.googlegroups.com>, tadamsmar <tadamsmar@yahoo.com> writes:[color=blue]
>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?[/color]
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.
In article <4c506fc9-e35f-4668-8320-b6ffd55180a2@g61g2000hsf.googlegroups.com>, tadamsmar <tadamsmar@yahoo.com> writes:[color=blue]
> 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?[/color]
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.
[email]koehler@eisner.nospam.encompasserve.org[/email] (Bob Koehler) writes:
[color=blue]
>In article <4c506fc9-e35f-4668-8320-b6ffd55180a2@g61g2000hsf.googlegroups.com>, tadamsmar <tadamsmar@yahoo.com> writes:[color=green]
>> 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?[/color][/color]
It's always been there.
[color=blue]
> 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.[/color]
[color=blue]
> 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.[/color]
[color=blue]
> 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.[/color]
I believe they use EFNs in the range 24-31.
[color=blue]
> 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.[/color]
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.
IanMiller wrote:
[color=blue]
> In some version of VMS a special event flag (number 128) was invented
> as a better answer.[/color]
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 ?
In article <490227d4$0$12515$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:[color=blue]
>IanMiller wrote:
>[color=green]
>> In some version of VMS a special event flag (number 128) was invented
>> as a better answer.[/color]
>
>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 ?[/color]
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.
In article <gdt182$1lp$1@pcls6.std.com>, [email]moroney@world.std.spaamtrap.com[/email] (Michael Moroney) writes:[color=blue]
>
> 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.[/color]
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.
JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
[color=blue]
>IanMiller wrote:[/color]
[color=blue][color=green]
>> In some version of VMS a special event flag (number 128) was invented
>> as a better answer.[/color][/color]
[color=blue]
>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 ?[/color]
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)
[color=blue]
>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 ?[/color]
[email]koehler@eisner.nospam.encompasserve.org[/email] (Bob Koehler) writes:
[color=blue]
>In article <gdt182$1lp$1@pcls6.std.com>, [email]moroney@world.std.spaamtrap.com[/email] (Michael Moroney) writes:[color=green]
>>
>> 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.[/color][/color]
[color=blue]
> 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.[/color]
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.
On Oct 24, 10:47*pm, moro...@world.std.spaamtrap.com (Michael Moroney)
wrote:[color=blue]
> JF Mezei <jfmezei.spam...@vaxination.ca> writes:[color=green]
> >IanMiller wrote:[color=darkred]
> >> In some version of VMS a special event flag (number 128) was invented
> >> as a better answer.[/color]
> >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 ?[/color]
>
> 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)
>[color=green]
> >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 ?[/color][/color]
If you are really curious you can look though the listings for use of
event flag 129
IanMiller <gxys@uk2.net> writes:
[color=blue]
>If you are really curious you can look though the listings for use of
>event flag 129[/color]
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.