Managing *PGM objects in ILE environment

[Guest.Visitor]

This is what we did. We made a new type-*pgmsrc. This source member has the crtpgm command and any paramaters needed to recreate the program. The program name is equal to this source member. In the comment lines of RPGLE or CLLE we put a line as follows: @m mymodname whatiamattached to X x where X=type of thing I am attached to and x is how to compile me,as a M for module or P for program. *************** Beginning of data ************************************************** ****0001.00 CRTPGM PGM(PGMSLIB/SFC202P) + 0002.00 TEXT('SALES FORECAST REPORT 1.0') + 0003.00 MODULE(*LIBL/SFC202C) + 0004.00 MODULE(*LIBL/SFC202IA) + 0008.00 ENTMOD(*LIBL/SFC202C) + 0009.00 BNDDIR(PGMSLIB/PGMSILE) + 0010.00 ACTGRP(*CALLER) 0011.00 0012.00 UPDPGM PGM(PGMSLIB/SFC202P) + 0013.00 MODULE(modlib1/modnme1 + 0014.00 modlib2/modnme2) ****************** End of data ************************************************** *******

[Guest.Visitor]

What a mess is to come out of this? If you want to save your head from aches, get organized. Agree upon some consistent naming scheme. ie. we name all serviceprograms with a prefix SV... Use ADM/400. ADM manages all 'parts' that make up your application. One part-type is 'BUILDOPTION' - physically nothing but a sourcemember containing the commands to build 'yourPgm'. If you have your buildoptions defined, you have them documented; if you need to change them, ADM will initiate all the necessary compiles - optionally of __everything__ that depends on your modified part. Check in the 'applications' forum, there are 2 threads regarding ADM. One word to binding(CRTPGM): Bind-by-copy places all the modules specified (on the MODULE parameter) physically into your Pgm. Use this for used-once-modules. Bind-by-reference resolves the modules needed at program load time (parameter BNDSRVPGM). These modules occupy space only in the serviceprogram you put them in (hopefully only in 1 place). Those are the modules you use from more than 1 main program. A Binding directory is what it is - a directory. What the binder could not find from the other two parameters, it tries to find according to the information in the binding directory. You may write into a binding directory what ever you like, it need not even exist on the system. Feel free to ask me more - hope this gives you a clue Regards, Martin.

[Guest.Visitor]

Martin-you must really like ADM. It is not too much of a mess unless someone forgets. We do use binding directories, a generic one per library, and then by groups of related items-barcode etc. We use similiar names for *srvpgm-they are supposed to start with srv.We have a binder source and a binding directory for each *srvpgm. Do you know about how much ADM costs? We already have a source checkout & archiving utility. Do you know anything about ILE sub procedures in RPGLE? Also-we decided to forgoe the S36 naming conventions and source files.All of our source is in QILESRC for ile types. We have a production, test, and developemnt libraries. It is easier to find the source, instead of check QRPGSRC, QCLSRC, QDDSSRC. We left physical files source (not printer files or displays) in its own source and library. We are also getting rid of the FM at the end of display file source-also left overs from S36 days.

[Guest.Visitor]

'What a mess is to come out of this?' .. by no means this applies to you, Barb.It seems you have a good grip on your development environment. Nevertheless i seriousely recommend taking a look at ADM. It really makes life easier.It is part of the ADTS package, which includes PDM, SEU, ... but i'm not sure if it's ready to use. Someone told me that you need to license for it separately. No idea about pricing, though. Ask IBM. As for RPG I am not an expert here; we use Cobol only. (Sup)procedures, by definition, are the smallest useful units to perform a specified task. They work much the same as the usual single-body programs we are used to from the OriginalProgramModel. They may have (or have not) Parameters. They have variables locally defined, which is something everybody ever wanted (no side effects by writing into a global variable). They have an UEP - UserEntryPoint, but as opposed to a program, you can not call them from the 'outside' (no 'PEP - ProgramEntryPoint'). They are local functions to a main program; like Subroutines they are coded into the same source as the main program.If you want to have (sub)procedures available to more than one program, create them as modules, which you put into serviceprograms. I'll be happy to answer more questions, if I can. See ya ... Regards, Martin.

[Guest.Visitor]

Sol-I think you responded to the previous sub proc. question I posted. What I really want to know is why the sub proc printed the global variable named brand, instead of the defined local variable named brand. In debug, in the sub proc, local brand had the correct value in it. In C++ functions, it would print the local variable, not the global.And to get at the global variable brand in the sub proc, one would have to refer to it explicitly.

[Guest.Visitor]

Just a bit of explanation to my previous posting:The new type is a new member type in pdm. It is not a new object type. If you do strseu, press f6 for new member, you can put any kind of type you want in the type field. We agreed to use *pgmsrc. This member is just a text member for documentation purposes at this point. The @m line that we put into the top of the clle and rpgle members is also for documentation. It helps to know if you should compile as a pgm or a module. We have a source checkout and archiving program that is used for version controls. The other in house programmer did some heavy duty source conversion programs for 36 to 400 code. He figures with the above documentation in clle & rpgle, and with the *pgmsrc members, he may someday write something that we can use as a pdm option to recreate pgms & modules. Since we now are using one source file for everything, having the *pgmsrc member helps to know what needs to be used in recreating the program, including binding directory entries, service programs and activation groups. This member uses the base name with a P at the end, then that is also what the *pgm object is named. That way we should be able to keep unique names on *pgm objects. I realize that you could use the dsppgm & get the names of modules used, but this approach works for us. On Tuesday, July 15, 1997, 11:05 AM, Barb Brooker wrote: This is what we did. We made a new type-*pgmsrc. This source member has the crtpgm command and any paramaters needed to recreate the program. The program name is equal to this source member. In the comment lines of RPGLE or CLLE we put a line as follows: @m mymodname whatiamattached to X x where X=type of thing I am attached to and x is how to compile me, as a M for module or P for program. *************** Beginning of data ************************************************** **** 0001.00 CRTPGM PGM(PGMSLIB/SFC202P) + 0002.00 TEXT('SALES FORECAST REPORT 1.0') + 0003.00 MODULE(*LIBL/SFC202C) + 0004.00 MODULE(*LIBL/SFC202IA) + 0008.00 ENTMOD(*LIBL/SFC202C) + 0009.00 BNDDIR(PGMSLIB/PGMSILE) + 0010.00 ACTGRP(*CALLER) 0011.00 0012.00 UPDPGM PGM(PGMSLIB/SFC202P) + 0013.00 MODULE(modlib1/modnme1 + 0014.00 modlib2/modnme2) ****************** End of data ************************************************** *******