X"91" call outs do not seem to work in managed code under visual studio

Dominique Sacre
Author
Rocketeer
Forum|Forum|13 years ago
May 8, 2012

[Migrated content. Thread originally posted on 08 May 2012]

Have a problem with x"91" call outs in managed code.

Code reads as...

01 command-lin-string pic x(80) value "dir/w".

01 RESULT PIC X COMP-X.
01 FUNC PIC X COMP-X VALUE 35.
01 COMMAND-LIN.
03 COMMAND-LIN-LENGTH PIC X COMP-X VALUE 0.
:
:
DISPLAY COMMAND-LIN-STRING UPON COMMAND-LINE.
CALL x"91" USING RESULT, FUNC, COMMAND-LIN.
IF RESULT = 0
MOVE "01" to lnk-error-status
END-IF.

No DOS box appears showing a directory listing (as it does in UNMANAGED code) but RESULT comes back as 0!

Managed code as defined by Application (program) output as Class library under .Net Framework 4.0

Apparently x"91" call outs don't work in managed code.

Must write as...

Working-Storage Section.
01 command-linex pic x(256) value spaces.
01 command-line-len pic x(4) comp-5.
01 run-unit-id pic x(8) comp-5.
01 stack-size pic x(4) comp-5.
01 flags pic x(4) comp-5.
01 status-codex pic x(2) comp-5.

Procedure Division.

* DISPLAY COMMAND-LIN-STRING UPON COMMAND-LINE.
* CALL x"91" USING RESULT, FUNC, COMMAND-LIN.

String "wzzip -yp " delimited by size
Backrest-FileName delimited by size
" dip*.*" delimited by size
into Command-Linex.

move length of Command-Linex to command-line-len.
move 5 to flags

call "CBL_EXEC_RUN_UNIT" using command-linex
by value command-line-len
by reference run-unit-id
by value stack-size
by value flags
returning status-codex.

BF200.
IF STATUS-CODEX = 0
* IF RESULT = 0
MOVE "01" to lnk-error-status

One for the knowledge base methinks!!

Like

+2

Chris Glazier
Moderator
Forum|Forum|13 years ago
May 9, 2012

[Migrated content. Thread originally posted on 08 May 2012]

Have a problem with x"91" call outs in managed code.

Code reads as...

01 command-lin-string pic x(80) value "dir/w".

01 RESULT PIC X COMP-X.
01 FUNC PIC X COMP-X VALUE 35.
01 COMMAND-LIN.
03 COMMAND-LIN-LENGTH PIC X COMP-X VALUE 0.
:
:
DISPLAY COMMAND-LIN-STRING UPON COMMAND-LINE.
CALL x"91" USING RESULT, FUNC, COMMAND-LIN.
IF RESULT = 0
MOVE "01" to lnk-error-status
END-IF.

No DOS box appears showing a directory listing (as it does in UNMANAGED code) but RESULT comes back as 0!

Managed code as defined by Application (program) output as Class library under .Net Framework 4.0

The X"91" function 35 should work correctly in a managed code console application.

I believe that you are trying to call it from a Windows Forms application and no console window exists for it to display to.

The only reason it works with CBL_EXEC_RUN_UNIT is that you are setting the flag bit to force it to create a new console for the new process.

This flag is not available with X"91" function 35.

Like

D

Dominique Sacre
Author
Rocketeer
Forum|Forum|13 years ago
May 9, 2012

[Migrated content. Thread originally posted on 08 May 2012]

Have a problem with x"91" call outs in managed code.

Code reads as...

01 command-lin-string pic x(80) value "dir/w".

01 RESULT PIC X COMP-X.
01 FUNC PIC X COMP-X VALUE 35.
01 COMMAND-LIN.
03 COMMAND-LIN-LENGTH PIC X COMP-X VALUE 0.
:
:
DISPLAY COMMAND-LIN-STRING UPON COMMAND-LINE.
CALL x"91" USING RESULT, FUNC, COMMAND-LIN.
IF RESULT = 0
MOVE "01" to lnk-error-status
END-IF.

No DOS box appears showing a directory listing (as it does in UNMANAGED code) but RESULT comes back as 0!

Managed code as defined by Application (program) output as Class library under .Net Framework 4.0

Chris Glazier originally wrote:

The X"91" function 35 should work correctly in a managed code console application.

I believe that you are trying to call it from a Windows Forms application and no console window exists for it to display to.

The only reason it works with CBL_EXEC_RUN_UNIT is that you are setting the flag bit to force it to create a new console for the new process.

This flag is not available with X"91" function 35.

We were attempting to take legacy code into a .NET environment with Windows forms replacing GUI Dialog screens. The form allowed for a backup of data files to be carried out which, for the 'old' code meant a call out to a batch file that would then call winzip and perform a 'dos box' operation.

As you quite rightly say the x'91' call in managed code does not allow for this process to operate but thanks to the boys at Microfocus a solution was found.

In converting our 'legacy' code into the new world of .NET there are sure to be a number of things that we, ourselves, come across that won't quite work the way we thought they might so I'll continue to post up issues we get and hopefully they'll become of use to others going down the same path over time as they get solved.

Like

D

Dominique Sacre
Author
Rocketeer
Forum|Forum|13 years ago
September 25, 2012

[Migrated content. Thread originally posted on 08 May 2012]

Have a problem with x"91" call outs in managed code.

Code reads as...

01 command-lin-string pic x(80) value "dir/w".

01 RESULT PIC X COMP-X.
01 FUNC PIC X COMP-X VALUE 35.
01 COMMAND-LIN.
03 COMMAND-LIN-LENGTH PIC X COMP-X VALUE 0.
:
:
DISPLAY COMMAND-LIN-STRING UPON COMMAND-LINE.
CALL x"91" USING RESULT, FUNC, COMMAND-LIN.
IF RESULT = 0
MOVE "01" to lnk-error-status
END-IF.

No DOS box appears showing a directory listing (as it does in UNMANAGED code) but RESULT comes back as 0!

Managed code as defined by Application (program) output as Class library under .Net Framework 4.0

Do the other call by number routines migrate to Visual COBOL as well? We are specifically interested in x’A7’ function 17, x’E5’, x’AF’ and B0’ function 0.

Like

+2

Chris Glazier
Moderator
Forum|Forum|13 years ago
September 26, 2012

[Migrated content. Thread originally posted on 08 May 2012]

Have a problem with x"91" call outs in managed code.

Code reads as...

01 command-lin-string pic x(80) value "dir/w".

01 RESULT PIC X COMP-X.
01 FUNC PIC X COMP-X VALUE 35.
01 COMMAND-LIN.
03 COMMAND-LIN-LENGTH PIC X COMP-X VALUE 0.
:
:
DISPLAY COMMAND-LIN-STRING UPON COMMAND-LINE.
CALL x"91" USING RESULT, FUNC, COMMAND-LIN.
IF RESULT = 0
MOVE "01" to lnk-error-status
END-IF.

No DOS box appears showing a directory listing (as it does in UNMANAGED code) but RESULT comes back as 0!

Managed code as defined by Application (program) output as Class library under .Net Framework 4.0

Over the years it has been our policy to try to replace these call-by-number rotuines with equivalent call-by-name routines where possible.

We understand that some customers (and indeed our own software) use various call-by-number routines, so over time and when needed some of these calls have been implemented to help bridge the gap between native and managed code. Some of them have been implemented because the MF ACCEPT/DISPLAY module (ADIS) required them under-the-covers.

So to answer your question, some of these routines have been implemented in managed .NET code but not all of them are available and some are only partially implemented.

Specifically for the ones that you mention in your post:

x”a7” fn 17 (set cursor shape) is implemented (used by our ADIS support)
alternatively you can use Console::Shape (which is what the runtime does)
x”af” is partially implemented (used by our ADIS support)
x”b0” fn 0 (setup function key table) is implemented (used by our ADIS support)
x'e5' (sound alarm) is implemented (used by our ADIS support)

All of these functions are only available in managed console applications (not gui) and it is unknown if they are 100% compatible, as the main purpose of the routines is to support ADIS itself in its pursuit of implementing the accept/display syntax.

If you have a requirement for a specific routine and it does not appear to function properly, then please let us know about it and we will do our best to provide a workaround, if possible.

Thanks.