<snip> I believe that this thread demonstrates what the problem is: its overly complicated. </snip>
Not the way I have read the thread. I'd bet that every function that is provided is used by some program. That makes it a function with a lot of (useful) options. And no one has demonstrated anything complex about using it. Is filling in a parameter area a nuisance? Maybe. Is it hard? No. An executable macro could have been provided to hide your filling in the parameter list. The cost did not warrant it 20 years ago. And still does not. >Why not just a simple service to look up the value of a system symbol? Because it is not cost-justified. I'm still waiting for someone to provide a clear reason to have such as "call" as you show. And if you truly want to do it, it is already available in REXX. And the function is available, albeit not as you write as a "simple service". When functionality is available, it is often more prudent to spend limited resources doing things that are not already available than to provide another way to do what can already be done. <snip> ...avoiding a mapping macro like ASASYMBP means that the simple service could easily have an AMODE64 version, whereas ASASYMBM is only AMODE31 and requires 31-bit storage. </snip> "Easily" is an interesting term. If there were a business case for ASASYMBM needing to support AMODE 64 and storage above the bar, then doing so would be considered. If it were so "easy" (and cost-justified) then there would be far fewer services (particularly those that have existed since way before AMODE 64) that do not accept AMODE 64, let alone data above 2G. Having it be a callable service does not make it appreciably easier to create an AMODE 64 analog than having there be a parameter area. 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
