This will be what I hope will be the first of many posts where I express my humble opinion (IMHO) about something, and you let me know what you think. This will only work if I get feedback from you, the readers of this blog.
I would like to start with source files.
My opinion is that you should keep the source members for all object types (RPGLE, DSPF, CLLE, PF, LF, etc.) in one source file in each library.
Some of my colleagues disagree with this, and keep the various types of source in their own source file.
I know that you can store source in the IFS (Integrated File System) of the IBM i. If you work in an environment where you do that I would like to here what you think are the advantages and disadvantages of doing that.
As I have mentioned before I work on several IBM i servers that have both home-grown and a purchased ERP software. Within the group of senior programmers and Programming Managers there is a difference of opinion on how many source files should be used in each home-grown application.
Method 1 - Classic
Some prefer the classic IBM i arrangement, with the following source files:
- QCBLSRC – CBL members, fortunately there is only in one library with COBOL programs in it.
- QCLSRC – CLP and CLLE members.
- QDDSSRC – DSPF, PF, LF, PRTF members.
- QPNLSRC – PNLGRP source.
- QQMQRYSRC – QMQRY members.
- QRPGSRC – RPG members.
- QRPGLESRC – RPGLESRC, SQLRPGLE members.
In some libraries QRPGSRC and QRPGLESRC have been merged into an expanded QRPGSRC.
Method 2 - All in one
The alternative method is to have one source file in each library that contains all the source members. For example, IMPSRC contains all the source members for the objects in the library IMPLIB.
Differences
| Method 1 - Classic | Method 2 - All in one |
| Having separate source files make it easier to look for just, for example, RPGLE members only. I go to QRPGLESRC. | Can easily be done in the WRKMBRPDM command. Just select the type of members you want to display. |
| The QRPGLESRC and QQMQRYSRC source files are different sizes to the others, they have a record length of 112 and 90. The others are all 92. | If you create the single source file with a record length of 112 all of the different types of source members will fit. It makes no difference to the various compilers what size the source member is. |
| I cannot have my display file and program have the same name. This is possible as they are not the same object type. | Why would you want to do that? IMHO every object should have its own unique name. |
| This is just the way it is done on a IBM i, as that is how it was on the System/38 and on the AS400 when it was first launched. | That was 25 years ago! Things change as better and more efficient ways of doing things are found. Your not programming the same way you were when the AS400 first was launched are you? |
IMHO
IMHO is for Method 2, the all in one source file.
What do you think? Do you agree or disagree with me?
Let me know by submitting a comment below.
You put them all in one source file then how do you manage source for objects of different types that you want to have the same name? And header files containing prototypes? We have QRPGLESRC and QRPGLECPY source files with a one to one relationship between program/module source and prototype copy member. You can't do that in one source file. Some source files need to be different record lengths too. 192 for ILE RPG. The rest should be left at 92. Keep 'em separate!
ReplyDeleteOh yes you can cope with include files in one src. Prototypes end in .pr: mypgm is the main and mypgm.pr us the included proro. Of course the problem is with members like mbr123456 hehe, ok.. Having all in one helps you keep control of what you have.
Deletein our env. We keeping them seperately, with reason.
ReplyDeleteWe keep those std pgm in 1 source. And those requures to create module, srvpgm, pgm in another.
We launch installer program to compile base on designated src file so as to quick setup automatically.
We are vendor, time is money
Makes sense?
I work in a large shop and we use method 2 for each major application. We also have a second source member for psuedo source code for our change management application.
ReplyDeleteIt makes no difference to me.
ReplyDelete1) check the normal standards, RPGLE source should be 112 in length, any more than that is a waste if space.
2) I agree, no two object should be named the same even if different types. Our std is display files begin with S, rpg & le R, CL is a C, physical files are F, logicals are L.
3) as said if all are 112 then it makes no difference to the program.
4) We have always kept them separate because the ERP package is set that way to we adhere to a) the ERP package standard b) or the client's standard.
There is also the environment where we have a library for data objects and a library for program objects and a library for source objects.
ReplyDeleteI am in an environment where we use one source file and it is nice to go to one place for all your source, but we do have a utility library with its own source files and some various packages with their own source libraries.
I have heard that putting source in the IFS is a way to give access to source control programs and editors that are NOT Power i specific, so a shop that might have Java or PHP or something else that is version-ed off the Power i might want to control all its source together and the IFS gives it access to the files. I could be wrong since I have never been in that environment but that is what I have read.
I have worked a place where they sell applications and they were selling just the program objects so having the source in a separate library made sense for them, until it was time to code changes then it became a nightmare with customer modifications etc.
I guess the bottom line is what works for your environment.
In all my previous positions we have different source files for the different source types. I started this position this year and they have only one. (Well, one source file per library, but different libraries for different application groups.)
ReplyDeleteIt took some getting used to. But I think I like it now.
It's true that sometimes it's inconvenient to search specifically for a CL when all sources are in one file. On the other hand, it's nice to do all of my editing, compiling, string searching, and name searching in one place. And it does ensure that names don't overlap.
It seems there is no difference. None of the organization has significant advantage. But be noted: after IBM i launched, many applications, automatic tools on IBM i are assuming source files are organized in classic way. So unless you are sure you will never be in touch to such applications and tools in future, you shall not abandon classic source file organization. Nor switching file organization later will be costly and painful.
ReplyDeleteI like the concept of a single file for all source types. Having said that, I NEVER USE THAT CONCEPT!
ReplyDeleteThe problem is that that method breaks down as soon as you add any code from another party. And you always have such code.
You can't beat 'em, so you might as well join 'em.
I always keep different types in different files, but that began because of a mistaken belief that different source types would breed if kept together (we came from a mainframe environment). Today I know better and don't think it matters. What is important is to keep source and object in the same library. Very annoying when clients don't follow that rule.
ReplyDeleteIts how JDEdwards has been doing it for years. Everything goes in JDESRC. I like it.
ReplyDeleteI was trained in a JD Edwards shop and I have always liked the single source file JDESRC. For me it is quicker and when I want to search source files for a particular value (field name , etc.) I only have to launch one search for all source types. JD Edwards does however keep their copied source in a separate source file named JDECPY. This setup has always worked for me.
ReplyDeleteSource and objects in one library....good for the convenience of the programmer. Not so great for backup and recovery, deployment of the object code, and so on. If (as is usually the case) programmer's convenience is not the overriding goal, don't put it all in one place.
ReplyDelete- kh
I think one character program names are the best. The rest should be reserved for telling you what type it is. Like xIAMCL, yIAMRPG and so on. (sarcasm) No, I hate that! Yet that is what people do. They keep their stuff in separate files yet insist people reserve a character to differentiate the name. For example XXX500 is assumed to be RPG, while XXX500C is assumed to be CL. Now that have this believe that they can merrily compile XXX500C out of QCLSRC and it won't blow away any like named RPG program because it has a C at the end. However I've seen it done. RPG program EXEC is killed by CL program exeC. Ok, maybe a bad example but you see how they end with a C.
ReplyDeleteOTOH, if you stop using stupid editors like SEU and start using RDP you can visualize all members as if they are in one source file even if they are spread out in the traditional QCLSRC, QRPGLESRC, etc. Just select your member name, (like ORD5*), and for your file instead of putting QCLSRC put Q*. Works like a charm.
Rob
Apparently, you're an old-time BPCS programmer.
ReplyDelete- kh
Actually, I think both systems are outdated. In the 21st century you use a source archiving system to keep sources and only take out a source when needed for change. And there the best option is too keep things together that belong together - meaning per project.
ReplyDeleteMy main point is that any scheme chosen should leverage the object type and sub-type feature of the AS/400 - iSeries - Sys/i native OS. But since many shops also use packages and may need to merge local changes, then separate sources must be maintained that conform to a target package. In any case, all local sources should be kept in a single library, so that backing it up saves all meta-data.
ReplyDeleteThus, all program sources could be stored in a PROGRAM source-file, whether RPG, COBOL, PL/1, C, or whatever. Display DDS in DISPLAY, print in PRINT, control language in CL, SQL ... you get the picture. Object name and source-member stay the same. KISS, and all local sources in one library, all local program objects in a single library, all display/printer objects in another, and all data-container and view objects in file libraries.
If your platform hosts multiple customers/clients, each with their own spin - say on report headings, then they will be need to be treated the same way as a package vendor, yet you use your local scheme in their libraries.
The native development tools should be used, since the Hawkeye and change-management packages work well with that approach. Those tools have everything a developer needs, and lack only the drag-n-drop graphic nonsense.
The only reason to use the IFS is that an owner/manager is too cheap and stupid to buy the native developer tools, and requires that free things such as emacs and CVS/Subversion get used.
Started out with multiple source files and see no reason to change now. Works well for me.
ReplyDeleteI needed to create new source development library and while searching for what record length is now standard I ran across this post. I decided for my purposes it now makes sense to only create one source file for all the objects. AS a rule I never name cl and rpg the same.
DeleteI mostly use single source file, have so for years. Easier to find stuff. Hate bouncing around to different source files just to see what the CL for an RPGLE pgm does. Either way isn't wrong, as long as your choice makes you more productive.
ReplyDeleteI still prefer the classic method. Most the shops I've been a part of in the past were using it. I think it's much cleaner but it's your choice as long as you're more productive & comfortable either way is ok.
ReplyDeleteWe have the old classic method. But after using Aldon change management where it presented as a single list regardless of the file it is in, you realize that having seperate source files is a waste of time and gains you nothing. And if you are not using a change management system you are on the wrong boat. Have to say I hated it at first but now it is my best friend. You don't have to have objects with the same name so why do it? No excuses
ReplyDeleteIt would be better to have separate source file each member type rather than all members in single source file...
ReplyDeleteWhy?
DeleteThe whole premise of the post is for people to explain why, in their opinion, their method is best.
I worked on JDE for a few years and having all the source members in one file made life a whole lot easier. Since the first character of a member identified it's type, you could select the CL, RPG, DDS etc for a program in PDM and view them all together.
ReplyDeleteWhy would you want to have multiple source files with the same name anyhow, you can't compile them with the same name!
The need to use multiple source files I believe dates back to the S/36 (maybe S/38 too not sure as it's so long ago now), when there were limits on the number of members in a source file.
I'm not in favor of one source file for all. I prefer to use one source file for each object type: QMODSRC for Modules (or bound programs), QDDSSRC (or QFILSRC) for Files, etc.
ReplyDeleteThis gives you the ability to have modules/programs with the same name as display file, etc. Just another way to do it.
My .02 after 24 years and several shops:
ReplyDeleteI like the Classic method but can work with the Single source, BUT, some things I don't like about the single source method:
1. Source Scans: With very large systems and you KNOW you only need to scan specific members its much quicker to scan a specific member.
2. Many times people accidentally alter the Type so it is not as clean as you think to just set your type values via your PDM Subset & see everything.
3. Object Names: Every object name should be unique to avoid all sorts of confusion and issues. Also, the unique part s/b at the end, not the middle, not the beginning. This allows you to use the WRKOBJ xxxyyy* to see ALL the associated objects of that Root Name. One of the most widely used commands on the system, IMHO.
4. I also agree that having different libraries for Source & Objects and Data Objects is essential for a clean DR and Backup.
5. None of the shops I've been in have had what I consider to have had ALL of the 'Best Practices' mentioned above. You take what you get and keep in mind that we didn't get to design the architecture and layout as it was unfortunately done many years ago. Anyone heard of a new iSeries installation lately? Not me... :-)
Ok a little late to the discussion, but, very surprised at the lack of support for IFS-based source code. Easy offline access, ability to mix all source types (sql, html, xml, java, rpg, etc), 3rd party tools for editing/search/compare/etc, and most importantly being able to version control it all with Git.
ReplyDeleteIf you use a Change Management System (aka Lifecycle Manager), then you really should not care. These days almost every shop has either Aldon, Turnover, Implementer, or some other form of CMS.
ReplyDeleteWhat matters is keeping data and source in separate libraries, because data needs to be backed up daily, while source can be backed up on weekly basis. Most shops have different servers for development and production. In those cases the data would be backed up from production box, and source from the development box (good shops deploy code to production on weekly basis after code review).
For the five years I have been using only on source file. It make it easier where you have all your CLLEs, RPGLE, SQLLE, etc... One issue that I have is that I can not find the standard records size. I like Bill W with the 112. Will this size cover most sources?. Thanks. Carlos
ReplyDelete112 will cover all of the popular source types.
DeleteIf you are going to program in totally free RPG you can make your source file even bigger and the RPG compiler will handle it.