Re: program/file data structure

John,

We did the same thing, as -every- shop should!

But I'm going to nit pick, not with your solution in particular, but how one
persons solution can, how should I say, require adoption to shop standards.

We also use program/file feed back areas.  In our shop P1 means Printer file #1.
We never use a number in the second position within a file's record for field
names. So we adopted the number designation for file feedback. This helped avoid
field name conflicts, so D1 is the first data base file feedback, and P1 the
first printer file feedback.

The only reason I bring this up is because of the recent thread on shared code.
IMO, one of the roadblocks of pure "plug in" code is naming conventions.  Sure 
we
can now have local vs global variables and that helps, but a program status DS
requires that you give a "name" to status, job, user, etc.

I agree with the other comments on this list, *user, *job, *jobn, (or whatever)
etc.  would be nice for program status values. I also do -not- want to rename
these values to field names. I don't think that anyone on this list has problems
with reserved words that start with "*".  I support the idea that *STATUS should
be more that just a from-to placement determinator, but a useable value.
Unfortunately, it's used in both program DS and file DS, so some other name
(*PGMSTS) needs to be developed.

How about it Hans?  Could something like this be placed in the "to do" pile?
Give it to the new kid on the team <g>

John P Carr wrote:

> I keyed this DDS in around 1985  while on the Sys/38   After I looked up
> what position the User ID was in (for the last time in 15 years)
>

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---