|
I'm not sure how much more help I can be, but let me relate this. I create commands to front-end the majority of my work. To keep the library list a slim as possible, I utilize the product library (PRDLIB) parameter on CRTCMD. I experienced a similar situation as you, where I want the command to "just work" in my development and quality libraries. When using option 15 (create options), I wanted Aldon to populate the product library based on where the object is compiled. You can't put &OL (object library) in the create command screen. What I had to do (and works for us) is go into main menu 11. Setup menu, 4. Work with definitions of commands that create objects, position to CRTCMD and option 2 to change. In the create keywords, I added PRDLIB(&OL). So for any of my programs, I'll check out the command and its processing program, compile both into dev, then I can run LG/command and it will run the correct program. Perhaps if you talk to Aldon some more, you might be able to utilize a similar strategy at the application or release level. Loyd Goodbar Senior programmer/analyst BorgWarner E/TS Water Valley 662-473-5713 -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jack Derham Sent: Wednesday, July 13, 2005 19:48 To: 'Midrange Systems Technical Discussion' Subject: RE: ALDON Question Aldon respond as you might expect and with further digging it appears that real problem might just be with the CRTPGM command. My initial approach was to create the program in my library using a Binding Directory and a Library List that included my library as the current library and the ITG library that contained all of the modules that were not being changed. The module being changed was in my library. The binding director included entries for each module in the collection with *libl include for each module definition. This structure did not create the program. My next step was to change the CRTPGM command so it included explicit references to the required modules including explicit reference to the actual libraries. This structure worked. Tomorrow, I will try this same approach but will change the library references to *libl and then I will change the Binding Directory approach with explicit library references. Any experiences with CRTPGM similar to this would be appreciated. For those who are interested this is the comment that we got back from Aldon. Alvin, Thank you for the details. The information you sent shows a successful checkout of the module and a successful creation of the module, so our processing for the modules is working fine. I am thinking that there is some confusion here, the checkout operation by nature will copy the source from the environment where it is being checked out from to the developer environment, it will not copy the object to the development environment, unless it is a non source based object. The create process will be looking in the environment libraries for the modules, if they are not present in the development environment. This will include the PDN, QUA and ITG environments if they are all used in the promotion path. If this is still an issue, could you forward the following output 1. The create in development report and joblog that is causing the problem. 2. An option 11 Print details of the object in question, and a module that is not found. -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Goodbar, Loyd (ETS - Water Valley) Sent: Wednesday, July 13, 2005 2:07 PM To: Midrange Systems Technical Discussion Subject: RE: ALDON Question Thinking about it some more, what do you want Aldon to do? Do you want Aldon to copy the module objects to your dev library? That may be feasible but not worth the effort if... Do you want Aldon to manage the binding directory entries? The overriding problem is the binding directory is not source based. I don't think Aldon will touch (modify) non-source based objects. So you would ask Aldon to look up the module in the binding directory in dev, and change the library to the current environment library. That sounds like too much sugar for a dime. That's also why you can't use substitution variables (&LIB) with it I suspect - not source based. I'm interested in hearing Aldon's reponse. Loyd Goodbar Senior programmer/analyst BorgWarner E/TS Water Valley 662-473-5713 -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jack Derham Sent: Tuesday, July 12, 2005 19:19 To: 'Midrange Systems Technical Discussion' Subject: RE: ALDON Question Thanks for the feedback. We have opened a discussion with Aldon. Will let the list know the results. Jack Derham Direct Systems, Inc. -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Goodbar, Loyd (ETS - Water Valley) Sent: Tuesday, July 12, 2005 8:48 AM To: Midrange Systems Technical Discussion Subject: RE: ALDON Question Now I see what you're saying. You are modifying a module that's used in a binding directory. To be honest, I haven't had to do this through Aldon. However, you can specify *LIBL for the module's library in the binding directory. It will be found when Aldon compiles the program object in order of development, integration, quality, production. You can still recompile the module and program objects in your library. You'd need to test this, but I think once you compile the program, you should see the library where Aldon and the binding directory found your module. Do a DSPPGM on the program object, and screen 3 of 7 (Detail: *MODULE) shows modules used. I suspect OS400 will replace the *LIBL with the actual library of the module bound to the program. This way, you are using known good code (modules in production) and testing your code in dev. HTH, Loyd Loyd Goodbar Senior programmer/analyst BorgWarner E/TS Water Valley 662-473-5713 -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jack Derham Sent: Monday, July 11, 2005 23:51 To: 'Midrange Systems Technical Discussion' Subject: RE: ALDON Question OK, so what you are telling me is that I should never create the program in my development library because using a Binding Directory will tell the compilier logic that the "other" modules are in the production environment. Jack Derham Direct Systems, Inc. -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Loyd Goodbar Sent: Monday, July 11, 2005 9:58 PM To: 'Midrange Systems Technical Discussion' Subject: RE: ALDON Question This to how Aldon works. Think about it like this: the program object in your library already contains the module, so you don't need the module object. You don't need to recompile all of the modules when recreating the *PGM object. Remember, when Aldon recompiles, your production library is in the recompile job's library list. Your development library is first, then QA libraries, then any production libraries. Just change the modules you need in your dev library, recompile them and the program. Unless you hardcoded the module list when creating the program.... That's a no-no. Aldon's designed to use the library list, so let it. HTH, Loyd -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jack Derham Sent: Saturday, July 09, 2005 12:17 AM To: MidRange List Subject: ALDON Question Have an application at a client site that consists of a program that 7 bound modules. When the application was constructed in ALDON all seven Modules were identified, along with a Binding Directory, supporting Display Files and the bound program. Everything seems to work just fine but when I went to check out the objects to make a change, I was surprised to find that the program object was brought to my library as was the binding directory and the source for all modules. What wasn't brought across were the module objects. My question: is this a normal ALDON characteristic or is this a function of local settings that could be changed. It is a real pain to have to compile all of the modules when you really only have to make a change in one. Jack Derham Direct Systems, Inc.
As an Amazon Associate we earn from qualifying purchases.
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.