In 4244327715204510.wa.paulgboulderaim@listserv.ua.edu, on
09/11/2012
at 08:42 AM, Paul Gilmartin paulgboul...@aim.com said:
You veered away from the topic of my question
I was addressing different issues; whether a fake [BQ]SAM read of the
directory returns actual TTR's at all, and
In p0624080bcc7321fafda9@[192.168.1.11], on 09/10/2012
at 01:03 AM, Robert A. Rosenberg hal9...@panix.com said:
At 15:30 -0400 on 09/07/2012, Shmuel Metz (Seymour J.) wrote about
Re: Anyone know how to copy a PDS directory as a flat file?:
Got paraphrase of WAD.
Broken as designed?
That
In 000801cd8f44$116df7a0$3449e6e0$@att.net, on 09/10/2012
at 06:04 AM, Kenneth J. Kripke kenneth_kri...@att.net said:
Next will come the member NAME, ttr, C field, and, the number of
TTRN's. You will want to AND out the C field. Then multiply the
number of ttrn's by 2 to convert to bytes.
Ref: z/os V1R13.0 DFSMS Using Data Sets, SC26-7410-11
This has the structure of a PDS Directory Block.
Since you will be most likely be using QSAM to process, the first half word
will contain the maximum number of bytes used in the directory block. You
won't see the COUNT and KEY fields of
On Mon, 10 Sep 2012 01:03:31 -0400, Robert A. Rosenberg wrote:
In this case it is WAD if you want to find the entries in any of the
PDS and PDS(E) Libraries in the concatenation ignoring any HFS
libraries encountered (and if the same name occurs in more than one
library, return the first one
Paul Gilmartin's point---that consistent values among DDLIST, DESERV,
and BLDL outputs is desirable---is important. Its importance would
indeed be hard to exaggerate.
Moreover, the time for jibbing at mixed-case values in reporting
contexts is long past. They are not, as they should be, usable
On Fri, 7 Sep 2012 08:19:53 -0400, Shmuel Metz (Seymour J.) wrote:
BTW, I saw a quote from an earlier message, but not the message
itself, talking about reading directory blocks from a PDSE. For the
record, those are not the actual PDSE directory blocks[1][2] but fake
blocks made to look like
See 'z/OS V1R12 DFSMS Using Data Sets', Chapter 26. It has a section titled
'Reading a PDS Directory Sequentially'. Chapter 27 has a similar section for
reading a PDSE directory.
Chris Blaicher
Senior Software Engineer, Software Services
Syncsort Incorporated
50 Tice Boulevard, Woodcliff
At 10:05 -0500 on 09/06/2012, Kirk Wolf wrote about Re: Anyone know
how to copy a PDS directory as a flat file?:
But don't PDS directory blocks have keys on disk? IEBGENER won't copy
those - your target dataset will be regular DSORG=PS.
You can ignore the existence of the keys. Their sole
At 15:30 -0400 on 09/07/2012, Shmuel Metz (Seymour J.) wrote about
Re: Anyone know how to copy a PDS directory as a flat file?:
Got paraphrase of WAD.
Broken as designed?
That is BAD - ie: The design is wrong but the code works as the
design says it should.
WAD is Working As Designed -
(The OP would be you, right?)
Yup. That's what makes me the expert on what his question meant.
However, you cannot sequentially read a UNIX directory.
Bummer indeed. I need a module that can sort out four cases, given a z/OS file
name.
- It is a sequential conventional dataset or PDS
In 07df01cd8c4d$b1408b20$13c1a160$@mcn.org, on 09/06/2012
at 09:35 AM, Charles Mills charl...@mcn.org said:
Did you read my preceding post? g
The one that denied the key field for PDS directory blocks? ;-)
BTW, I saw a quote from an earlier message, but not the message
itself, talking about
On Fri, 7 Sep 2012 07:03:10 -0700, Charles Mills wrote:
How many times has this wheel been re-invented?
Yeah, I could use DESERV for the PDS instead of reading the directory,
Does DESERV understand UNIX directories? ISTR not.
And I suspect that ISPF still relies on reading PDS(E) directories
And I suspect that ISPF still relies on reading PDS(E) directories as PS data
sets rather than using DESERV
I would be astounded if ISPF doesn't use standard services.
Since the format of PDSEs has never been published, and since directory space
can be created when needed in non-contiguous
I seriously doubt ISPF can read the directory as a PS data set
But that's the thing -- anyone can. It's fairly trivial. Follow the PDS
directory read documentation, and it works like magic on a PDSE. (I have no
knowledge or opinion on what ISPF actually does.)
Charles
-Original
On Fri, 7 Sep 2012 15:30:25 -0400, Shmuel Metz (Seymour J.) wrote:
Got paraphrase of WAD.
Broken as designed?
Something to the effect that DDLIST was designed to use ISPF
services to support ISPF functions, and ISPF has no service to
scan a UNIX directory. They also mentioned that DDLIST is
On 8/09/2012 1:49 AM, Bob Shannon wrote:
Since the format of PDSEs has never been published, and since directory space
can be created when
needed in non-contiguous areas, I seriously doubt ISPF can read the directory
as a PS data set.
Well, if reading the directory with QSAM or BSAM counts,
I want to make a PS (flat file) copy of the series of 256-byte blocks of a
PDS directory. (I want to copy the data to another platform so I can test
some code with it more readily.)
I tried
//GENEREXEC PGM=IEBGENER
//SYSUT1 DD
Specify LRECL
On Thu, 6 Sep 2012 06:28:42 -0700, Charles Mills wrote:
I want to make a PS (flat file) copy of the series of 256-byte blocks of a
PDS directory. (I want to copy the data to another platform so I can test
some code with it more readily.)
I tried
//GENEREXEC PGM=IEBGENER
Charles,
If I recall when writing an Assembler Program for a STOW macro there were
some pointers on how to dump a PDS Directory. And I think there may be
information in the ISPF Manuals as well.
Though I think you are better served by doing this with an assembler
program. Also, remember IBM
Charles,
You can create the file using IEFBR14 ...haven't tried to copy a directory to
it ...
Scott ford
www.identityforge.com
On Sep 6, 2012, at 9:28 AM, Charles Mills charl...@mcn.org wrote:
I want to make a PS (flat file) copy of the series of 256-byte blocks of a
PDS directory. (I want
Lizette's point that IBM can change the information in a PDS directory
without notice is of course generically correct
That conceded, such changes have been infrequent for many years; and
the functional stabilization of PDS support that came about with the
introduction of PDSEs makes further such
Assuming you have the authority to do so, superzap the F1 DSCB for your source
PDS so that its DSORG is PS instead of PO. Then do your IEBGENER. Then zap
the F1 back to PO. It might work. I have never tried this myself.
Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane *
There are also software vendors that can change the information in a PDS
directory without notice. PDSMAN and Endevor come to mind.
Regards,
John K
John Gilmore of the IBM Mainframe Discussion List
IBM-MAIN@listserv.ua.edu wrote on 09/06/2012 08:56:31 AM:
Lizette's point that IBM can change
This should work for you.
//GENEREXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=MY.CLIST,DISP=SHR,RECFM=FB,DSORG=PS,
// LRECL=256,BLKSIZE=256
//SYSUT2 DD
The content of a PDS directory can of course change. How not?
My points were two: 1) that it has been a very long time since
changes in a mapping DSECT for a PDS directory block were required,
and 2) that such changes are now highly unlikely. (Neither PDSMAN
nor Endevor makes use of new or
On Thu, 6 Sep 2012 14:14:43 +, Bill Fairchild wrote:
Assuming you have the authority to do so, superzap the F1 DSCB for your source
PDS so that its DSORG is PS instead of PO. Then do your IEBGENER. Then zap
the F1 back to PO. It might work. I have never tried this myself.
Perhaps you
I'm certain that you can read a PDS directory by specifying a DD with
DSORG=PS,RECFM=F,LRECL=256,BLKSIZE=256.
But don't PDS directory blocks have keys on disk? IEBGENER won't copy
those - your target dataset will be regular DSORG=PS.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
+1
I've used this simple method in the past
//S1 EXEC PGM=IKJEFT01
//SYSTSPRT DD DSN=YOUR.OUTPUT.FILE,DISP=(NEW,CATLG,), etc etc etc
//SYSTSIN DD *
PROF NOPREFIX
LISTDS 'YOUR.PDS' MEMBERS
- Original Message -
From: Paul Gilmartin paulgboul...@aim.com
Newsgroups:
Tony,
That will list the members, I think Charles wants the hex data found in the
directory itself. I am not sure there is an option on LISTD that will dump the
HEX data of the directory itself.
Lizette
I've used this simple method in the past
//S1 EXEC PGM=IKJEFT01
//SYSTSPRT
Chris Webster's JCL will do the job, and I like its restraint. The
input BLKSIZE= is necessary and is specified. An output BLKSIZE= is
inappropriate and is not specified.
Moreover, while I have never myself encountered a PDS directory that
filled even five 3390 crypto-cylinders, reference to
Yep, correct. I optimistically thought the OP was content with a member
list. When I want all the detail I've used SAS PROC SOURCE.
- Original Message -
From: Lizette Koehler stars...@mindspring.com
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday,
Lizette is correct. There is/was no such option.
There are a number of routines out there that provide what amount to
formatted dumps of PDS directories. C's original post did, however,
suggest that he needed a portable dataset, one he could take
elsewhere, containing the contents of such a
Ta-da! Thanks all. The below was sufficient. (And as a bonus, it didn't even
hose up my original PDS!) Thanks all.
//GENEREXEC PGM=IEBGENER
//SYSUT1 DD DSN=MY.PDS,DISP=SHR,RECFM=F,DSORG=PS,
// LRECL=256,BLKSIZE=256
Yes, I have done that in the past. I no longer own that code, so I am doing
it again. C++ this time, FWIW.
IBM could change anything at any time but I think the basic format of PDS
directories is going to outlive most of us. FWIW it's documented in Using
Datasets and there is no note that it is
But don't PDS directory blocks have keys on disk?
I don't *think* so.
In any event I just want something I can FTP to another box and that will
behave like reading the first few blocks of a PDS with B/QSAM, so the keys
don't matter to me.
Charles
-Original Message-
From: IBM Mainframe
In
CAHm_n2=y0-wuhodm8q0cyfat2edh-u8mpco4jd0o_sdjc91...@mail.gmail.com,
on 09/06/2012
at 10:05 AM, Kirk Wolf k...@dovetail.com said:
But don't PDS directory blocks have keys on disk?
Yes, but the OP asked for 256 bytes, suggesting that he doesn't need
the keys and in fact is not prepared to
In 071a01cd8c33$88e2d440$9aa87cc0$@mcn.org, on 09/06/2012
at 06:28 AM, Charles Mills charl...@mcn.org said:
Anyone know how to accomplish this, short of writing an assembler
program to do it?
Write a PL/I or REXX program to read the directory. Assuming that you
don't need the key, the DCB
Did you try IEBGENER with explicit DCB attributes?
Did you read my preceding post? g
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Thursday, September 06, 2012 9:15 AM
To:
If you are in tso 3.4 and looking at the pds directory and you issue:
SAVE LIST
you will get a sequential file with: USERID.LIST.MEMBERS
IIRC
On Thu, Sep 6, 2012 at 11:39 AM, John Gilmore jwgli...@gmail.com wrote:
Lizette is correct. There is/was no such option.
There are a number of
Try IDCAMS.
You do a REPRO of your PDS where you give the count that matches the
number of directory blocks and your output DD. You will need to specify
the INPUT DCB parameters, probably like this: DCB=(RECFM=F.LRECL=256).
The output DD can be defined as FB with LRECL=256.
This will give
Not sure what it is the OP wants but the IEHLIST may be all they need. Also
works for PDS/e.
Regards,
Herman Stocker
It is impossible to make anything foolproof, because fools are so ingenious.
-- Robert Heinlein
-Original Message-
From: IBM Mainframe Discussion List
Nope, the below is one of the answers to the OP's question. It also works
for PDSE, believe it or not.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Stocker, Herman
Sent: Thursday, September 06, 2012 11:27 AM
To:
In 07b601cd8c4a$4065bbd0$c1313370$@mcn.org, on 09/06/2012
at 09:11 AM, Charles Mills charl...@mcn.org said:
But don't PDS directory blocks have keys on disk?
I don't *think* so.
Always has, always will. From z/OS DFSMS Using Data Sets.
SC26-7410-09:
3.7.2 PDS Directory
PDS member
On Thu, 6 Sep 2012 15:30:57 -0700, Charles Mills wrote:
Nope, the below is one of the answers to the OP's question.
(The OP would be you, right?)
It also works for PDSE, believe it or not.
It says that in Using Data Sets, 3.8.11 Reading a PDSE Directory:
You can read a PDSE directory
45 matches
Mail list logo
