Profound is creating subfile control record.

[leomoore]

I created a format then added a grid expecting to use the format as my subfile control record. I saw an oddly named format but it had no fields or text associated with it, so I removed it in Profound Designer. I put the program into debug and saw it write the subfile records, but when the program hit the EXFMT for my expected control record, the subfile appeared, but was empty. After spending an embarrassing amount of time trying to fix the problem in the RPG, I took a deep breath and on an impulse looked at the DDS member. Low and behold the oddly named format was there and designated as the control record.

The control record is named QSFLCTL001. It includes the SFLCTL, SFLSIZ, SFLPAG, and SFLDSP key words. SFLSIZ and SFLPAG are set to 23 rather than the 10 and 9 I originally assigned. In addition the format contains:

1 2HTML('QPUISFLHOMEFMT')

The format I thought was my control record, HOMEFMT, contains the following:

1 2HTML('QPUICTL1 UDCMSGSFL 5 RS-
FLDSP 0 FSFLDSP RSFLDSPCTL-
0 FSFLDSPCTL RSFLCLR 0 FS-
FLCLR RSFLPAG 1 C1 9 RS-
FLSIZ 1 C2 10 0 3 RO-
VERLAY 0 FOVERLAY RASSUME -
0 RROWS 2 C1 1C1 -
1 ')

I believe that QPUICTL1 contained in the string is the name of the format I thought I deleted.

What does this mean?

[David]

In PUI, simply adding a grid to a record format makes it a "subfile control" record format. I say that in qoutes because, as you've seen, it is not a "real" control record format.

This is done for various technical reasons -- the generated DDS is designed for consumption by our designer and runtime and is not designed for manual browsing or editing. You should never remove record formats from the DDS manually, only with the designer.

The "funny" record format is created because the DDS compiler requires that there be "real" subfile control format for every subfile. It is not designed for actual use.

Our process associates the "subfile control" record with the subfile in another way -- using meta data that we've embedded into the subfile. This is the "funny" stuff you saw in there.

All that said, you don't need to worry about that too much, you can display your subfile by simply executing the record format that you added the grid to in the designer. HOMEFMT, in your case.

If the subfile did not display even if you wrote records to it, it's because either the SFLDSP indicator was not on, or the SFLCLR indicator was on when you executed HOMEFMT.

[leomoore]

That is interesting information. I did delete the extra format through Profound Designer, but I wonder if I managed to create a problem when I did it.

I have reviewed the RPG code (listed after this sentence), and it appears to be correct.

Exsr ClrSubfile;
SflRcdNbr = 1;

//DoU oNextProgram <> *Blanks;
DoW ContLp;
Exsr FillSubfile;
SflDspCtl = *On;
Exfmt HomeFmt;

Here is the code for the two subroutines.

Begsr ClrSubfile;

SflClr = *on;
write Homefmt;
SflClr = *off;

Endsr;

Code: Select all

         Reade (Sycode : SyUsc1) Fstrudc;          
         If not %eof(FstrUDC);                     
            recnum = recnum + 1;                   
            MsgSeq = SyUsc2;                       
            Msgtxt = %trim(Sydes1) + %trim(Sydes2);
            write UdcMsgSfl;                       
         EndIf;                                    
      EndDo;                                       
                                                   
      If recnum > 0;                               
         SflDsp = *On;                             
      Endif;                                       
                                                   

I believe the code is correct and have followed it step by step through debug. I believe that I have managed to damage the display file's meta-data. Rather than continue using up your time, I will make a copy of the file, then create a new file from scratch using the same field names. This time, when Profound shows the funky looking control record, I will leave it alone. It should not take long to rebuild. I will update this topic once I have completed the experiment.

[David]

As this has been resolved offline through support, I wanted to update this for the benefit of other readers.

The problem was that the SFILE keyword was not given on the file specification in the RPG program. This causes Open Access to report the format as not being a subfile at runtime when WRITE operations are done. This causes unpredictable behavior in the handler.

Adding the SFILE keyword resolves the problem and the program runs normally.

For the next update to Profound UI, we have added better handling of this situation -- it will give an "invalid relative record number" exception in this case. This is exactly what would happen on the green screen if you did the same thing.