- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: channelcnt sysgen
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-29-2009 04:01 PM
тАО06-29-2009 04:01 PM
The CHANNELCNT SYSGEN parameter value for your system is too low. Actual: 256; recommended minimum: 4096
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-29-2009 04:19 PM
тАО06-29-2009 04:19 PM
Solutionthis thread will take you through the methods available and the pros and cons :-
http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1246320890003+28353475&threadId=1071631
hth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-29-2009 05:17 PM
тАО06-29-2009 05:17 PM
Re: channelcnt sysgen
To supplement Mark's comment, please carefully note the use of MODPARAMS.DAT and AUTOGEN.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-05-2009 05:29 PM
тАО07-05-2009 05:29 PM
Re: channelcnt sysgen
modify/bytml=4000 system in uaf utility.
however the program keeps readin the old value. i have also restart the machine.
1)how can i see what is the current value
2) how can i change this bytml.
thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-05-2009 11:02 PM
тАО07-05-2009 11:02 PM
Re: channelcnt sysgen
I assume you are trying to modify the bytlm (there is no bytml) of the SYSTEM username using a command like:
UAF> modify system /bytlm=4000
That will change the authorized value and the next time that user logs in, the value in the UAF will be read and used when determining the limit applied to the process. However, it is not the only limit affecting the new process. An authorized value of 4000 will probably not have any effect, since the SYSGEN parameter PQL_MBYTLM is probably set to a value higher than 4000. Four thousand bytes is probably less than the minimum requirement for many things, and the PQL_MBYTELM sysgen parameter is a lower bounds to what a newly created process will get.
Answers to your questions:
1) to see what the authorized value in the SYSUAF file for the SYSTEM username:
UAF> show SYSTEM
2) To change the bytlm for the SYSTEM username:
UAF> modify systme /bytlm=4000
but the process created may have a higher limit than specified, based on several other limits that CREPRC and LOGINOUT use, for example the PQL_%BYTLM parameters.
To see the effective bytlm, log into the SYSTEM account and issue the command:
$ write sys$output f$getjpi("","BYTLM")
I am not sure why, but on my system, the value returned by f$getjpi is < max(UAF BYTLM,PQL_MBYTLM) Perhaps someone else will know why these don't agree.
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2009 02:44 AM
тАО07-06-2009 02:44 AM
Re: channelcnt sysgen
i have loaded jdk5.0-3 and it needs 400000 bytlm to run.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2009 03:56 PM
тАО07-06-2009 03:56 PM
Re: channelcnt sysgen
I have never used the jdk, so I am not sure what it is actually checking.
Where are you seeing the 399808? from the output of UAF> show system or from f$getjpi("","BYTLM")?
My GUESS is that the jdk is using $getjpi to determine the BYTLM, but that isn't the same as the UAF value.
See this thread:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1349628
However, the offset between the UAF value (stored in the JIB at offset JIB$L_ORG_BYTLM) and the value returned by $getjpi item BYTLM (in the JIB at offset JIB$L_BYTLM) doesn't appear to be constant. Also, since this is a "pooled quota", all processes in the JOB, i.e. the main process and all its subprocesses, share it. So another process in the same job can affect the value returned by f$getjpi(pid,"BYTLM").
If I were you, I would change the UAF BYTLM to something like 500000 and be done with it.
I just tried this and it works, even though it isn't documented, so don't assume it will always be there: f$getjpi("","ORG_BYTLM")
$ write sys$output f$getsyi("ARCH_NAME"),f$getsyi("NODE_SWTYPE"),f$getsyi("NODE_SWVERS")
AlphaVMS V8.3
$ write sys$output f$getjpi("","ORG_BYTLM")
600000
$ write sys$output f$getjpi("","BYTLM")
599808
$ write sys$output f$getjpi("","BYTCNT")
599808
$
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2009 05:22 PM
тАО07-06-2009 05:22 PM
Re: channelcnt sysgen
Please report this to HP and (in the interim) set BYTLM to 10% or 25% higher than what's not working here, and move on to the next problem.
BYTLM is intended to prevent a run-away process from consuming substantial or all of pool for its I/O buffers, but (on most any reasonably tuned systems) the difference between 500,000 and 600,000 bytes is immaterial. The box I just checked is a small and old one with limited memory, and has 1,190,000 bytes free in pool.
As for another recent discussion around BYTLM, see this thread:
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1349628
You may well need to increase the size of non-paged pool (or AUTOGEN may decide to implement that increase for you, particularly if pool requirements increase and you're also using feedback tuning) as you get going with any significant change in aggregate system load.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2009 06:42 PM
тАО07-06-2009 06:42 PM
Re: channelcnt sysgen
mr jon, i used f$getjpi("","BYTLM") to get the value.i have changed the bytlm value to 500000 by using modify system/bytlm=500000. jdk is no longer giving the error of low bytlm. however the value is still 99808 when i check using f$getjpi("","BYTLM")
mr hoff, thanks for your contribution. i am still reading through ur reply and hope it gives me more knowledge about bytlm
thanks once again
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2009 11:22 PM
тАО07-06-2009 11:22 PM
Re: channelcnt sysgen
It seems that the problem is solved, why do you care if it shows that you only have 99808? Is it curiosity (not a bad thing) or is there still something that is not working?
What do you get when you use
$ write sys$output f$getjpi("","ORG_BYTLM") ! I would expect you to see 500000
Are you seeing the value 99808 after you start JRE? Are you issuing the write sys$output from the same job as the Java Runtime Environment is running in?
Try entering the commands:
$ show process/sub ! this shows all the processes in the current job
$ write sys$output f$getjpi("","ORG_BYTLM") ! this displays the initial BYTLM for the original process in the job
$ write sys$output f$getjpi("","BYTLM") ! this displays ORG_BYTLM - long-term deductions from BYTLM quota for the job
My GUESS is that something in the jdk allocates 400,000 bytes from non-paged pool and uses one of the EXE$DEBIT_BYTCNT_BYTLM* routines to deduct 400000 from both BYTCNT and BYTLM, so any call to $getjpi for item BYTLM from any process in the job will get 400000 bytes less than it did before java was started. My guess is that if you don't start the Java Runtime Environment (or whatever you are starting) that f$getjpi("","BYTLM") will return 499808 instead of 99808; also f$getjpi("","ORG_BYTLM") will return 500000 (or whatever the UAF BYTLM was set to at the time the first process in the job was created).
Do read the thread referenced by my previous entry, and also referenced by Hoff. It has the explanation, originally written by John Gillings, for the difference between ORG_BYTLM and BYTLM.
Jon