> On May 16, 2016, at 7:23 AM, Elardus Engelbrecht
> wrote:
>
> John McKown wrote:
>
>>> You can always write a 3rd SORT system with a build in programming
>>> language. Hopefully that system is sort of free...
>
>> Oh, yeah. Perhaps based on Guile (big grin)
>> https://en.wikipedia.org/wiki
John McKown wrote:
>Well, I understand your comments on DFSORT's control language. ICETOOL +
>SYMNAMES does a lot to enhance DFSORT.
Indeed. ICETOOL is my friend.
>But a more "general purpose" language, building on these, might be nice.
Agreed. I look at what is available, how that is suit
On Mon, May 16, 2016 at 7:23 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:
> John McKown wrote:
>
> >> You can always write a 3rd SORT system with a build in programming
> language. Hopefully that system is sort of free...
>
> >Oh, yeah. Perhaps based on Guile (big grin)
> >htt
John McKown wrote:
>> You can always write a 3rd SORT system with a build in programming language.
>> Hopefully that system is sort of free...
>Oh, yeah. Perhaps based on Guile (big grin)
>https://en.wikipedia.org/wiki/GNU_Guile. It's a LISP variant.
H, very very interesting part of the GN
On Mon, May 16, 2016 at 4:31 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:
> Peter Hunkeler wrote:
>
> >Not sure whether I shall laugh or cry. DFSort is a great tool, no doubt;
> it's control statements (I intentionally don't called it "language") are a
> nightmare, no doubt. Ho
Peter Hunkeler wrote:
>Not sure whether I shall laugh or cry. DFSort is a great tool, no doubt; it's
>control statements (I intentionally don't called it "language") are a
>nightmare, no doubt. Hopefully noone will ever consider the above as something
>suitable for production. Overkill; not mai
>So, changed those to non-printable. That would fix it up, but the code is
>still suffering from having to change >horses in mid-stream. And there's the
>fat-fingering, which is an all-too-common issue.
>
>Leads to sort symbols, WHEN=INIT, two FINDREPs with STARTPOS and DO=1 and
>SHIFT=NO.
>
>
Well, Friday was a long week, and that often leads to fatal mistakes. Here the
mistake is using "printable" items as the source-data for the FINDREP. This
would be a problem if the value was a subset of the PARM.
So, changed those to non-printable. That would fix it up, but the code is still
su
It worked, once I un-fat-fingered it. Thanks again,
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bill Godfrey
Sent: Friday, May 13, 2016 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Suggestion for conditioning step on
DFSORT using JPn symbols:
// SET PARM1=XY
// SET PARM2=AB
//STEP0100 EXEC PGM=SORT,PARM='JP1"&PARM1",JP2"&PARM2"'
//SYMNOUT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SORTOUT DD SYSOUT=*
//SYSINDD *
OPTION COPY,STOPAFT=1
INREC OVE
al Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bill Godfrey
Sent: Friday, May 13, 2016 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Suggestion for conditioning step on symbols
On Fri, 13 May 2016 09:39:43 -0700, Charles Mills wrote:
>I know
On Fri, 13 May 2016 09:39:43 -0700, Charles Mills wrote:
>I know this has been kicked around before but I don't have a good answer off
>the top of my head and I don't know exactly how to Google for the answer.
>
>Does anyone have suggestions for conditioning a jobstep on &symbol1 !=
>&symbol2? I k
73-1298
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Farley, Peter x23353
Sent: Friday, May 13, 2016 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Suggestion for conditioning step on symbols
I don't have a solution for the st
frame Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Friday, May 13, 2016 10:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Suggestion for conditioning step on symbols
I don't have a solution for the string comparison issue, but the DISP=NEW
issue I can tel
Charles Mills wrote:
>I know this has been kicked around before but I don't have a good answer off
>the top of my head and I don't know exactly how to Google for the answer.
Can you search IBM-MAIN archives itself? Of course, you may try out different
search arguments...
>Does anyone have sug
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Friday, May 13, 2016 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Suggestion for conditioning step on symbols
I know this has been kicked around before but I don't hav
On Fri, 13 May 2016 09:39:43 -0700, Charles Mills wrote:
>I know this has been kicked around before but I don't have a good answer off
>the top of my head and I don't know exactly how to Google for the answer.
>
>Does anyone have suggestions for conditioning a jobstep on &symbol1 !=
>&symbol2? I k
I know this has been kicked around before but I don't have a good answer off
the top of my head and I don't know exactly how to Google for the answer.
Does anyone have suggestions for conditioning a jobstep on &symbol1 !=
&symbol2? I know that COND= and IF are only on return codes and similar
thin
18 matches
Mail list logo