On Thu, 18 Oct 2007 09:43:51 -0400, in bit.listserv.ibm-main you
wrote:
>I need to read source code from a PDS member whose name I don't know until my
>program runs, much the same as the COBOL
>compiler handles "COPY memname" statements. Is dynalloc the only way to go
>about it or does zOS pro
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Howard Brazee
> Sent: Thursday, October 18, 2007 9:22 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: How to read source from a PDS member
>
>
> On Thu, 18
How about just passing the member name as a parameter in a PROC?
//MYPGM PROC MBR=NOMBR
//RUNIT EXEC PGM=MYPGM
//INPUT DD DISP=SHR,DSN=MY.PDS(&MBR)
Tim Hare
Senior Systems Programmer
Florida Department of Transportation
Tel: +1 (850) 414-4209
---
Behalf
Of Howard Brazee
Sent: Thursday, October 18, 2007 4:22 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: How to read source from a PDS member
On Thu, 18 Oct 2007 09:43:51 -0400, in bit.listserv.ibm-main you
wrote:
>I need to read source code from a PDS member whose name I don't know
>until
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Howard Brazee
Sent: Thursday, October 18, 2007 9:22 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: How to read source from a PDS member
On Thu, 18 Oct 2007 09:43:51 -0400, in bit.listserv.ibm-main you
On Thu, 18 Oct 2007 16:34:36 +0200, Itschak Mugzach wrote:
>Do you REXX? This is the best language to deal with strings, allocations and
>dynamic variables on the fly. It is also run natively under TSO (and TSO
>batch) and thus, supports ALLOC commands.
>
And under IRXJCL and Unix System Services,
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Howard Brazee
>
> On Thu, 18 Oct 2007 09:43:51 -0400, in bit.listserv.ibm-main you
> wrote:
>
> >I need to read source code from a PDS member whose name I don't know
> >until my program runs, much the same as the COB
On Thu, 18 Oct 2007 08:21:44 -0600 Howard Brazee <[EMAIL PROTECTED]> wrote:
:>On Thu, 18 Oct 2007 09:43:51 -0400, in bit.listserv.ibm-main you
:>wrote:
:>>I need to read source code from a PDS member whose name I don't know until
my program runs, much the same as the COBOL
:>>compiler handles "
>On Thu, 18 Oct 2007 09:43:51 -0400, bit.listserv.ibm-main wrote:
>
>I need to read source code from a PDS member whose name I don't know
>until my program runs, much the same as the COBOL
>compiler handles "COPY memname" statements. Is dynalloc the only way to
>go about it or does zOS provide a
www.cbttape.org
there is a subroutine that is callable from Cobol that will let you read a
member of a PDS
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET
---
We've updated Harold's nice subroutine in order to be 31-bit compliant. I will
send you a copy if you like.
How about sending it to the CBT site and share with all comers?
From: "Rich Szabo" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To:
Sent: Friday, October 19, 2007 8:06 AM
Subject: Re: How to read source from a PDS member
We've updated Harold's nice subroutine in order to be 31-bit compliant. I
will
send you a copy if y
I've done this buy using the 'OPTIONAL" phrase on the file select in
Cobol, and then using TSO Allocate and Free commands from inside the
program itself.
The Program needs to Allocate, then OPEN, Read or Write, then Close,
then Free the file. This can be repeated in a single run of the program
as
On Thu, 18 Oct 2007 20:42:28 -0400 Gerhard Postpischil <[EMAIL PROTECTED]>
wrote:
:>Paul Gilmartin wrote:
:>>> On Thu, 18 Oct 2007 17:27:02 +0200, Binyamin Dissen wrote:
:>>> BPAM is not THAT unfriendly.
:>> If it truly were "not THAT unfriendly" you'd not have troubled
:>> to write a wrapper to
We've updated Harold's nice subroutine in order to be 31-bit compliant. I will
send you a copy if you like.
Rich Szabo
State Auto Insurance
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EM
Paul Gilmartin wrote:
On Thu, 18 Oct 2007 17:27:02 +0200, Binyamin Dissen wrote:
BPAM is not THAT unfriendly.
If it truly were "not THAT unfriendly" you'd not have troubled
to write a wrapper to hide the hostility from the programmer;
nor would numerous other inventors who independently replica
On Thu, 18 Oct 2007 17:27:02 +0200, Binyamin Dissen wrote:
>
>BPAM is not THAT unfriendly.
>
If it truly were "not THAT unfriendly" you'd not have troubled
to write a wrapper to hide the hostility from the programmer;
nor would numerous other inventors who independently replicated
your effort.
>A
On Thu, 18 Oct 2007 11:24:19 -0500, Tom Schmidt wrote:
>
>z/OS has the venerable OPEN-J service that might be what you are looking for
>here. Check the z/OS publications for the OPEN macro's TYPE=J operand.
>
Those fixated on performance will object to performing an OPEN
for each member rather tha
On Thu, 18 Oct 2007 18:24:12 -0500, Paul Gilmartin wrote:
>On Thu, 18 Oct 2007 11:24:19 -0500, Tom Schmidt wrote:
>>
>>z/OS has the venerable OPEN-J service that might be what you are looking
for
>>here. Check the z/OS publications for the OPEN macro's TYPE=J operand.
>>
>Those fixated on perfor
John/OP:
You might have overlooked an interesting gem of a feature of z/OS JCL:
FREE=CLOSE.
If you need to provide several alternative tables, you might be able to do so
strictly in the enveloping JCL by doing something like this:
//SYSLIB DD DISP=SHR,FREE=CLOSE,DSN=USERS.INPUT(TABLEX)
//SYS
On Oct 18 Tom Schmidt wrote:
>You might have overlooked an interesting gem of a feature of z/OS JCL:
>FREE=CLOSE.
>If you need to provide several alternative tables, you might be able to
> do so
>strictly in the enveloping JCL by doing something like this:
>//SYSLIB DD DISP=SHR,FREE=CLOSE,DSN
On Sat, 20 Oct 2007 09:17:16 -0400, Warner Mach wrote:
>
>>z/OS does not limit DDNAMES to a single appearance in a step (although you'd
>>be surprised how many think otherwise).
>>
FSVO "z/OS". I can readily cause a failure with:
14:44:15 IAT4410 DDNAME INPUTIS DUPLICATED WITHIN STEP
Use the Language Environment routine to dynamically allocate the dataset
(member) and skip having to run TSO. Puts the program name you are
executing back in the JCL. Now if only DB2 would get smarter. Although, if you
work at, even your DB2 programs can be run from the EXEC PGM= JCL
statement.
At 21:48 -0500 on 10/18/2007, Tom Schmidt wrote about Re: How to read
source from a PDS member:
Furthermore, OPEN-J has a different path length than traditional OPEN. Run a
few benchmarks.
OPEN-J (and its companion RDJFCB) are the simplest solution in my
opinion if you are using ALC and
At 09:17 -0400 on 10/20/2007, Warner Mach wrote about Re: How to read
source from a PDS member:
When I read this I thought it was pretty neat. Never had occurred to
me that this was possible ... It is still neat to know. However, as a
practical matter I could not think of an instance where it
Robert A. Rosenberg wrote:
The advantage is that you know when you reach the end of a member as
opposed to seeing the concatenation as one large file/member (although I
have a vague impression that there is an exit than can be driven [if
defined in the exitlist to the DCB] when you do the DD sw
> The exit you're thinking of is the Open exit. When the "unlike >
> concatenation" flag is set, it will be entered for each DD.
Or the EOV exit for that matter.
> Date: Mon, 22 Oct 2007 11:05:02 -0400> From: [EMAIL PROTECTED]> Subject: Re:
> How to read so
" does.
> Date: Mon, 22 Oct 2007 11:05:02 -0400> From: [EMAIL PROTECTED]> Subject: Re:
> How to read source from a PDS member> To: IBM-MAIN@BAMA.UA.EDU> > Robert A.
> Rosenberg wrote:> > The advantage is that you know when you reach the end of
> a member
ssion List [mailto:[EMAIL PROTECTED] On
Behalf Of Kenneth E Tomiak
Sent: Sunday, October 21, 2007 8:47 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: How to read source from a PDS member
Use the Language Environment routine to dynamically allocate the dataset
(member) and skip having to run TSO. Puts the pr
29 matches
Mail list logo
