topic Re: WRITE statement buffer issue with SUBMIT in Application Development and Automation Discussions

WRITE statement buffer issue with SUBMIT

Former Member — Tue, 29 Oct 2013 10:19:22 GMT

I'm submitting 2 programs from my new main program to save development time. Within all 3 programs a WRITE statement is performed to a printer. The problem is that these WRITE statements are separated on OS level into multiple spools. This will cause a problem if someone else prints at the exact same time as now the prints are 'merged'. Is it possible to pause the BUFFER while submitting the 2 sub-programs and then only release the BUFFER once the programs return to the main program. Or is it possible to 'open' BUFFER and 'close' BUFFER similar to Smartforms 'open' SPOOL and 'close' SPOOL? If not, I'll just have to combine the code of the 3 programs into 1 to force a single BUFFER/SPOOL.

Thanks, Adrian

Re: WRITE statement buffer issue with SUBMIT

former_member201275 — Tue, 29 Oct 2013 10:36:27 GMT

Possibly you could look into Submit statement with 'exporting list to memory'?

Then use function modules LIST_FROM_MEMORY, WRITE_LIST to output?

Re: WRITE statement buffer issue with SUBMIT

nabheetscn — Tue, 29 Oct 2013 10:40:24 GMT

Hi adrian

How is this WRITE statement related to printer i did not get you. Can you please explain the issue again? You are submitting these two progrms from your report and reading the data back from spool?

Nabheet

Re: WRITE statement buffer issue with SUBMIT

Former Member — Tue, 29 Oct 2013 11:53:21 GMT

Program A calls Program B which calls Program C.

Program A Prints certain group of labels and Program C prints certain group of labels.

The labels are printed with a WRITE statement. Not SAPScript. Not SmartForms.

The WRITE statements are based on comms with very old label printers (18 years).

So, program A generates a separate spool from program B.

If someone happens to print at the same time, their spool could be in between program A spool and program B spool at OS level.

I think the easiest may be to unfortunately just merge the 3 programs into 1 to avoid this possible negative testing scenario.

Re: WRITE statement buffer issue with SUBMIT

nabheetscn — Tue, 29 Oct 2013 12:00:31 GMT

Hi Adrian

What i believe its not going to be an issue as they will be in different session and in different context. Consider a scenario multiple people are printing same thing will it interfere i dont think so.

You program execution has its own area and other person executing it has its own.

I dont see any issue..Were you able to create this scenario?

Reagrds

NAbheet

Re: WRITE statement buffer issue with SUBMIT

Former Member — Tue, 29 Oct 2013 12:07:33 GMT

Hi Adrian,

Before the write statement, when you are setting the print parameters, using FM GET_PRINT_PARAMETERS, set parameter immediately = ' '.

This will prevent any of the write statements from being printed immediately.

Then after completing the third program, print the spool requests together using FM RSPO_RPRINT_SPOOLREQ or FM RSPO_OUTPUT_SPOOL_REQUEST or directly from SP01.

Re: WRITE statement buffer issue with SUBMIT

Former Member — Tue, 29 Oct 2013 12:22:19 GMT

That's a very interesting approach and idea. Thanks.

Re: WRITE statement buffer issue with SUBMIT

Former Member — Wed, 30 Oct 2013 09:13:50 GMT

Just for the record, I merged the programs to eliminate the multiple spools at OS level, but it doesn't change. There are still multiple spools. I analyzed the code further and notice that the NEW-PAGE PRINT OFF is used for every category of the printing e.g. 1)Header 2)Station Labels 3)Picking Labels and 4)Trailer. This is also exactly the number of spools I have - 4. So it looks like I can combine the 4 spools into 1 if I reduce the number of NEW-PAGE PRINT ON and NEW-PAGE PRINT OFF to only occur once for the entire group of labels.

Best regards,

Adrian

Re: WRITE statement buffer issue with SUBMIT

Former Member — Wed, 30 Oct 2013 09:19:12 GMT

That was it. Following is the documentation from SAP for PRINT ON - it does create a new spool request and that's the cause of my problem:

The addition PRINT ON creates a new print list level. The first output statement after NEW-PAGE PRINT ON opens a new spool request and writes to a print list in the SAP spool system. The number of the spool request is passed to sy-spono by the first output statement. While it is being created, the print list is sent page by page to the SAP spool system.