DOS to Windows conversion question

[SteveMillman]

Hi,

I am a long time COBOL programmer, primarily on the IBM mainframe. Years ago I got into Microsoft COBOL (which towards the end was manufactured by Micro Focus) and developed many programs on the PC using it.

My programs created print files which I printed using
DOS' print command...

Now I want to make these programs function on Windows and I know little of the Windows API or what to do.

I have two major hurdles to overcome...

1. How do I make use of the Windows Print Manager so that
reports can print "normally" on windows.
a. How can I accomodate the fact the some reports are
"compressed" 255 character lines..
b. How can I print on an ink jet or laser printer
instead of a dot matrix (which I preset
either manually or with control strings in the
program.).
2. How do I replace the DOS batch files I used prior as a
menu.. so that my system had function keys that were
pressed to navigate? Would that have to be a
program.. my system has 100 programs.. some of which
I run in a particular order.

I would appreciate any help from someone who is familiar with the WINdows API and Windows environment and knows what
an old DOS/Mainframer like me is going through..

Thank you,

Steve Millman

 

[Crox]

Hi,

You can still use your batches if you like.
You can still use the LPT1 port to print or in network environments capture LPT1.
You can still use control strings to set the laser- or inktjet.

If your want to use API call's, you can read the book 'programming windows' from Charles Petzold.

If you use a newer COBOL compiler it is easier to communicate with windows.

It can be easy to generate your report in HTML and use the start command to activate your report. The user can print the report in the windows-way.

Some reports are easy to generate in CSV format which can be handled by Excel. Also easy to create and Excel does the rest of the work.

The start statement can be the big help you need.

I hope this is helpful.

Regards,

Crox

 

[SteveMillman]

Thanks Crox.

I had noticed your name on the forums prior. I appreciate your help.

What is the start command? Regarding Batch Files, could DOS batch files really be used in Full Windows or do I have
to get or create a Windows equivalent. My current ones run DOS COBOL executables via a function key.

I will have to investigate the "Start" command. I am totally unfamiliar with it.

Thanks for the tip on the Windows book.. I will look into that as well.

Did you make this transition yourself, from DOS to Windows
COBOL?

Although I realize it might be easier to rewrite some of the applications, I know little of the actual Windows/COBOL programming.

I believe my old compiler will still work okay under the latest Windows.. I just never used any of its features.

Microsoft COBOL 5.0 has provisions for coding COBOL under
Windows 3.1 and Windows 95.

Steve

 

[SteveMillman]

Thanks Crox.

I had noticed your name on the forums prior. I appreciate your help.

What is the start command? Regarding Batch Files, could DOS batch files really be used in Full Windows or do I have
to get or create a Windows equivalent. My current ones run DOS COBOL executables via a function key.

I will have to investigate the "Start" command. I am totally unfamiliar with it.

Thanks for the tip on the Windows book.. I will look into
that as well.

Did you make this transition yourself, from DOS to Windows
COBOL?

Although I realize it might be easier to rewrite some of the applications, I know little of the actual Windows/COBOL programming.

I believe my old compiler will still work okay under the latest Windows.. I just never used any of its features.

Microsoft COBOL 5.0 has provisions for coding COBOL under
Windows 3.1 and Windows 95.

Steve

 

[Crox]

Hi,

If you use any windows, you can give the command:

START /?

on the DOS prompt. I guess you have the possibility with your compiler to give a dos command.

Hereafter I put the output of START /? from Windows NT.

I have several applications running under windows, even one using some API call's but I have not a good feeling about it. Talking with a webbrowser is more convenient. API call's give a lot of work.

Regards,

Crox

output of start /?

Starts a separate window to run a specified program or command.

START ["title"] [/Dpath] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
      [/LOW | /NORMAL | /HIGH | /REALTIME] [/WAIT] [/B] [command/program] [parameters]

    "title"     Title to display in  window title bar.
    path        Starting directory
    I           The new environment will be the original environment passed
                to the cmd.exe and not the current environment.
    MIN         Start window minimized
    MAX         Start window maximized
    SEPARATE    Start 16-bit Windows program in separate memory space
    SHARED      Start 16-bit Windows program in shared memory space
    LOW         Start application in the IDLE priority class
    NORMAL      Start application in the NORMAL priority class
    HIGH        Start application in the HIGH priority class
    REALTIME    Start application in the REALTIME priority class
    WAIT        Start application and wait for it to terminate
    B           Start application without creating a new window. The
                application has ^C handling ignored. Unless the application
                enables ^C processing, ^Break is the only way to interrupt the
                application
    command/program
                If it is an internal cmd command or a batch file then
                the command processor is run with the /K switch to cmd.exe.
                This means that the window will remain after the command
                has been run.

                If it is not an internal cmd command or batch file then
                it is a program and will run as either a windowed application
                or a console application.

    parameters  These are the parameters passed to the command/program


If Command Extensions are enabled, external command invocation
through the command line or the START command changes as follows:

non-executable files may be invoked through their file association just
    by typing the name of the file as a command.  (e.g.  WORD.DOC would
    launch the application associated with the .DOC file extension).
    See the ASSOC and FTYPE commands for how to create these
    associations from within a command script.

When executing an application that is a 32-bit GUI application, CMD.EXE
    does not wait for the application to terminate before returning to
    the command prompt.  This new behavior does NOT occur if executing
    within a command script.

When executing a command line whose first token is CMD without an
    extension or path qualifier, then replaces CMD with the value of the
    COMSPEC variable, thus avoiding picking up random versions of
    CMD.EXE when you least expect them.

When executing a command line whose first token does NOT contain an
    extension, then CMD.EXE uses the value of the PATHEXT
    environment variable to determine which extensions to look for
    and in what order.  The default value for the PATHEXT variable
    is:

        .COM;.EXE;.BAT;.CMD

    Notice the syntax is the same as the PATH variable, with
    semicolons separating the different elements.

When executing a command, if there is no match on any extension, then
looks to see if the name, without any extension, matches a directory name
and if it does, the START command launches the Explorer on that path.
If done from the command line, it is the equivalent to doing a CD /D
to that path.

 

[Thane]

Have you updated your compiler, or are you still using the MicroFocus (Microsoft) compiler?

 

[Thane]

Please note - there is significant syntax difference between START on NT/2000 and START on Windows 9x/ME.

 

[SteveMillman]

Thanks Crox and Thane. Still have not had time to do anything about checking out the start command in the context of this migration from DOS to Windows.