Code to extract PDS members? 
Author Message
 Code to extract PDS members?

I have an old S/370 tape here with a PDS on it. I have dumped the tape to a
PC, and am wondering if code exists to extract the members. I know IBM
sometimes gives out this kind of information on the sly (I have an old book
from IBM that tells how to do some cool stuff with Displaywrite/36 folders
in RPG) and am hoping that they let the cat  out of the bag on OS/VS PDSs,
so to speak.

Thanks in advance,
David Wollmann



Sun, 05 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

The problem is that there is not enough information.  PDSs on tape are usually in one of three formats --

- IEBUPDTE
- IEBCOPY
- IEHMOVE

The first two are the more likely.

IEBUPDTE will have source records as (generally) 80 byte line elements, separated by a line element containing, generally, something like ./ ADD NAME=xxxx, with the ./ at the start of the line element.  Clearly, only text files need apply.

IEBCOPY is much harder to deal with.  Its unloaded records are documented, but you may find it very hard to deal with.

IEHMOVE is also difficult to deal with.  Its unloaded PDS format is not thesame as IEBCOPY's unloaded format.

If the unloaded PDS contains load modules, you have major trouble.  However, it's unlikely it would be useful to you.

--Steve Myers


Quote:
>I have an old S/370 tape here with a PDS on it. I have dumped the tape to a
>PC, and am wondering if code exists to extract the members. I know IBM
>sometimes gives out this kind of information on the sly (I have an old book
>from IBM that tells how to do some cool stuff with Displaywrite/36 folders
>in RPG) and am hoping that they let the cat  out of the bag on OS/VS PDSs,
>so to speak.

>Thanks in advance,
>David Wollmann


-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.



Sun, 05 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

Steve,

These data are supposed to be IBM BookManager files and images. Since I
don't know anything about BookManager (except that it ain't {*filter*} from where
I'm sittin') I'm not sure if there would be load members or not. I do have
a bad fax copy of some JCL that would seem to indicate that there are some
datasets with '.LIB' extensions. A quick browse of the tape image confirms
that these filenames show up on the tape.

My only experience with a JCL-like language is OCL, so I'm not sure what
I'm looking at, but the script does include the identifiers 'DUMP' and
'DUMPDSN' in relation to the tape. The 'DUMP' identifier's context includes
a parameter list with several glob'd args, which would have included all
the likely dataset names I've seen in the tape image.

There looks to be an index of sorts at the head of the tape, followed by
what looks like an extents map. I think I'll do what I did with the
System/23 diskettes a while back and load the tables into memory and start
playing with them.

Dave Wollmann


Quote:
> The problem is that there is not enough information.  PDSs on tape are

usually in one of three formats --
Quote:

> - IEBUPDTE
> - IEBCOPY
> - IEHMOVE

> The first two are the more likely.

> IEBUPDTE will have source records as (generally) 80 byte line elements,

separated by a line element containing, generally, something like ./ ADD
NAME=xxxx, with the ./ at the start of the line element.  Clearly, only
text files need apply.
Quote:

> IEBCOPY is much harder to deal with.  Its unloaded records are

documented, but you may find it very hard to deal with.
Quote:

> IEHMOVE is also difficult to deal with.  Its unloaded PDS format is not

thesame as IEBCOPY's unloaded format.
Quote:

> If the unloaded PDS contains load modules, you have major trouble.

However, it's unlikely it would be useful to you.


Mon, 06 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

When you say "extract the members" what do you mean.

One can certainly read the PDS' directory, and read the data in each
member of the PDS.  Many ways to do that, but I normally use QSAM to read
the directory and BPAM to read the member data.

If you wish to perhaps read and understand load modules, then you need to
understand the structure of load module PDS datasets.  The last published
documentation on this was the Linkage Editor and Loader manual from about
1985.  Unfortunately this is a licensed publication and is sort of hard to
get.

If you merely want results, to quote a friend of mine "any problem that
can be fixed by throwing money at it is no longer a problem, its just an
expense".  In that direction the Edge Portfolio Analyzer (
http://www.edge-information.com ) might be of interest.  Also PDS has been
commercialized - I beleive the current name is star tools.

Rex Widmer
Builder of software archeology tools and other strange programs to help survive in a legacy based world.



Mon, 06 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

Which manuals are you interested in?  You might consider
getting a fresh copy from IBM's CDROM or downloading it from
their website... The manuals have .BOO extensions when they
are on CDROM.  ...jg

On 19 Jun 1997 02:46:29 GMT, "David P.C. Wollmann"

Quote:

>Steve,

>These data are supposed to be IBM BookManager files and images. Since I
>don't know anything about BookManager (except that it ain't {*filter*} from where
>I'm sittin') I'm not sure if there would be load members or not. I do have
>a bad fax copy of some JCL that would seem to indicate that there are some
>datasets with '.LIB' extensions. A quick browse of the tape image confirms
>that these filenames show up on the tape.



Mon, 06 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

Dave --

There may be good news and bad news here.

There are three kinds of Bookmanager files: "book" and "bookshelf index"
files, and "bookshelf" files.

There are two kinds of bad news.  Except for bookshelf files, which are
ordinary text files, Bookmanager files are binary files that require a
reader program.  The binary files are streamed PC or UNIX like files that
contain compressed text.

I think you are describing IEBCOPY files, and I think you are describing
files dumped to a standard label tape.  The first record is probably 80
bytes containing VOL1 in bytes 1 to 4.  The next two records are 80 bytes,
containing HDR1 and HDR2 in bytes 1 to 4.  Then a tape mark, followed by
data, followed by a tape mark, then EOF1 and EOF2 records and a tape mark.

A PDS directory consists of 256 byte records.  The first two bytes of
each record are the amount of data used in the block, including the header.
What follows are member entries --

Name -- 8 bytes character
TTR -- 3 bytes binary
INDC -- 1 byte binary, from high order bit to low order bit,
   attuuuuu
   a -- Member is an alias if on
   tt -- Used only with load modules
   uuuuu -- Binary number, multiple by 2 to get number of bytes of user
         data in the member entry.
The length of a member entry is 2 * uuuuu + 12.

I don't know the exact format of the extents table.  You will need it to
transform ttr (relative track + record on track) to cchhr (a real track
address, which is dumped with the track).

IEBCOPY dumps to a V-format data set.

Each physical record on the tape will start with nnnn0000.  The nnnn
should be the exact length of the physical record.  Then there will the
data records.  Each starts with nnnnffff.  The first two bytes are the
length.  The second two bytes are flags, used only when records extend
over several blocks.  I do not remember the exact codes.  The first part
of the data area for a data block is the "count" area, which has to do
with the way the records are written on disk.  You will see
cccchhhhrrkkdddd.  The cccc part is a cylinder number, the hhhh part is
a head number, and rr is the record in the track, starting with 1, not 0.
kk is the key length (8 bytes for directory records, 0 for data records),
and dddd is the data length of the record.  An End Of File is a record
with data length 0.


Quote:
>Steve,

>These data are supposed to be IBM BookManager files and images. Since I
>don't know anything about BookManager (except that it ain't {*filter*} from where
>I'm sittin') I'm not sure if there would be load members or not. I do have
>a bad fax copy of some JCL that would seem to indicate that there are some
>datasets with '.LIB' extensions. A quick browse of the tape image confirms
>that these filenames show up on the tape.

>My only experience with a JCL-like language is OCL, so I'm not sure what
>I'm looking at, but the script does include the identifiers 'DUMP' and
>'DUMPDSN' in relation to the tape. The 'DUMP' identifier's context includes
>a parameter list with several glob'd args, which would have included all
>the likely dataset names I've seen in the tape image.

>There looks to be an index of sorts at the head of the tape, followed by
>what looks like an extents map. I think I'll do what I did with the
>System/23 diskettes a while back and load the tables into memory and start
>playing with them.

>Dave Wollmann


>> The problem is that there is not enough information.  PDSs on tape are
>usually in one of three formats --

>> - IEBUPDTE
>> - IEBCOPY
>> - IEHMOVE

>> The first two are the more likely.

>> IEBUPDTE will have source records as (generally) 80 byte line elements,
>separated by a line element containing, generally, something like ./ ADD
>NAME=xxxx, with the ./ at the start of the line element.  Clearly, only
>text files need apply.

>> IEBCOPY is much harder to deal with.  Its unloaded records are
>documented, but you may find it very hard to deal with.

>> IEHMOVE is also difficult to deal with.  Its unloaded PDS format is not
>thesame as IEBCOPY's unloaded format.

>> If the unloaded PDS contains load modules, you have major trouble.
>However, it's unlikely it would be useful to you.



Mon, 06 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

[snipped]

Quote:
> I don't know the exact format of the extents table.  You will need it to
> transform ttr (relative track + record on track) to cchhr (a real track
> address, which is dumped with the track).

Actually, you don't need to know it. The access method used to read
individual members of the PDS is BSAM. There is a "feedback" option
in the DCB as well as a field that you can supply in the READ-SF
macro. Just read the directory sequentially with a DCB opened with
KEYLEN=8, extract the desired member's information, then POINT to the
TTR with a different OPENed DCB, and read until you get an EODAD exit
taken. (Each member is separated by an EOF mark)

The directory itself will also contain an EOF mark following the
number of blocks specified at the file's allocation time. Or, if
not all of the directory blocks are occupied, you could check for
a key of all X'FF' and/or binary zeros in the 256-byte data block.

Quote:
> IEBCOPY dumps to a V-format data set.

Actually, I *think* (warning: fuzzy memory alert!) that the records
of an unloaded PDS (tape) are in VBS format.

And, finally... The EOF mark on a DASD track has to have both the
key and data lengths set to zero. Technically, the 3990/3880 books
indicated that only the data field was required to be 0, but there
were controllers on the market [for a while] that would write a key
if specified and no data if indicated as 0. Then, a lot of programs,
including QSAM, would puke if you attempted to read past what YOU had
intended to be an EOF mark, but actually had just a key written...

Sometimes the required unit-exception in the CSW would come up, and
other times it wouldn't... Don't know if any of those controllers
are still out there. I suspect that most have long since been
"retired." (I.E. Deep-6'd)

Ciao,
Bill B.



Mon, 06 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

Bill --

Actually, he DOES need to know tracks / cylinder: he is reading the PDS
member from an unloaded image on a tape that is contains track images,
not from the device itself.  What you say applies only to read a PDS
on DASD.

Many years ago I wrote a utility to perform a limited data-security erase
on a data set.  This program did a format write on each track of two
records.  The first was an ordinary EOF record (e.g., key length 0, data
length 0), but the second record contained a 48 byte key that contained
'THIS TRACK CLEARED BY THE XXX CLEAR DATA SET UTILITY", or some such
text.  I remember is was 48 bytes, though.  Never encountered a
controller that barfed on it, either, though I would not want to guess
what would happen when the record was read.  Track image readers (IEHDASDR,
FDR, DF/DSS) never had a problem.  Read Multiple Count-Key-Data should
not have a problem, but back in the days when it took two passes (read
count commands data chained together to get the count records, followed
by constructed READ commands to read the key and data area) might have
had a problem.

--Steve Myers


Quote:

>[snipped]
>> I don't know the exact format of the extents table.  You will need it to
>> transform ttr (relative track + record on track) to cchhr (a real track
>> address, which is dumped with the track).

>Actually, you don't need to know it. The access method used to read
>individual members of the PDS is BSAM. There is a "feedback" option
>in the DCB as well as a field that you can supply in the READ-SF
>macro. Just read the directory sequentially with a DCB opened with
>KEYLEN=8, extract the desired member's information, then POINT to the
>TTR with a different OPENed DCB, and read until you get an EODAD exit
>taken. (Each member is separated by an EOF mark)

>The directory itself will also contain an EOF mark following the
>number of blocks specified at the file's allocation time. Or, if
>not all of the directory blocks are occupied, you could check for
>a key of all X'FF' and/or binary zeros in the 256-byte data block.

>> IEBCOPY dumps to a V-format data set.

>Actually, I *think* (warning: fuzzy memory alert!) that the records
>of an unloaded PDS (tape) are in VBS format.

>And, finally... The EOF mark on a DASD track has to have both the
>key and data lengths set to zero. Technically, the 3990/3880 books
>indicated that only the data field was required to be 0, but there
>were controllers on the market [for a while] that would write a key
>if specified and no data if indicated as 0. Then, a lot of programs,
>including QSAM, would puke if you attempted to read past what YOU had
>intended to be an EOF mark, but actually had just a key written...

>Sometimes the required unit-exception in the CSW would come up, and
>other times it wouldn't... Don't know if any of those controllers
>are still out there. I suspect that most have long since been
>"retired." (I.E. Deep-6'd)

>Ciao,
>Bill B.

-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.



Wed, 08 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

Quote:

> Bill --

> Actually, he DOES need to know tracks / cylinder: he is reading the PDS
> member from an unloaded image on a tape that is contains track images,
> not from the device itself.  What you say applies only to read a PDS
> on DASD.

Steve,

  You have misunderstood had I meant (or maybe I didn't explain it the
way it was intended; no matter...) by saying "he doesn't need to know
it." The *actual* contents of the cchhr are meaningless except while
performing a dataset copy with FDR, et al. I'm not saying that IEBCOPY
does not keep this information. But *why* would it need to keep it?
(This [kind of] implies that the pds must go back down to the same cchh
that it was unloaded from ??? )

  And I'm still confused ??? Did I miss the orginal post ??? Perhaps..
Is the person reading from a FDR-type of backup? Then yes, I'll conceed
that cchhr is necessary to "reconstruct" the image in memory, perhaps.
Otherwise, what's the point???

Quote:
> Many years ago I wrote a utility to perform a limited data-security erase
> on a data set.  This program did a format write on each track of two
> records.  The first was an ordinary EOF record (e.g., key length 0, data
> length 0), but the second record contained a 48 byte key that contained
> 'THIS TRACK CLEARED BY THE XXX CLEAR DATA SET UTILITY", or some such
> text.  I remember is was 48 bytes, though.  Never encountered a
> controller that barfed on it, either, though I would not want to guess
> what would happen when the record was read.  Track image readers (IEHDASDR,
> FDR, DF/DSS) never had a problem.  Read Multiple Count-Key-Data should
> not have a problem, but back in the days when it took two passes (read
> count commands data chained together to get the count records, followed
> by constructed READ commands to read the key and data area) might have
> had a problem.

There are two types of track-read commands: The original (X'5E' CCW)
would
actually halt transfer opon detection of an EOF record. The later one
(X'DE' I think - don't have my "Book of Doom" handy ???) would read the
entire track regardless of content and return a final "count" field of
all X'FF's to signify the end of the track in memory. It was also a
muli-
tracked command. I.E., Automagic head-switch and next-ccw fetch if
command
chaining was indicated. The 5E could not be used within the domain of a
define-extent/locate-record; while with the DE command, def-ext/loc-rec
were required with the appropriate "intent" bits set in the loc-rec.

And as far as puking is concerned, I never said the controller
upchucked,
rather some of the programs that accessed the bogus eof indicator. Some
times the controller would signal unit-exception; and other times, not.
And by QSAM blowing chunks, it should be noted that very strange errors
would appear on the console and the users SYNAD exit would be driven
with
either an I/O error or wrong-len-record.

If you didn't have a problem with it, then I suspect you never ran your
program on "Brand-X" controllers and DASD (Email me if you want to know
"who" the offending brands were! For fear of libel, I will refrain from
mentioning any specific companies.)

Ciao,
Bill B.



Wed, 08 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

Bill --

An IEBCOPY unload is very wierd.  It has elements of highly formatted data,
and elements of a track image dump.

For every block, you have to retain the address of the block, so you can
cross-correlate the data blocks with the directory or with TTR data in the
directory (there is a second TTR in every load module directory entry) or
user TTR records, which are present in some format load modules.

For whatever reason, IEBCOPY writes count data, which contains cchhr
addresses. not TTR data.

IEBCOPY does not restore a member to the same address.  However, it needs
to be able to translate internal addresses (the second TTR pointer in the
directory, as well as TTRs in user TTR records) when it reloads the
data.

-- Steve Myers


Quote:

>> Bill --

>> Actually, he DOES need to know tracks / cylinder: he is reading the PDS
>> member from an unloaded image on a tape that is contains track images,
>> not from the device itself.  What you say applies only to read a PDS
>> on DASD.

>Steve,

>  You have misunderstood had I meant (or maybe I didn't explain it the
>way it was intended; no matter...) by saying "he doesn't need to know
>it." The *actual* contents of the cchhr are meaningless except while
>performing a dataset copy with FDR, et al. I'm not saying that IEBCOPY
>does not keep this information. But *why* would it need to keep it?
>(This [kind of] implies that the pds must go back down to the same cchh
>that it was unloaded from ??? )

>  And I'm still confused ??? Did I miss the orginal post ??? Perhaps..
>Is the person reading from a FDR-type of backup? Then yes, I'll conceed
>that cchhr is necessary to "reconstruct" the image in memory, perhaps.
>Otherwise, what's the point???

>> Many years ago I wrote a utility to perform a limited data-security erase
>> on a data set.  This program did a format write on each track of two
>> records.  The first was an ordinary EOF record (e.g., key length 0, data
>> length 0), but the second record contained a 48 byte key that contained
>> 'THIS TRACK CLEARED BY THE XXX CLEAR DATA SET UTILITY", or some such
>> text.  I remember is was 48 bytes, though.  Never encountered a
>> controller that barfed on it, either, though I would not want to guess
>> what would happen when the record was read.  Track image readers (IEHDASDR,
>> FDR, DF/DSS) never had a problem.  Read Multiple Count-Key-Data should
>> not have a problem, but back in the days when it took two passes (read
>> count commands data chained together to get the count records, followed
>> by constructed READ commands to read the key and data area) might have
>> had a problem.

>There are two types of track-read commands: The original (X'5E' CCW)
>would
>actually halt transfer opon detection of an EOF record. The later one
>(X'DE' I think - don't have my "Book of Doom" handy ???) would read the
>entire track regardless of content and return a final "count" field of
>all X'FF's to signify the end of the track in memory. It was also a
>muli-
>tracked command. I.E., Automagic head-switch and next-ccw fetch if
>command
>chaining was indicated. The 5E could not be used within the domain of a
>define-extent/locate-record; while with the DE command, def-ext/loc-rec
>were required with the appropriate "intent" bits set in the loc-rec.

>And as far as puking is concerned, I never said the controller
>upchucked,
>rather some of the programs that accessed the bogus eof indicator. Some
>times the controller would signal unit-exception; and other times, not.
>And by QSAM blowing chunks, it should be noted that very strange errors
>would appear on the console and the users SYNAD exit would be driven
>with
>either an I/O error or wrong-len-record.

>If you didn't have a problem with it, then I suspect you never ran your
>program on "Brand-X" controllers and DASD (Email me if you want to know
>"who" the offending brands were! For fear of libel, I will refrain from
>mentioning any specific companies.)

>Ciao,
>Bill B.

-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.



Wed, 08 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

DOS used to support EOF with nonzero key length.

Quote:

> Bill --

> Actually, he DOES need to know tracks / cylinder: he is reading the PDS
> member from an unloaded image on a tape that is contains track images,
> not from the device itself.  What you say applies only to read a PDS
> on DASD.

> Many years ago I wrote a utility to perform a limited data-security erase
> on a data set.  This program did a format write on each track of two
> records.  The first was an ordinary EOF record (e.g., key length 0, data
> length 0), but the second record contained a 48 byte key that contained
> 'THIS TRACK CLEARED BY THE XXX CLEAR DATA SET UTILITY", or some such
> text.  I remember is was 48 bytes, though.  Never encountered a
> controller that barfed on it, either, though I would not want to guess
> what would happen when the record was read.  Track image readers (IEHDASDR,
> FDR, DF/DSS) never had a problem.  Read Multiple Count-Key-Data should
> not have a problem, but back in the days when it took two passes (read
> count commands data chained together to get the count records, followed
> by constructed READ commands to read the key and data area) might have
> had a problem.

> --Steve Myers

--

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.



Sat, 11 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

I believe it is at least possible to write files with absolute disk
addresses in them, which would require the unloaded data set to be
restored to the exact same disk blocks.   Presumably, when the PDS
is restored, and the unmovable option is not set, then new track
addresses could be computed.

I believe that I once knew that IEHMOVE unloaded PDS were
RECFM=FB, LRECL=80, BLKSIZE=800, but I never tried to look inside one.

-- glen



Sun, 19 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

Quote:

> I believe it is at least possible to write files with absolute disk
> addresses in them, which would require the unloaded data set to be
> restored to the exact same disk blocks.   Presumably, when the PDS
> is restored, and the unmovable option is not set, then new track
> addresses could be computed.

> I believe that I once knew that IEHMOVE unloaded PDS were
> RECFM=FB, LRECL=80, BLKSIZE=800, but I never tried to look inside one.

> -- glen

1. The PDS directory can be opened with LRECL/BLKSIZE=256.
2. The list is terminated with a member name of all FF.
3. You can open the directory and simultaneously open the
   members.

In reality, using things like STOW only all 0 and all F are
names you can't use. Everything else is legal.

DON'T DO WHAT YOU SAID ABOVE. Remember (you probably don't or you
would not be advocating this) where OS/360 used fixed disk
addresses inside of SVCLIB? You had to run a utility whenever
you played with SVCLIB to restore the new values. This was
a royal pain in the ...!



Sun, 19 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?


writes:

Quote:

>..snip

>DON'T DO WHAT YOU SAID ABOVE. Remember (you probably don't or you
>would not be advocating this) where OS/360 used fixed disk
>addresses inside of SVCLIB? You had to run a utility whenever
>you played with SVCLIB to restore the new values. This was
>a royal pain in the ...!

The utility (IEHIOSUP) did something even trickier.

SVCLIB had a serious performance problem: the PDS directory.  The idea
of SVCLIB was to provide an extension of the system.  The requirements
for the members were extreme: very short length (1024 bytes), and no
address constants.

For these modules, the PDS directory search took longer than the actual I/O
to read the module, since only one data block had to be read, and its
location and length were in the directory entry.

For heavy users -- initially OPEN, CLOSE and EOV -- a trick was devised.
A table was placed in each module, at a defined location, which showed
the last two characters (if I remember correctly), and the disk address
(in TTR format) for every module transferred to by the present module.
It was the job of IEHIOSUP to seek out and store values in these tables.
With this information the directory search was bypassed.

You had to run IEHIOSUP
- When creating SVCLIB (for example, in a SYSGEN)
- When updating SVCLIB
- When moving SVCLIB

The good news was it ran quickly,

I never thought it was such a pain in the a--.  You just ran it
whenever there was the slightest chance it would be needed.

These tables made SYS1.SVCLIB unmovable only in a minor sense.  You
could move it to your hearts content, so long as you reran IEHIOSUP.

-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.



Sun, 19 Dec 1999 03:00:00 GMT  
 Code to extract PDS members?

Quote:

> DON'T DO WHAT YOU SAID ABOVE. Remember (you probably don't or you
> would not be advocating this) where OS/360 used fixed disk
> addresses inside of SVCLIB? You had to run a utility whenever
> you played with SVCLIB to restore the new values. This was
> a royal pain in the ...!

Actually, IEHIOSUP updated TTRs, not MBBCCHHRs, in the Where To Go (WTG)
table. Even today IBM is telling us WTG <g>?

--

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.



Fri, 24 Dec 1999 03:00:00 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Dynalloc for a PDS member

2. Reading dynamicaly of member(s) of PDS

3. Arrrgh. PDS Member names

4. Trap PDS member update / recognize SRB mode

5. mvs assembler stow macro pds add member not working

6. Reading dynamicaly member(s) of PDS

7. Processing PDS members

8. REXX/TSO to get PDS member SIZE from directory

9. PDS members

10. PDS Member Statistics

11. REXX MVS/TSO reading of PDS datasets(38,000 members) -Reply

12. REXX MVS/TSO reading of PDS datasets(38,000 members)

 

 
Powered by phpBB® Forum Software