Finding cataloged and uncataloged copies of datasets

[Sam Golob]

Hi Folks,

We've just been involved in fixing three TSO commands that do 
approximately the same thing:


They find cataloged and uncataloged copies of a dataset name on your system.

The programs are:FIND (CBT File 406), FINDFILE (CBT File 300), and 
TSOFIND (CBT File 879).


The programs work by first looking up the cataloged version of the 
dataset name, and then doing a UCB scan to look at all of the DASD 
volumes on the system, and check if that dataset name exists on that 
volume.  Since UCB scan methods have changed with various versions of 
the MVS and z/OS levels, the UCB scanning method had to be updated, 
among a few other fixes that were necessary, depending on the program.


You can find the latest versions of these programs in www.cbttape.org, 
in the UPDATES section (until a new tape version comes out).  These 
three programs differ from each other, in how they are invoked, and 
whether the dataset name should, or should not, be enclosed in quotes.


Try these programs out, and pick and choose whichever ones are most 
useful to you.


All the best of everything to all of you.

Sincerely,   Sam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Where is format of Job ID documented?

[Joel C. Ewing]

There are ways in SDSF (I don't remember the details and they may have
changed) for someone with sufficient authority to display everything in
the output queues (STATUS ALL comes to mind, but it's been too long). 
If you find many Annn JOBID entries, especially with old dates, you
may have a problem.  If your installation doesn't intentionally support
any APPC apps, I wouldn't think you would find any. 

Unless things have changed.   APPC isn't functional by default but
requires an installation to take deliberate action to set up several
configuration files to define the APPC transactions to make it
functional.  If that hasn't been done, I wouldn't expect any APPC output
to exist.
Joel C Ewing

On 06/18/2016 04:00 PM, Jesse 1 Robinson wrote:
> How could I determine if APPC output is clogging my spool? I don't see any at 
> the moment.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Joel C. Ewing
> Sent: Saturday, June 18, 2016 6:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Where is format of Job ID documented?
>
> We always auto-purged older held output known to be past its usefulness and 
> for some categories of output that usefulness was a matter of hours not days. 
>
> My recollection is that after APPC came upon the scene we had to modify the 
> held-output purge command sequences or APPC output wasn't touched. 
> Makes me wonder if the folks seeing terrible performance when SDSF shows APPC 
> output could be unintentionally retaining APPC junk in their output queue 
> that has no useful function and which would be better to purge in a more 
> timely fashion.
> Joel C Ewing
>
> On 06/17/2016 02:11 PM, Jesse 1 Robinson wrote:
>> In the case of (2), Mark Zelden already explained why most of us have never 
>> seen Ann. His post reminded me of the severe performance problem when 
>> including APPC output. That goes back a long way, and I don't know if it's 
>> still a problem, but I agree with him that most shops have turned off APPC 
>> stuff SDSF either by old practice or by ongoing default in SDSF. 
>>
>> I really wonder if 'O' is ever used. When I submit a job to pull sysmods 
>> from Shopz, I can see in DA up to two additional tasks running at the same 
>> time presumably to handle the USS work. They are never called 'O' or 'U' 
>> anything. And there's 'no displayable data' when they're selected.  
>>
>> .
>> .
>> .
>> J.O.Skip Robinson
>> Southern California Edison Company
>> Electric Dragon Team Paddler
>> SHARE MVS Program Co-Manager
>> 323-715-0595 Mobile
>> 626-302-7535 Office
>> robin...@sce.com
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Charles Mills
>> Sent: Friday, June 17, 2016 10:59 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: (External):Re: Where is format of Job ID documented?
>>
>> Thanks. Dr. Merrill came closest to the answer I was looking for. The real 
>> question behind the question was "if I am processing JOB ID's what should I 
>> expect to see, and if I am presenting them to people who have never heard of 
>> JES, what should they expect to see and what does it mean?"
>>
>> Charles
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Tony Harminc
>> Sent: Friday, June 17, 2016 10:48 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Where is format of Job ID documented?
>>
>> On 15 June 2016 at 16:38, Charles Mills  wrote:
>>
>>> Yeah, I know, JOBn or Tnnn.
>>>
>>> Is there a formal description somewhere? Where?
>>>
>> It seems to me there are at least two quite different questions here:
>>
>> 1) What is the acceptable syntax for a Job ID?
>>
>> 2) What formats are seen "in the wild", and perhaps
>>
>> 3) What are the circumstances in which each can be generated?
>>
>> I think the answer to (1) is straightforward: The (perhaps obsolescent but 
>> still valid) description of a Job ID as supported by TSO's IKJPARS is "The 
>> jobname can have an optional job identifier. Each job identifier is a 
>> maximum of eight alphanumeric characters, the first of which must be an 
>> alphabetic character or one of the special characters $, #, @." So the TSO 
>> commands CANCEL,STatus, and OUTput  will enforce this, and perhaps others 
>> will too. Whether anything in the MVS Subsystem Interface enforces these 
>> rules I don't know, but I'd guess it's very unlikely. How it would return an 
>> indication of invalidity is one question, aside from the general un-SSIness 
>> of checking. So then of course each Job Entry Subsystem can do whatever it 
>> likes as fas as checking/enforcing, and those rules will presumably be 

WAIT >1 (Friday type question, a day late)

[Charles Mills]

I just had occasion to RTFM on WAIT. I'm sure WAIT with an event count
greater than one seemed like a terrific idea at the time, but has anyone
ever used it? What's an application for "wait for any two of these five
events to occur"?

I suppose one reasonable application for an event count greater than one
would be "WAIT for _all_ of these events to occur."

Charles 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Where is format of Job ID documented?

[Jesse 1 Robinson]

How could I determine if APPC output is clogging my spool? I don't see any at 
the moment.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel C. Ewing
Sent: Saturday, June 18, 2016 6:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Where is format of Job ID documented?

We always auto-purged older held output known to be past its usefulness and for 
some categories of output that usefulness was a matter of hours not days. 

My recollection is that after APPC came upon the scene we had to modify the 
held-output purge command sequences or APPC output wasn't touched. 
Makes me wonder if the folks seeing terrible performance when SDSF shows APPC 
output could be unintentionally retaining APPC junk in their output queue that 
has no useful function and which would be better to purge in a more timely 
fashion.
Joel C Ewing

On 06/17/2016 02:11 PM, Jesse 1 Robinson wrote:
> In the case of (2), Mark Zelden already explained why most of us have never 
> seen Ann. His post reminded me of the severe performance problem when 
> including APPC output. That goes back a long way, and I don't know if it's 
> still a problem, but I agree with him that most shops have turned off APPC 
> stuff SDSF either by old practice or by ongoing default in SDSF. 
>
> I really wonder if 'O' is ever used. When I submit a job to pull sysmods from 
> Shopz, I can see in DA up to two additional tasks running at the same time 
> presumably to handle the USS work. They are never called 'O' or 'U' anything. 
> And there's 'no displayable data' when they're selected.  
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Charles Mills
> Sent: Friday, June 17, 2016 10:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Where is format of Job ID documented?
>
> Thanks. Dr. Merrill came closest to the answer I was looking for. The real 
> question behind the question was "if I am processing JOB ID's what should I 
> expect to see, and if I am presenting them to people who have never heard of 
> JES, what should they expect to see and what does it mean?"
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tony Harminc
> Sent: Friday, June 17, 2016 10:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Where is format of Job ID documented?
>
> On 15 June 2016 at 16:38, Charles Mills  wrote:
>
>> Yeah, I know, JOBn or Tnnn.
>>
>> Is there a formal description somewhere? Where?
>>
> It seems to me there are at least two quite different questions here:
>
> 1) What is the acceptable syntax for a Job ID?
>
> 2) What formats are seen "in the wild", and perhaps
>
> 3) What are the circumstances in which each can be generated?
>
> I think the answer to (1) is straightforward: The (perhaps obsolescent but 
> still valid) description of a Job ID as supported by TSO's IKJPARS is "The 
> jobname can have an optional job identifier. Each job identifier is a maximum 
> of eight alphanumeric characters, the first of which must be an alphabetic 
> character or one of the special characters $, #, @." So the TSO commands 
> CANCEL,STatus, and OUTput  will enforce this, and perhaps others will too. 
> Whether anything in the MVS Subsystem Interface enforces these rules I don't 
> know, but I'd guess it's very unlikely. How it would return an indication of 
> invalidity is one question, aside from the general un-SSIness of checking. So 
> then of course each Job Entry Subsystem can do whatever it likes as fas as 
> checking/enforcing, and those rules will presumably be stricter than the 
> basic syntax.
>
> (2) has been much discussed already. I must say I've never seen an 
> Annn-format Job ID, but surely APPC is more than obsolescent now, and has 
> been for many years. In theory anyone can write a JES, and that JES could 
> have whatever rules it likes, but in practice I don't think anyone is really 
> going to be writing a JESx except perhaps as a learning exercise.
>
> (3) is a matter of anecdotes combined with actual knowledge of the code.
> Job IDs are generated by various programs, and can also come in off 
> the wire via NJE. Remotes systems such as RSCS don't have the concept 
> of a Job ID, so normally JES2 generatoes a J-type one of its own. If 
> there is an inbound one that doesn't match the rules, then what? I 
> don't know, but it shouldn't be hard to find out. Ah - looking at the 
> NJE headers reminds me that it's a 

Re: TIOT exceeded

[Lizette Koehler]

And if you search in www.ibm.com for TIOT I bet you could find some messages 
you would be interested in.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Saturday, June 18, 2016 11:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIOT exceeded
> 
> What searches have you done on IBM Main Archives and in www.ibm.com for TIOT
> information?
> 
> Have you done any internet searches?
> 
> If so, what have you found out.
> 
> It will depend on what task you are needing this information for.  DB2 handles
> it different, than say a batch job.
> 
> Have you looked at the INIT and Tuning guide for TIOT specifications.
> 
> Have you looked at this link?
> http://www-01.ibm.com/support/docview.wss?uid=isg3T165
> 
> The size of the TIOT
> The TIOT size is specified in the ALLOCxx PARMLIB member and has a default of
> 32K. This is sufficient for 1635 data sets on a single volume and 129 data
> sets with the maximum of 59 volumes defined. Before specifying large values
> for DYNVOL, on the assumption that all expansion will then be handled,
> consideration should be given to the effect on the TIOT size of jobs with
> large numbers of DD cards. If a data set, with one primary and five candidate
> volumes, was in a data class with a DYNVOL of less than 7, then 24 bytes of
> TIOT space would be required. If the same data set was using a data class with
> a DYNVOL of 20, then it would require 80 bytes of TIOT space. Since the size
> of the TIOT (or the size of all the TIOT entries for a job) is limited to the
> size specified in ALLOCXxx, when large quantities of data sets with large
> DYNVOL values are concurrently allocated, it is possible to exhaust the space
> in the TIOT.  This will result in allocation failures indicated by messages
> IEF240I or IEF491I for batch allocations or error reason codes 238 or 450
> (hexidecimal) for dynamic allocations.  Note that this is not a consideration
> for DB2, because it uses an interface to dynamic allocation, which creates an
> XTIOT.
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jake Anderson
> > Sent: Saturday, June 18, 2016 11:04 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: TIOT exceeded
> >
> > Hi
> >
> > Is there a way to know if the DD chain has approached the end or it
> > has approached the end of Chain. Is there a way to tweak the JCL to
> > overcome TIOT exceeded values ?
> >
> > Jake
> >

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TIOT exceeded

[Lizette Koehler]

What searches have you done on IBM Main Archives and in www.ibm.com for TIOT 
information?

Have you done any internet searches?

If so, what have you found out.

It will depend on what task you are needing this information for.  DB2 handles 
it different, than say a batch job.

Have you looked at the INIT and Tuning guide for TIOT specifications.

Have you looked at this link?
http://www-01.ibm.com/support/docview.wss?uid=isg3T165

The size of the TIOT
The TIOT size is specified in the ALLOCxx PARMLIB member and has a default of 
32K. This is sufficient for 1635 data sets on a single volume and 129 data sets 
with the maximum of 59 volumes defined. Before specifying large values for 
DYNVOL, on the assumption that all expansion will then be handled, 
consideration should be given to the effect on the TIOT size of jobs with large 
numbers of DD cards. If a data set, with one primary and five candidate 
volumes, was in a data class with a DYNVOL of less than 7, then 24 bytes of 
TIOT space would be required. If the same data set was using a data class with 
a DYNVOL of 20, then it would require 80 bytes of TIOT space. Since the size of 
the TIOT (or the size of all the TIOT entries for a job) is limited to the size 
specified in ALLOCXxx, when large quantities of data sets with large DYNVOL 
values are concurrently allocated, it is possible to exhaust the space in the 
TIOT.  This will result in allocation failures indicated by messages IEF240I or 
IEF491I for batch allocations or error reason codes 238 or 450 (hexidecimal) 
for dynamic allocations.  Note that this is not a consideration for DB2, 
because it uses an
interface to dynamic allocation, which creates an XTIOT.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: Saturday, June 18, 2016 11:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TIOT exceeded
> 
> Hi
> 
> Is there a way to know if the DD chain has approached the end or it has
> approached the end of Chain. Is there a way to tweak the JCL to overcome TIOT
> exceeded values ?
> 
> Jake
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

TIOT exceeded

[Jake Anderson]

Hi

Is there a way to know if the DD chain has approached the end or it has
approached the end of Chain. Is there a way to tweak the JCL to overcome
TIOT exceeded values ?

Jake

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Where is format of Job ID documented?

[Joel C. Ewing]

We always auto-purged older held output known to be past its usefulness
and for some categories of output that usefulness was a matter of hours
not days. 

My recollection is that after APPC came upon the scene we had to modify
the held-output purge command sequences or APPC output wasn't touched. 
Makes me wonder if the folks seeing terrible performance when SDSF shows
APPC output could be unintentionally retaining APPC junk in their output
queue that has no useful function and which would be better to purge in
a more timely fashion.
Joel C Ewing

On 06/17/2016 02:11 PM, Jesse 1 Robinson wrote:
> In the case of (2), Mark Zelden already explained why most of us have never 
> seen Ann. His post reminded me of the severe performance problem when 
> including APPC output. That goes back a long way, and I don't know if it's 
> still a problem, but I agree with him that most shops have turned off APPC 
> stuff SDSF either by old practice or by ongoing default in SDSF. 
>
> I really wonder if 'O' is ever used. When I submit a job to pull sysmods from 
> Shopz, I can see in DA up to two additional tasks running at the same time 
> presumably to handle the USS work. They are never called 'O' or 'U' anything. 
> And there's 'no displayable data' when they're selected.  
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Charles Mills
> Sent: Friday, June 17, 2016 10:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Where is format of Job ID documented?
>
> Thanks. Dr. Merrill came closest to the answer I was looking for. The real 
> question behind the question was "if I am processing JOB ID's what should I 
> expect to see, and if I am presenting them to people who have never heard of 
> JES, what should they expect to see and what does it mean?"
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Tony Harminc
> Sent: Friday, June 17, 2016 10:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Where is format of Job ID documented?
>
> On 15 June 2016 at 16:38, Charles Mills  wrote:
>
>> Yeah, I know, JOBn or Tnnn.
>>
>> Is there a formal description somewhere? Where?
>>
> It seems to me there are at least two quite different questions here:
>
> 1) What is the acceptable syntax for a Job ID?
>
> 2) What formats are seen "in the wild", and perhaps
>
> 3) What are the circumstances in which each can be generated?
>
> I think the answer to (1) is straightforward: The (perhaps obsolescent but 
> still valid) description of a Job ID as supported by TSO's IKJPARS is "The 
> jobname can have an optional job identifier. Each job identifier is a maximum 
> of eight alphanumeric characters, the first of which must be an alphabetic 
> character or one of the special characters $, #, @." So the TSO commands 
> CANCEL,STatus, and OUTput  will enforce this, and perhaps others will too. 
> Whether anything in the MVS Subsystem Interface enforces these rules I don't 
> know, but I'd guess it's very unlikely. How it would return an indication of 
> invalidity is one question, aside from the general un-SSIness of checking. So 
> then of course each Job Entry Subsystem can do whatever it likes as fas as 
> checking/enforcing, and those rules will presumably be stricter than the 
> basic syntax.
>
> (2) has been much discussed already. I must say I've never seen an 
> Annn-format Job ID, but surely APPC is more than obsolescent now, and has 
> been for many years. In theory anyone can write a JES, and that JES could 
> have whatever rules it likes, but in practice I don't think anyone is really 
> going to be writing a JESx except perhaps as a learning exercise.
>
> (3) is a matter of anecdotes combined with actual knowledge of the code.
> Job IDs are generated by various programs, and can also come in off the wire 
> via NJE. Remotes systems such as RSCS don't have the concept of a Job ID, so 
> normally JES2 generatoes a J-type one of its own. If there is an inbound one 
> that doesn't match the rules, then what? I don't know, but it shouldn't be 
> hard to find out. Ah - looking at the NJE headers reminds me that it's a 
> binary (16-bit!) job *number* that comes in, and then JES2 has bit flags to 
> say that it's a batch job or a started task. No TSO... Anyway
>
>


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Where is format of Job ID documented?

[Peter Hunkeler]

>The real question behind the question was "if I am processing JOB ID's what 
>should I expect to see, and if I am presenting them to people who have never 
>heard of JES, what should they expect to see and what does it mean?"




What does it mean to people that have not heard of JES? I guess such people the 
have not much knowledge about z/OS either. In that case, I'd say don't tell 
them anything about the jobid at all. Why? Because it is not telling you much 
anyway.
If I run a shell command from TSO, it will normally be run in my TSO address 
space, tos the jobid associated with this command would be Tnnn. If I run 
the command in batch, it might be running   in the batch job's AS or in a UNIX 
initiator AS (BPXAS), so the jobid would be Jnnn or Snnn, resp.. And if 
the same command is run from an STC, it mit be running in the STC's AS or again 
in a UNIX initiator AS, but the jobid will be Snnn in both cases.


But even standard MVS services might be run as STC or as batch job. Some run 
CICS or IMS as STC, some as batch job. So, CICS/IMS will show up as either 
Snnn or Jnnn.


--
Peter Hunkeler



--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New Updates to lbdsoftware.com

[suresh chacko]

Dear Lionel,

Appreciate your efforts great contributions System z World!

Best regards,

Suresh Chacko

On Fri, Jun 17, 2016 at 11:53 PM, Lionel Dyck  wrote:

> I've made a few updates:
>
>
>
> 1.   FASTPATH was updated to clear up a point and shoot bug that has
> been there for several years but only showed up today
>
> 2.   zFSTOOLS was updated with some cosmetic improvements thanks to
> Peter Giles
>
>
>
> The NEWEST addition to my site is PDSEGEN which is an ISPF dialog designed
> to provide a robust and user friendly tool for working with PDSE Version 2
> Member Generations. This tool provides the following capabilities:
>
>
>
> * Commands:  Compare member old-gen new-gen  *
>
>
>  *Copy to copy current PDSE to another/new PDSE   *
>
>
>  *Edit member *
>
>
>  *Locate member or member**
>
>
>  *Refresh - rebuild the member list   *
>
>
>  *Sort Create, Change, or User A/D*
>
>
>  *  - only one at a time  *
>
>
>  *  - A for ascending and D for descending*
>
>
>  **
>
>
>  * Selection  *
>
>
>  *   Commands: B - browse *
>
>
>  * C - compare  (for non-0 generations to gen 0)  *
>
>
>  * D - delete   (for gen 0 only)  *
>
>
>  * E - edit (for gen 0 only)  *
>
>
>  * converted to V for non-0 gen)  *
>
>
>  * M - mail the member (if enabled)   *
>
>
>  * P - promote  (for non-0 generations)   *
>
>
>  * R - recover  (for non-0 generations)   *
>
>
>  * S - select   (based on the prompt panel*
>
>
>  * O - tutorial panel *
>
>
>  * V - view   *
>
>
>  * X - execute the member (clist or rexx) *
>
>
>  * / - tutorial panel *
>
>
>
> Be aware when using it that it uses a rather (extremely) slow technique for
> determining the member generations since there is no IBM provided
> capability
> in either TSO, REXX, or ISPF. That means that the initial entry to a PDSE
> can take awhile but once you are in there it hums and really demonstrates
> the capabilities that are available with generations.
>
>
>
> As usual all of these tools are provided without warranty, guarantee, or
> promise that they will work for you and yours.  If you choose to install
> them be sure to test, test, and test again.
>
>
>
> Comements, suggestions, corrections, bug reports, etc. are welcome and
> appreciated but come with no promise that I'll be able to address them.
>
>
>
> Lionel B. Dyck <><
> Website:   http://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
*SureshNc*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN