Hi,
i started my Cobol career as Dev with MF Cobol on Xenix (1988) and got used into the "Screen Section" that for my surprise some years later saw as not available on Mainframe CICS.
My question relates with the real state of the art of having GnuCobol as a target for replatforming z/OS Cobol mainframe applications with some recode (minimum).
I saw already some approaches that take cobol and generate java in cobol style – not something very interesting to have since for a java dev, he expects a java dev style of code as a start.
Approaches like Micro-Focus Mainframe Emulation have issues and off course things like Hercules or even zPDT do not address the required “transformation”.
My purpose is to evaluate what exists today that off course with some “automatic recoding” of z/OS Cobol code, GnuCobol could be used as a valid Production target.
z/OS Cobol code can have many supporting technologies off course like MQ, DB2, IMS, CICS – is there a recipe already built that result from years of experience here?
I have in perspective a position where Application Modernization (Mainframe) is a requirement and off course that very likely I may be returning into my good old Cobol days that have nothing to do with Mainframes.
Sorry if I am posting a question already answered here.
Thank you
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have outlined what has been a mission of mine (using GnuCOBOL for zOS applications) over the course of the last 3 - 4 years. Unfortunately the moderators of this forum have prohibited me from discussing my efforts.
My Windows based solution does not meet the Stallman criteria for "free software" but rather is "free to use" software. Hence the gag order.
Feel free to send me private email. I will gladly respond.
Ralph
wincobol.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nearly. Actually the moderators of this forum would like to praise your efforts and advocate for your solution (if Win32 is the necessary target), if you want to also with "shipping" binaries - after you make your software "free" (as far as I remember the main point was to put your own COBOL sources under a free license.
I'd personally always suggest the same route as GnuCOBOL: "tools" (and scripts to create your binaries) as GPL, libraries (and COBOL programs that are CALLed) under LGPL - but aactually any free license would match. Copyright would still be 100% on your side.
You may want to reconsider this.
Until this possibly happens people can get the binaries only, possibly with a feeling of "no one can update this so this project possibly is not good for putting it as a dependency to important projects", from wincobol.com.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While this question arises from time to time it is perfectly fine to post it this way. GnuCOBOL should be able to compile most sources that run on IBM itself (just ensure to use the matching -std option). For MQ there are "Unix and Windows" binaries - as far as I know those work identical, just ensure to have its libraries in COB_PRELOAD. The same should apply to DB2.
CICS and IMS are a completely different issue, I'd be interested in working solutions there, too. Brian's FAQ does not have an entry for those either.
I know that COBOLworx wanted to work on those, @mheyman do you have any update or otherwise information about using those outside of the mainframe?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding CICS, i wonder if someone got ideas on building a tool that reads a BMS and generates an equivalent "Screen Section" code.
I will need to get time for putting my hands dirty on this but from what i see, GnuCobol is more advanced than my initial "assumption".
Windows is not "the issue" - Linux Rocks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To what purpose ?
A screen section derived from BMS is pretty meaningless without the accompanying "EXEC CICS RECEIVE / EXEC CICS SEND" CICS executive logic and application logic.
Consider the application logic built around the CICS interpretation of the 3270 buffer.
1. Write control characters
2. Attributes
3. Extended attributes
4. FSET
5. Length codes populated
6. etc.
It is a fairly long list of logic related considerations to be accounted for.
I have mapped BMS for CICS emulation. With regards to Linux Rocks - Linux would rock if it implemented the equivalent Windows API for Console Services.
Windows versions of Micro Focus and Fujitsu provide these CBL_ routines for screen creation and manipulation. Theses CBL_ routines are not included in the Linux versions.
CALL "CBL_CREATE_SCR".
CALL 'CBL_WRITE_SCR_CHATTRS' USING
CALL 'CBL_WRITE_SCR_CHARS' USING
CALL 'CBL_SET_CSR_POS' USING
CALL "CBL_SET_CSR_SHAPE" USING
CALL 'CBL_GET_SCR_SIZE' USING
CALL "CBL_SET_SCR_KEYFILE" USING
CALL "CBL_SET_SCR_TERMKEY" USING
CALL "CBL_READ_SCR_KEY" USING KEY-TYPE
All of the above map onto a Windows API(s).
Without Linux support of equivalent console services I think you are bound to the have Linux communicate with the graphics adapter card bios services.
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-04-07
Ralph Linkletter wrote:
Linux would rock if it implemented the equivalent Windows API for Console Services.
In the UN*X world there are no consoles, just (pseudo) terminals.
A completely different animal.
Many applications, such as Win 3270 emulators, are in fact full Win API applications which look like a console.
There is a Win console API, a subset of the full Win API, which is rarely used for real applications.
Using one of the GUI toolkit, such as Gtk or KDE, you can achieve the equivalent functionality.
For example x3270, a GUI application, uses the Xraw toolkit to create a GUI application which looks like 3270 console.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@dilodilo@pat-mccavery Are you able to provide those CBL_ functions as COBOL or C wrappers around curses? It seems most should be doable, possibly needing "something" exposed from libcob, but in any case doable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are some differences between the Micro Focus / Fujitsu syntax as compared to Brian's syntax.
All parameters are passed by reference:
All API calls specify an X Y buffer position
(relative to 0).
See the example CRT-POS below.
The Micro Focus and Fujitsu format are the same.
05 CRT-POS.
10 CRT-POS-ROW PIC 9(04) COMP-4 VALUE 0.
10 CRT-POS-COL PIC 9(04) COMP-4 VALUE 0.
**Micro Focus syntax:**
CALL 'CBL_WRITE_SCR_CHATTRS' USING
BUF-POS
BUF-DATA (BUF-SUB:BUF-LEN)
BUF-ATTR (BUF-SUB:BUF-LEN)
BUF-LEN.
CALL 'CBL_WRITE_SCR_CHARS' USING
BUF-POS
BUF-DATA (BUF-SUB:BUF-LEN)
BUF-LEN.
**Fujitsu syntax:**
A Fujitsu prerequisite call is to CBL_CREATE_SCR.
CALL 'CBL_WRITE_SCR_CHATTRS' USING
CRT-POS
CRT-DATA (CRT-SUB:CRT-LEN)
CRT-ATTR (CRT-SUB:CRT-LEN)
CRT-LEN.
CALL 'CBL_WRITE_SCR_CHARS' USING
CRT-POS
CRT-DATA (CRT-SUB:CRT-LEN)
CRT-LEN.
CALL 'CBL_READ_SCR_CHATTRS' USING
BUF-POS
BUF-DATA
BUF-ATTR
BUF-LEN
**Brian's format:**
call "CBL_WRITE_SCR_CHATTRS" using
by value 0
by reference cbuff
by reference abuff
by value clen
returning chstat
call "CBL_READ_SCR_CHATTRS" using
by value 0
by reference cbuff
by reference abuff
by value clen
returning chstat
Perhaps Brian's code contemplates the entirety of the screen buffer ?
"by value 0" as the first parameter in Brian's call(s) seems to imply some other mechanism is maintaining the cursor position. In the other compilers the X Y coordinate is required.
There are too many differences to use this as a Micro Focus / Fujitsu replacement .
Ralph
Last edit: Ralph Linkletter 2021-04-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I might finish up these extra stock library calls, seeing as I care more now than I did 7 years ago, but I might press for a slightly different set of idioms first.
There is a FSS library in Hercules MVS TSO space by Tommy Sprinkle, also ported to VM/370 CMS. Might try and see if a TPUT/TGET API would be sympatico with GnuCOBOL POSIX.
If there is going to be a path from mainframe screens to PC screens, might as well go all in and provide a framey API that can be used on MVS or CMS or POSIX. :-)
With a little tooth pulling, the tub3270 Linux/390 device driver kernel module might even sneak its way in x86 land, allowing full on virtual 3270 screens.
That same thought process might also lead to a batch processor that leverages ISAM/VSAM features in MVS to share data between frame COBOL and GnuCOBOL without thinking too hard.
The Hercules emulator handles sockets. A DIAGNOSE instruction is exposed to the S/370 that allows MVS access to hosted TCPIP. People are already enjoying MVS with KICKS (a CICS implementation), BRexx and a growing collection of 3270 block display routines. Latency for submitting jobs, extracting from the spool and getting data back to POSIX is blinky fast.
Adding an extra sub opcode to Hercules to also allow frame OS access to GnuCOBOL libcob services is looking like only a few lines of code will be needed.. A COBOL program running in emulated MVS and POSIX at the same time may be coming to a corner near you.
If the S/380 project proceeds as it should, (adding 31bit mode to s/370) there is an ever growing possibility that the GCC in MVS and CMS will be capable enough to actually get GnuCOBOL compiled for use on a frame, without needing any of the USS layer enabled. Not quite yet, but there are strides at improving the 31bit support in the normally 24bit limited public domain cuts of MVS 3.8 and VM/370 r6. Going above the line.
Having too much fun again.
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, there will probably be some entries soon-ish. I've working on a BKNTYM project, Back In Time, GnuCOBOL and the Hercules emulator. Mostly to start a pool of older 1972 ANS COBOL that work with MVS (and VM/370) and modern GnuCOBOL.
MVS 3.8j sports an open source KICKS contribution (a CICS implementation). I've been pondering a thin client on POSIX talking to a KICKS server setup running on an emulated MVS. MVS3.8j is too old for internet, but the Hercules emulator has "extended" the DIAGNOSE instruction to expose host services, including the TCP/IP stack. MVS3.8 feels like it has TCP/IP once you put some Assembly macros to work.
The guts of the BKNTYM plan is using POSIX and Hercules (MVS/VM) together in a solution mix. MVS 3.8j is circa 1985, but most things (source and binary) still work now the way they did, all the way back to the 1970 base of OS/360. Along with VM/370, RSCS, NJE and a few other improvements people have made to turnkey systems for Hercules, you can have entire clusters of Hercules emulated iron nodes running.
There have been some impressive strides made in modernizing the VM/370 hypervisor, lately, (VM/370 Community Edition was released last wee) and work on GCC for MVS and CMS is opening up a lot of potential for a fairly robust explosion of modernization for emulated iron.
There is no DB2 in this mix, but there is VSAM. Even the 1972 ANS COBOL compiler, written to support ISAM and before VSAM existed, can still "fallback" to using VSAM files (without a few features) by simply using a VSAM DD in place of an ISAM DD, i.e. ensuring the AMORG subparameter is set.
Jay Moseley missed having direct VSAM power, so he actually wrote a CALLable layer for both PL/I and COBOL in 360 assembly. I'm experimenting with ISAM COBOL simply using ISAM to VSAM powers inherent in MVS 3.8 core. Seeing as I don't miss any VSAM features having never used them, this does not seem limiting, at all. Jay knows more and felt a stronger need for more direct VSAM control.
It's fun, (and more importantly, very robust), writing some JCL in the comfort of Vim, submitting jobs from Vim via shell scripts to an MVS card reader, with results of the frame job output captured and plopped back into a Vim buffer. Blinky fast.
End game, if BKNTYM works out as it should, will be a playing field of COBOL on POSIX mixed relatively seamlessly with COBOL on MVS. (Old MVS, but so compatible that binaries from 1970 still run when loaded on a system of today). And not just COBOL, all the available compilers. ALGOL, Fortran, PL/1, COBOL, RPG, BASIC, XPL, SNOBOL4, ... (quite a few), and more emerging all the time.
I just ported Dave's FOCAL implementation to VM/370. Dave Pitts wrote the -t and -T listing outputs for GnuCOBOL. And I'm having way too much fun porting libforth, a Forth implementation to VM/370 CMS. An MVS TSO version is next. If these experiments bear fruit, then I'll be attempting getting libcob compiled for CMS and TSO, then cobc, to run GnuCOBOL on MVS and VM (without needing Unix System Services USS on the iron side). That is future work, and depends on learning enough with the first few experiments.
As always, the plan is to leverage GnuCOBOL, but instead of all or nothing rip and replace, to ease porting, is to provide a viable option to run programs on either POSIX or MVS targets interchangeably. Port programs one at a time instead of being faced with the all or nothing scenario.
Have good, make well,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Albeit a 3270 native buffer translation can display a 3270 screen there remains a gazillion lines of code to implement how the 3270 buffer is transformed for CICS, IMS, DM.
You are aware of CICS.
How about IMS DC ? DM (dialog manager)?
The PDF below is depicting a Windows implementation of a dialog manager (DM) panel.
Factually my WINZOS system fulfills the vast majority of zOS application development and testing (with actual JCL and zOS dataset naming convention). The entire user interface is built with ISPF and dialog manager. Even the most commonly used zOS control blocks are provided for and populated during execution.
Micro Focus supports PL/I and previously supported IBM assembler - WINZOS does not.
I do support GnuCOBOL. The GnuCOBOL support would be better if EXTFH was implemented as it was in Micro Focus and Fujitsu.
WINZOS development and programming is 100% COBOL
My 3270 emulation bolts up to CICS, and DM.
The 3270 emulation makes extensive use of the WIN console API's.
The 3270 emulation takes as input BMS, DM, IMS precisely emulating the user interface as if using a real 3270 or the likes of Attachmate.
Checkout the DM definition and the resulting 3270 display from DM panel services.
I am going to release WINZOS as a companion to WINIDE sometime in June.
Sadly I can't implement any of this in Linux / POSIX
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-04-07
@Simon thanks for the mention. COBOLworx, a project within Symas Corporation, has built an IMS/DB prototype (limited HIDAM) accessible from GnuCOBOL as well as other languages with the C ABI. We have shelved it for the moment ... lack of interested customers. I'd be happy to brief you. We also provide binaries for GnuCOBOL and our GnuCOBOL Source-Level debugging tool for gdb (freeware).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
i started my Cobol career as Dev with MF Cobol on Xenix (1988) and got used into the "Screen Section" that for my surprise some years later saw as not available on Mainframe CICS.
My question relates with the real state of the art of having GnuCobol as a target for replatforming z/OS Cobol mainframe applications with some recode (minimum).
I saw already some approaches that take cobol and generate java in cobol style – not something very interesting to have since for a java dev, he expects a java dev style of code as a start.
Approaches like Micro-Focus Mainframe Emulation have issues and off course things like Hercules or even zPDT do not address the required “transformation”.
My purpose is to evaluate what exists today that off course with some “automatic recoding” of z/OS Cobol code, GnuCobol could be used as a valid Production target.
z/OS Cobol code can have many supporting technologies off course like MQ, DB2, IMS, CICS – is there a recipe already built that result from years of experience here?
I have in perspective a position where Application Modernization (Mainframe) is a requirement and off course that very likely I may be returning into my good old Cobol days that have nothing to do with Mainframes.
Sorry if I am posting a question already answered here.
Thank you
You have outlined what has been a mission of mine (using GnuCOBOL for zOS applications) over the course of the last 3 - 4 years. Unfortunately the moderators of this forum have prohibited me from discussing my efforts.
My Windows based solution does not meet the Stallman criteria for "free software" but rather is "free to use" software. Hence the gag order.
Feel free to send me private email. I will gladly respond.
Ralph
wincobol.com
Nearly. Actually the moderators of this forum would like to praise your efforts and advocate for your solution (if Win32 is the necessary target), if you want to also with "shipping" binaries - after you make your software "free" (as far as I remember the main point was to put your own COBOL sources under a free license.
I'd personally always suggest the same route as GnuCOBOL: "tools" (and scripts to create your binaries) as GPL, libraries (and COBOL programs that are CALLed) under LGPL - but aactually any free license would match. Copyright would still be 100% on your side.
You may want to reconsider this.
Until this possibly happens people can get the binaries only, possibly with a feeling of "no one can update this so this project possibly is not good for putting it as a dependency to important projects", from wincobol.com.
Hi Rui and welcome to GnuCOBOL.
While this question arises from time to time it is perfectly fine to post it this way. GnuCOBOL should be able to compile most sources that run on IBM itself (just ensure to use the matching
-stdoption). For MQ there are "Unix and Windows" binaries - as far as I know those work identical, just ensure to have its libraries inCOB_PRELOAD. The same should apply to DB2.CICS and IMS are a completely different issue, I'd be interested in working solutions there, too. Brian's FAQ does not have an entry for those either.
I know that COBOLworx wanted to work on those, @mheyman do you have any update or otherwise information about using those outside of the mainframe?
Regarding CICS, i wonder if someone got ideas on building a tool that reads a BMS and generates an equivalent "Screen Section" code.
I will need to get time for putting my hands dirty on this but from what i see, GnuCobol is more advanced than my initial "assumption".
Windows is not "the issue" - Linux Rocks.
To what purpose ?
A screen section derived from BMS is pretty meaningless without the accompanying "EXEC CICS RECEIVE / EXEC CICS SEND" CICS executive logic and application logic.
Consider the application logic built around the CICS interpretation of the 3270 buffer.
1. Write control characters
2. Attributes
3. Extended attributes
4. FSET
5. Length codes populated
6. etc.
It is a fairly long list of logic related considerations to be accounted for.
I have mapped BMS for CICS emulation. With regards to Linux Rocks - Linux would rock if it implemented the equivalent Windows API for Console Services.
Windows versions of Micro Focus and Fujitsu provide these CBL_ routines for screen creation and manipulation. Theses CBL_ routines are not included in the Linux versions.
CALL "CBL_CREATE_SCR". CALL 'CBL_WRITE_SCR_CHATTRS' USING CALL 'CBL_WRITE_SCR_CHARS' USING CALL 'CBL_SET_CSR_POS' USING CALL "CBL_SET_CSR_SHAPE" USING CALL 'CBL_GET_SCR_SIZE' USING CALL "CBL_SET_SCR_KEYFILE" USING CALL "CBL_SET_SCR_TERMKEY" USING CALL "CBL_READ_SCR_KEY" USING KEY-TYPEAll of the above map onto a Windows API(s).
Without Linux support of equivalent console services I think you are bound to the have Linux communicate with the graphics adapter card bios services.
Ralph
Ralph Linkletter wrote:
In the UN*X world there are no consoles, just (pseudo) terminals.
A completely different animal.
Many applications, such as Win 3270 emulators, are in fact full Win API applications which look like a console.
There is a Win console API, a subset of the full Win API, which is rarely used for real applications.
Using one of the GUI toolkit, such as Gtk or KDE, you can achieve the equivalent functionality.
For example x3270, a GUI application, uses the Xraw toolkit to create a GUI application which looks like 3270 console.
@dilodilo @pat-mccavery Are you able to provide those CBL_ functions as COBOL or C wrappers around curses? It seems most should be doable, possibly needing "something" exposed from libcob, but in any case doable.
Hi Simon,
I believe that at least two of these routines have already been written by Brian:
Look here:
https://sourceforge.net/p/gnucobol/discussion/lounge/thread/2577c752/#b825/a7e7/bb7b/c465/0c2b
Maybe it would just be necessary to add them as functions available in the "STOCK LIBRRARY" ?
It would be a good news if it were possible!
There are some differences between the Micro Focus / Fujitsu syntax as compared to Brian's syntax.
All parameters are passed by reference: All API calls specify an X Y buffer position (relative to 0). See the example CRT-POS below. The Micro Focus and Fujitsu format are the same. 05 CRT-POS. 10 CRT-POS-ROW PIC 9(04) COMP-4 VALUE 0. 10 CRT-POS-COL PIC 9(04) COMP-4 VALUE 0. **Micro Focus syntax:** CALL 'CBL_WRITE_SCR_CHATTRS' USING BUF-POS BUF-DATA (BUF-SUB:BUF-LEN) BUF-ATTR (BUF-SUB:BUF-LEN) BUF-LEN. CALL 'CBL_WRITE_SCR_CHARS' USING BUF-POS BUF-DATA (BUF-SUB:BUF-LEN) BUF-LEN. **Fujitsu syntax:** A Fujitsu prerequisite call is to CBL_CREATE_SCR. CALL 'CBL_WRITE_SCR_CHATTRS' USING CRT-POS CRT-DATA (CRT-SUB:CRT-LEN) CRT-ATTR (CRT-SUB:CRT-LEN) CRT-LEN. CALL 'CBL_WRITE_SCR_CHARS' USING CRT-POS CRT-DATA (CRT-SUB:CRT-LEN) CRT-LEN. CALL 'CBL_READ_SCR_CHATTRS' USING BUF-POS BUF-DATA BUF-ATTR BUF-LEN **Brian's format:** call "CBL_WRITE_SCR_CHATTRS" using by value 0 by reference cbuff by reference abuff by value clen returning chstat call "CBL_READ_SCR_CHATTRS" using by value 0 by reference cbuff by reference abuff by value clen returning chstatPerhaps Brian's code contemplates the entirety of the screen buffer ?
"by value 0" as the first parameter in Brian's call(s) seems to imply some other mechanism is maintaining the cursor position. In the other compilers the X Y coordinate is required.
There are too many differences to use this as a Micro Focus / Fujitsu replacement .
Ralph
Last edit: Ralph Linkletter 2021-04-12
I might finish up these extra stock library calls, seeing as I care more now than I did 7 years ago, but I might press for a slightly different set of idioms first.
There is a FSS library in Hercules MVS TSO space by Tommy Sprinkle, also ported to VM/370 CMS. Might try and see if a TPUT/TGET API would be sympatico with GnuCOBOL POSIX.
http://tommysprinkle.com/mvs/fss/index.html
http://tommysprinkle.com/mvs/fss/funcref.html
If there is going to be a path from mainframe screens to PC screens, might as well go all in and provide a framey API that can be used on MVS or CMS or POSIX. :-)
With a little tooth pulling, the tub3270 Linux/390 device driver kernel module might even sneak its way in x86 land, allowing full on virtual 3270 screens.
That same thought process might also lead to a batch processor that leverages ISAM/VSAM features in MVS to share data between frame COBOL and GnuCOBOL without thinking too hard.
The Hercules emulator handles sockets. A DIAGNOSE instruction is exposed to the S/370 that allows MVS access to hosted TCPIP. People are already enjoying MVS with KICKS (a CICS implementation), BRexx and a growing collection of 3270 block display routines. Latency for submitting jobs, extracting from the spool and getting data back to POSIX is blinky fast.
Adding an extra sub opcode to Hercules to also allow frame OS access to GnuCOBOL libcob services is looking like only a few lines of code will be needed.. A COBOL program running in emulated MVS and POSIX at the same time may be coming to a corner near you.
If the S/380 project proceeds as it should, (adding 31bit mode to s/370) there is an ever growing possibility that the GCC in MVS and CMS will be capable enough to actually get GnuCOBOL compiled for use on a frame, without needing any of the USS layer enabled. Not quite yet, but there are strides at improving the 31bit support in the normally 24bit limited public domain cuts of MVS 3.8 and VM/370 r6. Going above the line.
Having too much fun again.
Cheers,
Blue
Well, there will probably be some entries soon-ish. I've working on a BKNTYM project, Back In Time, GnuCOBOL and the Hercules emulator. Mostly to start a pool of older 1972 ANS COBOL that work with MVS (and VM/370) and modern GnuCOBOL.
MVS 3.8j sports an open source KICKS contribution (a CICS implementation). I've been pondering a thin client on POSIX talking to a KICKS server setup running on an emulated MVS. MVS3.8j is too old for internet, but the Hercules emulator has "extended" the DIAGNOSE instruction to expose host services, including the TCP/IP stack. MVS3.8 feels like it has TCP/IP once you put some Assembly macros to work.
The guts of the BKNTYM plan is using POSIX and Hercules (MVS/VM) together in a solution mix. MVS 3.8j is circa 1985, but most things (source and binary) still work now the way they did, all the way back to the 1970 base of OS/360. Along with VM/370, RSCS, NJE and a few other improvements people have made to turnkey systems for Hercules, you can have entire clusters of Hercules emulated iron nodes running.
There have been some impressive strides made in modernizing the VM/370 hypervisor, lately, (VM/370 Community Edition was released last wee) and work on GCC for MVS and CMS is opening up a lot of potential for a fairly robust explosion of modernization for emulated iron.
There is no DB2 in this mix, but there is VSAM. Even the 1972 ANS COBOL compiler, written to support ISAM and before VSAM existed, can still "fallback" to using VSAM files (without a few features) by simply using a VSAM DD in place of an ISAM DD, i.e. ensuring the AMORG subparameter is set.
Jay Moseley missed having direct VSAM power, so he actually wrote a CALLable layer for both PL/I and COBOL in 360 assembly. I'm experimenting with ISAM COBOL simply using ISAM to VSAM powers inherent in MVS 3.8 core. Seeing as I don't miss any VSAM features having never used them, this does not seem limiting, at all. Jay knows more and felt a stronger need for more direct VSAM control.
It's fun, (and more importantly, very robust), writing some JCL in the comfort of Vim, submitting jobs from Vim via shell scripts to an MVS card reader, with results of the frame job output captured and plopped back into a Vim buffer. Blinky fast.
End game, if BKNTYM works out as it should, will be a playing field of COBOL on POSIX mixed relatively seamlessly with COBOL on MVS. (Old MVS, but so compatible that binaries from 1970 still run when loaded on a system of today). And not just COBOL, all the available compilers. ALGOL, Fortran, PL/1, COBOL, RPG, BASIC, XPL, SNOBOL4, ... (quite a few), and more emerging all the time.
I just ported Dave's FOCAL implementation to VM/370. Dave Pitts wrote the -t and -T listing outputs for GnuCOBOL. And I'm having way too much fun porting
libforth, a Forth implementation to VM/370 CMS. An MVS TSO version is next. If these experiments bear fruit, then I'll be attempting getting libcob compiled for CMS and TSO, then cobc, to run GnuCOBOL on MVS and VM (without needing Unix System Services USS on the iron side). That is future work, and depends on learning enough with the first few experiments.As always, the plan is to leverage GnuCOBOL, but instead of all or nothing rip and replace, to ease porting, is to provide a viable option to run programs on either POSIX or MVS targets interchangeably. Port programs one at a time instead of being faced with the all or nothing scenario.
Have good, make well,
Blue
Brian tput / tget are akin to display / accept.
Albeit a 3270 native buffer translation can display a 3270 screen there remains a gazillion lines of code to implement how the 3270 buffer is transformed for CICS, IMS, DM.
You are aware of CICS.
How about IMS DC ? DM (dialog manager)?
The PDF below is depicting a Windows implementation of a dialog manager (DM) panel.
Factually my WINZOS system fulfills the vast majority of zOS application development and testing (with actual JCL and zOS dataset naming convention). The entire user interface is built with ISPF and dialog manager. Even the most commonly used zOS control blocks are provided for and populated during execution.
Micro Focus supports PL/I and previously supported IBM assembler - WINZOS does not.
I do support GnuCOBOL. The GnuCOBOL support would be better if EXTFH was implemented as it was in Micro Focus and Fujitsu.
WINZOS development and programming is 100% COBOL
My 3270 emulation bolts up to CICS, and DM.
The 3270 emulation makes extensive use of the WIN console API's.
The 3270 emulation takes as input BMS, DM, IMS precisely emulating the user interface as if using a real 3270 or the likes of Attachmate.
Checkout the DM definition and the resulting 3270 display from DM panel services.
I am going to release WINZOS as a companion to WINIDE sometime in June.
Sadly I can't implement any of this in Linux / POSIX
Ralph
@Simon thanks for the mention. COBOLworx, a project within Symas Corporation, has built an IMS/DB prototype (limited HIDAM) accessible from GnuCOBOL as well as other languages with the C ABI. We have shelved it for the moment ... lack of interested customers. I'd be happy to brief you. We also provide binaries for GnuCOBOL and our GnuCOBOL Source-Level debugging tool for
gdb(freeware).