The "heartbeat problem" has been around, and solved, for years. I remember it even being written up in one of the IBM Journals by someone at Yorktown *lots* of years ago.

These days you simply go to your friendly VM Download Library and pick one of the Disconnected Service Machine packages, like VMSERVE (now owned by Bruce Hayden, since I've retired), or the more modern PIPESERVE (sp?) and only worry about the application side of the problem.

As a bonus, you get a general purpose DSM that you can use to automate (or test) any number of mundane tasks, like checking that all the other dsm's had closed their console spool file (via the TIMES file) on the hour, by it's arrival in the rdr. In a network of cpu's, that even helps watch that RSCS is working.

I do realize, from following this list, that there is now a lot of automation commercially available, but sometimes a quick 'out of your back pocket' solution is reassuring to management and can be used as a Proof Of Concept that leads to a Requirement. Not to mention that telling your manager "I can solve that problem before lunch and don't need a maintenance window to do it." doesn't hurt your reputation!

Les

Frank M. Ramaekers wrote:
Well, I did try using just the WAKEUP RESET (which changes the SMSG to
ON from SMSG IUCV), but I still missed the first IUCV MSG.

Frank M. Ramaekers Jr.

________________________________

From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Scott Rohling
Sent: Thursday, August 04, 2011 12:45 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Trapping SMSG messages

You might try 'WAKEUP RESET' just before you do the 'WAKEUP +0 (IUCVMSG'
(You didn't say, but assuming you tried this and it worked?).   You
should also end your routine with WAKEUP RESET (just before you restore
msg values - RESET does a SET MSG ON, which may not be what it was).
It's not clear in the doc - but I 'think' doing a RESET clears IUCV..

Scott Rohling
On Thu, Aug 4, 2011 at 11:37 AM, Frank M. Ramaekers
<framaek...@ailife.com> wrote:

Good points.  I've had the problem with MSG/SMSGs still in limbo and the
WAKEUP receives those first.  Is there a way to clear these prior to
issuing the WAKEUP (or sending the SMSG)?

Frank M. Ramaekers Jr.

________________________________

From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Scott Rohling
Sent: Thursday, August 04, 2011 10:55 AM


To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Trapping SMSG messages

Another couple of points --
-  Since you can't control who might send a message to you when - you
probably want to loop until there are no more rc=5.    It could be a msg
from another user is stacked in IUCV.
-  DESBUF is kind of brute force -- it wipes out the stack -- and there
could conceivably be things stacked and needed by whatever calls you.
Better to do a 'MAKEBUF';buf=rc   ...   and then 'DROPBUF' buf ...
then you only drop the things in your 'own' stack.. and you aren't
affected by what may already be in the stack for whatever called you.
Scott Rohling

On Thu, Aug 4, 2011 at 9:44 AM, Scott Rohling <scott.rohl...@gmail.com>
wrote:

Try turning the 'SET MSG IUCV' to 'WAKEUP +0 (IUCVMSG' ..   I think this
gets WAKEUP ready - and also issues the SET MSG IUCV.   The example
under 'HELP WAKEUP' shows it done this way and I seem to recall needing
to do it in something I'd written.
Scott Rohling

On Thu, Aug 4, 2011 at 9:28 AM, Frank M. Ramaekers
<framaek...@ailife.com> wrote:

I don't quite understand why I'm missing the first IUCV MSG sent to my
virtual machine after an IPL.   The basics of this program is:

1)                   Send a SMSG to VMUTIL of 'RUOKAY'

2)                   VMUTIL, if alive, will send back a MSG response
"IMOKAY"

3)                   If the proper response is received the RC is set to
zero, all other cases it's set to 1

My short REXX:

Trace "O" "PIPE LITERAL QUERY SET", "| CP", "| SPLIT AT ,", "| STRIP", "| FIND MSG"||, "| SPEC W2 1", "| VAR SETMSG" "CP SET MSG IUCV" "CP SMSG VMUTIL RUALIVE" "WAKEUP +00:02 (QUIET IUCVMSG CONS" wurc=rc XRC=1 /* Assume bad */ Select When wurc==5 then /* Message arrived */ Do queued() Parse pull WuType WuWho WuMsg
        If WuType=="*MSG" & WuWho=="VMUTIL" & WuMsg="IMOKAY" then

XRC=0 End When wurc==6 then /* Console interrupt */ Say "Interrupted" Otherwise Nop End /* Select */ "CP SET MSG" SetMsg
  /* Flush everything */

"DESBUF" If Externals()>0 then Parse external . Exit XRC
l maint


ENTER PASSWORD  (IT WILL NOT APPEAR WHEN TYPED):



HCPLNM101E DASD 0CF1 forced R/O; R/O by SYSTEM; stable by SYSTEM


HCPLNM101E DASD 0CF2 forced R/O; R/O by SYSTEM; stable by SYSTEM


z/VM Version 5 Release 4.0, Service Level 1003 (64-bit),


built on IBM Virtualization Technology


There is no logmsg data


FILES: 0066 RDR, 0007 PRT,   NO PUN


LOGON AT 10:25:22 CDT THURSDAY 08/04/11


z/VM V5.4.0    2011-03-31 08:13



PIPINX086I CMS/TSO Pipelines, 5654-030/5655-A17 1.0112
(Version.Release/Mod) - Generated 3 Jul 2010 at 11:32:36.

Source:  Princeton Runtime Distribution


Ready; T=0.02/0.02 10:25:24


vmutil


 10:25:25  * MSG FROM VMUTIL  : IMOKAY


Ready(00001); T=0.01/0.01 10:25:27


vmutil
Ready; T=0.01/0.01 10:25:41

vmutil
Ready; T=0.01/0.01 10:25:44

vmutil
Ready; T=0.01/0.01 10:25:44

vmutil
Ready; T=0.01/0.01 10:25:45

Any way to avoid missing this first MSG?

 Frank M. Ramaekers Jr.

Systems Programmer

MCP, MCP+I, MCSE & RHCE

American Income Life Insurance Co.

Phone: (254)761-6649 <tel:%28254%29761-6649>
1200 Wooded Acres Dr.

Fax: (254)741-5777 <tel:%28254%29741-5777>
Waco, Texas  76701

_____________________________________________________ This message
contains information which is privileged and confidential and is solely
for the use of the intended recipient. If you are not the intended
recipient, be aware that any review, disclosure, copying, distribution,
or use of the contents of this message is strictly prohibited. If you
have received this in error, please destroy it immediately and notify us
at privacy...@ailife.com.
_____________________________________________________ This message
contains information which is privileged and confidential and is solely
for the use of the intended recipient. If you are not the intended
recipient, be aware that any review, disclosure, copying, distribution,
or use of the contents of this message is strictly prohibited. If you
have received this in error, please destroy it immediately and notify us
at privacy...@ailife.com.

_____________________________________________________

This message contains information which is privileged and confidential and is 
solely for the use of the

intended recipient. If you are not the intended recipient, be aware that any 
review, disclosure,

copying, distribution, or use of the contents of this message is strictly 
prohibited. If you have

received this in error, please destroy it immediately and notify us at 
privacy...@ailife.com.

Reply via email to