Error messages aren't always clear but this one in TCPIP 5.2 regarding
the GATEWAY statement takes the prize, I think. Chuckie must have
worked vary hard to come up with this one.
Jim Bohnsack
Error messages aren't always clear but this one in TCPIP 5.2 regarding
the GATEWAY statement takes the prize, I think. Chuckie must have
worked vary hard to come up with this one.
Jim Bohnsack
I don't know what exactly has changed, but this has
been mentioned here before.
I've
Shimon--I think that we're talking about different oddities. I was
commenting, specifically, on the use of the word deprecated. The
message is:
DTCPRS058I Line /line /GATEWAY format deprecated, consult documentation.
Explanation: The GATEWAY statement specified is not in the recommended
Oh, sorry. I didn't realize that was your intention.
Shimon--I think that we're talking about different oddities. I was
commenting, specifically, on the use of the word deprecated. The
message is:
DTCPRS058I Line /line /GATEWAY format deprecated, consult documentation.
Explanation:
Perhaps I'm the only one who finds that message to be not very helpful.
Perhaps so. It's only an Information-level message. Deprecated isn't
really a new term in my experience. I've seen it used in various places
(although mostly by IBM, and therein mostly by Alan/Chuckie) to describe
use
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on
03/29/2007 08:09:37 AM:
Perhaps I'm the only one who finds that message to be not very helpful.
Perhaps so. It's only an Information-level message. Deprecated
isn't
really a new term in my experience. I've seen it used
Nope! He's the architect, right?
If a bridge falls down, the architect is blamed right along with the guy
who installed all the rivets wrong.
Alan is just under-depreciated. ;-)
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the
On Thursday, 03/29/2007 at 08:21 MST, Miguel Delapaz/Endicott/[EMAIL PROTECTED]
wrote:
Is it wrong to relish the fact that Alan gets blamed for stuff that's
not his
fault? :-)
Here I am, silently taking arrows for the team, when all of a sudden there
is a knife in between my ribs. Et
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
Would not the combination of
SPOOL CONS * START
TERM MORE 0 0
TERM HOLD OFF
Prior to starting the program accomplish the result?
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Ian S. Worthington
Sent: Thursday,
There's Arty Ecock's IUCVTRAP package. It should be on the repository
of the old VM Tools tape - whose location escapes me at the moment.
Mike Harding
EDS VM National Capability
134 El Portal Place
Clayton, Ca. USA 94517-1742
* phone: +01-925-672-4403
* Fax: +01-925-672-4403
*
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 HOLD OFF
Prior to starting the program accomplish the result?
Regards,
Richard Schuh
-Original Message-
From: The IBM
On Thursday, 03/29/2007 at 08:21 MST, Miguel
Delapaz/Endicott/[EMAIL PROTECTED]
wrote:
Is it wrong to relish the fact that Alan gets blamed for stuff
that's
not his
fault? :-)
Only if you don't wash your hands thoroughly afterwards...
Yes, there is the NOTERM option. Yet another way would be to simply
disconnect the machine after starting the program (with the console
spooled, of course).
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Shimon
On Mar 29, 2007, at 10:35 AM, Alan Altmark wrote:
But you know what they say: Guilty dog barks first. :-)
If only it were Friday, we could say He who smelt it, dealt it.
Adam
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
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
If you have a long running program, WAKEUP is not actively grabbing the
messages; they are being queued by CP. They do not get eaten until the
program ends. The problem is what happens if the number of messages
received is greater than the number that CP will queue. The messages
discarded may
Sorry Richard: WAKEUP is actively grabbing messages: even when your long
running program is active, WAKEUP's first level interrupt handler is active
too. WAKEUP will queue the IUCV messages in its own storage. It is not
only CP that queues. When WAKEUP can't catch up CP queues too. The
19 matches
Mail list logo
