Primary and secondary cell counts are not provided on IARCP64 simply because the value of providing such a thing is far less (if there was any at all) than the cost of providing it. It makes sense for CPOOL because GETMAIN (STORAGE OBTAIN) is in 8-byte increments. But storage above-2G is in 1M increments even if you only want 8 bytes. Once you have to get 1M anyway, do you really care about primary vs secondary? There is danger in presuming that "old needs" apply to "new situations".
Whether IBM's documentation is deficient our not, the fact is that the official documentation -- namely things that you can rely upon and we will take an APAR to correct (whether that be a correction in code or a correction in the documentation) -- is what is in the books, not what might or might not be in a macro prolog. It is not infrequent that additional data that is in a macro prolog and not in a book is not part of the intended programming interface. And it is all to frequent that useful and necessary data is in neither a macro prolog nor a book. The thing I happen to prefer about macro prologs is that the syntax diagrams of many of the newer macros are hierarchical and (to me) easier to understand than the "brackets and braces" style of most of the IBM books, when it comes to what is required with what. New major functional areas may have their own books and use railroad-track syntax diagrams which, while cumbersome, at least do let you see the complete syntax too. It is quite unlikely that the large amount of resources to change from brackets and braces to either other style will be allotted. FWIW, IARCP64 might not have been a good one to complain about. Before complaining about IARCP64, did anyone actually compare the book to the macro prolog before making sweeping generalizations? I ask this because this macro happens to be one for which the book chapter was, to a large extent, created from the same source that produced the macro prolog. The book chapter for this macro might even be more correct than the macro prolog. Still, there's always the possibility of errors, and always plenty of opportunity for improving documentation. Taking IARCP64 as an example, it might be worth having a discussion of things that you the users prefer in the macro prolog "style" to the book chapter "style". And I'm also curious about omissions you might find. For example, it is fully intentional that the modify form is not part of the book chapter - if anything, the macro is in error in not preventing MF=M from being specified. Feel free to send me notes offline (or, if you think the discussion will be helpful to the group, post there). Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
