How to Print to USB Printer under Win 7 using VS 2015

I am unable to print direct to usb printer under windows 7 using MF VS 2015. I spent considerable time researching how to do this. I am very familiar with Liant's RM Cobol printing facilities. I tried setting the COBCONFIG.cfg  via Gael's steps but the properties for the project under the application tab does not have a Environment button... I have tried Chris's suggestions also... I keep getting the error LPT1 not found in VS 2015 during project execution... Any definitive help would be appreciated as I am not familiar with MF VS 2015 or any other visual development environment. I have spent most of my life writing in pure legacy environments. I thank all for their help !

The code is simple

select lne assign to printer

         organization is line sequential.

fd lne

   label records are omitted.

01  lnerec   pic x(132).

open output lne.

move "test" to lnerec.

write lnerec.

close lne.

  • Having continued to research this problem I ran across  net xpress sample in the docs that helped resolve this issue... it is quite different from traditional cobol programming as there is no Select, FD, Open, Close, or Write Statements... Everything is handled thru call statements... You must supply your own PCL codes as well... But It works... The zip file in the docs is ""   There is most likely much more to be learned about printing now a days as compared to the past

  • Hi Allen,

    Yes you can handle everything through PC_PRINTER calls if that is what you are referring to but you should still be able to redirect the printer the way that you were trying to do.

    I think that the problem that you reported in not having an Environment tab available in your properties is because you have created a managed code project instead of a native project. The Environment tab and COBCONFIG settings apply to a native project only.

    In a managed .NET project the run-time tunables such as set printer_redirection=true are set directly in an app.config file. Please see the documentation here.

    You can also add an application.config file to a native project and set this tunable by double clicking on the application.config in the project and using the Runtime Configuration tab. There is a setting under File Handling called Redirect Assign TO PRINTER to Windows Spooler. If you set this to Yes then you can use the method that you used before as well.

    My question to you is, was using a managed .NET project intentional or should you perhaps be using a native project instead? A managed project generates .NET assemblies from your code and a native project generates native .EXE/DLL files for Windows.

  • Chris....

    Thanks for your answer.... I chose “managed” as it was what Fano and I used in trying to get my initial VS 2015 issues resolved... The coding I have done thus far was exploratory in nature and serving as a learning tool since this is my first true venture into the 21st century of visual coding. Based on your response I now learn (good thing), that I should be choosing “native” as the production applications I will be writing will be deployed to everyday windows platforms... Additionally I chose to include all file i-o logic as well as screen handling in “form1.cbl” as traditionally I would have handled it that way in my past.... Is there anything wrong with this “old” approach... It seems to be the only way that I can get my head around the visual coding environment as I seem to get lost breaking apart the traditional coding logic into a bunch of separate called sub routines... Advice is always gratefully received !



  • Since you mention that you are using "form1.cbl" this would indicate that you ARE using .NET managed code to create a Windows Forms GUI application. This is not available in a native project so a managed project is what you should be using.

    I can understand that using these .NET classes and OO COBOL in general can be quite a new experience for a traditional procedural COBOL programmer. It is a new way of thinking.

    Although you can use these Form.cbl programs to contain all of your COBOL logic including file handling I would highly recommend that you do not do this. It is much better to separate the UI layer of an application from the business layer containing your processing code and data file handling. This is especially true in an event driven application like a Windows Form. The form1.cbl should really contain only UI code and then it should either CALL procedural programs compiled as managed code or INVOKE methods in additional classes that handle the program logic other than the UI.

    This separation will become important especially when you go into maintenance mode or perhaps you would like to replace the Windows forms with another UI like WPF or convert to a web application using ASP.NET. Then you could keep your existing business logic and just replace the front end.