Author Topic: REPORT.CLOSE - One Slot Too Soon??  (Read 13128 times)

Tom Pellitieri

  • Rock Star
  • *****
  • Posts: 224
  • Tom Pellitieri - Toledo, Ohio
REPORT.CLOSE - One Slot Too Soon??
« on: June 30, 2009, 09:14:44 AM »
I recently rewrote the SPAWN.EMAIL routine to use a different pdf creator to send scheduled GRIM reports via e-mail.  The process generally works, but there's a minor glitch.

In the default GRIM Report template for /RD, the REPORT.CLOSE routine is called in the Process After Exec slot.  The help on this slot states that the process is called after PRINTER OFF but before PRINTER.CLOSE. 

E-mailed reports are first written to the _HOLD_ file, and the SPAWN.EMAIL routine cleans up by deleting the file from _HOLD_.  Unfortunately, this occurs before SB+ issues the PRINTER.CLOSE command. 

The upshot of this is that a additional job is added to the _HOLD_ file, consisting of the setup codes for the selected stationary!  Effectively, SB+ notices that it can't find the printer file it was writing, and creates a new one.

I suspect I could try moving the REPORT.CLOSE process to the /PD.R Process After, but that makes the report template less useful.

Any alternative suggestions to prevent these stray jobs from accummulating in the _HOLD_ file??

precisonline

  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #1 on: July 07, 2009, 08:23:34 AM »
This is pretty far-fetched, so let's go in with that in mind...

Being how this is going out through email, might it make sense to setup a printer class and printer specifically for printing to email that doesn't have any setup or reset codes?
-Kevin
Accidents "happen"; success, however, is planned and executed.

Tom Pellitieri

  • Rock Star
  • *****
  • Posts: 224
  • Tom Pellitieri - Toledo, Ohio
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #2 on: July 07, 2009, 12:15:28 PM »
Well.. there is a printer class and printer set up just for this.  Unfortunately, we're using setup codes on the stationary in order to get the PDF converter to use the correct font and page orientation, otherwise it assumes Portrait mode with Courier 10cpi.  Doesn't work too well for 132 column reports...

As a kludge (and yes, it's an extreme kludge!), I'm clearing values 7-9 in PRINT.DEFN<29> after deleting the job from _HOLD_.  This has prevented the stray jobs after the report is e-mailed, but we still get the stray jobs when the report doesn't actually run (i.e., the select returns zero records). 

The problem is that both the report and the scheduler are calling the OUTPUT.REDIRECT routine (which in turn calls SH.PRINT.MANAGER), but only the report calls the REPORT.CLOSE routine (which does the cleanup).

At least I have half the problem solved, albeit with a most inelegant process...

Tom Pellitieri

  • Rock Star
  • *****
  • Posts: 224
  • Tom Pellitieri - Toledo, Ohio
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #3 on: July 31, 2009, 09:17:57 AM »
As I mentioned earlier this month (in this thread), we have problems with stray jobs in the _HOLD_ file due to calls to OUTPUT.REDIRECT from both the scheduler and the actual report when using e-mail as a delivery method.  As a reminder, the e-mail process deletes the job from the print queue, and the report closing wound up adding the setup codes in a new job.  I did a kludge to eliminate the setup codes, but we still have the problem when the report doesn't run at all.  In this case, the _HOLD_ entry is created by the scheduler before the report is called.  Since there's no data, the orphaned entry just has setup codes, and doesn't get deleted.

I'm wondering if this might be related to the way the printer redirection is handled.  OUTPUT.REDIRECT uses calls to SH.PRINT.MANAGER.  In some of my own programs (early UniData conversions, mind you!), I have used EXEC "SETPTR", but that option doesn't apply the SB+ stationery. 

I'm wondering if there's a way to EXEC "CHANGE.PRINTER" rather than calling SH.PRINT.MANAGER to avoid the problem.  Any thoughts?

I guess the real puzzle is why does the call to SH.PRINT.MANAGER effectively open the print job?  Is there perhaps a parameter that can override this until the report actually opens?  Of course, OUTPUT.REDIRECT would have to know whether it was being called from the scheduler or the report before it called SH.PRINT.MANAGER.  Again, any thoughts?

--Tom

precisonline

  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #4 on: July 31, 2009, 10:39:28 AM »
I guess the real puzzle is why does the call to SH.PRINT.MANAGER effectively open the print job?  Is there perhaps a parameter that can override this until the report actually opens?  Of course, OUTPUT.REDIRECT would have to know whether it was being called from the scheduler or the report before it called SH.PRINT.MANAGER.  Again, any thoughts?
SH.PRINT.MANAGER opens the print job to output the setup codes, that's the only reason that makes sense, I would think.

You said "E-mailed reports are first written to the _HOLD_ file, and the SPAWN.EMAIL routine cleans up by deleting the file from _HOLD_.  Unfortunately, this occurs before SB+ issues the PRINTER.CLOSE command. The upshot of this is that a additional job is added to the _HOLD_ file, consisting of the setup codes for the selected stationary!  Effectively, SB+ notices that it can't find the printer file it was writing, and creates a new one."

So you're saying here that at the end of the print job, after the _HOLD_ entry has been removed, SB+ outputs the printer setup string into a new hold file before it releases it?  Just playing devil's advocate, you're certain this is happening at the end of the print job?  If you change SPAWN.EMAIL to not delete the _HOLD_ file this is not a problem?

If you don't want to keep those files hanging around I would think you could issue your own PRINTER CLOSE before deleting the hold entry and then maybe reassign the printer to a /dev/null printer and let the chips fall into the bit bucket.

Possible?
-Kevin
Accidents "happen"; success, however, is planned and executed.

Tom Pellitieri

  • Rock Star
  • *****
  • Posts: 224
  • Tom Pellitieri - Toledo, Ohio
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #5 on: August 03, 2009, 06:34:48 AM »
I'm certain about the timing of events, and it makes sense based on SB+'s own help, as I noted in the first post of this thread.  I'm clearing the PRINT.DEFN fields after deleting the hold entry, and that solves the problem when there's actually a report to e-mail.

At this point, our problem is that the Scheduler Process calls SH.PRINT.MANAGER to redirect the report before the actual report process is called.  Since the report selection has no records, the REPORT.CLOSE process isn't called from the report, and no e-mail is generated, so the _HOLD_ entry isn't deleted.

--Tom

precisonline

  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #6 on: August 03, 2009, 08:02:38 AM »
I feel like somehow I haven't been paying enough attention, and therefore offer my apologies for any misunderstanding.

So... I now understand that there's a report that would normally email but ... in certain situations it might not select any records and when this happens there's no email and the _HOLD_ entry is left intact when really it's just chaff.  Is this correct?

If so, is this one of those situations where the runner paragraph is checking to see if anything was selected and then isn't calling the /PD.R at all?  If the /PD.R is called - even if there's no records selected - I would expect that REPORT.CLOSE would be called.
-Kevin
Accidents "happen"; success, however, is planned and executed.

Tom Pellitieri

  • Rock Star
  • *****
  • Posts: 224
  • Tom Pellitieri - Toledo, Ohio
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #7 on: August 03, 2009, 09:31:58 AM »
Kevin, you are correct - the /PD.P (GRIM-enabled) verifies that there is data to report, and only executes the /PD.R if there is.

Unfortunately, both the Scheduler and the /PD.R call OUTPUT.REDIRECT, but only the /PD.R calls REPORT.CLOSE.  I'm thinking that perhaps the Scheduler should store the stationery over-ride info somewhere and let the the /PD.R make the sole call to OUTPUT.REDIRECT.  Not certain how to convince Prelude to do this, though...

--Tom


precisonline

  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #8 on: August 03, 2009, 09:45:54 AM »
I believe (and that's about all the confidence I can give on this issue) that Prelude has all this logic to not call the /PD.R to avoid printing/emailing/faxing reports that have nothing more than a header.  Problem is, when the printer has already been turned on before this determination is made, well, things can get a little wonky (as you've seen).

Just thinking... what if the /PD.P that made the determination to not run the /PD.R called REPORT.CLOSE instead when there's nothing to output?  I realize such a change might have to be manually applied to a whole bunch of programs but ... theoretically does it have any merit?

You said "Unfortunately, both the Scheduler and the /PD.R call OUTPUT.REDIRECT, but only the /PD.R calls REPORT.CLOSE.  I'm thinking that perhaps the Scheduler should store the stationery over-ride info somewhere and let the the /PD.R make the sole call to OUTPUT.REDIRECT.  Not certain how to convince Prelude to do this, though..."  There are actually a number of complexities to this, mostly due to the way that the scheduler is calling OUTPUT.REDIRECT.  When the scheduler calls OUTPUT.REDIRECT, @RECORD has the scheduler record so OUTPUT.REDIRECT extracts what it needs from that variable and proceeds on its way.  In the /PD.R - at least when that process is called, @RECORD has been cleared already.  So to pull this off the scheduler would have to shuttle the printer, stationery, copies, and hold options into a @PARMS(..) element somewhere and then OUTPUT.REDIRECT would have to pull from that @PARMS(..) element.

Possible?  Absolutely.  But it could be a pretty significant rework to the way that Prelude does printer handling, and as such I don't think the idea would be met with all that much love. 
« Last Edit: August 03, 2009, 09:48:41 AM by precisonline »
-Kevin
Accidents "happen"; success, however, is planned and executed.

Tom Pellitieri

  • Rock Star
  • *****
  • Posts: 224
  • Tom Pellitieri - Toledo, Ohio
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #9 on: August 04, 2009, 12:43:57 PM »
Just thinking... what if the /PD.P that made the determination to not run the /PD.R called REPORT.CLOSE instead when there's nothing to output?

The /PD.P would need to determine if it was called by the scheduler or not, since there would be no reason to call REPORT.CLOSE if the _HOLD_ entry wasn't already active.

Alternative option:  If the /PD.P could detect the open _HOLD_ entry, it could close and delete it if the report doesn't run.  Not sure how to determine that, however.

--Tom

precisonline

  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #10 on: August 04, 2009, 01:01:22 PM »
Well, we know when it's run through the scheduler as @WORK<12,1> = 'JS'.  Would that work?  I think that'd be easier than detecting an open _HOLD_ entry.  I thought maybe SYSTEM(1) might tell if the hold file is open but that's only between PRINTER ON and PRINTER OFF; it doesn't tell us squat between PRINTER OFF and PRINTER CLOSE.
-Kevin
Accidents "happen"; success, however, is planned and executed.

Tom Pellitieri

  • Rock Star
  • *****
  • Posts: 224
  • Tom Pellitieri - Toledo, Ohio
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #11 on: August 04, 2009, 03:09:29 PM »
Hmm... I'm concerned that if I call REPORT.CLOSE with no report I'll wind up sending a bunch of blank e-mails instead of just having a dead item in the _HOLD_ file.

Ideally, I need to delete the _HOLD_ entry from the queue.  It looks like the key is stored in @WORK - I've added a line to capture @WORK and will check tomorrow.

--Tom

Alex Copeland

  • Professional
  • ***
  • Posts: 23
  • Artist's rendering
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #12 on: March 20, 2010, 07:42:39 PM »
Tom,

I realize that this post is almost a year old and that you've probably solved this problem.  We do something similar with our report distribution except that we rarely use the GRI/Prelude method of email distribution.  I've got shell scripts set up as print queues in AIX.  The scripts do stuff like send the report as an email attachment, send as a pdf, build web pages for month end reports, etc.

The benefit of hanging a printer out there on there on the AIX side to do you PDF printing or whatever is that layer of abstraction -- you don't have to rewrite any of Prelude's code, nor do you have to worry about _HOLD_ entries, SB+ calls -- it's just another printer.  Plus you can send anything to it, not just GRI stuff.

Out of curiosity,  how did you end up resolving your issue?

--Alex

Tom Pellitieri

  • Rock Star
  • *****
  • Posts: 224
  • Tom Pellitieri - Toledo, Ohio
Re: REPORT.CLOSE - One Slot Too Soon??
« Reply #13 on: March 22, 2010, 06:19:33 AM »
Alex,

Because of problems with upgrade paths on prior systems, it has been corporate policy to work within the Prelude framework as much as possible since we started with them in 1994.  That means we use /GRIM as much as possible in order to maintain a relatively consistant user interface.

The problem still exists, but I wound up writing a program to clear out the orphaned/blank reports from the _HOLD_ file each morning.  Fortunately, I needed an unusual PCL code in the setup for our PDF conversions.  The program selects _HOLD_ items with Attribute 1 ending with that string, then deletes any item that has only one attribute.  This is scheduled to run in the early AM, so the queue is clean for the day.

--Tom