Ralph Linkletter

I would think this an interesting project. However as I imagine the interface from my File-AID experiences and comparing it to the GnuCOBOL user forum. There is by necessity a penchant with GnuCOBOL users that demands an accept numeric dialog and validating and storing various form of edited usage display data fields. This infers that I would never entertain doing a DFED (Data File Editor). When I read posts from Simon extolling features in GC4 that will not be available in GC3 I get a wee bit upset....

Can you document how it was implemented on your side please. SYMORG or SYMNAMES ? If in the TAKEFILE what syntax is required in supporting symbols The new record counter is impleneted with ? Please advise, Thanks Bruce

This is my take on what I read in the GCC COBOL manual. My concern is that of maintaining data / numeric integrity. The scope must embrace integrity beyond computational criteria. Comparative expressions and assignment expressions are also within the scope of numeric integrity. A conditional expression interacting with erroneous numeric data will branch erroneously Regardless of committee based edicts (ISO, ANSI, POSIX, whatever) logic must prevail. Permitting the creation and perpetuation of inaccurate...

This is my take on what I read in the GCC COBOL manual. My concern is that of maintaining data / numeric integrity. The scope must embrace integrity beyond computational criteria. Comparative expressions and assignment expressions are also within the scope of numeric integrity. A conditional expression interacting with erroneous numeric data will branch erroneously Regardless of committee based edicts (ISO, ANSI, POSIX, whatever) logic must prevail. Permitting the creation and perpetuation of inaccurate...

I understand the SYMBOLS integration. Hey while you are in the source code can you add a counter to the audit file. Records omitted or included. This is what I produced from my DFSORT emulation. Thank you for the feedback ! Bruce +++ DFSORT Processed RECORDS IN=: 262 +++ DFSORT Processed RECORDS OUT=: 74 +++ DFSORT Processed OMIT/INCLUDE=: 188 <========= ** WINZOS JOB LOG Copyright 2010-2025 Metamorphous Company LLC ** JOB: AY2SORT JOB NUMBER: 0409 DATE: 08/24/26 TIME: 11:50:37 1 //AY2SORT JOB 'WINZOS-SORT',CLASS=A,MSGCLASS=A...

Are you planning to use the takefile for specifying the SYMBOLS ? SYMBOLS ORDERNUM,1,6,CH USE C:\WINZOS\DATA\SORTIN03.DAT RECORD F,00400 ORG SQ USE C:\WINZOS\DATA\SORTIN02.DAT RECORD F,00400 ORG SQ USE C:\WINZOS\DATA\SORTIN01.DAT RECORD F,00400 ORG SQ GIVE C:\WINZOS\ZOSICF\S2121566.DAT RECORD F,00400 ORG SQ OPTION MODS E15=(TESTAE15) SORT FIELDS=(ORDERNUM,A) OMIT COND=(3,1,CH,EQ,C'1') That actually seems as if would fit in easily - would it not ? Are there other operands that precede the USE clause(s)...

Your goal is to get rid of MS permantly which I have done ? I thought you were building a COBOL educational project ? I think you will find that Windows and a 3270 terminal emulator own the zOS COBOL world. Look at the job listings for COBOL programmers. Virtually all want zOS COBOL experience. Not Mac - Not Linux. Your previous post indicated a project to educate newbies to COBOL. "Making a Noob to GnuCOBOL and developing in COBOL based on the fact that so many young people have considered or ARE...

The many companies that are looking for COBOL programmers are mainframe IBM zOS companies that routinely use COBOL for business applications. 95%+ of COBOL programmers are in these zOS accounts - this is where the market for COBOL skills resides. If you want newbies to acquire marketable skills then TK5 or WINZOS are a much better vehicle to appeal to newbies. COBOL without a zOS ecosystem is merely COBOL. Practical professional use of COBOL takes place not in Linux but in zOS accounts across the...