Re: AEHTRIBMKC?

[Jack J. Woehr]

On 10/12/2017 2:35 PM, Karl S Huf wrote:

That's a recurring problem I run into.  Use the function in your browser
(each one has a different method) to purge the IBM cookies.


THANK YOU for actually answering my question! Deleting cookies worked.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: ShopZ order response

[Clark Morris]

[Default] On 12 Oct 2017 13:57:48 -0700, in bit.listserv.ibm-main
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:

>On Wed, 11 Oct 2017 23:52:12 -0500, Edward Gould wrote:
>>> 
 IOW we are going to be majorly hurt if IBM decided to drop tape.
 
>>> I'd be inclined to trust the SHA-1 checksum transmitted via an independent
>>> verifiable conduit more than a heat-sealed polyethylene sleeve on a 3480 
>>> cartridge.
>>> SMP/E will verify the checksum and Do No Evil.
>>>
>>I have asked the auditor and he seems happy with a plastic sealed envelope 
>>that is handled by signatures. 
>>
>"signatures"?  Do you mean you expect Ginni to pick up a Sharpie and
>sign the plastic sleeve?
>
>I believe John Eels at SHARE Denver predicted the demise of tape as an
>interchange vehicle.  In part because the media are no longer being
>manufactured.
>
>A customer asked, "Then might it be permissible to return used tapes to IBM
>for re-use?"
>
>"No."
>
>>Like I said I was always happy with a 3480/3420 tape. I suspect that if 
>>someone is going to intercept a tape they are reasonably advanced 
>>counterfiting team.
>> 
>Since in the near future no one will be able to create a tape, it follows 
>logically
>that no one will be able to counterfeit one.

Given that IBM has reported a way to create multi-terabyte tapes (and
presumably read them), I find it hard to believe tape is dead. Whether
there will be enough drives of a given type commonly available at the
dwindling number of mainframe sites to make it worth while for IBM to
have that tape drive to create the tapes is another question. 3420s
and then 3480s were at one time ubiquitous.  Now I suspect the variety
of incompatible drives is making make it increasing interesting for
any vendor to supply their software on tape.

Clark Morris
>
>You need to get a different auditor; one who is comfortable with the fact
>that in the 21st Century enterprises widely use the Internet to transfer
>busiess-critical data.
>
>-- 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: fopen DD

[Alan Young]

Try changing the STDENV DD to 

//STDENV DD *
_BPX_BATCH_SPAWN=YES
_BPX_SHAREAS=YES
/*

The variables are discussed in 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa400/bpxug240.htm

-Original Message-
>From: Frank Swarbrick 
>Sent: Oct 12, 2017 5:17 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: fopen DD
>
>I am playing with the Swift for z/OS beta.  Swift itself supports little in 
>the way of I/O, and instead depends on the underlying C runtime.  Below is a 
>small program that opens a file, reads 4 bytes in to a buffer and writes out 
>the results as an integer.
>
>import Libc
>
>func fwx(file filename: String, access: String) {
>if let fwf = fopen(filename, access) {
>defer { fclose(fwf) }
>let buffer = UnsafeMutablePointer.allocate(capacity: 1)
>defer { buffer.deallocate(capacity: 1) }
>let _ = fread(buffer, MemoryLayout.size, 1, fwf)
>print("from \(filename): \(buffer.pointee)")
>}
>else {
>print("error opening file \(filename): \(errno)")
>}
>}
>
>fwx(file: "/u/dvfjs/fw.bin", access: "rb")
>fwx(file: "//'DVFJS.FW'", access: "rb")
>fwx(file: "dd:FW", access: "rb")
>
>The last three statements are the "mainline" of the program.  For the first 
>one the file is a Unix file.  For the second one its a VSAM ESDS called 
>'DVFJS.FW'.  Both of these work.  I can't figure out how to specify a DD 
>reference to make that last one work.  I've tried both using "dd:FW" and 
>"//dd:FW".  Is it perhaps a problem with the DD itself?  When running it under 
>BPXBATCH I am specifying the FW DD like I would for any other batch job:
>
>//SHELL  JOB NOTIFY=,REGION=2000M
>//UNIXSH  EXEC PGM=BPXBATCH,PARMDD=PARMSIN
>//FW  DD DISP=SHR,DSN=DVFJS.FW
>//PARMSIN DD *
>SH /u/dvfjs/src/fw
>/*
>//STDIN   DD DUMMY
>//STDOUT  DD SYSOUT=*
>//STDERR  DD SYSOUT=*
>//STDENV  DD DUMMY
>//
>
>Does the Unix environment for BPXBATCH not have access to the JCL DD?
>
>We don't have a license for the C compiler, so I've never used C for z/OS.
>
>Frank
>

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

Re: fopen DD

[Paul Gilmartin]

On Fri, 13 Oct 2017 00:17:40 +, Frank Swarbrick wrote:
>
>//SHELL  JOB NOTIFY=,REGION=2000M
>//UNIXSH  EXEC PGM=BPXBATCH,PARMDD=PARMSIN
>//FW  DD DISP=SHR,DSN=DVFJS.FW
>//PARMSIN DD *
>SH /u/dvfjs/src/fw
>/*
>//STDIN   DD DUMMY
>//STDOUT  DD SYSOUT=*
>//STDERR  DD SYSOUT=*
>//STDENV  DD DUMMY
>//
>
>Does the Unix environment for BPXBATCH not have access to the JCL DD?
> 
Right.  BPXBATCH starts a new address space which inherits none of the DDs.
BPXBATSL runs in the job step address space, but has onerous APF entanglements.

I don't know that BPXWUNIX is better.

The cumbersome alternative is to use Rexx; BPXWDYN('alloc dd(FW) ...'), then
address SYSCALL spawn with BPX_SHAREAS=MUST.  Details are left as an
exercise for the student.  The MVS-OE forum might be helpful.

-- gil

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

fopen DD

[Frank Swarbrick]

I am playing with the Swift for z/OS beta.  Swift itself supports little in the 
way of I/O, and instead depends on the underlying C runtime.  Below is a small 
program that opens a file, reads 4 bytes in to a buffer and writes out the 
results as an integer.

import Libc

func fwx(file filename: String, access: String) {
if let fwf = fopen(filename, access) {
defer { fclose(fwf) }
let buffer = UnsafeMutablePointer.allocate(capacity: 1)
defer { buffer.deallocate(capacity: 1) }
let _ = fread(buffer, MemoryLayout.size, 1, fwf)
print("from \(filename): \(buffer.pointee)")
}
else {
print("error opening file \(filename): \(errno)")
}
}

fwx(file: "/u/dvfjs/fw.bin", access: "rb")
fwx(file: "//'DVFJS.FW'", access: "rb")
fwx(file: "dd:FW", access: "rb")

The last three statements are the "mainline" of the program.  For the first one 
the file is a Unix file.  For the second one its a VSAM ESDS called 'DVFJS.FW'. 
 Both of these work.  I can't figure out how to specify a DD reference to make 
that last one work.  I've tried both using "dd:FW" and "//dd:FW".  Is it 
perhaps a problem with the DD itself?  When running it under BPXBATCH I am 
specifying the FW DD like I would for any other batch job:

//SHELL  JOB NOTIFY=,REGION=2000M
//UNIXSH  EXEC PGM=BPXBATCH,PARMDD=PARMSIN
//FW  DD DISP=SHR,DSN=DVFJS.FW
//PARMSIN DD *
SH /u/dvfjs/src/fw
/*
//STDIN   DD DUMMY
//STDOUT  DD SYSOUT=*
//STDERR  DD SYSOUT=*
//STDENV  DD DUMMY
//

Does the Unix environment for BPXBATCH not have access to the JCL DD?

We don't have a license for the C compiler, so I've never used C for z/OS.

Frank

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

Re: whois.ibm.com - gone

[zMan]

On Thu, Oct 12, 2017 at 6:09 PM, Edward Gould 
wrote:

> Yes people make mistakes but they correct the problem as soon as they are
> made aware of it. That is the way I have been taught since kindergarten.
> *ITS* your responsibility. to fix things that you broke.


That's so last-century. Everyone is exceptional, and it's not "broken", it
just has a different perspective. If someone else doesn't like it, *they *can
fix it!

(Yes, tongue firmly in cheek, lest ye think I've completely lost it)

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

Re: whois.ibm.com - gone

[Edward Gould]

> On Oct 12, 2017, at 12:06 PM, Sankaranarayanan, Vignesh 
>  wrote:
> 
> Errr what?
> I'm sure you noticed that I'm not from IBM?
> An IBM employee wouldn't tweet an IBM 'situation' out to the world.
> 
> PS: Someone who's a bit rubbish in their job doesn't need be from India for 
> it to make sense. As if the entire rest of the world is 100% correct and 
> perfect all the time.
> 
> IBM has been making a lot of changes to their sites in the recent past; cut 
> them some slack. Whether this was a mistake or not, people are allowed to 
> make mistakes (as long as they then learn from it). Deal with it.
> If this was a service you were very reliant on, contact your service rep.
> 
> – Vignesh
> Mainframe Infrastructure

Yes people make mistakes but they correct the problem as soon as they are made 
aware of it. That is the way I have been taught since kindergarten. *ITS* your 
responsibility. to fix things that you broke.

Ed


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

Re: ShopZ order response

[Paul Gilmartin]

On Wed, 11 Oct 2017 23:52:12 -0500, Edward Gould wrote:
>> 
>>> IOW we are going to be majorly hurt if IBM decided to drop tape.
>>> 
>> I'd be inclined to trust the SHA-1 checksum transmitted via an independent
>> verifiable conduit more than a heat-sealed polyethylene sleeve on a 3480 
>> cartridge.
>> SMP/E will verify the checksum and Do No Evil.
>>
>I have asked the auditor and he seems happy with a plastic sealed envelope 
>that is handled by signatures. 
>
"signatures"?  Do you mean you expect Ginni to pick up a Sharpie and
sign the plastic sleeve?

I believe John Eels at SHARE Denver predicted the demise of tape as an
interchange vehicle.  In part because the media are no longer being
manufactured.

A customer asked, "Then might it be permissible to return used tapes to IBM
for re-use?"

"No."

>Like I said I was always happy with a 3480/3420 tape. I suspect that if 
>someone is going to intercept a tape they are reasonably advanced 
>counterfiting team.
> 
Since in the near future no one will be able to create a tape, it follows 
logically
that no one will be able to counterfeit one.

You need to get a different auditor; one who is comfortable with the fact
that in the 21st Century enterprises widely use the Internet to transfer
busiess-critical data.

-- gil

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

Re: AEHTRIBMKC?

[Tony Harminc]

On 12 October 2017 at 16:35, Karl S Huf  wrote:
> That's a recurring problem I run into.  Use the function in your browser
> (each one has a different method) to purge the IBM cookies.  Some of the
> IBM pages have been updated to recognize this has happened and actually
> redirect to a page designed to allow for a one-click IBM cookie purge.
> Sadly most don't (and I don't have this cookie problem with ANY other
> website that I visit regularly).

Of course I don't *want* to purge all my cookies, or even all my IBM
cookies. I have logon info and who knows what else needed to use
various IBM sites. This is the same nonsense told to me by my bank and
ebay and Facebook and Google and any number of other sites - "oh, your
cookies are probably messed up so just delete them all" Right! :-(
Then we're into "Forgotten your userid?" Yes, it was in a cookie but I
had to delete it.

A function to purge "messed up" IBM cookies sounds great, but I don't
suppose there's a link to such a page that'll last more than a week.

Tony H.

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

Re: AEHTRIBMKC?

[Karl S Huf]

That's a recurring problem I run into.  Use the function in your browser
(each one has a different method) to purge the IBM cookies.  Some of the
IBM pages have been updated to recognize this has happened and actually
redirect to a page designed to allow for a one-click IBM cookie purge.
Sadly most don't (and I don't have this cookie problem with ANY other
website that I visit regularly).



___
Karl S Huf | Senior Vice President | World Wide Technology
50 S LaSalle St, LQ-18, Chicago, IL  60603 | phone (312)630-6287 |
k...@ntrs.com
Please visit northerntrust.com
CONFIDENTIALITY NOTICE: This communication is confidential, may be
privileged and is meant only for the intended recipient. If you are not
the intended recipient, please notify the sender ASAP and delete this
message from your system.  NTAC:3NS-20

P Please consider the environment before printing this e-mail.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jack J. Woehr
> Sent: Thursday, October 12, 2017 12:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXT] AEHTRIBMKC?
>
> Normal stupid question of the day: Anyone else having trouble reaching
IBM
> Knowledge Center?
>
> /Should have its own acronym, "AEHTRIBMKC?"/
>
> Today I am unable to reach the Knowledge Center from Firefox on Mac
and
> Ubuntu Linux, but I can reach it okay from Firefox on Windows 7.
>
> On the two failing platforms, the response is :
>
>
>   Bad Request
>
> Your browser sent a request that this server could not understand.
> Size of a request header field exceeds server limit.
>
> Cookie
>
>

> IBM_HTTP_Server at www-01.ibm.com
>  2D01.ibm.com=DwICaQ=K5gMqH44tVpW9Mb7NvpzqAFAhrpSdUITR819
> D8huNsU=PjUrsjOU3_h7Q7zyRd3wDw=Lobg1OV8mkhXsBcyK7ux-Aja-
> MfE30pHapqnWRuoDl8=S2v9OekQZ1ob3XTnlZNQOOW3Za9KqTKCfmoVMO
> Y12Hs=> Port 443
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a
way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
Carl
> Sagan
>
>
> --
> 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: AEHTRIBMKC?

[Jack J. Woehr]

On 10/12/2017 2:21 PM, Allan Staller wrote:

I am basing this on perceived deficiencies in the aforementioned availability, 
functionality and content.
Not "just because they are new".



I am basing my question on the fact that I can't connect :)

Anybody else in the same shape?

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: AEHTRIBMKC?

[Allan Staller]

Agreed. 

I am basing this on perceived deficiencies in the aforementioned availability, 
functionality and content.
Not "just because they are new". 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Thursday, October 12, 2017 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AEHTRIBMKC?

There are two kinds of fools. One says, “This is old, therefore it is good”; 
the other says, “This is new, therefore it is better.”  -- William Ralph Inge

> John McKown 
> October 12, 2017 at 2:27 PM
> On Thu, Oct 12, 2017 at 1:16 PM, Allan Staller  
> ​ But they are so __NEW__ and ... and ... ___SHINY___! They simply 
> must be better. ​ And next week we will be premiering the new, 
> chromed, hexagonal wheel! Made with nanotechnology for that quantum effect 
> feeling!
>
>
> --
> I just child proofed my house.
> But the kids still manage to get in.
>
>
> Maranatha! <><
> John McKown
>
> --
> 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'.
>
> Allan Staller  October 12, 2017 at 2:16 
> PM The "new tools" are not as reliable, available, or functional as 
> the tools they are replacing.
>
> Yitsha'CK HeyZeus  October 12, 2017 at 
> 1:53 PM confession dat really him dat confession of me triratsirhc
>
> Twilight bver
>
> On Thu, Oct 12, 2017 at 1:52 PM Jack J. Woehr  wrote:
>
> > Normal stupid question of the day: Anyone else having trouble 
> > reaching IBM Knowledge Center?
> >
> > /Should have its own acronym, "AEHTRIBMKC?"/
> >
> > Today I am unable to reach the Knowledge Center from Firefox on Mac 
> > and Ubuntu Linux, but I can reach it okay from Firefox on Windows 7.
> >
> > On the two failing platforms, the response is :
> >
> >
> > Bad Request
> >
> > Your browser sent a request that this server could not understand.
> > Size of a request header field exceeds server limit.
> >
> > Cookie
> >
> > 
> > 
> > IBM_HTTP_Server at www-01.ibm.com
> 
>  >
> Port 443
> >
> > --
> > Jack J. Woehr # Science is more than a body of knowledge. It's a way 
> > of www.well.com/~jax
>  #
> thinking, a way of skeptically interrogating the
> > universe
> > www.softwoehr.com
>  #
> with a fine understanding of human fallibility. -
> > Carl Sagan
> >
> >
> > 
> > -- 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
>
>
> 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'.
>
> Jack J. Woehr 
> October 12, 2017 at 1:51 PM
> Normal stupid question of the day: Anyone else having trouble reaching 
> IBM Knowledge Center?
>
> /Should have its own acronym, "AEHTRIBMKC?"/
>
> Today I am unable to reach the Knowledge Center from Firefox on Mac 
> and Ubuntu Linux, but I can reach it okay from Firefox on Windows 7.
>
> On the two failing platforms, the response is :
>
>
> Bad Request
>
> Your browser sent a request that this server could not understand.
> Size of a request header field exceeds server limit.
>
> Cookie
>
> --
> --
> IBM_HTTP_Server at www-01.ibm.com
> 
>  >
> Port 443
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way 
> of www.well.com/~jax  # thinking, a way of 
> skeptically interrogating the universe www.softwoehr.com 
>  # with a fine understanding of human 
> fallibility. - Carl Sagan
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> 

Re: whois.ibm.com - gone

[John Arwe]

On 10/12/2017 8:29 AM, Edward Gould wrote:
>> It is gone permanently, I'm afraid.  DSTM, please.
> DTSM there are several acronyms, one of which is gross and I don’t think you 
> are talking about Santa Monica. Please elaborate.

I believe JE's intended meaning is:

Don't
Shoot
The
Messenger


John Arwe
z/VM devt

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

Re: AEHTRIBMKC?

[Mark Jacobs - Listserv]

There are two kinds of fools. One says, “This is old, therefore it is 
good”; the other says, “This is new, therefore it is better.”  -- 
William Ralph Inge



John McKown 
October 12, 2017 at 2:27 PM
On Thu, Oct 12, 2017 at 1:16 PM, Allan Staller 
​ But they are so __NEW__ and ... and ... ___SHINY___! They simply must be
better. ​ And next week we will be premiering the new, chromed, hexagonal
wheel! Made with nanotechnology for that quantum effect feeling!


--
I just child proofed my house.
But the kids still manage to get in.


Maranatha! <><
John McKown

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


Allan Staller 
October 12, 2017 at 2:16 PM
The "new tools" are not as reliable, available, or functional as the 
tools they are replacing.


Yitsha'CK HeyZeus 
October 12, 2017 at 1:53 PM
confession dat really him dat confession of me triratsirhc

Twilight bver

On Thu, Oct 12, 2017 at 1:52 PM Jack J. Woehr  wrote:

> Normal stupid question of the day: Anyone else having trouble reaching
> IBM Knowledge Center?
>
> /Should have its own acronym, "AEHTRIBMKC?"/
>
> Today I am unable to reach the Knowledge Center from Firefox on Mac and
> Ubuntu Linux, but I can reach it okay from Firefox on Windows 7.
>
> On the two failing platforms, the response is :
>
>
> Bad Request
>
> Your browser sent a request that this server could not understand.
> Size of a request header field exceeds server limit.
>
> Cookie
>
> 
> IBM_HTTP_Server at www-01.ibm.com 
 
> 
Port 443

>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax 
 # 
thinking, a way of skeptically interrogating the

> universe
> www.softwoehr.com 
 # 
with a fine understanding of human fallibility. -

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


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


Jack J. Woehr 
October 12, 2017 at 1:51 PM
Normal stupid question of the day: Anyone else having trouble reaching
IBM Knowledge Center?

/Should have its own acronym, "AEHTRIBMKC?"/

Today I am unable to reach the Knowledge Center from Firefox on Mac and
Ubuntu Linux, but I can reach it okay from Firefox on Windows 7.

On the two failing platforms, the response is :


Bad Request

Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.

Cookie


IBM_HTTP_Server at www-01.ibm.com 
 
> 
Port 443


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax 
 # 
thinking, a way of skeptically interrogating the universe
www.softwoehr.com 
 # 
with a fine understanding of human fallibility. - Carl Sagan



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

Re: AEHTRIBMKC?

[John McKown]

On Thu, Oct 12, 2017 at 1:16 PM, Allan Staller 
wrote:

> The "new tools" are not as reliable, available, or functional as the tools
> they are replacing.
>
>
​But they are so __NEW__ and ... and ... ___SHINY___! They simply must be
better.​ And next week we will be premiering the new, chromed, hexagonal
wheel! Made with nanotechnology for that quantum effect feeling!


-- 
I just child proofed my house.
But the kids still manage to get in.


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: AEHTRIBMKC?

[Allan Staller]

The "new tools" are not as reliable, available, or functional as the tools they 
are replacing.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Yitsha'CK HeyZeus
Sent: Thursday, October 12, 2017 12:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AEHTRIBMKC?

confession dat really him dat confession of me triratsirhc

Twilight bver

On Thu, Oct 12, 2017 at 1:52 PM Jack J. Woehr  wrote:

> Normal stupid question of the day: Anyone else having trouble reaching 
> IBM Knowledge Center?
>
> /Should have its own acronym, "AEHTRIBMKC?"/
>
> Today I am unable to reach the Knowledge Center from Firefox on Mac 
> and Ubuntu Linux, but I can reach it okay from Firefox on Windows 7.
>
> On the two failing platforms, the response is :
>
>
>   Bad Request
>
> Your browser sent a request that this server could not understand.
> Size of a request header field exceeds server limit.
>
> Cookie
>
> --
> -- IBM_HTTP_Server at www-01.ibm.com  Port 443
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the 
> universe www.softwoehr.com # with a fine understanding of human 
> fallibility. - Carl Sagan
>
>
> --
> 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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




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

Re: AEHTRIBMKC?

[Yitsha'CK HeyZeus]

confession dat really him dat confession of me triratsirhc

Twilight bver

On Thu, Oct 12, 2017 at 1:52 PM Jack J. Woehr  wrote:

> Normal stupid question of the day: Anyone else having trouble reaching
> IBM Knowledge Center?
>
> /Should have its own acronym, "AEHTRIBMKC?"/
>
> Today I am unable to reach the Knowledge Center from Firefox on Mac and
> Ubuntu Linux, but I can reach it okay from Firefox on Windows 7.
>
> On the two failing platforms, the response is :
>
>
>   Bad Request
>
> Your browser sent a request that this server could not understand.
> Size of a request header field exceeds server limit.
>
> Cookie
>
> 
> IBM_HTTP_Server at www-01.ibm.com  Port 443
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
>
> --
> 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

AEHTRIBMKC?

[Jack J. Woehr]

Normal stupid question of the day: Anyone else having trouble reaching 
IBM Knowledge Center?


/Should have its own acronym, "AEHTRIBMKC?"/

Today I am unable to reach the Knowledge Center from Firefox on Mac and 
Ubuntu Linux, but I can reach it okay from Firefox on Windows 7.


On the two failing platforms, the response is :


 Bad Request

Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.

Cookie


IBM_HTTP_Server at www-01.ibm.com  Port 443

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


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

Re: whois.ibm.com - gone

[Sankaranarayanan, Vignesh]

That statement was for people who tend to point fingers.
Note that at least in the mainframe world, we have to fill savagely huge shoes 
and it's not the easiest job in the world, considering the bigger picture (that 
only we are 'lucky enough' to see).


">>I'd like to believe this was [not? -- gil] because of me (!!!), but
>>only IBM knows what really happened :)"

Meant it as I said it (without the 'not').
Just found it slightly amusing that something I said may have caused IBM to 
take down a site. Very unlikely, but an amusing prospect nonetheless.

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: 12 October 2017 23:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: whois.ibm.com - gone

On Thu, 12 Oct 2017 17:06:48 +, Sankaranarayanan, Vignesh wrote:
>
>PS: Someone who's a bit rubbish in their job doesn't need be from India for it 
>to make sense. As if the entire rest of the world is 100% correct and perfect 
>all the time.
>
No offense intended; I merely was amused by a coincidence in your surname, an 
earlier somewhat prejudiced ply which I quoted, and that in your otherwise 
excellent English (it might be your first language), you seem to have omitted 
an adverb, "not":

>>I'd like to believe this was [not? -- gil] because of me (!!!), but
>>only IBM knows what really happened :)

I believe walls, trade barriers, and the residue of the Mason-Dixon Line are 
Bad Things.  If employees overseas were compensated fairly, according to 
ability, there'd be no incentive for companies to move jobs offshore.
The pernicious "cheapest bidder" effect would remain as powerful locally as 
internationally.

Apologies for whatever political content, gil

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Re: whois.ibm.com - gone

[Paul Gilmartin]

On Thu, 12 Oct 2017 17:06:48 +, Sankaranarayanan, Vignesh wrote:
>
>PS: Someone who's a bit rubbish in their job doesn't need be from India for it 
>to make sense. As if the entire rest of the world is 100% correct and perfect 
>all the time.
> 
No offense intended; I merely was amused by a coincidence in your
surname, an earlier somewhat prejudiced ply which I quoted, and
that in your otherwise excellent English (it might be your first
language), you seem to have omitted an adverb, "not":

>>I'd like to believe this was [not? -- gil] because of me (!!!), but only IBM 
>>knows
>>what really happened :)

I believe walls, trade barriers, and the residue of the Mason-Dixon Line
are Bad Things.  If employees overseas were compensated fairly, according
to ability, there'd be no incentive for companies to move jobs offshore.
The pernicious "cheapest bidder" effect would remain as powerful locally
as internationally.

Apologies for whatever political content,
gil

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

Re: Transfer a large number of sequential file from mainframe to redhat linux V6.5

[Clark Morris]

[Default] On 12 Oct 2017 09:03:14 -0700, in bit.listserv.ibm-main
ibmm...@foxmail.com (ibmm...@foxmail.com) wrote:

>Hi John
>
> Could you give us a sample of the ftp job or the rexx? 
>
>Thanks a lot !
A major consideration, at least on the z series side is the cpu and
MSU costs of doing the transfer with compression versus the costs of
doing it without compression.

Clark Morris
>
>Jason Cai
>
>
>>>?My first though is to "tune" your network. I'm assuming you are talking
>>>from z/OS to Linux via TCPIP over ethernet. ?From what little I know, most
>seem to use an MTU of 1500. You might get better throughput if you could
>configure the MTU to be larger. This is oft times called "jumbo frames" (
>https://en.wikipedia.org/wiki/Jumbo_frame ).
> 
>Whether to compress or not is basically a trade off between how long it
>takes to compress-transfer-uncompress vs. just transfer. This will depend
>on the power of the boxes on each end and the "size of the pipe" between
>them.
> 
>Assuming a "large pipe" (that is 10 Gib/s or larger):
>I am not certain how you generate the list of files to be transferred. But
>what I would possibly do is multiple concurrent FTP jobs running at the
>same time. For example: job 1 in the job stream finds all the DSNs to be
>transferred. For each DSN, it creates an FTP "put" control card. Assuming
>REXX as the language of choice, each control card is recorded in a stem
>variable. Something like: ftp_control.0=;
>ftp_control.1="put "; and so on. Now determine the number of concurrent
>FTPs you want to do. Divide the number of ftp control cards by this number.
>Create a normal batch job where each job runs a single FTP step which has
>"n" ftp_control cards in it. Submit each job to z/OS using the internal
>reader. Have enough initiators running to run those jobs. Let them all (or
>a subset) run at one time. The extreme of this is to have each job do a
>single FTP. And have "n" initiators running those jobs. You could generate,
>say, 20 FTP jobs, and run 5 at a time by having 5 initiators set up &
>dedicated to running just those jobs (by dedicating a specific JOBCLASS to
>this purpose).
> 
>Anyway, I was just thinking that instead of serially compressing,
>transferring, and uncompressing the data; it might be faster with a "large
>pipe" to do multiple transfers concurrently.
> 
> 

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

Re: Transfer a large number of sequential file from mainframe to redhat linux V6.5

[ibmm...@foxmail.com]

Hi John

 Could you give us a sample of the ftp job or the rexx? 

Thanks a lot !

Jason Cai


>>​My first though is to "tune" your network. I'm assuming you are talking
>>from z/OS to Linux via TCPIP over ethernet. ​From what little I know, most
seem to use an MTU of 1500. You might get better throughput if you could
configure the MTU to be larger. This is oft times called "jumbo frames" (
https://en.wikipedia.org/wiki/Jumbo_frame ).
 
Whether to compress or not is basically a trade off between how long it
takes to compress-transfer-uncompress vs. just transfer. This will depend
on the power of the boxes on each end and the "size of the pipe" between
them.
 
Assuming a "large pipe" (that is 10 Gib/s or larger):
I am not certain how you generate the list of files to be transferred. But
what I would possibly do is multiple concurrent FTP jobs running at the
same time. For example: job 1 in the job stream finds all the DSNs to be
transferred. For each DSN, it creates an FTP "put" control card. Assuming
REXX as the language of choice, each control card is recorded in a stem
variable. Something like: ftp_control.0=;
ftp_control.1="put "; and so on. Now determine the number of concurrent
FTPs you want to do. Divide the number of ftp control cards by this number.
Create a normal batch job where each job runs a single FTP step which has
"n" ftp_control cards in it. Submit each job to z/OS using the internal
reader. Have enough initiators running to run those jobs. Let them all (or
a subset) run at one time. The extreme of this is to have each job do a
single FTP. And have "n" initiators running those jobs. You could generate,
say, 20 FTP jobs, and run 5 at a time by having 5 initiators set up &
dedicated to running just those jobs (by dedicating a specific JOBCLASS to
this purpose).
 
Anyway, I was just thinking that instead of serially compressing,
transferring, and uncompressing the data; it might be faster with a "large
pipe" to do multiple transfers concurrently.
 
 
-- 
I just child proofed my house.
But the kids still manage to get in.
 
 
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: git, z/OS and COBOL

[Jesse 1 Robinson]

Today LinkedIn news note points to an article on Git for z/OS by Rosalind 
Radcliffe, who has been speaking at SHARE for some time on its virtues. This 
very long URL goes through LinkedIn. 

https://www.linkedin.com/pulse/git-zos-development-how-do-you-build-now-can-rosalind-radcliffe/?trk=eml-email_feed_ecosystem_digest_01-recommended_articles-7-PBYN=AQFJkRF5baAZ4A=fromEmail=3GEOaGOlxTtnY1
  

.
.
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 David Crayford
Sent: Thursday, October 12, 2017 3:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: git, z/OS and COBOL

On 11/10/2017 9:48 PM, Pew, Curtis G wrote:
>> I'd like to run into the problems before the applications people have a 
>> chance to hit it so we can head that all off.
>>
>> And I'd love to know the answers to this before the POC dies. So I am very 
>> interested in this thread.
> I think all the discussion of line numbering is a bit of a red herring. You 
> can still use git on files that have line numbers. It may have to keep track 
> of “changes” that don’t really change anything, and it may require additional 
> storage and processing, but git still works.
>
> In most cases line numbers imbedded in files are relics of older 
> technologies, and you’re better off eliminating them. But if there’s a case 
> where you do still need them, it won’t prevent current technology from doing 
> its thing.
>
> (In case you couldn’t tell, I’m a big fan of git. I don’t think anyone 
> who embraces it will regret it.)

Indeed! If you can ditch those relics all the better. I'm a big fan of git too. 
It's revolutionized our workflows on z/OS. We use bitbucket and Jira from 
Atlassian which integrate beautifully. We use agile and raise a Jira for each 
feature branch. This gives us visibility to every line of code that has been 
changed for each feature. We do code reviews on pull requests which is great 
for QA. Code reviews find bugs early and we've found find more bugs than 
systems testing.


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

Re: whois.ibm.com - gone

[Paul Gilmartin]

On Wed, 11 Oct 2017 23:02:47 -0400, Tony Thigpen wrote:
>...
>I wonder if they outsourced their web stuff to India? :-)
>...

On Thu, 12 Oct 2017 14:03:20 +, Sankaranarayanan, Vignesh wrote:

>About a few weeks ago, I tweeted saying I found a page within ibm.com that 
>allowed looking up an IBM-er's contact info by just inputting their last name.
>
>I'd like to believe this was because of me (!!!), but only IBM knows what 
>really happened :)
>
>- Vignesh
>Mainframe Infrastructure
>
Errr...

-- gil

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

Re: whois.ibm.com - gone

[Phil Smith III]

Tony Thigpen wrote:

>They have really messed up their web sites in the last two years. Using Doc
online now just about impossible. And, many times, they don't even give an
easy to find PDF download option. (I have found that going back up the
manual chain will sometimes give you the option.)

 

>Lately, a lot of Google links to IBM sites just get that pesky 'not found'
screen.

 

>I wonder if they outsourced their web stuff to India? :-)

 

I think so. A month or so ago, I heard about a z14 event on the wrong coast.
So I went did some searches, wound up at https://www.ibm.com/events/ and
searched for "z14". Which gets you 104 results-none of which are actually
about the z14. So this is the new, premier product, yet it's not findable.
Brilliant.

 

I opened a ticket, and got a response:

Thank you for contacting IBM.

We are in receipt of your e-mail regarding the IBM z14.

For information about the IBM z14, please visit the below link:

 
https://www.redbooks.ibm.com/redbooks.nsf/pages/z14?Open

If this is not the information you are looking for, please resend your
e-mail with additional information such as:

- the detail description of the request

- kind of assistance you are looking for

Thank you for visiting our site and contacting IBM.

 

Responded to that, pointing out that it didn't answer my question ("Where
are the z14 events?") and noting that they should be a wee bit more
interested in a failure of basic site functionality. That got the automated
response and then nothing.

 

Mentioned it to a friend with POK connections. He forwarded it to an IBM
Fellow, who pushed it up the chain, but:

 

xxx just called back after talking with several maroons within the IBM
marketing cog. He is confirming, that for all practical purposes, all IBM
websites are now supported externally by sub-contractors. Many of these subs
have zero knowledge of or about IBM other than what they are told and so
they implement and walk away.

 

I've been an IBM fan for over 40 years; I've made my living off of IBM
systems for almost that entire time (since 1980, minus about a year during
the dot-com bubble). Sadly, at this point I'm hoping they survive until I
retire. Makes me feel physically ill.

 

.phsiii


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

Re: whois.ibm.com - gone

[Sankaranarayanan, Vignesh]

About a few weeks ago, I tweeted saying I found a page within ibm.com that 
allowed looking up an IBM-er's contact info by just inputting their last name.

I'd like to believe this was because of me (!!!), but only IBM knows what 
really happened :)

- Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: 12 October 2017 12:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: whois.ibm.com - gone

John Eells wrote:
> Dyck, Lionel B. , TRA wrote:
>> It would appear that the whois.ibm.com site that was very useful to
>> find contact info for any IBM employee has been removed.  Does anyone
>> know if there is a new url for that service?
>>
>
> I sent a note asking what happened to it.  I'll let the list know if I
> get a response.
>

It is gone permanently, I'm afraid.  DSTM, please.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Re: whois.ibm.com - gone

[Paul Gilmartin]

On Thu, 12 Oct 2017 07:29:38 -0500, Edward Gould wrote:
>> 
>> It is gone permanently, I'm afraid.  DSTM, please.
>
>DTSM there are several acronyms, one of which is gross and I don’t think you 
>are talking about Santa Monica. Please elaborate.
>Thanks,
> 
Try DSTM, instead.

-- gil

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

Re: whois.ibm.com - gone

[Edward Gould]

> On Oct 12, 2017, at 6:02 AM, John Eells  wrote:
> 
> John Eells wrote:
>> Dyck, Lionel B. , TRA wrote:
>>> It would appear that the whois.ibm.com  site that 
>>> was very useful to
>>> find contact info for any IBM employee has been removed.  Does anyone
>>> know if there is a new url for that service?
>>> 
>> 
>> I sent a note asking what happened to it.  I'll let the list know if I
>> get a response.
>> 
> 
> It is gone permanently, I'm afraid.  DSTM, please.

John,

DTSM there are several acronyms, one of which is gross and I don’t think you 
are talking about Santa Monica. Please elaborate.
Thanks,

Ed
> 
> -- 
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com 

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

Re: [EXTERNAL] Re: whois.ibm.com - gone

[Dyck, Lionel B. (TRA)]

DTSM - don't shoot the messenger

But I think another explanation is that whois.ibm.com is now DTSM - dark side 
of the moon

--
Lionel B. Dyck <><
Mainframe Systems Programmer - TRA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Thursday, October 12, 2017 7:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: whois.ibm.com - gone

At first glance, it looked to me like  you used a common pinball players' 
euphemism: SDTM - Straight Down the Middle!  (but strangely appropriate)

Is Bluepages next?

Dana

On Thu, 12 Oct 2017 07:02:35 -0400, John Eells  wrote:

>John Eells wrote:
>
>It is gone permanently, I'm afraid.  DSTM, please.
>
>--
>John Eells
>IBM Poughkeepsie
>ee...@us.ibm.com
>

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

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

Re: whois.ibm.com - gone

[Dana Mitchell]

At first glance, it looked to me like  you used a common pinball players' 
euphemism: SDTM - Straight Down the Middle!  (but strangely appropriate)

Is Bluepages next?

Dana

On Thu, 12 Oct 2017 07:02:35 -0400, John Eells  wrote:

>John Eells wrote:
>
>It is gone permanently, I'm afraid.  DSTM, please.
>
>--
>John Eells
>IBM Poughkeepsie
>ee...@us.ibm.com
>

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

Re: Transfer a large number of sequential file from mainframe to redhat linux V6.5

[John McKown]

On Thu, Oct 12, 2017 at 1:08 AM, ibmm...@foxmail.com 
wrote:

> Hi
>
> > Are the files Classic data sets or z/OS UNIX files?
>
> The files are Classic data sets from unloading zos db2 table.
>
> > Are the files binary or text?
>
>  The files are text
>
> > Which compression technique(s)  are  you considering?
>
> Any  compression technique(s) we are  considering
>
> Thanks a lot!
>
> Jason Cai
>
>
​My first though is to "tune" your network. I'm assuming you are talking
from z/OS to Linux via TCPIP over ethernet. ​From what little I know, most
seem to use an MTU of 1500. You might get better throughput if you could
configure the MTU to be larger. This is oft times called "jumbo frames" (
https://en.wikipedia.org/wiki/Jumbo_frame ).

Whether to compress or not is basically a trade off between how long it
takes to compress-transfer-uncompress vs. just transfer. This will depend
on the power of the boxes on each end and the "size of the pipe" between
them.

Assuming a "large pipe" (that is 10 Gib/s or larger):
I am not certain how you generate the list of files to be transferred. But
what I would possibly do is multiple concurrent FTP jobs running at the
same time. For example: job 1 in the job stream finds all the DSNs to be
transferred. For each DSN, it creates an FTP "put" control card. Assuming
REXX as the language of choice, each control card is recorded in a stem
variable. Something like: ftp_control.0=;
ftp_control.1="put "; and so on. Now determine the number of concurrent
FTPs you want to do. Divide the number of ftp control cards by this number.
Create a normal batch job where each job runs a single FTP step which has
"n" ftp_control cards in it. Submit each job to z/OS using the internal
reader. Have enough initiators running to run those jobs. Let them all (or
a subset) run at one time. The extreme of this is to have each job do a
single FTP. And have "n" initiators running those jobs. You could generate,
say, 20 FTP jobs, and run 5 at a time by having 5 initiators set up &
dedicated to running just those jobs (by dedicating a specific JOBCLASS to
this purpose).

Anyway, I was just thinking that instead of serially compressing,
transferring, and uncompressing the data; it might be faster with a "large
pipe" to do multiple transfers concurrently.


-- 
I just child proofed my house.
But the kids still manage to get in.


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: [EXTERNAL] Re: whois.ibm.com - gone

[Dyck, Lionel B. (TRA)]

John - we won't shoot you - thanks for checking

--
Lionel B. Dyck <><
Mainframe Systems Programmer - TRA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Thursday, October 12, 2017 6:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: whois.ibm.com - gone

John Eells wrote:
> Dyck, Lionel B. , TRA wrote:
>> It would appear that the whois.ibm.com site that was very useful to 
>> find contact info for any IBM employee has been removed.  Does anyone 
>> know if there is a new url for that service?
>>
>
> I sent a note asking what happened to it.  I'll let the list know if I 
> get a response.
>

It is gone permanently, I'm afraid.  DSTM, please.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

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

Re: whois.ibm.com - gone

[John Eells]

John Eells wrote:

Dyck, Lionel B. , TRA wrote:

It would appear that the whois.ibm.com site that was very useful to
find contact info for any IBM employee has been removed.  Does anyone
know if there is a new url for that service?



I sent a note asking what happened to it.  I'll let the list know if I
get a response.



It is gone permanently, I'm afraid.  DSTM, please.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: git, z/OS and COBOL

[David Crayford]

On 11/10/2017 9:48 PM, Pew, Curtis G wrote:

I'd like to run into the problems before the applications people have a chance 
to hit it so we can head that all off.

And I'd love to know the answers to this before the POC dies. So I am very 
interested in this thread.

I think all the discussion of line numbering is a bit of a red herring. You can 
still use git on files that have line numbers. It may have to keep track of 
“changes” that don’t really change anything, and it may require additional 
storage and processing, but git still works.

In most cases line numbers imbedded in files are relics of older technologies, 
and you’re better off eliminating them. But if there’s a case where you do 
still need them, it won’t prevent current technology from doing its thing.

(In case you couldn’t tell, I’m a big fan of git. I don’t think anyone who 
embraces it will regret it.)


Indeed! If you can ditch those relics all the better. I'm a big fan of 
git too. It's revolutionized our workflows on z/OS. We use bitbucket and 
Jira from Atlassian which integrate beautifully. We use agile and raise 
a Jira for each feature branch. This gives us visibility to every line 
of code that has been changed for each feature. We do code reviews on 
pull requests which is great for QA. Code reviews find bugs early and 
we've found find more bugs than systems testing.


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

Re: APAR OA53994

[Jousma, David]

FYI, the GA version of the PTF is available for this.   While we didn’t see the 
problem either, this is one of those that could be very pervasive and maybe not 
noticed for awhile...

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, October 03, 2017 5:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APAR OA53994

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Even though we are not aware of having the problem, we've been pursuing the 
++APAR fix just in case. In order to APPLY CHECK it cleanly, we had to include 
a cousin PTF that we had not yet received, let alone applied: UA92697. That PTF 
is also PEed but fixed by the same APAR. Level 2 didn't seem to understand our 
problem. IBM does advise, after all, receiving all maintenance on a regular 
basis. We don't. ;-( Just be aware that if UA92697 is not already installed 
(before it went PE presumably), then you need to include it in the same apply 
job with AA53994. 

BTW we're inclined to wait for the GA PTF. 

.
.
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 Jousma, David
Sent: Monday, October 02, 2017 6:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: APAR OA53994

All,  just an FYI, we are in the middle of a maintenance cycle, and happened to 
pick up these offending PTF's awhile back.   IBM does have an APARFIX 
available.   I'm working with them trying to gauge the confidence level in it.  
They have updated the text of the APAR to include the conditions required for 
it to occur.   Probably a fairly rare case, but good to close the hole.

ERROR DESCRIPTION:
  During CLOSE processing of an extended format dataset, a logic
  error occurs causing the blocks at the end of the dataset to not
  be written out to the dataset if the I/O has not completed yet.
 
  Conditions for problem to occur:
  - QSAM and OUTPUT
  - Physical Sequential Extended Format dataset
  - During close processing, the dataset must run out of space in
the current extent. This will drive EOV processing to get a
new extent and re-drive i/o.
  - The i/o must not complete before we get to the invalid code
path. If it completes, there is no problem.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: Jousma, David
Sent: Monday, October 02, 2017 7:51 AM
To: 'IBM Mainframe Discussion List'
Subject: RE: APAR OA53994

Thanks for the heads up Skip.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, September 29, 2017 3:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: APAR OA53994


I just got a notice from ASAP that APAR OA53994 has PEed PTF UA91904 ,  which 
we installed in July. It looks pretty serious: records dropped at the end of an 
extended format sequential file. We have had no reports of such a problem, but 
it's pretty worrying. Has anyone stumbled on this crack in the sidewalk?

.
.
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
**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, 

Re: Transfer a large number of sequential file from mainframe to redhat linux V6.5

[ibmm...@foxmail.com]

Hi 

 We could move our datasets to a same volume and convert the  volume to a cckd 
image using Hercules utilies

after we transfer the cckd image to linux,how will the cckd image be used by 
linux? 

Thanks a lot!

Best Regards

Jason Cai


>A suggestion...Could be better or not... You could try... Convert your volume 
>to a cckd image using Hercules utilies. Once they are converted, you will be 
>take advantage of compression and time to this transfer. I did same thing some 
>thing, with success. Btw there is one a problem, you need to move your 
>datasets to a same volume.. Make sense?

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

Re: Transfer a large number of sequential file from mainframe to redhat linux V6.5

[ibmm...@foxmail.com]

Hi 

> Are the files Classic data sets or z/OS UNIX files?
 
The files are Classic data sets from unloading zos db2 table.

> Are the files binary or text?
 
 The files are text

> Which compression technique(s)  are  you considering?
 
Any  compression technique(s) we are  considering

Thanks a lot!

Jason Cai 

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