I have a text file that has zoned value with sign in it,like below:
000033} -> value: -330
000298} ->value: -2980
when I sort it in ascending,I can't get what I want below:
000398}
000033}
Does GCSORT support sort zoned value with sign in it?
Kind regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you provide more data - what actual command and format did you specify - then someone familiar with GCSORT may be able to help you. If you don't specify any format the tool can only sort by standard collation (so x'00' through x'FF').
It would be definitely good to tweak GCSORT with GC4 options as this can provide a data dictionary for any file, allowing GCSORT to know the format if the data dictionary for that file is available.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-07-29
Thanks for reply.
I use the command below.
/opt/batch/RUNTIME/bin/gcsort sort fields"(1,10,ZD,A)" use sortin.txt record f,10 org ls give sortout.txt record f,10 org ls
I want attachment the data file but it was rejected so I paste it below.
<sortin.txt>
000000033}
000000298}
000000033A
000000298B
000000033J
000000298K</sortin.txt>
The DATA is formatted with Sign for Zone-Decimal, Modified.
You can find what it is in http://www.simotime.com/datazd01.htm.
It seems GCSORT cannot handle data like this.
But GnuCOBOL can handle it when I use the compile option "-fsign=EBCDIC".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Modified the GCSORT module with the insertion of the option -fsign = EBCDIC they can be used for files with ZONED fields and EBCDIC sign.
New command line:
opt / batch / RUNTIME / bin / gcsort -fsign=EBCDIC sort fields "(1,10, ZD, A)" use sortin.txt record f, 10 org ls give sortout.txt record f, 10 org ls
Now the result is as expected.
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Had a wee bit of a problem with "gcsort option -fsign="
Solved it by inferring what was meant in the --help option
This is the proper method to implement -fsign=
GCSORT -fsign=EBCDIC TAKE C:\IBZANIM\GNUDATA\TAKEFILE.TXT
It might be helpful to provide a sample command line invocation within --help output
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-10-16
Question ?
Is there any chance someone could build a .EXE for GCSORT. The .exe folder is empty.
There is updated source, but for those of us not steeped in "C" and / or Linux, GCSORT is not readily available.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have no clue if this is enough but I've created the following file from the current GCSORT sources using Arnold's GC 3.1.2 MinGW build + make from MSYS:
If you use a build from Arnold you can try to copy that to its "bin" folder and check.
GCSORT.EXE via Arnold's 32 bit builds
"The program can't start because libcob.dll is missing"
I presume that libcob-4.dll is the actual name of the data set being referenced - correct ?
Even though the path contains the drive and directory as to where libcob-4 resides the error (above) is still issued (it resides in C:\IBZANIM\WINGNU\BIN)
It appears that successful execution requires that the current directory be the directory that contains libcob-4.dll. Correct ?
Creating a GCSORT directory that contains libcob-4.dll and gcsort.exe does not work either. Adding set path=%path%;c:\ibzanim\wingnu\bin; enabled gcsort to execute.
Seems odd that gcsort.exe requires libcob-4.dll to be in the current directory.
I did as you stated.
I have a long path environment variable.
\IBZANIM\WINGNU\BIN is in the path. \IBZANIM\WINGNU is your built
directory structure- merely renamed and isolated from the default
directory structure
However cobc is functional with the path as indicated below
c:\winedit>path
gcsort. Nothing to do.
Usage: gcsort <option>
Execute command
or : gcsort TAKE <filename params="">
Read and execute command from filename params
or : gcsort --help
Print help
or : gcsort --version
Print version information
or : gcsort --config
Print values of environment variables</filename></option>
I guess I can change my .BAT files to include your directory first (renamed from your default).
How close to DFSORT are the GCSORT sort parameters ?
Ralph
On 4/14/2021 10:28 PM, Arnold Trembley wrote:
Did you copy the "gcsort.exe" file into the same "\bin" folder where "cobc.exe", "cobcrun.exe", and "coblib-4.dll" reside?
The compiler's \bin folder should be in your windows PATH already.
It's possible that building gcsort.exe using mingw make has some artifacts of the Linux directory structure that cause this problem. I've been told that moving Linux programs to different folders is not as simple as in Windows.
I have not actually used gcsort, but based on the examples I've read, it is an attempt to create a clone of DFSORT for GnuCOBOL. So it should work like DFSORT, but of course there is still the issue of ASCII versus EBCDIC and the issue of no OS support for structured files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Usage with file parameters : gcsort <options> take filename
Usage from command line : gcsort <options> <control statements=""></control></options></options>
gcsort control statements
Notations: '{name}' = parameters , '|' = Alternative format of control statement
SORT | MERGE FIELDS Control statement for Sort or Merge file(s)
USE Declare input file(s)
GIVE Declare output file [ SUM FIELDS ] Sum fields for same record key, or eliminate duplicate keys) [ INCLUDE ] Select input records that respect include condition(s) [ OMIT ] Omit input records that respect include condition(s) [ INREC ] Reformat input record Before sort, merge or copy operation [ OUTREC ] Reformat input record After sort, merge or copy operation [ OUTFIL ] Create one or more output files for sort,merge or copy operation [ OPTION ] Specifies option for control statements
{Parameters}____|____
{FileName} = Filename or Env. Variable | EQ = Equal
{Pos} = Field Position | GT = GreaterThan
{Len} = Field Length | GE = GreaterEqual
{RecordLen}= Record Length | LT = LesserThan
{MinLen} = Min size of record | LE = LesserEqual
{MaxLen} = Max size of record | NE = NotEqual
{Order} = A(ascending) | D(descending)| SS = SubString (only for Field Type 'CH') ______|______ {Condition}__________
Format 1 - (Pos,Len,{FormatType},{Relational},[AND|OR],Pos,Len,{FormatType})
Format 2 - (Pos,Len,{FormatType},{Relational},[X|C'[value]'] | numeric value)]
Format 3 - ( {Condition} ,[AND|OR],{Condition} ) _____________ File Organization__|_Mandatory for ORG = IX
LS = Line Sequential | P = Primary Key
SQ = Sequential Fixed or Variable | A = Alternative Key
IX = Indexed Fixed or Variable | D = Alternative Key with Duplicates
RL = Relative Fixed or Variable | C = Continue definition ______|______ _Field Format Type_|{FormatType2}_Format Type SumField
CH = Char | BI = Binary unsigned
BI = Binary unsigned | FI = Binary signed
FI = Binary signed | FL = Floating Point
FL = Floating Point | PD = Packed
PD = Packed | ZD = Zoned
ZD = Zoned | CLO = Numeric sign leading
CLO = Numeric sign leading | CSL = Numeric sign leading separate
CSL = Numeric sign leading separate | CST = Numeric sign trailing separate
CST = Numeric sign trailing separate | ______|______ _{FieldSpec}Field Specification_______
pos, len pos = position input record, len = length of field
posOut:pos,len posOut = position output, pos = position input , len = length
n:X Filling with Blank character from last position to n
(absolute position of output record).
n:Z Filling with zero Binary character from last position to n
(absoluteposition of output record).
C'constant' constant character value.
nC'constant' repeat n times constant character value.
nX repeat n times Blank character.
nZ repeat n times Binary (0x00) character.
X'hh....hh' hexdecimal characters.
nX'hh...hh' repeat n times hexdecimal characters. _____________
Environment Variables ____________
COB_VARSEQ_FORMAT Used by GnuCOBOL
GCSORT_DEBUG 0 no print info, 1 info DEBUG, 2 for info Parser
GCSORT_MEMSIZE Memory Allocation in byte (Default 512000000 byte)
GCSORT_PATHTMP Pathname for temporary files (Default TMP / TEMP / TMPDIR)
GCSORT_STATISTICS 0 minimal informations, 1 for Summary, 2 for Details
GCSORT_TESTCMD 0 for normal operations , 1 for ONLY test command line (NO SORT) ________________
Sauro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To add to this: if someone is missing a function then we already have a wish-list item for that: [feature-requests:#400] to check / add to / say "yes, I need xyz".
There are a couple things that would help GCSORT be a wee bit more useful in zOS applications.
Support for the Y2K date formats and two exits.
A "Record At A Time " methodology defines the E15 / E35 interaction.
See: https://www.ibm.com/docs/en/zos/2.1.0?topic=exits-dfsort-inputuser-exitoutput-logic-examples
The two common and important exits are referred to as E15 and E35 (sometimes E37).
They are actually rather simple to implement.
An E15 exit makes an application subroutine responsible for the "USING" file processing
An E35 exit makes an application subroutine responsible for the "GIVING" file processing
One of the exits require that the subroutine(s) supply the sort control cards
The basic process of E15 reads an input record record and passes the record to sort.
E15 signifies end of input by passing a return code 8 to the sort.
At conclusion of the E15 process - the sorting phase begins
The basic process of E35 is it accepts a record from sort after the sort phase is complete.
E35 passes the records back to the exit one record at a time until end of output - return code 8.
At conclusion of the E35 process the sort has ended
Legacy application are more than likely to still use 2 character YY fields for date fields.
Especially if the Y2K solution was deployed using a "sliding or fixed window" paradigm.
DFSORT will also infer the full YYYY with the Y2? sort field implementation.
These are the common DFSORT definitions of date fields requiring that SORT infer the full YYYY.
Y2C 2 bytes Two-digit character or zoned-decimal year data
Y2P 2 bytes Two-digit packed-decimal year data
Y2D 1 byte Two-digit decimal year data
Y2B 1 byte Two-digit binary year data
Y2Z 2 bytes Two-digit character or zoned-decimal year data
There are some other values where "special indicators" are needed
I have several COBOL programs that implement RAAT to various SORT vendors. I will glady share the source if needed.
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do agree with Ralph, the Exit routines may be handy and would allow the cobol programs that are used to be the same on Zos transfered to gnucobo, withoug much change. However...
We use Syncsort on the mainframe (and it is near about the same as DFsort), and the only reason we even used it and exit programs is because on Zos, nothing we found is as fast as the I/O for SyncSort. ( You can get SyncSort for Linux, but $$$...)
Really we had a program that read Very Large data files on the Mainframe and did some calculations and reformatiing, and it about 6 hours. When we changed it to and external SysnSort (with exits) for the small cobol part, it ran in under an hour.
And in Zos JCL we did try useing differnt buffers and such (like we do for Vsam sort of ) but the SyncSort was the best way to go..
Not to mention the Join statements and control breaks for SyncSort, ... we never wrote cobol report or small data reformat programs, we did it in external SyncSort...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a text file that has zoned value with sign in it,like below:
000033} -> value: -330
000298} ->value: -2980
when I sort it in ascending,I can't get what I want below:
000398}
000033}
Does GCSORT support sort zoned value with sign in it?
Kind regards,
The GCSORT teadme, also online available at https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/GCSORT mentions zoned-decimal, therefore I guess it should work.
If you provide more data - what actual command and format did you specify - then someone familiar with GCSORT may be able to help you. If you don't specify any format the tool can only sort by standard collation (so x'00' through x'FF').
It would be definitely good to tweak GCSORT with GC4 options as this can provide a data dictionary for any file, allowing GCSORT to know the format if the data dictionary for that file is available.
Thanks for reply.
I use the command below.
/opt/batch/RUNTIME/bin/gcsort sort fields"(1,10,ZD,A)" use sortin.txt record f,10 org ls give sortout.txt record f,10 org ls
I want attachment the data file but it was rejected so I paste it below.
<sortin.txt>
000000033}
000000298}
000000033A
000000298B
000000033J
000000298K</sortin.txt>
<sortout.txt>
000000033}
000000033A
000000033J
000000298}
000000298B
000000298K</sortout.txt>
<expect result="">
000000298K
000000298}
000000033J
000000033}
000000033A
000000298B</expect>
The DATA is formatted with Sign for Zone-Decimal, Modified.
You can find what it is in http://www.simotime.com/datazd01.htm.
It seems GCSORT cannot handle data like this.
But GnuCOBOL can handle it when I use the compile option "-fsign=EBCDIC".
Hi,
Modified the GCSORT module with the insertion of the option -fsign = EBCDIC they can be used for files with ZONED fields and EBCDIC sign.
New command line:
opt / batch / RUNTIME / bin / gcsort -fsign=EBCDIC sort fields "(1,10, ZD, A)" use sortin.txt record f, 10 org ls give sortout.txt record f, 10 org ls
Now the result is as expected.
Regards
Had a wee bit of a problem with "gcsort option -fsign="
Solved it by inferring what was meant in the --help option
This is the proper method to implement -fsign=
GCSORT -fsign=EBCDIC TAKE C:\IBZANIM\GNUDATA\TAKEFILE.TXT
It might be helpful to provide a sample command line invocation within --help output
Ralph
Thanks Ralph,
I will follow your suggestion.
Sauro
Where would I find the new windows version of GCSORT with the above improvement ?
Hi,
you can find new version in : https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/GCSORT/
Question ?
Is there any chance someone could build a .EXE for GCSORT. The .exe folder is empty.
There is updated source, but for those of us not steeped in "C" and / or Linux, GCSORT is not readily available.
I have no clue if this is enough but I've created the following file from the current GCSORT sources using Arnold's GC 3.1.2 MinGW build +
makefrom MSYS:If you use a build from Arnold you can try to copy that to its "bin" folder and check.
GCSORT.EXE via Arnold's 32 bit builds
"The program can't start because libcob.dll is missing"
I presume that libcob-4.dll is the actual name of the data set being referenced - correct ?
Even though the path contains the drive and directory as to where libcob-4 resides the error (above) is still issued (it resides in C:\IBZANIM\WINGNU\BIN)
It appears that successful execution requires that the current directory be the directory that contains libcob-4.dll. Correct ?
Creating a GCSORT directory that contains libcob-4.dll and gcsort.exe does not work either. Adding set path=%path%;c:\ibzanim\wingnu\bin; enabled gcsort to execute.
Seems odd that gcsort.exe requires libcob-4.dll to be in the current directory.
Am I missing something ?
Please advise
Ralph
Did you copy the "gcsort.exe" file into the same "\bin" folder where "cobc.exe", "cobcrun.exe", and "coblib-4.dll" reside?
The compiler's \bin folder should be in your windows PATH already.
I did as you stated.
I have a long path environment variable.
PATH=C:\IBZANIM\LOADLIB;C:\IBZANIM\ANIMRTS;C:\WINEDIT;C:\TRIFOX\BIN;C:\PROGRA~1\IBM\SQLLIB\BIN;C:\IBZANIM\WINGNU\BIN;C:\Program Files (x86)\CommonFiles\Fujitsu\COBOL;C:\FJ\;C:\WINEDIT;C:\ProgramFiles\Trifox\BIN;C:\IBZANIM\ANIMRTS;C:\IBZANIM\LOADLIB;C:\Program Files(x86)\;c:\windows\SYSTEM32;c:\windows;c:\windows\SYSTEM32\WBEM;c:\windows\SYSTEM32\WINDOWSPOWERSHELL\V1.0\;C:\PROGRAM FILES (X86)\IBM\GSK8\LIB;C:\PROGRAM FILES(X86)\GUISPF;C:\PROGRAM FILES (X86)\PKWARE\PKZIPC;C:
\Program Files\WIDCOMM\Bluetooth Software\;C:\ProgramFiles\WIDCOMM\Bluetooth Software\syswow64;C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x86;C:\Program Files (x86)\Intel\OpenCLSDK\2.0\bin\x64;C:\Users\ASUSI5.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm\;C:\Program Files (x86)\NVIDIA
Corporation\PhysX\Common;C:\Program Files (x86)\AMD\ATI.ACE\Core-Sta
tic;C:\Program Files (x86)\Common Files\Acronis\SnapAPI\;C:\ProgramFiles (x86)\AOMEI Backupper;C:\Program Files (x86)\WinMerge;C:\Program Files\Calibre2\;C:\ProgramFiles\ibm\gsk8\lib64;C:\PROGRA~1\IBM\SQLLIB\BIN;C:\PROGRA~1\IBM\SQLLIB\FUNCTION;C:\PROGRA~1\IBM\SQLLIB\SAMPLES\REPL;C:\Program Files(x86)\Gpg4win..\GnuPG\bin;C:\PROGRAM FILES\GUISPF;C:\WINEDIT
;C:\Program Files (x86)\SPFLite2;C:\ProgramFiles\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;
~~~
C:\WINEDIT gcsort
c:\IBZANIM>gcsort -> failed libcob.dll not found
c:\IBZANIM>cobc
cobc: error: no input files cobc is functional
c:\IBZANIM>set path=c:\ibzanim\wingnu\bin;%path%
Moving C:\ibzanim\wingun\bin to front of the path makes gcsort functional
c:\IBZANIM>gcsort
gcsort Version 01.01.00
Copyright (C) 2009-2020 Cedric ISSALY / Sauro Menna
gcsort. Nothing to do.
Usage: gcsort <option>
Execute command
or : gcsort TAKE <filename params="">
Read and execute command from filename params
or : gcsort --help
Print help
or : gcsort --version
Print version information
or : gcsort --config
Print values of environment variables</filename></option>
I guess I can change my .BAT files to include your directory first (renamed from your default).
How close to DFSORT are the GCSORT sort parameters ?
Ralph
On 4/14/2021 10:28 PM, Arnold Trembley wrote:
Last edit: Ralph Linkletter 2021-04-15
It's possible that building gcsort.exe using mingw make has some artifacts of the Linux directory structure that cause this problem. I've been told that moving Linux programs to different folders is not as simple as in Windows.
I have not actually used gcsort, but based on the examples I've read, it is an attempt to create a clone of DFSORT for GnuCOBOL. So it should work like DFSORT, but of course there is still the issue of ASCII versus EBCDIC and the issue of no OS support for structured files.
Hello,
the parameters present can be extracted with: gcsort --help
or in / trunk / tools / GCSORT / doc /
the reference document is present.
gcsort --help
gcsort help
gcsort is a program to sort, merge and copy records in a file into a specified order
Syntax case insensitive
Return code : 0 (ok) - 16 (error)
Usage with file parameters : gcsort <options> take filename
Usage from command line : gcsort <options> <control statements=""></control></options></options>
gcsort options
-fsign=[ASCII|EBCDIC] define display sign representation
gcsort control statements
Notations: '{name}' = parameters , '|' = Alternative format of control statement
SORT | MERGE FIELDS Control statement for Sort or Merge file(s)
USE Declare input file(s)
GIVE Declare output file
[ SUM FIELDS ] Sum fields for same record key, or eliminate duplicate keys)
[ INCLUDE ] Select input records that respect include condition(s)
[ OMIT ] Omit input records that respect include condition(s)
[ INREC ] Reformat input record Before sort, merge or copy operation
[ OUTREC ] Reformat input record After sort, merge or copy operation
[ OUTFIL ] Create one or more output files for sort,merge or copy operation
[ OPTION ] Specifies option for control statements
gcsort
SORT | MERGE
FIELDS({Pos},{Len},{FormatType},{Order}, ...) |
FIELDS({Pos},{Len},{Order}, ...),FORMAT={FormatType} |
FIELDS=COPY
{Parameters}____|____
{FileName} = Filename or Env. Variable | EQ = Equal
{Pos} = Field Position | GT = GreaterThan
{Len} = Field Length | GE = GreaterEqual
{RecordLen}= Record Length | LT = LesserThan
{MinLen} = Min size of record | LE = LesserEqual
{MaxLen} = Max size of record | NE = NotEqual
{Order} = A(ascending) | D(descending)| SS = SubString (only for Field Type 'CH')
______|______
{Condition}__________
Format 1 - (Pos,Len,{FormatType},{Relational},[AND|OR],Pos,Len,{FormatType})
Format 2 - (Pos,Len,{FormatType},{Relational},[X|C'[value]'] | numeric value)]
Format 3 - ( {Condition} ,[AND|OR],{Condition} )
_____________
File Organization__|_Mandatory for ORG = IX
LS = Line Sequential | P = Primary Key
SQ = Sequential Fixed or Variable | A = Alternative Key
IX = Indexed Fixed or Variable | D = Alternative Key with Duplicates
RL = Relative Fixed or Variable | C = Continue definition
______|______
_Field Format Type_|{FormatType2}_Format Type SumField
CH = Char | BI = Binary unsigned
BI = Binary unsigned | FI = Binary signed
FI = Binary signed | FL = Floating Point
FL = Floating Point | PD = Packed
PD = Packed | ZD = Zoned
ZD = Zoned | CLO = Numeric sign leading
CLO = Numeric sign leading | CSL = Numeric sign leading separate
CSL = Numeric sign leading separate | CST = Numeric sign trailing separate
CST = Numeric sign trailing separate |
______|______
_{FieldSpec}Field Specification_______
pos, len pos = position input record, len = length of field
posOut:pos,len posOut = position output, pos = position input , len = length
n:X Filling with Blank character from last position to n
(absolute position of output record).
n:Z Filling with zero Binary character from last position to n
(absoluteposition of output record).
C'constant' constant character value.
nC'constant' repeat n times constant character value.
nX repeat n times Blank character.
nZ repeat n times Binary (0x00) character.
X'hh....hh' hexdecimal characters.
nX'hh...hh' repeat n times hexdecimal characters.
_____________
Environment Variables
____________
COB_VARSEQ_FORMAT Used by GnuCOBOL
GCSORT_DEBUG 0 no print info, 1 info DEBUG, 2 for info Parser
GCSORT_MEMSIZE Memory Allocation in byte (Default 512000000 byte)
GCSORT_PATHTMP Pathname for temporary files (Default TMP / TEMP / TMPDIR)
GCSORT_STATISTICS 0 minimal informations, 1 for Summary, 2 for Details
GCSORT_TESTCMD 0 for normal operations , 1 for ONLY test command line (NO SORT)
________________
Sauro
To add to this: if someone is missing a function then we already have a wish-list item for that: [feature-requests:#400] to check / add to / say "yes, I need xyz".
Related
Wish List: #400
There are a couple things that would help GCSORT be a wee bit more useful in zOS applications.
Support for the Y2K date formats and two exits.
A "Record At A Time " methodology defines the E15 / E35 interaction.
See: https://www.ibm.com/docs/en/zos/2.1.0?topic=exits-dfsort-inputuser-exitoutput-logic-examples
The two common and important exits are referred to as E15 and E35 (sometimes E37).
They are actually rather simple to implement.
An E15 exit makes an application subroutine responsible for the "USING" file processing
An E35 exit makes an application subroutine responsible for the "GIVING" file processing
One of the exits require that the subroutine(s) supply the sort control cards
The basic process of E15 reads an input record record and passes the record to sort.
E15 signifies end of input by passing a return code 8 to the sort.
At conclusion of the E15 process - the sorting phase begins
The basic process of E35 is it accepts a record from sort after the sort phase is complete.
E35 passes the records back to the exit one record at a time until end of output - return code 8.
At conclusion of the E35 process the sort has ended
Legacy application are more than likely to still use 2 character YY fields for date fields.
Especially if the Y2K solution was deployed using a "sliding or fixed window" paradigm.
DFSORT will also infer the full YYYY with the Y2? sort field implementation.
These are the common DFSORT definitions of date fields requiring that SORT infer the full YYYY.
There are some other values where "special indicators" are needed
I have several COBOL programs that implement RAAT to various SORT vendors. I will glady share the source if needed.
Ralph
I do agree with Ralph, the Exit routines may be handy and would allow the cobol programs that are used to be the same on Zos transfered to gnucobo, withoug much change. However...
We use Syncsort on the mainframe (and it is near about the same as DFsort), and the only reason we even used it and exit programs is because on Zos, nothing we found is as fast as the I/O for SyncSort. ( You can get SyncSort for Linux, but $$$...)
Really we had a program that read Very Large data files on the Mainframe and did some calculations and reformatiing, and it about 6 hours. When we changed it to and external SysnSort (with exits) for the small cobol part, it ran in under an hour.
And in Zos JCL we did try useing differnt buffers and such (like we do for Vsam sort of ) but the SyncSort was the best way to go..
Not to mention the Join statements and control breaks for SyncSort, ... we never wrote cobol report or small data reformat programs, we did it in external SyncSort...