|
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 mailing list archive is Copyright 1997-2024 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 [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
