Comparison Routine - take 2

[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

Re: z/OS BDAM question

[Farley, Peter x23353]

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

Re: Comparison Routine

[David Dai]

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 
performing the comparison. Here is a example:

CMPCOLM 10:137 
NCHGT 'at -??-?? ??:??:??','at -XX-XX XX:XX:XX'
OCHGT 'at -??-?? ??:??:??','at -XX-XX XX:XX:XX'

David Dai 



From:   "Peter Morrison" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   26/10/2018 10:19 AM
Subject:Comparison Routine
Sent by:"IBM Mainframe Discussion List" 



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 routine in z/OS but I cannot
find anything.

 

Anyone have any ideas?

 

Peter Morrison

 


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


Click 
https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== 
 to report this email as spam.



Fundi Software Pty Ltd  2018  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

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

Re: Comparison Routine

[Mike Schwab]

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 Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> 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.
> >
> >I believe there is such a publicly available routine in z/OS but I cannot
> >find anything.
> >
> >Anyone have any ideas?
> >
> /bin/grep
>
> #define _XOPEN_SOURCE
> #include 
> int fnmatch(const char *pattern, const char *string, int flags);
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/rfnmtc.htm
>
> Otherwise, need more context.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Comparison Routine

[Paul Gilmartin]

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.
>
>I believe there is such a publicly available routine in z/OS but I cannot
>find anything.
>
>Anyone have any ideas?
> 
/bin/grep

#define _XOPEN_SOURCE
#include 
int fnmatch(const char *pattern, const char *string, int flags);
   
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/rfnmtc.htm

Otherwise, need more context.

-- 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

[Tony Harminc]

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 web
> site was for sale.

The Wayback Machine has it up to March 2008. Lots of doc, but no
suggestion of how to get the actual compiler. Sigh... So much lost
software.

Tony H.

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

Comparison Routine

[Peter Morrison]

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 routine in z/OS but I cannot
find anything.

 

Anyone have any ideas?

 

Peter Morrison

 


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

Re: Sizing CF Structures

[Peter Bishop]

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 
mention in the PR/SM guide and the various redbooks (Tech Guide, Tech Intro, 
etc.) of what a new level of CFCC will mean for the CF structure sizes.  The 
z14 Tech Intro says this in section 3.7.6:

 Coupling Facility Control Code Level
Various levels (such as 22 and 23) of Coupling Facility Control Code (CFCC) are 
available for the z14. For more information, see IBM Knowledge Center.
CF structure size changes can be expected when moving from one CFCC level to 
another.  Review the CF LPAR size by using the following tools:
 The CFSizer tool is a web-based and is useful when a workload is changed or 
introduced
 The Sizer Utility, which is an authorized z/OS program download, is useful 
when upgrading a CF

Have you tried the Sizer Utility?  I don't have a system to use it on just now 
but it may be worth a shot.  I also found that the CFSizer tool can be a lot of 
work to use and would avoid it if possible  :-)

A ROT:  aside from your usual best-practice monitoring of changes due to usage, 
only change the size if the CFCC code needs it.  After using CFSizer and the 
various inputs it needed for the different structures, I seem to recall having 
to approximately double the GRS structure sizes when we went to z13 and level 
21, and that that ended up being overkill although we left them in place as 
they weren't impacting anything.  DB2 structures and others (RACF, VSAM RLS, 
etc.) were unchanged.  I didn't know about the Sizer Utility then, it may have 
saved us the hassle of making the GRS changes.

These days with "cheap" memory it can pay to oversize the CF LPARs for safety's 
sake.  Also, if you have a sysprog-only Sysplex, which I assume you do as that 
is also best practice, then one can consider resizing CFs with new LPAR 
definitions, structure moves, etc. if it is worth doing so after the initial 
migration is bedded in.  I tend to take a cautious approach to CF operation, as 
I believe you do going by your previous posts.

cheers,
Peter


On Thu, 25 Oct 2018 22:46:13 +, Jesse 1 Robinson  
wrote:

>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 anyone 
>have a ROT for estimating structure sizes for a new CEC? Most structures are 
>probably OK-they usually are-but some may need to increase, an exigency that 
>often does not become apparent until a system gets busy on a Tuesday morning.
>
>We're moving from two z12 CECs to a z14 and a z13s with no sizing problems 
>currently in evidence. Any advice?
>
>
>.
>.
>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
>
>
>--
>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: Sizing CF Structures

[Michael Babcock]

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 Jesse 1 Robinson 
wrote:

> 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 anyone have a ROT for estimating structure sizes for a new CEC? Most
> structures are probably OK-they usually are-but some may need to increase,
> an exigency that often does not become apparent until a system gets busy on
> a Tuesday morning.
>
> We're moving from two z12 CECs to a z14 and a z13s with no sizing problems
> currently in evidence. Any advice?
>
>
> .
> .
> 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
>
>
> --
> 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

[Paul Gilmartin]

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.)
>
>What halfword value is invalid? Surely by definition...
>
>Oh - you mean silent truncation of a larger value into a halfword?
>What does the language (what language?) definition say about this?
>And what did the optimized code do that failed?
> 
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 web
site was for sale.

"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.

The optimized code simply omitted the STH which debugger used only to
examine a value at breakpoint and the LH which allowed debugging to
modify that value.  Optimized code kept the value in a GR.

-- gil

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

Sizing CF Structures

[Jesse 1 Robinson]

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 anyone have 
a ROT for estimating structure sizes for a new CEC? Most structures are 
probably OK-they usually are-but some may need to increase, an exigency that 
often does not become apparent until a system gets busy on a Tuesday morning.

We're moving from two z12 CECs to a z14 and a z13s with no sizing problems 
currently in evidence. Any advice?


.
.
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


--
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

[Tony Harminc]

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 program check on such a condition.)

What halfword value is invalid? Surely by definition...

Oh - you mean silent truncation of a larger value into a halfword?
What does the language (what language?) definition say about this?
And what did the optimized code do that failed?

Tony H.

--
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

[Paul Gilmartin]

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

[Paul Gilmartin]

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 say that most installations have EQUALS as their default.
> 
This is barely tolerable, only given that DFSORT (may I guess SYNCSORT also?)
allows an overriding(?) NOEQUALS option.  Installations should think twice 
(several
times) before altering a vendor's default.  Consistency, and KISS.  At least, it
invalidates the vendor's documentation (ignoring an absurd suggestion that each
site should provide a local copy of vendor's documentation tailored to reflect
installation defaults.)

Should an ISV test its code according to the primary vendor's defaults?  To the
modal installation defaults?  Both?  That can exponentially increase the number
of required test cases.

-- 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

[Jesse 1 Robinson]

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.  

.
.
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 Paul Gilmartin
Sent: Thursday, October 25, 2018 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SORT not behaving consistently

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" 
>variable.
> 
Mostly agree.  But once I was furious with a compiler vendor when my program 
got fixed-point overflow when optimized and operated as I intended when I 
compiled in debug mode.  Vendor said WAD; the construct I depended on was 
documented as unpredictable.  Grrr.  Any errors detected in production mode 
should be reported in debug mode, especially if the unspecified behavior is 
deterministic.

(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.)

-- gil


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

Determinism (was: SORT not behaving consistently)

[Paul Gilmartin]

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 this can vary is due to the amount of memory available on the system
>since that can impact which sort technique is used.  If an incore sort is
>done, it's likely (but not definite) that records with the same key may
>retain their original sequence.  If work files are used (be they memory
>object, Hiperspace or disk sortwk), then records with the same key value
>might get dispersed to different work files and in the output phase be
>merged in a different sequence.  Since DFSORT adapts to available
>resources, it is not surprising to see this variance.  The whole reason we
>have the EQUALS parameter, is for situations where maintaining the original
>sequence is required.
>
+1

An insightful analysis.  And EQUALS isn't/shouldn't be the default because it
may affect performance adversely.

But there shouldn't be as many installation default options as other plies
have suggested.  Programmer skills should be left as portable as possible.
Even as I'm irritated when a site aliases "rm" to "rm -i", "mv" to "mv -i",
and "ls" to "ls -F".  (They're Only Trying to Help Me.  Grrr.)

Farther off, but somehow related, I was shocked to discover that SQL/DS (DB2
for CMS?) allows duplicate rows in a table.  That can barely be described in set
theoretic terms.  I know; assign a unique index to prevent duplicates.

-- 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

[Paul Gilmartin]

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" 
>variable.
> 
Mostly agree.  But once I was furious with a compiler vendor when my program
got fixed-point overflow when optimized and operated as I intended when I
compiled in debug mode.  Vendor said WAD; the construct I depended on was
documented as unpredictable.  Grrr.  Any errors detected in production mode
should be reported in debug mode, especially if the unspecified behavior is
deterministic.

(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.)

-- 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

[Christopher Y. Blaicher]

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 intermediate string is, which in turn effects 
how the final merge will run.

Both DFSORT and Syncsort have an EQUALS parameter, both as a job option and as 
a default installation option.

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 say that most installations have EQUALS as their default.

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: Thursday, October 25, 2018 2:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT not behaving consistently

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 should matter to 
all of us. 

.
.
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 Beesley, Paul
Sent: Thursday, October 25, 2018 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SORT not behaving consistently

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: Thursday, October 25, 2018 5:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT not behaving consistently

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 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 machine, and then 
> running the identical sort against identical data on the new setup, they get 
> several records in a different order.
> Seems they are sorting on the first 21 characters or so, and it is doing that 
> fine, but the order of the records beyond that is a bit random, whereas on 
> the new system they are in the same order as the input.
> On the new system it's almost like EQUALS is coded, but it's not.
> Hope that makes sense.
> Any ideas what would cause this (repeatable) difference in the outcome ... 
> faster machine? Faster disks?
> Paul


--
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

[Charles Mills]

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 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, October 25, 2018 2:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT not behaving consistently

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 should matter to 
all of us. 

.
.
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 Beesley, Paul
Sent: Thursday, October 25, 2018 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SORT not behaving consistently

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: Thursday, October 25, 2018 5:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT not behaving consistently

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 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 machine, and then 
> running the identical sort against identical data on the new setup, they get 
> several records in a different order.
> Seems they are sorting on the first 21 characters or so, and it is doing that 
> fine, but the order of the records beyond that is a bit random, whereas on 
> the new system they are in the same order as the input.
> On the new system it's almost like EQUALS is coded, but it's not.
> Hope that makes sense.
> Any ideas what would cause this (repeatable) difference in the outcome ... 
> faster machine? Faster disks?
> Paul


--
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

[David Betten]

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 system
since that can impact which sort technique is used.  If an incore sort is
done, it's likely (but not definite) that records with the same key may
retain their original sequence.  If work files are used (be they memory
object, Hiperspace or disk sortwk), then records with the same key value
might get dispersed to different work files and in the output phase be
merged in a different sequence.  Since DFSORT adapts to available
resources, it is not surprising to see this variance.  The whole reason we
have the EQUALS parameter, is for situations where maintaining the original
sequence is required.


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
email:  bet...@us.ibm.com


IBM Mainframe Discussion List  wrote on
10/25/2018 02:37:24 PM:

> From: Jesse 1 Robinson 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 10/25/2018 02:38 PM
> Subject: Re: SORT not behaving consistently
> Sent by: IBM Mainframe Discussion List 
>
> 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 should matter to all of us.
>
> .
> .
> 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 Beesley, Paul
> Sent: Thursday, October 25, 2018 11:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: SORT not behaving consistently
>
> 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: Thursday, October 25, 2018 5:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SORT not behaving consistently
>
> 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 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 machine,
> and then running the identical sort against identical data on the
> new setup, they get several records in a different order.
> > Seems they are sorting on the first 21 characters or so, and it is
> doing that fine, but the order of the records beyond that is a bit
> random, whereas on the new system they are in the same order as the
input.
> > On the new system it's almost like EQUALS is coded, but it's not.
> > Hope that makes sense.
> > Any ideas what would cause this (repeatable) difference in the
> outcome ... faster machine? Faster disks?
> > Paul
>
>
> --
> 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

[Jesse 1 Robinson]

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 should matter to 
all of us. 

.
.
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 Beesley, Paul
Sent: Thursday, October 25, 2018 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SORT not behaving consistently

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: Thursday, October 25, 2018 5:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT not behaving consistently

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 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 machine, and then 
> running the identical sort against identical data on the new setup, they get 
> several records in a different order.
> Seems they are sorting on the first 21 characters or so, and it is doing that 
> fine, but the order of the records beyond that is a bit random, whereas on 
> the new system they are in the same order as the input.
> On the new system it's almost like EQUALS is coded, but it's not.
> Hope that makes sense.
> Any ideas what would cause this (repeatable) difference in the outcome ... 
> faster machine? Faster disks?
> Paul


--
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

[Beesley, Paul]

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: Thursday, October 25, 2018 5:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT not behaving consistently

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 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 machine, and then 
> running the identical sort against identical data on the new setup, they get 
> several records in a different order.
> Seems they are sorting on the first 21 characters or so, and it is doing that 
> fine, but the order of the records beyond that is a bit random, whereas on 
> the new system they are in the same order as the input.
> On the new system it's almost like EQUALS is coded, but it's not.
> Hope that makes sense.
> Any ideas what would cause this (repeatable) difference in the outcome ... 
> faster machine? Faster disks?
> Paul
>
> Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are 
> trading names used by the Atos group. The following trading entities are 
> registered in England and Wales: Atos IT Services UK Limited (registered 
> number 01245534), Atos Consulting Limited (registered number 04312380), Atos 
> Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud 
> Company Limited (registration number 08011902). The registered office for 
> each is at Second Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.  
> The VAT No. for each is: GB232327983.
>
> This e-mail and the documents attached are confidential and intended solely 
> for the addressee, and may contain confidential or privileged information. If 
> you receive this e-mail in error, you are not authorised to copy, disclose, 
> use or retain it. Please notify the sender immediately and delete this email 
> from your systems. As emails may be intercepted, amended or lost, they are 
> not secure. Atos therefore can accept no liability for any errors or their 
> content. Although Atos endeavours to maintain a virus-free network, we do not 
> warrant that this transmission is virus-free and can accept no liability for 
> any damages resulting from any virus transmitted. The risks are deemed to be 
> accepted by everyone who communicates with Atos by email.
>
> --
> 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
Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading 
names used by the Atos group. The following trading entities are registered in 
England and Wales: Atos IT Services UK Limited (registered number 01245534), 
Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited 
(registered number 08514184) and Canopy The Open Cloud Company Limited 
(registration number 08011902). The registered office for each is at Second 
Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.  The VAT No. for each 
is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

--
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

[Charles Mills]

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 Conacher
Sent: Thursday, October 25, 2018 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT not behaving consistently

So are you saying that the order of records with identical keys is different
machine to machine?
Does that matter?

--
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

[Cameron Conacher]

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 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 machine, and then 
> running the identical sort against identical data on the new setup, they get 
> several records in a different order.
> Seems they are sorting on the first 21 characters or so, and it is doing that 
> fine, but the order of the records beyond that is a bit random, whereas on 
> the new system they are in the same order as the input.
> On the new system it's almost like EQUALS is coded, but it's not.
> Hope that makes sense.
> Any ideas what would cause this (repeatable) difference in the outcome ... 
> faster machine? Faster disks?
> Paul
> 
> Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are 
> trading names used by the Atos group. The following trading entities are 
> registered in England and Wales: Atos IT Services UK Limited (registered 
> number 01245534), Atos Consulting Limited (registered number 04312380), Atos 
> Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud 
> Company Limited (registration number 08011902). The registered office for 
> each is at Second Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.  
> The VAT No. for each is: GB232327983.
> 
> This e-mail and the documents attached are confidential and intended solely 
> for the addressee, and may contain confidential or privileged information. If 
> you receive this e-mail in error, you are not authorised to copy, disclose, 
> use or retain it. Please notify the sender immediately and delete this email 
> from your systems. As emails may be intercepted, amended or lost, they are 
> not secure. Atos therefore can accept no liability for any errors or their 
> content. Although Atos endeavours to maintain a virus-free network, we do not 
> warrant that this transmission is virus-free and can accept no liability for 
> any damages resulting from any virus transmitted. The risks are deemed to be 
> accepted by everyone who communicates with Atos by email.
> 
> --
> 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

[Sri h Kolusu]

>>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 on both jobs and re-run the jobs and send me the complete job
output.  (am on vacation , so the response might be delayed)

I also want to see the installation defaults on both machines. You can run
the following job to list the installation defaults

//STEP0100 EXEC PGM=ICETOOL
//TOOLMSG   DD SYSOUT=*
//DFSMSGDD SYSOUT=*
//OUT   DD SYSOUT=*
//TOOLINDD *
  DEFAULTS LIST(OUT)
/*

Thanks,
 Kolusu
DFSORT Development
IBM Corporation


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

SORT not behaving consistently

[Beesley, Paul]

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 machine, and then 
running the identical sort against identical data on the new setup, they get 
several records in a different order.
Seems they are sorting on the first 21 characters or so, and it is doing that 
fine, but the order of the records beyond that is a bit random, whereas on the 
new system they are in the same order as the input.
On the new system it's almost like EQUALS is coded, but it's not.
Hope that makes sense.
Any ideas what would cause this (repeatable) difference in the outcome ... 
faster machine? Faster disks?
Paul

Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading 
names used by the Atos group. The following trading entities are registered in 
England and Wales: Atos IT Services UK Limited (registered number 01245534), 
Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited 
(registered number 08514184) and Canopy The Open Cloud Company Limited 
(registration number 08011902). The registered office for each is at Second 
Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.  The VAT No. for each 
is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

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

Re: SMP/E

[John Eells]

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

Re: SMP/E

[Kurt Quackenbush]

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.
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.



This seems to address the end customer's point of view.  Is there
something similar, either from IBM or from CA, addressing the fellow
ISV's point of view? Did CA reverse-engineer IBM's process, or bribe
IBM to share it?  (I read only the first page.)


No reverse engineering or bribery was required, just a polite request. 
If any other ISV is interested in creating their own Automated Service 
Request server to handle SMP/E RECEIVE ORDER requests for their PTFs, 
feel free to contact me off-list.


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: DCB Open Exit

[Peter Relson]

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 (mapped by IHALDAX) was introduced in z/OS 2.2. 

Peter Relson
z/OS Core Technology Design


--
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

[R.S.]

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 extent with a maximum of 255 extents for BDAM, 
but I can't find any doc to verify that right now.

BDAM (DSORG=DA) dataset is limited to 64k TRKs. Whole dataset, not extent.
There are other limitations regarding extents.

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: z/OS Client Web Enablement Toolkit sample

[Steve Austin]

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 sample

Hi Steve,

I'm one of the developers working on z/OS Client Web Enablement Toolkit.

The updated connection URI is https://soa.smext.faa.gov and the updated request 
URI is /asws/api/airport/status/jfk

The connection type has been upgraded from HTTP to HTTPS. If you do not utilize 
AT-TLS, or if there is not a AT-TLS policy enabled for the connection to this 
FAA server, you may need to set additional SSL/TLS support options in your 
application. These options include turning on SSL/TLS, and telling toolkit the 
location of your certificate store (HWTH_OPT_USE_SSL, HWTH_OPT_SSLKEY, 
HWTH_OPT_SSLKEYTYPE options).   

See this link for more details:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieac100/ieac1-cwe-http-options.htm

We understand that having a working sample is a priority to you and we are 
working on getting the sample updated as soon as we possibly can.   
We hope to have something shipped very soon.

Galina Gorelik

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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

--
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

[Giliad Wilf]

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 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.
>
>Frank M. Ramaekers Jr. | Systems Programmer | Information Technology | 
>American Income Life Insurance Company | 254-761-6649 (732-6649)
>
>--
>This message contains information which is privileged and confidential and is 
>solely for the use of the intended recipient. If you are not the intended 
>recipient, be aware that any review, disclosure, copying, distribution, or use 
>of the contents of this message is strictly prohibited. If you have received 
>this in error, please destroy it immediately and notify us at 
>privacy...@torchmarkcorp.com.
>
>--
>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: We're IST-2IDT, and switching back from UTC+3 to UTC+2 at 2AM Oct. 28th

[Giliad Wilf]

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 on Sunday, Oct. 28th, Israel is switching from IDT to IST.
>>...
>>... We ... as far as I know, do not rely on local time.
>> 
>???
>
>If you "do not rely on local time", how can timezones and offsets matter to 
>you?
>
>-- 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