Run display program in batch?
Last Post 08 Aug 2006 05:06 AM by EdMan. 23 Replies.
AddThis - Bookmarking and Sharing Button Printer Friendly
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Page 1 of 212 > >>
Author Messages Not Resolved
Atom
New Member
New Member
Posts:6

--
02 Aug 2006 08:22 PM
I converted a complex legacy display program to work in both interactive and batch modes. In interactive mode, the program performs just like what it normally does, which takes input from user and then do the complex processing. When the program is run in batch mode (this is indicated through parameters), instead of getting input from screens, it switches and gets input from data queue or work files. This program is working totally fine in both interactive and batch modes on an interactive session, but it is NOT working when I call it through SBMJOB. I understand that, this is because a submitted job has no display device. I guess some of you might have already done this before, so how did you get it to work? Or is it possible to get it to work this way? Your help is very much appreciated. Thanks. :thumbup:
Tommy Holden
Senior Member
Senior Member
Posts:2833
Avatar

--
02 Aug 2006 08:29 PM Accepted Answer
on your display file F spec set the file to USROPN. second, you'll have to determine programmatically if the job is batch or interactive. If batch mode don't open the display file...
Atom
New Member
New Member
Posts:6

--
02 Aug 2006 09:06 PM Accepted Answer
Thanks for your quick reply. :thumbup: In order not to make too much changes to the complex legacy program, I am replacing only the user input in batch mode with data getting from data queue or work files. Data is still being written to multiple sub-files and later read from for complex processing. I guess I still have to open the display file, so is it possible to do that? :confused:
Jim Wong
Basic Member
Basic Member
Posts:80

--
02 Aug 2006 09:42 PM Accepted Answer
Thanks for your quick reply. :thumbup: In order not to make too much changes to the complex legacy program, I am replacing only the user input in batch mode with data getting from data queue or work files. Data is still being written to multiple sub-files and later read from for complex processing. I guess I still have to open the display file, so is it possible to do that? :confused:
Atom: What is the error message that you are getting and what does the second level text say on the batch job that failed? That should give you a clue as what is failing. You know that you should not display the display file when in batch and handle any exceptions when bad data is in the alternative input be it data queue or other.
Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16408
Avatar

--
02 Aug 2006 10:25 PM Accepted Answer
In order not to make too much changes to the complex legacy program, I am replacing only the user input in batch mode with data getting from data queue or work files. Data is still being written to multiple sub-files and later read from for complex processing. I guess I still have to open the display file, so is it possible to do that?
In order to READ, WRITE or EXFMT a display file, it must have a display device (terminal) associated with it and acquired. If it does not, you'll get an error when you try to access the display file. Does that mean you can't use a display file in a program submitted to batch? No. A batch program can acquire a terminal and use it for display i/o while your program is running. Just use OVRDSPF FILE(myDSPF) DEV(term) to point it to the terminal to use. The terminal should be turned on and sitting at the sign-on screen for this to work. If you don't want to have an actual terminal that always has to be at the sign-on screen when the program is run, you could potentially write a program that pretends to be a terminal. It creates a display device, and handles all i/o to & from that device. This would be rather complicated to code, but you didn't ask if it'd be easy, you just asked if it was possible. :) With this approach, you wouldn't need the data queues, you could supply the input to the screen, just as if a user had typed it. Finally, rather than use a display at all, you might consider replacing the subfiles with MODS. This is probably easier than creating a fake terminal session, and the code will be easier to follow and maintain. The best solution, however, is to write more modular code. I realize that you didn't write the original program, and you're just stuck with it.... but you might keep this in mind for future projects. Keep your display logic in a separate module from your business logic. That way, when it comes time to make a program that can run either interactively or in batch, it'll be easy. Not to mention that it'll be easy to add other interfaces (Web, GUI, etc) if they should ever be desired. Moving forward, this is really the way to go!
Atom
New Member
New Member
Posts:6

--
03 Aug 2006 03:23 PM Accepted Answer
Does that mean you can't use a display file in a program submitted to batch? No. A batch program can acquire a terminal and use it for display i/o while your program is running. Just use OVRDSPF FILE(myDSPF) DEV(term) to point it to the terminal to use. The terminal should be turned on and sitting at the sign-on screen for this to work.
My designated display device to the display file was in “VARY ON PENDING” status all the while so it never worked. As soon as the designated display device is in "SIGNON DISPLAY" status, the program works like a champ now. Great advice! Thank you so much! :thumbup:
The best solution, however, is to write more modular code. I realize that you didn't write the original program, and you're just stuck with it.... but you might keep this in mind for future projects. Keep your display logic in a separate module from your business logic. That way, when it comes time to make a program that can run either interactively or in batch, it'll be easy. Not to mention that it'll be easy to add other interfaces (Web, GUI, etc) if they should ever be desired. Moving forward, this is really the way to go!
I am totally agreed with you. Thank you so much for your help. :D
Bryan Leaman
Veteran Member
Veteran Member
Posts:1745
Avatar

--
03 Aug 2006 03:34 PM Accepted Answer
Data is still being written to multiple sub-files and later read from for complex processing. I guess I still have to open the display file, so is it possible to do that?
Yes. You don't have to allocate a display to open a display file in batch. You *do* have to avoid any operations that result in writing a record format to the screen. I have done this with package software where I wanted to be able to apply updates easily, making as small a footprint in their code as I could. So I just surrounded the WRITE operations with a condition on how it was being run and pulled my data in after the EXFMTs, etc. I recall testing that writing & reading a subfile are ok, as long as you don't write the control record with SFLDSP or SFLDSPCTL on. You gotta watch hear, because the old pgm might have SFLDSPCTL on during the subfile clear operation. I'm 100% in agreement with writing more modular code, but this legacy pgm from a well-known ERP software house wasn't written that way. --Bryan
Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16408
Avatar

--
03 Aug 2006 05:05 PM Accepted Answer
I recall testing that writing & reading a subfile are ok, as long as you don't write the control record with SFLDSP or SFLDSPCTL on. You gotta watch hear, because the old pgm might have SFLDSPCTL on during the subfile clear operation.
That's interesting, as I've tried to do this and have never been able to get it to work! Maybe I'm doing something wrong. Let me whip up a simple test program and try again...
Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16408
Avatar

--
03 Aug 2006 05:43 PM Accepted Answer
Okay, Bryan... I'm trying to implement your suggestion of making a program run in batch as long as it doesn't allocate a device. Whenever I run my program, I get a CPF5070 error. (File TESTSCRN in library MYLIB has no program devices acquired.) Here's the code for my display file (called TESTSCRN):
     H DFTACTGRP(*YES)

     FTESTSCRN  CF   E             WORKSTN SFILE(SFLREC:RRN)
     F                                     INDDS(ScreenInds)
     F                                     USROPN

     D TESTPGM         PR                  extpgm('TESTPGM')
     D   BatchParm                    1A   const
     D TESTPGM         PI
     D   BatchParm                    1A   const

     D ScreenInds      DS
     D   EXIT                         1N   overlay(ScreenInds: 03)
     D   CANCEL                       1N   overlay(ScreenInds: 12)
     D   SFLCLR                       1N   overlay(ScreenInds: 50)
     D   SFLDSP                       1N   overlay(ScreenInds: 51)

     D QCMDEXC         PR                  ExtPgm('QCMDEXC')
     D   cmd                      32702A   const options(*varsize)
     D   len                         15P 5 const

     D Batch           s              1N   inz(*OFF)
     D RRN             S                   like(LastPos)
     D Cmd             s            100A   varying

      /free

         if ( %parms>=1 and BatchParm='Y' );
            Batch = *ON;
         endif;

         // --------------------------------------------------
         //  Make absolutely certain that display file
         //  won't automatically request a device.
         // --------------------------------------------------

         cmd = 'CHGDSPF FILE(TESTSCRN) DEV(*NONE)';
         QCMDEXC(cmd: %len(cmd));


         // --------------------------------------------------
         //  Allocate requester device if interactive
         // --------------------------------------------------

         if ( not Batch );
             cmd = 'OVRDSPF FILE(TESTSCRN) DEV(*REQUESTER)';
             QCMDEXC(cmd: %len(cmd));
         endif;

         open TESTSCRN;


         // --------------------------------------------------
         //  Clear subfile
         // --------------------------------------------------

         SFLDSP = *OFF;  
         SFLCLR = *ON;
         write SFLCTL;
         SFLCLR = *OFF;
         RRN = 0;

         // --------------------------------------------------
         //  Load some data into the subfile
         // --------------------------------------------------

         for RRN = 1 to 50;
            FieldA = 'Line ' + %char(RRN) + ' Field A';
            FieldB = 60 - RRN;
            SFLDSP = *ON;
            write SFLREC;
         endfor;


         // --------------------------------------------------
         //  If interactive, display subfile
         // --------------------------------------------------

         if (LastPos>1);
            NewPos = LastPos;
         else;
            NewPOs = 1;
         endif;

         if (not Batch);
            write footer;
            exfmt sflctl;
         endif;

         // --------------------------------------------------
         //  Clean up & quit
         // --------------------------------------------------

         close *all;
         if ( not Batch );
             cmd = 'DLTOVR FILE(TESTSCRN)';
             QCMDEXC(cmd: %len(cmd));
         endif;

         *inlr = *on;
      /end-free
The CPF5070 error occurs when I try to write the control record to clear the subfile. If you look at the DDS, you'll see that the SFLDSPCTL should be off, and the SFLDSP should be off when the subfile is cleared, yet it still crashes. So then I tried changing to code to omit the clearly of the subfile altogether by adding an IF statement around the SFLCLR code like this:

     if (not Batch);
         SFLDSP = *OFF;  
         SFLCLR = *ON;
         write SFLCTL;
         SFLCLR = *OFF;
         RRN = 0;
     endif;
After making that change, it still crashes -- but now it crashes on the line that says "WRITE SFLREC". Now I realize that if I completely remove all read/write/exfmt to the display file, my program won't crash in batch -- but what good is that? If I can't use the subfile in batch, I may as well leave the file closed, since I'm going to have to replace all of my subfile logic with a MODS or array anyway, and it really doesn't buy me anything to open the display file with DEV(*NONE). So, was I correct yesterday when I said you couldn't do this? Or, am I doing something wrong in my code? Since a well-known ERP software has it working, it must be my code, but I have no clue what I can do differently.
Tommy Holden
Senior Member
Senior Member
Posts:2833
Avatar

--
03 Aug 2006 05:51 PM Accepted Answer
but what if you didn't use the SFLCLR but looped through the subfile & cleared the data???
Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16408
Avatar

--
03 Aug 2006 06:34 PM Accepted Answer
but what if you didn't use the SFLCLR but looped through the subfile & cleared the data???
I tried omitting the SFLCLR altogether, and it didn't matter.
Bryan Leaman
Veteran Member
Veteran Member
Posts:1745
Avatar

--
03 Aug 2006 06:53 PM Accepted Answer
Scott, I apparently didn't make myself clear. A "well-known" ERP developer wrote a crappy interactive program. I wanted to use it in batch for transaction processing and was able to make it work (though I'm no longer with that company and cannot review all the code changes I made). :( I *thought* I had tested the ability to write to a subfile in batch once and had it working, but I don't recall the specifics. I'm still convinced I had that running at one point, but at what OS level, I cannot say. If I can find my old notes, I'll post them here. --Bryan
Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16408
Avatar

--
03 Aug 2006 07:49 PM Accepted Answer
Bryan, I understand that it was your modification, not the original ERP software, that made it able to run in batch. Since you were the programmer, I was hoping you'd be able to tell me what I'm doing wrong. Though, maybe you're misremembering, and it wasn't actually a subfile.
Bryan Leaman
Veteran Member
Veteran Member
Posts:1745
Avatar

--
03 Aug 2006 08:04 PM Accepted Answer
I am probably mis-remembering. For the ERP mod I definitely never opened the display and never wrote to the record formats. The other was probably a figment of my imagination. It's tough getting old. ;) --Bryan
Atom
New Member
New Member
Posts:6

--
03 Aug 2006 08:08 PM Accepted Answer
The hurdles right now are: 1) How do I find the first available QPADEV*? 2) How do I programmatically change the DEVD to “SIGNON DISPLAY”? I need to do these in order to support multiple simultaneous jobs. Any ideas? Thanks.
Bryan Leaman
Veteran Member
Veteran Member
Posts:1745
Avatar

--
03 Aug 2006 08:42 PM Accepted Answer
I would strongly recommend you not try to continue down that path. How about creating work files in QTEMP for your subfiles and conditioning the writes & chains to the subfiles to use your work file record formats instead? e.g.

C                              IF        BATCH=*ON
C                              WRITE WRKF1
C                              ELSE
C                              WRITE SFL1
C                              ENDIF
...
C                              IF        BATCH=*ON
C                              SETLL  WRKF1
C                              READ   WRKF1                      31
C                              ELSE
C                              READC SFL1                          31
C                              ENDIF
C             *IN31       DOWEQ*OFF
...
C                              IF        BATCH=*ON
C                              READ   WRKF1                      31
C                              ELSE
C                              READC SFL1                          31
C                              ENDIF
C                              ENDDO
--Bryan
Atom
New Member
New Member
Posts:6

--
03 Aug 2006 09:19 PM Accepted Answer
I would strongly recommend you not try to continue down that path. How about creating work files in QTEMP for your subfiles and conditioning the writes & chains to the subfiles to use your work file record formats instead?
I have seen similar codes as you suggested from where I work. I wanted to do something simpler than that, but I think eventually I would go the same route if time is up. Thanks.
Bryan Leaman
Veteran Member
Veteran Member
Posts:1745
Avatar

--
03 Aug 2006 09:28 PM Accepted Answer
Finding an available device name that isn't in use, acquiring it, and hoping nobody turns it off while your running doesn't seem too simple either. I don't believe you can't change the device to "Signon display." It has to be there. --Bryan
Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16408
Avatar

--
03 Aug 2006 11:50 PM Accepted Answer
Well... you could use the Virtual Terminal APIs... but... I wouldn't. It'd be easy to create a temporary file in QTEMP or a MODS in the program to replace the subfile when you're running in batch. Much easier than getting the virtual terminal APIs to do what you need to do.
gamesmd
New Member
New Member

--
06 Aug 2006 01:21 PM Accepted Answer
a good site www.gamesmd.com. offering cheap powerleveling of wow
You are not authorized to post a reply.
Page 1 of 212 > >>


Acceptable Use Policy