QCLSRC, QCBLSRC, QRPGSRC, QxxxSRC
John W Mickevich
Just trying to get some constructive debate going with this one!
I have been programming on the System/36 and AS/400 now for many
years. The whole concept of the QxxxSRC source physical files seems
silly to me. Why not keep all your source code in the same source
physical file.
In the applications I write, I have only two source physical files in
each library - PROGRAMS (which holds program source) and FILES(which
holds DDS source). This seems like a pretty logical separation to me.
My applications usually have CL, RPG, COBOL, etc programs with names
which are very similar (i.e. RPG program VENDMAST with CL program
VENDMASTC). When I have to modify a program, all the source members
for the application are right up there on the screen next to one
another - none of this jumping around between multiple source physical
files to change the CL, COBOL, etc.
I work for a consulting company and do work on many systems which are
using the QxxxSRC concept, and every time it bugs the hell out of me
when I have to modify applications with this structure. I never write
applications using this method - especially when I spend all the up
front time designing the thing. I do not like the idea of taking a
nice design and 'uglifying' it in this manner.
If anyone has any responses, post to this newsgroup - perhaps we can
get some pros and cons each way.
John W Mickevich
Computer Management Technologies
jmic...@cmtonline.com
Bradley V. Stone
You open up a big can of worms asking something like this. This could
get to be a big thread.
But, I'll give my .02. I don't mind splitting stuff up. I subset my
lists all the time so going from RPG, to CL to display is as simple as
changing the filename in PDM.
I've seen a lot of different ways, and yours is one. Personally, I
didn't care for it, but that's because I was used to the other way.
If you're going that far, why even split up DDS and program source?
Anyways, most of the time (99%) when there is a problem with a program
it is either the CL or the RPG, and guessing which one isn't that
rough.
There are pros and cons to each way to do this. Nothing will get
settled, but it will be interesting to see what comes of this.
Bradley V. Stone
bvs...@usa.net
http://prairie.lakes.com/~bvstone/
1992 Yamaha FJ1200
1969 Suzuki T250
"I was on fire.... and I was dry!"
Doug MacPherson
In article <349f321c...@news.concentric.net>,
jmic...@concentric.net wrote:
> Just trying to get some constructive debate going with this one!
>
> I have been programming on the System/36 and AS/400 now for many
> years. The whole concept of the QxxxSRC source physical files seems
> silly to me. Why not keep all your source code in the same source
> physical file.
<Very good reasoning snippered>
I used to do the same and even worked for a company that adopted that as a
standard. Vigilance will pay off. But, we're dealing with a Copernican
revolution here. The dark age thinkers still pretty much run the show...
For a real kick, try naming conventions. For example, I tend to name my
physical files something like "ORDHDR" and any logicals are simply
"ORHDR01," "ORDHDR02..." ad infinitum (at least to 99). When you work
with the member list in PDM, the logicals stack up quite nicely behind the
physical.
However, several consulting firms I've worked with have this as their
naming conventions: ORPHDR, ORLHDR01, ORLHDR02... As you can see, you
have to search separately for logicals and physicals since there is no
generic filter you can use to bring them together.
I say the source file issue is a small one. The naming conventions,
however, is a big one...
-Doug MacPherson
(Take away the "poofter" in my address and you can send e-mail to me...)
Sébastien Taildeman
i had a problem with a printer and Rumba unde windows 3.11 the printer 's
name deskjet 540 and connected by a switch box auto, the problem has
dissapeared for the moment just by changing the auto switchbox by a manuel
one keep intouch if you want to know what's next
Doug MacPherson a écrit dans le message ...
Gordon Dracup
I agree with you. It makes sense to have all the source in one physical
file. The only potential downside I can think on is with RPGLE source
which has a larger record length than RPG, but all that means is that
every RPG source you hold has a few unused characters at the end. No big
deal really.
John W Mickevich <jmic...@concentric.net> writes
>Just trying to get some constructive debate going with this one!
>
>I have been programming on the System/36 and AS/400 now for many
>years. The whole concept of the QxxxSRC source physical files seems
>silly to me. Why not keep all your source code in the same source
>physical file.
[snip]
--
Gordon Dracup
Cipher Solutions Limited
Telephone 0131-477 7717
J. Scott McPhee
In message <349f321c...@news.concentric.net> -
jmic...@concentric.net (John W Mickevich) writes:
:>
:>Just trying to get some constructive debate going with this one!
:>
:>using the QxxxSRC concept, and every time it bugs the hell out of me
:>when I have to modify applications with this structure. I never write
:>applications using this method - especially when I spend all the up
:>front time designing the thing. I do not like the idea of taking a
:>nice design and 'uglifying' it in this manner.
:>
:>If anyone has any responses, post to this newsgroup - perhaps we can
:>get some pros and cons each way.
:>
:>John W Mickevich
:>Computer Management Technologies
:>jmic...@cmtonline.com
This started out in the days of the System 38 when the programmer's menu
was the main developer interface. When you specified the source type (RPG,
CBL, DSPF, etc.) the menu automatically open the associated QxxxSRC file if
you did not override the source file name. Since we programers were a lazy
lot, we usually did not override the default. <G>
You would at least need one source file for each object type (ie files,
Programs, Commands). In addition, diffrent language compilers may expect a
diffrent source record length. For example: ILE RPG required a length of
112 while OPM RPG only requires a length of 96.
regards
J. Scott McPhee
Richard L Daniels
John W Mickevich wrote:
>
> Just trying to get some constructive debate going with this one!
> silly to me. Why not keep all your source code in the same source
> physical file.
>
that many comments re Y2K may apply... Probably having roots in the
many components that make up commands, programs, etc. When you have
source code for screens and source code for logic and source code for
file definitions and source code for xxx, I guess SOME non-creative
types figured that each object/member for the same module should have
the same name and therefore must need to be kept in different files.
Go Figure. Like you, I'd prefer to see 1 library for source 1 library
for program objects and a third for volitile/static data.
Jeff Crosby
> In the applications I write, I have only two source physical files in
> each library - PROGRAMS (which holds program source) and FILES(which
> holds DDS source). This seems like a pretty logical separation to me.
What about commands? I have every application command driven. Each
RPG *PGM object has a corresponding *CMD object of the same name. The
CL program name has a prefix of CL. Since the source and object names
are the same on my system, I must put (at minimum) the command source
and RPG source in different source physical files. I happen to use the
default source file names.
Here's what the heirarchy of a single RPG program "PGM01" would look
like:
Command = PGM01
CPP = CLPGM01
VCP = CLPGM01V
POP = CLPGM01P
RPG program = PGM01
--
-Jeff
Gary Guthrie
Aha, this topic again...
I'd like to point out a few things that are often overlooked when the
discussion of 1 versus multiple source files comes up.
The first things I'll point out are the fairly obvious things, followed
by some not so obvious things - things that many programmers fail to
consider when making these decisions, and understandably so.
The obvious include the arguments for programmers' ease-of-use with 1
source file. Everything is there together, no flipping around, etc. The
arguments about naming conventions handling, etc. Naming conventions can
be put in place to support either 1 or multiple source file scenarios.
As some also point out, various source types have differing record
length requirements. For most, you can just create the source file with
a maximum record length and let trailing blanks hang around for those
source-types that don't use the extra space. However, this won't work
for ALL source types. Consider Query Management Queries which need 91
bytes as the record length. Don't ask me why! They just do. Obviously,
this type of restriction factors into the decision.
The act of moving between source files is fairly painless, in my
opinion. Particularly in these days where multiple sessions are the
norm. It is less convenient if you have a single session, but still not
terrible. Though, I'll concede, it could be annoying.
I'll dispense with the obvious (I could go on and on), but I think it
more helpful to point out the not-so-obvious.
With a single source file, the file is larger with more members. This,
potentially, could be a considerably larger file with considerably more
members. From the programmers' perspective there are some drawbacks. The
time required to subset the members in PDM, etc. is one area. This will
be slower, perhaps considerably slower. Scanning is another area that
will potentially require considerable more time. Various operations such
as DSPFD, etc. that have to deal with more members will take more time.
I think the point is made about the time issue here.
However, there is a perhaps even more important non-obvious angle - at
least from many programmers' point of view. That is operational
requirements. Consider for example save/restore functions. Often, the
window for save/restore functions is already too tight. Or perhaps a
system where DASD usage is high. Breaking down source files can help
situations like this.
This not only argues for multiple source files by type, but for further
modularization as well. That source that is static (not undergoing
modification) doesn't need to be saved as often as source that is
undergoing changes. This means it can be a real benefit to break the
source up based on activity. The static things can then be archived
off-line for those systems where DASD usage is high, freeing up space.
Or even if left on the system, static source does not need to be saved
as often. By saving only the source that is actively changing savings
are realized in back-up time and media consumption.
I could go on, but perhaps this is enough of a tickler to start folks
thinking from a perspective other than from the programming-ease side of
things.
Gary Guthrie
CVWD
In article <349f321c...@news.concentric.net>, jmic...@concentric.net
(John W Mickevich) writes:
>In the applications I write, I have only two source physical files in each
>library - PROGRAMS (which holds program source) and FILES(which holds DDS
>source). This seems like a pretty logical separation to me. My applications
>usually have CL, RPG, COBOL, etc programs with names which are very similar
>(i.e. RPG program VENDMAST with CL program VENDMASTC). When I have to modify
>a program, all the source members for the application are right up there on
>the screen next to one another - none of this jumping around between multiple
>source physical files to change the CL, COBOL, etc.
We take it one step further - everything is in QSOURCE. We don't put DDS in a
separate file because most DDS sources are program-related (the DDS for the
screens and print files) so we just put everything together. MUCH easier than
jumping around and no chance of accidentally naming two things the same because
you did not realize there was already something with that name, but the source
was somewhere else. Want to back up just the source files? No problem - they
all have the same name.
I know that it had to be that way for S/36 and S/38 compatability, and way back
at the beginning (V1R1) native menu source had to be in MNUSRC, but there is no
reason for new development to use those conventions.
MPVSGROI
Just wanna put my two cents in on this. I prefer the status quo!
I keep my *DSPF, *PF, *LF, and *PRTF in QDDSSRC.My *CLP(programs), and
*CLLE(*modules) in QCLSRC. And
my RPGLE(*modules) in QRPGLESRC. I usually keep a
QTXTSRC in my production library(s) for panel-type HELP
TEXT members, and programming SHELLS. and I don't use
QCMDSRC at all, 'cos, I prefer to write *DSPF prompts instead.
As Dennis Miller would say, "that's my opion, I could be wrong!"
:-)
...paul j. sgroi
But the wooden ships, were just a hippie dream
Cap-sized in excess, if you know what I mean...Neil Young
Scott Klement
Hmmm... We use the "QxxxSRC" approach, but unlike your setup,
we have only one library for source, rather than having source files in
each library.
I find the "seperated by language" approach to be helpful primarily for
searching purposes. For example, we have a file called "PROFILE",
if I want to see everywhere that this file is used, I can search for "FPROFILE"
in my RPG source (because all files in RPG are defined on an F-spec)
this saves me from getting the word "Profile" included in comments, literals, etc.
The same sort of concept applies to the other languages as well, of course,
and since they're all in seperate files, I can do the search differently depending
on the language.
Furthermore, searches would take a very long time if I had to search every
single source member on the system each time I searched -- I can subset my
searches by language, which I find helpful. For example, if I'm looking for
where an invalid value is being placed in a record, I don't have to bother
searching QCLSRC, QDDSSRC, QMENU, etc.
Other than searching for things, however, I cannot think of a reason why we
couldn't use one source file... tho I don't think changing the name of the
source file would save a significant amount of time.
John W Mickevich wrote:
> I have been programming on the System/36 and AS/400 now for many
> years. The whole concept of the QxxxSRC source physical files seems
> silly to me. Why not keep all your source code in the same source
> physical file.
>
> In the applications I write, I have only two source physical files in
> each library - PROGRAMS (which holds program source) and FILES(which
> holds DDS source). This seems like a pretty logical separation to me.
> My applications usually have CL, RPG, COBOL, etc programs with names
> which are very similar (i.e. RPG program VENDMAST with CL program
> VENDMASTC). When I have to modify a program, all the source members
> for the application are right up there on the screen next to one
> another - none of this jumping around between multiple source physical
> files to change the CL, COBOL, etc.
[snip]
Unknown
For our main software we have a separate library for source, the
subdivision in files is by module (GL, Inventory,...) and by the
object library (programs, database files, french objects, english
objects). For programs we have a separate file for ILE because of the
length difference. Something like:
SG00PGM GL programs
SG00PG1 French objects for GL
SG00PG2 English objects for GL
SG00DT1 GL database with field descriptions in French
SG00DT2 GL database with field descriptions in English
IG00PGM GL ILE programs
SI00PGM Inventory programs
SI00PG1 French objects for Inv.
SI00PG2 English objects for Inv.
SI00DT1 Inv. database with field descriptions in French
SI00DT2 Inv. database with field descriptions in English
II00PGM Inv. ILE programs
This allows us to save modules separately and groups objects by
function.
Even though RPG programs for a module are in two separate files
because some are ILE and others are not, it's transparent to the
programmer because they work inside a configuration management system
who knows where the source is.
For small utility modules, like the installation module, I tend to
prefer one source file with everything in it.
Christopher An
I prefer keep different programs in different files. I even divide same
RPG or CL code into number of different physical files regarding their
categories. It is very important to keep different things separate,
specially when you have large number of program source codes. Right not
we have around 8,000 RPG and CL programs, and it may be a headache if
you have all these in one physical file.
It all depends on how many programs in your system. However, I prefer
to keep everything separate. It happens same when you deal with your
PC. I will be a mess if you keep all files in one directory regardless
their file type. It would be OK if you have few files, but it is
getting harder as you get more files in your computer.
Christopher An
a...@newstar-tech.com
Newstar Technologies Inc.
Daniele Greggio
Bradley V. Stone ha scritto nel messaggio
<349f5886....@news.lakes.com>...
>On Tue, 23 Dec 1997 03:59:05 GMT, jmic...@concentric.net (John W
>Mickevich) wrote:
>
>>Just trying to get some constructive debate going with this one!
>>
>>I have been programming on the System/36 and AS/400 now for many
>>years. The whole concept of the QxxxSRC source physical files seems
>>silly to me. Why not keep all your source code in the same source
>>physical file.
>>
>>In the applications I write, I have only two source physical files in
>>each library - PROGRAMS (which holds program source) and FILES(which
>>holds DDS source). This seems like a pretty logical separation to me.
>>My applications usually have CL, RPG, COBOL, etc programs with names
>>which are very similar (i.e. RPG program VENDMAST with CL program
>>VENDMASTC). When I have to modify a program, all the source members
>>for the application are right up there on the screen next to one
>>another - none of this jumping around between multiple source physical
>>files to change the CL, COBOL, etc.
>>
>>I work for a consulting company and do work on many systems which are
>>using the QxxxSRC concept, and every time it bugs the hell out of me
>>when I have to modify applications with this structure. I never write
>>applications using this method - especially when I spend all the up
>>front time designing the thing. I do not like the idea of taking a
>>nice design and 'uglifying' it in this manner.
>>
>>If anyone has any responses, post to this newsgroup - perhaps we can
>>get some pros and cons each way.
>>
>>John W Mickevich
>>Computer Management Technologies
>>jmic...@cmtonline.com
>>
>
I think that the better way, used in in a lot of MIS, is the way to use some
different source file but non based on the source type but based on the
application of the programs. For example:
SRCORD for the rpg, cbl, clp, dspf of the order application,
SRCINV for the rpg, cbl, clp, dspf of the invoices application
and
SRCORDDB for the pf,lf of th order application
This organization is useful because, working with PDM, your source are all
close (if you have a standard name like OR05R, OR05D, OR05C ... naturally)
and during the modification you can pass from a source to another quickly
without change the source file. Normally you work on one application for
hours or for days, so you don't need to change the source file during your
work for a lot of time keeping, however, divided and organized your sources.
The files are in another source because their names are, generally, very
different from the name of the programs and can't be near the source of the
programs that used them in the PDM list and the modification to the file are
less frequent and often not necessary when modify the programs, so is better
take them in another source file.
To have only two source file "Programs" and "Files" are good only for small
MIS with 200/300 source max and only if they have a good names with right
prefix in the programs.
Daniele Greggio
Syn...@galactica.it
John & Barb Brooker
At my previous employer, all in-house programs were divided how you did
it, QPGMSRC for RPG, DDS, PRTF, CL. Files were in another library.
Packaged code was however it came.
At present employer, source is all over the place, because of conversion
from 36 code, and multiple locations and library's. It is a nightmare
for a new employee. Someone should draw a map!
Since all new developement is ILE and longer source member length, we
have started to put everything but files into QILESRC. This is much
better for finding the source.
We try to name source members by function-AR, AP, EDI, BAR, and then a
number. Then the last 2 letters are for type and multiples.
GL1024c (CLLE)
GL1024d (display file)
GL1024ia (RPGLE)
GL1024ib (RPGLE #2)
GL1024r (printer file)
For some reason the other programmer decided to put service program
mod's in a new source file-QSRVSRC, and then did not have the search
tools check this source file. (has since been changed after finding a
yr2k change that was missed.)
We put trigger programs in the library the files are in and use QILESRC
for the source file.
We use Test Lib (high in library list) PGMSLIB (under Test in lib list)
for production, and then we have developer's libraries.
We have tools in place for finding the objects by use and so do not use
the find string in pdm options very often.
> John W Mickevich wrote:
>
> > I have been programming on the System/36 and AS/400 now for many
> > years. The whole concept of the QxxxSRC source physical files seems
> > silly to me. Why not keep all your source code in the same source
> > physical file.
> >
> > In the applications I write, I have only two source physical files in
> > each library - PROGRAMS (which holds program source) and FILES(which
> > holds DDS source). This seems like a pretty logical separation to me.
> > My applications usually have CL, RPG, COBOL, etc programs with names
> > which are very similar (i.e. RPG program VENDMAST with CL program
> > VENDMASTC). When I have to modify a program, all the source members
> > for the application are right up there on the screen next to one
> > another - none of this jumping around between multiple source physical
> > files to change the CL, COBOL, etc.
>
> [snip]
Bradley V. Stone
This sounds like a good idea, but what we actually do is similary and
the same.
We divide our different application types by library instead of source
members. Thay way if a company for instance doesn't want the
inventory part of the package, that's one less library to send them
and one less library in the library list.
Richard Knechtel
John & Barb Brooker wrote:
>
> We try to name source members by function-AR, AP, EDI, BAR, and then a
> number. Then the last 2 letters are for type and multiples.
> GL1024c (CLLE)
> GL1024d (display file)
> GL1024ia (RPGLE)
> GL1024ib (RPGLE #2)
> GL1024r (printer file)
>
God this almost looks like JD Edwards naming conventions. :^)
--
Richard Knechtel
EDS
(Systems Engineer/System Administrator)
(Aspiring AS/400 GURU)
The contents of this message express only MY opinion.
This message does not necessarily reflect the policy or views of
my employer, EDS. All responsibility for the statements
made in this posting resides solely and completely with the
ME.
I Ex-Spaminate spammers!
See US Code Title 47, Sec.227(a)(2)(B), Sec.227(b)(1)(C)
and Sec.227(b)(3)(C).
John W Mickevich
Thanks to all that have responded to my original post.
I was curious how may people were using methods other than the
"normal" QxxxSRC and to my surprise there seems to be quite a few.
Some good points were made both for and against QxxxSRC.
Thanks again and Happy New Year!
Njal Fisketjon (Njål Fisketjøn)
I think the main reason for keeping the QxxxSRC naming is historical, using S/38 Programmers Menu
let the system supply the source file name from the member type.
I see no benefit from renaming the QDDSSRC to FILES, and since most shops do their work in RPG I see
no real benefit from mixing RPG & CL source. If you're using a lot of different languages maybe, but
most shops don't.
I have been working with the same system for many years and know most of the program names. I
therefore seldom needs the search capabilities of PDM, and think it's must faster to just type the
member name, than first type position to and then option. Had the PDM lists had an extender I might
consider changing, but we have used the exit program of the Programmer Menu as well, which is quite
handy.
We place CRT** command options in comment lines at the beginning of the source, and the exit program
adds them to the CRT** command string before submitting
Examples:
PF
/*CRT** SIZE(50000 10000 5)
PRTF
/*CRT** PAGESIZE(70 100) FORMTYPE(A4)
ILERPG
/*CRT** BNDSRVPGM(DAT MSG)
and so on.
I could of course create a userdefined for create that did the exit program stuff, but why bother?
Njål Fisketjøn
e-mail: nfis...@hesgrp.com
http://www.robin.no/~nfisketj
Jon Jerpbak
I have worked at a number of shops and only one used a common source
physical file. All of the others used the QxxxSRC standard. I actually got
used to the common file and did like it.