On Thu, 6 Sep 2007 18:52:15 -0500, Ed Gould wrote: >On Sep 6, 2007, at 6:25 PM, Paul Gilmartin wrote: > >> On Thu, 6 Sep 2007 14:27:42 -0500, Ed Gould wrote: >>> >>>> IBM designers fail to understand that doing something half right >>>> twice is >>>> simply not as good as doing it fully right once. Why didn't they >>>> invest >>>> the same resource to provide a single facility with both >>>> capabilities? >>>> >>>> Conway's law strikes again. >>> >>> Not necessarily... You have to look at the utilities manual and see >>> the exact sequence of the parm list that is to be supplied, if it >>> isn't then you are out of luck. BTW you are SOL if you try and get >>> the utilities to change as most (all?) of them are probably >>> functionally stabilized. *IF* attachmvs has its own then you probably >>> should ask for a conforming parm CP to be created. IIRC the utilities >>> are pretty standard in their requirements (nothing special) for parm >>> being passed. I am not defending IBM but the utilities have done it >>> this way for 20+ years and it would take an act of god to get IBM to >>> change them (WAD). >>> You might have better luck asking for a new set of utilities (god >>> knows they are needed) that conform to the attachmvs cp . In any case >>> I think you are out of luck. >>> >> Huh ??? >> >> I raised no issue with the programming interface to the utilities >> (at least not in this thread). It is exactly that of the LINK >> and ATTACH MACROs, and exactly that of ATTCHMVS. To change it would >> affect far more than the utilities. >> >> My complaint is that there's an interface from Rexx that supports >> the full capabilities of ATTACH's parameter list, and another that >> allows calling a program in the authorized state, but none that >> supports both. >> >Gil, to me its a two issue problem. One: the calling parm issue. I >just cannot believe that IBM would come up with a "non standard" parm >list . The published standard is just that standard. If attachmvs is >not honoring the standard then it should be either changed or an >option on the the command to make a standard calling list should be >put onto the command. At the moment I don't have access to the parm >list that attachmvs creates. You will have to find it and examine it >against the utilities parm list and go after IBM if it is either >incorrect(don't agree) or figure out how to get attachmvs to correct >the "apparent" discrepancy. In either case it is simply an IBM issue >as the grandfather clause should hold them to correcting the issue. >It is also possible that maybe IBM will figure out a way to skate >from the seemingly inconsistent parm passing. > >It could be as simple as the parm you are passing is incorrect and >once you correct it the utility should work as advertised. Please >look at the manual for invoking the utilities from another program. >It was at one time clearly documented. If it isn't now, then open a >doc apar. My memory is really foggy on the parm You should look at a >manual for the final word. > Huh ??
I have written in this thread that the parameter list supplied by ATTCHMVS is compatible with that supplied by CALL and compatible with the alternate DDNAME list employed by the utilities. Why do you believe otherwise, or believe that I said otherwise, or wish to prove that I said something incorrect? What I see as a deficiency is that ATTCHMVS can not invoke programs in the APF authorized state. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
