How does does Roscoe userid allocate space for their functions?

book

Article ID: 197725

calendar_today

Updated On:

Products

CA Roscoe

Issue/Introduction

Trying to find out how Roscoe userids allocate space internally.

Environment

z/OS any level

Roscoe r6.0 and above

Resolution

In Roscoe, all users share the same storage space.  If your talking about ETSO applications running under Roscoe, then its the  
EPL that controls that but other than that, the storage is shared by the users.  Each user has a number of bytes for certain control blocks. No   
user gets more than any other user.                                      

For every execution of the DISPLAY command there is a buffer acquired from subpool 239(SQA). The initial buffer is based off of the DISBUF=   
value specified in ROSCOE SYSIN parms.      

DISBUF= Dynamic buffer length in KB (1024 bytes). The default is 8.       
               JES2: A buffer this size is acquired in subpool 239 (SQA) for      
                every execution of the DISPLAY command. During               
                termination, global messages are written indicating the      
                number of GETMAINs for DISPLAY and the number of times       
                that the buffer was too small.  If the number of times       
                the buffer was to small is excessive, sites may want to      
                increase DISBUF=.                                            
                                                                             
In normal cases this value is sufficient However if there is a user requesting a large list, for example DIS A*, there may be an overrun of      
the initial buffer. If that should happen then the routine gets back a number of members that this buffer is overrun by and then calculates a       
new buffer size based off of this and then tries to get the information  again.  Now in the mean time the number of jobs to be displayed may have     
increased so there is a chance that this will overrun again. If this should happen we go through this calculation one more time. If it should     
fail a third time then we end this. There is a limit of two retries.

        
There is no provision to limit this SQA and it would require a change to accommodate this (A DAR).