Re: Delta Outage

[Ed Jaffe]

On 8/17/2016 9:04 PM, Edward Gould wrote:

Is that you in the black leather jacket?


That's me... 8-)

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: GMail vs. COBOL

[Ed Jaffe]

On 8/17/2016 6:31 PM, zMan wrote:

I mean, "When I read the list in GMail, I don't want to see a thread broken
into 27 different ones simply because some folks use non-compliant MUAs."


Yes, every reply from Bill Woodger starts a new thread. I have not yet 
examined the headers to understand why.


This might also happen with some other posters, but Bill's are _by far_ 
the most numerous...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Delta Outage

[Edward Gould]

Ed,

Is that you in the black leather jacket?

Ed

> On Aug 17, 2016, at 6:35 PM, Ed Jaffe  wrote:
> 
> On 8/17/2016 4:25 PM, Clark Morris wrote:
>> From one of the papers I skimmed, the outage may have been caused by a
>> failure in the backup power system or the changeover control system.
>> Does Transaction Processing Facility (Nee Airline Control Program?)
>> support GDPS?
> 
> Delta's mainframe stayed up.
> https://twitter.com/SoulEddieJ/status/764081680483098624
> 
> -- 
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.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: GMail vs. COBOL

[zMan]

I mean, "When I read the list in GMail, I don't want to see a thread broken
into 27 different ones simply because some folks use non-compliant MUAs."

Principle of Least Astonishment suggests, at least to me, that this would
make sense. And given that the predominant desktop client (Outlook--like it
or not, it is the predominant one) just looks at Subject:, and that
mistakenly merging a thread in a discussion forum is pretty unlikely, I'm
suggesting that there's no real downside. Heck, people reply to existing
threads with new topics; this is the inverse. And less likely (what are the
odds that there will be two unconnected threads called "GMail vs. COBOL" at
the same time?)

I certainly understand the purist argument; maybe it could be optional
(though I'd argue that it should be enabled by default).

But this is really OT and I misdoubt that GMail devs read this list...
...though maybe they should!

On Tue, Aug 16, 2016 at 8:01 PM, Tomasz Rola  wrote:

> On Tue, Aug 16, 2016 at 05:02:38PM -0500, Bill Woodger wrote:
> > And now from the archive, posted as a reply to my last.
> >
>
> Both messages came to my mailbox, unlinked from the thread and from
> each other. But I have already linked them. I am using mutt, all it
> takes is four strokes per message - and if the message comes with its
> own subthread linked below, that is even better, whole subthread gets
> placed where it belongs.
>
> During last two years I have learned to enter those strokes without
> thinking much - *n& - and n to locate next lost subthread. I
> think it is time to configure my first keyboard macro in mutt, if
> possible.
>
> If you would like to try something, I will try to help.
>
> --
> Regards,
> Tomasz Rola
>
> --
> ** A C programmer asked whether computer had Buddha's nature.  **
> ** As the answer, master did "rm -rif" on the programmer's home**
> ** directory. And then the C programmer became enlightened...  **
> ** **
> ** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **
>
> --
> 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

Re: JZOS calling a 64 bit class

[Ed Jaffe]

On 8/17/2016 5:17 PM, Janet Graff wrote:

My STEPLIB only contains JVMLDM60 so I'll get with the sysprogs to get the 64 
bit version installed.


Use ISPF 3.4 to look for **.SIEALNKE data sets.

You might get lucky and discover the one you need is already installed.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: JZOS calling a 64 bit class

[Janet Graff]

Edward,

Thank you!  My STEPLIB only contains JVMLDM60 so I'll get with the sysprogs to 
get the 64 bit version installed.

Thanks!
Janet
>On 8/17/2016 4:42 PM, Janet Graff wrote:
>> JAVAJVM EXEC PGM=JVMLDM60

>When you run a 64-bit JVM, the JZOS launcher name must end with six 
>('6') not zero ('0'). Try JVMLDM66 instead.

>BTW, that's the launcher for Java 6 -- a pretty darn slow release. We're 
>using JVMLDM86 for Java 8.

>-- 
>Edward E Jaffe

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

Re: JZOS calling a 64 bit class

[Ed Jaffe]

On 8/17/2016 5:03 PM, Ed Jaffe wrote:

On 8/17/2016 4:42 PM, Janet Graff wrote:

JAVAJVM EXEC PGM=JVMLDM60


When you run a 64-bit JVM, the JZOS launcher name must end with six 
('6') not zero ('0'). Try JVMLDM66 instead.


Actually, each 64-bit release starts with '6' and increases by one for 
each sub release: 6.0 = JVMLDM66, 6.1 = JVMLDM67, 7.0 = JVMLDM76, 7.1 = 
JVMLDM77, 8.0 = JVMLDM86 and so forth...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: JZOS calling a 64 bit class

[Ed Jaffe]

On 8/17/2016 4:42 PM, Janet Graff wrote:

JAVAJVM EXEC PGM=JVMLDM60


When you run a 64-bit JVM, the JZOS launcher name must end with six 
('6') not zero ('0'). Try JVMLDM66 instead.


BTW, that's the launcher for Java 6 -- a pretty darn slow release. We're 
using JVMLDM86 for Java 8.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Delta Outage

[John Crossno]

What's interesting about Twitterland trying to put the blame on the
mainframe, is that Delta has already said something about having trouble
getting 400ish servers back up. But then again, people believe what they
want to, and often are lacking in the common sense arena.

Pardon any typos, sent using my thumbs

On Aug 10, 2016 17:37, "Ed Jaffe"  wrote:

> On 8/10/2016 2:00 PM, Jesse 1 Robinson wrote:
>
>> No planes fell out of Delta's sky. It was the reservation system that
>> crashed; I doubt that the FAA has much to say in that arena.
>>
>
> Exactly. And, the removal of airfare price fixing 38 years ago had no
> bearing on it either. IJS.
>
> Once the dust settles, we'll know _exactly_ what went wrong at Delta and
> why. If you're not following Twitter, you should be aware there are already
> folks trying to make Delta's mainframe the scapegoat.
>
> Many major players had inadequate DRPs and BRPs on 9/11 and the IT
> industry has learned a lot since that time.
>
> Whatever happened to Delta, let's hope it becomes a "teachable" moment for
> everyone that isn't overshadowed by finger pointing or jumping on soapboxes
> by those who wish to espouse some ridiculous political or computer platform
> ideology...
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.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: JZOS calling a 64 bit class

[Janet Graff]

JAVAJVM EXEC PGM=JVMLDM60

>What program name are you invoking on EXEC PGM= ?

>-- 
>Edward E Jaffe

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

Re: JZOS calling a 64 bit class

[Ed Jaffe]

On 8/17/2016 4:32 PM, Janet Graff wrote:

Is there anything special I have to do to convert the 31 bit java invocation 
JCL to 64 bit other than change all the paths to point to the 64 bit java 
libraries and to point to my 64 bit java classes?


What program name are you invoking on EXEC PGM= ?

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Delta Outage

[Ed Jaffe]

On 8/17/2016 4:25 PM, Clark Morris wrote:

 From one of the papers I skimmed, the outage may have been caused by a
failure in the backup power system or the changeover control system.
Does Transaction Processing Facility (Nee Airline Control Program?)
support GDPS?


Delta's mainframe stayed up.
https://twitter.com/SoulEddieJ/status/764081680483098624

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

JZOS calling a 64 bit class

[Janet Graff]

I have Batch JCL to call the JVM to invoke 31 bit java classes.

I have generated the 64 bit version of the java classes and I'm trying to 
convert my JCL to invoke the 64 bit class.

I am getting this error

 CEE3588S A call was made to a function in the AMODE 64 DLL libjvm.so from an 
AMODE 31 caller.   
  From entry point JzosVM::initializeVMArgs() at compile unit offset 
+0094 at entry offset +0094 at  
  address 1AA03D2C. 
 

so it looks like the jvm is 64 bit.  The class I'm invoking is definitely 64 
bit and I've confirmed that by printing out the bitmode in the program and 
running it from the USS command prompt.

Is there anything special I have to do to convert the 31 bit java invocation 
JCL to 64 bit other than change all the paths to point to the 64 bit java 
libraries and to point to my 64 bit java classes?

Is there any way to tell from the CEEDUMP what AMODE 31 caller is causing the 
problem?

Janet

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

Re: Delta Outage

[Clark Morris]

[Default] On 10 Aug 2016 14:37:12 -0700, in bit.listserv.ibm-main
edja...@phoenixsoftware.com (Ed Jaffe) wrote:

>On 8/10/2016 2:00 PM, Jesse 1 Robinson wrote:
>> No planes fell out of Delta's sky. It was the reservation system that 
>> crashed; I doubt that the FAA has much to say in that arena.
>
>Exactly. And, the removal of airfare price fixing 38 years ago had no 
>bearing on it either. IJS.
>
>Once the dust settles, we'll know _exactly_ what went wrong at Delta and 
>why. If you're not following Twitter, you should be aware there are 
>already folks trying to make Delta's mainframe the scapegoat.
>
>Many major players had inadequate DRPs and BRPs on 9/11 and the IT 
>industry has learned a lot since that time.
>
>Whatever happened to Delta, let's hope it becomes a "teachable" moment 
>for everyone that isn't overshadowed by finger pointing or jumping on 
>soapboxes by those who wish to espouse some ridiculous political or 
>computer platform ideology...

From one of the papers I skimmed, the outage may have been caused by a
failure in the backup power system or the changeover control system.
Does Transaction Processing Facility (Nee Airline Control Program?)
support GDPS?

Clark Morris

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

Re: PTF order fulfillment issues and getting HOLDDATA

[Jesse 1 Robinson]

ftp://service.boulder.ibm.com/s390/holddata/full.txt

This is essentially the same job I referred to on Monday as having 'always 
worked' in the past but was suddenly failing. Now it's working again. It's 
vanilla FTP. Was Monday's failure a hiccup? 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Wednesday, August 17, 2016 5:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: PTF order fulfillment issues and getting HOLDDATA

On 8/16/2016 12:57 PM, Richards, Robert B. wrote:

> I would like a list of all servers (DNS names, etc.) that IBM supports
to provide HOLDDATA downloads so that I can stop going to my firewall guy 
begging for an emergency CR (very much frowned upon).

For Shopz and SMP/E RECEIVE ORDER downloads, this documents the IBM server host 
names and IP addresses:
http://www-01.ibm.com/support/docview.wss?uid=isg3T1018808

For manually downloading the HOLDDATA file, use this:
ftp://service.boulder.ibm.com/s390/holddata/full.txt

Kurt Quackenbush -- IBM, SMP/E Development

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

Re: Capturing STC SYSOUT when the STC is shut down

[Paul Gilmartin]

On Wed, 17 Aug 2016 11:39:39 -0500, John McKown wrote:
>
>​What the OP really seems to need is a way to direct one output stream to
>both the SPOOL and a data set. ...​ In JCL, that could do this (assuming the 
>existence of
>the TEE subsystem) might looks something like:
>
>//SYSPRINT DD SUBSYS=(TEE,'DISK,SPOOL')
>//DISK DD DISP=(NEW,CATLG,DELETE),DSN=...
>//SPOOL DD SYSOUT=*
>
>​That might actually be an interesting project.​
> 
One might do this in Rexx with:
SYSCALL pipe
SYSCALL spawn tee
bunch-of-allocates
LINKMVS started-task

... and BPXBATCH to launch the Rexx (that's what it was invented for).

Tee might not be able to deal with data sets, so you might also need
another pipe, then:
SYSCALL spawn cp  /dev/fd/0  //DATA.SET.NAME
(Assuming all this conforms to RACF rules.)

I believe the JCL OUTPUT statement allows direction of SYSPRINT to
several streams, but they must all be SYSOUT.  Why not add
regular data sets to the mix?

I hate JCL!  John's suggestion might be a palliative.

-- gil

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

Re: Real Userid when specifying USER=

[Ed Jaffe]

On 8/17/2016 9:24 AM, Jesse 1 Robinson wrote:

Thanks for setting me straight. The threads I referred to must have focused on 
'where did the JCL come from?'. Nice to know that the original submitter is 
available to a running job.


You can get that information in a running job by issuing RACROUTE 
REQUEST=TOKENXTR followed by RACROUTE REQUEST=TOKENMAP and then mapping 
the result with macro ICHRUTKN. There's lots of good stuff in there...


The token is also stored for completed jobs in JES2/JES3 job and output 
control blocks.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: How does COBOL detect a recursive call?

[Bill Woodger]

That, Victor, could still require "IS RECURSIVE" on the PROGRAM-ID to avoid the 
abend with the IGZ0064S message (because the "handler" is invoked from the same 
program), depending the linkedit/binder RENT/REUS values. So it doesn't make it 
any simpler at the level of the mechanics.

Also, when entered as a "handler", you have no choice about what appears as 
"parameters", so arranging something distinguishable may be an issue.

Generally, a program which previously used ENTRY statements would be rewritten 
with "control data" in the USING if it shared WORKING-STORAGE, and as two 
programs if there was no sharing of WORKING-STORAGE (why did it use an ENTRY in 
the first place?).

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

Re: Capturing STC SYSOUT when the STC is shut down

[John McKown]

On Wed, Aug 17, 2016 at 11:12 AM, John Mattson 
wrote:

> My suggestion would use the KISS principle.  Yes, you can write (and
> maintain) SDSF code or REXX, or use special software, or do it the simple
> way.  Remember an STC is just a JCL job for most practical purposes.
> 1) Change the STC //SYSPRINT to go to DISP=(NEW,CATLG),DSN=SOME.GDG(+1)
> ...
> 2) ADD a new STEP  PGM=ICEGENER  and gener SOME.GDG(+1) to SYSOUT=*
> Mission accomplished.  Audit has the GDG they want for heaven only
> knows why, and the sysout is still in the STC's sysout.
>
>
​As best as I understand the OP's request, he has two "demands": One from
auditing that the output be in a data sets; the second from some users that
they be able to read the output while the STC is still running (apparently
preferably via SDSF because they know it). Your solution addresses the
first, but precludes the second.​

​What the OP really seems to need is a way to direct one output stream to
both the SPOOL and a data set. This sort of thing is (conceptually) done in
a UNIX environment by piping output into the "tee" command. "tee" takes its
input (the output of the command) and writes it to all the output files in
its parameter list and to stdout as well (so that the user can see it as it
is being written).​ In JCL, that could do this (assuming the existence of
the TEE subsystem) might looks something like:

//SYSPRINT DD SUBSYS=(TEE,'DISK,SPOOL')
//DISK DD DISP=(NEW,CATLG,DELETE),DSN=...
//SPOOL DD SYSOUT=*

​That might actually be an interesting project.​


-- 
Klein bottle for rent -- inquire within.

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: Capturing STC SYSOUT when the STC is shut down

[Paul Gilmartin]

On Wed, 17 Aug 2016 09:12:09 -0700, John Mattson wrote:

>My suggestion would use the KISS principle.  Yes, you can write (and
>maintain) SDSF code or REXX, or use special software, or do it the simple
>way.  Remember an STC is just a JCL job for most practical purposes.
>1) Change the STC //SYSPRINT to go to DISP=(NEW,CATLG),DSN=SOME.GDG(+1) ...
>2) ADD a new STEP  PGM=ICEGENER  and gener SOME.GDG(+1) to SYSOUT=*
>Mission accomplished.  Audit has the GDG they want for heaven only
>knows why, and the sysout is still in the STC's sysout.
> 
I inferred the OP has the requirement (although he didn't explicitly state it) 
to
be able to view the incomplete SYSPRINT with SDSF while the job is running.

-- gil

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

Re: Real Userid when specifying USER=

[Jesse 1 Robinson]

Thanks for setting me straight. The threads I referred to must have focused on 
'where did the JCL come from?'. Nice to know that the original submitter is 
available to a running job.  

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Tuesday, August 16, 2016 5:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Real Userid when specifying USER=

On Tue, 16 Aug 2016 22:53:32 +, Jesse 1 Robinson  
wrote:

>We've had threads here about the difficulty of associating a running 
>job with the person/process that submitted it. At submit time-- passing 
>a job stream to the internal reader--the submitter's userid is known so 
>as to validate SAF authority to run the job under whatever userid is coded on 
>the job card, if any. After that the origin of the job is not knowable unless 
>the 'submitting process' has embedded such information somewhere in the job 
>itself.

Not true. The UTOKEN attached to the ACEE while the job is running records both 
the submitting user and the execution user. However, if that job submits a 
second job, the association with the original user who submitted the first job 
is lost.

--
Walt


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

Re: Capturing STC SYSOUT when the STC is shut down

[John Mattson]

My suggestion would use the KISS principle.  Yes, you can write (and
maintain) SDSF code or REXX, or use special software, or do it the simple
way.  Remember an STC is just a JCL job for most practical purposes.
1) Change the STC //SYSPRINT to go to DISP=(NEW,CATLG),DSN=SOME.GDG(+1) ...
2) ADD a new STEP  PGM=ICEGENER  and gener SOME.GDG(+1) to SYSOUT=*
Mission accomplished.  Audit has the GDG they want for heaven only
knows why, and the sysout is still in the STC's sysout.

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

Re: How does COBOL detect a recursive call?

[Victor Gil]

Chuck,

Just another weird suggestion which may [or may not] work in your case - why 
can't the very SAME entry point also serve as the error handler?

I mean, it is being called with a parameter list, so by parsing the input 
parameters can't it determine the exact reason for call?

And if it's for the error handling - just take another path?

HTH,
-Victor-


==
The wherefores of using a main program and an ENTRY versus 2 programs is a 
political battle I am not prepared or willing to fight. 
When initially assigned this project I was hoping that my Systems status within 
the company would grant me some carte blanche in how I engineered the solution 
but, alas, I was mistaken. 
 
Suffice it to say, until/unless I find a technical problem to warrant the 
multiple program construct, or even the multiple programs per member construct, 
I am stuck with using the COBOL language verbs as they have been engineered. 
If, and when, they fail to function, I will have the ammunition I need to push 
for one of the other programming constructs. 
 
I do appreciate all of your narratives of what was occurring. 
 
Chuck 
 
Charles (Chuck) Hardee 
Senior Systems Engineer/Database Administration 
EAS Information Technology 
 
Thermo Fisher Scientific 
300 Industry Drive | Pittsburgh, PA 15275 
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230 
chuck.har...@thermofisher.com  | www.thermofisher.com 
 
WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies. 
 


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

Re: PTF order fulfillment issues and getting HOLDDATA

[Kurt Quackenbush]

On 8/16/2016 12:57 PM, Richards, Robert B. wrote:

Thanks Skip. I'll take a look at this further, but in the end, I still will 
need to resolve the firewall issues.


As a reminder, if anyone is having local firewall troubles using FTPS 
due to the IBM servers now requiring secured downloads, I highly 
recommend adding the following statements to your  information 
and trying to use HTTPS instead:


javahome="/usr/lpp/java/Jx.x"
downloadmethod="https"
downloadkeyring="javatruststore"

Of course specify the correct directory for your preferred and installed 
level of Java on the javahome attribute.  Many firewalls/proxies seem to 
be much more tolerant of HTTPS than FTPS.


Kurt Quackenbush -- IBM, SMP/E Development

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

CSVLLIX2, LLA Exit2: overrrule LLA's algorithme?

[Vernooij, Kees (ITOPT1) - KLM]

Hello,

2 decades ago, we brought the IMS program library under LLA whith positive 
results for the IMS performance.
After refreshing the library it took LLA quite some time to calculate which 
modules should be staged to VLF and in the meantime we had bad IMS response 
times. We solved this in CSVLLIX2 by forcing LLA to stage IMS program library 
modules to VLF quickly.

Is anyone still overruling LLA's staging algorithms in CSVLLIX2 or is everybody 
happy with LLA's default decisions?

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

Re: PTF order fulfillment issues and getting HOLDDATA

[Kurt Quackenbush]

On 8/16/2016 12:57 PM, Richards, Robert B. wrote:


I would like a list of all servers (DNS names, etc.) that IBM supports

to provide HOLDDATA downloads so that I can stop going to my firewall
guy begging for an emergency CR (very much frowned upon).

For Shopz and SMP/E RECEIVE ORDER downloads, this documents the IBM 
server host names and IP addresses:

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

For manually downloading the HOLDDATA file, use this:
ftp://service.boulder.ibm.com/s390/holddata/full.txt

Kurt Quackenbush -- IBM, SMP/E Development

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

Re: High disconnect times and PPRC

[Gonzalo Cengotita]

Hi,

Then you should do CQUERY to the secondary devices to find the Global Copy
links

Regards,


*Gonzalo Cengotita*

2016-08-17 12:50 GMT+02:00 Martyn Jones :

> The adapters we are seeing with high response times are 0032 and 0532.
>
> Turns out these are the Async links to a Global Mirror site at a
> considerable distance (we weren't aware of this part of the config). So,
> the high PPRC response times were a red herring.
>
> It is definitely a DS8800 site, and they are using PPRC/GDPS ..
>
> So, we're still at a loss to explain the extremely high disconnect times
> we're occasionally seeing (up to 77 seconds, although at very low activity
> rates).
>
> Thanks for all your input.
>
> Martyn
>
> --
> 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: High disconnect times and PPRC

[Martyn Jones]

The adapters we are seeing with high response times are 0032 and 0532.

Turns out these are the Async links to a Global Mirror site at a considerable 
distance (we weren't aware of this part of the config). So, the high PPRC 
response times were a red herring.

It is definitely a DS8800 site, and they are using PPRC/GDPS ..

So, we're still at a loss to explain the extremely high disconnect times we're 
occasionally seeing (up to 77 seconds, although at very low activity rates).

Thanks for all your input.

Martyn

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

Re: High disconnect times and PPRC

[Gonzalo Cengotita]

Hi,

DMX11 is the serial number of the disk cabinet. Which adapters are you
seeing with the high response time?


*Gonzalo Cengotita*

2016-08-16 14:16 GMT+02:00 Martyn Jones :

> Our client is experiencing delays due to high disconnect times in a PPRC
> environment.
>
> These problems do not appear to be due to high traffic, nor can I see any
> obvious pattern to their occurrences.
>
> Looking at the PPRC statistics from the RMF type 74-8 records, I can see
> two adapters out of the 10 used that have average responses up to 42 times
> those of the other links.
>
> Using the CQUERY command however, I can find no devices that show these
> links being used (on any sub-channel).
>
> Anybody got any suggestions where else I could look?
>
> Martyn
>
>
> --
> 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: PTF order fulfillment issues and getting HOLDDATA

[Richards, Robert B.]

Okay, color me confused. Here is the FTP from last Saturday that worked:

EZA1456I Connect to ?   
  
EZA1736I  public.dhe.ibm.com
  
EZA1554I Connecting to: dispby-112.boulder.ibm.com 170.225.15.112 port: 21. 
  
Snipped disclaimer...
220 service.boulder.ibm.com FTP server (Version wu-2.6.3(5) Custom Tue Jul 2 
15:15:19 MDT 2013) ready.

>From Sunday through yesterday that did not work:

EZA1456I Connect to ?   
EZA1736I  public.dhe.ibm.com
EZA1554I Connecting to: dispmy-112.mul.ie.ibm.com 129.35.224.112 port: 21.  

>From this morning with NO CHANGES made on my end:

EZA1456I Connect to ?   
EZA1736I  public.dhe.ibm.com
EZA1554I Connecting to: dispby-112.boulder.ibm.com 170.225.15.112 port: 21. 
220 ProFTPD 1.3.5b Server (proftpd) [170.225.15.112]

My firewall did not like:  dispmy-112.mul.ie.ibm.com 129.35.224.112 port: 21.

IBM, at least for this morning, reverted back to dispby-112.boulder.ibm.com 
170.225.15.112 port: 21 and my FTP worked like a charm.

In my joy at a good FTP, I almost missed the second line of: ProFTPD 1.3.5b 
Server (proftpd). A quick search revealed where it came from. Perhaps the 
developers should ask IBM if they can list them as one of the sites powered by 
ProFTPD.  :-)

Bob

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