Comments (2)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 localhost commented Permalink

you need to explain what you mean self-documenting in this context, martin. do you mean well defined instrumentation, publishing well documented information - in which case its surely worth talking to standards such as ARM in this piece. or something else? i am genuinely interested. would the "self-documentation" of a mainframe environment be understood by anyone else, from a different platform's perspective?or as you just saying devs should document their apps - not exactly news, that. :-) ?

2 localhost commented Permalink

<p>James, you raise a good point...</p> <p>One example of what I mean is the addition of the processor hardware model to SMF 70 in z/OS R.7 RMF. (I was pleased when I asked them to put it in that they did.) So you now know that not only is your machine a z990 Model 309 but it's actually got 4 books. i.e it's physically a D32.</p> <p>Now, you raise a good question as to whether the ARM standard should contain all this information or not. I would think it should - but, as I've confessed before, I'm not working actively with ARM yet. To me there were short term gains in enhancing SMF, and RMF in particular.</p> <p>I can certainly see that any installation managing a traditional server farm would have challenges in keeping track of what each server was, and the various settings in force on each server (whether hardware or the software stack).</p> <p>While I don't suppose people are running thousands of "z" mainframes (or even thousands of "z" LPARs) I can see keeping track of stuff can be a challenge.</p> <p>And part of the point of this blog entry is to help me understand whether it's just me that thinks this kind of self-documentation is important.</p>