F-spec Update/Add - No update/add in Pgm

[jayvaughn]

A new client is on what appears to be a rpgIII evolved system with a MAPICS type architecture (many control files).

I'm running across a few programs that have a file declared in the f-spec with Update/add specified.
In the program they do no updates or adds. Just a read.

After questioning a couple of the programmers, they mumble something about the "workflow" requires it sometimes to avoid a CPF error.

Is there a valid reason for this I am overlooking. Maybe a common industry practice that was implemented at one time - is it sill valid?

[Whitecat27]

Greetings Jay,

This situation is the highly irritating bane of my programming experiences. From what you describe, my thought is that the programmer used a program that defined the file as an update/add, simply copied the file F-spec into their new program simply because it was "easier" to include an F-spec from an existing program, rather than understanding how that specific file would be used in their new program without the proper changes.

Although copying chunks of source code from one program to another is a well established, and very useful technique... making those kinds of source code copies without thinking about the task given, blindly accepts the possibility of record locks, logic errors, and other unusual happenings in unrelated programs and processes when using that file at 3 AM during nightly processing.

However, the programmer that did this "finished" and "tested" this original program in record time, got a blue ribbon from the boss, and quickly moved on to the next programming task at hand without actually thinking about what they actually accomplished and the affected results in the future. This kind of programmer is not an actual programmer in my opinion, they simply "write code". For the reasons you mention, there is a real difference between an actual "programmer" and someone who just "writes code".

You seem like you are a person who actually looks at the compiler spool files and pays attention to the "warning" errors. More than not, many folks do not do this, or even care about those compile errors. I think it's good for you that you pay attention to the kind of thing that you write about.


Best Regards,

Fred Williams


P.S. To specifically answer your basic question... NO, not only NO, but Hell No, this is generally not accepted as a common standard or practice when writing iSeries programs for any industry.

[Brian Rusch]

There is one situation that would require the file to be opened for update even though no updates are performed and that is if the file was opened for update and the open was shared (OVRDBF SHARE(*YES)) prior to the RPG program being called. This is usually done in a CL program.

[CRinger400]

They must see a few CPF5027 and CPF5032 messages (row locked for update) in QSYSOPR at times.

I never code UPDATE if the file is READ only.

I do do the opposite though. If I defined a file as READ only, I *always* code the related READxx and CHAIN with (n) which is NO LOCK. Why?
As soon as someone in the future modifies the program and changes the F-Spec to UPDATE, you could get unintended record locks in the pre-existing code if they don't think to add the (n).

Ringer

[jayvaughn]

Feedback here is what I was expecting. The last 8 years of my 20 years as an RPG developer has had me gravitating more towards no f-specs and more sql. I do like CRinger400's proactive i/o's with the (n).

[Barbara Morris]

Another possible reason for coding it as update or add is to prevent blocking. We can code BLOCK(*NO) now in RPG IV, but in RPG III, the compiler had to be tricked into not blocking, either by coding it as update or add, or by coding something like a SETLL.

But the mumbling about avoiding a CPF error suggests that it was due to shared files not being opened correctly by the first open. If that was the case, too bad they didn't add a comment to the F spec.

[jayvaughn]

i realize a common reason for this is simply copying and pasting the f-spec and not adjusting it's definition appropriately, but based on this shops history (and MAPICS influence) I'd say the blocking prevention was probably the biggest reason (to give them a little credit ). thx Barbara

[Peder Udesen]

A reason might be that OVRDBF SHARE(*YES) is used. The first time the file is opened limits all following attempts to open the file.
For example if the first program only opens it in input/update mode then it is not possible to open the file later in input/update/append mode.

[jayvaughn]

A reason might be that OVRDBF SHARE(*YES) is used. The first time the file is opened limits all following attempts to open the file.
For example if the first program only opens it in input/update mode then it is not possible to open the file later in input/update/append mode.

so what if this is a file opened at the beginning of the process as update with shared access path. Then pgm_C down the stream is modified to access the file, but not with an f-spec. Instead an sql select is coded over the file. Will this cause any issues? WHat about vice versa? Originally opened as Input only shared access path, but pgm_C updates the file via sql (and no f-spec)?

[Peder Udesen]

If your SQL program uses the same file I would expect that you would receive an error when it tries to update.
So if your RPG program opens File1 with F-spec (Input/Update) and you later tries to insert records to File1 using SQL
I would expect that you receive an error.

But the easiest thing is to try it out.

[jayvaughn]

good call - so I tried this...

on command line...

OVRDBF FILE(QUE27) TOFILE(TSTJHV/QUE27) SHARE(*YES)
OPNDBF FILE(TSTJHV/QUE27) OPTION(*INP)

then ran this pgm...

0001.00 H option(*srcstmt:*nodebugio)
0002.00 H dftactgrp(*no) actgrp(*caller)
0003.00 *----------------------------------------------------------
0004.00 * SQL Default Options
0005.00 *----------------------------------------------------------
0006.00 exec sql
0007.00 set option
0008.00 commit = *NONE,
0009.00 closqlcsr = *ENDMOD,
0010.00 datfmt = *ISO;
0010.01
0010.02
0010.03 exec sql insert into tstjhv.que27
0010.04 (select * from tstjhv.que27
0010.05 fetch first 1 row only);
0048.04
0049.00 *inlr = *on;


It inserted the new records with no problem - based on this test and other research i have done, i'm concluding any current data path specified, is overridden with a new one when sql accesses the file.