Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Sri h Kolusu]

> And that's the way IBM nowadays treats it's customers?

Customer? If you are a customer you would have gone thru proper channels of
opening a PMR and Level 2 would answer your questions. Please do that.

>Too bad I don't have the
> email address of Arvind Krishna, I would have loved to CC: this reply to
him!

Wow. Is that a threat?

>>As for the product you're responsible for? In 1964 IBM developed a
programming
language, PL/I, without keywords also being reserved words, alleviating the
need
to ever having to change programs when new keywords were introduced. Why
can't
you do that for SORT?

If you want something done, there are proper channels for requesting it.
RFE is one of it

https://www.ibm.com/developerworks/rfe/


> Using an adblocker is too hard? Ask yourself, would Frank Yaeger have
been
> deterred by ads when supporting an IBM product?

I use adblocker in addition to Umatrix. Thanks for your suggestion.

> especially item 4!
> And more ramblings of a nobody?

Good for you. well I don't have boast about what I did or how much I help
on this board and other helpboards.

Either way this will be my last and final reply to you and your posts.

Thanks,
Kolusu

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Seymour J Metz]

> I'm sure others here have looked and looked and looked at code they wrote,
> absolutely sure that it was OK, only to be informed by a colleague, after 
> he/she
> looked at it for about 42 milliseconds, that they missed out on another
> "Purloined Letter"...

Sometimes, 42 ms after I explain what the code is supposed to do I get a "duh" 
moment before he has time to spot it.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [rob...@prino.org]
Sent: Friday, January 15, 2021 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

On 2021-01-15 16:22, Sri h Kolusu wrote:
>>
>> Please don't patronise me with high "coding standards", you banned
>> me from your
>> forum when I commented on the fact that you suggested using UNSPEC()
>> to look at
>> the internal representation of z/OS HEX FLOAT values in order top
>> print them in
>> a PL/I program, and then deleted the postings to hide your own
> incompetence!
>
>
> Robert,
>
> Ya right ! And you had the audacity to call it a bug in the product even
> though you are data owner and mere checking of the data would have answered
> your own question.  I should have gone with my first instinct of just
> ignoring your rambling. That is the only thing you do.

And that's the way IBM nowadays treats it's customers? Too bad I don't have the
email address of Arvind Krishna, I would have loved to CC: this reply to him!

Then again, maybe the "Heart to Heart" program still exists, it used to
guarantee that a letter to the CEO was only read by the CEO.

And it actually worked in a grey past: after having been shoved around for
months not receiving the updates for OS/2 I was entitled to, a "Heart to Heart"
letter to Mr Palmisano did the trick,  I was contacted by a personal assistant
of the managing director of IBM UK, and two weeks later a big box with all OS/2
updates arrived!

Maybe you should have a look at
<https://secure-web.cisco.com/1iKkzjhX3DhkxVKtwzuOOXESTUuOsbSgksr38EUwRZ82okrw_MiTlqzdtaw043sUF_VpfwDaoy8en7XEdn8WrAvKFZHqz76yqtobf1OAq3970vrWonUVVY3MkBk7EzbQNHgvfuZCoN1c4HiYR8Y-zVZT_j_DBS_BPnu3MR2CfzPzFcf9dKXKl1Ed48YST5XuJkGTuU-VQNZj3iUknjxd_ikvL5RCdZXeSaXL6_cZn9qFXcOsYVihSqmlBdtknZBfupvNxfqa6GiEHmxWkLtNaQFBBlB30O2RSszd-51M0x8FqH47TUNEsU0A4ImBp7P8M__80P44NkjjtBsi86dA9OmTogzZgYILM-oGJ9_5oLWu5So1WzO388I2ew_Rpz1as4imLi-OR1BHgL4pjEBdefb-ZizPdNb8ZoSXUi0yMkW8yGOhdQFTzhxKMHCuCthOBNUcYIdOAjXDHLa-PSHE-RA/https%3A%2F%2Fwww.joelonsoftware.com%2F2007%2F02%2F19%2Fseven-steps-to-remarkable-customer-service%2F>,
especially item 4!

I'm sure others here have looked and looked and looked at code they wrote,
absolutely sure that it was OK, only to be informed by a colleague, after he/she
looked at it for about 42 milliseconds, that they missed out on another
"Purloined Letter"...

And more ramblings of a nobody?

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147579
(Given the last IBM comment, not unlikely that it will be delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=100073
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=31632
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=84512
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=145001
(Planned for future release)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
(Under consideration)

As for the product you're responsible for? In 1964 IBM developed a programming
language, PL/I, without keywords also being reserved words, alleviating the need
to ever having to change programs when new keywords were introduced. Why can't
you do that for SORT?

>> And did you actually read the "...and ***someone*** came up with a
>> really very
>> elegant way of performing this task, ..." (Emphasis added...) You should
> have
>> seen, as you're also on that forum, that the solution was provided by
> Jörg
>> Findeisen!
>
> I stopped browsing that forum ever since they forced ads.

Using an adblocker is too hard? Ask yourself, would Frank Yaeger have been
deterred by ads when supporting an IBM product?

> Kudos to Jorg > findeisen for coding a solution. And the degree of elegance 
> depends. So if
> you are happy with the solution stick with it
>
>>>> And that saves? 1 nanosecond?
>
> The question is NOT only about saving CPU cycles. The elegance you boast
> isn't seen when you code such statements.
>
>> Which is really important for something that processes 209 lines of
>> input, and
>> might at some stage process as many as 

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Robert Prins]

On 2021-01-15 16:22, Sri h Kolusu wrote:


Please don't patronise me with high "coding standards", you banned
me from your
forum when I commented on the fact that you suggested using UNSPEC()
to look at
the internal representation of z/OS HEX FLOAT values in order top
print them in
a PL/I program, and then deleted the postings to hide your own

incompetence!


Robert,

Ya right ! And you had the audacity to call it a bug in the product even
though you are data owner and mere checking of the data would have answered
your own question.  I should have gone with my first instinct of just
ignoring your rambling. That is the only thing you do.


And that's the way IBM nowadays treats it's customers? Too bad I don't have the 
email address of Arvind Krishna, I would have loved to CC: this reply to him!


Then again, maybe the "Heart to Heart" program still exists, it used to 
guarantee that a letter to the CEO was only read by the CEO.


And it actually worked in a grey past: after having been shoved around for 
months not receiving the updates for OS/2 I was entitled to, a "Heart to Heart" 
letter to Mr Palmisano did the trick,  I was contacted by a personal assistant 
of the managing director of IBM UK, and two weeks later a big box with all OS/2 
updates arrived!


Maybe you should have a look at 
, 
especially item 4!


I'm sure others here have looked and looked and looked at code they wrote, 
absolutely sure that it was OK, only to be informed by a colleague, after he/she 
looked at it for about 42 milliseconds, that they missed out on another 
"Purloined Letter"...


And more ramblings of a nobody?

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147579
(Given the last IBM comment, not unlikely that it will be delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=100073 
(Delivered)


https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=31632
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=84512
(Delivered)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=145001
(Planned for future release)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
(Under consideration)

As for the product you're responsible for? In 1964 IBM developed a programming 
language, PL/I, without keywords also being reserved words, alleviating the need 
to ever having to change programs when new keywords were introduced. Why can't 
you do that for SORT?



And did you actually read the "...and ***someone*** came up with a
really very
elegant way of performing this task, ..." (Emphasis added...) You should

have

seen, as you're also on that forum, that the solution was provided by

Jörg

Findeisen!


I stopped browsing that forum ever since they forced ads.  


Using an adblocker is too hard? Ask yourself, would Frank Yaeger have been 
deterred by ads when supporting an IBM product?



Kudos to Jorg > findeisen for coding a solution. And the degree of elegance 
depends. So if
you are happy with the solution stick with it


And that saves? 1 nanosecond?


The question is NOT only about saving CPU cycles. The elegance you boast
isn't seen when you code such statements.


Which is really important for something that processes 209 lines of
input, and
might at some stage process as many as 300 lines on input, and it's part

of a

job that runs for about a minute, so saving a fraction of a second? And

when

SORT is invoked by the viewer, the result is usually displayed when
my finger is
still next to the Enter key.


As I said earlier I wouldn't have bothered to answer the questions from YOU
if you hadn't called an user error a bug in the product.


I guess the question marks didn't make it to your side...

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Sri h Kolusu]

>
> Please don't patronise me with high "coding standards", you banned
> me from your
> forum when I commented on the fact that you suggested using UNSPEC()
> to look at
> the internal representation of z/OS HEX FLOAT values in order top
> print them in
> a PL/I program, and then deleted the postings to hide your own
incompetence!


Robert,

Ya right ! And you had the audacity to call it a bug in the product even
though you are data owner and mere checking of the data would have answered
your own question.  I should have gone with my first instinct of just
ignoring your rambling. That is the only thing you do.

> And did you actually read the "...and ***someone*** came up with a
> really very
> elegant way of performing this task, ..." (Emphasis added...) You should
have
> seen, as you're also on that forum, that the solution was provided by
Jörg
> Findeisen!

I stopped browsing that forum ever since they forced ads.  Kudos to Jorg
findeisen for coding a solution. And the degree of elegance depends. So if
you are happy with the solution stick with it

>>> And that saves? 1 nanosecond?

The question is NOT only about saving CPU cycles. The elegance you boast
isn't seen when you code such statements.

> Which is really important for something that processes 209 lines of
> input, and
> might at some stage process as many as 300 lines on input, and it's part
of a
> job that runs for about a minute, so saving a fraction of a second? And
when
> SORT is invoked by the viewer, the result is usually displayed when
> my finger is
> still next to the Enter key.

As I said earlier I wouldn't have bothered to answer the questions from YOU
if you hadn't called an user error a bug in the product.

Thanks,
Kolusu


IBM Mainframe Discussion List  wrote on
01/15/2021 10:53:50 AM:

> From: Robert Prins 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 01/15/2021 08:54 AM
> Subject: [EXTERNAL] Re: Bug in DFSORT? [WAS: Merging multiple
> records using DFSORT]
> Sent by: IBM Mainframe Discussion List 
>
> On 2021-01-15 11:50, Sri h Kolusu wrote:
> >> So what's so special about 80? 9, 41 and 44 are unique in the entire
set
> > of >sort control statements, and 80 also doesn't appear, yet replacing
44
> > by 80 >results in incorrect output.
> >
> >> I've gone over it again and again, but I'm totally clueless, unless
this
> > is >one of those bugs that nobody's encountered before(*).
> >> So, if someone can confirm the problem, or that this is a case of
Edgar
> >> Allan Poe's "The Purloined Letter", i.e. so obvious that it hides in
plain
> >> sight, please reply to this post!
> >
> > Robert,
> >
> > Let me start off with "It is NOT a BUG" and the obvious is right in
front
> > of you. As a data owner you SHOULD be in a better position to tell as
to
> > what is so special about the data at position 80.
>
> Yes, as I already wrote, it's probably a case of "The Purloined
Letter"...
>
> > To explain what is so special about 80. Open the input dataset in
> > browse/edit mode
> >
> > Issue the command F '+' 44 ALL then make a note of where exactly you
are
> > finding the specified character. Also Make a note of the number of
times
> > the character is found. (5 times)
> >
> > Hint : It is found on the FIRST line of the boxed data skipping the
first
> > set of data
> >
> > Now issue the same command but changing the position to 80
> >
> > F '+' 80 ALL
> >
> > Also make a note of how many number of times the character is found (9
> > times)
> >
> > Hint : It is found on the FIRST/SECOND/THIRD line of the boxed data
> > starting with the first set of data.
> >
> > DFSORT is merely doing what you wanted it to do. So I am not sure
comparing
> > a 5 time found data with 9 times found data is correct.
> >
> > Btw the control cards can be optimized and I am not even sure as to why
you
> > need a numeric conversion for simply sticking a constant value of
0120 ?
> > Not sure how it passed your high "coding standards"
>
> Please don't patronise me with high "coding standards", you banned
> me from your
> forum when I commented on the fact that you suggested using UNSPEC()
> to look at
> the internal representation of z/OS HEX FLOAT values in order top
> print them in
> a PL/I program, and then deleted the postings to hide your own
incompetence!
>
> And did you actually read the "...and ***someone*** came up with a
> really very
> elegant way of performing this task, ..." (Emphasis added...) You should
have
> seen, as you're also on that forum, that the solution was provide

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Robert Prins]

On 2021-01-15 11:50, Sri h Kolusu wrote:

So what's so special about 80? 9, 41 and 44 are unique in the entire set

of >sort control statements, and 80 also doesn't appear, yet replacing 44
by 80 >results in incorrect output.


I've gone over it again and again, but I'm totally clueless, unless this

is >one of those bugs that nobody's encountered before(*).

So, if someone can confirm the problem, or that this is a case of Edgar
Allan Poe's "The Purloined Letter", i.e. so obvious that it hides in plain
sight, please reply to this post!


Robert,

Let me start off with "It is NOT a BUG" and the obvious is right in front
of you. As a data owner you SHOULD be in a better position to tell as to
what is so special about the data at position 80.


Yes, as I already wrote, it's probably a case of "The Purloined Letter"...


To explain what is so special about 80. Open the input dataset in
browse/edit mode

Issue the command F '+' 44 ALL then make a note of where exactly you are
finding the specified character. Also Make a note of the number of times
the character is found. (5 times)

Hint : It is found on the FIRST line of the boxed data skipping the first
set of data

Now issue the same command but changing the position to 80

F '+' 80 ALL

Also make a note of how many number of times the character is found (9
times)

Hint : It is found on the FIRST/SECOND/THIRD line of the boxed data
starting with the first set of data.

DFSORT is merely doing what you wanted it to do. So I am not sure comparing
a 5 time found data with 9 times found data is correct.

Btw the control cards can be optimized and I am not even sure as to why you
need a numeric conversion for simply sticking a constant value of 0120 ?
Not sure how it passed your high "coding standards"


Please don't patronise me with high "coding standards", you banned me from your 
forum when I commented on the fact that you suggested using UNSPEC() to look at 
the internal representation of z/OS HEX FLOAT values in order top print them in 
a PL/I program, and then deleted the postings to hide your own incompetence!


And did you actually read the "...and ***someone*** came up with a really very 
elegant way of performing this task, ..." (Emphasis added...) You should have 
seen, as you're also on that forum, that the solution was provided by Jörg 
Findeisen!



INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:+120,ZD,LENGTH=4)),

should be as simple as

INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:C'0120')),


And that saves? 1 nanosecond?


Similarly when using the substring format and searching for multiple
characters, it is advisable to have a comma so that it is easy to
understand and maintain.

(44,1,SS,EQ,C'+|') should be  (44,1,SS,EQ,C'+,|')


And how much extra time does this add to parsing the string? Sheesh...


This is explained in the 2nd bullet here

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icea100/substr.htm

And just for the record, the job can be optimized and can be done easily.


Which is really important for something that processes 209 lines of input, and 
might at some stage process as many as 300 lines on input, and it's part of a 
job that runs for about a minute, so saving a fraction of a second? And when 
SORT is invoked by the viewer, the result is usually displayed when my finger is 
still next to the Enter key.


Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Sri h Kolusu]

>So what's so special about 80? 9, 41 and 44 are unique in the entire set
of >sort control statements, and 80 also doesn't appear, yet replacing 44
by 80 >results in incorrect output.

>I've gone over it again and again, but I'm totally clueless, unless this
is >one of those bugs that nobody's encountered before(*).
>So, if someone can confirm the problem, or that this is a case of Edgar
>Allan Poe's "The Purloined Letter", i.e. so obvious that it hides in plain
>sight, please reply to this post!

Robert,

Let me start off with "It is NOT a BUG" and the obvious is right in front
of you. As a data owner you SHOULD be in a better position to tell as to
what is so special about the data at position 80.

To explain what is so special about 80. Open the input dataset in
browse/edit mode

Issue the command F '+' 44 ALL then make a note of where exactly you are
finding the specified character. Also Make a note of the number of times
the character is found. (5 times)

Hint : It is found on the FIRST line of the boxed data skipping the first
set of data

Now issue the same command but changing the position to 80

F '+' 80 ALL

Also make a note of how many number of times the character is found (9
times)

Hint : It is found on the FIRST/SECOND/THIRD line of the boxed data
starting with the first set of data.

DFSORT is merely doing what you wanted it to do. So I am not sure comparing
a 5 time found data with 9 times found data is correct.

Btw the control cards can be optimized and I am not even sure as to why you
need a numeric conversion for simply sticking a constant value of 0120 ?
Not sure how it passed your high "coding standards"

INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:+120,ZD,LENGTH=4)),

should be as simple as

INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:C'0120')),

Similarly when using the substring format and searching for multiple
characters, it is advisable to have a comma so that it is easy to
understand and maintain.

(44,1,SS,EQ,C'+|') should be  (44,1,SS,EQ,C'+,|')

This is explained in the 2nd bullet here

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icea100/substr.htm

And just for the record, the job can be optimized and can be done easily.

Thanks,
 Kolusu

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Robert Prins]

On 2021-01-12 16:12, Robert Prins wrote:

I'm currently using this...


I've posted the question to , 
and someone came up with a really very elegant way of performing this task, but 
his solution, unlike the one I posted in the start of this thread, cannot handle 
data in a legacy format, which is a must, as the code to look at older results 
automagically invokes sort to convert members that contain split (into chunks of 
121 bytes) members into merged ones.


So I added some additional code that correctly processes the old data, but then 
I realised that instead of using my hack, it would be more useful to select a 
unique column in the second table that does not appear in the same format in the 
same place in the legacy data.


Fow what it's worth, and for those not willing to access the above post, the JCL 
I use is below:


//PRINOSOR JOB (PRINO),
// 'Test LW merge',
// CLASS=A,
// MSGCLASS=H,
// MSGLEVEL=(2,0),
// NOTIFY=
//*
//MERGELW EXEC PGM=SORT
//*
//SYSOUTDD SYSOUT=*
//*
//SORTINDD DSN=@@121.TEXT,  /* FB(121)
// DISP=SHR
//*
//SORTOUT   DD SYSOUT=*
//*
//SYSIN DD *
* Merge the LW file
*
* See: https://ibmmainframes.com/viewtopic.php?t=68044

  OPTION COPY
* 
* Put '0120' in columns 364-367

  INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:+120,ZD,LENGTH=4)),

* Whatever   0120
* 
* Test column 9 for '+' or '|' OR column 41 for '+' or '|'
* - copy 365 ('1') to 364
* - add seqno to 367, for two records

IFTHEN=(WHEN=GROUP,BEGIN=(9,1,SS,EQ,C'+|',OR,41,1,SS,EQ,C'+|'),
  PUSH=(364:365,1,367:SEQ=1),RECORDS=2),

* T-1 / P-1  1121
* T-1 / P-2  1122
* 
* Test column 44 for '+' or '|'
* - copy 366 ('2') to 364
* - add seqno to 367, for three records

*!! CHANGE 44 below to 80 and things go wrong!!

IFTHEN=(WHEN=GROUP,BEGIN=(44,1,SS,EQ,C'+|'),
  PUSH=(364:366,1,367:SEQ=1),RECORDS=3),

* T-2 / P-1  2121
* T-2 / P-2  2122
* T-2 / P-3  2123
* 
* Test column column 367 for '1'
* - add columns 1-121 at column 122

IFTHEN=(WHEN=GROUP,BEGIN=(367,1,ZD,EQ,+1),
  PUSH=(122:1,121)),

* Whatever   0120
* T-1 / P-1 T-1 / P-11121
* T-1 / P-2 T-1 / P-11122
* Whatever  T-1 / P-10120
* T-2 / P-1 T-2 / P-12121
* T-2 / P-2 T-2 / P-12122
* T-2 / P-3 T-2 / P-12123
* Whatever  T-2 / P-10120
* 
* Test column column 367 for '2'
* - add columns 1-121 at column 243

IFTHEN=(WHEN=GROUP,BEGIN=(367,1,ZD,EQ,+2),
  PUSH=(243:1,121))

* Whatever   0120  x 0...: 1,121
* T-1 / P-1 T-1 / P-11121
* T-1 / P-2 T-1 / P-1 T-1 / P-2  1122
* t-1 / P-1 t-1 / P-1 T-1 / P-2  1121  x 1..1: 122,1+1,121
* t-1 / P-2 t-1 / P-1 t-1 / P-1  1122
* Whatever  t-1 / P-1 t-1 / P-1  0120  x 0...: 1,121
* T-2 / P-1 T-2 / P-1 t-1 / P-1  2121
* T-2 / P-2 T-2 / P-1 T-2 / P-2  2122
* T-2 / P-3 T-2 / P-1 T-2 / P-2  2123  x 2..3: 122,121+243,121+1,121
* 

  OUTFIL FNAMES=(SORTOUT),
INCLUDE=((364,1,ZD,EQ,+0),OR,
 (364,1,ZD,EQ,+1,AND,367,1,ZD,EQ,+2),OR,
 (364,1,ZD,EQ,+2,AND,367,1,ZD,EQ,+3)),

FTOV,VLTRIM=C' ',

IFTHEN=(WHEN=(364,1,ZD,EQ,+0),BUILD=(1,121)),

IFTHEN=(WHEN=(364,1,ZD,EQ,+1,AND,367,1,ZD,EQ,+2),
  BUILD=(122,121,1,121)),

IFTHEN=(WHEN=(364,1,ZD,EQ,+2,AND,367,1,ZD,EQ,+3),
  BUILD=(122,121,243,121,1,121))

The input file (@@121.text) is included (I hope) as a plain-text (58 lines, no 
trailing spaces) attachment, or can be scraped from 
 (with the JCL and 
expected output)


Paste it into an FB(121) dataset, paste the JCL, and submit it, and SYSOUT from 
SORT will show two merged tables, so far so good.


If you look at the input or, to make things a bit easier, the output, and then 
look at the second and third IFTHEN statements, the second tests for a '+'or '|' 
in columns 9 & 41, the third just checks for the same two characters in column 44.


I've not (yet) checked why the second IFTHEN uses two columns and the third 
IFTHEN only one column as the three columns checked are mutually exclusive, but...


column 44 is also present in the legacy data, so I thought, "Why not change that 
one into 80?" which is the next column in the second table that only contains 
'+' and '|', or even 

Merging multiple records using DFSORT

[Robert Prins]

I'm currently using this

* Merge the LW file
*
* These sort commands can handle both the old, it's left unchanged, as
* well as the new, records are merged, LW output file.
***
 OPTION COPY
 INREC  IFTHEN=(WHEN=(1,1,CH,EQ,C'1',OR, ASA
114,1,CH,EQ,C'+',OR, Old eol
114,1,CH,EQ,C'|'),   Old eol
   OVERLAY=(122:C' ')),
IFTHEN=(WHEN=NONE,
   OVERLAY=(122:SEQNUM,8,ZD,122:122,8,ZD,MOD,+2,M11,LENGTH=1))
*
 OUTREC IFTHEN=(WHEN=GROUP,BEGIN=(122,1,CH,EQ,C'1'),
  PUSH=(123:1,121))
*
 OUTFIL FTOV,VLTRIM=C' ',
  OMIT=(122,1,CH,EQ,C'1'),
IFTHEN=(WHEN=(122,1,CH,EQ,C'0'),BUILD=(123,121,1,121)),
IFTHEN=(WHEN=(122,1,CH,EQ,C' '),BUILD=(1,121))

which works like a charm.

However, the input file is about to change, and as we're still not willing to 
update the regression testing framework to cater for files other than FB(121), 
the above has to change for additional input records, which means another 
ifthen-when group. I guess it's not a problem to change the current overlay to a 
fixed '1' followed by the current seqnum logic (Correct me if I'm wrong!) and 
add another with a fixed '2' plus a mod +3 sequence number, the new records need 
to be assembled from three records. (Yes, sigh...)


However, can I use multiple "PUSH"es? The manual tells me

You can use the following in PUSH:
c: Specifies the output position (column) to be overlaid. If you do not
specify c: for the first item, it defaults to 1:. If you do not specify c:
for any other item, it starts after the previous item. You can specify
items in any order and overlap output columns. c can be 1 to
32752.
If you specify an item that extends the output record beyond the
end of the input record, the record length is automatically
increased to that length, and blanks are filled in on the left as
needed. For variable-length records, the RDW length is increased
to correspond to the larger record length after all of the items are
processed. Missing bytes in specified input fields are replaced with
blanks so the padded fields can be processed.
p,m
***Specifies a field in the ***first input record*** of each group to be
propagated to every record of the group.*** p specifies the starting
position of the field in the input record and m specifies its length.
A field must not extend beyond position 32752.
ID=n
Specifies a ZD identifier of length n is to be added to every record
of each group. The identifier starts at 1 for the first group and is
incremented by 1 for each subsequent group. n can be 1 to 15.
SEQ=n
Specifies a ZD sequence number of length n is to be added to
every record of each group. The sequence number starts at 1 for
the first record of each group and is incremented by 1 for each
subsequent record of the group. n can be 1 to 15.[/quote]

Emphasis (***) added, which seems that I can only merge data from the first 
record?

Or do I have to resort to something more exotic, like 
?


Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN