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.
