Good morning, Mr. @Ken Schwartz.

Please, test the "prndemox.cbl" sample program that's available under your installation.

It will show you how to use "WIN$PRINTER" to select the printers of your machine.

Looking forward for your feedback.

You must use WIN$PRINTER.

Claudio has already answered your original question.   But the PDF infrastructure has other options, and I figured I should present them, just in case any are useful.  Also, I just found out that the sample file is only available with the windows compiler, not the linux compiler.  So if you only use thin client you wouldn't have it.  I expect you have it, but I'm uploading it here, just in case.  (had to use .txt as the extension instead of .cbl)

So, if you use WIN$PRINTER to control your printer output, you are good to go to do exactly what you asked.  Or you could use the "-P PDF <filename>" option to control the filename programmatically, instead of letting the user choose.  Which to use depends on the use case.

If you use printer control codes, they won't work with the print to pdf.

If you have an option to generate output for a postscript printer, you can install ghostscript and use it to convert the postscript to pdf.  I have no idea what would happen if you sent that to the "microsoft print to pdf", but my guess is it wouldn't work.

I use postscript commands and ghostscript to create PDF files, but Inside acucobol you also have some options I've never tried:

• -P PDF <filename>
  • This sends output to <filename> creating a pdf file.  Essentially the same as using microsoft print to pdf, but you have control over the name.
  • You control formatting using WIN$PRINTER commands, and the PDF_* environment variables
    • The PDF_* variables control font, margin and page size.
    • The C$PDF can be used (see below), but there are a couple options which conflict - see the documentation.
• C$PDF function can be used generate pdf files. 
  • LOTS of options.  A scary amount.  Enjoy the control!
• -P PDF <filename> AND C$PDF
  • From the manual: 

    It is possible to use an implementation that uses both the PDF printing techniques (-P PDF) and C$PDF. You can call C$PDF with the name of an open file (see the CALL Statement, General Rule 6), as long as that file is using the PDF interface (-P PDF). There are some restrictions, which will cause the runtime to halt, such as creating new objects (FONT, PAGE, OUTLINE, etc...). Care must be taken to ensure that you do not modify the page in a way that causes the PDF interface to lose the current position.

Hello Ken,

Robert already mentioned C$PDF.

I myself did a small project with C$PDF in 2019 and got it to work. I think there are also examples with source that you could use.

Don't know on those available on MicroFocus website. Perhaps Claudio knows.

I myself created a routine for use in other projects, added R-PDF.cbl.

Thank you for your responses.  I am somewhat familiar with WIN$PRINTER.  To be more specific, are there special considerations to make use of Microsoft Print to PDF in terms of the file name?  We want to use it as a cloud printing solution.  Thanks all.

Use device "-Q \\\\Microsoft print to PDF", if you want the user to specify the filename.  You can pre-specify options to the print job, by adding options eg) "...PDF;COPIES=2;DUPLEX=YES;" but filename isn't one of them.

Use device "-P PDF myfilename.pdf" if you want to create "myfilename.pdf" file.  ie) predetermine the name.

For the -Q option, you might have to check the names in WIN$PRINTER via the WINPRINT-SET-PRINTER function first.

Again, for me this is all theory, but these ought to work, since -Q asks for a spoolername and "Microsoft print to PDF" is one of the spoolers.