Kris,
Your RxServer is more modern than my VMSERVE and has the
advantage of your continual support, which I can't do w/o
access to a VM system. Also, your technical knowledge has
grown since I retired (and so has VM), so RxServe may have
features that VMSERVE wasn't capable of.
VMSERVE is aimed at the Application Developer and my point
in posting my PLUG was to raise awareness that many of the
WAKEUP problems posted have already been solved with
VMSERVE and the programmer can concentrate on his Business
Application.
As old and tired as VMSERVE is, I notice that it still gets
plenty of downloads, so at least some folks are exploring
its usability.
I'm indebted to the original author (Rick Holt, at
Yorktown) who transferred ownership to me back in the 80's
and to the internal IBM community for their continuous
feedback until I retired at the end of May, 2004.
Les
Kris Buelens wrote:
<PLUG2>
We had about 7 servers in each of up to 18 VM systems to manage, all based
on RxServer, and obviously we were able to do it all from one location.
</PLUG2>
2009/9/16 Les Koehler <vmr...@tampabay.rr.com>
Iirc, Pipes provides the facilities to negate the problem, but I don't
remember the details.
<PLUG>
Interested parties might want to investigate/try my VMSERVE PACKAGE from
the VM Download Library. It's a little old now, but when I retired it was
widely used within IBM, saving lots of folks a lot of effort in setting up
and running service machines.
My responsibilities in Global Services required me to monitor, at one time,
about 15 service machines across four systems connected via RSCS. All the
monitoring was automated and I was only notified of unexpected or missing
events.
I could even schedule changes remotely, have them installed on the fly,
notify interested parties of their success or failure and automatically
back them off if they failed to install.
<EPLUG>
Les
Chip Davis wrote:
I'm sorry to rise to the bait, but the nearly universal misunderstanding
of the MAKEBUF command is one of my sore spots.
<PEDANT>
There is absolutely nothing about MAKEBUF that provides any sort of
separation of the records in the program stack. Successive reads from the
stack will completely ignore any MAKEBUF point and happily continue to read
records until the stack is empty, with no indication that a MAKEBUF point
was passed.
To ensure that no more records are read from the program stack than were
placed there after a MAKEBUF, it is necessary to do a Rexx Queued() or
SENTRIES command at the MAKEBUF point to determine how many records are
already on the stack, and then remove no more than were added after the
MAKEBUF. This essentially renders the MAKEBUF/DROPBUF superfluous.
The ONLY thing that MAKEBUF does is to reset the FIFO pointer to equal the
LIFO pointer. This is quite handy because it allows one to place a group of
records on the top of the stack in FIFO order. Without MAKEBUF, this
operation would require reading all the records off the stack, stacking the
new records FIFO, then restacking FIFO the original records.
The closest that MAKEBUF comes to a "separate what you place in the stack
from what is already there" operation, is that if all of the records that
were added to the program stack after a MAKEBUF command are not removed, the
remaining records can be deleted with the appropriate DROPBUF.
</PEDANT>
If at some point, CMS is given the benefit of multiple program stacks (as
in the TSO/REXX environment) you could truly "separate what you place in the
stack from what is already there" by placing the new records in a new stack.
At that point, MAKEBUF and DROPBUF will become vestigial. TSO/REXX's
NEWSTACK/DELSTACK commands and the ability to create "a stack of stacks" is
what everyone seems to think MAKEBUF/DROPBUF provides.
-Chip-
On 9/15/09 15:49 Kris Buelens said:
Yes, DROPBUF 0 would be even better, a MAKEBUF is not required in such a
server I'd say: you'd use it to separate what you place in the stack from
what is there already, but as you code DROPBUF 0, there is surely nothing
anymore to separate your stuff from.
