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
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 faci
>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!
>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]>
wrot
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
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
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-
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 facil
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 under
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 d
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
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 ca
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 PROTECT
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 an
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
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 "addres
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,
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 un
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 leve
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
//
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 facili
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 o
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
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
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 t
>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 comm
-
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
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 facilitie
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 sequent
>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 / sign
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 Serv
-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 conf
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?
>
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
34 matches
Mail list logo
