In our BPCS 405 CD on OS/400 V5R1 there are several areas where company policies, modifications, equipment used, or lack of what I just said, can have an effect on speed of sign on. Many of these might also be true for your version at your company.
It has been a while since I saw the particulars, but some place there is 
documentation how much "gas" a PC is supposed to have to support Client 
Access and various versions of BPCS, in which a PC whose speed, memory, 
processor, etc. etc. is marginal, ought not to be running more than some 
number of CA sessions, or not running many other aps at same time as CA.
Also look at other stuff on that PC ... there are things that can 
contribute to slow operation of a PC that are independent of the 
application that is slow.
There is hardware you can upgrade to help your 400 run faster, not just 
sign-on.
There are 3rd party enhancements for BPCS to help all of BPCS run much 
faster, not just sign-on.
OS/400 has a topic called performance, which has to do with the efficiency 
of operations overall, some of which impact speed of signon, but I consider 
other areas more critical.  MIDRANGE_L is the place to ask about that, and 
there is probably relevant stuff in their archives.
It is an advanced topic of system administration that I think should be 
required for programmers because what we do, and how we do it, has a big 
impact here.  IBM has technical classes in excess of a week on this 
topic.  There are manuals, 3rd party books, and lots of articles in the 400 
trade press.
OS/400 has a number of settings for your installation.
WRKSYSVAL then select *SEC (security values) then for particular values do 5 (view the setting) then F1 for an explanation. What is the smallest number of characters you think is reasonable for a user-id and a password?
Less security means faster access.  It is a trade off.

Depending on how the PC access is setup, you can have the PC remember the password, so you never have to key it in. I think there should be a corporate policy whether this is an approved practice.
After keying password and press enter, up pops an OS/400 screen informing 
the user of last time they signed on, and how many failed attempts ... I 
like this because if any other person been using my sign on, I can deduce 
it.  Many co-workers could not be bothered.  You can change user profile to 
skip this.
Something I did recently.  Study the total number of jobs on the system, 
including those that created unprinted reports.  OS/400 has job structures 
to keep track of all this stuff, and when that fills up, the system has 
lock ups and sluggishness, rebuilding additional work areas.  The 
sluggishness most likely to hit right as someone signing on or starting a 
new batch program.
After I mucked in this area, and encouraged people to review their reports 
to see what could be killed, our performance increased dramatically.
How many times do people have to key in their password, and is it the same 
one all places?  There is a computer industry standard concept known as 
single sign-on.  You have to get to some level of OS (all OS) to implement 
this.  Check it out.
When BPCS is launched by OS/400 sign-on, as specified by the user profile, 
it runs a CL program called BPCSMENU, to which modifications can be added 
VERY CAREFULLY.  OS/400 is optimized to help certain operations function 
more efficiently than others.  This means that rarely used actions like 
sign-on.off start/end programs as opposed to running the stuff, suffers, 
because optimization goes to efficiency of running the actual software.  I 
suppose you could dig into how that is done, and turn it around so that 
start stop goes fast as greased lightning and locks up everything else.
Clare mentioned indexes over files uniquely involved in sign on.
Seems to me that IIM and some other files are very heavily used throughout all BPCS operations, so there may be other indexes that are wise.
There are hassles associated with sign on ... there may be some time-out 
setting that can be adjusted in the Client Access connections.  You can get 
clues from DSPLOG ... notice that during sign on there are several events 
... do they sometimes seem to take too long from step to step?  It may be 
related to time of day and what all else is running on the system.  It may 
be related to how that user is connected to the 400.
Seems to me, an emulation of an emulation of an emulation is not as fast as 
the real thing.  Each emulation contributes to stuff going more slowly, 
because the real thing has to be translated, so a review of the reasons for 
various hardware decisions may be worth while to see if the financial 
savings from getting other than the real thing, justifies the costs in loss 
of productivity, when launching OS/400 and BPCS tasks.
A person, powering on, then signing onto a green screen that is directly 
connected to the AS/400 (same building) then start some BPCS program.  That 
runs noticably faster than someone doing same thing on a PC or from a green 
screen that is connected to the AS/400 over some communication line.  Some 
of those reasons for more slowly are unavoidable for many reasons, but you 
can break the reasons down into steps, to be addressed individually, to see 
if something can be done to help overall productivity.
Hi all

Does anyone have any ingenious methods of speeding up the initial signon to
BPCS (we are on v6.01.00 GA Mixed mode).

I don't want to move menus/options as this will create more work when
upgrade time comes around.

thanks


Regards

Martin Bath
Global IT Group
Invensys Controls
Tel:      +44 (0) 1752 724388
Mobile: +44 (0) 7736 017318
Fax :    +44 (0) 1752 732455
Email : martin.bath@xxxxxxxxxxxx

CONFIDENTIALITY NOTICE
This e-mail and any attachments are confidential and also may be privileged.
If you are not the named recipient, or have otherwise received this
communication in error, please delete it from your inbox, notify the sender
immediately, and do not disclose its contents to any other person, use them
for any purpose, or store or copy them in any medium. Thank you for your
cooperation.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact copyright@midrange.com.

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.