Skip to main content

Tips & Techniques : Managing a file in LMi that is created by a program in QTEMP

  • October 7, 2021
  • 3 replies
  • 1 view
Joe Baumgarten

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? :)



------------------------------
Joe Baumgarten
Senior CSE
Rocket Internal - All Brands
Ames IA United States
------------------------------

    3 replies

    George Loose
    • George Loose
    • New Participant
    • October 8, 2021

    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? :)



    ------------------------------
    Joe Baumgarten
    Senior CSE
    Rocket Internal - All Brands
    Ames IA United States
    ------------------------------
    What could be easier?  Consider this...

    I can suggest an alternate strategy, that is, if you have access to the "PGMA" CL program source code.

    I have discovered that relying on IBM i outfile layouts will often eventually cause a CPF4131 error, because IBM sometimes updates those outfile definitions.

    To keep my software product insensitive to IBM changes, so that I don't get Support calls and bug fix requests, I have defined my own table that is comprised of only the columns I need from the outfile, to be used by my application. 

    To leverage my stable file, I would add these changes to the example PGMA program:
        1. Change the CL program to refer to the stable file (which can be registered in the deployed product's library for database tables) .
             1.1. Use DSPFFD to view the column definitions of the outfile produced by the IBM i command, perhaps into a temporary work library.
        2.  Use CRTDUPOBJ to duplicate from your empty, reference copy of your stable file, into the QTEMP library of the current job.
            2.1.  Be sure to first check if the file exists in QTEMP, perhaps by using CLRPFM, and if the file is not found, have the MONMSG DO( ) command perform the CRTDUPOBJ action.
        3. Allow the existing IBM i command to produce its outfile.
        4. Use the CPYF command with FMTOPT(*MAP *DROP) to copy from the IBM i command outfile to the QTEMP clone of my stable file.

    This approach allows you to recompile your CL program within LM(i) without concern for the transient nature of QTEMP files, and your stable version of the outfile data can be registered as part of your deployed product.  This would simplify your LM(i) environment and eliminate the need for a non-distributed library.

    George Loose
    Technical Product Manager - IBM i
    (and still a hands-on programmer!)
    SMA Technologies
    Houston, TX

    ------------------------------
    George Loose
    Technical Product Manager - IBM i
    SMA Technologies
    Houston TX United States
    ------------------------------
    Joe Baumgarten
    David Andrews
    Joe Baumgarten
    What could be easier?  Consider this...

    I can suggest an alternate strategy, that is, if you have access to the "PGMA" CL program source code.

    I have discovered that relying on IBM i outfile layouts will often eventually cause a CPF4131 error, because IBM sometimes updates those outfile definitions.

    To keep my software product insensitive to IBM changes, so that I don't get Support calls and bug fix requests, I have defined my own table that is comprised of only the columns I need from the outfile, to be used by my application. 

    To leverage my stable file, I would add these changes to the example PGMA program:
        1. Change the CL program to refer to the stable file (which can be registered in the deployed product's library for database tables) .
             1.1. Use DSPFFD to view the column definitions of the outfile produced by the IBM i command, perhaps into a temporary work library.
        2.  Use CRTDUPOBJ to duplicate from your empty, reference copy of your stable file, into the QTEMP library of the current job.
            2.1.  Be sure to first check if the file exists in QTEMP, perhaps by using CLRPFM, and if the file is not found, have the MONMSG DO( ) command perform the CRTDUPOBJ action.
        3. Allow the existing IBM i command to produce its outfile.
        4. Use the CPYF command with FMTOPT(*MAP *DROP) to copy from the IBM i command outfile to the QTEMP clone of my stable file.

    This approach allows you to recompile your CL program within LM(i) without concern for the transient nature of QTEMP files, and your stable version of the outfile data can be registered as part of your deployed product.  This would simplify your LM(i) environment and eliminate the need for a non-distributed library.

    George Loose
    Technical Product Manager - IBM i
    (and still a hands-on programmer!)
    SMA Technologies
    Houston, TX

    ------------------------------
    George Loose
    Technical Product Manager - IBM i
    SMA Technologies
    Houston TX United States
    ------------------------------
    Hi George, 

    When I asked "what could be easier?", I wasn't expecting a reply :) 

    But your method is quite ingenious. 

    Thanks for sharing!

    Joe.

    ------------------------------
    Joe Baumgarten
    Senior CSE
    Rocket Internal - All Brands
    Ames IA United States
    ------------------------------
    David Taylor
    • David Taylor
    • Participating Frequently
    • October 11, 2021

    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? :)



    ------------------------------
    Joe Baumgarten
    Senior CSE
    Rocket Internal - All Brands
    Ames IA United States
    ------------------------------
    Another approach would be to skip the traditional use of DSPLIB and the work file and go straight to the SQL listing for the job's library list.  Simon does a better job of explaining the details on his blog, https://www.rpgpgm.com/2016/02/retrieving-jobs-library-list-using-sql.html. This solution also gets around the file level check when IBM changes the file format for one of these work files.  The only real barrier now is getting over the "we have never done it that way" syndrome. :) 


    SELECT ORDINAL_POSITION AS POS,
         SYSTEM_SCHEMA_NAME AS LIBRARY,
         TYPE,
         CAST(TEXT_DESCRIPTION AS CHAR(50)) AS TEXT
   FROM QSYS2.LIBRARY_LIST_INFO


    ------------------------------
    David Taylor
    Senior Developer
    Range Resources Corporation
    Fort Worth TX United States
    ------------------------------
    Joe Baumgarten
    S

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement