As a detail for instance. MVS 3.8 seems to run IKFCBL00 as the COBOL compiler, via COBUC, UCL, UCLG, etc. Is it ICGYW something something in z series now? Or do programmers talk like that? Is there macro names to fling aroung the water cooler like COBCLG? Then to relating (conflating?) cobc -l to // LKED.LMOD DD ...
Cheers,
Blue
Last edit: Brian Tiffin 2020-08-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As a detail for instance. MVS 3.8 seems to run IKFCBL00 as the COBOL
compiler, via COBUC, UCL, UCLG, etc.
Correct.
Is it ICGYW something something in z series now? Or do programmers
talk like that? Is there macro names to fling aroung the water cooler
lile COBCLG? Then to relating (conflating?) |cobc -l| to |// LKED.LMOD
DD ...|
For more modern platforms that depends on exactly the os and the version
i.e., I have access to both OS390 and zOS so different products and
versions.
Just a question of finding out what the process tools are for CL or CLG
( compile, link and may be go)
Of course the level of Cobol differs subject to what one you are using
and IBM still don't support free formats :(
.
Vince
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, the goal is still to get to page 1 in terms of tone. I have near zero frame experience. A small stint in the early 1980s, and recent exploring of Hercules MVS 3.8j. Where do you want to start, Celso? I don't have the 50 years of in between that can spot right thinking from wrong thinking in terms of the jargon, terms of art and slang like I'd like this thread to start covering.
Explanation of POSIX process vs MVS job? Or nitty gritty, can skip some background, CALL to assembler or C issues? Start with linking PGM=IDCAMS type concepts to GnuCOBOL file system models?
One of the first things I can see with MVS is Job vs POSIX process. The frame doesn't start an executable inside any owned state. Fresh start each and every JOB card. The machine is the only parent in terms of JOB cards. I may be mistaken in that foundation of reasoning, and would appreciate a correction for anyone that knows more.
POSIX has the concept of the process tree. Machine starts PID 0 ?, then forks off to PID 1 (which may or not fork off other process ids and now does, many). PID 1 is systemd in 2020 GNU/Linux distros.
A process gets a pointer to a block of memory, the environment space, name=value pairs, concatenated togther and accessed via setenv putenv. And it has wrinkles.
The initial state of a POSIX process is an identical copy of the parent that forked it (you can think of it as spawning, but fork is only one step of a spawn, and super fast). Well, almost identical. The key OS process structure is updated and the current return code is in the state left by the fork, which is 0 when a child starts. The parent state is only different in the nano-seconds after a fork in the return code, which is the new child Process ID, PID. At point of int pid = fork() <right here, the call frame at point of return from the fork function>.
It is up to the child view (with a zero return code) to ask the system what its own process id is. The parent got the distinguishing copy of that value when the kernel finished the fork, so the child has to ask. Children may either wipe state and load an image, or simply continue on, relying on copy-on-write memory pages. A child only needs to allocate page memory if anyone in the tree touchs the page during the life of the process. Plus many many other details on low level Linux, above my pay grade.
Not much of that applies in MVS 3.8. You don't really have the process tree view of running tasks and jobs. When the frame starts a job card it pretty much starts clean, the state of the system kernel? what ever you call the running image after IPL in slang terms. (Asking) is configured for. SYS1.PARMLIB being loaded? - another term of art to nail down - comes to mind.
What is the street slang for that state in frame speak? And the verb (loaded?) that got it there.
The POSIX OS also provides each process an environment space. A pointer to an array of pointers to C zero terminated strings in NAME=VALUE form.
A child process can modify its own environment. It can not directly influence the environment of the parent. When a modification is made, any children of the chidren get the intermediate changed view of a starting environment, and again cannot modify the parent process environment state. DIrectly. The parent might be nice enough to be listening to signals from children (or a socket) and go out of its way to update its view of the environment. There are very good reasons to never do this. :-)
GnuCOBOL makes fairly extensive use of the POSIX environment. Rich in details. There is a list of some of them in the FAQ, but that list is sorely out of date with trunk.
The view of the environment is also at the mercy of some GNU/Linux distribution decisions, and the ever changing (usually slowly at the libc ABI level, but a layer up and things start to drift and shift). Default search paths for dynamic linking and symbol lookup, (dlopen and dlsym) can vary. Default dead code elimination by the link edit phase (in terms of the default search rpath or LD_RUN_PATH as set at compile time) is another shift we may have to keep up with.
I mentioned that last one, as if can effect the -L and -l options used in a cobc invocation. Lots of things effect the run-time effect of the -L and -l options used in a cobc compile. Details we can dig up and hopefully explain properly.
Then Windows adds another layer of complication, but we won't go there for the now, Celso. Sound cool?
More as we go. Did any of the above make sense, Celso? et al? Is that suitable for page 1 in a how to configure make for framers thread?
Have good, make well,
Blue
Last edit: Brian Tiffin 2020-08-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think I was able to explain correctly about mainframe cobol and gnucobol. The cobol language I learned was mainframe cobol and I am now switching to GNUcobol. I'm having some difficulties but I'm gradually overcoming. I've done many examples of GNUcobol that worked correctly. And I managed to understand its logic and operation. But I am completely outraged at myself for not being able to solve this example of gnucobol: https://github.com/opensourcecobol/Open-COBOL-ESQL https://github.com/opensourcecobol/Open-COBOL-ESQL/tree/develop/sample
INSERTTBL.cbl
FETCHTBL.cbl
You have already given me many tips on how to program correctly in GNUcobol. All of these tips helped me understand how the GNUcobol cobol language works.
Celso Henrique.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think I was able to explain correctly about mainframe cobol and gnucobol.
That's a major part of the questions I've been asking, Celso. To find common speak to ensure understanding on both sides.
I'm trying to avoid handing you a fish at this point, Celso. Learning to fish being the goal. I'd like to end this thread with you solving the run-time symbol lookups for your setup. To a level to know where to look if the issue ever arises again with a different combination of program components.
I'll reiterate at this point. Anyone that can handle the technical details and jargon surrounding mainframes, can handle POSIX. For the most part, just a different knowledge base. There are a few core foundational concept differences, but even those are well within the same brainspace. I'd like to find the right words to describe the relationships in a meaningful way.
Given that, Celso, I'm still flailing a little.
When you programmed on the mainframe, did you ever have to pay heed to the details of the
//COMPSTEPEXECPGM=IGYCRCTL ...
or
//COMPSTEPEXECCOBCLG ...
JCL statements? Or was it always site local boiler plate for the EXEC cards?
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to try and change that alphabet soup impression a little, Celso. Removing a layer of nebulous can aid in understanding.
Yes, MVS is a detail rich operating environment. So is POSIX. So is Windows.
Yes MVS is still kinda stuck in upper case short names, but the encodings all have a root and usually an attempt at a mnemonic or acronym.
IEB, utilities
IEBDG, utility, data generation
IEF, code modules,
IEFBR14, code module, named for the primary assembler instruction, branch thru register 14
IDC, Integrated Data Clusters, and the famous IDCAMS, which I pronounce as eye-dee-cams, but the acroynm is AMS access method services.
And on and on into the hundreds. But they all actually mean something. Some just become slang. DASD, Direct Access Storage Device, but you don't even need the acronym, everyone knows what everyone means when they say dazz-dee.
Building up a jargon file for GnuCOBOL for mainframers might have to slip into historical slang, but the hope is that the meaning conveyed is the meaning meant. Sans cargo culting. If there has to be some background definitions, then the attempt will be made to make those understandable from both points of view, too.
Common words like prefix can have a fairly disjoint meaning in casual conversation, sometimes similar but not always. At my current level of MVS misunderstanding, prefix implies the High Level Qualifier in a data set name. SYS1. or UserID.. In POSIX circles (in particular with GNU and autoconf) prefix (without other context) is the top level portion of a full path, as it applies to build and installation, /usr/ or /usr/local, for instance.
No one needs to remember all the words in the acronym and mnemonic soup though, there are reference lists and hidden gems of documentation. Einstein put it well
Einstein was once asked how many feet are in a mile. Einstein's reply was "I don't know, why should I fill my brain with facts I can find in two minutes in any standard reference book?
IBM does a much better job, with quantities of reference material. POSIX less so.
I'd put IBM firmly in the top contenders for king of computing reference books; so many acronymns to explain. But they are explained, all of them. And usually thought out and chosen on purpose, not by random picks from a Scrabble bag.
IBM makes finding IEFBR14 docs pretty easy. Knowing why to use IEFBR14 is knowing the conventions and the slow build up of knowledgebase.
Then, information overload. Thats when a mental swap from tree to forest can help. With too many details, aim for getting a gist of things, then gloss over. Our subconscious is running so many background tasks and summary overnight runs that enough quick grok exposers to an information pile, makes finding things in that information easier and easier.
I'm really starting to drift and ramble...
There is a skill, determining the gender of chicken chicks. A fairly subtle skill it seems. When attempting to train new chick sexers, the experts were asked how they made the call. After some efforts, the experts had to admit that they could not explain it in prose. They just "knew". Trainees are told to just guess, male/female, then hand the chick to an expert. The expert reports back with a Right/Wrong. This is repeated, for all the chicks in the incubators. (I'm making up numbers). 50/50 right wrong on day 1. 58/42 right wrong on day two. 77/33 right wrong on day 3. End of the week, the trainees are correct far more often than incorrect, and approaching expert. And they can't explain how they do it. They just "know". By repetition and not wanting to be told they were wrong.
A side moral of that side-trek is that quick looks at alien data piles can make it less and less alien over time. Assuming there is some feedback regarding on track or completely off the rails when guessing at what you are seeing.
Long post to just say that the alphabet soup offered up by IBM shouldn't be treated as random. Focus on some trees, the forest starts to make sense.
POSIX is worse off in terms of locality of reference material. There are lots of documents, and they are everywhere, not just in a Red bookshelf. Even with less acronym soup words, getting the required hints and chance to grok POSIX can sometimes be harder.
mv? Oh, move. ls ? list sorted? ell ess? Why? Call it list directory and add an alias... But no, gotta know ls. And grep, the global regex print. Gahh!
They kinda got it right with AWK, at least that acronymn is just names of people. :-)
Alien.
Until the day it just makes sense. Experts would be hard pressed to explain it in prose. it just makes sense. Sadly, those same POSIX experts have to remember where too many reference books are, which hurts the overall learning curve for beginning, intermediate, and top levels.
On the frame, I'd imagine the curves from beginner to intermediate and intermediate to expert follow fairly predictable paths. Less so in POSIX. The freeness of the software combinations makes it exponentially harder to document in a unified manner. So, fragmentation abounds.
And I'm sensing we are getting closer to being able to chat our way to a GnuCOBOL/MVS jargon file, with a focus on tectonics for building and using GnuCOBOL, In particular, POSIX static and dynamic link loader issues as compared to mainframe job steps.
Ok, one more common term request for everyone. Link Loader. LKED in DD statement speak. I think that relationship holds? Link Loader/Link Editor? Can we use those terms interchangeably in an MVS/POSIX COBOL jargon file? Phrases that everyone just knows are the actions of resolving symbols and labels in pre and post-loaded object machine code, destined for virtualized memory, managed by highly sophisticated paging tables.
Sub request; how do you differentiate between static link at compile time and dynamic load-link at run-time while in mainframe shop watercooler discussions? The casual word(s) that a co-worker just knows what you mean. I'm hoping that static and dynamic will do, but I haven't seen many references to static in MVS docs.
Do COBOL programmers have to care about the distinction on the frame, or is it the change once in a blue moon boiler plate and edit small DSN details kinda thing?
Ok, 'nother point of curiosity;
I'd be interested to hear if cost-codes might ever come into play with JCL decisions. Are any usage fees rated by type of compute. or OS features exercised? Would any of these charge issues effect how a COBOL programmer writes compile, link or run JCL? Would those decisions ever run counter to best design / module layout optimization decisions?
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, one more common term request for everyone. Link Loader. LKED in DD statement speak. I think that relationship holds? Link Loader/Link Editor? Can we use those terms interchangeably in an MVS/POSIX COBOL jargon file? Phrases that everyone just knows are the actions of resolving symbols and labels in pre and post-loaded object machine code, destined for virtualized memory, managed by highly sophisticated paging tables.
The "new nomenclature" for LKED is BINDER
Binder still executes IEWL (linker)
EXEC PGM=IEWL,PARM='XREF,LIST', IEWL is alias of IEWBLINK
Most would still use "LINK / LINKER" as jargon.
Sub request; how do you differentiate between static link at compile time and dynamic load-link at run-time while in mainframe shop watercooler discussions? The casual word(s) that a co-worker just knows what you mean. I'm hoping that static and dynamic will do, but I haven't seen many references to static in MVS docs.
Almost all zOS subroutines are called dynmically. That is that subroutines are cataloged as RECFM=U in a PDS / PDSE (a "load module" would be the jargon)
Do COBOL programmers have to care about the distinction on the frame, or is it the change once in a blue moon boiler plate and edit small DSN details kinda thing?
Subsystems like MQ, or IMS require entry point resolution. However most zOS installations will have explicit proc lib members to compile and link various subsystem programs.
Ok, 'nother point of curiosity;
I'd be interested to hear if cost-codes might ever come into play with JCL decisions. Are any usage fees rated by type of compute. or OS features exercised? Would any of these charge issues effect how a COBOL programmer writes compile, link or run JCL? Would those decisions ever run counter to best design / module layout optimization decisions?
I think you are speaking of job accouting.
One of the parameters of the job statement can indicate the charge back department budget wise for SMF (System Management Facility) resources consumed during execution of a job stream.
To prevent run away execution another operand of the job statement is TIME=nnnn.
If the execution of an application consumes more CPU time that allotted via the TIME=parameter the job will abend (terminate) with a SYSTEM Error (S322).
Generally speaking zOS knows everthing regarding the execution of a step.
The number of SIO's (a measurement of DASD utilization), the allocated memeory, the used memeroy, lines printed, datasets accessed... All of these individual elements of "usage" comprise the "charges" to be applied to a departmental budget.
S322(s) are the bane of programmers on call.
Is it a run away execution or is the execution interacting with more than the usual amount of transactions / input records / complex resoultion of SQL verbs ?
The system / abend dump is more or less meaniless in determing the cause of a S322.
You may find this IBM URL illuminating :-) https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieag200/intro.htm
Ralph
Last edit: Ralph Linkletter 2020-08-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But, on the job accounting. Do COBOL programmers worry about job accounting, on a day to day basis? I don't mean at the gross level of obvious waste, or over the top trial sizing. In technical terms, any detailed planning on which BINDER arguments are included in JCL, or in which order during module and program build? Issues like locality of reference and/or page table optimizations. Is that a concern for COBOL programmers on a frame? A couple of the programmers in each team?
You bump into SFM pretty early on when exploring MVS 3.8j. There is an MF1 job collecting and reporing data every 15 minutes in a default Tk4- setup. A mild annoyance. You learn to /p mf1, or doing something like setting INTERVAL(5m) and STOP(10m) in SYS1.PARMLIB(IRBMF100), cuz yeah, that was easy to find. :-)
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Short answer: No programmers do not worry about job accounting codes. We usually have a specific code that we nearly always use, it may be for a project or specific person, usually it is at a group level , thus rarely changes.
Now as far as BINDER arguments, not sure what that is, but we do pay attention to execution optimiztion (cpu use, time, resources). We try to keep the cycles down because that is what IBM charges $$$. Example, we hardly ever write COBOL reports or control break reports; we use SyncSort (or IBM sort) because it is super effecient; SORT now days have Join statements and is really powerful, and is FAST !
The costs is one reason we have moved some systems off of the mainframe onto Linux servers using GnuCOBOL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As Mickey said most zOS installations use job accounting only as after the fact reporting.
That said, when leasing mainframe time, use of job accounting can be more scrutinous.
BINDER / LKED concerns are rare. Proc libs responsible for compilation and linking are very static. Routine if you will. Most of the compile and link proc lib source is maintained outside the purview of the application programmer.
Concern over paging is out of scope for the application programming staff.
Long running jobs (taking longer than expected) can be analyzed for efficiency.
Poor response time of CICS and IMS transactions (system loading ? SQL? IMS DB access?
The analysis is done primarily by utilities that can analyze mountains of SMF data. Of particular concern is DB2 and IMS DB optimization.
Rarely would COBOL code be investigated for efficiency.
DASD access would be more suspect than a review of code efficiency.
Xpeditor is the asset used to review and test code.
Is the program doing what it supposed to do ?
LOAD MODULE NOT FOUND -Abend S806
Is an example abend that will require analysis of the JCL.
Typically resolved by adding a concatenation to STEPLIB
OR a COBOL error in a call to a subroutine - spelling ?
The primary mission of the zOS application programmer is the application business logic.
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I spent the last 20 years of my career working on application performance tuning in an IBM Z/OS environment. Most often the goal was to reduce the chargeback costs, however there were occasions when we needed to reduce the runtime to meet service level agreements.
I would estimate that 80+ percent of our tuning efforts centered around DB2 SQL queries in COBOL programs. In our CICS regions we did quite a bit of caching in SHARED memory of DB2 data that was relatively static in nature. In these cases the cache searching techniques were critical to application performance. I found that a hand coded binary search was quite a bit more efficient than the SEARCH ALL verb. In fact when caching a VSAM file which was accessed in both batch and CICS, we found that since we were emulating the VSAM START command on a partial key, we could not use the SEARCH ALL verb as it would not find the next higher key if the search key did not exist. So we had to use a hand coded binary search. The performance improvement was evident even with Enterprise COBOL 4.2, with version 6.2 the performance of the binary search was much improved by the use of better optimized code for the higher ARCH levels.
So while I would agree that most of the time, the performance of the COBOL code is not a significant factor, the same is NOT true when it comes to relational database queries.
Also, given a choice of programmers to hire, I would always include an understanding and appreciation of performance as one of the factors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I spent the last 20 years of my career working on application performance tuning in an IBM Z/OS environment. Most often the goal was to reduce the chargeback costs,
...
:-)
But, but... Was this from a cubicle? Or the corner office? By that I mean, did all the programmers in those shops pay heed to the issues with day to day coding, or were the optimizations applied at the integration level, and only a few people on a project needed to think through the operating system technicals and deployment schemes?
I've gotten a sense from this thread that perhaps the best MVS -> GnuCOBOL jargon file would attempt to entirely gloss over sysadmin, sysprog, and operator roles.
That attempt would probably fail. ;-)
POSIX and GNU/Linux requires a bit of system administration and operations background when setting up for use as a development system.
I guess, a lot of core COBOL on a mainframe, the business logic angles, can remain fairly isolated from systems programming and operator roles. These issues are harder to gloss over with GnuCOBOL. There needs to be the odd reference to non-business programming areas of programming. I think. For anything beyond hello, world programming, that is.
It is pretty easy using the distro packages to get rolling with the release versions of GnuCOBOL. Setting up a more complete development node that has all the tools for building the compiler from source will require a level of comfort with system administration and a minimum set of things to know about GNU/Linux and POSIX.
"We have rat pie, rat pudding, rat cake, strawberry tart""Strawberry?""Well, it's got a little rat 'n it""A little?""Well, three"
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that using Hercules may have led you astray a wee bit in your understanding of zOS COBOL application programmers.
I suspect that a very very few zOS COBOL application programmers have ever been responsible for zOS IPL operations.
This is an axiom of your own creation, "entirely gloss over sysadmin, sysprog, and operator roles" where "roles" are those of a zOS application COBOL programmer.
Just to put zOS operation procedures in perspective.
Albeit a programmer can issue DISPLAY (upon console), virtually never would an ACCEPT (from console) be permitted.
Think lights out data centers or zOS data centers with 100's of operational personnel interacting with multiple console routings.
I would also think that ACCEPT (from console) is verboten with operation on network server farms.
I would make the focus of your efforts one that highlights the procedures necessary to substitute command files for JCL.
After attaining an operational understanding of zOS batch via Gnu the next mountain for the transitioning zOS COBOL programmer will be online (CICS, IMS).
Whereupon the notion of using vanilla GnuCOBOL more or less meets a formidable obstacle.
Perhaps batch is the limit for GnuCOBOL use.
Tearing apart BMS or MFS source and converting
EXEC CICS SEND /RECEIVE MAP to some granular curses equivalent is unlikely to succeed.
Micro Focus COBOL expended significant effort to accommodate the realities of zOS emulation. I do not think a crowd sourced development effort by volunteers can meet the requirements of zOS (other than COBOL alone) emulation / simulation on Windows or Linux.
Again the nagging question
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that using Hercules may have led you astray a wee bit in your understanding of zOS COBOL application programmers.
:-) Maybe, but I'm pretty sure my entire history with programming led to the headspace I live in. I've always felt the need to know the basics of the target OS. It didn't ever come to mind that programmers would ever think differently. Until recently. My programming roles have almost always come with operations side tasks. The few times in a team without sysadmin passwords, I usually just told the sysdamin what commands I would type if I had the password. I was only on mainframes for a few months way back when, but I read up on things before making requests or asking questions regarding the JCL models I was handed.
I suspect that a very very few zOS COBOL application programmers have ever been responsible for zOS IPL operations.
Which is probably by necessity, but still a little sad that the programmers didn't pick up a little system maintenance skills or background as part of being able to do the job properly. Oh well. MVS 3.8 and Hercules changes that a little bit. Programmers can not only read up on OS features, but can practise too. No excuses now. Learn some basics without risk.
I would make the focus of your efforts one that highlights the procedures necessary to substitute command files for JCL.
Yeah, that'll be one of the goals. A straight up checklist of items. The how, not so much the why. (Sad face). I'll be fighting my inner child writing to that audience. ;-)
Perhaps batch is the limit for GnuCOBOL use.
Doubtful. But it might make for a more approachable hello world discussion.
I do not think a crowd sourced development effort by volunteers can meet the requirements of zOS (other than COBOL alone) emulation / simulation on Windows or Linux.
I'll disagree with that sentiment. KICKS for CMS/TSO was a one man show. This is free software, Ralph. Just takes the right person(s) with the right itch(es) and humanity benefits.
I'd avoid spinning too many cycles on the nagging question about GnuCOBOL's role in the universe, Ralph. It has no set purpose beyond cross platform free software COBOL. Designed and developed to be a useful COBOL.
Potential areas of use are limited only by imagination, with huge piles of existing works to leverage. GnuCOBOL development could, but it is not a priority of this free software project to replace any operating environments or smash the cornerstones of commercial computing. At this point in time.
If it simply puts some downward pressure on lock-in COBOL usage licensing, then maybe that counts as a valid enough unintended purpose for GnuCOBOL?
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To provide 3270 like services it is required to:
Manage the keyboard - relate keyboard events to display presentation
Map BMS, IMS, or DMS forms to memory
Relate DMS, IMS, CICS memory mapping to Windows console buffer
Respond to function keys, keyboard navigation, text entry
Where approriate record key count per data field (CICS requirement)
Use CBL_xxxx_SCR routines to interact with Windows Console api(s)
Manage terminal send and receive as if a 3270 control unit
A list of the CBL routines (MF and Fujitsu) is at the end of this post
Several of the Fujitsu and Micro Focus CBL routines are not
implemented in GnuCOBOL.
Further, using GnuCOBOL, I have not had any success in implementing
the native Windows api(s) from which the the CBL routines are derived.
I think having access to the console handle(s) (via api) at .EXE
creation would make using the api(s) functional.
A wish list item for GnuCOBOL would be implementation of the
missing Micro Focus and Fujitsu CBL routines.
This is just a peek into the processing required to produce a CICS \ DMS
presentation in 3270 format.
It'd be worth looking through some of the 3270 support code in the Linux kernel. I've never looked until a few minutes ago, but I wonder how hard it would be to include /drivers/s390/char/3270 and perhaps /dev/dasd sources in a build for AMD64? Not sure how many dependencies on the /s390 trees the tub3270 loadable kernel module would require.
Quick grok, seems all the 3270 device needs is access to /dev/dasd, which may or may not mean that is a dead end on non s390 capable chips. I've not yet seen any inline assembly, all C code so far. There would be more rabbit holeing to find out if it would be worth exploring all the rabbit holes.
I haven't found any page that says Linux system 390 module sources only work with s390 hardware or emulators. Haven't found any page that says anything, actually. ;-)
And yes, we can round out the stock system library that ships with cobc --list-system. I'd peg that as an area of GnuCOBOL development that requires the least amount of compiler writer expertise. You just need to work to a single function call frame API in C.
Adding the link symbol so GnuCOBOL knows about a new built-in is one line of libcob/system.def, a header declaration source line, and the C implementation of the function. (Then tests, docs, translation strings, ..., but very little in terms of compiler writing, just some system programming). Examples from existing system service routines make adding wish list items like these, well within reach. A much expanded circle of programmers with relevant skills is available.
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Simon.
Was your initial question before the topic drift solved?
Yes.
I am still getting beaten with GNUcobol, but I am making some progress.
My only difficulty is to deal with this hundred configuration variables.
Gradually I am progressing with GNUcobol and Linux Ubuntu. But regarding GNUcobol and windows 10, I'm just getting beaten, for now.
Celso Henrique.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, Vince.
As a detail for instance. MVS 3.8 seems to run IKFCBL00 as the COBOL compiler, via COBUC, UCL, UCLG, etc. Is it ICGYW something something in z series now? Or do programmers talk like that? Is there macro names to fling aroung the water cooler like COBCLG? Then to relating (conflating?)
cobc -lto// LKED.LMOD DD ...Cheers,
Blue
Last edit: Brian Tiffin 2020-08-03
On 03/08/2020 09:13, Brian Tiffin wrote:
Just a question of finding out what the process tools are for CL or CLG
( compile, link and may be go)
Of course the level of Cobol differs subject to what one you are using
and IBM still don't support free formats :(
.
Vince
Ok. Smiley.
So, the goal is still to get to page 1 in terms of tone. I have near zero frame experience. A small stint in the early 1980s, and recent exploring of Hercules MVS 3.8j. Where do you want to start, Celso? I don't have the 50 years of in between that can spot right thinking from wrong thinking in terms of the jargon, terms of art and slang like I'd like this thread to start covering.
Explanation of POSIX process vs MVS job? Or nitty gritty, can skip some background, CALL to assembler or C issues? Start with linking PGM=IDCAMS type concepts to GnuCOBOL file system models?
One of the first things I can see with MVS is Job vs POSIX process. The frame doesn't start an executable inside any owned state. Fresh start each and every JOB card. The machine is the only parent in terms of JOB cards. I may be mistaken in that foundation of reasoning, and would appreciate a correction for anyone that knows more.
POSIX has the concept of the process tree. Machine starts PID 0 ?, then forks off to PID 1 (which may or not fork off other process ids and now does, many). PID 1 is systemd in 2020 GNU/Linux distros.
A process gets a pointer to a block of memory, the environment space, name=value pairs, concatenated togther and accessed via setenv putenv. And it has wrinkles.
The initial state of a POSIX process is an identical copy of the parent that forked it (you can think of it as spawning, but fork is only one step of a spawn, and super fast). Well, almost identical. The key OS process structure is updated and the current return code is in the state left by the fork, which is 0 when a child starts. The parent state is only different in the nano-seconds after a fork in the return code, which is the new child Process ID, PID. At point of
int pid = fork() <right here, the call frame at point of return from the fork function>.It is up to the child view (with a zero return code) to ask the system what its own process id is. The parent got the distinguishing copy of that value when the kernel finished the fork, so the child has to ask. Children may either wipe state and load an image, or simply continue on, relying on copy-on-write memory pages. A child only needs to allocate page memory if anyone in the tree touchs the page during the life of the process. Plus many many other details on low level Linux, above my pay grade.
Not much of that applies in MVS 3.8. You don't really have the process tree view of running tasks and jobs. When the frame starts a job card it pretty much starts clean, the state of the system kernel? what ever you call the running image after IPL in slang terms. (Asking) is configured for. SYS1.PARMLIB being loaded? - another term of art to nail down - comes to mind.
What is the street slang for that state in frame speak? And the verb (loaded?) that got it there.
The POSIX OS also provides each process an environment space. A pointer to an array of pointers to C zero terminated strings in NAME=VALUE form.
A child process can modify its own environment. It can not directly influence the environment of the parent. When a modification is made, any children of the chidren get the intermediate changed view of a starting environment, and again cannot modify the parent process environment state. DIrectly. The parent might be nice enough to be listening to signals from children (or a socket) and go out of its way to update its view of the environment. There are very good reasons to never do this. :-)
GnuCOBOL makes fairly extensive use of the POSIX environment. Rich in details. There is a list of some of them in the FAQ, but that list is sorely out of date with trunk.
The view of the environment is also at the mercy of some GNU/Linux distribution decisions, and the ever changing (usually slowly at the libc ABI level, but a layer up and things start to drift and shift). Default search paths for dynamic linking and symbol lookup, (dlopen and dlsym) can vary. Default dead code elimination by the link edit phase (in terms of the default search
rpathorLD_RUN_PATHas set at compile time) is another shift we may have to keep up with.I mentioned that last one, as if can effect the
-L and -loptions used in acobcinvocation. Lots of things effect the run-time effect of the-L and -loptions used in a cobc compile. Details we can dig up and hopefully explain properly.Then Windows adds another layer of complication, but we won't go there for the now, Celso. Sound cool?
More as we go. Did any of the above make sense, Celso? et al? Is that suitable for page 1 in a how to configure make for framers thread?
Have good, make well,
Blue
Last edit: Brian Tiffin 2020-08-03
Dear friends.
I don't think I was able to explain correctly about mainframe cobol and gnucobol. The cobol language I learned was mainframe cobol and I am now switching to GNUcobol. I'm having some difficulties but I'm gradually overcoming. I've done many examples of GNUcobol that worked correctly. And I managed to understand its logic and operation. But I am completely outraged at myself for not being able to solve this example of gnucobol:
https://github.com/opensourcecobol/Open-COBOL-ESQL
https://github.com/opensourcecobol/Open-COBOL-ESQL/tree/develop/sample
INSERTTBL.cbl
FETCHTBL.cbl
You have already given me many tips on how to program correctly in GNUcobol. All of these tips helped me understand how the GNUcobol cobol language works.
Celso Henrique.
That's a major part of the questions I've been asking, Celso. To find common speak to ensure understanding on both sides.
I'm trying to avoid handing you a fish at this point, Celso. Learning to fish being the goal. I'd like to end this thread with you solving the run-time symbol lookups for your setup. To a level to know where to look if the issue ever arises again with a different combination of program components.
I'll reiterate at this point. Anyone that can handle the technical details and jargon surrounding mainframes, can handle POSIX. For the most part, just a different knowledge base. There are a few core foundational concept differences, but even those are well within the same brainspace. I'd like to find the right words to describe the relationships in a meaningful way.
Given that, Celso, I'm still flailing a little.
When you programmed on the mainframe, did you ever have to pay heed to the details of the
or
JCL statements? Or was it always site local boiler plate for the EXEC cards?
Cheers,
Blue
Dear Brian Tiffin
I know Mainframe cobol is a soup of letters, such the amount of applications that comes with it.
Celso Henrique
:-)
I'd like to try and change that alphabet soup impression a little, Celso. Removing a layer of nebulous can aid in understanding.
Yes, MVS is a detail rich operating environment. So is POSIX. So is Windows.
Yes MVS is still kinda stuck in upper case short names, but the encodings all have a root and usually an attempt at a mnemonic or acronym.
IEB, utilities
IEBDG, utility, data generation
IEF, code modules,
IEFBR14, code module, named for the primary assembler instruction, branch thru register 14
IDC, Integrated Data Clusters, and the famous IDCAMS, which I pronounce as eye-dee-cams, but the acroynm is AMS access method services.
And on and on into the hundreds. But they all actually mean something. Some just become slang. DASD, Direct Access Storage Device, but you don't even need the acronym, everyone knows what everyone means when they say dazz-dee.
Building up a jargon file for GnuCOBOL for mainframers might have to slip into historical slang, but the hope is that the meaning conveyed is the meaning meant. Sans cargo culting. If there has to be some background definitions, then the attempt will be made to make those understandable from both points of view, too.
Common words like prefix can have a fairly disjoint meaning in casual conversation, sometimes similar but not always. At my current level of MVS misunderstanding, prefix implies the High Level Qualifier in a data set name. SYS1. or UserID.. In POSIX circles (in particular with GNU and autoconf) prefix (without other context) is the top level portion of a full path, as it applies to build and installation, /usr/ or /usr/local, for instance.
No one needs to remember all the words in the acronym and mnemonic soup though, there are reference lists and hidden gems of documentation. Einstein put it well
IBM does a much better job, with quantities of reference material. POSIX less so.
I'd put IBM firmly in the top contenders for king of computing reference books; so many acronymns to explain. But they are explained, all of them. And usually thought out and chosen on purpose, not by random picks from a Scrabble bag.
IBM makes finding IEFBR14 docs pretty easy. Knowing why to use IEFBR14 is knowing the conventions and the slow build up of knowledgebase.
Then, information overload. Thats when a mental swap from tree to forest can help. With too many details, aim for getting a gist of things, then gloss over. Our subconscious is running so many background tasks and summary overnight runs that enough quick grok exposers to an information pile, makes finding things in that information easier and easier.
I'm really starting to drift and ramble...
There is a skill, determining the gender of chicken chicks. A fairly subtle skill it seems. When attempting to train new chick sexers, the experts were asked how they made the call. After some efforts, the experts had to admit that they could not explain it in prose. They just "knew". Trainees are told to just guess, male/female, then hand the chick to an expert. The expert reports back with a Right/Wrong. This is repeated, for all the chicks in the incubators. (I'm making up numbers). 50/50 right wrong on day 1. 58/42 right wrong on day two. 77/33 right wrong on day 3. End of the week, the trainees are correct far more often than incorrect, and approaching expert. And they can't explain how they do it. They just "know". By repetition and not wanting to be told they were wrong.
A side moral of that side-trek is that quick looks at alien data piles can make it less and less alien over time. Assuming there is some feedback regarding on track or completely off the rails when guessing at what you are seeing.
Long post to just say that the alphabet soup offered up by IBM shouldn't be treated as random. Focus on some trees, the forest starts to make sense.
POSIX is worse off in terms of locality of reference material. There are lots of documents, and they are everywhere, not just in a Red bookshelf. Even with less acronym soup words, getting the required hints and chance to grok POSIX can sometimes be harder.
mv? Oh, move.ls? list sorted? ell ess? Why? Call it list directory and add an alias... But no, gotta knowls. Andgrep, the global regex print. Gahh!They kinda got it right with AWK, at least that acronymn is just names of people. :-)
Alien.
Until the day it just makes sense. Experts would be hard pressed to explain it in prose. it just makes sense. Sadly, those same POSIX experts have to remember where too many reference books are, which hurts the overall learning curve for beginning, intermediate, and top levels.
On the frame, I'd imagine the curves from beginner to intermediate and intermediate to expert follow fairly predictable paths. Less so in POSIX. The freeness of the software combinations makes it exponentially harder to document in a unified manner. So, fragmentation abounds.
And I'm sensing we are getting closer to being able to chat our way to a GnuCOBOL/MVS jargon file, with a focus on tectonics for building and using GnuCOBOL, In particular, POSIX static and dynamic link loader issues as compared to mainframe job steps.
Ok, one more common term request for everyone. Link Loader. LKED in DD statement speak. I think that relationship holds? Link Loader/Link Editor? Can we use those terms interchangeably in an MVS/POSIX COBOL jargon file? Phrases that everyone just knows are the actions of resolving symbols and labels in pre and post-loaded object machine code, destined for virtualized memory, managed by highly sophisticated paging tables.
Sub request; how do you differentiate between static link at compile time and dynamic load-link at run-time while in mainframe shop watercooler discussions? The casual word(s) that a co-worker just knows what you mean. I'm hoping that static and dynamic will do, but I haven't seen many references to static in MVS docs.
Do COBOL programmers have to care about the distinction on the frame, or is it the change once in a blue moon boiler plate and edit small DSN details kinda thing?
Ok, 'nother point of curiosity;
I'd be interested to hear if cost-codes might ever come into play with JCL decisions. Are any usage fees rated by type of compute. or OS features exercised? Would any of these charge issues effect how a COBOL programmer writes compile, link or run JCL? Would those decisions ever run counter to best design / module layout optimization decisions?
Cheers,
Blue
Ok, one more common term request for everyone. Link Loader. LKED in DD statement speak. I think that relationship holds? Link Loader/Link Editor? Can we use those terms interchangeably in an MVS/POSIX COBOL jargon file? Phrases that everyone just knows are the actions of resolving symbols and labels in pre and post-loaded object machine code, destined for virtualized memory, managed by highly sophisticated paging tables.
The "new nomenclature" for LKED is BINDER
Binder still executes IEWL (linker)
EXEC PGM=IEWL,PARM='XREF,LIST', IEWL is alias of IEWBLINK
Most would still use "LINK / LINKER" as jargon.
Sub request; how do you differentiate between static link at compile time and dynamic load-link at run-time while in mainframe shop watercooler discussions? The casual word(s) that a co-worker just knows what you mean. I'm hoping that static and dynamic will do, but I haven't seen many references to static in MVS docs.
Almost all zOS subroutines are called dynmically. That is that subroutines are cataloged as RECFM=U in a PDS / PDSE (a "load module" would be the jargon)
Do COBOL programmers have to care about the distinction on the frame, or is it the change once in a blue moon boiler plate and edit small DSN details kinda thing?
Subsystems like MQ, or IMS require entry point resolution. However most zOS installations will have explicit proc lib members to compile and link various subsystem programs.
Ok, 'nother point of curiosity;
I'd be interested to hear if cost-codes might ever come into play with JCL decisions. Are any usage fees rated by type of compute. or OS features exercised? Would any of these charge issues effect how a COBOL programmer writes compile, link or run JCL? Would those decisions ever run counter to best design / module layout optimization decisions?
I think you are speaking of job accouting.
One of the parameters of the job statement can indicate the charge back department budget wise for SMF (System Management Facility) resources consumed during execution of a job stream.
To prevent run away execution another operand of the job statement is TIME=nnnn.
If the execution of an application consumes more CPU time that allotted via the TIME=parameter the job will abend (terminate) with a SYSTEM Error (S322).
Generally speaking zOS knows everthing regarding the execution of a step.
The number of SIO's (a measurement of DASD utilization), the allocated memeory, the used memeroy, lines printed, datasets accessed... All of these individual elements of "usage" comprise the "charges" to be applied to a departmental budget.
S322(s) are the bane of programmers on call.
Is it a run away execution or is the execution interacting with more than the usual amount of transactions / input records / complex resoultion of SQL verbs ?
The system / abend dump is more or less meaniless in determing the cause of a S322.
You may find this IBM URL illuminating :-)
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieag200/intro.htm
Ralph
Last edit: Ralph Linkletter 2020-08-05
Thanks, Ralph.
But, on the job accounting. Do COBOL programmers worry about job accounting, on a day to day basis? I don't mean at the gross level of obvious waste, or over the top trial sizing. In technical terms, any detailed planning on which BINDER arguments are included in JCL, or in which order during module and program build? Issues like locality of reference and/or page table optimizations. Is that a concern for COBOL programmers on a frame? A couple of the programmers in each team?
You bump into SFM pretty early on when exploring MVS 3.8j. There is an MF1 job collecting and reporing data every 15 minutes in a default Tk4- setup. A mild annoyance. You learn to
/p mf1, or doing something like settingINTERVAL(5m)andSTOP(10m)in SYS1.PARMLIB(IRBMF100), cuz yeah, that was easy to find. :-)Cheers,
Blue
Short answer: No programmers do not worry about job accounting codes. We usually have a specific code that we nearly always use, it may be for a project or specific person, usually it is at a group level , thus rarely changes.
Now as far as BINDER arguments, not sure what that is, but we do pay attention to execution optimiztion (cpu use, time, resources). We try to keep the cycles down because that is what IBM charges $$$. Example, we hardly ever write COBOL reports or control break reports; we use SyncSort (or IBM sort) because it is super effecient; SORT now days have Join statements and is really powerful, and is FAST !
The costs is one reason we have moved some systems off of the mainframe onto Linux servers using GnuCOBOL.
As Mickey said most zOS installations use job accounting only as after the fact reporting.
That said, when leasing mainframe time, use of job accounting can be more scrutinous.
BINDER / LKED concerns are rare. Proc libs responsible for compilation and linking are very static. Routine if you will. Most of the compile and link proc lib source is maintained outside the purview of the application programmer.
Concern over paging is out of scope for the application programming staff.
Long running jobs (taking longer than expected) can be analyzed for efficiency.
Poor response time of CICS and IMS transactions (system loading ? SQL? IMS DB access?
The analysis is done primarily by utilities that can analyze mountains of SMF data. Of particular concern is DB2 and IMS DB optimization.
Rarely would COBOL code be investigated for efficiency.
DASD access would be more suspect than a review of code efficiency.
Xpeditor is the asset used to review and test code.
Is the program doing what it supposed to do ?
LOAD MODULE NOT FOUND -Abend S806
Is an example abend that will require analysis of the JCL.
Typically resolved by adding a concatenation to STEPLIB
OR a COBOL error in a call to a subroutine - spelling ?
The primary mission of the zOS application programmer is the application business logic.
Ralph
Ralph,
I spent the last 20 years of my career working on application performance tuning in an IBM Z/OS environment. Most often the goal was to reduce the chargeback costs, however there were occasions when we needed to reduce the runtime to meet service level agreements.
I would estimate that 80+ percent of our tuning efforts centered around DB2 SQL queries in COBOL programs. In our CICS regions we did quite a bit of caching in SHARED memory of DB2 data that was relatively static in nature. In these cases the cache searching techniques were critical to application performance. I found that a hand coded binary search was quite a bit more efficient than the SEARCH ALL verb. In fact when caching a VSAM file which was accessed in both batch and CICS, we found that since we were emulating the VSAM START command on a partial key, we could not use the SEARCH ALL verb as it would not find the next higher key if the search key did not exist. So we had to use a hand coded binary search. The performance improvement was evident even with Enterprise COBOL 4.2, with version 6.2 the performance of the binary search was much improved by the use of better optimized code for the higher ARCH levels.
So while I would agree that most of the time, the performance of the COBOL code is not a significant factor, the same is NOT true when it comes to relational database queries.
Also, given a choice of programmers to hire, I would always include an understanding and appreciation of performance as one of the factors.
:-)
But, but... Was this from a cubicle? Or the corner office? By that I mean, did all the programmers in those shops pay heed to the issues with day to day coding, or were the optimizations applied at the integration level, and only a few people on a project needed to think through the operating system technicals and deployment schemes?
I've gotten a sense from this thread that perhaps the best MVS -> GnuCOBOL jargon file would attempt to entirely gloss over sysadmin, sysprog, and operator roles.
That attempt would probably fail. ;-)
POSIX and GNU/Linux requires a bit of system administration and operations background when setting up for use as a development system.
I guess, a lot of core COBOL on a mainframe, the business logic angles, can remain fairly isolated from systems programming and operator roles. These issues are harder to gloss over with GnuCOBOL. There needs to be the odd reference to non-business programming areas of programming. I think. For anything beyond hello, world programming, that is.
It is pretty easy using the distro packages to get rolling with the release versions of GnuCOBOL. Setting up a more complete development node that has all the tools for building the compiler from source will require a level of comfort with system administration and a minimum set of things to know about GNU/Linux and POSIX.
Cheers,
Blue
I think that using Hercules may have led you astray a wee bit in your understanding of zOS COBOL application programmers.
I suspect that a very very few zOS COBOL application programmers have ever been responsible for zOS IPL operations.
This is an axiom of your own creation, "entirely gloss over sysadmin, sysprog, and operator roles" where "roles" are those of a zOS application COBOL programmer.
Just to put zOS operation procedures in perspective.
Albeit a programmer can issue DISPLAY (upon console), virtually never would an ACCEPT (from console) be permitted.
Think lights out data centers or zOS data centers with 100's of operational personnel interacting with multiple console routings.
I would also think that ACCEPT (from console) is verboten with operation on network server farms.
I would make the focus of your efforts one that highlights the procedures necessary to substitute command files for JCL.
After attaining an operational understanding of zOS batch via Gnu the next mountain for the transitioning zOS COBOL programmer will be online (CICS, IMS).
Whereupon the notion of using vanilla GnuCOBOL more or less meets a formidable obstacle.
Perhaps batch is the limit for GnuCOBOL use.
Tearing apart BMS or MFS source and converting
EXEC CICS SEND /RECEIVE MAP to some granular curses equivalent is unlikely to succeed.
Micro Focus COBOL expended significant effort to accommodate the realities of zOS emulation. I do not think a crowd sourced development effort by volunteers can meet the requirements of zOS (other than COBOL alone) emulation / simulation on Windows or Linux.
Again the nagging question
Ralph
:-) Maybe, but I'm pretty sure my entire history with programming led to the headspace I live in. I've always felt the need to know the basics of the target OS. It didn't ever come to mind that programmers would ever think differently. Until recently. My programming roles have almost always come with operations side tasks. The few times in a team without sysadmin passwords, I usually just told the sysdamin what commands I would type if I had the password. I was only on mainframes for a few months way back when, but I read up on things before making requests or asking questions regarding the JCL models I was handed.
Which is probably by necessity, but still a little sad that the programmers didn't pick up a little system maintenance skills or background as part of being able to do the job properly. Oh well. MVS 3.8 and Hercules changes that a little bit. Programmers can not only read up on OS features, but can practise too. No excuses now. Learn some basics without risk.
Yeah, that'll be one of the goals. A straight up checklist of items. The how, not so much the why. (Sad face). I'll be fighting my inner child writing to that audience. ;-)
Doubtful. But it might make for a more approachable hello world discussion.
I'll disagree with that sentiment. KICKS for CMS/TSO was a one man show. This is free software, Ralph. Just takes the right person(s) with the right itch(es) and humanity benefits.
Sadly it seems Mike Noel has given up on KICKS, seeing the mainframe as a dead horse as of the mid 2010s. http://kicksfortso.com/same/kicks-progress.htm
I'll disagree with that sentiment as well. :-)
I'd avoid spinning too many cycles on the nagging question about GnuCOBOL's role in the universe, Ralph. It has no set purpose beyond cross platform free software COBOL. Designed and developed to be a useful COBOL.
Potential areas of use are limited only by imagination, with huge piles of existing works to leverage. GnuCOBOL development could, but it is not a priority of this free software project to replace any operating environments or smash the cornerstones of commercial computing. At this point in time.
If it simply puts some downward pressure on lock-in COBOL usage licensing, then maybe that counts as a valid enough unintended purpose for GnuCOBOL?
Cheers,
Blue
To provide 3270 like services it is required to:
Manage the keyboard - relate keyboard events to display presentation
Map BMS, IMS, or DMS forms to memory
Relate DMS, IMS, CICS memory mapping to Windows console buffer
Respond to function keys, keyboard navigation, text entry
Where approriate record key count per data field (CICS requirement)
Use CBL_xxxx_SCR routines to interact with Windows Console api(s)
Manage terminal send and receive as if a 3270 control unit
A list of the CBL routines (MF and Fujitsu) is at the end of this post
Several of the Fujitsu and Micro Focus CBL routines are not
implemented in GnuCOBOL.
Further, using GnuCOBOL, I have not had any success in implementing
the native Windows api(s) from which the the CBL routines are derived.
I think having access to the console handle(s) (via api) at .EXE
creation would make using the api(s) functional.
A wish list item for GnuCOBOL would be implementation of the
missing Micro Focus and Fujitsu CBL routines.
This is just a peek into the processing required to produce a CICS \ DMS
presentation in 3270 format.
CBL Routines
Ralph
Last edit: Ralph Linkletter 2020-08-04
It'd be worth looking through some of the 3270 support code in the Linux kernel. I've never looked until a few minutes ago, but I wonder how hard it would be to include /drivers/s390/char/3270 and perhaps /dev/dasd sources in a build for AMD64? Not sure how many dependencies on the /s390 trees the tub3270 loadable kernel module would require.
Quick grok, seems all the 3270 device needs is access to /dev/dasd, which may or may not mean that is a dead end on non s390 capable chips. I've not yet seen any inline assembly, all C code so far. There would be more rabbit holeing to find out if it would be worth exploring all the rabbit holes.
I haven't found any page that says Linux system 390 module sources only work with s390 hardware or emulators. Haven't found any page that says anything, actually. ;-)
And yes, we can round out the stock system library that ships with
cobc --list-system. I'd peg that as an area of GnuCOBOL development that requires the least amount of compiler writer expertise. You just need to work to a single function call frame API in C.Adding the link symbol so GnuCOBOL knows about a new built-in is one line of libcob/system.def, a header declaration source line, and the C implementation of the function. (Then tests, docs, translation strings, ..., but very little in terms of compiler writing, just some system programming). Examples from existing system service routines make adding wish list items like these, well within reach. A much expanded circle of programmers with relevant skills is available.
Cheers,
Blue
So @btiffin can you give some of those stock library functions a try, co-working with whomever you see available?
@celsofigueiredo sadly this disussion board does not allow a split of a topic. Was your initial question before the topic drift solved?
Dear Simon.
Was your initial question before the topic drift solved?
Yes.
I am still getting beaten with GNUcobol, but I am making some progress.
My only difficulty is to deal with this hundred configuration variables.
Gradually I am progressing with GNUcobol and Linux Ubuntu. But regarding GNUcobol and windows 10, I'm just getting beaten, for now.
Celso Henrique.