Opening/Closing Files in CL

CL
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

From: Ed Seigler To: All

I am developing a CL program that retrieves information about certain files. In order to get this information, I use the Display File Description (DSPFD) command to send the information to an outfile. I then use the Receive File (RCVF) command to read the outfile and access the appropriate field.

The problem is that when I try to use the DSPFD command and send the information to the same outfile, I get message CPF3084 (Error clearing member...) meaning that the system cannot clear the file. I close the file before executing the second DSFPD and then open the file before I read it with RCVF. The program is shown in 3.

The problem is that when I try to use the DSPFD command and send the information to the same outfile, I get message CPF3084 (Error clearing member...) meaning that the system cannot clear the file. I close the file before executing the second DSFPD and then open the file before I read it with RCVF. The program is shown in Figure 3.

When I look at program status, the system says that the file member (TRFLIBNAM) is locked. I've tried working with the Override Database File (OVRDBF) command using SHARE(*YES) and the Deallocate Object (DLCOBJ) command, but I can't get the program to work.

From: Pete Hall To: Ed Seigler

Put the DCLF and RCVF commands in a subprogram, and have the subprogram pass back the &RFLIB value in a parameter. Each time the subprogram returns, the file will be closed. CL is very limited when it comes to manipulating database records. Solving this problem requires either two programs or a different language.

From: Matt Fulton To: Ed Seigler

You can't do it the way you're trying to. The system ignores the opens and closes in a CL program-the file is locked from the first time it's referenced in the program until the program ends.

The only solution I've found (ugly, but it works) is to put the reads in a separate CL (or RPG) program and then call it from the main program. If you do that, you can eliminate the open and close, because they're done implicitly.

You'll also have a problem like this if you try to execute a Clear Physical File Member (CLRPFM) command, a Remove Member (RMVM) command, or other file operations to a file that's in use in a CL program.

From: Matt Sargent To: Ed Seigler

As someone else mentioned, the close and open statements won't work using the method you've specified. CL automatically opens the file when you do the first read, and the file remains open until an end-of-file condition is reached or the program terminates. Once it's closed, you can't open it again within that program.

But I bet you could use other methods to get the information you want. It looks like the information you need is always in the first record. Give this a try:

1. Use the DSPFD command on RBFILEP and send the information to an outfile in QTEMP.

2. Run CPYF against the file you created in step one and select the first record. The output from CPYF should be directed to TRFLIBNAM, specifying REPLACE(*YES).

3. Use the DSPFD command on RIFILEP and send the information to the same QTEMP outfile.

4. Run CPYF again, selecting the first record from the outfile in QTEMP. This time, the output to TRFLIBNAM should specify REPLACE(*NO).

This process loads file TRFLIBNAM with the two records you need before the file is even opened. With two RCVFs, you've got your data.

If your objective is to find what library these files are in, you could use the Retrieve Object Description (RTVOBJD) command and not have to worry about reading outfiles.


Opening/Closing Files in CL

Figure 3 Attempt to Open the Same File for Output in CL

 /*TRANSFER INVOICES TRANSACTIONS FROM CURRENT FILES TO HISTORY*/ PGM DCLF FILE(SMRCHIST/TRFLIBNAM) DCL VAR(&RBFILEP) TYPE(*CHAR) LEN(10) DCL VAR(&RIFILEP) TYPE(*CHAR) LEN(10) /*RBFILEP*/ CLOF OPNID(TRFLIBNAM) MONMSG MSGID(CPF4520) DSPFD FILE(RBFILEP) TYPE(*RCDFMT) OUTPUT(*OUTFILE) + FILEATR(*PF) OUTFILE(SMRCHIST/TRFLIBNAM) OPNDBF FILE(SMRCHIST/TRFLIBNAM) OPTION(*ALL) RCVF CHGVAR VAR(&RBFILEP) VALUE(&RFLIB) /*RIFILEP*/ CLOF OPNID(TRFLIBNAM) MONMSG MSGID(CPF4520) DSPFD FILE(RIFILEP) TYPE(*RCDFMT) OUTPUT(*OUTFILE) + FILEATR(*PF) OUTFILE(SMRCHIST/TRFLIBNAM) OPNDBF FILE(SMRCHIST/TRFLIBNAM) OPTION(*ALL) RCVF CHGVAR VAR(&RIFILEP) VALUE(&RFLIB) ENDPGM 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  •  

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: