RE: Library and Source File Question: naming conventions

I agree: adherence to the shop standard, whatever it is, is the most
important consideration.  Is this the right time to say "Amen!"?

My standard:
XY (two-letter combinations belong to the software developer [me];
letter-number combinations are for customer stuff)
Z (type: D=DSPF, R=RPGLE, C=CLLE, M=CMD, A=PRTF, B=ICFF, P=PF, L=LF,
H=PNLSRC, G=MSGF, etc.)
NNNxxx (usually 3 numbers sequence, but can be 3-6 alpha numeric)

I've developed a number of handy utilities to work with the various members
required in a program.  I type "XXM730 AR 001" and I'll see ARD001 in SDA,
ARD001 in SEU ('cause SDA doesn't handle date data types, or ENTFLDATR, or
MAPVAL, or windows keywords, etc.), ARH001 in SEU, ARR001 in SEU, ARC001 in
SEU, ARM001 in SEU, ARR001PR (the prototype) in SEU, and ARR001 (the binding
directory) in WRKBNDDIRE.  Then the whole shebang gets submitted to compile
(the old objects are moved to archive libraries, of course).

When I see a program like CUSTINQ, my stomach knots...

-rf

-----Original Message-----
From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com]On
Behalf Of Vernon Hamberg
Sent: Wednesday, October 09, 2002 5:44 PM
To: midrange-l@midrange.com
Subject: RE: Library and Source File Question

Rob

Sure, why not? First, the parallel to extensions on the PC does not work,
at least for me. Otherwise I should have names like ORD500PGM, which
becomes ORD500PGM.PGM in IFS. That's not the same thing.

The reason I'd use suffixes is to help tell what the source type is. It's
similar in function to .c and .cpp for C/C++ source, .bas for BASIC, .pas
for Pascal, etc.

You also see the attribute in PDM, just like in WRKOBJ. But in a mapped
drive, that attribute does not appear, I believe. And I've not used WDSC
enough yet to have an opinion.

I'm still inclined toward separate source files. The varying lengths move
that way. I like to minimize exceptions, and I'm not sure CL tolerates a
longer record length. QMQRY definite requires 91, will not work with
longer. So I generally make a rule, for me, of separate files. Others where
I work do not. We have a mix, actually.

Bottom line, this is probably a religious argument and I choose to cease
and desist (after this post). There's not a real right/wrong IMO (except
for the *DOC.DOC kind of thing). In all of this, take what you like and
leave the rest. Find something that works and doesn't get in the way.

Regards

Vern

At 03:18 PM 10/9/02 -0500, you wrote:

>Names that reflect the source types?
>like
>ORD500R for rpg
>ORD500C for CL
>ORD500D for display file
>ORD500O for printer output?
>And if you do a WRKLNK '/QSYS.LIB/MYLIB.LIB/ORD500*.*' you'll see:
>/QSYS.LIB/MYLIB.LIB/ORD500C.PGM
>/QSYS.LIB/MYLIB.LIB/ORD500D.FILE
>/QSYS.LIB/MYLIB.LIB/ORD500O.FILE
>/QSYS.LIB/MYLIB.LIB/ORD500R.PGM
>And if you do a WRKOBJ MYLIB/ORD500* you'll see:
>Object      Type      Library     Attribute
>ORD500C     *PGM      MYLIB       CLP
>ORD500R     *PGM      MYLIB       RPG
>ORD500D     *FILE     MYLIB       DSPF
>ORD500O     *FILE     MYLIB       PRTF
>
>Question, when you create stuff on your PC do you end up with names like:
>MYPGMEXE.EXE
>TESTDOC.DOC
>QUESTIONSDOC.DOC
>OTHERDOC.DOC
>FINANCIALSXLS.XLS
>RESUMEWP1.WP1
>
>
>Rob Berendt
>
>                       Vernon Hamberg
>
>Have separate source members. It did not used to be necessary, but
>nowadays, because of record lengths, it is. RPGLE needs a record length of
>112,  older RPG needs 92. QMQRY's need 91, QMFORMs need 162 or some such.
>
>I would still use distinct names, even in separate source files, since the
>resulting objects, whether modules or programs or service programs, still
>need distinct names. This gives you the chance to make names that reflect
>the original source types - might be useful.
>
>Regards
>
>Vern

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.