Error with CSV Format in ReportWriter using Prelude Scheduler

[precisonline]

I just assisted a Prelude site with a weird error message that was popping up in the scheduler when running a report to CSV format.  When you run a report with the CSV option (for emailing), Prelude sets up the /RD to output to the DIF format.  This causes a CSV item to be written to DEVWORK which they then pick up and email.  When there's stuff to be output, this works well.  When there's nothing selected, however, there's a problem.

At the end of the DIF output, the SB+ ReportWriter calls a subroutine UT.DIFF.FILE for some reason, likely to finalize the DIF output.  Problem is, if nothing was selected a message comes up that states:

(1) NO DETAIL LINES CREATED

...and when running in the scheduler, the input on the error message causes the scheduler job to abort.  We traced this message to that UT.DIFF.FILE routine called directly from the SB+ ReportWriter, via this stack trace:

                          (1) NO DETAIL LINES CREATED***DEBUGGER called at line 146 of program C:\IBM\ud71\sys\CTLG\X\_SB_SB.INP.EDIT-Effects F10-Action
!?
[1]     C:\IBM\ud71\sys\CTLG\X\_SB_SB.SYSMENU: 179
[2]     C:\IBM\ud71\sys\CTLG\X\_SB_SB.MENU.SELECT: 262
[3]     C:\IBM\ud71\sys\CTLG\X\_SB_SB.MENU.S: 348
[4]     C:\IBM\ud71\sys\CTLG\X\_SB_SB.PROCESS: 225
[5]     C:\IBM\ud71\sys\CTLG\X\_SB_SB.EVAL.EXP: 409
[6]     C:\IBM\ud71\sys\CTLG\X\_SB_SB.PROCESS: 141
[7]     C:\IBM\ud71\sys\CTLG\X\_SB_SH.TCL: 448
[8]     C:\IBM\ud71\sys\CTLG\X\_SB_SB.PROCESS: 141
[9]     C:\IBM\ud71\sys\CTLG\X\_SB_SB.RD: 784
[10]    C:\IBM\ud71\sys\CTLG\X\_SB_SB.RD.FUNCT: 436
[11]    C:\IBM\ud71\sys\CTLG\X\_SB_SB.PUT.IN.MENU: 325
[12]    C:\IBM\ud71\sys\CTLG\X\_SB_SB.PROCESS: 233
[13]    C:\IBM\ud71\sys\CTLG\X\_SB_SB.RD.RUN: 1837
[14]    C:\IBM\ud71\sys\CTLG\X\_SB_UT.DIFF.FILE: 235
[15]    C:\IBM\ud71\sys\CTLG\X\_SB_SB.DISP: 202
[16]    C:\IBM\ud71\sys\CTLG\X\_SB_SB.INP.EDIT: 146
!


As it's called right from inside the /RD itself, there's no place to put any hook points to check W12 = 'JS' like the rest of the Prelude code, so there appears to be limited options for suppressing this behavior.

My recommendation to this client was this: For any jobs that run in the scheduler and need to export to the CSV format, they'll need to front the /RD with some kind of a process that selects the records and only calls the /RD if there are records to be processed.  We have the RUN.GRIM.RPT process and a number of other helper processes available in my Standard Processes document that can help, but... it's still going to be a lot of work.  Alternatively, they could use the Download Definition tool to create their CSV files instead of going through the /RD - thus doing an end-around on this problem - but it's still going to be a bit of effort to recode their CSV exports to the Download Definition format.

But my point in writing this is more of a query.  In the gazillion years I've been doing SB+ and the half gazillion that we've been supporting Prelude, I've never seen this message before.  Does that mean that the CSV format in the /RD is not being used much, or that people have been coding around this issue for years, or even that nobody's noticed until now?

[Tom Pellitieri]

I suspect that few people schedule reports that export to CSV format, and if they do, they may be checking for active lists first.

Generally, the CSV file is downloaded from AIX to a Windows system.  Since the scheduler does not have a direct connection to a Windows system, a scheduled report would require later human interaction to retrieve the file.

We often select and test for data before calling a report.  For Prelude sales orders, it is more efficient to select a date range from the order header file before selecting the corresponding detail lines, so dated sales reports always have a "two level" select.  A test is made after the order header selection, because if nothing was selected, the line item selection would occur on the ENTIRE sales history file. 

Since we have nearly 18 years of sales data on file at this point, avoiding large unindexed selections is very important here.

--Tom