Re: PDS to Sequential Question
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
Re: PDS to Sequential Question
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. Ed -- 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
Re: PDS to Sequential Question
>From a regular TSO environment I have been using: "CALL 'SYS1.LINKLIB(IEBCOPY)'" for many years. It's under ISPF that problems show up. I am assuming that you mean not under ISPF when you refer to a 'regular TSO environment'? - Too busy driving to stop for gas! -- 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
Re: PDS to Sequential Question
>From a regular TSO environment I have been using: "CALL 'SYS1.LINKLIB(IEBCOPY)'" for many years. Believe I have also replaced SYS1.LINKLIB with a single asterisk, too. Had RECEIVE in a CLIST in the 1990's without TSOEXEC. On Wed, 5 Sep 2007 16:54:44 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>When is TSOEXEC necessary? I used to need it for RECEIVE, but I just tried it without and it worked. It's been so long since I needed it that it has vanished from my vocabulary. > >TSOEXEC (if you look it up through Help TSOEXEC) is only required when you need to invoke an APF authorised command (or programme), such as IEBCOPY. > >RECEIVE/XMIT were changed many years ago, to not require it anymore. > >SPECIAL NOTE: if you invoke TSOEXEC LOGOFF somehow under ISPF (I made it an option), you will sign off when you exit ISPF. > >- >Too busy driving to stop for gas! > >-- >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 -- 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
Re: PDS to Sequential Question
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 -- 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
Re: PDS to Sequential Question
On Sep 6, 2007, at 12:17 PM, Paul Gilmartin wrote: On Wed, 5 Sep 2007 21:06:35 -0500, Ed Gould wrote: when (in assembler) you invoke most (all?) IBM utilities to specify in a parm list the ddnames you want to use. ... In assembler you would be able to but in JCL and TSO you cannot. while Rexx "address ATTCHMVS" allows you exactly that facility. I don't know whether you consider Rexx part of TSO nowadays or not. So, "address ATTCHMVS program parm1 parm2 ..." supports supplying alternate DDNAME lists, but not invoking authorized programs; "address TSO [TSOEXEC] call *(program) parm1" supports invoking authorized programs but not supplying alternate DDNAME lists. 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. Ed -- 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
Re: PDS to Sequential Question
On Thu, 6 Sep 2007 12:04:52 -0500, Paul Gilmartin <[EMAIL PROTECTED]> wrote: > >>//COPYSRC EXEC PGM=BPXBATSL, >>// PARM='PGM /bin/cat //DD:LIB(&MEM)' >>//... >>//STDOUT DD DSN=&&SRC,DISP=(NEW,PASS), >> >Must be 1.7 or higher. Wasn't that (or 1.8?) the first release that >supports non-UNIX files as DD STDOUT? > 1.5, 1.6, or 1.7 with PTFs for APAR OA11699. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: PDS to Sequential Question
On Wed, 5 Sep 2007 21:06:35 -0500, Ed Gould wrote: > >when (in assembler) you invoke most (all?) IBM utilities to specify >in a parm list the ddnames you want to use. ... >In assembler you would be able to but in JCL and TSO you cannot. while > Rexx "address ATTCHMVS" allows you exactly that facility. I don't know whether you consider Rexx part of TSO nowadays or not. So, "address ATTCHMVS program parm1 parm2 ..." supports supplying alternate DDNAME lists, but not invoking authorized programs; "address TSO [TSOEXEC] call *(program) parm1" supports invoking authorized programs but not supplying alternate DDNAME lists. 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. -- 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
Re: PDS to Sequential Question
You are correct. The cp manpage only says that it supports //dataset format, but not specifically DDs. Sorry; I jumped to a conclusion when I read it. While I agree with your comments regarding the limitations of BPXBATSL, but in this case it does work and solves the OP requirements as I understand them. The enhancements to BPXBATCH/SL came in 1.7, but I believe that there are PTFs for previous releases. See: http://www-1.ibm.com/support/docview.wss?uid=isg1OA11699 On 9/6/07, Paul Gilmartin <[EMAIL PROTECTED]> wrote: > On Thu, 6 Sep 2007 09:47:25 -0500, Kirk Wolf wrote: > > > >- //DD(MEMBER) is supported according to the cp man page. > > > At which release? at 1.8, I see only: > > [EMAIL PROTECTED]:128$ uname -a > OS/390 18.00 03 2094 > > [EMAIL PROTECTED]:129$ man cp | grep -i dd >UNIX, the end-of-line delimiter will be added (Code page IBM-1047 >in addition, it preserves file mode, owner, and group owner, if >notes" in topic SHCMDDES.CP.5 for details on how to treat text > data. > topic SHCMDDES.CP.3.2. > behavior for cp" in topic SHCMDDES.CP.3.2. > tagging behavior for cp" in topic SHCMDDES.CP.3.2. > | Member/PartitionedDat||| > | > size, the record is padded with blanks. > one record. The last record is padded with blanks. > [EMAIL PROTECTED]:130$ > > No mention of DDNAMEs. If I missed something, what should I have looked for? > > >- UID 0 requirements for BPXBATCL "SH" option don't apply to "PGM" > > > Of course I remember an unpleasant experience with PARM='SH ...'. > But "PGM" fails to provide basic constructs such as looping, redirection, > and pipes. > > I wonder why the restriction? Is it because "SH" tries to run a login > shell, and something in /etc/profile requires spawning an authorized process? > What if I try: > > EXEC PGM=BPXBATSL,PARM='PGM /bin/sh -c "date | wc"' > > ??? I suspect that lexical limitations in BPXBATSL's parsing of its PARM > would quickly trip me up. > > -- 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 > -- 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
Re: PDS to Sequential Question
On Thu, 6 Sep 2007 09:47:25 -0500, Kirk Wolf wrote: > >- //DD(MEMBER) is supported according to the cp man page. > At which release? at 1.8, I see only: [EMAIL PROTECTED]:128$ uname -a OS/390 18.00 03 2094 [EMAIL PROTECTED]:129$ man cp | grep -i dd UNIX, the end-of-line delimiter will be added (Code page IBM-1047 in addition, it preserves file mode, owner, and group owner, if notes" in topic SHCMDDES.CP.5 for details on how to treat text data. topic SHCMDDES.CP.3.2. behavior for cp" in topic SHCMDDES.CP.3.2. tagging behavior for cp" in topic SHCMDDES.CP.3.2. | Member/PartitionedDat||| | size, the record is padded with blanks. one record. The last record is padded with blanks. [EMAIL PROTECTED]:130$ No mention of DDNAMEs. If I missed something, what should I have looked for? >- UID 0 requirements for BPXBATCL "SH" option don't apply to "PGM" > Of course I remember an unpleasant experience with PARM='SH ...'. But "PGM" fails to provide basic constructs such as looping, redirection, and pipes. I wonder why the restriction? Is it because "SH" tries to run a login shell, and something in /etc/profile requires spawning an authorized process? What if I try: EXEC PGM=BPXBATSL,PARM='PGM /bin/sh -c "date | wc"' ??? I suspect that lexical limitations in BPXBATSL's parsing of its PARM would quickly trip me up. -- 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
Re: PDS to Sequential Question
On Thu, 6 Sep 2007 10:32:42 -0500, Kirk Wolf wrote: >The results are interesting when I actually tried using the cp command >with //DD:(mem) :-) > >The "cp" command doesn't properly handle the "//DD:(member)" >syntax that fopen supports. It seems to always result in the >following error, even if the output file DCB matches: > "cp" is too smart (read complicated) for the programmers' own good. It would be better if it tried to be less UNIX-y in its handling of non-UNIX facilities and simply allowed the programmer to supply the exact argument strings to fopen() rather than synthesizing them from UNIX-style command line switches. If you have found documentation that "cp" supports the "//DD:(mem)" construct (I couldn't), you have grounds for a PMR. >But, "cat", which is *not* documented to support MVS dataset names >(although I use it all the time), works perfectly. > "cat" is better because it doesn't try to outsmart the programmer. But, as you recognize, unsupported. Can you process binary files and text files alike? >IMO, the solutions using a utility like IEBCOPY aren't ideal since >they require control cards to specify the member name, which can't be >parameterized in JCL without some other helper utility. > There have been plenty of rants about this; don't tempt me! >//COPYSRC EXEC PGM=BPXBATSL, >// PARM='PGM /bin/cat //DD:LIB(&MEM)' >//... >//STDOUT DD DSN=&&SRC,DISP=(NEW,PASS), > Must be 1.7 or higher. Wasn't that (or 1.8?) the first release that supports non-UNIX files as DD STDOUT? -- 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
Re: PDS to Sequential Question
The results are interesting when I actually tried using the cp command with //DD:(mem) :-) The "cp" command doesn't properly handle the "//DD:(member)" syntax that fopen supports. It seems to always result in the following error, even if the output file DCB matches: >>> cp: FSUM6258 cannot open file "//DD:ISPPLIB": EDC5087I The specified file charac teristics did not match those of the existing file. But, "cat", which is *not* documented to support MVS dataset names (although I use it all the time), works perfectly. So, the following JCL actually works, and allows you to use JCL PROC variables to parameterize the member name that you want to assemble, which seems important to me. It might be better just to write a small assembler program that takes a member name as a parm and copies that member from a concatenated DD to some output DD, but this works. IMO, the solutions using a utility like IEBCOPY aren't ideal since they require control cards to specify the member name, which can't be parameterized in JCL without some other helper utility. //ASMLIB PROC MEM= //COPYSRC EXEC PGM=BPXBATSL, // PARM='PGM /bin/cat //DD:LIB(&MEM)' //LIB DD DSN=PDS1,DISP=SHR // DD DSN=PDS2,DISP=SHR //... //STDERR DD SYSOUT=* //STDOUT DD DSN=&&SRC,DISP=(NEW,PASS), //SPACE=(CYL,(2,1)), //DCB=(LRECL=80,BLKSIZE=27920,RECFM=FB) //* //ASSEMBLE EXEC ASMAC //C.SYSIN DD DSN=&&SRC,DISP=(OLD,DELETE) // PEND Kirk Wolf Dovetailed Technologies -- 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
Re: PDS to Sequential Question
I was trying to help by suggesting a solution that met the OP requirements, but to your points: - //DD(MEMBER) is supported according to the cp man page. - UID 0 requirements for BPXBATCL "SH" option don't apply to "PGM" Kirk Wolf Dovetailed Technologies On 9/5/07, Paul Gilmartin <[EMAIL PROTECTED]> wrote: > On Wed, 5 Sep 2007 15:57:30 -0500, Kirk Wolf wrote: > > > >// EXEC PGM=BPXBATSL, > >// PARM='PGM /bin/cp //DD:LIB(&MEM) //DD:OUT' > > > o To my knowledge, the "//DD:..." construct is not documented as > a facility of /bin/cp. It may happen to work in some cases, > but if it produces unexpected or undesired results, it won't > be supported. > > o ISTR bad APF entanglements with BPXBATSL: > >#BPXBATR.1 "z/OS V1R7.0 UNIX System Services Command Reference" > >... Failure to meet the >following conditions will result in a failure when BPXBATSL is invoked. >... > > * The invoker must have an UID of 0 to issue a SH request > * The child process is not setuid or setgid to a value different from >the parent > * The spawned filename is not an external link or a sticky bit file > * The parent has enough resources to allow the child process to reside >in the same address space > > One or more of these have tripped me up in the past. > > -- 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 > -- 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
Re: PDS to Sequential Question
On Sep 5, 2007, at 5:59 PM, Paul Gilmartin wrote: On Wed, 5 Sep 2007 15:30:37 -0500, Ed Gould wrote: Its been awhile since I had to dynamically invoke IEBCOPY so if I am out of phase please just say I am wrong. The only ddname(s) that I can think of that you might need to change is sysprint and sysin, I fell into the habit of using "address ATTCHMVS" in EXECs not for IEBCOPY but for IEBGENER, where some prior step allocated a SYSPRINT that I wanted to use as SYSUT1 for a subsequent IEBGENER, or I wanted to use the SYSUT2 from IEBGENER as input to a subsequent program, all within the single EXEC. I felt it expedient to override the DDNAMEs to IEBGENER rather than FREE and re-ALLOCATE (which wouldn't have worked for temporary data sets anyway). -- gil Gil, I guess I was misunderstanding what your issue is. There is an option when (in assembler) you invoke most (all?) IBM utilities to specify in a parm list the ddnames you want to use. I don't remember the syntax exactly but essentially you pass the utility a list of ddnames and a parm list. In that list in an exact sequence (order) is a alternate ddname for each file the utility uses ie sysprint,sysin,first ddname,second ddname etc. I misunderstood what you were complaining about. I am guessing now you are complaining the names of the ddnames and not being able to "override " it. In assembler you would be able to but in JCL and TSO you cannot. while (to me) its a small complaint, its one I have lived with since day one of os/360 and don't see it as an issue or overly restrictive. Ed -- 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
Re: PDS to Sequential Question
On Sep 5, 2007, at 5:52 PM, Paul Gilmartin wrote: On Thu, 6 Sep 2007 00:46:34 +0300, Binyamin Dissen wrote: :>extract a member from this to a sequential file. C O=OUTPDS,I=INPRIV,INTEST,INPROD If "OUTPDS" is a sequential file, the result will be an IEBCOPY unloaded data set, likely not the OP's intention. I suppose if "OUTPDS" is a PDS, a subsequent IEBGENER step would fix it. Gil: Only true if the PDS is a non load module PO type data set. Not sure if this is a PDSe (but I would think the issue is the same). Ed -- 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
Re: PDS to Sequential Question
On Wed, 5 Sep 2007 15:30:37 -0500, Ed Gould wrote: > >Its been awhile since I had to dynamically invoke IEBCOPY so if I am >out of phase please just say I am wrong. >The only ddname(s) that I can think of that you might need to change >is sysprint and sysin, > I fell into the habit of using "address ATTCHMVS" in EXECs not for IEBCOPY but for IEBGENER, where some prior step allocated a SYSPRINT that I wanted to use as SYSUT1 for a subsequent IEBGENER, or I wanted to use the SYSUT2 from IEBGENER as input to a subsequent program, all within the single EXEC. I felt it expedient to override the DDNAMEs to IEBGENER rather than FREE and re-ALLOCATE (which wouldn't have worked for temporary data sets anyway). -- 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
Re: PDS to Sequential Question
On Thu, 6 Sep 2007 00:46:34 +0300, Binyamin Dissen wrote: > >:>extract a member from this to a sequential file. > > C O=OUTPDS,I=INPRIV,INTEST,INPROD > If "OUTPDS" is a sequential file, the result will be an IEBCOPY unloaded data set, likely not the OP's intention. I suppose if "OUTPDS" is a PDS, a subsequent IEBGENER step would fix it. -- 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
Re: PDS to Sequential Question
On Wed, 5 Sep 2007 15:57:30 -0500, Kirk Wolf wrote: > >// EXEC PGM=BPXBATSL, >// PARM='PGM /bin/cp //DD:LIB(&MEM) //DD:OUT' > o To my knowledge, the "//DD:..." construct is not documented as a facility of /bin/cp. It may happen to work in some cases, but if it produces unexpected or undesired results, it won't be supported. o ISTR bad APF entanglements with BPXBATSL: #BPXBATR.1 "z/OS V1R7.0 UNIX System Services Command Reference" ... Failure to meet the following conditions will result in a failure when BPXBATSL is invoked. ... * The invoker must have an UID of 0 to issue a SH request * The child process is not setuid or setgid to a value different from the parent * The spawned filename is not an external link or a sticky bit file * The parent has enough resources to allow the child process to reside in the same address space One or more of these have tripped me up in the past. -- 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
Re: PDS to Sequential Question
On Tue, 4 Sep 2007 16:36:28 -0400 "Thompson, Steve" <[EMAIL PROTECTED]> wrote: :>Ok, I confess, I'm suffering from old age. :>I know that there is a way to concatenate n PDSes together, and then :>extract a member from this to a sequential file. :>Why am I needing this? Well, I have several levels of source libraries :>(PROD, TEST, Private) and I need to pull a member from the lowest level :>and assemble it. And I'd like to have a batch job that does this so I :>don't have to fiddle with all of it when I have a complex module to be :>linked together after a few macro changes. :>IEBCOPY won't do it (well, not simply). IEBPTPCH wants to put in ASA :>control characters, IEBGENER will go sequential to pds with control :>statements. :>So anybody got an off the shelf method, standard futility solution? Why do you feel that IEBCOPY "won't" do it "simply"? //S1 EXEC PGM=IEBCOPY //OUTPDS DD whatever //INPROD DD whatever //INTEST DD whatever //INPRIV DD whatever etc. C O=OUTPDS,I=INPRIV,INTEST,INPROD S M= -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: PDS to Sequential Question
How about something like this: // PROC ASMLIB,MEM= // EXEC PGM=BPXBATSL, // PARM='PGM /bin/cp //DD:LIB(&MEM) //DD:OUT' //LIB DD DSN=PDS1,DISP=SHR // DD DSN=PDS2,DISP=SHR // DD . //OUT DD DSN=&&OUT,DISP=(NEW,PASS), // DCB=(LRECL=80,RECFM=FB) // EXEC ASMAC //C.SYSIN DD DSN=&&OUT,DISP=(OLD,DELETE) // On 9/4/07, Thompson, Steve <[EMAIL PROTECTED]> wrote: > Ok, I confess, I'm suffering from old age. > > I know that there is a way to concatenate n PDSes together, and then > extract a member from this to a sequential file. > > Why am I needing this? Well, I have several levels of source libraries > (PROD, TEST, Private) and I need to pull a member from the lowest level > and assemble it. And I'd like to have a batch job that does this so I > don't have to fiddle with all of it when I have a complex module to be > linked together after a few macro changes. > > IEBCOPY won't do it (well, not simply). IEBPTPCH wants to put in ASA > control characters, IEBGENER will go sequential to pds with control > statements. > > So anybody got an off the shelf method, standard futility solution? > > Regards, > Steve Thompson > > -- > > > > -- > 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 > -- 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
Re: PDS to Sequential Question
On Sep 5, 2007, at 12:31 PM, Paul Gilmartin wrote: On Wed, 5 Sep 2007 12:09:06 -0500, Ed Gould wrote: Indeed. I'm so accustomed to "address ATTCHMVS" for o Better PARM facilities Could you please explain "better parm facilities" , please? The address [TSO -- gil] command offers parm facilities. What more could you need? Two things: The first has been discussed ad tedium here; surely the list will prefer that I not resurrect it today. The second is the ability to pass multiple PARMs, for example alternate DDNAME lists to utilities. Gil, Its been awhile since I had to dynamically invoke IEBCOPY so if I am out of phase please just say I am wrong. The only ddname(s) that I can think of that you might need to change is sysprint and sysin, as all other ddnames can by changed by specification in sysin . If you are talking about sysut3 or sysut4 (maybe) but they are work type datasets and are worthless after the job so a temporary dataset is perfect for this. Mind you this is from a self written program so I am not sure why you would need to override the ddnames sysprint (or sysin) from TSO. Please let me know why you would need to do so from TSO. I can't think if a single reason for either sysin or sysprint, I am not saying there isn't a good reason just that I can't think of one. TSO environment allows you to re-allocate either one to a different file, so its not like batch is user definable. There are other utilities this might not be true for, I am just curious as to why you say IEBCOPY it is so needed. Ed -- 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
Re: PDS to Sequential Question
From: Paul Gilmartin <[EMAIL PROTECTED]> I regularly, now that I think of the code, use an EXEC that does CALL *(IEBCOPY) with no TSOEXEC, and used to fail when I used ATTCHMVS. Just to be on the safe side, would it be better to always code this: address tso "TSOEXEC CALL *(IEBCOPY)" Instead of this: address tso "CALL *(IEBCOPY)" ? Dave Salt See the new SimpList(tm) rollover image at: http://www.mackinney.com/products/SIM/simplist.htm _ Enter to win a night a VIP night out at TIFF http://redcarpet.sympatico.msn.ca/ -- 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
Re: PDS to Sequential Question
On Wed, 5 Sep 2007 12:09:06 -0500, Ed Gould wrote: > >> Indeed. I'm so accustomed to "address ATTCHMVS" for >> o Better PARM facilities > >Could you please explain "better parm facilities" , please? The >address [TSO -- gil] command offers parm facilities. > >What more could you need? > Two things: The first has been discussed ad tedium here; surely the list will prefer that I not resurrect it today. The second is the ability to pass multiple PARMs, for example alternate DDNAME lists to utilities. -- 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
Re: PDS to Sequential Question
On Wed, 5 Sep 2007 16:54:44 +, Ted MacNEIL wrote: >>When is TSOEXEC necessary? I used to need it for RECEIVE, but I just tried >>it without and it worked. It's been so long since I needed it that it has >>vanished from my vocabulary. > >TSOEXEC (if you look it up through Help TSOEXEC) > I just did. It says little more than you have already. > is only required when you need to invoke an APF authorised command > (or programme), such as IEBCOPY. > IEBCOPY's requirement for APF is problematical. Try LOOKAT IEB1099I for an elliptic hint. IBM cleaned up the M&C for IEB1099I and IEB1099E in response to my RCF a few years ago, but declined to clarify in the RM "when it can not avoid using a service requiring authorization", stating that IBM preferred not to commit to a specification. I don't respect that; sometimes it works, sometimes it fails, IBM won't document it. But I regularly, now that I think of the code, use an EXEC that does CALL *(IEBCOPY) with no TSOEXEC, and used to fail when I used ATTCHMVS. (I remember the failures better than the solution.) How does all that relate to AUTHPGM? >RECEIVE/XMIT were changed many years ago, to not require it anymore. > Confirmed by experience. -- 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
Re: PDS to Sequential Question
On Sep 5, 2007, at 9:06 AM, Paul Gilmartin wrote: On Tue, 4 Sep 2007 23:43:28 +, Ted MacNEIL wrote: That might yet be simpler than LM services. But beware of APF entanglements calling IEBCOPY from Rexx. address "TSO" "TSOEXEC CALL 'SYS1.LINKLIB(IEBCOPY)'" Indeed. I'm so accustomed to "address ATTCHMVS" for o Better PARM facilities ---SNIP- Gil, Could you please explain "better parm facilities" , please? The address command offers parm facilities. What more could you need? Ed -- 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
Re: PDS to Sequential Question
>When is TSOEXEC necessary? I used to need it for RECEIVE, but I just tried it >without and it worked. It's been so long since I needed it that it has >vanished from my vocabulary. TSOEXEC (if you look it up through Help TSOEXEC) is only required when you need to invoke an APF authorised command (or programme), such as IEBCOPY. RECEIVE/XMIT were changed many years ago, to not require it anymore. SPECIAL NOTE: if you invoke TSOEXEC LOGOFF somehow under ISPF (I made it an option), you will sign off when you exit ISPF. - Too busy driving to stop for gas! -- 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
Re: PDS to Sequential Question
- Too busy driving to stop for gas! -Original Message- From: Paul Gilmartin <[EMAIL PROTECTED]> Date: Wed, 5 Sep 2007 09:06:39 To:IBM-MAIN@BAMA.UA.EDU Subject: Re: PDS to Sequential Question On Tue, 4 Sep 2007 23:43:28 +, Ted MacNEIL wrote: >>That might yet be simpler than LM services. But beware of APF entanglements >>calling IEBCOPY from Rexx. > >address "TSO" "TSOEXEC CALL 'SYS1.LINKLIB(IEBCOPY)'" > Indeed. I'm so accustomed to "address ATTCHMVS" for o Better PARM facilities o Availability in IRXJCL and Unix prior to advent of "address TSO", that I often overlook CALL. When is TSOEXEC necessary? I used to need it for RECEIVE, but I just tried it without and it worked. It's been so long since I needed it that it has vanished from my vocabulary. Mark Z. is correct: RTFM says the catenand limit for LMINIT is 16. -- 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 -- 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
Re: PDS to Sequential Question
On Tue, 4 Sep 2007 23:43:28 +, Ted MacNEIL wrote: >>That might yet be simpler than LM services. But beware of APF entanglements >>calling IEBCOPY from Rexx. > >address "TSO" "TSOEXEC CALL 'SYS1.LINKLIB(IEBCOPY)'" > Indeed. I'm so accustomed to "address ATTCHMVS" for o Better PARM facilities o Availability in IRXJCL and Unix prior to advent of "address TSO", that I often overlook CALL. When is TSOEXEC necessary? I used to need it for RECEIVE, but I just tried it without and it worked. It's been so long since I needed it that it has vanished from my vocabulary. Mark Z. is correct: RTFM says the catenand limit for LMINIT is 16. -- 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
Re: PDS to Sequential Question
On Tue, 4 Sep 2007 16:09:58 -0500, Paul Gilmartin <[EMAIL PROTECTED]> wrote: >On Tue, 4 Sep 2007 16:36:28 -0400, Thompson, Steve wrote: > >>Ok, I confess, I'm suffering from old age. >> >>I know that there is a way to concatenate n PDSes together, and then >>extract a member from this to a sequential file. >> >> >>So anybody got an off the shelf method, standard futility solution? >> >ISPF LM services? > >(Well, for n<=3. Onerous restriction. Not necessarilly something >I like about IBM.) > That's news to me since I have code that uses more than 3. I thought the limit was 10 but I'm pretty sure the limit was changed to 16 sometime either in OS/390 R9 or OS/390 R10. I'm too busy (lazy?) catching up from being out of the office for a few days right now or I would look. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: PDS to Sequential Question
>That might yet be simpler than LM services. But beware of APF entanglements >calling IEBCOPY from Rexx. address "TSO" "TSOEXEC CALL 'SYS1.LINKLIB(IEBCOPY)'" - Too busy driving to stop for gas! -- 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
Re: PDS to Sequential Question
On Tue, 4 Sep 2007 17:55:58 -0400, Thompson, Steve wrote: >> >ISPF LM services? > >(Well, for n<=3. Onerous restriction. Not necessarilly something I >like about IBM.) > > >Nuts! Of course I need 5 all told. > My apologies; I shot from the hip there. In: #<<< 2.33.3 "z/OS V1R9.0 ISPF Services Guide" IBM Library Server I now find: If the ddname is allocated to one or more partitioned data sets, member names cannot be included. LMINIT allows up to 16 concatenated data sets. (I assumed that LMINIT rather than screen geometry was responsible for the limitations in the panels.) >Ok, time to roll my own. I think I'll use REXX to generate the control >cards, invoke IEBCOPY... > That might yet be simpler than LM services. But beware of APF entanglements calling IEBCOPY from Rexx. -- 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
Re: PDS to Sequential Question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Tuesday, September 04, 2007 4:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PDS to Sequential Question On Tue, 4 Sep 2007 16:36:28 -0400, Thompson, Steve wrote: >Ok, I confess, I'm suffering from old age. > >I know that there is a way to concatenate n PDSes together, and then >extract a member from this to a sequential file. > > >So anybody got an off the shelf method, standard futility solution? > ISPF LM services? (Well, for n<=3. Onerous restriction. Not necessarilly something I like about IBM.) Nuts! Of course I need 5 all told. Ok, time to roll my own. I think I'll use REXX to generate the control cards, invoke IEBCOPY... Regards, Steve Thompson -- 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
Re: PDS to Sequential Question
On Tue, 4 Sep 2007 16:36:28 -0400, Thompson, Steve wrote: >Ok, I confess, I'm suffering from old age. > >I know that there is a way to concatenate n PDSes together, and then >extract a member from this to a sequential file. > > >So anybody got an off the shelf method, standard futility solution? > ISPF LM services? (Well, for n<=3. Onerous restriction. Not necessarilly something I like about IBM.) -- 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
PDS to Sequential Question
Ok, I confess, I'm suffering from old age. I know that there is a way to concatenate n PDSes together, and then extract a member from this to a sequential file. Why am I needing this? Well, I have several levels of source libraries (PROD, TEST, Private) and I need to pull a member from the lowest level and assemble it. And I'd like to have a batch job that does this so I don't have to fiddle with all of it when I have a complex module to be linked together after a few macro changes. IEBCOPY won't do it (well, not simply). IEBPTPCH wants to put in ASA control characters, IEBGENER will go sequential to pds with control statements. So anybody got an off the shelf method, standard futility solution? Regards, Steve Thompson -- -- 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
