× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



All of your source in one file is ok as long as you do not have any
objects/source with the same name.  Some software packages have CL, RPG,
CMD, DSPF, PRTF that are the same name and this would not work putting them
all in one source file. The objects for files would be in one library and
the pgms would be in another one. 

As for knowing where the source is for an object:
Understand that you can see where the source was at the time the object was
created by doing a:
 
DSPOBJD OBJ(objectname) OBJTYPE(*PGM) DETAIL(*SERVICE). 

If you create your objects in a library different than the production and
you move the object and source to production, then the DSPOBJD will not be
correct.  If you move the source to production and then recreate the
objects, then the DSPOBJD would be correct......UNLESS someone moves the
source member to a different source file (like into in one source, like the
thread is suggesting).

We do all of our new and mods in a development library, move the source and
object to a test library for the users to test and then move the source and
object to a production library.  In each of these cases when we do the move,
we use the command CHGOBJD2 to change the library name for the source
library name to the library we are moving to.  This way we can always tell
where the source is for the object.  If we where to move source into a
different source file name and library, we have a PDM user option to change
all of the objects in a library to the new source file name and library.
This way there is not question as to where the source is for an object.
The CHGOBJD2 is a TAATOOL command.

It really depends on how accurate and tight you want your
system/programming.

Jim

 

-----Original Message-----
From: Malchow, Grizzly [mailto:GMalchow@automaticproducts.com]
Sent: Tuesday, January 21, 2003 10:30 AM
To: Midrange Systems Technical Discussion
Subject: RE: QRPGSRC vs. QRPGLESRC


The whole reason this started is because someone couldn't find the source of
a program. This person hasn't programmed in about 8 years, and never in
RPGIV. Thus this person never looks in QRPGLESRC. I don't think this person
even knew the file existed. Unfortunately this person is the one who makes
the decisions. I disagree with this decision. Maybe I can find some RPG 2
programs to stick in the source file also. 

-----Original Message-----
From: Ed Chabot [mailto:echabot@marlinfirearms.com] 
Sent: Tuesday, January 21, 2003 9:47 AM
To: Midrange Systems Technical Discussion
Subject: RE: QRPGSRC vs. QRPGLESRC


Griz,

General housekeeping and organization should be reason enough.  I'm not sure
if there is an overriding technical reason, but perhaps others on the list
can help.

Ed Chabot
The Marlin Firearms Company
100 Kenna Drive
North Haven, CT 06743
(203)985-3254

-----Original Message-----
From: midrange-l-bounces@midrange.com
[mailto:midrange-l-bounces@midrange.com]On Behalf Of Malchow, Grizzly
Sent: Tuesday, January 21, 2003 10:18 AM
To: midrange-l@midrange.com
Subject: QRPGSRC vs. QRPGLESRC


I'm supposed to create a source file named QRPGSRC that will be hold all of
source files, both RPG and RPGILE. I've always kept the 2 source members in
seperate source files. I.E. QRPGSRC and QRPGLESRC. I know QRPGLESRC has a
longer record length. I'm supposed to create a QRPGSRC with a record lenght
of 112. Everywhere I've been before has always kept the sources seperate. I
don't think it's necesarily a good idea. I need a good reason to explain why
we should not do this, other than industry standards, the differences in the
code etc. _______________________________________________
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/mailman/listinfo.cgi/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.


_______________________________________________
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/mailman/listinfo.cgi/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.


_______________________________________________
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/mailman/listinfo.cgi/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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.