Gnucobol, environment variables and other configuration variables.

[celsofigueiredo]

Dear.

I've been using Gnucobol since I was an open cobol (but only a user). I realized that this tool has improved a lot, but I have doubts about the environment variables and the configuration variables.

Type:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export LD C = anything :/directory
./configure --with-db --anything --anything

And also, before the execution of a program

export ??????????
COPY=/directory
SCR=/directory
OC_OBJ=/directory
./program

I'm a little suspicious, the reason for some GNUcobol example programs, which I try to run and don't work.
Can you help me with my doubts?

Celso Henrique.

[Brian Tiffin]

We can talk more about this, Celso, but that seems like an overly complex view. Perhaps we can use some tricks to simplify things locally for you.

If you are going to build GnuCOBOL from source, take the time to ensure that the local link loader cache config includes /usr/local/lib. It'll be a one time sudo level text edit of a system file, ala /etc/ld.so.conf. Which probably has something like

include /etc/ld.so.conf.d/*.conf

in it, Ensure one of the configuration files, either /etc/ld,so.conf itself or a sub-directory file. Any of them can include the information. Pick one.

For example, here, an old pentuim laptop, Ubuntu 18.04

btiffin@dev:/etc$ cat /etc/ld.so.conf.d/libc.conf
# libc development configuration
/usr/local/lib

The filename libc.conf was arbitrary. Just make sure one of the ld.so.conf files includes a line of

/usr/local/lib

After that, and a sudo ldconfig (or reboot), you'll never have to worry about the /usr/local/lib thing again, for that development node. Unless some care is taken, this is actually a bit more secure than relying on LD_LIBRARY_PATH at run-time. Win-win.

I'm not sure what you mean by the export LD C = anything line, Celso. Which is a good sign we have not explained things properly over the last few months. Focus on a tree, ignore the forest, the forest can be overwhelming. Make your dev machine a fort. Customize to taste, one decoration at a time, then more things should just work as expected on first tries. The best kinda tries. :-)

Let's work out some system level ld.so configurations and/or development subdirectory links to system level search paths. Make it easier to focus on some COBOL going forward. We can find some steps and incantations to make sure ./configure behaves on your dev box with less surprise. And GnuCOBOL libcob just finds the things it is supposed to find.

After that, we can discuss some of the more intricate details and flexibilities.

With that in mind. Do not fear mucking around in system level files (if you own the system). Do it once, jot it down, and smooth out possible future grief on the development box. If the system barks about not finding a library you know is in a directory where you want it, add it to ld.so.conf and be done with it. While developing, go ahead and add a system level symlink if it helps get a build working. Jot it down, and continue to the next hurdle. Undo the temp links when no longer used. Mistakes made? Text editors and reboots can usually fix them.

It's overwhelming, but to build some of these decorations, site local information needs to be figured out.

For fun and profit, as a step, try ldconfig -p (without sudo). It'll list the entire link loader cache. Then ldconfig -p | grep cob to see where your system expects to find libcob. Don't worry too much about the amount of information. Focus on a few of the lines and leave the rest to the subconscious and sleep time.

Another tool to get used to is strace and looking at all the system calls that occur during compiles and when running new programs. Again, try and ignore the forest and find a few interesting trees to stare at. With an eventual goal of simplifying things until the forest dissappears into the background when chasing problems.

Have good, make well,
Blue

[Vincent (Bryan) Coen]

Please provide what programs do not compile or/and work with GC v3.1 RC-1.

Should point out I use Linux and do not set the above paths and the
one's you set before running a program but I do have in .bashrc the
following :

# .bashrc

# User specific aliases and functions

# Source global definitions
if [ -f /etc/bashrc ]; then
         . /etc/bashrc
fi
export COB_SET_TRACE=YES
export COB_TRACE_FILE=${HOME}/trace.log
export COBCPY=~/cobolsrc/ACAS/copybooks
export COB_SCREEN_ESC=YES
export COB_SCREEN_EXCEPTIONS=YES
export COB_LIBRARY_PATH=~/bin
#
export 
PATH=~/bin:.:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/games:/usr/lib64/qt5/bin:/home/vince/bin:/home/vince/.local/bin:/home/vince/mvs380/hercules/linux/64/bin
export ACAS_LEDGERS=~/ACAS
export ACAS_BIN=~/bin
export TMPDIR=~/tmp

On the above I have excluded any that are not related to GC.

Vince

[celsofigueiredo]

Dear Vincent.

I currently use GNUcobol on linux ubuntu 16.04 and the version of gnucobol is (GnuCOBOL) 3.1-rc1.0.

celso@celso-Inspiron-3583:~$ cobc --info
cobc (GnuCOBOL) 3.1-rc1.0
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
Este programa é livre; ver a origem para condições de cópia.  NÃO existe
garantia; nem sequer para COMERCIALIZAÇÃO ou ADEQUAÇÃO A UM DETERMINADO FIM.
Escrito por Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Compilado em:  Jul 30 2020 20:47:27
Empacotado em: Jul 01 2020 00:39:30 UTC
Versão de 'C': "5.4.0 20160609"

build information
build environment        : x86_64-pc-linux-gnu
CC                       : gcc
C version                : "5.4.0 20160609"
CPPFLAGS                 : -I/usr/local/include
CFLAGS                   : -O0 -g3 -pipe -fsigned-char -Wall
                           -Wwrite-strings -Wmissing-prototypes
                           -Wno-format-y2k
LD                       : /usr/bin/ld -m elf_x86_64
LDFLAGS                  : -Wl,-z,relro,-z,now,-O1

GnuCOBOL information
COB_CC                   : gcc
COB_CFLAGS               : -I/usr/local/include -Wno-unused
                           -fsigned-char -Wno-pointer-sign
                           -I/usr/local/include -pipe
COB_LDFLAGS              : 
COB_LIBS                 : -L/usr/local/lib -lcob -lm
COB_CONFIG_DIR           : /usr/local/share/gnucobol/config
COB_COPY_DIR             : /usr/local/share/gnucobol/copy
COB_MSG_FORMAT           : GCC
COB_OBJECT_EXT           : o
COB_MODULE_EXT           : so
COB_EXE_EXT              : 
64bit-mode               : yes
BINARY-C-LONG            : 8 octetos (bytes)
endianness               : little-endian
native EBCDIC            : não
entrada/saída de ecrã  : ncurses
variable file format     : 0
sequential file handler  : integrado
ISAM file handler        : BDB
mathematical library     : GMP
XML library              : libxml2
JSON library             : cJSON
celso@celso-Inspiron-3583:~$

these variables I have to add to the bash.bashrc file

export COB_SET_TRACE=YES
export COB_TRACE_FILE=${HOME}/trace.log
export COBCPY=~/cobolsrc/ACAS/copybooks
export COB_SCREEN_ESC=YES
export COB_SCREEN_EXCEPTIONS=YES
export COB_LIBRARY_PATH=~/bin

export
PATH=~/bin:.:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/games:/usr/lib64/qt5/bin:/home/vince/bin:/home/vince/.local/bin:/home/vince/mvs380/hercules/linux/64/bin
export ACAS_LEDGERS=~/ACAS
export ACAS_BIN=~/bin
export TMPDIR=~/tmp

As you noticed, I don't know how to configure anything.

Celso Henrique.

[Vincent (Bryan) Coen]

Hi  my comments lower down :---->

On 01/08/2020 02:33, celsofigueiredo wrote:

[...]> these variables I have to add to the bash.bashrc file

export COB_SET_TRACE=YES
export COB_TRACE_FILE=${HOME}/trace.log
export COBCPY=~/cobolsrc/ACAS/copybooks
export COB_SCREEN_ESC=YES
export COB_SCREEN_EXCEPTIONS=YES
export COB_LIBRARY_PATH=~/bin

export PATH=~/bin:.:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/games:/usr/lib64/qt5/bin:/home/vince/bin:/home/vince/.local/bin:/home/vince/mvs380/hercules/linux/64/bin

Change above where 'vince' to your login name directory and remove any
paths that are not in your system such as
/home/vince/MVS380/hercules/linux, and /usr/games if not needed so the
above line looks like :

PATH=~/bin:.:/usr/local/bin:/usr/local/sbin:/usr/bin:/home/vince/bin:/home/vince/.local/bin

and add any you need or are using but remember to create a bin directory
from your home directory to hold all your binaries / executables.
This is used only for your created programs as all other usually go else
where.

export ACAS_LEDGERS=~/ACAS
export ACAS_BIN=~/bin

Remove these two as they are for my open source ACAS accounting software
written in GnuCobol (available on SF as ACAS.

export TMPDIR=~/tmp

Here make sure you have a directory in your home directory called tmp - 
you should have but ...

Next  change line :

export COBCPY=~/cobolsrc/ACAS/copybooks

To match your directory for your copy libraries and if you do not have one then remove it

This is only needed if you are building systems / packages of Cobol
written programs.

If you cam compiling for another system / application the I have a
script that over writes ir i.e., :

export COPCPY=~/cobolsrc/payroll-UK/copybooks

or

export COBCPY=~/

Here note the leading ~ char which says path starting in home directory.

Now my attempt to look at my o/p from cobc --info

Most of the differences are because you are using a very old ubuntu distribution as the current one is  20.04 LTS
The 'LTS'   means long term support so it is usually good for 5 years or better.
I suggest you consider upgrading but this might involve a total re-install and that might be a bit of a pain if you do not have a separate partition to install to and this way you can always reboot back to the older version while setting the new one up.

It is possible that v20.04 will update over 16.04.   I have to look at this myself as I run a media system which uses 16.04 with mythtv - just have to pluck up the courage :)

Vince

[celsofigueiredo]

Dear Vincent.

I just don't use the newest version of Ubuntu at (20.04), due to a cobol editor, which I have been using for a long time (OpenCobolIDE 4.7.6) this editor, does not work from version 18.04 of ubuntu. This is the only reason I don't use newer versions of ubuntu.
environment variables and any other type of variable, for me it's a monster that I can't understand.
other variables that I don't know what it's for:
export CPPFLAGS=
export LDFLAGS=

Celso Henrique.

P.S.:

Examples that didn't work:
https://gnucobol.sourceforge.io/faq/gcfaq.html#index-917
https://github.com/opensourcecobol/Open-COBOL-ESQL
https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/esql/
Examples that worked correctly:
https://sourceforge.net/p/dbpre/code/HEAD/tree/
https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/samples/DBsample/PostgreSQL/

[Vincent (Bryan) Coen]

On 01/08/2020 22:40, celsofigueiredo wrote:

Dear Vincent.

I just don't use the newest version of Ubuntu at (20.04), due to a cobol editor, which I have been using for a long time (OpenCobolIDE 4.7.6) this editor, does not work from version 18.04 of ubuntu. This is the only reason I don't use newer versions of ubuntu.

What is the problem with running under 18 or 20 exactly as it should
work if all the required libraries are installed ?

environment variables and any other type of variable, for me it's a monster that I can't understand.
other variables that I don't know what it's for:

export CPPFLAGS=
export LDFLAGS=

Looking at the PG manual :

COB_LDFLAGS
Set to any linker/loader (ld) switches that you’d like to pass on to the C compiler from the cobc compiler (in addition to any that cobc will specify).

Not found CPPFLAGS  so where did you see that one ?

Should point out a lot of these type of settings are special purpose so it is likely you do not need them - ok I have never needed them :)

Vince

[celsofigueiredo]

Dear Vincent.

My system:
Linux Ubuntu 16.04 and windows 10 (I hardly use this crappy windows); but from time to time I have to use it.
Mysql database and Postgres database.
Gnucobol 3.1
I have always studied, practiced and worked with Cobol programming language for Mainframe.
But as I am now retired, and not to forget COBOL, I started using the OpenCobolIDE 4.7.6 editor and GNUCobol 3.1.
From that list above, of examples that don't work, do you have the solution?
Once again, I appreciate your help.

Celso Henrique.

P.S.:
Sorry for the message above, I sent it as anonymous, forgot to login

---

mod edit, removed duplicate mentioned above

[Brian Tiffin]

Perhaps we can work together to write up some documentation that can make things easier, Celso.

As a chat at first, later an outline and some prose if things work out.

To start; if I said "environment variables are kinda like JCL system symbols", would you know what I meant to imply? The wrongness of the loose conceptual relationship notwithstanding.

This is to get a handle on what page to start on, Celso. The objective would be to relate POSIX concepts to MVS concepts. There are fundamental differences, but we might be able to abstract that away if we can find the correct prose, make it easier to transfer existing MVS skills and assumptions to and from GNU/Linux details.

Then if I said "the ld.so cache is kinda like SYS1.PARMLIB(LPALST00) (even looser conceptual relation) and SYS1.PARMLIB(LNKLST00) (slightly closer to ld.so cache and search path in concept) when using a LKED.SYSLIB DD statement", would that make any sense?

I'm willing, if you are, Celso; how far down the rabbit holes do we want to go to make an effective explanation of the differences between cobc/libcob and IGYWCLG (or IKFCBL00 or ,,, depending on what SYS1.PROCLIB might provide on sites you worked on and what any COB.SYSLIB DD might look like.

If you think this might be a worthwhile way of coming to grips with POSIX link loading, Celso, let's dig in and work out some inter-OS jargon we can use to make it seem more like intra-OS,

An opinion. Anyone that can handle programming on a mainframe can handle POSIX details (and then some). :-)

Have good,
Blue

[Ralph Linkletter]

Brian I think //STEPLIB or //JOBLIB is a more appropriate comparison than the linkst (or LPA).
zOS application programmers are familiar with the above.
Not so much interacting with LINKLST since loading occurs at IPL time.
Typically interaction withSYS1.PARMLIB(LPALST00) is the domain of zOS system programmers - not application programming staff. Most often a RACF protected resource.
Perhaps pursue the analogy on the basis of JOBLIB ?

[Brian Tiffin]

Good points, Ralph. I'm of the opinion that everyone learns with different mental triggers, so the more analogies the better.

I was going to mention steps when it came to explaining the difference between cobc -c, -m, -b and -x and how those kinda relate to C, CG, CL, and CLG.

The differences in detail are not always directly relatable, given the apple and orangeness of the platforms.

Looking for a reasonable baseline for conversations for this particular question, (with a hope that it might generate some useful entries in the FAQ or Guide, for anyone coming to GnuCOBOL from mainframe programming).

And maybe the odd round of cheerleading to let every programmer know that there is nothing to fear from owning a machine and digging in with a little system administration from time to time. :-)

Have good,
Bllue

[Mickey White]

Brian, Ralph is correct. Most cobol programers do not worry about SYS1 libraries. The IBM shops I work(ed) at programmers just either used a compile jcl job in one of their own partioned data sets ( I do this where I work), and the compile/link statements never change (except maybe a configuration parameter)
Here is my example of compile exe and link>
//COMPILE EXEC PGM=IGYCRCTL,PARM='NOEXIT,TRUNC(BIN),ARITH(EXTEND)'
//LINKED EXEC PGM=HEWL,PARM='LET,LIST,XREF',COND=(5,LT)
Other places I worked, the progmmers just use an ISPF panel that never changes by us (except PARMS).. and it runs basically the same compiler (parms added/selected/changed on the spf panel)
//COBOL EXEC PGM=IGYCRCTL,REGION=220M,COND=(12,LE),

The real changes are in the JOBLIB, PROCLIB, or STEPLIB in the JCL that executes the compiled program. When you run the program you changed.
In this jcl is were you most times would add different libraries ( load , link, C, ... whatever) . We mostly use the steplib or proclib to run our test versions of the program vs the production versions.
example
//RANDOM1 EXEC PGM=RANDOM1
//STEPLIB DD DISP=SHR,DSN=MY.PDS.DEVLINK
// DD DISP=SHR,DSN=SYS1.LINKLIB
// DD DISP=SHR,DSN=PROD.LINK

The step lib for the program ofcoures looks in MY.PDS.DEVLINK first for the program then the other concatenated libraries.

This is Z/os current.

[Brian Tiffin]

Thanks, Mickey.

Can't say I'm not a little bit disappointed. (With a smiley).

Flailing around looking for some prose that may help connect the dots from MVS programming to GNU/Linux, we just skip the entire JCL thing? What percentage of COBOL programmers care enough to be able to create a JCL card stack from scratch?

terminology question - what do you call a stack of JCL cards that make up a job when chatting in the coffee room? deck? stack? job? "all the cards"? ;-)

With the percentage question, I'm trying to alleviate a fear that professional COBOL is cargo cult programming (from the OS perspective). Boiler plate programming, just to save some techinical typing is a good time saver, in my opinion, but cargo cult programming of copy and pasting ununderstood control cards sounds a little scarier.

Or, that impression is bunk? Not knowing the ins and outs of the system is "by design"? Let people focus on the single role of "COBOL programmer, keep arms and hands inside the cabin at all times". All you ned to know is how to change a DSN field in a DD statement? Leave the rest to the system programmer?

Asking, not to be (overly) facetious, but to get to the Page 1 of a jargon file for useful communication in a how-to for a framer using a POSIX compiler. If the prose is better off skipping over some OS concepts (SYS1.LPALST for instance), then so be it.

Still unclear on the day to day baseline of normal jargon used in technical discussions between COBOL programmers, system programmers, operators and/or team leads. What level of operating system technical detail is the norm?

As a for instance, I'd want to know what IGYCRCTL means in long form. How to people "speak" CRCTL? I usually pronounce CLG as CompileLinkGo in my inner dialog. COBUCLG makes some sense that way and doesn't become part of a cargo cult headspace. With IKFCBL00, I'd want to look into how IKF became the prefix, and how that relates to IGY naming decisions, etc. If that is not a day to day concern with COBOL programmers on a frame, it means shifting page 1 of the jargon file to make things useful.

Cheers,
Blue

[Ralph Linkletter]

I have not seen a 2540R card reader / punch in 30 years.
Hence I have not seen a "stack" of JCL cards ("deck" would be the term back then) in over 30 years.
When you say "cards" are you thinking Holerith 80 character physical cards - like Bicycle playing cards. Cards I could hold in my hands ?

ISPF is the mechanism to code, test, and submit jobs.
Missing from this discussion is the actual process of compiling a mainframe COBOL program.
With the exception of a vanilla batch job (not DB2, no batch CICS, no batch IMS, no MQ) most often a preprocesor or two are executed prior the the COBOL compilation.
Further the source code manager(s) are part of and parcel to compiling a zOS mainframe COBOL program (products like Endevor, Panvalet, some IBM mechanism)

Compile, link, and go is not a relevant process anymore.
The successfully compiled COBOL program is cataloged to a user, test, or production PDSE library. If testing, then JCL is created with the appropriate DD cards, utilities, proc libs, test datasets... and submitted via ISPF for execution.

Promotion from user to test to production is also a finite process.
Each step along the way the RACF protection increases accordingly.
Regarding, "IGYCRCTL means in long form" what the hell does Ubuntu mean in long form :-)

Some IBM prefixes have a history. I can think of one STL compiler professional that created all modules with his initials.

A typical test job stream

//ASQLJOB  JOB 'WINZOS - TSUBLUH',CLASS=A,MSGCLASS=A 
//STEP01 EXEC PGM=IEFBR14 
//SYSUT1 DD DSN=TSUBLUH.WINZOS.SORTED.DATA,DISP=(MOD,DELETE,DELETE)
/*                                                                 
//STEP02   EXEC PGM=IKJEFT01,REGION=1024K 
//SYSUDUMP  DD SYSOUT=*
//SYSPRINT  DD SYSOUT=*  
//SYSOUT    DD SYSOUT=*   
//SYSTSPRT  DD SYSOUT=*    
//SYSUT1    DD DSN=TSUBLUH.EMPLOYEE.DATA,DISP=SHR 
//SYSTSIN   DD *
  DSN SYSTEM(DB2) 
      RUN PROGRAM(ZTESTSQL) PLAN(EMPLOYEE) - 
      PARMS('/EMPD')  - 
      LIB('TSUBLUH.DB2.LOADLIB')  
  END 
/*                                                                 
//STEP03 EXEC PGM=IEFBR14  
//SYSUT1 DD DSN=TSUBLUH.WINZOS.SORTED.DATA,DISP=(MOD,DELETE,DELETE)  
/*  
//                                                            

Submitted for execution via TSO / ISPF.
One could not find an 029 key punch to create the above.
Beyond that, finding a 2540R card reader / punch would also be virtually impossible :-)

[Brian Tiffin]

Cards I could hold in my hands ?

Nope, the terminology of JCL source lines. Ala job card. Around a meeting room, what is common jargon for the source lines that make up a complete JCL job stream.

Compile, link, and go is not a relevant process anymore.
The successfully compiled COBOL program is cataloged to a user, test, or production PDSE library. If testing, then JCL is created with the appropriate DD cards, utilities, proc libs, test datasets... and submitted via ISPF for execution.

Cool. So, in a common shop. who writes the JCL? COBOL programmer?, system programmer?, operations? Do the programmers decide what link libraries are involved or where modules are written? I assume that even in ISPF panels, the programmer thinks of this as a SUBMIT? Versus, say, thinking about it as a "command pipeline" in POSIX?

Does the average COBOL programmer need to know what SYSUT1 infers? Or does the focus gloss over that and simply cargo cult program a change to the DSN and maybe the DISPosition. (an example of long-form questions is DISP meaning dispostion and DSN meaning Data Set Name).

Regarding, "IGYCRCTL means in long form" what does Ubuntu mean in long form :-)

Ubuntu is Zulu (Nguni Bantu) for humanity.

Debian is short for Debra and Ian. Debra Lynn happened to be Ian Murdoch's girlfriend at the time of naming.

And just as another tidbit of root meaning, the "My" in MySQL, is named after the daughter of Michael Widenius, My. Another daughter's name being the root of MariaDB.

I find knowing the roots of jargon extremely helpful in understanding. Or at the very least, to remove a curiosity surrounding why things are the way they are during coffee talks and team meetings with management.

Part of the goal of this thread. To find the common speak that can help us ensure both sides of the conversation understand the words in play. So a description of building on POSIX has a better chance of making sense to an experienced (or intermediate level) mainframe COBOL programmer.

As it's going, I (and I think we) have more work to do to find comfortable common ground to avoid some foundational misunderstandings.

Once that is more settled, (and I am speaking of my own sense that things are making sense), we can get into the myriad technical details and interactions of the environment settings and compile time switches with GnuCOBOL on POSIX. With, hopefully, the odd reference to relationships with MVS JCL programming.

To try and avoid documentation (lack thereof, actually) that leads to cargo cult programming. Putting in what I mean by that, just in case, as it is slang jargon I'm using.

    Cargo culting was a specific phenomenon and later a
    general concept. The specific phenomenon was the belief
    which began among Melanesians in the late 19th and early
    20th centuries that various ritualistic acts such as the
    building of an airplane runway would result in the
    appearance of cargo via airplanes, even though they did
    not have a specific reason to believe that airplanes would
    land on their site.

That initial definition from wikipedia can lead to a somewhat derogatory tone. I find it more subtle than that. Not demeaning, just deknowing.

We have zero excuse putting GnuCOBOL in culting territory in 2020. Will strive to avoid. :-)

Have good,
Blue

[Mickey White]

Brian. A complete set of JCL is usually just called a Job.
Compiles are done before we create detail JCL. The compile Job usually does not change, just the source code PDS member name. Compiling is the mindless task, unless you need extra loadlibs concatenated (as mentioned before ) during the compile process.

Programmers have to learn JCL because they write their own JCL jobs, usually, at least the norma business logic applications: payroll, invoicing, billing, data manipulation... Learning JCL is learning a new language, like COBOL, Assembler, Fortran....

Today we use proc statements, which is just a way to store multiple step JCL. A typical job may run 5 to 10 execute statements (executes the loaded/linked program) with its associated DD statements. Some statements (execute) may be system programs, like IEBCOPY or REPRO to creat VSAM (index) files, Sorts, .... The proc statement would just point to the proclibrary (proclib) PDS and inside there are all the JCL statments.... You donot have to use proclibs, you can have every step inside the single JCL job. And usually during code and test you do have all the steps in a job, and once it is ready to go to production you would copy all the steps (not the JOB card/statement) to a pds proclib. And then the JCL Job could just execute the proc.

So Developers DO have to write the JCL.

The programmer (COBOL) does need to know some specific libraries. Example, the different LOAD libraires , like the static library, the dynamic load library, and even a SYS1 library that contains the IBM utilities or some other high-level library that contain specific company utilities/programs/subroutines. These usually are not many and most programmer just use the common static and/or dynamic cobol load libraries (where the programmer compiles his program to).

IBM has many utility type programs and most of the names do not mean anything:
some old short examles
IGY - Cobol compiler
IKF - Another cobol compiler ( very old )
IST - Communication server aka VTAM
IDC - access metod services / vsam
IKJ - TSO
ISP - ISPF dialof manager
ISR - ISPF
IEB
...
Hope that helps

[Ralph Linkletter]

Brian:

The challenge is that of disparate platforms.
Render on to Caesar blah blah blah.

zOS represents a culture. A culture that has been honed over decades.
Substituting / accommodating a foreign culture (POSIX in this instance) is a matter of time and in my opinion necessity.
The question I have is one of need / necessity.
Is it necessary to transition the familiar culture (zOS) to a new culture (POSIX or whatever) ?
If so why ?

I suspect there is a some rational process that would enable doing so.
Especially from an educational perspective.
Perhaps as a function of job security.
Recreation / hobby ?

Beyond the above ???

From a zOS perspective POSIX is a standard I am not familiar with.
Is a POSIX compliant compiler as proprietary as UWP or .NET ?
What functionality is lost as a consequence of a imposing POSIX as a "standard" ?

Celso there are some facets of zOS application programming environment that are difficult to replicate with GnuCOBOL (or for that matter any PC COBOL vendor) and presumably more difficult to implement with a POSIX version.

The first major difference in the Cobol domain is there is no native support for EBCDIC files.
A corollary on the zOS side is there is no native support for ASCII files.

Consider the level of effort required to implement these zOS utilities.
DFSORT (include, omit, sum, E15, E37, E22 exits)
No support of inter language calling - common assembler language subroutines, PL/I
No support of language environment routines (LE, CEExxxx)
No support for any DFSMS-DFP utilities. For example:
IDCAMS
IEBGENR
IEBCOPY
...
Most DB/2 utilities
No JCL
No Proclib(s)
No SDSF
The set of missing zOS functionality is extensive.

From a hardware perspective 3270 terminal features are not available.
Missing:
TSO
CICS
IMS
Dialog manager
ISPF
ISPF editor (especially the bindings to the JES reader - no SUBMIT)

From an I-O subsytem perspective missing are:
PDS / PDSE
Generation data groups
A system catalog
Concatenated datasets (especially those concatenated datasets that are OPENED I-O)

The above represent commonplace functionality of zOS.
Many of the zOS components are missing.
Albeit most of the missing elements can be provided for by recreating the functionality, the level of effort and the in depth understanding required to do so is a formidable task.

3270 services are an absolute requirement - missing almost everywhere on any non IBM platform.
As I understand it, a faithful 3270 emulation via Linux would require explicit programming of the video adapter BIOS (way beyond the TTY / term cap / term info services of Linux).
There is no screen section in an IBM zOS Cobol environment.
This is major surgery to port a zOS online application.
No BMS (CICS Basic Mapping Support).
No MFS (IMS Message Format Service).
No dialog manager panel definitions

From my perspective GnuCOBOL provides a platform for batch jobs and an interactive platform provided by curses.
The baseline logic of a program can persist.
A new OS environment will dictate a learning curve to assimilate new techniques to accomplish what was routine in the zOS environment

Transitioning from a Realia, a Micro Focus, a Fujitsu or other PC COBOL vendor I presume to be easier that transitioning from zOS COBOL.
But it seems that each COBOL vendor has implemented its own scheme to access OS services.

I guess it gets back to my persistent question.
What is the purpose of GnuCOBOL.
It still eludes me :-)

Ralph

[Mickey White]

This is excellent Ralph.

Here is good information for the mainframer coming over to the GnuCOBOL process. It shows what Z/os has that is not found here at GnuCOBOL and is really not found anywhere else except at IBM.

So as Brian, and all of us, continue to help the Mainframes come on over and use GnuCOBOL we can relate to questions they may have on what they are used to doing on the Z/os side, and what they may or may not be able to do here on Linux/Windows/Mac.

It will be good to remind them that GnuCOBOL is cobol, not Z/os and not Linux and not any of the things that IBM may offer except Cobol.

I love this group and this continuing education and the professionalism.
Keep on Keeping on! :)

[James K. Lowden]

As I understand it, a faithful 3270 emulation via Linux would require explicit programming of the video adapter BIOS (way beyond the TTY / term cap / term info services of Linux).

I can help you there: that's absolutely not true.

I was part of a small team in the 1980s that created a faithful 3270 emulation. It's no great trick, provided a character-addressable terminal with attributes for things like bold and reverse video.

There are a few 3270 emulatiors available from your garden-variety package manager. Whether they're "faithful" or not depends on what you mean, but any limitations are certainly not attributable to not using the BIOS.

---

One question I would have about 3270 support, though, is: why? Why, in 2020, is it interesting to recreate the computing experience of 1975? The programmers and engineers of that day certainly didn't seek inspiration from 1925!

Instead, I would like to see BMS "upgraded" to the present day. Keep BMS, but map it onto today's bitmapped hardware. Define your forms, and generate all the GUI artifacts, copybooks, and network glue, so that the Cobol programmer need only do what he did for CICS (only simpler): write to the terminal and read back from it. No rows or column or layout or intricate UI detail. Just put a form and get a response. The programmer never sees a terminal; he sees only data structures.

Programmers who grew up in the model-view-controller world, or who learned application programming post-Netscape, can't imagine how simple -- how very, very simple -- the CICS programming model is. All the work of transferring data between the user and the application isn't just simple: it's automatic.

I've never seen a simpler, more powerful system for basic information gathering and reporting. It's too bad it's not more widely understood and emulated.

[Ralph Linkletter]

Interesting.
Perhaps you could point me to a Linux based 3270 package. Not the likes of Attachmate but rather a Linux implementation of 3270 support with an API that will support the 3270 native data streams.
3270 data streams are the backbone of BMS (CICS), MFS (IMS), DMS (ISPF).
A product that can manage and provide simulation of 3270 data streams via Linux.
Translating 3270 commands, orders, and attributes to a Linux terminal device:
COMMANDS
Write
Erase/Write
Read Buffer
Read Modified
Select
Erase All Unprotected
No Operation
Sense
ORDERS
Start Field (SF)
Set Buffer Address (SBA)
Insert Cursor (IC)
Program Tab (PT)
Erase Unprotected to Address

To me the premise that a bit mapped device is needed to replace an existing solution that accommodates billions of transactions on a daily basis is once again a solution in search of a problem.

I can point you to 3270 packages that operate with Windows.
I have never found such a package for Linux.

[Mickey White]

x3270 is what I use on Linux to get to Hercules MVS3.8 on linux VIA TSO.
(when connected to Hercules, you have SPF and it is nice, as you know)

[Ralph Linkletter]

I guess I did not present a clear definition of the Linux service I am searching for.
Given a DMS definition of a panel (example below) I was searching for a Linux mechanism to support an API between the user written DMS primitive and the Linux device.
The end product to present a terminal display that has the same characteristics as if on a 3270 device or 3270 emulator.
The windows implementation by executing this PC based COBOL statement:

      ** START DIALOG MANAGER WITH PANEL ISR@PRIM
       A-020-SEL-PRIMARY-FUNCTION.
           CALL ZOSPD189 USING
                                                  ISPSEL-LEN
                                                  ISPSEL-PARM.
      ** A RETURN HERE INDICATES ZOS TERMINATION

)ATTR
  % TYPE(TEXT)   INTENS(HIGH) COLOR(TURQ)
  + TYPE(TEXT)   INTENS(LOW) SKIP(ON)
  ^ TYPE(TEXT)   INTENS(HIGH) COLOR(PINK)
  _ TYPE(INPUT)  CAPS(ON) JUST(LEFT) COLOR(RED) INTENS(HIGH)
/*_ TYPE(INPUT)  CAPS(ON) JUST(LEFT) PAD(_) COLOR(RED) INTENS(HIGH) */
  ! TYPE(INPUT)  INTENS(HIGH) COLOR(RED)
  \ TYPE(INPUT)  INTENS(LOW)  CAPS(ON) JUST(LEFT) COLOR(RED)
  { TYPE(OUTPUT) INTENS(HIGH) COLOR(GREEN)
  } TYPE(TEXT) INTENS(LOW) COLOR(GREEN)
  * TYPE(OUTPUT) INTENS(LOW) SKIP(ON)
  @ TYPE(TEXT) INTENS(LOW) COLOR(YELLOW)
  # TYPE(text) INTENS(LOW) COLOR(BLUE)
  $ TYPE(TEXT) INTENS(HIGH) COLOR(WHITE)
 /*  IF (&ZHILITE = YES OR &ZGUI ¬= &Z)                    */
 /*  .ATTRCHAR(19)='PAS(ON) COLOR(WHITE)'                  */
 /*  .ATTRCHAR(1A)='PAS(ON) COLOR(RED)'                    */
 /*  .ATTRCHAR(1B)='PAS(ON) COLOR(BLUE)'                   */
 /*  .ATTRCHAR(1C)='PAS(ON) COLOR(GREEN)'                  */
 /*  .ATTRCHAR(1D)='PAS(ON) COLOR(PINK)'                   */
 /*  .ATTRCHAR(1E)='PAS(ON) COLOR(YELLOW)'                 */
 /*  .ATTRCHAR(1F)='PAS(ON) COLOR(TURQ)'                   */
)BODY
%------------------#WINZOS Primary Option Menu Version 5.6%--------------------
%Option  ===>_ZCMD                                                             +
%
%
%   0 +Settings     }Terminal and WINZOS user parameters}Time. . .  : +&ZTIME
%   1 +View         }Display source data or listings    }Terminal.  : +3278-2
%   2 +Edit         }Create or edit source programs     }PF Keys. . : +&ZKEYS
%   3 +Utilities    }Perform utility functions          }Language.  : +English
%   C +Cobol Compile}Foreground COBOL compile / Link    }Appl ID. . : +ISR
%   P +PL/I         }Foreground PL/I compile / link     }TSO logon. : +&ZUSER
%   5 +Batch Compile}Submit batch compile / link        +System ID  : +WINZOS
%   6 +Windows CMD  }Execute Windows Commands           +Release. . : +5.6
%   S +SDSF         }SDSF Panels
%   A +Assembler    }Java Based Don Higgins Assembler/BAL Emulator
%   T +CICS         }Online Transaction Services via CICS
%   E +Extensions   }User defined functions
%   X +Exit         }Terminate#WINZOS}using log/list defaults
%
%
%
%
%
$Licensed Materials - Property of Metamorphous LLC
$(C) Copyright Metamorphous LLC 2010 - 2019.
)INIT
 &ZPRIM = YES
)PROC
 &ZSEL = TRANS (TRUNC (&ZCMD, '.')
                 0,'PANEL(ISPISMMN)'
                 1,'PGM(ZOSPD104) PARM(1)'
                 5,'PGM(ZOSPD104) DOSCMD(ISPF)'
                 2,'PGM(ZOSPD104) PARM(0)'
                 3,'PANEL(ISRUTIL )'
                 C,'PGM(ZOSPD420)'
                 6,'PANEL(ISRTSO)'
                 S,'PANEL(ISPSDSF1)'
                 T,'PANEL(ISPMCO30)'
                 E,'PGM(ZOSPD277) NOCHECK'
                 P,'PGM(ZOSPD315)'
                 X,'EXIT'
                ' ',' '
                 *,'?')
)END

I am also in need of a 3270 API that can function between the CICS emulation and the linux device display.

* cics statement
              EXEC CICS SEND  
                   MAPSET('MAP6')                                   
                   MAP('MAP6')                                         
                   FROM(MAP6I)                                         
                   CURSOR                                              
                   ERASE                                               
              END-EXEC   
 * exec cics emulation interface
       * SEND MAPSET MAP6 - MAPNAME MAP6
           MOVE 'MAP6' TO MAPSET-NAME.
           MOVE 'MAP6' TO MAPNAME-NAME.
           MOVE 'ZOSJS007' TO PMODULE.
           CALL PMODULE    USING
                           EXEC-CONTROL
                           MAPSET-NAME
                           MAPNAME-NAME
                          MAP6I.          

This is somewhat different than emulating a host 3270 session.
Ralph

[Brian Tiffin]

Hmm, there is a Linux kernel module for driving 3270 devices. But, I've only found docs regarding the kernel/s390 setup. Haven't looked close enough to see if this kernel source can be configured for intel builds.

https://www.kernel.org/doc/html/latest/s390/3270.html

The tub3270 module may well have some inline s390 assembler that would need to be ported, going to look into it. It might end up being a sweet add.

Cheers,
Blue

[celsofigueiredo]

Dear Brian Tiffin, Ralph Linkletter, Vincent

I really liked your encouragement, really for those who come from the cobol MAINFRAME, get a little bit, but I'm already getting used to GNUcobol. Despite my doubts, there are many. I will continue to program in GNUcobol, so as not to forget that excellent programming language that is COBOL. The only example that I really managed to execute until the end, was this:
https://github.com/opensourcecobol/Open-COBOL-ESQL
The others are still studying solutions.
GNUcobol is a new learning experience for me.

[Vincent (Bryan) Coen]

Many if not all of us come from a m/f background or still am and that can be many brands of kit although these days IBM is the primary.

Vincent