Help,it takes too long to logon to tso!

jac...@my-deja.com

unread,

Mar 13, 2000, 3:00:00 AM3/13/00

to

It takes too long to logon to my tso, what can I
do to optimize? What may be the potential causes?
Any advice will be appreciated. TIA!

Sent via Deja.com http://www.deja.com/
Before you buy.

Frank Clarke

unread,

Mar 13, 2000, 3:00:00 AM3/13/00

to

On Mon, 13 Mar 2000 02:32:59 GMT, jac...@my-deja.com wrote:

>It takes too long to logon to my tso, what can I
>do to optimize? What may be the potential causes?
>Any advice will be appreciated. TIA!

How many datasets concatenated to [SYSPROC SYSEXEC ISPPLIB ISPMLIB
ISPSLIB ISPTLIB] ? How many are you adding when you 'optimize'? Do
you add each new dataset individually or do you gather all the changes
and reallocate once-per-DDName? Are you running special
once-when-I-logon routines? What do they do?

I don't actually want answers to these questions, but these are some
of the questions you should be asking of yourself as a first step in
diagnosing. Others will surely have more (and better) suggestions.

Frank Clarke
Member of the REXX Language Association
Join us at http://www.rexxla.org

Mark Zelden

unread,

Mar 13, 2000, 3:00:00 AM3/13/00

to

Frank Clarke wrote:
>
> On Mon, 13 Mar 2000 02:32:59 GMT, jac...@my-deja.com wrote:
>
> >It takes too long to logon to my tso, what can I
> >do to optimize? What may be the potential causes?
> >Any advice will be appreciated. TIA!
>
> How many datasets concatenated to [SYSPROC SYSEXEC ISPPLIB ISPMLIB
> ISPSLIB ISPTLIB] ? How many are you adding when you 'optimize'? Do
> you add each new dataset individually or do you gather all the changes
> and reallocate once-per-DDName? Are you running special
> once-when-I-logon routines? What do they do?
>
> I don't actually want answers to these questions, but these are some
> of the questions you should be asking of yourself as a first step in
> diagnosing. Others will surely have more (and better) suggestions.
>

May may want to check out Thomas Conley's Dynamic ISPF Share presentation.
It should be available at www.share.org.

Mark

Check out my MVS utilities page at:
http://www.flash.net/~mzelden/mvsutil.html

Kalinich, John

unread,

Mar 13, 2000, 3:00:00 AM3/13/00

to

Turn trace on in your startup CLIST/Rexx and add some time() statements. Below
are some logon times at our site.

Minimal TSO proc (no DD's) .7 sec
Normal TSO proc (29 DD's) 5.7 sec
TSO session manager proc (65 DD's) 15.1 sec

Regards,
John Kalinich
USA Logistics Systems Support Center, Saint Louis, Missouri

Thomas Conley

unread,

Mar 13, 2000, 3:00:00 AM3/13/00

to

> It takes too long to logon to my tso, what can I
> do to optimize? What may be the potential causes?
> Any advice will be appreciated. TIA!
>

There are many causes of slow TSO logon time. The most likely are STEPLIBs
in the logon proc and/or a logon clist that frees and reallocates
everything. I gave a SHARE presentation called "Dynamic ISPF" detailing a
strategy to deal with this. You can grab it at my Web site.

--
Regards,
Thomas Conley, President
Pinnacle Consulting Group, Inc.
59 Applewood Drive
Rochester, NY 14612-3501
P: (716)720-0012
F: (716)723-3713
http://users.mindex.com/pinnacle
To reply, remove the words 'consult' from my email address

Troy Allen Cross

unread,

Mar 13, 2000, 3:00:00 AM3/13/00

to

"Kalinich, John" wrote:
>
> Turn trace on in your startup CLIST/Rexx and add some time() statements. > > Below are some logon times at our site.
>
> Minimal TSO proc (no DD's) .7 sec
> Normal TSO proc (29 DD's) 5.7 sec
> TSO session manager proc (65 DD's) 15.1 sec

I was always told to use DD statement in the logon procs over ALLOC
statements in the logon clist/exec.

Has this changed?

Of course, you are not comparing DD statements to ALLOC statements. You
are just saying that every DD statement adds time to a TSO logon.

F.Y.I. Troy
--
Troy Allen Cross, Manager, Operations and Technical Support, Meshel Hall
Youngstown State University, One University Plaza, Youngstown, OH
44555-3036
A.K.A. on Internet as t...@ysu.edu

Mark L. Bartlett

unread,

Mar 13, 2000, 3:00:00 AM3/13/00

to

If your installation has a lengthy signon proc, you may not be able to
do anything about it. If this is the case, contact your TSO admin.

Otherwise:
Please provide more info.:
Connection type - lan, dial-up, direct connect
If dial-up, connection speed?

jac...@my-deja.com wrote:

> It takes too long to logon to my tso, what can I
> do to optimize? What may be the potential causes?
> Any advice will be appreciated. TIA!
>

Mark Zelden

unread,

Mar 13, 2000, 3:00:00 AM3/13/00

to

Troy Allen Cross wrote:
>
>
> I was always told to use DD statement in the logon procs over ALLOC
> statements in the logon clist/exec.
>
> Has this changed?
>

Not really. For data sets "always needed" you should allocate them
in the logon PROC. The reason is that allocation runs at privileged
dispatching priority during logon when allocating files in the
JCL. When allocating via LOGON clist you run at TSO priority, this
will probably drop you into TSO periods with a low dispatching priority
(this also depends on the setting of CNTCLIST in IEAOPTxx - even
in goal mode). Of course if you are still in compat/ips mode than
PVLDP may be set lower than TSO, but it probably is not. What you have
to do is weigh the trade off between many dynamic allocations/deallocations
of "always needed data sets" in LIBDEFs etc VS. quick logon time.

Ken Brick

unread,

Mar 14, 2000, 3:00:00 AM3/14/00

to

John wrote
>> Turn trace on in your startup CLIST/Rexx and add some time()
statements. Below
>> are some logon times at our site.

>> Minimal TSO proc (no DD's) .7 sec
>> Normal TSO proc (29 DD's) 5.7 sec
>> TSO session manager proc (65 DD's) 15.1 sec

I'm interested, generically, in what datasets do you allocate. Currently
our development logons would have around 90-100 datasets, the sysprogs
and DBA's 30-30 additional. It is my ambition to reduce the number by
using LIBDEF techniques etc. but it is not a high priority task more a
wish.

--
Ken Brick
Brick Computer Services Ltd.
kbr...@netspace.net.au
PH: 613 9817 5506
Mob. 0409009764

William H. Sweeney

unread,

Mar 14, 2000, 3:00:00 AM3/14/00

to

I usually like to allocate a minimum of datasets in the LOGON PROC (e.g.
SYSEXEC or SYSPROC, ISPF temporary VIO datasets), to minimize the
possibility of a JCL error. Then, your initial allocation should only
allocate the IBM ISPF libraries, and perhaps SDSF. After that, everything
else should try and use LIBDEFs and ALTLIBs.

Try issuing the TSO command 'ISRDDN'. This will tell you what is
allocated, and available during your session. Unfortunately, IBM includes a
lot of their libraries in the new systems, of which some are not used by
most customers, and can be removed. Almost all of the IBM products that are
used (e.g. RACF, IPCS, ISMF), and their libraries, work well with LIBDEFs
and ALTLIBs. Loadlibs (i.e. ISPLLIB) do not work well with LIBDEFs, and can
either be placed in the LinkList, or allocated in the initial allocation
PROC/EXEC. Here is an example of the RACF allocation:

/********* REXX EXEC ******************/
/* THIS IS THE EXEC TO ALLOCATE THE RACF DATASETS USING LIBDEF */
/* ONLY WHEN THEY ARE NEEDED */
"ALTLIB ACTIVATE APPLICATION(CLIST) DATASET('SYS1.HRFCLST')"
"ISPEXEC LIBDEF ISPSLIB DATASET ID('SYS1.HRFSKEL')"
"ISPEXEC LIBDEF ISPMLIB DATASET ID('SYS1.HRFMSG')"
"ISPEXEC LIBDEF ISPPLIB DATASET ID('SYS1.HRFPANL')"
/* EXEC THE RACF COMMAND */
"ISPEXEC SELECT PANEL(ICHP00)"
/* FREE IT ALL UP */
"ISPEXEC LIBDEF ISPSLIB"
"ISPEXEC LIBDEF ISPMLIB"
"ISPEXEC LIBDEF ISPPLIB"
"ALTLIB DEACTIVATE APPLICATION(CLIST)"
EXIT

You are however at the mercy of your Systems staff, as to what gets changed
in the TSO/ISPF environment. If you can cut down on the excessive over
allocation of unnecessary files, it should help.

Bill

***

Roy Gardiner

unread,

Mar 14, 2000, 3:00:00 AM3/14/00

to

> From: William H. Sweeney [mailto:whsw...@SSCMAINFRAME.COM]

> I usually like to allocate a minimum of datasets in
> the LOGON PROC (e.g. SYSEXEC or SYSPROC, ISPF temporary VIO datasets), to
minimize the
> possibility of a JCL error. Then, your initial allocation should only
> allocate the IBM ISPF libraries, and perhaps SDSF. After
> that, everything else should try and use LIBDEFs and ALTLIBs.

Check the CBT http://www.cbttape.org/ file 372 to get a faster allocate
command.

There are two extremes:

1) fastest: one piece of JCL for each TSO user, with a command does no
ALLOCS or LIBDEFS, only starts ISPF

With several hundred, possibly thousand, TSO/ISPF users this is an
administrative nightmare.

2) most comprehensive: one command for everyone which looks at who you are
and what you want and decides what libraries to allocate before starting
ISPF.

This is inevitably slower than straight JCL but easier to control.

I have done the second several times, and am quite sure many subscribers to
this group have too; does the group want to extend this thread to cover
this? I am happy to correspond off-line as well.

Regards, Roy Gardiner
---------------------------------------------------------------------------
The contents of this e-mail may be privileged and are confidential. It may not be disclosed to or used by anyone other than the addressee(s), nor copied in any way. If received in error, please advise the sender, then delete it from your system.
National Westminster Bank Plc is regulated by the Personal Investment Authority and IMRO for investment business. A member of the NatWest and Gartmore Marketing Group advising on the life assurance, pensions and unit trust products only of that Marketing Group.
Registered Office: 41 Lothbury London EC2P 2BP
Registered Number: 929027 England
---------------------------------------------------------------------------

Mark Zelden

unread,

Mar 14, 2000, 3:00:00 AM3/14/00

to

Ken Brick wrote:
>
>
> I'm interested, generically, in what datasets do you allocate. Currently
> our development logons would have around 90-100 datasets, the sysprogs
> and DBA's 30-30 additional. It is my ambition to reduce the number by
> using LIBDEF techniques etc. but it is not a high priority task more a
> wish.
>

OUCH! No wonder it takes so long (especialy if you are allocating
via logon clist). Sounds like what a serverpac distributes.
I would allocate ISPF, SDSF, a local CLIST library, (containing all
of the LIBDEF clists etc.), a local panel library, a local table
library (at least for SITECMDS), and if it is a development
system with commonly used tools, perhaps some of those data sets (for
example FILEAID). You should be able to get down to 30 data sets or
under.

At many sites I have often found libraries allocated to ISPLLIB that
are in the LNKLST, which is not necessary.