Re: Program design to minimize record locks (still stuck)

I am curious how the data structure for the screen is actually used in the program. Do a search ion the calcs for the screen data structure. If it isn't actually ever used in the calcs then maybe the easiest solution is to change the way the fields on the screen are defined. The screen names don't need to be changed, just defined in the dds instead of in the data structure. That should resolve the issue quite easily..

Here is a really simple solution right out of left field. It should work, but ... sometimes I overlook the obvious problems. I am about to say something that makes sense to me but could very well be wildly wrong,. I wonder what happens if you comment the data structure for the data file and then where the data structure is used in your calcs, you change the name to the data structure you've defined for the screen? After all, the only fields changing are the fields on the screen, right? In other words, use @$SCR03 in the calcs where ever you were using PMYFILEDS.


Pete Helgren wrote:

Barbara.

Thanks. There is only one extname ds for this physical file. I chose the first field I found on the listing that the compiler was complaining about and then scanned the listing for the field name. I found it in several places since it is one of the key fields.

The first occurrence is in a ds that contains the screen fields:
E DS EXTNAME(WASA408:SCR03)

In this case format SCR03 in file WASA408 has an occurrence of the field name.

The second occurrence is in the FileNameDS that I added using extname:
DFileNameDS e ds extname(PASA408)

And this is where the compiler is complaining. So, if I understand you correctly, the fact that I have a field name that is in two files that have been referenced by EXTNAME, even though the files are different files, causes the error. The EXTNAME on the display file is a convention used in the "model" this program is based on and is required because of logic in the /Copy member that is common to all programs that use this "model".

Looks like I am not going to be able to solve this problem easily. Since I am not very familiar with the "model" code this program is based on, I'll have to walk through all of it and see how I can redesign this code so that it doesn't lock the record while the screen is displayed AND so I don't have to explicitly move the data between the screen format and record format. I think using a DS is the key here, I just need to figure out how best to use it without clashing with other DS's that are already part of this model.

Back to the drawing board!

Thanks for your help.

Pete



Barbara Morris wrote:

Pete Helgren wrote:

...
a) Extname - Causes a RNF3804 error on the fields that are in the screen format that have the same name as the data structure or file (I think...the error is pretty vague:"Name Field1 in external description PMYFile is not renamed external name is ignored.")
...

Are you coding EXTNAME for the screen file or the database file? Since you have the same field names in both files, you can only define an EXTNAME DS for one of them (unless you use PREFIX or QUALIFIED for one of them which defeats your current purpose).

I think you want to compare the old database record with the new database record, so you should code an EXTNAME DS for the database file. When you READ the database file, it would automatically populate the DS. When you EXFMT your screen, any output-capable screen fields that have the same names as the database file would be set from the DS, and any input-capable screen fields would set the DS fields after the EXFMT.

If you only have one EXTNAME ds, then you'll have to hunt through the listing to find out what's up with the RNF3804. For one of the subfields you are getting the error for, look in the cross reference to find out where else that field name has been defined earlier in the program. Maybe you have them defined in another data structure. Be sure to use the listing for this; you can't always tell what's going on from your original source.