I think Rob hit the nail on the head. STARSYS tries a 2-way IUCV connection
but *VMEVENT is 1-way. You should be using STARMSG instead as it's also
1-way.
--
Mike Harding
z/VM System Support
mhard...@us.ibm.com
mikehard...@mindless.com
(925) 672-4403 (o)
(925) 323-2070 (m)
(925) 672-3922 (h)
/sp
On Thu, 15 Apr 2021 at 16:32, Rob van der Heij wrote:
> On Thu, 15 Apr 2021 at 16:16, John P. Hartmann wrote:
>
>> Please trace IUCV to see the interrupt parameter and message number.
>>
>
> I see it as well, and I'm trying to remember what I'm doing wrong, since
> folks are using CMS Pipelines
On Thu, 15 Apr 2021 at 16:16, John P. Hartmann wrote:
> Please trace IUCV to see the interrupt parameter and message number.
>
I see it as well, and I'm trying to remember what I'm doing wrong, since
folks are using CMS Pipelines to catch VMEVENT stuff...
Rob
Please trace IUCV to see the interrupt parameter and message number.
Also check for message in parameter list.
The target class is supposed to identify the data; without that, STARMSG
*VMEVENT is useless. Perhaps STARMSG could/should be enhanced to
write the IPARML in front of the data (or
Hello, gang.
I'm trying to use the starsys *VMEVENT stage to capture logon/logoff
messages in a z/VM user id.
The user id has this in it's definition.
priv classes: ABCDG
IUCV statement: IUCV *VMEVENT MSGLIMIT 65535
but when I run this simple text case, I see this:
pipe starsys *vmevent | cons
