|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.