Re: COBOL and POSIX pipes

[Paul Gilmartin]

On Thu, 16 Feb 2017 19:32:37 -0800, Anne & Lynn Wheeler wrote:
>
>Unix traditional records are variable length deliminated by trailing
>null/zero byte.
> 
For text files on disk it was far more traditonal to use LF or  NL
rather than NUL as the delimiter.

>lots of traditional unix API programming would read w/o
>length restriction and common attack is to provide extremely long record
>that would overwrite end of buffer being used ... resulting failure
>and/or compromise. Lots of pressure to get UNIX (c language) programmers
>to use API that specify maximum length read.
>
read(), fread(), fgets(), and snprintf() all provide a maximum length
argument.  Among the antiquated outliers are gets() and sprintf().
Those should be neither used nor taught nowadays.

Traditional automobiles lacked seat belts, air bags, and collision
warning systems.  Modern automotive designers aren't allowed to
omit most of those features, although deregulation may change
that.  Few such restrictions apply to software designers.

And it's pointless to boast, repeatedly, about how much better
we are nowadays.

-- gil

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

Re: COBOL and POSIX pipes

[Anne & Lynn Wheeler]

john.archie.mck...@gmail.com (John McKown) writes:
> ​It adds some really nice features to legacy z/OS. But UNIX files can be
> confusing to z/OS programmers because they are more like "memory" than
> "disk" in that they are simply an ordered sequence of _bytes_, not
> _records_. The file system itself does not have _any_ interpretation o​f
> how those bytes are grouped into logical records. z/OS programmers, in
> general, are used to reading individual records when reading a data set.
> When you read a UNIX file, the program must tell the UNIX kernel ("access
> method") how many bytes you want to read. UNIX will return __NO MORE__ than
> that number of bytes. It could return fewer, if there are not that many
> left before "end of file" (an on some other rare occasions). Your code must
> then somehow know where the data you want (aka "this record") ends. Which
> means either the file is composed of fixed length records, hard coded in
> the program, or there is meta information encoded in the file data itself
> which indicates a length (similar to the LLBB field in a z/OS variable
> length data set) for each record. You can't rely on the system "handing"
> you a "logical record: when you do a UNIX read simply because there is no
> such thing, in a general sense.

Unix traditional records are variable length deliminated by trailing
null/zero byte. lots of traditional unix API programming would read w/o
length restriction and common attack is to provide extremely long record
that would overwrite end of buffer being used ... resulting failure
and/or compromise. Lots of pressure to get UNIX (c language) programmers
to use API that specify maximum length read.

I had this discussion with Dennis Ritchie that traditional IBM variable
length used two-byte explicit length prefixing ... while the unix method
saved a byte per record, with just a single (null/zero) byte postfixing
the record ... back in the days of "small memory" and pdp-7 ... birth of
unix
http://www.linfo.org/pdp-7.html

trivia: some of the CTSS people went to the 5th flr and did Multics and
others went to the ibm science center on the 4th floor and did virtual
machines, bunch of online applications, the internal network (also used
for university bitnet/earn) and invented GML. folklore is that some of
the AT&T worked on multics and then returned home and did unix
https://en.wikipedia.org/wiki/Multics#UNIX
dennis
https://en.wikipedia.org/wiki/Dennis_Ritchie

past posts mentioning ibm science center, 4th flr, 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech
CTSS
https://en.wikipedia.org/wiki/Compatible_Time-Sharing_System

I joke that when release 1 cp67 was delivered to the university in
Jan1968 it had some code that I completely rewrote ... but then saw very
similar code in unix 20yrs later (possibly all having traced back to
CTSS?). recent posts mentioning early cp67
http://www.garlic.com/~lynn/2017b.html#26 Virtualization's Past Helps Explain 
Its Current Importance
http://www.garlic.com/~lynn/2017b.html#27 Virtualization's Past Helps Explain 
Its Current Importance
http://www.garlic.com/~lynn/2017b.html#28 Virtualization's Past Helps Explain 
Its Current Importance
http://www.garlic.com/~lynn/2017b.html#29 Virtualization's Past Helps Explain 
Its Current Importance
http://www.garlic.com/~lynn/2017b.html#30 Virtualization's Past Helps Explain 
Its Current Importance
http://www.garlic.com/~lynn/2017b.html#32 Virtualization's Past Helps Explain 
Its Current Importance

I've also frequently commented that the original IBM mainframe TCP/IP
product was implemented in vs/pascal and *never* had any of the length
related vulnerabiilties and exploits that have been epidemic in C
language implementations. some past posts
http://www.garlic.com/~lynn/subintegrity.html#buffer

-- 
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: COBOL and POSIX pipes (was: A design question)

[John McKown]

On Thu, Feb 16, 2017 at 7:49 PM, scott Ford  wrote:

> You guys are amazing. I havent used Unix on Z/OS much, a little. It has
> advantages for sure.
>
> Scott
>
>
​It adds some really nice features to legacy z/OS. But UNIX files can be
confusing to z/OS programmers because they are more like "memory" than
"disk" in that they are simply an ordered sequence of _bytes_, not
_records_. The file system itself does not have _any_ interpretation o​f
how those bytes are grouped into logical records. z/OS programmers, in
general, are used to reading individual records when reading a data set.
When you read a UNIX file, the program must tell the UNIX kernel ("access
method") how many bytes you want to read. UNIX will return __NO MORE__ than
that number of bytes. It could return fewer, if there are not that many
left before "end of file" (an on some other rare occasions). Your code must
then somehow know where the data you want (aka "this record") ends. Which
means either the file is composed of fixed length records, hard coded in
the program, or there is meta information encoded in the file data itself
which indicates a length (similar to the LLBB field in a z/OS variable
length data set) for each record. You can't rely on the system "handing"
you a "logical record: when you do a UNIX read simply because there is no
such thing, in a general sense.

The main drawback to z/OS UNIX is the relatively extreme overhead of doing
a fork() or spawn(). UNIX shells do those by the _ton_. Which explains the
BPXAS instances, which are the UNIX equivalent of a WLM batch initiator
(even runs the same program, IEFIIC, just with a special PARM= value).
Another drawback, to me, of z/OS UNIX is that the supplied UNIX tools (like
awk, find and /bin/sh) are _not_ as good as the GNU versions. Thankfully
Rocket Software has stepped into the gap with a nice port of many of them
for _no cost_, with optional paid support.

-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

Re: ICSF Question

[Mark Jacobs - Listserv]

The key labels are readable, so you know what keys are there. The field 
that describes what the key is used for, DATA, EXPORTER,... is also 
readable. What information are you looking to ascertain?


Mark Jacobs


Steely.Mark 
February 16, 2017 at 6:20 PM
Is there anything out there that will generate a report of what is in 
the variable length CKDS ?


I am able to browse the file but some type of report would be nice.

Thanks

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





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

Re: COBOL and POSIX pipes (was: A design question)

[scott Ford]

You guys are amazing. I havent used Unix on Z/OS much, a little. It has
advantages for sure.

Scott

On Mon, Feb 13, 2017 at 1:35 PM, John McKown 
wrote:

> On Mon, Feb 13, 2017 at 12:28 PM, Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Mon, 13 Feb 2017 11:58:57 -0600, John McKown wrote:
> > >
> > >...having already used
> > >a UNIX subroutine, I guess I figured it was easier to use another UNIX
> > >subroutine rather that setting up an FD along with an OPEN / READ loop /
> > >CLOSE.​
> > >
> > >... I think that the HLASM is basically
> > >being used as a "QSAM for RACF" type interface.​
> > >
> > If the replies returned by RACF are of uniform length or the assembler
> > program can pad them, BPX1RED is easiest.  I'm accustomed to
> > dealing with utility output where records are variable length,
> > contain no control characters, and are NL-terminated.  For that,
> > I might as well ALLOC and use the real QSAM.
> >
>
> ​Another point in your favor would be that the resultant code would be more
> understandable to a regular COBOL programmer. The only "oddity" would be
> the setup, in its calls to BPX1PIP and BPXWDYN.​
>
>
>
> >
> > -- gil
> >
> >
>
> --
> Our calculus classes are an integral part of your education.
>
> Maranatha! <><
> John McKown
>
> --
> 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: ICSF Question

[zMan]

"What is in the CKDS" -- keys? How would this report know?

On Thu, Feb 16, 2017 at 6:20 PM, Steely.Mark 
wrote:

> Is there anything out there that will generate a report of what is in the
> variable length CKDS ?
>
> I am able to browse the file but some type of report would be nice.
>
> Thanks
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

ICSF Question

[Steely.Mark]

Is there anything out there that will generate a report of what is in the 
variable length CKDS ? 

I am able to browse the file but some type of report would be nice. 

Thanks

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

Re: LBI w/ TAPE|DASD [Was:31 vs 24 QSAM]

[Jesse 1 Robinson]

Thanks for the clarification. It's been three or four years since I did this. 

I created

   SYSPDCBE DCBE  BLKSIZE=0

and added a pointer in the existing SYSPRINT DCB

   DCBE=SYSPDCBE

It all worked like a charm. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: Thursday, February 16, 2017 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: LBI w/ TAPE|DASD [Was:31 vs 24 QSAM]

About 2 years ago, I was working on determining a performance problem with an 
ISV product. They were processing a very large amount of data and so we moved 
their data off to Tape, with the idea that we could cut the CPU burn of the 
product (as in, make it wait for I/O as it was eating 65-85% of a single CPU - 
single tasking, not multi-tasking).

What I found, in moving it to tape (VTS) is that the virtual tape was 
responding faster than DASD. And this was w/o LBI.

Did some further testing with LBI (and a test program that had the ability to 
handle LBI), to find that it was able to process the data faster than it could 
from DASD. Significantly faster -- it seems that the VTS was reading from disks 
into cache, and it was caching the "tape" at a rate greater than the DASD Raid 
boxes could respond for the same I/O.

Then we put in a request to the vendor of the first product for LBI support and 
had to explain to them why.

Also, to a different post -- You can't replace a DCB with a DCBE. 
You use them in conjunction with each other, and store the address of the DCBE 
into the DCB BEFORE OPEN, and if all the flags are correct, you have LBI 
support once OPEN is finished.

Regards,
Steve.T

On 02/16/2017 11:44 AM, Jesse 1 Robinson wrote:
> I mentioned having modified a QSAM program to write 'large blocks' by 
> replacing DCB with DCBE. My goal was to test the effect of very large blocks 
> in our new tape subsystem, which we had learned was highly biased in favor of 
> large blocks. This had nothing to do with AMODE, which was all 31. The 
> program certainly ran faster with large blocks such as 260K. I could not 
> distinguish improvement at the IOS level (lower I/O count) vs. improvement at 
> the tape level. Most likely a combination.
>
> My problem with the new tape was that the vendor seemed to assume that a 
> customer could just tweak JCL to create giant blocks. In fact many of our 
> largest tape files are created by utilities--IBM or otherwise--that are not 
> written for large blocks. In practice you can code as large a block size as 
> you wish, but if the program contains only DCBs, any size greater than 32K is 
> simply ignored without error. While the change to DCBE was very simple, it 
> has to be accomplished by the program owner.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>



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

Re: Layout CPC serial number z13S

[Carmen Vitullo]

Thanks Tom 

- Original Message -

From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, February 16, 2017 11:40:25 AM 
Subject: Re: Layout CPC serial number z13S 

On Thu, 16 Feb 2017 11:14:52 -0500, Carmen Vitullo wrote: 

>Tom are you using PROCVIEW CORE? 

Yes. PROCVIEW CORE,CPU_OK 

-- 
Tom Marchant 

-- 
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: KC!? Susan Shumway?

[Paul Gilmartin]

On Fri, 10 Feb 2017 13:30:00 -0500, Susan Shumway wrote:

>Hi Paul(Gil?),
>
>That's great to hear that KC works on Midori! It's always nice to have a
>surprise that's pleasant every once in a while...
> 
But that shouldn't need to be a surprise.  Heed Tim Berners-Lee:
https://www.anybrowser.org/campaign/

>Regarding your wishes:
>
> > o That ToC sidebar should have resize handles, vertically so I can
>see more
> >   lines at once, and horizontally so I can see more of the docment
>titles.
>I (Firefox) see a vertical resize bar to make the TOC frame wider -
>
Ah! I found it.  It's nearly invisible; very few pixels wide.

>perhaps try a different browser. There's no horizontal resize bar, just
>
Tim Berners-Lee

> > o String searches work in that sidebar, but it doesn't scroll to make the
> >   search target visible.  Sheesh!

>Yes, I agree that that's annoying. The issue is actually already known,
>so we'll hope for a resolution soon. In the meantime, at least the
>
Breathlessly awaiting.

>search target is highlighted and its path is expanded in the TOC, so
>just scroll down until you see the highlighted, expanded topic to orient
>yourself.
> 
That does help.


> > o When I follow a link to a topic, then return to the parent page with 
> > browser
> >   "Back" control, it should show that parent page scrolled to the point 
> > where
> >   I left it, as most sites do, not scrolled to the top as KC does.
>
>Yes, this is another annoyance that is known and hopefully resolved
>soon. It's a pain, but, if you've scrolled in a topic and don't want to
>re-scroll when you return to it, the best thing to do for now is to just
>open links in new tabs/windows and return to the original tab/window
>when you're done.
>
I do that whenever I remember.  It's frustrating when I forget.  IIRC, at the
inception of KC, "Back" didn't work at all.  I wonder what possessed the
developers to break it, then only partially repair it.  Better they should
have left it alone.

Complaint of the day:  At page:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.asma100/mvafile.htm
z/OS
z/OS 2.1.0
HLASM
HLASM Programmer's Guide
Assembling your program on z/OS
Input and output data sets

... the header shows the full hierarchy path as shown.  If I switch
to 2.2 (good feature; thanks!), it shows only two levels:
z/OS
z/OS 2.2.0

... What happens to the rest?

Thanks again,
gil

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

Re: LBI w/ TAPE|DASD [Was:31 vs 24 QSAM]

[Steve Thompson]

About 2 years ago, I was working on determining a performance 
problem with an ISV product. They were processing a very large 
amount of data and so we moved their data off to Tape, with the 
idea that we could cut the CPU burn of the product (as in, make 
it wait for I/O as it was eating 65-85% of a single CPU - single 
tasking, not multi-tasking).


What I found, in moving it to tape (VTS) is that the virtual tape 
was responding faster than DASD. And this was w/o LBI.


Did some further testing with LBI (and a test program that had 
the ability to handle LBI), to find that it was able to process 
the data faster than it could from DASD. Significantly faster -- 
it seems that the VTS was reading from disks into cache, and it 
was caching the "tape" at a rate greater than the DASD Raid boxes 
could respond for the same I/O.


Then we put in a request to the vendor of the first product for 
LBI support and had to explain to them why.


Also, to a different post -- You can't replace a DCB with a DCBE. 
You use them in conjunction with each other, and store the 
address of the DCBE into the DCB BEFORE OPEN, and if all the 
flags are correct, you have LBI support once OPEN is finished.


Regards,
Steve.T

On 02/16/2017 11:44 AM, Jesse 1 Robinson wrote:

I mentioned having modified a QSAM program to write 'large blocks' by replacing 
DCB with DCBE. My goal was to test the effect of very large blocks in our new 
tape subsystem, which we had learned was highly biased in favor of large 
blocks. This had nothing to do with AMODE, which was all 31. The program 
certainly ran faster with large blocks such as 260K. I could not distinguish 
improvement at the IOS level (lower I/O count) vs. improvement at the tape 
level. Most likely a combination.

My problem with the new tape was that the vendor seemed to assume that a 
customer could just tweak JCL to create giant blocks. In fact many of our 
largest tape files are created by utilities--IBM or otherwise--that are not 
written for large blocks. In practice you can code as large a block size as you 
wish, but if the program contains only DCBs, any size greater than 32K is 
simply ignored without error. While the change to DCBE was very simple, it has 
to be accomplished by the program owner.

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




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

IBM's 12-month SVC period replaced with MVM

[Al Sherkow]

With Country Multiplex Pricing IBM announced "Multiplex Version Measurement" 
which removed the 12-month time frame for converting to new versions of MLC 
products (DB2 V10 to DB2 V11, MQ V7 to MQ V8). This week with US announcement 
Announcement 217-093 it has been renamed to "Multi-Version Measurement and it 
now applies to those not using Country Multiplex also. 

I need an example to explain, let's continue with DB2 V10 to DB2 V11 on a 1000 
MSU environment. For sites using SCRT for sub-capacity charging the tool would 
report both versions. During the SVC period IBM would charge for the version 
with the greatest number of MSUs at the price of the new version. If you were 
60% converted SCRT might be reporting 600 MSUs for V11 and perhaps 500 MSUs for 
V10. Some of those V10 MSUs could be in LPARs without V11 installed yet. You 
would be charged for 600 MSUs of V11. The V10 MSUs in LPARs without V11 were 
not charged for because of SVC. 

Now with MVM SCRT continues to report DB2 V11 at 600 MSUs and DB2 V10 at 500 
MSUs. These will be added together, but also limited by the z/OS MSUs for MVM. 
Even across all your LPARs if z/OS is using 900 MSUs for it's maximum 
simultaneous 4HRA it would be unfair to charge 1,100 MSUs of DB2. So SCRT adds 
a new line "DB2 (ALL)" and that line will report 900 MSUs, it will never be 
larger than z/OS. You will be charged for 900 MSUs of DB2 V11. 

IPLA products will work similarly, and now do not have their 6 month conversion 
period. 

This will begin with the April 2-May 1 SCRT data, submitted between May 2 and 
May 9. The changes will show up on the June 1st invoices. New releases of SCRT 
(Classic or Java) will be available April 10th to add the functionality to 
report the (ALL) line. 

Of course LCS will be updated to support this new functionality for my 
licensees! 


Al Sherkow, I/S Management Strategies, Ltd.
Consulting Expertise on IBM Workload License Charges (WLC),
LPARs and LCS Software
Seminars Since 2003 on IBM Mainframe Software Pricing
+1 414 332-3062

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

Re: 31 vs 24 QSAM

[Charles Mills]

I don't really know anything about this but it sounds to me like one of @Gil's 
cases of making a good modification in the wrong place. Why not do this is such 
a way as to be transparent to old QSAM programs -- no need for a DCBE? Have an 
operand in the JCL or in SYS1.PARMLIB or the PPT to make it behave as described 
below if necessary, but by default honor the JCL blocksize and hide the > 32K 
from the application. Tell the application the blocksize is 32K -- 15 bit 
integers being what they are -- but go ahead under the covers with a 260K 
blocksize. No QSAM program should be doing its own deblocking, and if it is, 
well, put an exception in the JCL or the PPT or wherever.

Or at the very least make the below behavior the default but have an option to 
honor the 260K even in the absence of a DCBE. Tell the customers their gun, 
their bullet, their feet.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, February 16, 2017 8:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 31 vs 24 QSAM

I mentioned having modified a QSAM program to write 'large blocks' by replacing 
DCB with DCBE. My goal was to test the effect of very large blocks in our new 
tape subsystem, which we had learned was highly biased in favor of large 
blocks. This had nothing to do with AMODE, which was all 31. The program 
certainly ran faster with large blocks such as 260K. I could not distinguish 
improvement at the IOS level (lower I/O count) vs. improvement at the tape 
level. Most likely a combination. 

My problem with the new tape was that the vendor seemed to assume that a 
customer could just tweak JCL to create giant blocks. In fact many of our 
largest tape files are created by utilities--IBM or otherwise--that are not 
written for large blocks. In practice you can code as large a block size as you 
wish, but if the program contains only DCBs, any size greater than 32K is 
simply ignored without error. While the change to DCBE was very simple, it has 
to be accomplished by the program owner.

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

Re: Layout CPC serial number z13S

[Tom Marchant]

On Thu, 16 Feb 2017 11:14:52 -0500, Carmen Vitullo wrote:

>Tom are you using PROCVIEW CORE?

Yes. PROCVIEW CORE,CPU_OK

-- 
Tom Marchant

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

Re: 31 vs 24 QSAM

[Bill Woodger]

Yes, don't just write using LBI from a program and expect to validate old vs 
new with ISRSUPC in batch.

I know that a PMR has been raised about whether ISRSUPC supports LBI, the 
IEC141I 013-E1 message it produces hints at not.

From what I've heard, using LBI, where it is possible to use it, leads to 
dramatic improvements in throughput. Not surprising, 32k blocks vs 256k blocks.

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

Re: 31 vs 24 QSAM

[Jesse 1 Robinson]

I mentioned having modified a QSAM program to write 'large blocks' by replacing 
DCB with DCBE. My goal was to test the effect of very large blocks in our new 
tape subsystem, which we had learned was highly biased in favor of large 
blocks. This had nothing to do with AMODE, which was all 31. The program 
certainly ran faster with large blocks such as 260K. I could not distinguish 
improvement at the IOS level (lower I/O count) vs. improvement at the tape 
level. Most likely a combination. 

My problem with the new tape was that the vendor seemed to assume that a 
customer could just tweak JCL to create giant blocks. In fact many of our 
largest tape files are created by utilities--IBM or otherwise--that are not 
written for large blocks. In practice you can code as large a block size as you 
wish, but if the program contains only DCBs, any size greater than 32K is 
simply ignored without error. While the change to DCBE was very simple, it has 
to be accomplished by the program owner.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Wednesday, February 15, 2017 9:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: 31 vs 24 QSAM

Joseph Reichman wrote:

>I'm going to run it again tomorrow
>Just to double check

With varying LRECL, BLKSIZE and quantity of records/blocks. If you can, of 
course.

Also read a block, read it again, write and write it again. I'm sure you will 
get 'interesting' numbers.

Good luck. If you do that properly, that testing should be a good Red-Book 
article.

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

Re: Layout CPC serial number z13S

[Carmen Vitullo]

That begs a question from me , Tom are you using PROCVIEW CORE? 
we've tired to test this options on a small test LPAR sharing one zIIP engine, 
we did not like the results, so I wonder how it works out on a larger LPAR 
thanks 
Carmen 

- Original Message -

From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, February 16, 2017 10:05:13 AM 
Subject: Re: Layout CPC serial number z13S 

On our z13s, D M=CPU returns this format: 

CORE STATUS: HD=h MT=mm [MODE: CP=cn zIIP=zin] 
ID ST ID RANGE VP ISCM CPU THREAD STATUS 
cId wst tIdL-tIdH vp  tt 
cId wst tIdL-tIdH vp  tt 
cId wst tIdL-tIdH vp  tt 
CPC ND = tt.nnn.mmm.pp.ss 

CPC SI = .... 
Model:  
CPC ID = ii 
CPC NAME = cpc_name 
CPC IS RUNNING AT dd% OF NORMAL EFFECTIVENESS 
LP NAME = lp_na LP ID = jj 
CSS ID = cc 
MIF ID = m 

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieam700/iee174i36.htm
 

-- 
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: Layout CPC serial number z13S

[Tom Marchant]

On our z13s, D M=CPU returns this format:

CORE STATUS: HD=h  MT=mm  [MODE: CP=cn  zIIP=zin]   
   
IDSTID RANGE   VP ISCM  CPU THREAD STATUS
cId   wst   tIdL-tIdH  vp   tt
cId   wst   tIdL-tIdH  vp   tt
cId   wst   tIdL-tIdH  vp   tt
CPC ND = tt.nnn.mmm.pp.ss

CPC SI = ....
 Model: 
CPC ID = ii
CPC NAME = cpc_name
CPC IS RUNNING AT dd% OF NORMAL EFFECTIVENESS
LP NAME = lp_na  LP ID = jj
CSS ID = cc
MIF ID = m

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieam700/iee174i36.htm

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

Re: IBM Netview Session Manager replacement

[Keith Banham]

Forgot to mention that by using RACF PassTickets then you remove the potential 
that user-ids and passwords are visible in plain text over the network or in 
memory or on a DASD etc, depending on your non-PassTicket approach. Again RACF 
PassTickets are a big plus for security and the auditors.

Keith Banham
R&D Manager
Macro 4 Ltd

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

Re: Layout CPC serial number z13S

[R.S.]

W dniu 2017-02-16 o 08:42, Ron van der Zande pisze:

Thanks for the answers. Layout as I expected. But serial numbers I got still 
looking strange.
Layout  84y and 02y
 to be seen in D m=cpu before model at every cpu menthioned
The y might be 8 for BASIC mode and 9 for LPAR mode but about this I am not 
sure if this is still the case.
84 and 02 was the IBM plant number. 02 I see in your displays but 84 looks 
strange to me.
In Europe 51 machine build in Montpellier (France).


51 *was* Montpellier, de factory does not exist anymore (been there, 
seen that).

83 was Ireland
84 is Singapore.


BTW: the layout of CPC number is not changed for z13s, is it?

--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: IBM's Marissa Mayer moment: Staff ordered to work in one of 6 main offices – or face the axe (2)

[Rugen, Len]

I've had the opposite complaint, after pushing each task to where I was waiting 
on something, I was leaving the office about 3 PM one day and ran into the VP.  
He questioned why I was leaving when others had to stay to all hours of the 
night to get their work done.  I said something like "I'm sorry they hired such 
slow people" and kept waking.  This when my mainframe was "going away" and 
being replaced by 100's of servers :-)   I knew I'd get in my "hours" during 
the maintenance windows.  When managers can't determine work effort, they 
revert to "butt time in seat" to attempt to measure effort.  

I'm still here, he is gone

Len Rugen

Metrics and Automation – umdoitmetr...@missouri.edu



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

Re: IBM Netview Session Manager replacement

[Keith Banham]

Like TPX the Tubes product will cater for single password and passing on 
passwords to the applications, as described in the previous entries, but it 
also has RACF PassTicket support - once the user is Authenticated at sign-on to 
Tubes then it utilises RACF capabilities to authorise the sign-on to all their 
applications. Whatever the approach please don't expect the poor end-user to 
remember multiple passwords - they will only write them all down on a 
whiteboard! This is one of the key benefits of using a session manager - 
centralized security, administration and control. With also using RACF to 
determine what applications a user can see and use the security team maintain 
complete control - auditors heaven. Don't be fooled by those who say they can 
just open up more emulation windows - a slippery slope to lose of security and 
control.

Keith Banham
R&D Manager
Macro 4 Ltd


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

Re: IBM's Marissa Mayer moment: Staff ordered to work in one of 6 main offices – or face the axe (2)

[Tom Marchant]

On Wed, 15 Feb 2017 14:46:10 -0500, Phil Smith III  wrote:

>John McKown noted:
>
>>​Lack of loyalty (both ways)​ causes lack of trust. It also, IMO, is why
>>some people decide to defraud their employers in various ways. A kind of
>>tit-for-tat where the employee "gets back his own" from the company.
>>Simplest example: __consistently__ coming in just a bit late ("bad
>>traffic"), taking a bit more time for lunch, leaving just a "bit" early "to
>>avoid the traffic".
>
>Of course you’re right. Folks are also encouraged to such shenanigans by 
>company stupidity, like all-hands meetings that start 10 minutes late, or 
>long, content-free all-company emails. I tend to sit there going “Let’ see, 
>n,000 people x 10 minutes = y man-days wasted…” In a decent-sized company, you 
>get to a man-year pretty fast. For the folks who don’t love their jobs (which 
>some of us are lucky enough to do), this makes it easy and justified to waste 
>a bit of time on their own…

Then there are the employers who routinely expects people to work overtime 
without paying them for the additional work. I once had a job interview with a 
company who told me that they routinely need to work 50 to 60 hours per week. 
My assumption was that they were underestimating it and that they wouldn't 
staff up to the levels where it wouldn't be needed. When they called me back, I 
declined.

-- 
Tom Marchant

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

Re: New DASD for mainframe

[R.S.]

Lizette,
Your qiestions are relevant. And very important.
And that's why I asked about people's experiences. ;-)

And I dare to answer some of the questions:

1) This is matter of declarations. IMHO more important is current set of 
features.

2) See above
3) I don't understand.
4) This is not shop sale, so each contract can be different. I haven't 
seen any offering from that company, but I know what to put in the 
contract. Without those things I won't sign it.
5) More important is fix time, however for my location the offering is 
24/7/356.

6) How close??? This is matter of FICON and speed of light in a glass.
7) This is part of the contract.
8) They claim all microcode updates are online, disk additions and swaps 
are online, controller swaps are online.



(I'm still not a salesman)

--
Radoslaw Skorupka
Lodz, Poland







W dniu 2017-02-16 o 00:53, Lizette Koehler pisze:

Just one comment.

When looking at DASD for mainframe, keep the following items in mind

1) How soon can the vendor implement new functions that IBM implements in IOS

2) What feature(s) are you using today that are not available for some period of
time from the vendor?

3) What issues will the vendor share with their product?  FICON, IOS, etc
bugs, challenges they have seen with implementation

4) What are the maintenance contracts like between IBM and what this vendor
offers?  Is the maintenance included in the purchase?  Does it increase during
extension?

5) What kind of support is provided by the vendor?  24x7x365?  Close to your
shop or far away?  How many CEs are close to your location?

6) How close does the dasd unit need to be to the mainframe?

7) Cost to add/remove storage components.

8) When does the DASD unit need to be totally offline for maintenance?  Or is it
dynamic updates?



Basically hardware is hardware.  What your mission critical apps need should
drive the hardware solution.  If it is not critical, then probably a good
vendor.  If you need something with a high level of deliverables, maybe not.

So, see if there is a list on the internet for the product or vendor.  Probably
there will be chatter if some shops are using it.


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
Sent: Wednesday, February 15, 2017 10:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: New DASD for mainframe

I just learnt there is new DASD (disk system) provider for mainframe.
It's INFINIDAT. From the sales pitch it looks very promising.
The architecture is similar to XIV and the designer is the same person:
Moshe Yanai.
The difference is Infinidat support FICON connectivity and all "must have"
features like HyperPAV, remote copy (PPRC), PiT copy (flashcopy), EAV, etc.

Question:is there anyone who want to share user experience of the DASD?
Offlist opinions are welcome.


Disclaimer: This is not an advertisement, I don't sell it, I have to
relationship to any partner of the company.

--
Radoslaw Skorupka
Lodz, Poland





---
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


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

Re: zLinux

[Vince Getgood]

I thought Timefinder was for replicating data at a local level? (like Flashcopy 
/ snapshot)

You seem to be suggesting moving the data to a remote EMC box.  I would have 
thought SRDF would be the product to use?

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

Re: Dynamic Exit and SDSF DYNX

[Rob Scott]

I imagine that is down to :

(1) For those exits defined via the PROGxx statements at IPL time, the system 
uses CSVDYNEX REQUEST=ADD service without the DSNAME and MODADDR keywords.

(2) The "LoadPt" and "Modlen" fields are only going to be available if CSVDYNEX 
REQUEST=ADD uses DSNAME (both LoadPt and Modlen will be known) or MODADDR (only 
Loadpt will be known).

Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barbara Nitz
Sent: Thursday, February 16, 2017 6:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dynamic Exit and SDSF DYNX

I was kinda blind. The Exit command without DIAG shows both exits, it just 
doesn't show them vertically.

Why are the LoadPt and ModLen for the IPL-loaded Exits not shown in either DYNX 
or the DIAG output?

Barbara

>you're completely right, SYS.IEFUSI is a different *exitname* to 
>SYSTSO.IEFUSI. That explains why I saw DYNX with only the default IEFUSI - I 
>looked at the wrong statement. Now I see that DYNX shows me two lines:
> SYSTSO.IEFUSI  1 IEFUSITS YESYES  8E0A0EA8 0E0A0EA8 0158
> SYSTSO.IEFUSI  2 IEFUSI   YESYES  86995410  
>
>(although I still don't understand why the second is showing me a MODEPA but 
>no LoadPt or ModLen).
>
>Unfortunately:
>
>D PROG,EXIT,EN=SYSTSO.IEFUSI
>CSV461I 07.06.25 PROG,EXIT DISPLAY 778
>EXIT MODULE   STATE MODULE   STATE MODULE   STATE
>SYSTSO.IEFUSIIEFUSITS   A   IEFUSI A
>
>D PROG,EXIT,EN=SYSTSO.IEFUSI,DIAG
>CSV464I 07.11.47 PROG,EXIT DISPLAY 786
>EXIT SYSTSO.IEFUSI
>MODULESTATE EPADDRLOADPTLENGTHJOBNAME   PARAM
>IEFUSITSA   8E0A0EA8  0E0A0EA8  0158  *
>IEFUSI  A   86995410      *
>
>Why are the two displays different (other than the obvious more information 
>from the diag parm)? I expected the one without DIAG to show both exits, too!
>
>Barbara
>
>--
>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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 877.328.2932 ■ +1 781.577.4321
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: 31 vs 24 QSAM

[Martin Packer]

I would also like to know what the buffering spec was in both cases (per my
previous comment).

Thanks, Martin

Sent from my iPad

> On 15 Feb 2017, at 23:18, Joseph Reichman  wrote:
>
> I'm going to run it again tomorrow
>
>
> Just to double check
>
> Thanks  for your help
>
>
>
>> On Feb 15, 2017, at 6:04 PM, Sam Siegel  wrote:
>>
>> Are you sure it is not just cache?  were the tests run multiple times
>> and averaged?  was the load on the system and dasd sub-system similar
>> for each test?
>>
>>> On Wed, Feb 15, 2017 at 12:19 PM, Joseph Reichman
 wrote:
>>> Hi
>>>
>>> And thank you all
>>>
>>> I just did a benchmark
>>>
>>> And I had a significant savings in CPU time
>>>
>>> 24 bit QSAM .85 CPU time 31 bit QSAM .34 CPU time
>>>
>>> I could tell it ran a lot faster
>>>
>>>
>>>
>>>
>>> Joe Reichman
>>> 8045 Newell St Apt 403
>>> Silver Spring MD 20910
>>> Home (240) 863-3965
>>> Cell (917) 748 -9693
>>>
>>> --
>>> 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
>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

AW: Re: The "Cobol and 00A Program Check" Story - Some insight gained

[Peter Hunkeler]

>PER SLIP trap. Cannot issue the command yourself? Find out what brand of 
>scotch your favorite sysprog drinks.


Thanks, but I'm not seeking for help in this case. A couple of people had 
offered their help when I was posting seeking for help in this matter late last 
year. I just posted some new facts, thinking some might be interested.



--
Peter Hunkeler



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