Re: DFHSM query command from Console

[Lizette Koehler]

Some presentations and Documents on DFHSM
ftp://ftp.software.ibm.com/software/iea/content/com.ibm.iea.zos/zos/1.0/DFSMS/BestPractices1.pdf

https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.arci000/moncjds.htm

Attention: Do not attempt to reorganize your control data sets while DFSMShsm 
is running on any processor that uses those control data sets.

http://www-01.ibm.com/support/docview.wss?uid=isg3S1001120

http://www-01.ibm.com/support/docview.wss?uid=isg3T1023389



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Friday, October 14, 2016 7:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM query command from Console
> 
> We take down DFHSM, using IDCAMS allocate a new one, repro the old one to the
> new one, just for protection we then rename the current to .OLD and .NEW to
> Current
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Peter
> > Sent: Friday, October 14, 2016 6:27 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: DFHSM query command from Console
> >
> > Hi Liz/All
> >
> > If the MCDS is full. Can we dynamically resize  without an IPL ? Or
> > else are there any scheduled batch job that can reorg the MCDS ?
> >
> > On Oct 14, 2016 9:24 PM, "Lizette Koehler"  wrote:
> >
> > > What are you looking for?  The name of the MCDS?  Or information in
> > > the MCDS/BCDS and so forth?
> > >
> > > If the later, look up the LIST command in the HSM Admin manual and
> > > issue F hsmstcname,LIST yada yada yada ODS('where you want the
> > > output to go')
> > >
> > > HSM will create the ODS dataset for your or mod onto it if it exits.
> > >
> > > Lizette
> > >
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List
> > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter
> > > > Sent: Friday, October 14, 2016 8:14 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: DFHSM query command from Console
> > > >
> > > > Hi
> > > >
> > > > Is it possible to query MCDS dataset usage from master console ?
> > > >
> > > > I apologize as I am new to DFHSM.
> > > >
> > > > Peter
> 

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

Re: DFHSM query command from Console

[Lizette Koehler]

We take down DFHSM, using IDCAMS allocate a new one, repro the old one to the 
new one, just for protection we then rename the current to .OLD and .NEW to 
Current

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: Friday, October 14, 2016 6:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM query command from Console
> 
> Hi Liz/All
> 
> If the MCDS is full. Can we dynamically resize  without an IPL ? Or else are
> there any scheduled batch job that can reorg the MCDS ?
> 
> On Oct 14, 2016 9:24 PM, "Lizette Koehler"  wrote:
> 
> > What are you looking for?  The name of the MCDS?  Or information in
> > the MCDS/BCDS and so forth?
> >
> > If the later, look up the LIST command in the HSM Admin manual and
> > issue F hsmstcname,LIST yada yada yada ODS('where you want the output
> > to go')
> >
> > HSM will create the ODS dataset for your or mod onto it if it exits.
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter
> > > Sent: Friday, October 14, 2016 8:14 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: DFHSM query command from Console
> > >
> > > Hi
> > >
> > > Is it possible to query MCDS dataset usage from master console ?
> > >
> > > I apologize as I am new to DFHSM.
> > >
> > > Peter

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

Re: DFHSM query command from Console

[Peter]

Hi Liz/All

If the MCDS is full. Can we dynamically resize  without an IPL ? Or else
are there any scheduled batch job that can reorg the MCDS ?

On Oct 14, 2016 9:24 PM, "Lizette Koehler"  wrote:

> What are you looking for?  The name of the MCDS?  Or information in the
> MCDS/BCDS and so forth?
>
> If the later, look up the LIST command in the HSM Admin manual and issue
> F hsmstcname,LIST yada yada yada ODS('where you want the output to go')
>
> HSM will create the ODS dataset for your or mod onto it if it exits.
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Peter
> > Sent: Friday, October 14, 2016 8:14 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: DFHSM query command from Console
> >
> > Hi
> >
> > Is it possible to query MCDS dataset usage from master console ?
> >
> > I apologize as I am new to DFHSM.
> >
> > Peter
>
> --
> 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: Running USS with locale other than 1047

[Paul Gilmartin]

On Fri, 14 Oct 2016 16:24:18 -0400, Rick Troth wrote:
>
>The advantage in the non-EBCDIC* world is that the lower half of 8-bit
>space is rather more consistent. And that space is where we have some
>serious trouble on this side of the line (pipe symbol versus
>exclamation, square brackets, curly braces).
> 
At least they should have stabilized the graphemes in the s/360 PrincOps.
But that might still leave conflicts among caret, logical not and pipe, leaky
pipe.

>... The result of the SHARE effort was what some call
>"Code Page 37 version 2". IBM never fully took-up the customer-produced
>code page, but they did listen and they gave us CP 1047.
>
Feels as if CP37V2 fell victim to pernicious NIH.  I suspect IBM still doesn't
have a CCSID matching CP37V2.


>CP 1047 is the best we have, if we are to live in the world IBM has
>created for us.
> 
Ref. Elon Musk.

>There is still the problem that a stream of bytes might not be
>recognized. Tagging files with charset ABC or code page 123 is clumsy at
>best.
>
"It's the best we have," but not available for Classic data sets.
The non-EBCDIC world gets along nicely with no tagging and a
presumption of UTF-8.

>This is where even Dignus doesn't quite get it: They translate EBCDIC
>0x15 to non-EBCDIC 0x0A. (Actual non-EBCDIC for "newline" is 0x85.) But
>their table only helps with the above test, and _makes sense_ for cases
>where someone did an un-measured translation. So I can't fault them.
>
CMS Pipelines (perhaps other CMS utilities) use 0x25 instead of 0x15.
There's some very Bad History behind all this.

>Once the result of the EBCDIC (or not) check is known, one can apply
>locale and "convert" appropriately. i.e., beyond the cramped walls of
>8-bit space.
>
But one must somehow know locale to differentiate among ISO-8859-x
and UTF-8 and the far greater number of EBCDIC CCSIDs.

>* I say non-EBCDIC here because "ASCII" has baggage for many. Y'all know
>what I mean.
>
Yes, but he hasn't been active on these lists for several months.

Answering my question earlier in this thread, I used ISPF 3.17
with an IBM-1047 terminal to view a UTF-8 file containing the 1047
character matrix.  Displayed splendidly (Yaaay!)  Then I used the
ISPF Edit Copy command to append another copy of the same file
(same tags, of course).  It appears garbled.  They could have done
better.  If the active file is UTF-8 (pretty universal) and the copied
file is fully tagged, Copy might be expected either to convert it also
to UTF-8 or copy it in literally.  Neither seems to have happened.

-- gil

I suppose I can mail my test data off-list to anyone interested.

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

Re: COBOL warnings [was:ABO Automatic Binary Optimizer]

[Farley, Peter x23353]

Bill,

You're not wrong about those kinds of COBOL warnings.  No "stupid perform" 
program passes a code review that I am tasked with, but I do have to say I've 
never seen one.

The failure to use scope terminators is unfortunately a very personal "style" 
issue when it is not directly addressed by any company-wide standard.  I have 
had co-workers who flat refused to use them except where absolutely required 
(like in the context of another IF or ELSE or PERFORM).  They tended to be 
quite careful users of "full stop/period" terminators though, so they weren't 
generating any bugs that I saw.

And yes, you may assume "we are not the owner of the copybook, so (we) can't 
change it", so even adding a FILLER is not possible (we're not even authorized 
to bring another group's COPY book into a change setup).  And I am not in any 
position to write or create a COBOL "message exit" for the standard compilation 
system, that is controlled by others.  I may suggest a change to a COPY member 
to the owning group, but "it will be have to be prioritized below other 
important work . . . ".

As for confronting auditors, again I am far from their environments.  I've 
never actually seen one at my current employer, they never get down to our 
level.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Friday, October 14, 2016 5:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

Peter, 

The RC=4 thing was not directed at you. I don't think anyone with "experience" 
(being counted as just turning up for years, or "one year of experience many 
times") would be contributing to this list.

I'm pointing out that "RC=4 is OK, get on with the test" is reasonably common. 
And with such systems, whether implied from one of the diagnostic messages, or 
simply associated with the sloppiness of the method, *I guarantee there are 
careless bugs in the system*. 

Someone sent me a program a couple of weeks ago. Numerous W and I diagnostics, 
including the interesting "hey, here's a SECTION, the prior paragraphs aren't 
within SECTIONs, watch it buddy, could be very bad" message.

Looking at the program, written originally in the early 80s and changed a 
number of times since, you could see that it had started out fairly well, and 
was still quite readable. Whereas when written, the full-stop/period in the 
PROCEDURE DIVISION had much greater significance, once using compilers which 
didn't require it, most, but not all, new statements were terminated with a 
full-stop/period (so they had become sloppy), and also no END- scope 
terminators were used. So, you immediately expect to find an IF where the 
indentation shows one intention, and the code (presence or absence of 
full-stop/period) shows reality. Lo, there it was.

They had become sloppy, and sloppy always costs.

Take the stupid PERFORM. Here's an example program:

 

Now, the diagnostic, only a W, is indicating you may have a problem. Anyone who 
reads that and leaves it is... only superseded by anyone who doesn't even read 
it because "RC=4 is OK".

Back to your REDEFINES in copybooks. I'll assume that "we are not the owner of 
the copybook, so can't change it". If that is the case, that is where auditors 
are your friends - play the "sloppy" story to them, and explain that it is 
unacceptable (to you) that such practice is acceptable from an audit point of 
view.

If that has no direct impact, and you have at least V4.2, you can use a 
"message exit" for the compiler (can be written in COBOL even) which "upgrades" 
the status of any W and I that you select. Then your programs won't compile. 
Then they'll have to change the copybook?

Or are we driven back to "if we change the copybook, we have to recompile and 
change, and test, 200 programs". Well, if you only fix those REDEFINES with 
FILLERs (explicit or implicit) then a) you don't *need* to recompile any 
program just for the copybook change b) if you do recompile anything/everything 
then the object code *should be identical* c) if proven identical (except for 
date/time of compile) then it is already as tested as the current version d) if 
not proved identical you know that something else is wrong and whatever that 
is, it is unexpected for your test cases.

Now, I'd like to run that past an auditor if I was in a position to do so, even 
if only to become aware of their response.
--


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.

Re: ICETOOL Question

[Lizette Koehler]

Mark,

Did you check out the material on ibm website for ICETOOL?  It is pretty much a
4GL type language.  Here is the URL and a brief Blurb for those that do not know
ICETOOL

ftp://ftp.software.ibm.com/storage/dfsort/mvs/sorttool.pdf

This paper is a mini-user guide for DFSORT's versatile ICETOOL data processing
and reporting utility.  The major
features of ICETOOL for z/OS DFSORT V1R10 (used for z/OS 1.10 and z/OS 1.11) and
z/OS DFSORT V1R12 (used for z/OS 1.12), including its JCL and control
statements, are discussed at length using many examples.  The objective is to
show you how to use DFSORT's ICETOOL to accomplish complex tasks

ICETOOL, a versatile data set processing and reporting utility, provides an
easy-to-use batch front-end for DFSORT.  ICETOOL combines new features with
previously available DFSORT features to perform complex sorting, copying,
merging, reporting and analytical tasks using multiple data sets in a single job
step.  ICETOOL was first introduced in DFSORT Release 11.1 and was significantly
enhanced in each subsequent DFSORT release.
The many enhancements to ICETOOL through October, 2010 are reflected in this
paper.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mark Jacobs - Listserv
> Sent: Friday, October 14, 2016 1:10 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ICETOOL Question
> 
> Before I dig into the books, does anyone have an ICETOOL example that does
> this;
> 
> Copy all records in a file has these fields
> 
>    B   CCC  D
> 
> to a different file in this field order
> 
>      
> --
> 
> Mark Jacobs
> Time Customer Service
> Global Technology Services
> 
> The standard you walk past is the standard you accept.
> Lt. Gen. David Morrison
> 
> 

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

Re: ABO Automatic Binary Optimizer

[Bill Woodger]

Peter, 

The RC=4 thing was not directed at you. I don't think anyone with "experience" 
(being counted as just turning up for years, or "one year of experience many 
times") would be contributing to this list.

I'm pointing out that "RC=4 is OK, get on with the test" is reasonably common. 
And with such systems, whether implied from one of the diagnostic messages, or 
simply associated with the sloppiness of the method, *I guarantee there are 
careless bugs in the system*. 

Someone sent me a program a couple of weeks ago. Numerous W and I diagnostics, 
including the interesting "hey, here's a SECTION, the prior paragraphs aren't 
within SECTIONs, watch it buddy, could be very bad" message.

Looking at the program, written originally in the early 80s and changed a 
number of times since, you could see that it had started out fairly well, and 
was still quite readable. Whereas when written, the full-stop/period in the 
PROCEDURE DIVISION had much greater significance, once using compilers which 
didn't require it, most, but not all, new statements were terminated with a 
full-stop/period (so they had become sloppy), and also no END- scope 
terminators were used. So, you immediately expect to find an IF where the 
indentation shows one intention, and the code (presence or absence of 
full-stop/period) shows reality. Lo, there it was.

They had become sloppy, and sloppy always costs.

Take the stupid PERFORM. Here's an example program:

   IDENTIFICATION DIVISION. 
   PROGRAM-ID. STAB59. 
   DATA DIVISION. 
   WORKING-STORAGE SECTION. 
   PROCEDURE DIVISION. 
   DISPLAY "GOING TO B" 
   PERFORM B THRU A 
   DISPLAY "COMING BACK FROM... A?" 
   GOBACK 
   . 
   A. 
   DISPLAY "IN A" 
   . 
   B. 
   DISPLAY "IN B" 
   . 

Compile that, and you get: 

 7  IGYPA3086-W   "PERFORM" start-of-range "B" follows the "PERFORM" 
end-of-range "A".  The "PERFORM" end-of-range may be unreachable.  The 
statement was processed as written. 
 

Run it and you get this:

GOING TO B  
  
IN B
  
IGZ0037S The flow of control in program STAB59 proceeded beyond the last line 
of the program. 
 From compile unit STAB59 at entry point STAB59 at compile unit offset 
+039E at entry offset +039E at 
 address 1210039E.  
  

Basically it fell of the end of the program, in this case. Of course if there 
was a paragraph after B, it would have fallen into that. If there was some 
'rithmetic it could have S0C7'd, or with other code caused some other abend. 
But it needn't have caused another system abend, it depends what the code it 
drops into does.

If it continues to wimble along and still falls off the end of the program, you 
get the user abend, as above.

However, if, below B, there is a PERFORM range which is still active... then as 
it falls, it will arrive at the termination of the active PERFORM.

And if later in the program control passes to A, then, as if by magic, control 
will fly to the position after PERFORM B THRU A.

Now, the diagnostic, only a W, is indicating you may have a problem. Anyone who 
reads that and leaves it is... only superseded by anyone who doesn't even read 
it because "RC=4 is OK".

Back to your REDEFINES in copybooks. I'll assume that "we are not the owner of 
the copybook, so can't change it". If that is the case, that is where auditors 
are your friends - play the "sloppy" story to them, and explain that it is 
unacceptable (to you) that such practice is acceptable from an audit point of 
view.

If that has no direct impact, and you have at least V4.2, you can use a 
"message exit" for the compiler (can be written in COBOL even) which "upgrades" 
the status of any W and I that you select. Then your programs won't compile. 
Then they'll have to change the copybook?

Or are we driven back to "if we change the copybook, we have to recompile and 
change, and test, 200 programs". Well, if you only fix those REDEFINES with 
FILLERs (explicit or implicit) then a) you don't *need* to recompile any 
program just for the copybook change b) if you do recompile anything/everything 
then the object code *should be identical* c) if proven identical (except for 
date/time of compile) then it is already as tested as the current version d) if 
not proved identical you know that something else is wrong and whatever that 
is, it is unexpected for your test cases.

Now, I'd like to run that past an auditor if I was in a position to do so, even 
if only to become aware of their response.

Re: ABO Automatic Binary Optimizer

[Bill Woodger]

On Thu, 13 Oct 2016 16:44:42 -0400, Tony Harminc  wrote:

>On 13 October 2016 at 14:47, Bill Woodger  wrote:
>>
>> No, it doesn't turn the machine-code (ESA/370) into anything intermediate.
>
>Are you quite sure?
>

No, actually I'm not. It would be brilliant if it did, and if the inetermediate 
code could be output (for the entire executable). Although the generated 
"p-code" for pre-ABO and post-ABO perhaps wouldn't/needn't be the same?

If ABO generates COBOL, I'll let you push me down a mountain.

Something Java-ie? You could surprise me. If you find out, or someone else 
reveals, how it is done, I'm not going to deny it :-)

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

Re: Running USS with locale other than 1047

[Rick Troth]

Some history, and some hope.


On 10/13/16 16:24, Paul Gilmartin wrote:

Hmmm... You asked about Danish,
but your Mail Agent seems to be speaking Finnish.


:-)

The advantage in the non-EBCDIC* world is that the lower half of 8-bit 
space is rather more consistent. And that space is where we have some 
serious trouble on this side of the line (pipe symbol versus 
exclamation, square brackets, curly braces).


Years ago, Edwin Hart (then at JHU APL) and others worked through SHARE 
to normalize EBCDIC into a code page which could be translated to/from 
non-EBCDIC* consistently and reliably. We've discussed it in the 
lists/fora, perhaps this particular list/forum, even recently. (I've 
slept since then.) The result of the SHARE effort was what some call 
"Code Page 37 version 2". IBM never fully took-up the customer-produced 
code page, but they did listen and they gave us CP 1047.


Outside of IBM, most have an affinity for a _one-to-one reversible 
mapping_ which treats the EBCDIC side as CP37V2 and the non-EBCDIC* side 
as ISO-8859-1. This doesn't help the Poles, I suppose. (It would have 
been nice if IBM had a Polish code page which could use the /same 
translate table/ and match-up with a Polish non-EBCDIC code page.)


Witness Dignus: aside from newline (see below) their default 
/translation is the same/ as that gleaned from this two-decades-old 
SHARE effort. Nice work. Good job.


CP 1047 is the best we have, if we are to live in the world IBM has 
created for us.
(And some people accept the "CP1047" tag even though they're really 
talking CP37V2.)

Sadly, CP 1047 doesn't help the Poles (nor the Danes, nor the Finns).
But now it appears we can change locale. Fabulous!

Thankfully locale variables (LANG, LC_CTYPE, et al) are indicated using 
an even smaller subset of EBCDIC than those code points which map from 
"low order non-EBCDIC".


There is still the problem that a stream of bytes might not be 
recognized. Tagging files with charset ABC or code page 123 is clumsy at 
best.


*Here's hope: *

Newline is always non-printable whether EBCDIC or non-EBCDIC*.
Given a stream of bytes of unknown meaning (but reasonably expecting 
"plain text") on can trigger on 0x15 and be reasonably sure the 
preceding is EBCDIC or trigger on 0x0A and be reasonably sure the 
preceding is not. (And one can strip off or append 0x0D as needed.)


If the content is a shell script, locale variables can be recognized and 
respected.
XML, HTML, and source code can trivially include reliable cues to the 
proper locale for rendering.


Again, for a byte stream text file, look for EBCDIC "NL" newline or look 
for non-EBCDIC "LF" linefeed. EBCDIC NL will never appear in non-EBCDIC 
printable plain text. Non-EBCDIC LF will never appear in EBCDIC 
printable plain text. It's a good test.


This is where even Dignus doesn't quite get it: They translate EBCDIC 
0x15 to non-EBCDIC 0x0A. (Actual non-EBCDIC for "newline" is 0x85.) But 
their table only helps with the above test, and _makes sense_ for cases 
where someone did an un-measured translation. So I can't fault them.


Once the result of the EBCDIC (or not) check is known, one can apply 
locale and "convert" appropriately. i.e., beyond the cramped walls of 
8-bit space.


-- R; <><

* I say non-EBCDIC here because "ASCII" has baggage for many. Y'all know 
what I mean.








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

Re: ICETOOL Question

[Bill Woodger]

Why ICETOOL?

It is a DFSORT COPY operation, with a BUILD on INREC.

OPTION COPY

INREC BUILD=(starta,lengtha,startb,lengthb,startc,lengthc,startd,lengthd)

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

Re: EXTERNAL: wget for omvs?

[Mark Post]

>>> On 10/14/2016 at 03:59 PM, Jerry Whitteridge 
wrote: 
> Curl would be what I would use on zOS to do the same function as wget - (I 
> think it can use wget under the covers)

I don't believe that to be true.  One feature that wget has that curl does not 
is recursively downloading entire trees, while maintaining last-modified dates, 
etc.  If you're only downloading one file here and there, and don't mind the 
dates not matching, then curl is just fine.  Doing more than that is certainly 
possible (it's a very powerful command in a lot of ways), but you'll start 
getting into scripting things.


Mark Post

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

ICETOOL Question

[Mark Jacobs - Listserv]

Before I dig into the books, does anyone have an ICETOOL example that 
does this;


Copy all records in a file has these fields

   B   CCC  D

to a different file in this field order

     
--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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

Re: EXTERNAL: wget for omvs?

[Jerry Whitteridge]

Curl would be what I would use on zOS to do the same function as wget - (I 
think it can use wget under the covers)

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Friday, October 14, 2016 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: wget for omvs?

Is there a OMVS version of WGET?

Thanks

--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI Service 
Delivery & Engineering

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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

Re: wget for omvs?

[Dyck, Lionel B. (TRA)]

Thank you - didn't know about curl 

--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer 
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bigendian Smalls
Sent: Friday, October 14, 2016 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: wget for omvs?

Rocket ported tools has curl.


> On Oct 14, 2016, at 1:36 PM, Dyck, Lionel B. (TRA)  wrote:
> 
> Is there a OMVS version of WGET?
> 
> Thanks
> 
> --
> 
> Lionel B. Dyck (TRA Contractor)
> Mainframe Systems Programmer
> Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI 
> Service Delivery & Engineering
> 
> --
> 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: ABO Automatic Binary Optimizer

[Norman Hollander on Desertwiz]

You should request it from them.  If there is a change to the channel 
subsystem, and afterwards yours jobs start running
slowly, you may want to see if it is I/O related, for example...

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, October 14, 2016 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

Thanks Norman, but as I am not a sysprog I am not involved in those types of 
changes.  I/we depend on our facilities management team to handle those issues.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Norman Hollander on Desertwiz
Sent: Friday, October 14, 2016 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

You should request the Hardware Buckets for microcode updates.  Sometimes, 
there could be a necessary OS PTF to support/exploit new microcode.  Is there a 
chance that microcode code cause a production problem?
You know the answer...  Can the update be backed out?  Not always... 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, October 14, 2016 10:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

I don’t know how other installations perform processor model upgrades, but our 
facilities manager moves in one new processor (CEC) at a time on a weekend 
during an extended maintenance window and activates only the development/QA 
LPAR's on it for at least a week (sometimes more) of "active use" of the new 
model before migrating production LPAR's to the new model.  Remaining CEC's are 
migrated in similar fashion over a period of months.

A "live" regression test, if you will, with only Development/QA LPAR's affected 
by any issues.  I suppose a similar procedure could work for ABO translations, 
but I suspect that hardware change is "different" from the company's 
perspective, not under full company control if you will.  Individual programs 
*are* under full company control and thus subject to the regression test rules.

I don’t know how we handle microcode updates, so I can't comment accurately on 
that, but I suspect it is done one CEC at a time with backout procedures in 
place in case of issues.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, October 14, 2016 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

On Fri, 14 Oct 2016 11:29:46 -0400, Farley, Peter x23353 wrote:

>Timothy,
>
>You missed two crucial issues:
>
>1. Auditors don't believe in "verification" and management requires audits to 
>pass.  IT does not control auditors (quite the reverse in fact).  And we lowly 
>programmers have no input to auditors at all.
>2. There is no existing independent verification tool for a company to use on 
>ABO's output.  And if someone creates one, it has to be from a company OTHER 
>than IBM so that IBM's ABO results are independently verifiable.
>
>"Smart" testing is of course a valid and desirable goal, but lacking an 
>existing *independent* verification tool there is no option but full 
>regression testing.  Manual verification is not reasonable or cost effective, 
>especially for very large programs and program suites.
>
>And again, I am not trashing ABO, which on its face is an amazing tool BUT it 
>changes object code.  Lacking independent automated verification, in any sane 
>definition of a program life cycle system that is a change that requires full 
>regression testing.
>
Do the above apply likewise to moving to a different processor model, or even 
to a microcode upgrade?

-- 


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: wget for omvs?

[Bigendian Smalls]

Rocket ported tools has curl.


> On Oct 14, 2016, at 1:36 PM, Dyck, Lionel B. (TRA)  wrote:
> 
> Is there a OMVS version of WGET?
> 
> Thanks
> 
> --
> Lionel B. Dyck (TRA Contractor)
> Mainframe Systems Programmer
> Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
> VA OI Service Delivery & Engineering
> 
> --
> 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

wget for omvs?

[Dyck, Lionel B. (TRA)]

Is there a OMVS version of WGET?

Thanks

--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering

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

Re: ABO Automatic Binary Optimizer

[Farley, Peter x23353]

Thanks Norman, but as I am not a sysprog I am not involved in those types of 
changes.  I/we depend on our facilities management team to handle those issues.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Norman Hollander on Desertwiz
Sent: Friday, October 14, 2016 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

You should request the Hardware Buckets for microcode updates.  Sometimes, 
there could be a necessary
OS PTF to support/exploit new microcode.  Is there a chance that microcode code 
cause a production problem?
You know the answer...  Can the update be backed out?  Not always... 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, October 14, 2016 10:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

I don’t know how other installations perform processor model upgrades, but our 
facilities manager moves in one new processor (CEC) at a time on a weekend 
during an extended maintenance window and activates only the development/QA 
LPAR's on it for at least a week (sometimes more) of "active use" of the new 
model before migrating production LPAR's to the new model.  Remaining CEC's are 
migrated in similar fashion over a period of months.

A "live" regression test, if you will, with only Development/QA LPAR's affected 
by any issues.  I suppose a similar procedure could work for ABO translations, 
but I suspect that hardware change is "different" from the company's 
perspective, not under full company control if you will.  Individual programs 
*are* under full company control and thus subject to the regression test rules.

I don’t know how we handle microcode updates, so I can't comment accurately on 
that, but I suspect it is done one CEC at a time with backout procedures in 
place in case of issues.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, October 14, 2016 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

On Fri, 14 Oct 2016 11:29:46 -0400, Farley, Peter x23353 wrote:

>Timothy,
>
>You missed two crucial issues:
>
>1. Auditors don't believe in "verification" and management requires audits to 
>pass.  IT does not control auditors (quite the reverse in fact).  And we lowly 
>programmers have no input to auditors at all.
>2. There is no existing independent verification tool for a company to use on 
>ABO's output.  And if someone creates one, it has to be from a company OTHER 
>than IBM so that IBM's ABO results are independently verifiable.
>
>"Smart" testing is of course a valid and desirable goal, but lacking an 
>existing *independent* verification tool there is no option but full 
>regression testing.  Manual verification is not reasonable or cost effective, 
>especially for very large programs and program suites.
>
>And again, I am not trashing ABO, which on its face is an amazing tool BUT it 
>changes object code.  Lacking independent automated verification, in any sane 
>definition of a program life cycle system that is a change that requires full 
>regression testing.
>
Do the above apply likewise to moving to a different processor model, or even 
to a microcode upgrade?

-- 


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: ABO Automatic Binary Optimizer

[Norman Hollander on Desertwiz]

You should request the Hardware Buckets for microcode updates.  Sometimes, 
there could be a necessary
OS PTF to support/exploit new microcode.  Is there a chance that microcode code 
cause a production problem?
You know the answer...  Can the update be backed out?  Not always... 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, October 14, 2016 10:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

I don’t know how other installations perform processor model upgrades, but our 
facilities manager moves in one new processor (CEC) at a time on a weekend 
during an extended maintenance window and activates only the development/QA 
LPAR's on it for at least a week (sometimes more) of "active use" of the new 
model before migrating production LPAR's to the new model.  Remaining CEC's are 
migrated in similar fashion over a period of months.

A "live" regression test, if you will, with only Development/QA LPAR's affected 
by any issues.  I suppose a similar procedure could work for ABO translations, 
but I suspect that hardware change is "different" from the company's 
perspective, not under full company control if you will.  Individual programs 
*are* under full company control and thus subject to the regression test rules.

I don’t know how we handle microcode updates, so I can't comment accurately on 
that, but I suspect it is done one CEC at a time with backout procedures in 
place in case of issues.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, October 14, 2016 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

On Fri, 14 Oct 2016 11:29:46 -0400, Farley, Peter x23353 wrote:

>Timothy,
>
>You missed two crucial issues:
>
>1. Auditors don't believe in "verification" and management requires audits to 
>pass.  IT does not control auditors (quite the reverse in fact).  And we lowly 
>programmers have no input to auditors at all.
>2. There is no existing independent verification tool for a company to use on 
>ABO's output.  And if someone creates one, it has to be from a company OTHER 
>than IBM so that IBM's ABO results are independently verifiable.
>
>"Smart" testing is of course a valid and desirable goal, but lacking an 
>existing *independent* verification tool there is no option but full 
>regression testing.  Manual verification is not reasonable or cost effective, 
>especially for very large programs and program suites.
>
>And again, I am not trashing ABO, which on its face is an amazing tool BUT it 
>changes object code.  Lacking independent automated verification, in any sane 
>definition of a program life cycle system that is a change that requires full 
>regression testing.
>
Do the above apply likewise to moving to a different processor model, or even 
to a microcode upgrade?

-- 


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: ABO Automatic Binary Optimizer

[Tony Harminc]

On 14 October 2016 at 02:30, Timothy Sipples  wrote:

> No, not optimistic. Mere fact. Sun Microsystems made Java 1.0 generally
> available for download on January 23, 1996, for the Windows 95, Windows NT,
> and Solaris operating systems (three different operating systems across two
> different processor architectures). That was over two decades ago.

We're not debating the existence of Java in 1996. What you said that I
disagree with is this:

 >For perspective, for over two decades (!) Java has
> compiled/compiles bytecode *every time* a Java class is first instantiated.
> The resulting native code is model optimized depending on the JVM release
> level's maximum model optimization capabilities or the actual machine
> model, whichever is lower.

This just isn't correct. The Java made available by Sun in 1996 was a
pure interpreter. They wrote C code to implement a JVM, and the
related (and in fact much larger) baggage of class loaders and such.
This C code could be compiled for just about any architecture, but it
did no converting of JVM bytecodes into native instructions. It was a
lot like the many interpreters that existed for decades before, such
as UCSD Pascal's P-code, and a number of offerings from IBM and many
others ( APL, CPS-BASIC and CPS-PL/I), TSO classic CLISTs, Rexx, and
more. In pass 1 source code is converted into some kind of internal
representation, and in pass 2 that representation is then interpreted
by native code. What the intermediate form looks like with respect to
the source language differs. Either it's a lot like the source,
cleaned up for easier machine processing (CLIST, Rexx, most BASICs),
or it's more of an easy-to-interpret virtual machine (UCSD, JVM), but
by definition it's not the native instruction set of the eventual
target machine. Sun's JVM, as documented in the 1996 book, did define
some pseudo-ops for performance reasons, but they were entirely
optional and in no way can be called compiling (JIT or otherwise).

Back in 1996, while I'm sure there were bright people thinking about
JIT compilation of JVM bytecodes into existing instruction sets, the
more general musing (in the Sun JVM book, even) was about building
hardware to directly execute -- rather than interpret --  JVM
bytecodes. That didn't happen in any commercial way to my knowledge.

> Java isn't the earliest example of a bytecode-to-native technology. IBM's
> Technology Independent Machine Interface (TIMI) proved the concept much
> earlier. TIMI traces its roots to the IBM System/38 introduced in August,
> 1979.

I'd say its roots go much further back to the failed Future System
(FS), that Lynne Wheeler has mentioned here many times.

> The latest TIMI technologies are found in the IBM i platform, another
> platform deservedly famous as a stable, reliable home for applications.
> Before program execution (just before, if necessary) TIMI automatically
> translates the bytecode to native code tailored for that particular
> hardware model environment, persists it, and runs it.

You're describing the Original Programming Model (OPM), which has
largely been deprecated in recent years in favour of compiling
directly into native (p-series) instructions, probably via some quite
different intermediate representation.

> TIMI is arguably even closer to ABO conceptually than Java is.

Sure. It wouldn't surprise me at all to find that the intermediate
representation used by ABO is the very same one used on the IBM i.
Certainly ABO and the IBM i compilers all come from the same lab.

Tony H.

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

Re: TCP/IP ezasoket call interface - connection timeout parameter.

[Roberto Halais]

Same here. Non-blocking.

On Fri, Oct 14, 2016 at 11:44 AM, Ward, Mike S  wrote:

> We always use non-blocking, it seems to perform better. We had the same
> issue's here that you experienced. That's why we went the non-blocking way.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cannaerts, Jan
> Sent: Friday, October 14, 2016 7:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TCP/IP ezasoket call interface - connection timeout parameter.
>
> Hello list,
>
>
> We have a situation where we have a CICS transaction which exchanges
> information With another company over TCP/IP, using the ezasoket call
> interface.
> We are the client, while they are the server.
>
> Through experience we have learned that "because reasons", the server does
> not always accept our connections, but our connection attempts are not
> being actively refused. Instead, the connection attempt waits until its
> timeout value is met and then returns with the appropriate error code. For
> every pending connection that will never succeed, a transaction sits there
> waiting for its timeout. Those queue up, we reach MaxTasks, and other work
> gets disrupted.
>
> So the question is then; how and/or where we can set this timeout value
> for a connection attempt? From what I gather, it's not possible to set this
> value on a per-socket basis, as some digging through the IP Sockets
> Application Programming Interface Guide and Reference has left me wanting.
> From the z/OS Communications Server: IP Configuration Reference, I find
> that I can set the CONNECTTIMEOUT parameter in the TCPCONFIG statement of
> our TCP/IP profile, but this value will then be enforced on every
> connection made through that IP stack.
> From what I gather, we don't set CONNECTTIMEOUT, and as such are subject
> to the
> 75 second default, which is definitely too long for what we're doing.
>
> We could set up an entirely different IP stack with a lower CONNECTTIMEOUT
> for just this application, but that seems a bit much. Especially if we can
> set the connection timeout on a per-socket basis instead.
>
> Another idea is to make the sockets that perform the connection attempts
> non-blocking. We would check the return code after the connection attempt,
> and if successful continue. If the connection is still pending, we'd issue
> a select with an appropriate timeout parameter. At this point this seems
> the most logical way to continue. But I know I might be missing something,
> otherwise I wouldn't be consulting the list.
>
> Any ideas, or comments about my assumptions are kindly appreciated.
>
>
> Regards,
> Jan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ==
> This email, and any files transmitted with it, is confidential and
> intended solely for the use of the individual or entity to which it is
> addressed. If you have received this email in error, please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named addressee,
> you should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this message by
> mistake and delete this e-mail from your system. If you are not the
> intended recipient, you are notified that disclosing, copying, distributing
> or taking any action in reliance on the contents of this information is
> strictly prohibited.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
“Live as if you were to die tomorrow. Learn as if you were to live
forever.”
– Mahatma Gandhi

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

Re: ABO Automatic Binary Optimizer

[Farley, Peter x23353]

I don’t know how other installations perform processor model upgrades, but our 
facilities manager moves in one new processor (CEC) at a time on a weekend 
during an extended maintenance window and activates only the development/QA 
LPAR's on it for at least a week (sometimes more) of "active use" of the new 
model before migrating production LPAR's to the new model.  Remaining CEC's are 
migrated in similar fashion over a period of months.

A "live" regression test, if you will, with only Development/QA LPAR's affected 
by any issues.  I suppose a similar procedure could work for ABO translations, 
but I suspect that hardware change is "different" from the company's 
perspective, not under full company control if you will.  Individual programs 
*are* under full company control and thus subject to the regression test rules.

I don’t know how we handle microcode updates, so I can't comment accurately on 
that, but I suspect it is done one CEC at a time with backout procedures in 
place in case of issues.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, October 14, 2016 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

On Fri, 14 Oct 2016 11:29:46 -0400, Farley, Peter x23353 wrote:

>Timothy,
>
>You missed two crucial issues:
>
>1. Auditors don't believe in "verification" and management requires audits to 
>pass.  IT does not control auditors (quite the reverse in fact).  And we lowly 
>programmers have no input to auditors at all.
>2. There is no existing independent verification tool for a company to use on 
>ABO's output.  And if someone creates one, it has to be from a company OTHER 
>than IBM so that IBM's ABO results are independently verifiable.
>
>"Smart" testing is of course a valid and desirable goal, but lacking an 
>existing *independent* verification tool there is no option but full 
>regression testing.  Manual verification is not reasonable or cost effective, 
>especially for very large programs and program suites.
>
>And again, I am not trashing ABO, which on its face is an amazing tool BUT it 
>changes object code.  Lacking independent automated verification, in any sane 
>definition of a program life cycle system that is a change that requires full 
>regression testing.
>
Do the above apply likewise to moving to a different processor model, or even to
a microcode upgrade?

-- 


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: ABO Automatic Binary Optimizer

[Norman Hollander on Desertwiz]

Back in my banking days, we Sysprogs worked with OPs and APPs to create several 
Jobstreams to
create a group of critical/typical transactions to exercise various 
applications (such as Loan Origination,
ATM, Retail, and Financial, along with File Transfer, Statement Printing, 
etc.).  These were used for any
major changes, like Processor changes, Microcode, DASD changes, Channel 
changes, Printer mods (we had
3900 Duplex printers), OS changes, Middleware changes, and Application changes. 
 These were used as a vehicle
to exercise major components, and were a good indicator that a change appeared 
successful.  If you've ever been
through an Operational Audit, you know that the "process" must be in place for 
changes, and you must routinely
exercise them.  While all changes might not be subjected to this process, a 
robust Change Management process
will determine the need, and will satisfy most auditors.  Satisfying auditors 
is not really a SysProg daily job, but it
is something often required.  If your shop does not need such time consumers, 
consider yourself lucky.  AFAIK, many
industries still require these today.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, October 14, 2016 9:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer

On Fri, 14 Oct 2016 11:29:46 -0400, Farley, Peter x23353 wrote:

>Timothy,
>
>You missed two crucial issues:
>
>1. Auditors don't believe in "verification" and management requires audits to 
>pass.  IT does not control auditors (quite the reverse in fact).  And we lowly 
>programmers have no input to auditors at all.
>2. There is no existing independent verification tool for a company to use on 
>ABO's output.  And if someone creates one, it has to be from a company OTHER 
>than IBM so that IBM's ABO results are independently verifiable.
>
>"Smart" testing is of course a valid and desirable goal, but lacking an 
>existing *independent* verification tool there is no option but full 
>regression testing.  Manual verification is not reasonable or cost effective, 
>especially for very large programs and program suites.
>
>And again, I am not trashing ABO, which on its face is an amazing tool BUT it 
>changes object code.  Lacking independent automated verification, in any sane 
>definition of a program life cycle system that is a change that requires full 
>regression testing.
>
Do the above apply likewise to moving to a different processor model, or even 
to a microcode upgrade?

-- 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: ABO Automatic Binary Optimizer

[Paul Gilmartin]

On Fri, 14 Oct 2016 11:29:46 -0400, Farley, Peter x23353 wrote:

>Timothy,
>
>You missed two crucial issues:
>
>1. Auditors don't believe in "verification" and management requires audits to 
>pass.  IT does not control auditors (quite the reverse in fact).  And we lowly 
>programmers have no input to auditors at all.
>2. There is no existing independent verification tool for a company to use on 
>ABO's output.  And if someone creates one, it has to be from a company OTHER 
>than IBM so that IBM's ABO results are independently verifiable.
>
>"Smart" testing is of course a valid and desirable goal, but lacking an 
>existing *independent* verification tool there is no option but full 
>regression testing.  Manual verification is not reasonable or cost effective, 
>especially for very large programs and program suites.
>
>And again, I am not trashing ABO, which on its face is an amazing tool BUT it 
>changes object code.  Lacking independent automated verification, in any sane 
>definition of a program life cycle system that is a change that requires full 
>regression testing.
>
Do the above apply likewise to moving to a different processor model, or even to
a microcode upgrade?

-- gil

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

Re: Language Environment LIBVEC layout?

[Lizette Koehler]

This is just a guess after reading the doc.

This might be a question IBM can answer.  Some of the processes might be
internal to IBM and not available to the average user.

In other words, if there is a Service that can provide the information, it is
possible the Csect Offsite may not be accessible or stable (they might move it
on you) 

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Pete Dillon
> Sent: Friday, October 14, 2016 8:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Language Environment LIBVEC layout?
> 
> Gentlefolk,
> 
> Subject says all, really - does anyone have a layout for the Language
> Environment LIBVEC CSECT? The manuals cover structure but not actual contents;
> I'm trying to properly understand the under-the-covers nuts and bolts of
> starting up a COBOL program, and am running into code that uses hard-coded
> offsets in LIBVEC. While I could force an abend then work backwards from a
> dump, it would be so much easier if someone could help me with this (there are
> likely hundreds of addresses in there and it would be dull in the extreme to
> go through them!).
> 
> For the avoidance of ambiguity the LIBVEC I'm interested in is the one pointed
> to by offset 696 decimal in the CAA, field name CEECAACELV.
> 
> Many thanks in advance,
> 
> Pete.

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

Re: DFHSM query command from Console

[Lizette Koehler]

What are you looking for?  The name of the MCDS?  Or information in the 
MCDS/BCDS and so forth?

If the later, look up the LIST command in the HSM Admin manual and issue
F hsmstcname,LIST yada yada yada ODS('where you want the output to go')

HSM will create the ODS dataset for your or mod onto it if it exits.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: Friday, October 14, 2016 8:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFHSM query command from Console
> 
> Hi
> 
> Is it possible to query MCDS dataset usage from master console ?
> 
> I apologize as I am new to DFHSM.
> 
> Peter

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

Re: ABO Automatic Binary Optimizer

[Anne & Lynn Wheeler]

sipp...@sg.ibm.com (Timothy Sipples) writes:
> No, not optimistic. Mere fact. Sun Microsystems made Java 1.0
> generally available for download on January 23, 1996, for the Windows
> 95, Windows NT, and Solaris operating systems (three different
> operating systems across two different processor architectures). That
> was over two decades ago.

re:
http://manana.garlic.com/~lynn/2016f.html#91 ABO Automatic Binary Optimizer
http://manana.garlic.com/~lynn/2016f.html#92 ABO Automatic Binary Optimizer

trivia: general manager of the sun business group responsible for java
had formally been at IBM Los Gatos lab ... and one of two people
responsible for the original mainframe pascal (I got invited to the JAVA
announce).

In the early 90s, object language were all the rage and (at least) both
Apple and Sun were doing new operating systems (Apple's Pink and Sun's
SPRING).

Before SUN abandon'ed SPRING, I was asked if I would be interested in
coming onboard and bringing SPRING to commercial quality for release (I
did some review and then declined). Note the SPRING and GREEN (JAVA)
people claimed that there was no overlap between the two ... although
from SPRING: A Client-Side Stub Interpreter

We have built a research operating system in which all services are
presented through interfaces described by an interface description
language. The system consists of a micro-kernel that supports a small
number of these interfaces, and a large number of interfaces that are
implemented by user-level code. A typical service implements one or
more interfaces, but is a client of many other interfaces that are
implemented elsewhere in the system. We have an interface compiler
that generates client-side and service-side stubs to deliver calls
from clients to services providing location transparency if the client
and server are in different address spaces. The code for client-side
stubs was occupying a large amount of the text space on our clients,
so a stub interpreter was written to replace the client-side stub
methods. The result was that we traded 125k bytes of stub code for 13k
bytes of stub descriptions and 4k bytes of stub interpreter. This
paper describes the stub interpreter, the stub descriptions, and
discusses some alternatives.

... snip ...

note that I've periodically claimed that the father of 801/RISC had gone
to the opposite extreme of the (failed) Future System effort. In the
late 70s, there was an effort to replace a myriad of internal IBM
microprocessors all, with 801/RISC (Iliad) ... controlers, low &
mid-range 370, AS/400 (follow-on to S/38). The 4361 & 4381 (followon to
4331 and 4341) were originally going to be Iliad microprocessors. For
the 4361/4381 Iliad, they were looking in addition to straight
interpreting 370 (like early generations of 360 & 370), a JIT
(just-in-time) compiler that took snipets of 370->801. In the early 70s,
I had written a PLI program that analyzed 370 assembler programs,
creating a high-level abstraction of the instructions and program flow
... and got asked to spend some time talking to the Iliad/JIT
people. Note for various reasons, these Iliad efforts failed and all
reverted to doing traditional CISC processors (and some of the RISC/801
engineers leave and start showing up at other companies working on RISC
efforts)

In the late 80s some 370 emulation efforts started which morph into
Hercules and other offerings. At least one of the commercial 370
emulator offerings implemented JIT (370->native) on-the-fly (for intel &
sparc) for high-use 370 code snippets.

During the 90s, there was a lot about the RISC throughput performance
advantage over I86. However, starting about two decades ago, I86
processor implementations started doing hardware translation of I86
instructions to series of risc micro-ops for actual execution ... which
has contributed to largely closing the throughput difference between I86
and RISC processors.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: TCP/IP ezasoket call interface - connection timeout parameter.

[Ward, Mike S]

We always use non-blocking, it seems to perform better. We had the same issue's 
here that you experienced. That's why we went the non-blocking way.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cannaerts, Jan
Sent: Friday, October 14, 2016 7:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TCP/IP ezasoket call interface - connection timeout parameter.

Hello list,


We have a situation where we have a CICS transaction which exchanges 
information With another company over TCP/IP, using the ezasoket call interface.
We are the client, while they are the server.

Through experience we have learned that "because reasons", the server does not 
always accept our connections, but our connection attempts are not being 
actively refused. Instead, the connection attempt waits until its timeout value 
is met and then returns with the appropriate error code. For every pending 
connection that will never succeed, a transaction sits there waiting for its 
timeout. Those queue up, we reach MaxTasks, and other work gets disrupted.

So the question is then; how and/or where we can set this timeout value for a 
connection attempt? From what I gather, it's not possible to set this value on 
a per-socket basis, as some digging through the IP Sockets Application 
Programming Interface Guide and Reference has left me wanting. From the z/OS 
Communications Server: IP Configuration Reference, I find that I can set the 
CONNECTTIMEOUT parameter in the TCPCONFIG statement of our TCP/IP profile, but 
this value will then be enforced on every connection made through that IP stack.
>From what I gather, we don't set CONNECTTIMEOUT, and as such are subject to the
75 second default, which is definitely too long for what we're doing.

We could set up an entirely different IP stack with a lower CONNECTTIMEOUT for 
just this application, but that seems a bit much. Especially if we can set the 
connection timeout on a per-socket basis instead.

Another idea is to make the sockets that perform the connection attempts 
non-blocking. We would check the return code after the connection attempt, and 
if successful continue. If the connection is still pending, we'd issue a select 
with an appropriate timeout parameter. At this point this seems the most 
logical way to continue. But I know I might be missing something, otherwise I 
wouldn't be consulting the list.

Any ideas, or comments about my assumptions are kindly appreciated.


Regards,
Jan

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: FW: IBM Education Assistance for z/OS - Useful??

[Ward, Mike S]

I concur, my staff appreciates that these articles are out there.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Friday, October 14, 2016 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: FW: IBM Education Assistance for z/OS - Useful??

Hi Marna,
I did have a look at some presentations a while ago. Very helpful, so please do 
keep this going.Some presentions are a little sparse. Some more comment would 
be helpful.

RegardsPeter


From:   Marna Walle/Poughkeepsie/IBM@IBMUS
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   10/12/2016 02:35 PM
Subject:IBM Education Assistance for z/OS - Useful??
Sent by:IBM Mainframe Discussion List



Hello IBM-MAINers,
I wanted to ask about the usefulness of the IBM Education Assistance (IEA) for 
z/OS.

A little background:  IEA is found here:
http://www.redbooks.ibm.com/redbooks.nsf/pages/IBMIEAV22avail?Open and provides 
concise and technical information about a specific function introduced in z/OS. 
 For instance, there is a module there for Dynamic
Logrec in z/OS V2.2.It is intended to be a "one stop shopping"
location for new enhancements in a z/OS release.  Of course, all information 
can also be found in the appropriate z/OS books.  We've had IEA for both z/OS 
V2.1 and V2.2.

My questions are:
1)  is this is still a good way to provide this information to you?
2) with all the other ways to learn about new functions, is IEA still needed by 
you?
3) are there particular topics in IEA that you like and want to continue to see 
in the future?  if so, which ones?

Thanks in advance for any opinions you'd like to share.
-Marna WALLE
z/OS Installation, IBM Poughkeepsie

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

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: ABO Automatic Binary Optimizer

[Farley, Peter x23353]

Timothy,

You missed two crucial issues:

1. Auditors don't believe in "verification" and management requires audits to 
pass.  IT does not control auditors (quite the reverse in fact).  And we lowly 
programmers have no input to auditors at all.
2. There is no existing independent verification tool for a company to use on 
ABO's output.  And if someone creates one, it has to be from a company OTHER 
than IBM so that IBM's ABO results are independently verifiable.

"Smart" testing is of course a valid and desirable goal, but lacking an 
existing *independent* verification tool there is no option but full regression 
testing.  Manual verification is not reasonable or cost effective, especially 
for very large programs and program suites.

And again, I am not trashing ABO, which on its face is an amazing tool BUT it 
changes object code.  Lacking independent automated verification, in any sane 
definition of a program life cycle system that is a change that requires full 
regression testing.

Peter

P.S. -- To Bill Woodger:  I don't know how other COBOL programmers work, but I 
*always* review the compiler warnings, and strive to make my compilations 
warning-free.  I don't always succeed (data area copy books that define smaller 
areas over larger ones and debugging paragraphs that are not commented out are 
particular nuisances), but I do try.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Timothy Sipples
Sent: Friday, October 14, 2016 2:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ABO Automatic Binary Optimizer


With all that said, one has to be smart about when, where, how, and how
much to test. Bill Woodger reminded me of an important fact, that if you're
not smart about testing and you're just running "big" tests over and over
to tick checkboxes, even when it makes little or no sense, then you're not
actually testing well either. You're very likely missing genuine risks.
Literally nobody wins if you've got an expensive, bloated testing regime
that isn't actually testing what you should be testing in 2016 (and
beyond). There are also many cases when business users simply throw up
their hands and declare "No thank you; I can't afford to wait 68 days for
your testing program to complete," and they shop elsewhere for their IT
services.

My friends and colleagues, we must always be *reasonable* and adaptable,
else we're lost at sea. And it's simply unreasonable to treat ABO
optimizations the same for testing purposes as source code changes and
recompiles. The source code doesn't change! The correct ABO testing effort
answer should be something more than zero and something less than what's
ordinarily advisable for a "typical" source code change/recompile trip.
Please consult with ABO technical experts to help decide where precisely
that "in between" should be given your particular environment and
applications.

--

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: DFHSM query command from Console

[Mark Jacobs - Listserv]

F HSM,Q CDS


Peter 
October 14, 2016 at 11:14 AM
Hi

Is it possible to query MCDS dataset usage from master console ?

I apologize as I am new to DFHSM.

Peter

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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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

DFHSM query command from Console

[Peter]

Hi

Is it possible to query MCDS dataset usage from master console ?

I apologize as I am new to DFHSM.

Peter

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

Language Environment LIBVEC layout?

[Pete Dillon]

Gentlefolk,

Subject says all, really - does anyone have a layout for the Language
Environment LIBVEC CSECT? The manuals cover structure but not actual
contents; I'm trying to properly understand the under-the-covers nuts and
bolts of starting up a COBOL program, and am running into code that uses
hard-coded offsets in LIBVEC. While I could force an abend then work
backwards from a dump, it would be so much easier if someone could help
me with this (there are likely hundreds of addresses in there and it
would be dull in the extreme to go through them!). 

For the avoidance of ambiguity the LIBVEC I'm interested in is the one
pointed to by offset 696 decimal in the CAA, field name CEECAACELV.

Many thanks in advance,
  
Pete.

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

Fwd: Why Aren't Enterprises Getting Off the Mainframe?

[Mark Regan]

Why
Aren't Enterprises Getting Off the Mainframe?


*by Bob Thomas*

For decades we've all been hearing about the demise of the mainframe. And
yes, a fair number of small to mid-sized companies have switched to
distributed systems. But there were also enterprises that abandoned their
goal to get rid of their mainframe after spending multiple millions of
dollars in the effort. I wonder how many companies decided to soldier on
with their mainframe after getting to year eight of their five-year plan to
be mainframe free...

http://enterprisesystemsmedia.com/article/why-arent-enterprises-getting-off-the-mainframe#sr=nf%20xfcgmbti=ofxtmfuufs=tnjv3=NF%20XG%20-%20bsu%201-tmc=1455645067


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

Re: Help with broken CB chain

[Donald Likens]

I found the statement in the POP...

PERFORM LOCKED OPERATION can be thought
of as performing concurrent interlocked updates of
multiple operands. However, the instruction does
not actually perform any interlocked update, and a
serially reusable resource cannot be updated predictably
through the use of both PERFORM
LOCKED OPERATION and conditional-swapping
instructions (CS and CDS).

Thanks for your help.

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

Re: Does JZOS DFSORT get offloaded to a zIIP?

[David Crayford]

On 14/10/2016 9:10 PM, Kirk Wolf wrote:

JZOS does have native code (not byte code) that is part of the JVM which is
zIIP eligible.


Right. So the JNI C/C++ RTL functions run on a zIIP but as I thought 
DFSORT running in a spawned process does not. DFSORT could have been 
executed with a simple link
to the program so I'm guessing that spawning a process was a design 
feature so it wouldn't run on a zIIP?



The JZOS DFSORT wrapper spawns DFSORT in a separate process, which is not
part of the JVM and is therefore not zIIP eligible.


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Fri, Oct 14, 2016 at 7:54 AM, Martin Packer 
wrote:


DFSORT is not executing as bytecode in a JVM so no.

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or

https://itunes.apple.com/gb/podcast/mainframe-performance-
topics/id1127943573?mt=2



From:   David Crayford 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   14/10/2016 13:49
Subject:Does JZOS DFSORT get offloaded to a zIIP?
Sent by:IBM Mainframe Discussion List 



I'm guessing the answer is no judging by the fact that JZOS spawns a
jdfsort UNIX process to do the sort and if it did everybody would just
write Java wrappers to
sort data sets thus reducing the cost of running DFSORT.

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

AW: FW: IBM Education Assistance for z/OS - Useful??

[Peter Hunkeler]

Hi Marna,
I did have a look at some presentations a while ago. Very helpful, so please do 
keep this going.Some presentions are a little sparse. Some more comment would 
be helpful.

RegardsPeter


From:   Marna Walle/Poughkeepsie/IBM@IBMUS
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   10/12/2016 02:35 PM
Subject:IBM Education Assistance for z/OS - Useful??
Sent by:IBM Mainframe Discussion List



Hello IBM-MAINers,
I wanted to ask about the usefulness of the IBM Education Assistance (IEA)
for z/OS.

A little background:  IEA is found here:
http://www.redbooks.ibm.com/redbooks.nsf/pages/IBMIEAV22avail?Open and
provides concise and technical information about a specific function
introduced in z/OS.  For instance, there is a module there for Dynamic
Logrec in z/OS V2.2.It is intended to be a "one stop shopping"
location for new enhancements in a z/OS release.  Of course, all
information can also be found in the appropriate z/OS books.  We've had
IEA for both z/OS V2.1 and V2.2.

My questions are:
1)  is this is still a good way to provide this information to you?
2) with all the other ways to learn about new functions, is IEA still
needed by you?
3) are there particular topics in IEA that you like and want to continue
to see in the future?  if so, which ones?

Thanks in advance for any opinions you'd like to share.
-Marna WALLE
z/OS Installation, IBM Poughkeepsie

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

--
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: Does JZOS DFSORT get offloaded to a zIIP?

[Kirk Wolf]

JZOS does have native code (not byte code) that is part of the JVM which is
zIIP eligible.

The JZOS DFSORT wrapper spawns DFSORT in a separate process, which is not
part of the JVM and is therefore not zIIP eligible.


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Fri, Oct 14, 2016 at 7:54 AM, Martin Packer 
wrote:

> DFSORT is not executing as bytecode in a JVM so no.
>
> Martin Packer,
> zChampion, Principal Systems Investigator,
> Worldwide Cloud & Systems Performance, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or
>
> https://itunes.apple.com/gb/podcast/mainframe-performance-
> topics/id1127943573?mt=2
>
>
>
> From:   David Crayford 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   14/10/2016 13:49
> Subject:Does JZOS DFSORT get offloaded to a zIIP?
> Sent by:IBM Mainframe Discussion List 
>
>
>
> I'm guessing the answer is no judging by the fact that JZOS spawns a
> jdfsort UNIX process to do the sort and if it did everybody would just
> write Java wrappers to
> sort data sets thus reducing the cost of running DFSORT.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
> --
> 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: Does JZOS DFSORT get offloaded to a zIIP?

[Martin Packer]

DFSORT is not executing as bytecode in a JVM so no.

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2



From:   David Crayford 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   14/10/2016 13:49
Subject:Does JZOS DFSORT get offloaded to a zIIP?
Sent by:IBM Mainframe Discussion List 



I'm guessing the answer is no judging by the fact that JZOS spawns a 
jdfsort UNIX process to do the sort and if it did everybody would just 
write Java wrappers to
sort data sets thus reducing the cost of running DFSORT.

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

TCP/IP ezasoket call interface - connection timeout parameter.

[Cannaerts, Jan]

Hello list,


We have a situation where we have a CICS transaction which exchanges information
With another company over TCP/IP, using the ezasoket call interface.
We are the client, while they are the server.

Through experience we have learned that "because reasons", the server does not
always accept our connections, but our connection attempts are not being
actively refused. Instead, the connection attempt waits until its timeout value
is met and then returns with the appropriate error code. For every pending 
connection that will never succeed, a transaction sits there waiting for its
timeout. Those queue up, we reach MaxTasks, and other work gets disrupted.

So the question is then; how and/or where we can set this timeout value
for a connection attempt? From what I gather, it's not possible to set this 
value
on a per-socket basis, as some digging through the IP Sockets Application
Programming Interface Guide and Reference has left me wanting. From the
z/OS Communications Server: IP Configuration Reference, I find that I can set 
the
CONNECTTIMEOUT parameter in the TCPCONFIG statement of our TCP/IP profile, but
this value will then be enforced on every connection made through that IP stack.
>From what I gather, we don't set CONNECTTIMEOUT, and as such are subject to 
>the 
75 second default, which is definitely too long for what we're doing.

We could set up an entirely different IP stack with a lower CONNECTTIMEOUT for
just this application, but that seems a bit much. Especially if we can set the
connection timeout on a per-socket basis instead.

Another idea is to make the sockets that perform the connection attempts
non-blocking. We would check the return code after the connection attempt, and 
if
successful continue. If the connection is still pending, we'd issue a select 
with
an appropriate timeout parameter. At this point this seems the most logical way
to continue. But I know I might be missing something, otherwise I wouldn't be
consulting the list.

Any ideas, or comments about my assumptions are kindly appreciated.


Regards,
Jan

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

Does JZOS DFSORT get offloaded to a zIIP?

[David Crayford]

I'm guessing the answer is no judging by the fact that JZOS spawns a 
jdfsort UNIX process to do the sort and if it did everybody would just 
write Java wrappers to

sort data sets thus reducing the cost of running DFSORT.

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

Re: RMF Spreadsheet report 4 hour rolling MSU

[John Zoppetti]

John, an email with the info is on the way to you.  Let me know how successful 
it is.

John Zoppetti
Mainframe Support
U. S. Steel

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

Re: Experience with GDDR

[Barbara Nitz]

>The minimum specs we were provided insist on a 2-CP solution, but when I
>pressed them, other than "commands took a long time", I received no
>valid reason why a single CP with sufficient memory would not be enough.
>Does anyone have experience with GDDR LPARs, specifically the CP
>requirement, and be willing to share that with a fellow Sysprog?

The two LPARs we are running both run with a single CP, and have for almost a 
year, AFAIK. No adverse effects that I could observe (but then, I don't 'do' 
hardware).

Be aware that we currently have problems terminating the GDDR address spaces 
during system shutdown that run on all systems. They need to get force arm'd to 
terminate. EMC tells us that we are behind on maintenance, I was told we have 
the maint installed, and we still need to force arm them. Go back to being 
'behind on maint' and start over.  I am getting frustrated with that. 

Barbara

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

Re: RMF Spreadsheet report 4 hour rolling MSU

[Jorge Garcia]

Hi all,

 Peter Mailand, from RMF IBM team, answers me. This value is available with the 
overview statement LACS,LACSM,LACSA,LACSB and you obtain overview records. Then 
you can process with Generic Overview Report Spreadsheet .

Regards

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

Re: Expanding eCSA

[Martin Packer]

So am I. Let us know what you find out.

Thanks, Martin

Sent from my iPad

> On 13 Oct 2016, at 20:24, phil yogendran  wrote:
>
> Thanks Martin, I will follow up with that. I am particularly interested
in
> how the *MASTER* address space uses ePVT.
>
> On Thu, Oct 13, 2016 at 1:09 PM, Martin Packer 
> wrote:
>
>> Type 30 has 31-bit (and 24-bit FWIW) Allocation numbers for each address
>> space. DB2 and MQ used to be prime users of 31-Bit (and secondarily CICS
>> is) but the most modern level of MQ and recentish levels of DB2 chanced
>> all that.
>>
>> And I'm sure you know RMF SMF 78-2 has System-Level virtual storage
>> numbers - for the commonish areas.
>>
>> Cheers, Martin
>>
>> Martin Packer,
>> zChampion, Principal Systems Investigator,
>> Worldwide Cloud & Systems Performance, IBM
>>
>> +44-7802-245-584
>>
>> email: martin_pac...@uk.ibm.com
>>
>> Twitter / Facebook IDs: MartinPacker
>>
>> Blog:
>> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>>
>> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/
or
>>
>> https://itunes.apple.com/gb/podcast/mainframe-performance-
>> topics/id1127943573?mt=2
>>
>>
>>
>> From:   phil yogendran 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date:   13/10/2016 16:10
>> Subject:Expanding eCSA
>> Sent by:IBM Mainframe Discussion List 
>>
>>
>>
>> Hello All,
>>
>> The problem I have is that a few IMS reorg jobs which place a high
demand
>> on eCSA often fail due to insufficient eCSA.
>>
>> The current eCSA allocation is 1030M. I would like to try bumping it up
to
>> 1130M or even 1230M.
>>
>> My question is how can I determine who would be impacted? Who requires
the
>> most amount of ePRIVATE and what is that number?
>>
>> Thanks
>>
>> Phil
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
>>
>> --
>> 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
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: Experience with GDDR

[Timothy Sipples]

GDPS options are also available.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: ABO Automatic Binary Optimizer

[Timothy Sipples]

Tony Harminc wrote:
>That seems a little, uh, optimistic. The Java Programming Language
>book, and the corresponding Java Virtual Machine Specification, first
>editions, were both published in 1996.

No, not optimistic. Mere fact. Sun Microsystems made Java 1.0 generally
available for download on January 23, 1996, for the Windows 95, Windows NT,
and Solaris operating systems (three different operating systems across two
different processor architectures). That was over two decades ago.

http://web.archive.org/web/20080205101616/http://www.sun.com/smi/Press/sunflash/1996-01/sunflash.960123.10561.xml

I was not even counting Sun's "alpha" and "beta" release timeline, but some
would.

Java isn't the earliest example of a bytecode-to-native technology. IBM's
Technology Independent Machine Interface (TIMI) proved the concept much
earlier. TIMI traces its roots to the IBM System/38 introduced in August,
1979. The latest TIMI technologies are found in the IBM i platform, another
platform deservedly famous as a stable, reliable home for applications.
Before program execution (just before, if necessary) TIMI automatically
translates the bytecode to native code tailored for that particular
hardware model environment, persists it, and runs it. TIMI is arguably even
closer to ABO conceptually than Java is.

Another analog to ABO is the technology that Transitive Corporation (a
company IBM acquired) developed. Apple's Mac OS X 10.4 ("Tiger") for Intel
X86 introduced "Rosetta," a translation technology. Rosetta took Mac OS X
applications compiled for PowerPC and translated them, at program load, to
X86 instructions for execution on Apple's then new Intel-based Macintoshes.
It worked extremely well. Apple removed Rosetta from Mac OS X 10.7 some
years later, after developers had recompiled their applications to ship X86
versions. For a time IBM offered PowerVM Lx86 for IBM Power Servers, a
Transitive technology that performed the reverse translation (X86 to
Power).

There are many well proven technologies that parallel ABO. Java, TIMI,
Rosetta, and PowerVM Lx86 are four examples.

With all that said, one has to be smart about when, where, how, and how
much to test. Bill Woodger reminded me of an important fact, that if you're
not smart about testing and you're just running "big" tests over and over
to tick checkboxes, even when it makes little or no sense, then you're not
actually testing well either. You're very likely missing genuine risks.
Literally nobody wins if you've got an expensive, bloated testing regime
that isn't actually testing what you should be testing in 2016 (and
beyond). There are also many cases when business users simply throw up
their hands and declare "No thank you; I can't afford to wait 68 days for
your testing program to complete," and they shop elsewhere for their IT
services.

My friends and colleagues, we must always be *reasonable* and adaptable,
else we're lost at sea. And it's simply unreasonable to treat ABO
optimizations the same for testing purposes as source code changes and
recompiles. The source code doesn't change! The correct ABO testing effort
answer should be something more than zero and something less than what's
ordinarily advisable for a "typical" source code change/recompile trip.
Please consult with ABO technical experts to help decide where precisely
that "in between" should be given your particular environment and
applications.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: Recompile/Reassemble not always the same :)

[Elardus Engelbrecht]

Gibney, Dave wrote:

>But, IBM Macros (z/OS and CICS) have changed over time. BALR/BASSM etc. 
>Arguably, the module, while different, still preforms the same.  

True. Depending on how you compile it, the resulting object codes may differ or 
may be the same.

Example: RACROUTE ... has this ,RELEASE= 

Depending on what release you specify or let it be defaulted at compiling time, 
your object code may differs.

Then there are that HLASM options like MACHINE() or OPTABLE() 
for example too.

Eventually, your code may performs the same.

Groete / Greetings
Elardus Engelbrecht

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