Rocket DevOps (formerly Aldon)

Here is the scenario:

• PGMA is a CL program. Its job is to read through a list of all of the objects in a library and take action on them.
• It declares a file called DSPLIBPF.
• This file is generated in the CL program on the fly via the DSPLIB command to an output file in QTEMP.
• The program does an override database file command to specifically point to the file in QTEMP.
• Once the program is done, the file is automatically deleted when the operating system deletes the job's QTEMP library.

That's a very popular technique on the IBM i! The problem is that you can't compile the program by submitting it to batch because you can't create the file in the batch job's QTEMP. You end up having to accurately create the file in QTEMP (not always easy to do if the file is hard to generate) and then compile the program interactively.

 LMi can make this process a lot easier:

1. Create a  new "non-deploy" library group in your release.
1. We need this new library group to tell deployment that we do not want to deploy this file over to the target systems. We need the program to create it on the fly in QTEMP and for that version of the object to be the only version found in the run time library list.
2. STRLMI, 13 Work with Releases, 2 Change, 3 Change library groups.
3. Add the new library group.  Call it "QTEMP no deploy". Be sure to direct the object to one of the release's existing controlled libraries. 
2. Update your deployment target definition to NOT deploy any object of this library group.
1. STRLMI, 6 Deployment, 13 Targets, 54 Mapping.
2. Make sure your "qtemp no deploy" library group has "*NONE" in the target library. This is what stops it from getting send and restored on the target systems. 
3. Press F6 to add the file as a permanent object to your release.
1. Make sure that you specify the "source option" of 9=None. Typically, there is no source code for these files, they get created via a command. 
2. Make sure you select the "qtemp no deploy" library group you created above.
3. On the command line, create the file in your development library (not in QTEMP)
4. Check out the program that references the file. 
5. Compile, promote and deploy the two objects as usual. The program will be deployed, the file will not!

Making this a "permanent" object in the LMi structure on the dev box is one of the advantages of LMi! As the developer works on future changes to programs, they never have worry about recreating this "on the fly" file; it's already in the LMi library list! When you compile in dev and promote up the line, LMi will have no problem compiling the program in batch because the file is defined to the release. When you deploy, the program will be sent to the target but the "temporary" file will not.

What could be easier? :)

Here is the scenario:

• PGMA is a CL program. Its job is to read through a list of all of the objects in a library and take action on them.
• It declares a file called DSPLIBPF.
• This file is generated in the CL program on the fly via the DSPLIB command to an output file in QTEMP.
• The program does an override database file command to specifically point to the file in QTEMP.
• Once the program is done, the file is automatically deleted when the operating system deletes the job's QTEMP library.

That's a very popular technique on the IBM i! The problem is that you can't compile the program by submitting it to batch because you can't create the file in the batch job's QTEMP. You end up having to accurately create the file in QTEMP (not always easy to do if the file is hard to generate) and then compile the program interactively.

 LMi can make this process a lot easier:

1. Create a  new "non-deploy" library group in your release.
1. We need this new library group to tell deployment that we do not want to deploy this file over to the target systems. We need the program to create it on the fly in QTEMP and for that version of the object to be the only version found in the run time library list.
2. STRLMI, 13 Work with Releases, 2 Change, 3 Change library groups.
3. Add the new library group.  Call it "QTEMP no deploy". Be sure to direct the object to one of the release's existing controlled libraries. 
2. Update your deployment target definition to NOT deploy any object of this library group.
1. STRLMI, 6 Deployment, 13 Targets, 54 Mapping.
2. Make sure your "qtemp no deploy" library group has "*NONE" in the target library. This is what stops it from getting send and restored on the target systems. 
3. Press F6 to add the file as a permanent object to your release.
1. Make sure that you specify the "source option" of 9=None. Typically, there is no source code for these files, they get created via a command. 
2. Make sure you select the "qtemp no deploy" library group you created above.
3. On the command line, create the file in your development library (not in QTEMP)
4. Check out the program that references the file. 
5. Compile, promote and deploy the two objects as usual. The program will be deployed, the file will not!

Making this a "permanent" object in the LMi structure on the dev box is one of the advantages of LMi! As the developer works on future changes to programs, they never have worry about recreating this "on the fly" file; it's already in the LMi library list! When you compile in dev and promote up the line, LMi will have no problem compiling the program in batch because the file is defined to the release. When you deploy, the program will be sent to the target but the "temporary" file will not.

What could be easier? :)

Here is the scenario:

• PGMA is a CL program. Its job is to read through a list of all of the objects in a library and take action on them.
• It declares a file called DSPLIBPF.
• This file is generated in the CL program on the fly via the DSPLIB command to an output file in QTEMP.
• The program does an override database file command to specifically point to the file in QTEMP.
• Once the program is done, the file is automatically deleted when the operating system deletes the job's QTEMP library.

That's a very popular technique on the IBM i! The problem is that you can't compile the program by submitting it to batch because you can't create the file in the batch job's QTEMP. You end up having to accurately create the file in QTEMP (not always easy to do if the file is hard to generate) and then compile the program interactively.

 LMi can make this process a lot easier:

1. Create a  new "non-deploy" library group in your release.
1. We need this new library group to tell deployment that we do not want to deploy this file over to the target systems. We need the program to create it on the fly in QTEMP and for that version of the object to be the only version found in the run time library list.
2. STRLMI, 13 Work with Releases, 2 Change, 3 Change library groups.
3. Add the new library group.  Call it "QTEMP no deploy". Be sure to direct the object to one of the release's existing controlled libraries. 
2. Update your deployment target definition to NOT deploy any object of this library group.
1. STRLMI, 6 Deployment, 13 Targets, 54 Mapping.
2. Make sure your "qtemp no deploy" library group has "*NONE" in the target library. This is what stops it from getting send and restored on the target systems. 
3. Press F6 to add the file as a permanent object to your release.
1. Make sure that you specify the "source option" of 9=None. Typically, there is no source code for these files, they get created via a command. 
2. Make sure you select the "qtemp no deploy" library group you created above.
3. On the command line, create the file in your development library (not in QTEMP)
4. Check out the program that references the file. 
5. Compile, promote and deploy the two objects as usual. The program will be deployed, the file will not!

Making this a "permanent" object in the LMi structure on the dev box is one of the advantages of LMi! As the developer works on future changes to programs, they never have worry about recreating this "on the fly" file; it's already in the LMi library list! When you compile in dev and promote up the line, LMi will have no problem compiling the program in batch because the file is defined to the release. When you deploy, the program will be sent to the target but the "temporary" file will not.

What could be easier? :)