<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. >>> >> >> >> -- Kris Buelens, IBM Belgium, VM customer support
