If the diag 8 response is truncated, the response from CP sets condition code 1 and returns how many bytes of the output would not fit in the buffer. If this information was somehow returned by the vmcp command, then you'd know how much bigger your response buffer should be, and then reissue the command with the correct buffer size.
While that doesn't fix the problem of vmcp not being able to obtain a buffer, it would help avoid it by not needing a very large buffer for many commands. Pipelines in CMS automatically obtains a larger buffer for CP QUERY commands, because there are no side effects from issuing a query more than once. If the command is not a query, the number of bytes that didn't fit the buffer can be returned to the program, so that the command can be issued again with a larger buffer. On Thu, Jul 9, 2015 at 1:16 PM, Michael MacIsaac <[email protected]> wrote: > I'm going to stop here for now. I've learned a lot about Linux memory from > this thread (but that's easy when you don't know much to begin with :)). > > I guess a question to the Linux developers in Germany would be: > > If vmcp is called with a buffer of 1M and the last slab in /proc/buddyinfo > is 0, would it not be reasonable to nudge the kernel to free at least one > slot up, assuming this can be done safely? > > Thanks. > > -Mike > > -- Bruce Hayden z/VM and Linux on z Systems ATS IBM, Endicott, NY ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
