*USRSPC Question

[Guest.Visitor]

I am looking at using *usrspc objects to increase the I/O speed in some applications. What I plan to do is put file data into a user-space and then have a program read from the this instead of the file. I have been looking at the IBM redbook (Who knew you could do that in RPGIV) and at some past posts here and it looks promising. What I am missing is if there is a way to update the user-space without having to reload the entire data file again, I load the user space once, but I would like to update it whenever the data in the file changes. Is this possible? or do I have to reload it every time I want new data? Thanks for your help. Mauricio Della-Quercia

[Guest.Visitor]

David; What I am looking for is to determine how easy it is to update a user-space "record". Example: I load a user-space with file data, then the file record gets changed/deleted/added, I don't want to reload the user-space again I just want to update/delete/add the item that was changed to reflect the changes on the file. Question: Is it possible to update a "record" in a user-space like that? Thanks Mauricio

[D.Handy]

Mauricio, <font color=blue>Question: Is it possible to update a "record" in a user-space like that?</font> Yes, but basically only by pseudo-RRN. You could quite easily use pointer arithmetic to calculate an offset for a given "RRN" then change a basing pointer for a DS to map the "record". If you want to do it by key instead, investigate a "user index" instead of a "user space". It will give you keyed access to entries. That being said, using SETOBJACC is alot simpler. <g> Doug

[Guest.Visitor]

Doug; Thanks, today I stumbled upon the User Indexes and you are right, they seem to be more appropriate to what I want to to. I will proabley have some questions about them as well <g> SETOBJACC is easier, but this is an opportunity to LEARN and implement new stuff, and that doesn't happen to much around here <g> Regards Mauricio

[Guest.Visitor]

Mauricio, You will not find much difference in performance between file access and user user indexes. It seems as though you are trying to develop some sort of cache to improve your applications performance. One drawback of SETOBJACC is that you cannot control what is loaded, you always get the whole thing. If you are only using a small subset of records from a file I doubt that you will come close to what you can do with a cache or hash. Every case is different, so it would be helpful if you could post some rough numbers like total values, size of key/data, etc. Some examples: We have a file that contains information about file fields. This file is accessed heavily. This file overall contains tens of thousands of records, but records tend to be used in sets of about 50. Setting up a long term cache to contain 50 records for the main key and another to contain the most recently used records in memory greatly improved performance of this application. In another case where usage was more random, a cache containing the 80 most frequently used records (periodically re-prioritized and partially flushed) noticably improved the performance of the applications that accessed this function. The 80 and 15,000 were arrived at through trial and error. David Morris

[Guest.Visitor]

David; Yes I am trying to improve performance on an application that uses current inventory allocations to determine what items can be shipped. The most commonly used program is one that reads allocations and available qtys for a certain item and returns what is available to ship. It uses 5 files, 2 are logicals over the same physical. This is the program I am trying to improve. Current Status on files: Aprox. Recs Rec Length key Length File A 10,000 141 39 File B 10,000 93 38 File C 10,000 503 20 File D 20 6 6 File E 20 6 6 Most of the processing is going to be done on files A and B, since it has to read all the ones for that key value (the item). I guess that there would only be aprox 100 records that fall into the key value each time the program is called for a specified item. The program as it stands is fairly quick, but it is called easily over a hundred times when a user pages on this application. My idea was to get the most commonly used files (A and B) into a user spaces and/or user indexes and then have this program access that, what I have been trying to determine is if the user spaces can be updated without being cleared. I havent used caches on the 400, so I don't know how they would apply in this situation. Any suggestions are welcome. Regards Mauricio

[Guest.Visitor]

Mauricio, Am I correct in assuming that you are calling this program many times purely to determine what the inventory levels are. For example you have PGMA which is the Order Input program calling PGMB repeatedly to check inventory. Depending on how you have structured the programs and the calls it may be that each time you call PGMB you are "opening" and "closing" the six or seven files you mention. This in itself causes a major overhead to response as opening and closing files is very heavy on I-O. If the assumption of the PGMA and PGMB scenario above is correct there are a couple of alternatives to using a User Space (which strikes me as using a sledgehammer to crack a nut). Option 1. Place a CLP in front of PGMA which overrides all files opened by PGMB to SHARE(*YES) and follow this with an OPNDBF of said files. In this way the files are physically opened in the front-end and shared each time PGMB is called. This will avoid the physical opening each time you go in and out of PGMB. One thing to watch out for is that if the files are also used in PGMA you may have conflicts between *INPUT only opens and *UPDATE Opens. Option 2. Call PGMB and return without setting on *LR. PGMB remains active with all variables intact until shut down with *LR or ending the stack. This also contributes to speeding up the communication between PGMA and PGMB. Option 1 will definitely improve things as I have had to do this before in a similar situation. Option 2 also, but from experience not as much as 1 and can be more troublesome, but be careful with files that are used in both programs PGMA and PGMB. Hope I am making the right assumptions and the above suggestions help. Mick.

[Guest.Visitor]

Mauricio, The files you have described are pretty small and it would be hard to gain much of an advantage over database access. In the cases where I have found cacheing to be an advantage we continuously use a small subset of a very large file. I would try the SETOBJACC method, which is not a catch all solution. If you are interested in learning more about the user space and index APIs, you might look at an article Midrange Computing published last October(?) titled "Put it in Storage" that describes those APIs and some techniques you can use to wrap them into standard service program calls. David Morris

[Guest.Visitor]

David; I enjoyed your response since it was something similiar that I had suggested to management when they came up with the idea, and you are correct if it was ONLY for this small application then SETOBJACC would suffice. But the user space is a possible solution for an entire system. The original idea came from a consulting company when asked on how to improve general performance on our entire system. The consulting company had done something similiar to this with other customers where many files were substituded for User spaces. In this way their overall application performance was increased. When asked if something like that would work on our system I suggested we try it out on a small but intensive I/O application to determine among other things how easy to implement, maintain, does it work as expected, etc. You are proabley right, it might be a sledgehammer for a walnut, but if it works like we want it to then the potencial benefits are very attractive. Regards Mauricio

[Guest.Visitor]

Michael; Thanks for your response, in this case the program already has both of your suggestions. The reason I am looking at user spaces is that I might apply that method in other programs if it works in this one. Regards Mauricio

[Guest.Visitor]

Mauricio, Here is a code sample for something that has worked for me. I cut out the application specific code to make it clearer what is happening. You can vary the sizes of the arrays, miss counts, etc. to fit your needs. <pre> DNUMis S 5U 0 Not used misses. DNUStrI S 5U 0 INZ(%ELEM(NUExpInf)) Start at index. DNUNxtI S LIKE(NUStrI) INZ(%ELEM(NUExpInf)) Next index to add. DNUArySiz C CONST(120) D DS D NUExpInf 17A DIM(NUArySiz) Name cache. D NUExpUse 5U 0 OVERLAY(NUExpInf) Used count. D NUExpNam LIKE(Exp01Nam) OVERLAY(NUExpInf: 3) Name cache. C EVAL Exp01Nam = ExpNam C EVAL I = NUStrI C Exp01Nam LOOKUP NUExpNam(I) 01 C* Cache hit C IF *IN01 C EVAL NUExpUse(I) = NUExpUse(I) + 1 C* C ELSE C EVAL NUMis = NUMis + 1 C SELECT C WHEN NUMis > 20000 C SORTA NUExpUse C EVAL NUStrI = 120 C EVAL NUNxtI = 120 C EVAL NUMis = *ZEROS C WHEN NUNxtI = 1 C EVAL NUNxtI = 60 C ENDSL C C EVAL I = NUNxtI C EVAL NUExpUse(I) = 1 C EVAL NUExpNam(I) = Exp01Nam C* Decrement start at index. C IF NUStrI > NUNxtI C EVAL NUStrI = NUNxtI C END C EVAL NUNxtI = NUNxtI - 1 C EVAL PgmFnd = *OFF C ENDIF</pre> David Morris

[Guest.Visitor]

David; Thank you very much for the code, it looks like a good fit for this applications. Mauricio

[flensburg@novasol.dk]

David, I guess you're thinking of user queues (object type *USRQ) - they're still only accessible through MI- and C-functions. Best regards, Carsten Flensburg