And, there is a bug: if you specify IUCV *MSG MSGLIMIT 30, the actual limit
becomes X'3xxx', that is: a very large number. When specifying 300, then
300 is the limit indeed
From Ch. 16 (*MSG) of the CP Programming Services book:
"The Message system service uses the IUCV default value of 255 fo
On Friday, 03/30/2007 at 10:54 ZE2, Shimon Lebowitz <[EMAIL PROTECTED]>
wrote:
> >
> > I tested this years ago when we encountered problems with messages
that
> > seemed to get lost
> >
> But is it documented?
> Things from 'years ago' sometimes change with no
> announcement when they are undocum
Chuckie is such a tease ... stay tuned details at 11:00
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Alan Altmark
Sent: Friday, March 30, 2007 11:57 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: MSGTRAP/Trapping MSGs
On Friday, 03/30/2007 at
On Friday, 03/30/2007 at 01:14 ZE3, Kris Buelens <[EMAIL PROTECTED]>
wrote:
> > In the past, Ross Fried's QIUCV EXEC displayed the number of queued
message
> correctly,
> > now in z/VM 5.2, it displays 0. This QIUCV EXEC needs some additional
fixes.
>
> QIUCV still displayes the number of que
EDU
cc
Subject
Re: MSGTRAP/Trapping MSGs
> In the past, Ross Fried's QIUCV EXEC displayed the number of queued
message correctly,
> now in z/VM 5.2, it displays 0. This QIUCV EXEC needs some additional
fixes.
QIUCV still displayes the number of queued lines when running
QIUCV
In the past, Ross Fried's QIUCV EXEC displayed the number of queued
message correctly,
now in z/VM 5.2, it displays 0. This QIUCV EXEC needs some additional
fixes.
QIUCV still displayes the number of queued lines when running
QIUCV SYSTEM
instead of
QIUCV userA
--
Kris Buelens,
IBM Belgium,
Yes, it still is:
User A: start REXXTRY (or simething similar), issue 'WAKEUP (IUCVMSG'
User B: from another user, send a message to the first one;
User A: WAKEUP will end with RC5 and you sit in VM READ
User B: From the other user, send 270 numbered messages
User A: no messages displayed, WAKEUP
>
> I tested this years ago when we encountered problems with messages that
> seemed to get lost
>
But is it documented?
Things from 'years ago' sometimes change with no
announcement when they are undocumented internals.
I am not arguing with you, I myself have no vague idea,
just wondering if
discarded may
include something important.
Regards,
Richard Schuh
--
*From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On
Behalf Of *Kris Buelens
*Sent:* Thursday, March 29, 2007 3:08 PM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: MSGTRAP/Trapping M
include something important.
Regards,
Richard Schuh
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: Thursday, March 29, 2007 3:08 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: MSGTRAP/Trapping MSGs
Why did
Why did nobody mention WAKEUP? Not the same as TERM HOLD OFF: the messages
will be eaten by WAKEUP and be displayed afterwards.
WAKEUP +0 (IUCVMSG
... perform the work
start a REXX EXEC that basically performs:
do forever
'WAKEUP +0 (IUCVMSG'
if rc=2 then leave
pars
One thing I don't like about NOTERM is that output from the "virtual
HMC" (i.e. messages generated by SERVC instruction) ignores the NOTERM
option and appears on the console.
On Thu, 2007-03-29 at 10:19 -0700, Schuh, Richard wrote:
> Yes, there is the NOTERM option. Yet another way would be to sim
Lebowitz
Sent: Thursday, March 29, 2007 10:09 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: MSGTRAP/Trapping MSGs
I believe there is also SPOOL CON NOTERM
(but I haven't used it in ages).
Shimon
> Would not the combination of
>
> SPOOL CONS * START
> TERM MORE 0 0
> TERM HO
;
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> Behalf Of Ian S. Worthington
> Sent: Thursday, March 29, 2007 9:59 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: MSGTRAP/Trapping MSGs
>
> There used to be a VMTOOLS package
ch 29, 2007 9:59 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: MSGTRAP/Trapping MSGs
There used to be a VMTOOLS package called MSGTRAP which could be called
before
a long-running program to ensure that any incoming messages neither put
the
console into HOLDING status nor where lost (they could be display
, March 29, 2007 9:59 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: MSGTRAP/Trapping MSGs
There used to be a VMTOOLS package called MSGTRAP which could be called
before
a long-running program to ensure that any incoming messages neither put
the
console into HOLDING status nor where lost (they could be
There used to be a VMTOOLS package called MSGTRAP which could be called before
a long-running program to ensure that any incoming messages neither put the
console into HOLDING status nor where lost (they could be displayed on
completion).
It looks like this sadly never made it to the public reposi
17 matches
Mail list logo
