Comparison Routine - thanks

2018-10-26 Thread Peter Morrison
Hello listers,

 

I want to thank everyone who replied, either privately or via the list.  

 

It turns out that, yes, macro ASAXWC is what I needed (and forgot about).

 

I have written code to do this before (twice!) but both times I got 'let
go'.  I wasn't looking forward to designing and writing it a third time!

 

Peter Morrison

 


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


Re: SMP/E

2018-10-26 Thread scott Ford
Yes I just starting using the CA service. It’s weird I never had to learn
SMP/E per se. I guess you can teach old dawgs new tricks.

Scott

On Thu, Oct 25, 2018 at 9:16 AM John Eells  wrote:

> Longabaugh, Robert E wrote:
> > CA has offered Internet Service Retrieval (RECEIVE ORDER) since January
> 2018.
> https://support.ca.com/us/product-content/status/announcement-documents/2018/ca-smp-e-receive-order---maintenance-delivery-made-easy.html
> > I believe that at least one other ISV offers RECEIVE ORDER, but do not
> want name the wrong one.
> >
> 
>
> The other one is Compuware:
>
>
> https://globenewswire.com/news-release/2018/04/02/1458509/0/en/Compuware-s-New-Automated-Receive-Order-System-Greatly-Simplifies-Ordering-and-Delivery-of-Maintenance.html
>
> I have heard that at least one other vendor is working on it.
>
> I personally find it very encouraging that we now have three software
> vendors (IBM, CA, Compuware) using the same process for PTF delivery.
> It's a step along the road to what I personally hope will become a
> platform-wide set of common processes for product and PTF acquisition
> and installation within a few years.  (If you have not been following
> along, you can find my SHARE presentations and others from IBM and other
> vendors online.)
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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


Re: SORT not behaving consistently

2018-10-26 Thread Christopher Y. Blaicher
Sorts today are designed to minimize elapsed time, at least Syncsort's MFX 
sort, is by default. As with EQUALS there are ways to tell the sorts what to 
prioritize on, TIME, EXCPS, MEMORY.

In making optimization decisions, we tend to go by the rule of, you can buy 
more CPU or memory or DASD, but you can't buy more time.

Many, most?, shops have production windows that have grown smaller, thus the 
effort that is made to minimize time.

[AD] We do all the optimization with an eye out for what else is running in the 
system. We don't want to start a sort and give it so many resources that it 
negatively effects the rest of the processes running on a system.  Using the 
Global Sort Optimizer, we track what the usual resources available are for the 
expected duration of a sort and prevent that sort that starts at 7:50AM, and is 
going to run for an hour, from taking all the resources that your online 
systems need that start up at 8:00AM.

Syncsort provides sorting technology to many other vendors including IBM 
(DB2Sort), BMC (BMCSORT), and others.  

Chris Blaicher
Technical Architect
Syncsort, Inc.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, October 26, 2018 12:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT not behaving consistently

My first job in IT had me working on a fairly new application that was designed 
around an ISAM master file. Shortly before going live, it was discovered that 
the data center billed application business units for I/O but not for memory 
usage. So a quick change was instituted to read the entire ISAM file into 
virtual storage at startup and process it there. I don't know what the savings 
amounted to, but it was certainly an example of nudging people in an 
unexpected--and probably unwanted--direction.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cameron Conacher
Sent: Friday, October 26, 2018 9:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SORT not behaving consistently

About a hundred years ago I ran into a similar sort issue.
Parallel runs in our pre-production environment did not have sequence matched 
sort outputs. I chased several threads. EQUALS made things match but there is a 
cost. Apparently it was related to sort work DASD. Knowing I could make it 
right with EQUALS was good enough. It was the only way to guarantee a sequence 
of records with matching sort keys. Since I considered the final matching key 
sequence random I just did not care enough to use EQUALS to force a matching 
sequence.


Sent from my iPhone

> On Oct 26, 2018, at 11:35 AM, Seymour J Metz  wrote:
> 
> Be careful what you measure; people will optimize in ways that you didn't 
> anticipate and don't want. What affects perfolrmance is the working set, and 
> a large region is not synonymous with a large working set.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Thursday, October 25, 2018 5:06 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: SORT not behaving consistently
> 
>> On Thu, 25 Oct 2018 20:36:58 +, Jesse 1 Robinson wrote:
>> 
>> OK, I'm simmering down. Here's my concern: I own the SORT product; I own the 
>> CEC; I own the DASD. If I change any of those things and the user's output 
>> differs, then I'm on the spot to explain why. The explanation may not be 
>> difficult, but if a user presses with 'why didn't you tell us this would 
>> happen', I'm on the defensive for an outcome I can't control or even 
>> anticipate. I don't like being on the defensive. You don't score points on 
>> defense even if you survive to battle another day. OK, I'm done.
>> 
> I was once a user of a site that had a chargeback policy and tried
> (desperately) to make the charge for any job repeatable, regardless of 
> background system load, to avoid "Why didn't you tell us this would 
> happen?"  Impossible.  For example, who pays for paging I/O?  If you 
> don't charge for it, you're motivating prodigal REGION use.  They 
> seemed to have the misguided idea that making the formula complicated 
> enough would make it repeatable.
> 
> -- gil


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

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

Re: z/OS BDAM question

2018-10-26 Thread Steve Smith
BDAM implies DSORG DA, but can use any RECFM.  However, DSORG DA files are
usually physically equivalent to DSORG PS, and often are so designated.
However, most DA files I've seen are indeed RECFM=F.

sas

On Fri, Oct 26, 2018 at 11:40 AM Tom Sims  wrote:

> Datacom may use some method of "direct access," but the datasets
> themselves are RECFM=F.

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


Application change for ISAM effects wasRe: SORT not behaving consistently

2018-10-26 Thread Clark Morris
[Default] On 26 Oct 2018 09:45:46 -0700, in bit.listserv.ibm-main
jesse1.robin...@sce.com (Jesse 1 Robinson) wrote:

>My first job in IT had me working on a fairly new application that was 
>designed around an ISAM master file. Shortly before going live, it was 
>discovered that the data center billed application business units for I/O but 
>not for memory usage. So a quick change was instituted to read the entire ISAM 
>file into virtual storage at startup and process it there. I don't know what 
>the savings amounted to, but it was certainly an example of nudging people in 
>an unexpected--and probably unwanted--direction.  
>
What did the change do to CPU time and overall run time?

Clark Morris
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler 
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Cameron Conacher
>Sent: Friday, October 26, 2018 9:01 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: SORT not behaving consistently
>
>About a hundred years ago I ran into a similar sort issue.
>Parallel runs in our pre-production environment did not have sequence matched 
>sort outputs. I chased several threads. EQUALS made things match but there is 
>a cost. Apparently it was related to sort work DASD. Knowing I could make it 
>right with EQUALS was good enough. It was the only way to guarantee a sequence 
>of records with matching sort keys. Since I considered the final matching key 
>sequence random I just did not care enough to use EQUALS to force a matching 
>sequence.
>
>
>Sent from my iPhone
>
>> On Oct 26, 2018, at 11:35 AM, Seymour J Metz  wrote:
>> 
>> Be careful what you measure; people will optimize in ways that you didn't 
>> anticipate and don't want. What affects perfolrmance is the working set, and 
>> a large region is not synonymous with a large working set.
>> 
>> 
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>/> 
>> 
>> From: IBM Mainframe Discussion List  on 
>> behalf of Paul Gilmartin 
>> <000433f07816-dmarc-requ...@listserv.ua.edu>
>> Sent: Thursday, October 25, 2018 5:06 PM
>> To: IBM-MAIN@listserv.ua.edu
>> Subject: Re: SORT not behaving consistently
>> 
>>> On Thu, 25 Oct 2018 20:36:58 +, Jesse 1 Robinson wrote:
>>> 
>>> OK, I'm simmering down. Here's my concern: I own the SORT product; I own 
>>> the CEC; I own the DASD. If I change any of those things and the user's 
>>> output differs, then I'm on the spot to explain why. The explanation may 
>>> not be difficult, but if a user presses with 'why didn't you tell us this 
>>> would happen', I'm on the defensive for an outcome I can't control or even 
>>> anticipate. I don't like being on the defensive. You don't score points on 
>>> defense even if you survive to battle another day. OK, I'm done.
>>> 
>> I was once a user of a site that had a chargeback policy and tried
>> (desperately) to make the charge for any job repeatable, regardless of 
>> background system load, to avoid "Why didn't you tell us this would 
>> happen?"  Impossible.  For example, who pays for paging I/O?  If you 
>> don't charge for it, you're motivating prodigal REGION use.  They 
>> seemed to have the misguided idea that making the formula complicated 
>> enough would make it repeatable.
>> 
>> -- gil
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: SORT not behaving consistently

2018-10-26 Thread Jesse 1 Robinson
My first job in IT had me working on a fairly new application that was designed 
around an ISAM master file. Shortly before going live, it was discovered that 
the data center billed application business units for I/O but not for memory 
usage. So a quick change was instituted to read the entire ISAM file into 
virtual storage at startup and process it there. I don't know what the savings 
amounted to, but it was certainly an example of nudging people in an 
unexpected--and probably unwanted--direction.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cameron Conacher
Sent: Friday, October 26, 2018 9:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SORT not behaving consistently

About a hundred years ago I ran into a similar sort issue.
Parallel runs in our pre-production environment did not have sequence matched 
sort outputs. I chased several threads. EQUALS made things match but there is a 
cost. Apparently it was related to sort work DASD. Knowing I could make it 
right with EQUALS was good enough. It was the only way to guarantee a sequence 
of records with matching sort keys. Since I considered the final matching key 
sequence random I just did not care enough to use EQUALS to force a matching 
sequence.


Sent from my iPhone

> On Oct 26, 2018, at 11:35 AM, Seymour J Metz  wrote:
> 
> Be careful what you measure; people will optimize in ways that you didn't 
> anticipate and don't want. What affects perfolrmance is the working set, and 
> a large region is not synonymous with a large working set.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Thursday, October 25, 2018 5:06 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: SORT not behaving consistently
> 
>> On Thu, 25 Oct 2018 20:36:58 +, Jesse 1 Robinson wrote:
>> 
>> OK, I'm simmering down. Here's my concern: I own the SORT product; I own the 
>> CEC; I own the DASD. If I change any of those things and the user's output 
>> differs, then I'm on the spot to explain why. The explanation may not be 
>> difficult, but if a user presses with 'why didn't you tell us this would 
>> happen', I'm on the defensive for an outcome I can't control or even 
>> anticipate. I don't like being on the defensive. You don't score points on 
>> defense even if you survive to battle another day. OK, I'm done.
>> 
> I was once a user of a site that had a chargeback policy and tried
> (desperately) to make the charge for any job repeatable, regardless of 
> background system load, to avoid "Why didn't you tell us this would 
> happen?"  Impossible.  For example, who pays for paging I/O?  If you 
> don't charge for it, you're motivating prodigal REGION use.  They 
> seemed to have the misguided idea that making the formula complicated 
> enough would make it repeatable.
> 
> -- gil


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


Re: SORT not behaving consistently

2018-10-26 Thread Cameron Conacher
About a hundred years ago I ran into a similar sort issue.
Parallel runs in our pre-production environment did not have sequence matched 
sort outputs. I chased several threads. EQUALS made things match but there is a 
cost. Apparently it was related to sort work DASD. Knowing I could make it 
right with EQUALS was good enough. It was the only way to guarantee a sequence 
of records with matching sort keys. Since I considered the final matching key 
sequence random I just did not care enough to use EQUALS to force a matching 
sequence.


Sent from my iPhone

> On Oct 26, 2018, at 11:35 AM, Seymour J Metz  wrote:
> 
> Be careful what you measure; people will optimize in ways that you didn't 
> anticipate and don't want. What affects perfolrmance is the working set, and 
> a large region is not synonymous with a large working set.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Thursday, October 25, 2018 5:06 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: SORT not behaving consistently
> 
>> On Thu, 25 Oct 2018 20:36:58 +, Jesse 1 Robinson wrote:
>> 
>> OK, I'm simmering down. Here's my concern: I own the SORT product; I own the 
>> CEC; I own the DASD. If I change any of those things and the user's output 
>> differs, then I'm on the spot to explain why. The explanation may not be 
>> difficult, but if a user presses with 'why didn't you tell us this would 
>> happen', I'm on the defensive for an outcome I can't control or even 
>> anticipate. I don't like being on the defensive. You don't score points on 
>> defense even if you survive to battle another day. OK, I'm done.
>> 
> I was once a user of a site that had a chargeback policy and tried
> (desperately) to make the charge for any job repeatable, regardless
> of background system load, to avoid "Why didn't you tell us this
> would happen?"  Impossible.  For example, who pays for paging
> I/O?  If you don't charge for it, you're motivating prodigal REGION
> use.  They seemed to have the misguided idea that making the
> formula complicated enough would make it repeatable.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: z/OS BDAM question

2018-10-26 Thread Tom Sims
Datacom may use some method of "direct access," but the datasets 
themselves are RECFM=F.


Disclaimer, not a Datacom expert, more of a Datacom victim, by way of 
other CA program products.


Tom Sims

On 10/26/2018 8:11 AM, Rob Schramm wrote:

I think I have seen it work for DSNTYPE=LARGE instead of extended format.

Aren't CA Datacom files bdam?  I say that because.. last time i interacted
with Datacom it was only able to use DSNTYPE=LARGE.

Rob Schramm



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


Re: SORT not behaving consistently

2018-10-26 Thread Seymour J Metz
Be careful what you measure; people will optimize in ways that you didn't 
anticipate and don't want. What affects perfolrmance is the working set, and a 
large region is not synonymous with a large working set.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, October 25, 2018 5:06 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: SORT not behaving consistently

On Thu, 25 Oct 2018 20:36:58 +, Jesse 1 Robinson wrote:

>OK, I'm simmering down. Here's my concern: I own the SORT product; I own the 
>CEC; I own the DASD. If I change any of those things and the user's output 
>differs, then I'm on the spot to explain why. The explanation may not be 
>difficult, but if a user presses with 'why didn't you tell us this would 
>happen', I'm on the defensive for an outcome I can't control or even 
>anticipate. I don't like being on the defensive. You don't score points on 
>defense even if you survive to battle another day. OK, I'm done.
>
I was once a user of a site that had a chargeback policy and tried
(desperately) to make the charge for any job repeatable, regardless
of background system load, to avoid "Why didn't you tell us this
would happen?"  Impossible.  For example, who pays for paging
I/O?  If you don't charge for it, you're motivating prodigal REGION
use.  They seemed to have the misguided idea that making the
formula complicated enough would make it repeatable.

-- gil

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

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


Re: z/OS BDAM question

2018-10-26 Thread Chris Hoelscher
Well I'll BDAM

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Friday, October 26, 2018 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] z/OS BDAM question

On Wed, 24 Oct 2018 18:22:04 +, Frank M. Ramaekers wrote:

>want to know if BDAM can be larger than 65535 tracks.   Is this limitation per 
>extent or entire file size.

It seems to depend on how you want to access it.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/d4087.htm

--
Tom Marchant

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, age, 
disability, sex,
sexual orientation, gender identity, or religion. Humana Inc. and its 
subsidiaries do not
exclude people or treat them differently because of race, color, national 
origin, age,
disability, sex, sexual orientation, gender identity, or religion.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


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


Re: z/OS BDAM question

2018-10-26 Thread Tom Marchant
On Wed, 24 Oct 2018 18:22:04 +, Frank M. Ramaekers wrote:

>want to know if BDAM can be larger than 65535 tracks.   Is this limitation per 
>extent or entire file size.

It seems to depend on how you want to access it.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/d4087.htm

-- 
Tom Marchant

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


Re: Comparison Routine - take 2

2018-10-26 Thread Farley, Peter x23353
CBT321 (member COBANALZ) has sample code that uses SYS1.MODGEN(ASAXWC).  The 
macro is not GUPI but is used in several places in JES2, which can be seen in 
SYS1.HASPSRC members for further examples.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, October 26, 2018 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comparison Routine - take 2

That should fulfill the OP's request.

It does not look like what I recall, but it might be the same thing. I think
I saw an example of calling the routine directly, not using an executable
macro.

Was perhaps using
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ia
td100/IATYAXWC-map.htm 

It's a JES3 service, so that would be consistent with my remembering a
reference in some SSI sample or similar.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike LaMartina
Sent: Friday, October 26, 2018 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comparison Routine - take 2

SYS1.MODGEN(ASAXWC)?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, October 26, 2018 6:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comparison Routine - take 2

I am racking my brain. I think perhaps I saw the reference in some SSI
program, either an IBM sample or something from the CBT.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, October 26, 2018 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comparison Routine - take 2

There is a routine as you describe and I am trying to remember where I saw a
reference to it, a couple of months ago. I considered using it but ended up
rolling my own. You can specify the wildcard characters so you could use %
instead of ? a la SQL. I will keep trying to remember.

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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


Re: z/OS BDAM question

2018-10-26 Thread Rob Schramm
I think I have seen it work for DSNTYPE=LARGE instead of extended format.

Aren't CA Datacom files bdam?  I say that because.. last time i interacted
with Datacom it was only able to use DSNTYPE=LARGE.

Rob Schramm

On Thu, Oct 25, 2018, 11:18 PM Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> My personal experience converting two old BDAM-based systems in the past
> (one for an ISV product, one for a user application), is that converting to
> use RRDS is relatively easy (SMOP), gives you much better control of error
> conditions, and performs as well or better even in extreme conditions if
> you make intelligent use of BLSR or SMB to use local caching of buffers.
> Memory is (relatively) cheap, so make the most use of it that you can.
>
> And RRDS can be both extended (> 4Gb file size) and compressed saving much
> disk space, but YMMV depending on the volume of I/O you need to sustain.
> Compression isn't free, though it seems to be quite inexpensive (in CPU
> time) these days, at least on relatively current hardware.
>
> And RRDS is supported in z/VSE as well, making the code more portable if
> you need that option.
>
> HTH
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Frank M. Ramaekers
> Sent: Wednesday, October 24, 2018 2:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: z/OS BDAM question
>
> EXTERNAL EMAIL
>
> I'm a z/VM and z/VSE shop, but we do have a z/OS system and someone in IT
> want to know if BDAM can be larger than 65535 tracks.   Is this limitation
> per extent or entire file size.
>
> From the z/VSE LISTSERV:
> I believe it is 65K tracks per extent with a maximum of 255 extents for
> BDAM, but I can't find any doc to verify that right now.
>
> --
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


Re: Comparison Routine - take 2

2018-10-26 Thread Charles Mills
That should fulfill the OP's request.

It does not look like what I recall, but it might be the same thing. I think
I saw an example of calling the routine directly, not using an executable
macro.

Was perhaps using
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ia
td100/IATYAXWC-map.htm 

It's a JES3 service, so that would be consistent with my remembering a
reference in some SSI sample or similar.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike LaMartina
Sent: Friday, October 26, 2018 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comparison Routine - take 2

SYS1.MODGEN(ASAXWC)?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, October 26, 2018 6:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comparison Routine - take 2

I am racking my brain. I think perhaps I saw the reference in some SSI
program, either an IBM sample or something from the CBT.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, October 26, 2018 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comparison Routine - take 2

There is a routine as you describe and I am trying to remember where I saw a
reference to it, a couple of months ago. I considered using it but ended up
rolling my own. You can specify the wildcard characters so you could use %
instead of ? a la SQL. I will keep trying to remember.

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

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

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


Re: Comparison Routine - take 2

2018-10-26 Thread Mike LaMartina
SYS1.MODGEN(ASAXWC)?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, October 26, 2018 6:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comparison Routine - take 2

I am racking my brain. I think perhaps I saw the reference in some SSI
program, either an IBM sample or something from the CBT.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, October 26, 2018 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comparison Routine - take 2

There is a routine as you describe and I am trying to remember where I saw a
reference to it, a couple of months ago. I considered using it but ended up
rolling my own. You can specify the wildcard characters so you could use %
instead of ? a la SQL. I will keep trying to remember.

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

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


Re: Comparison Routine - take 2

2018-10-26 Thread Charles Mills
I am racking my brain. I think perhaps I saw the reference in some SSI
program, either an IBM sample or something from the CBT.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, October 26, 2018 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comparison Routine - take 2

There is a routine as you describe and I am trying to remember where I saw a
reference to it, a couple of months ago. I considered using it but ended up
rolling my own. You can specify the wildcard characters so you could use %
instead of ? a la SQL. I will keep trying to remember.

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


Re: Comparison Routine - take 2

2018-10-26 Thread Charles Mills
There is a routine as you describe and I am trying to remember where I saw a
reference to it, a couple of months ago. I considered using it but ended up
rolling my own. You can specify the wildcard characters so you could use %
instead of ? a la SQL. I will keep trying to remember.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Morrison
Sent: Friday, October 26, 2018 2:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Comparison Routine - take 2

Hello listers.

 

The answers to my original question were interesting, but not close to what
I am looking for.

 

(By the way, in the original question I scanned for typos before I hit
'send', but of course (good one, Murphy) missed one.  SQU should have been
SQL, of course).

 

The answers covered regular expressions, GREP, and SUPERC.  None of these
are any good to me.

 

I believe there is a routine, either directly callable via a pointer in a
system control block (I have looked in the CVT and ECVT and cannot find
anything), OR a loadable/linkable module that IBM provide.

 

Specifically, it DOES NOT handle general regular expressions, but explicitly
handles just SQL-style 'LIKE' matches, but using '*' instead of '%' (match 0
or more characters, and 'greedy') and '?' instead of '_' (match 1
character).

 

The routine can be easily called from assembler or most high-level
languages.  In my case I want to call it from Assembler, with no LE
environment, so 'C' routines are no good (I could use metal C (assuming that
there is a suitable routine that can be compiled with metal C, or is in the
'standard' metal C support library) but don't want to set up an interface to
it for just one routine.).

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


Re: SORT not behaving consistently

2018-10-26 Thread Tom Marchant
On Thu, 25 Oct 2018 17:51:47 -0500, Paul Gilmartin wrote:

>"Machine independent".  The data type was not "halfword", but "int", defined
>as [-32768,32767] and stated that the effect of assigning a larger value was
>undefined.  Debugger should have enforced.

It should have enforced that the effect of assigning a larger value was 
undefined? 
What does that mean?

-- 
Tom Marchant

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


Comparison Routine - take 2

2018-10-26 Thread Peter Morrison
Hello listers.

 

The answers to my original question were interesting, but not close to what
I am looking for.

 

(By the way, in the original question I scanned for typos before I hit
'send', but of course (good one, Murphy) missed one.  SQU should have been
SQL, of course).

 

The answers covered regular expressions, GREP, and SUPERC.  None of these
are any good to me.

 

I believe there is a routine, either directly callable via a pointer in a
system control block (I have looked in the CVT and ECVT and cannot find
anything), OR a loadable/linkable module that IBM provide.

 

Specifically, it DOES NOT handle general regular expressions, but explicitly
handles just SQL-style 'LIKE' matches, but using '*' instead of '%' (match 0
or more characters, and 'greedy') and '?' instead of '_' (match 1
character).

 

The routine can be easily called from assembler or most high-level
languages.  In my case I want to call it from Assembler, with no LE
environment, so 'C' routines are no good (I could use metal C (assuming that
there is a suitable routine that can be compiled with metal C, or is in the
'standard' metal C support library) but don't want to set up an interface to
it for just one routine.).

 

Peter Morrison

 


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