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
You may want to look at NCHGT and OCHGT process statements of SuperC
compare utility
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54u200/ispu2220.htm
. '?' can be used to match one character
The ideas is that you can 'mask' fields in the old and new files before
z/OS regular expressions.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/regexpa.htm
https://www.idug.org/p/bl/et/blogaid=670
https://www.pcre.org/ Pearl Compatable Regular Expression for z/OS
at CBT TAPE FILE 939.
On Thu, Oct 25, 2018 at 9:29 PM Paul
On Fri, 26 Oct 2018 13:18:31 +1100, Peter Morrison wrote:
>
>I am trying to find details on a comparison routine that can be used in
>z/OS, that allows you to compare a field against a pattern similar to the
>SQU 'LIKE' operator - where '*' matches 0 or more characters and '?' matches
>just one.
>
On 25 October 2018 at 18:51, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> Mainsail, one of my most enjoyable programming experiences:
> https://en.wikipedia.org/wiki/SAIL_(programming_language)
>
> An embryonic attempt at O-O. Alas, several years ago the vendor's
Hello,
I am trying to find details on a comparison routine that can be used in
z/OS, that allows you to compare a field against a pattern similar to the
SQU 'LIKE' operator - where '*' matches 0 or more characters and '?' matches
just one.
I believe there is such a publicly available
I break it into two parts: hardware-motivated size changes and
software-motivated ones. Normally the latter are fairly predictable, e.g.
based on usage, etc. Here you say there is no indication of any change there.
The former are somewhat sparsely documented in my view, but there is usually
When we went to a z14-ZR1 we had to increase the size of one of our RRS
structures. RRS wouldn’t come up since the min size changed with the new
CFCC level. Had to have 3M instead of 2M. Don’t remember which one off
the top of my head. I can check if you like.
On Thu, Oct 25, 2018 at 5:46 PM
On Thu, 25 Oct 2018 17:16:49 -0400, Tony Harminc wrote:
>
>> (In debug mode, the compiler generated STH; LH of a halfword variable not
>> otherwise referenced, truncating an invalid halfword value. Even before
>> that,
>> I had felt that by design STH should program check on such a condition.)
We've played the game of sizing CF structures for two decades. About to play it
yet again. The main problem is that the sizing tool asks for some input for
most structures, and that input is itself a SWAG. Without spending an
inordinate amount of time researching the current environment, does
On 25 October 2018 at 16:12, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> (In debug mode, the compiler generated STH; LH of a halfword variable not
> otherwise referenced, truncating an invalid halfword value. Even before that,
> I had felt that by design STH should
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
On Thu, 25 Oct 2018 19:56:19 +, Christopher Y. Blaicher wrote:
>
>If reproducibility of record sequences is important, then use the EQUALS
>option. It adds to the key length, but nothing comes for free, although it
>would have to be a pretty huge sort to notice the difference.
>
>I would
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
On Thu, 25 Oct 2018 14:48:24 -0400, David Betten wrote:
>If EQUALS is in effect, then DFSORT will always preserve the original order
>of records with the same key value. If EQUALS is not in effect, then it is
>possible for the sequence of records with the same key value to vary. One
>reason
On Thu, 25 Oct 2018 14:58:40 -0400, Charles Mills wrote:
>I think I respectfully disagree. Sometimes particular combinations of options
>yield unspecified behavior. Sure, computers are generally deterministic but
>the results might be dependent on region size or some other "irrelevant"
Jesse,
Each sort does optimization, not just each sort product, but each sort
executed. There are a lot of factors that go into optimization like memory
layout, other work running on the machine, what disk drives are available.
Lots of other things also.
Now, that effects how long each
I think I respectfully disagree. Sometimes particular combinations of options
yield unspecified behavior. Sure, computers are generally deterministic but the
results might be dependent on region size or some other "irrelevant" variable.
Charles
-Original Message-
From: IBM Mainframe
If EQUALS is in effect, then DFSORT will always preserve the original order
of records with the same key value. If EQUALS is not in effect, then it is
possible for the sequence of records with the same key value to vary. One
reason this can vary is due to the amount of memory available on the
I for one find this discrepancy highly disturbing unless it can be tracked down
to an unintended difference in SORT options. Like it or not, a program should
give consistent results on every execution wherever it's run. Whether it
matters to the user in this particular case is not germane. It
My thought exactly. Apparently it does... which, as Charles Mills correctly
says, the rest of the fields should be part of the sort key or they should use
EQUALS.
Regards and thanks
Paul
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Cameron Conacher
Sent:
If the order of records matters then the "matter" should be part of the sort
key (or EQUALS).
Otherwise it could change machine to machine or PTF to PTF or day to day.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Cameron
So are you saying that the order of records with identical keys is different
machine to machine?
Does that matter?
Sent from my iPhone
> On Oct 25, 2018, at 12:23 PM, Beesley, Paul wrote:
>
> Hi
>
> Have been asked to investigate reasons for an identical DFSORT behaving
> differently on 2
>>On the new system it's almost like EQUALS is coded, but it's not.
Paul,
Most likely it is EQUALS that might cause this type of issue. Did you run
to see if the installation defaults match on both machines?
If you want DFSORT team to diagnose the issue, then please code //SORTDIAG
DD DUMMY
Hi
Have been asked to investigate reasons for an identical DFSORT behaving
differently on 2 machines.
We are transitioning a service which is currently on a zEC12 to a z14 machine,
and the disks are currently HP9500, moving to IBM DS8886.
When they run sort of multi-thousand records on the old
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
On 10/24/2018 7:09 PM, Paul Gilmartin wrote:
On Wed, 24 Oct 2018 22:12:45 +, Longabaugh, Robert E wrote:
CA has offered Internet Service Retrieval (RECEIVE ORDER) since
January 2018.
LDA vs VSMLIST: I would use neither.
If you're trying to make a decision based on the amount of user-region
storage that is available or something else related to private storage,
then consider the LDAX.
While fields in the LDA are not programming interfaces, fields in the LDAX
are.
The LDAX
W dniu 2018-10-24 o 20:22, Frank M. Ramaekers pisze:
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
Thanks for your timely and helpful response Galina.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Galina Gorelik
Sent: Wednesday, October 24, 2018 8:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Client Web Enablement Toolkit
You can't.
BDAM does not support DSNTYPE=LARGE.
Giliad
On Wed, 24 Oct 2018 18:22:04 +, Frank M. Ramaekers
wrote:
>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
Good question.
Developers here do not rely on local time, but I want them to always see local
time.
It has something to do with human perception of "reality".
Giliad
On Wed, 24 Oct 2018 16:30:24 -0500, Paul Gilmartin wrote:
>On Wed, 24 Oct 2018 02:38:39 -0500, Giliad Wilf wrote:
>>
>>At 2AM
If you use the Relative Block Address the dataset can be much larger.
Mikael Nyström
Core Ledger
SEB
Phone: +46 70 739 48 55
Switchboard: +46 771 62 10 00
Postal Address: A-B9, SE-106 40 Stockholm, Sweden
Office Address: Stjarntorget 4
E-mail: mikael.nyst...@seb.se
www.seb.se
? Please
33 matches
Mail list logo
