I am quite the beginner, but hopefully I can find some understanding here. I have a few questions regarding personal interest in learning COBOL.
When using device names in cobol, how does cobol know where that device is on a non-mainframe system?
For example - DISPLAY "X" using PRINTER. How does the compiler know which printer? Where is that particular device address stored?
I am attempting to learn cobol at the same time as learning some raspberry pi things, and I wanted to try to access the gpio pins through cobol. I know I can do it in C, using the already written libraries which simply define a hardware memory map position to some variable name (such as GPIO_18 = 0x020000000 or whatever).
Just like the PRINTER descriptor, how do I get Cobol to send data where I want? Does cobol have the same type of common libraries included at compile time like C? It seems without JCL, some of this is more tricky.
From my initial reading this week, it seems the CALL function can import a file (whatever.c) and read the data in that file, but I don't know the appropriate function to make cobol utilize those specific alias's.
I am sure with more reading I can ask my question more precicely, but hopefully someone will be kind and point me in a good direction.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When using device names in cobol, how does cobol know where that device is on a non-mainframe system?
It doesn't really.** GnuCOBOL has a very POSIX-ey view of Data Definitions and resource allocations, compared to say MVS on a frame.
** That's a lie in detail. libcob has code in it for the mnemonic names like SYSIN and PRINTER. Then there are very system specific handlers and overrides available. DISPLAY UPON PRINTER does not directly support port IO for instance, it calls system routines. And usually uses environment variables along with system configuration settings to manage the details.
You can set COBPRINTER to a shell pipeline command string and data is routed as Unix pipe data to wherever the system commands send the pipeline. It can be anywhere, but usually ends with lp or lpr or other POSIX print spool command. Those queues (and installed device drivers) are managed by GNU/Linux sysadmins, or Windows POSIX layer persons, etc.
There is somewhat of an impedance mismatch when reasoning with mainframe device names and POSIX device streams. There are different layers for COBOL in translating FILE SECTION names and conventions on a frame than what is provided on small tin. We could do a better job of bridging that gap in reasoning, but POSIX can have some advantages too.
There is direct access to most Linux devices via the filesystem. The /dev, /sys, trees, along with mount points, loadable device drivers and things like FUSE, but that is managed by the OS, not COBOL. You could open a /dev/...filename for read/write, but the COBOL record versus POSIX stream thing could get complicated. There are many many possibilities for setting up a POSIX layer so it looked simple from the GnuCOBOL side, but not easily from within GnuCOBOL, out of the box. But, another caveat, GnuCOBOL supports POINTER and PROGRAM-POINTER. You can eventually do anything using only COBOL sources that you can do in C, including laying down machine code at runtime and jumping to it, if needs be. But why do that if three lines of shell script can do the same thing, kinda thing.
Attached are 2 COBOL programs.
SIMPLE1.COB relates a COBOL file definition to a dataset on a PC by use of the ASSIGN TO clause with a literal that designates the PC file to process
SIMPLE2.COB relates a COBOL file definition by a different use of the ASSIGN TO clause.
In this instance the COBOL program expects an environment SET STATEMENT for SYSUT1.
SET SYSUT1=C:..... You replace the .. folders(s) and PC file Name. with the location of the file to be processed.
I am quite the beginner, but hopefully I can find some understanding here. I have a few questions regarding personal interest in learning COBOL.
When using device names in cobol, how does cobol know where that device is on a non-mainframe system?
For example - DISPLAY "X" using PRINTER. How does the compiler know which printer? Where is that particular device address stored?
I am attempting to learn cobol at the same time as learning some raspberry pi things, and I wanted to try to access the gpio pins through cobol. I know I can do it in C, using the already written libraries which simply define a hardware memory map position to some variable name (such as GPIO_18 = 0x020000000 or whatever).
Just like the PRINTER descriptor, how do I get Cobol to send data where I want? Does cobol have the same type of common libraries included at compile time like C? It seems without JCL, some of this is more tricky.
From my initial reading this week, it seems the CALL function can import a file (whatever.c) and read the data in that file, but I don't know the appropriate function to make cobol utilize those specific alias's.
I am sure with more reading I can ask my question more precicely, but hopefully someone will be kind and point me in a good direction.
Thanks!
It doesn't really.** GnuCOBOL has a very POSIX-ey view of Data Definitions and resource allocations, compared to say MVS on a frame.
** That's a lie in detail. libcob has code in it for the mnemonic names like SYSIN and PRINTER. Then there are very system specific handlers and overrides available. DISPLAY UPON PRINTER does not directly support port IO for instance, it calls system routines. And usually uses environment variables along with system configuration settings to manage the details.
You can set COBPRINTER to a shell pipeline command string and data is routed as Unix pipe data to wherever the system commands send the pipeline. It can be anywhere, but usually ends with
lporlpror other POSIX print spool command. Those queues (and installed device drivers) are managed by GNU/Linux sysadmins, or Windows POSIX layer persons, etc.There is somewhat of an impedance mismatch when reasoning with mainframe device names and POSIX device streams. There are different layers for COBOL in translating FILE SECTION names and conventions on a frame than what is provided on small tin. We could do a better job of bridging that gap in reasoning, but POSIX can have some advantages too.
There is direct access to most Linux devices via the filesystem. The
/dev,/sys, trees, along with mount points, loadable device drivers and things like FUSE, but that is managed by the OS, not COBOL. You could open a/dev/...filename for read/write, but the COBOL record versus POSIX stream thing could get complicated. There are many many possibilities for setting up a POSIX layer so it looked simple from the GnuCOBOL side, but not easily from within GnuCOBOL, out of the box. But, another caveat, GnuCOBOL supports POINTER and PROGRAM-POINTER. You can eventually do anything using only COBOL sources that you can do in C, including laying down machine code at runtime and jumping to it, if needs be. But why do that if three lines of shell script can do the same thing, kinda thing.See https://gnucobol.sourceforge.io/faq/index.html#printer for some obscure details about setting up PRINTER output. There are more hints in the FAQ, Jay.
Have good,
Blue
Last edit: Brian Tiffin 2021-10-16
Attached are 2 COBOL programs.
SIMPLE1.COB relates a COBOL file definition to a dataset on a PC by use of the ASSIGN TO clause with a literal that designates the PC file to process
SIMPLE2.COB relates a COBOL file definition by a different use of the ASSIGN TO clause.
In this instance the COBOL program expects an environment SET STATEMENT for SYSUT1.
SET SYSUT1=C:..... You replace the .. folders(s) and PC file Name. with the location of the file to be processed.
Hopes this helps a little bit.
Ralph