RE: QRPGSRC vs. QRPGLESRC

[rob@xxxxxxxxx]

Does that work for your ile programs also?

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 




"Rubino, Jim" <Jim.Rubino@Fike.com>
Sent by: midrange-l-bounces@midrange.com
01/21/2003 02:15 PM
Please respond to Midrange Systems Technical Discussion
 
        To:     "'Midrange Systems Technical Discussion'" 
<midrange-l@midrange.com>
        cc: 
        Fax to: 
        Subject:        RE: QRPGSRC vs. QRPGLESRC


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.


_______________________________________________
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.