Refresh Interactive Screens

[R.Koontz]

Just a quick thought. Anyway to change the wait parm when user hits enter or something?

[gbarnes]

Try the FRCDTA and the OVERLAY keywords on your subfile control record.

[johnhester67]

You can safely ignore the errors when writing the control record and reading the filename, hence my use of.

          write(e) ctl1;
          read(e) selfupd2 ;

and your use of monitor.

The real error occurs when doing a chain or readc to the subfile record.

From your previous post
"I get the error again down the line when it tries to chain to the subfile for an update."

If you look at the code in my previous posting, you will see that it clears and rebuilds the subfile every 999 records. Try running it, but change subFileFull to 15 instead of 999. Thus the data structure array will work. Just don't chain to the subfile, clear it then rebuild it from the array.

[R.Koontz]

Thats not the problem. It would still give me the error b/c I'm still writing data to the subfile from a data source. Either array or file it would not make a difference.

[johnhester67]

How about this?
Use the auto refresh technique that crashes when you chain to the subfile.
Create a data structure that has the same layout as your subfile display record including the RRN.
Create an array of this data structure.
When you write a record to the subfile, add it to the data structure array.
When it comes to processing the subfile with chain or readc, don't. Process the array instead. Then clear and rebuild the subfile from the ammended array.

[R.Koontz]

I could do that but still would get the error I'm getting.. Its such a cobbled up program to begin with.. I wish I had time to re-wright it but I don't.

Thanks for your input

[azeitonav]

This is how I did it back in 2003. Added Invite key word to last record written to screen before the read (I always write a footer record for SFLs). added MAXDEV(*FILE) to program display file definition. Write control record then footer record. Read display file and check for error. If error status is 1331, it was a time out and I just reload the SFL with the refreshed data. We actually had a file with the wait time per user and overrode the display file wait time before opening the file.

[R.Koontz]

So that seem to work. I think the problem was doing the read to the display file name. So I took a gamble and applied the same kind of logic to the actual program ( written years ago) This program has the read and write and all the extra stuff needed including the 3 second wait time. it works to trigger the display file again but get this error... any ideas on what I can look at to fix this...So I thought I would put a monitor around the read subfile file b/c I was getting this error. But it tuens out I get the error again down the line when it tries to chain to the subfile for an update.
Any ideas?

Message . . . . : SFLDSPCTL or SFLDSP option required for PUTGET.
Cause . . . . . : The SFLDSPCTL or SFLDSP option is required for PUTGET for
file S#DP546 in library RONTEMP. GET part of PUTGET required that input or
output be done. However, input or output cannot be done unless SFLDSPCTL or
SFLDSP is specified.
Recovery . . . : Either correct the program or the device file and then try

[johnhester67]

Okay, forget what I said in my last post about not being able to do it with a subfile.

I just cobbled this together and it works. No data queues, just a subfile.

The display file SELFUPD2 should be created with WAITRCD(3)

     A                                      DSPSIZ(24 80 *DS3)
     A                                      PRINT
     A                                      INVITE
     A                                      CA03(03 'exit')
     A          R SFL1                      SFL
     A            SDATA          5   O  4  4
     A          R CTL1                      SFLCTL(SFL1)
     A                                      OVERLAY
     A  91                                  SFLDSP
     A  90                                  SFLDSPCTL
     A  89                                  SFLCLR
     A                                      SFLSIZ(0161)
     A                                      SFLPAG(0160)
     A                                      SFLLIN(0004)
     A  90                                  SFLEND(*MORE)
     A                                  1  3TIME
     A                                  1 30'SELF UPDATING DISPLAY'
     A                                      DSPATR(HI)
     A                                      DSPATR(UL)
     A                                  3 26'Your Data Will Be Shown Here'
     A                                      DSPATR(HI)
     A          R FKEYS
     A                                      OVERLAY
     A                                 24  4'F3=Exit'
     A                                      COLOR(BLU)

The RPG program SELFUPR2 should be created with DFTACTGRP(*NO)

     FSELFUPD2  CF   E             WORKSTN SFILE(SFL1:RRN1) maxdev(*file)

     D event           S              5a
     D rrn1            S              4  0
     d subFileFull     c                   999

      /free
       exsr ClrSfl;
       write fkeys;
       dou *In03 ;
          if rrn1 >= subfileFull;
             exsr clrSfl;
          endif;
          write(e) ctl1;
          read(e) selfupd2 ; //ĪRead From Display File
          sData  = %subst(%char(%time):4:5);
          rrn1 += 1;
          Write(e)  sfl1;
          *IN91 = *On  ;
       enddo ;
       *inlr = *On ;


       begsr clrSfl;
          *In89 = *On ;
          *In90 = *Off ;
          *In91 = *Off ;
          *In75 = *Off ;
          write(e)  ctl1;
          rrn1 = 0 ;
          *In89 = *Off ;
          *In90 = *On  ;
          *In91 = *Off ;
       endsr ;
      /end-free

When called the program adds a record to the subfile then displays it. It keeps adding and displaying automatically.
The only thing I would say is make sure you read the filename rather than the subfile control record name.

[R.Koontz]

I don't need to store the data anywhere to start the subfile Its an EDI monitor program. When new EDI orders come in it displays them on the screen for the user. Then they can accept them or reject. So no input at the time it gets generated. The only problem I'm having is it will not time out like a regualt screen does.
I created a simple subfile that just counts to 100. Then when it times out it would count to 200 etc.. It does not time out. It does what I want it to do when I hit enter. I did this with a screen to display 1 then add 2.... every 3 seconds and thats works just fine. Its the subfile who is the problem.. I must have missed something but its coded the same.
Any ideas?
Thanks

[johnhester67]

For some strange reason that I have never managed to find an explanation for, the method I suggested yesterday does not work with subfile displays. You didn't mention it was a subfile program, otherwise I would have suggested this method instead.

The last article cited by SPITCHER http://www.itjungle.com/mpo/mpo081502-story06.html does what you want. It allows input to your program from the screen and from a data queue at the same time. You will need to ammend your subfile program to call the QRCVDTAQ API and add some code to rebuild or update the subfile when data is received from the data queue.

I suggest creating a trigger program on the file or files that hold the order data. When the data in these files is changed, have the trigger program write an entry to a data queue. This data queue has been attached to the display file of the subfile program at compile time or using the CHGDSPF command. Then have the subfile program use whatever data sent to the data queue to rebuild or update the subfile without user input.

When I used this technique, I sent the order number to the data queue. My program updated the subfile when existing order details had been changed. I rebuilt the subfile if an order had been deleted, completed or new details were added to an existing order.

At the site I coded this for, there was only one person doing order entry. If your site has multiple users entering orders at the same time you will need to come up with something a bit more complex than this, but at least it is a start.

Regards.

John

[R.Koontz]

Thanks but I have seen those. I can get a single screen to work but not the subfile. It displays the data in the subfile just fine using the write and read method. I have the invite and all the other goodies in the program (same program that uses the regualr screen). It just will not time out and dispaly it again and again after 3 seconds like it does for the regualr screen. I have complied the screen with a 3 second timeout. There has to be something I'm missing. It does not seem that hard...lol

Thanks

Try these then

Examples included.

http://www.iseriesnetwork.com/article.cfm?id=17885

http://www.iseriesnetwork.com/article.cfm?id=18064

http://www.itjungle.com/mpo/mpo081502-story06.html

http://www.code400.com/forum/showthread.php/2120-Another-SubFile-Auto-Refresh-Question

[R.Koontz]

Thanks but my COBOL is really rusty.. I probably could not even read it righ anymore...

Thanks anyways.

[Terry Winchester]

I have an example of using a data queue to automatically refresh a screen without any user intervention. However, it is written in COBOL...but your more than welcome to have a copy of it...

Terry