We are planning to scan documents and load via EntireX-RPC to Mainframe.
Size of each document is 220K. Planning to upload around 30 thousands documents per day.
Currently we process approximately 25 millions commands per day and have got 550 users during peak time.
Currently update commands are as follows.
What considerations should I take as I am anxious about the following :
(a) Work Part 1 : As only 25% is reserved, large records coming in could cause concerns for existing transactions. As user updates and user ET’s occur, data is written to Work Part 1 in a wraparound fashion. Once the updates wraparound, a check is made to see if the data to be overwritten has been ET’d and if it has been flushed to Associator and Data Storage. If it has not been Buffer Flushed, then a Buffer Flush is issued. If the user to be overwritten has not been ET’d, then that user is backed out and a response code 9.
(b) Increase in buffer flush could affect performance.
© By how much should LP sizing be increased ? Currently it is 420000.
(d) Should other parameters like TT or NISNHQ be increased ?
(e) Any performance issues to be considered ?
Are there any other considerations I need to be looking into ?
Your thoughts and comments would be appreciated.
Thanks & Regards
Years ago I wrote a technical paper on what is causing response code 9 subcode 15, but I do not have it anymore on my PC , so I will check whether I can find it and attach it here later.
Response code 9 subcode 15 can occur, if your online transaction takes a long time to ET, and batch updates are running at full speed. It does not matter how many records the online transaction modifies, but how many records are happening by all users (Batch) between the interval time of the first update in the online transaction and the ET. If this fills a substantial part of work part one then you may get this response.
To accommodate this you may have to increase LP. LP depends not only on the number of Work blocks but also on the work blocksize. In your case I would recommend to change the devicetype for PLOG and Work to half track or devicetype 8393.
You need not change ASSO or Data to do this. But you have to tell the nucleus via ADADEF NEWWORK that you will give him a new size and a new work devicetype.
If you are on version 8 to speed up updates I would also recommend you make use of the new ADARUN parameters NWORK1buffers and NPLOGbuffers. Specify as many buffers as will reside on 2 cylinders. For device-type 8393 this would be 60.
Of course making your update throughput higher may increase the likelihood for response 9 subcode 15 but this should be dealt with by increasing LP, There is virtually no threshold and disk space is cheap.
How large your LP needs to be I can not tell, because that depends how much time your online update transaction may take (Do they span human interactions at a screen for example) and how fast your upload will be.
Start with a large value for LP and if you get response 9 subcode 15 double the size.
My guess is that your current LP size (which workblock size are you using?) may be sufficient but I could be wrong.
Of course updates from batch will increase your bufferflush requirements.
You might want to increase LBP and LFIOP to get better buffer flush throughput.
Whether NISNHQ needs to be increased depends how often you will ET between updates in your batch upload.
Thanks Rainer for your reply. Much Appreciated.
Both PLOG and WORK have got device type 8393.
Following are our related Nucleus parameter setting which I believe are close to what you have recommended.