Peter Relson wrote >>The sample showed use of ALESERV EXTRACTH and ALESERV ADD.
>>FYI, ALESERV EXTRACTH "works" as you want, but the far more direct mechanism >>of >>PSAAOLD -> ASCBASSB -> ASSBSTKN is also fully supported for getting home's >>STOKEN. Yes, we're a bit simple minded and tend to use IBM macros where they exist, although it's not a hard and fast rule. I'm sure one could argue endlessly about the pros and cons of using IBM CB fields rather than the macros provided by IBM for lots of things, but at the end of the day maybe there can be too much concern for saving a few picoseconds where it is completely unimportant, at the cost perhaps of other aspects of (good) programming. This code is executed once when an address space starts. I doubt we'd make noticeable savings by directly accessing some CB field. This also avoids any need to check whether this or that CB field is an official interface, not to mention that it might help the less experienced when they can just look up the macro documentation to see what is going on. Still, another possibility to tell customers we've reduced instruction paths. >>ALESERV ADD for an address space is allowed only for a non-swappable space. Indeed we do a TRANSWAP in CAS when starting the DAS, then OKSWAP after the DAS xm-posts its completion of initialization. After that things run quite happily swappable (in the case of the product this code came from anyway). But in fact it's the IARVSERV SHARE that otherwise blows up (with a 6C5), not ALESERV ADD. I do wonder if the sample was actually useful to someone. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
