1748036 Members
4686 Online
108757 Solutions
New Discussion юеВ

Re: channelcnt sysgen

 
SOLVED
Go to solution
adarsh_4
Frequent Advisor

channelcnt sysgen

after loading jdk5.0-3 on vms 7.3-2. one of the check file was givin this inoformation below. how can i get this change done.

The CHANNELCNT SYSGEN parameter value for your system is too low. Actual: 256; recommended minimum: 4096
10 REPLIES 10
marsh_1
Honored Contributor
Solution

Re: channelcnt sysgen

hi,

this 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

Robert Gezelter
Honored Contributor

Re: channelcnt sysgen

adharsh,

To supplement Mark's comment, please carefully note the use of MODPARAMS.DAT and AUTOGEN.

- Bob Gezelter, http://www.rlgsc.com
adarsh_4
Frequent Advisor

Re: channelcnt sysgen

thank you mark and robert. i manage to do it. i have another issue. iam trying to modify bytml to 4000 by the following command

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
Jon Pinkley
Honored Contributor

Re: channelcnt sysgen

adarsh,

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
it depends
adarsh_4
Frequent Advisor

Re: channelcnt sysgen

thanks jon. i tried to change the value using "modify system/bytlm=400000" but the value is still 399808.

i have loaded jdk5.0-3 and it needs 400000 bytlm to run.
Jon Pinkley
Honored Contributor

Re: channelcnt sysgen

adarsh,

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
it depends
Hoff
Honored Contributor

Re: channelcnt sysgen

The provided documentation appears inadequate to the task.

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.

adarsh_4
Frequent Advisor

Re: channelcnt sysgen

thanks jon and hoff.

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
Jon Pinkley
Honored Contributor

Re: channelcnt sysgen

adarsh,

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
it depends