Re: Where's Java!? (SMP/E needs to know.)

[Rick Troth]

I'm a huge fan of sym-link to the "production" version of any package.
That way, you can have older, or newer, releases available simultaneously.
(see end)

The usual magic prefix for IBM is /usr/lpp.
So maybe point /usr/lpp/javaprod at the current release.
You could then set JAVAHOME in /etc/profile to that path,
and users could override JAVAHOME if and when they need to.


On 01/20/2016 05:26 PM, Rob Schramm wrote:

I vote symlink as well.

Rob Schramm

On Wed, Jan 20, 2016, 4:45 PM John McKown 
wrote:


I like the SYMLINK idea. I do that myself, "by hand".

On Wed, Jan 20, 2016 at 3:34 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:


Dammit!  The path to Java changes with any z/OS release and/or
any Java release.  I need continually to add to my PATH variable
to keep up.  And there's nothing an ISV can supply in JCL samples
for SMP/E's SMPJHOME; the example in the SMP/E Reference is
woefully outdated.

This makes as little sense as if programmers were required to
code "//SYSLIB  DD  DSN=SYS1.ZOSV2R2.MACLIB".

I'm inclined to submit an RFE for either a utility to find Java or for
IBM's supplying a usable symbolic  link to a preferred Java.
Retroactive; I can't wait for everyone to be on z/OS 2.3

Any suggestions on form or rationale for such an RFE?

Thanks,
gil

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




--
Werner Heisenberg is driving down the autobahn. A police officer pulls
him over. The officer says, "Excuse me, sir, do you know how fast you
were going?"
"No," replies Dr. Heisenberg, "but I know where I am."

Computer Science is the only discipline in which we view adding a new wing
to a building as being maintenance -- Jim Horning

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

He's about as useful as a wax frying pan.

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


End notes:
I've been pushing a similar common prefix for years.
It happens that /usr/lpp is sort of similar, though IBM uses it a little 
differently.
Sad that these things don't get more traction. We're not getting enough 
out of the richness that is POSIX.


Would love to hear from others who have gone down this road.
Whadaya do about third party stuff? How do you handle things 
consistently across Unix?

(Not all the world is USS.)

-- R; <><

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

Re: Where's Java!? (SMP/E needs to know.)

[Andrew Rowley]

On 21/01/2016 16:50, Rob Schramm wrote:

You are being short sighted.  Why would I spend additional time and energy
updating a myriad of JAVA_HOME statements, scripts, JCL when I can simply
standardize the whole thing.  Sure you can always override JAVA_HOME... but
that is the exception.. Not the rule.
My point is that there shouldn't be a myriad of statements - JAVA_HOME 
should be set in one place and available to everything that needs it. 
Only tasks that need something different should need to specify their 
own JAVA_HOME.


The only reason why we have it in a myriad of places is that there is no 
easy way on z/OS to set an environment variable system-wide. Maybe that 
horse has bolted, but I do think it is better to work towards common 
standards rather than inventing yet another way z/OS is different to 
everything else.


Andrew Rowley

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

Re: Where's Java!? (SMP/E needs to know.)

[Paul Gilmartin]

On Thu, 21 Jan 2016 03:14:44 +, Rob Schramm wrote:

>About the /etc/profile...
>Best to set JAVA_HOME to a symlink.  Less work for an upgrade.  The users
>can always override such things.. Having a standard symlink(s) that can be
>used gives a nice amount of control and consistency.
>
Can you cite an authority for "JAVA_HOME"?  I find it mentioned in various
IBM pubs, mainly relating to Websphere.  It's nowhere mentioned in
/etc/* nor in /samples/*.

Can SMP/E, an old fashioned batch utility expect to find JAVA_HOME set?
Can the batch JCL programmer override it without painful contortions?
Right now, I'm working on the BPXWUNIX function  I cited earlier in JCL
tailoring to select the newest /usr/lpp/java/J*/bin.

Early in Release 3, SMP/E used to execute the programmer's ~/.profile via
a login shell.  That was a disaster; too many surprises.  They got better.

On Linux I see:

500 $ whence java
/usr/bin/java

501 $ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Nov 10  2014 /usr/bin/java -> /etc/alternatives/java

502 $ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 45 Nov 23 20:03 /etc/alternatives/java -> 
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/java

503 $ ls -l /usr/lib/jvm/java-7-openjdk-i386/jre/bin/java
-rwxr-xr-x 1 root root 5596 Nov 20 16:27 
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/java

... I see considerable rationale for the double symlink:  "java" is in a generic
executables directory, pointing to a product-specific directory, pointing to a
version.

-- gil

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

Re: Where's Java!? (SMP/E needs to know.)

[Andrew Rowley]

On 21/01/2016 15:00, Jack J. Woehr wrote:

Andrew Rowley wrote:
In answer to the original question, having SMP/E use the JAVA_HOME 
environment variable would be the clean way.
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim3000/java.htm?lang=en 



Isn't that javahome from a different location? Not the JAVA_HOME 
environment variable?


Andrew Rowley

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

Re: Where's Java!? (SMP/E needs to know.)

[Jack J. Woehr]

Andrew Rowley wrote:


Isn't that javahome from a different location? Not the JAVA_HOME environment 
variable?


Yeah, but it's set the same way JAVA_HOME is, pointing to the root of the 
installation. IBM always has to be kinky,
and beside, they probably wanted to make sure that if the user has a pet java version installed side by side with the 
version

SMP/E uses that it didn't conflict.

Anway, which ever on you set first, some global or local shell file that sets

   export JAVA_HOME=$javahome
   or
   export javahome=$JAVA_HOME

Unix weenies live ensconced in a heap of shell scripts that set environment for given tasks. It's our self-inflicted 
pain the way JCL is that of the z/OS hack :)


I apologize if I have clouded the issue. It just sorta sounded non-issue-ish to 
Unix/Java ears :)

--
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: Where's Java!? (SMP/E needs to know.)

[Jack J. Woehr]

Paul Gilmartin wrote:
Can you cite an authority for "JAVA_HOME"? 

https://docs.oracle.com/cd/E19182-01/820-7851/inst_cli_jdk_javahome_t/

http://askubuntu.com/questions/175514/how-to-set-java-home-for-java

$JAVA_HOME is a convention, but it's a strong one recognized by umpteen 
applications, including Apache software such as Ant.

z hacks certainly recognize the power of conventions in software deployment.


--
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: Where's Java!? (SMP/E needs to know.)

[Rob Schramm]

About the /etc/profile...
Best to set JAVA_HOME to a symlink.  Less work for an upgrade.  The users
can always override such things.. Having a standard symlink(s) that can be
used gives a nice amount of control and consistency.

Rob Schramm

On Wed, Jan 20, 2016, 5:30 PM Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> Doesn't z/OS Unix have the equivalent of /etc/profile?  And doesn't Java
> installation create an entry or invoked script in /etc/profile to set the
> JAVAHOME environment variable as every other *ix system does?  Shouldn't
> that be the preferred method for compatibility with every other *ix Java
> environment?
>
> Just asking  . . .
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, January 20, 2016 4:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Where's Java!? (SMP/E needs to know.)
>
> Dammit!  The path to Java changes with any z/OS release and/or
> any Java release.  I need continually to add to my PATH variable
> to keep up.  And there's nothing an ISV can supply in JCL samples
> for SMP/E's SMPJHOME; the example in the SMP/E Reference is
> woefully outdated.
>
> This makes as little sense as if programmers were required to
> code "//SYSLIB  DD  DSN=SYS1.ZOSV2R2.MACLIB".
>
> I'm inclined to submit an RFE for either a utility to find Java or for
> IBM's supplying a usable symbolic  link to a preferred Java.
> Retroactive; I can't wait for everyone to be on z/OS 2.3
>
> Any suggestions on form or rationale for such an RFE?
>
> Thanks,
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Where's Java!? (SMP/E needs to know.)

[Jack J. Woehr]

Andrew Rowley wrote:


In answer to the original question, having SMP/E use the JAVA_HOME environment 
variable would be the clean way.




http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim3000/java.htm?lang=en


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

Eighteen year old server trumped by functional 486 fleet!

[Ed Gould]

Follow on story about 18 year old server


http://www.theregister.co.uk/2016/01/20/486_fleet_still_in_production/


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

Re: Where's Java!? (SMP/E needs to know.)

[Rob Schramm]

Andrew,

You are being short sighted.  Why would I spend additional time and energy
updating a myriad of JAVA_HOME statements, scripts, JCL when I can simply
standardize the whole thing.  Sure you can always override JAVA_HOME... but
that is the exception.. Not the rule.

Rob Schramm

On Thu, Jan 21, 2016, 12:07 AM Andrew Rowley 
wrote:

> On 21/01/2016 15:00, Jack J. Woehr wrote:
> > Andrew Rowley wrote:
> >> In answer to the original question, having SMP/E use the JAVA_HOME
> >> environment variable would be the clean way.
> >
> http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim3000/java.htm?lang=en
> >
>
> Isn't that javahome from a different location? Not the JAVA_HOME
> environment variable?
>
> Andrew Rowley
>
> --
> 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: Where's Java!? (SMP/E needs to know.)

[Andrew Rowley]

On 21/01/2016 14:14, Rob Schramm wrote:

About the /etc/profile...
Best to set JAVA_HOME to a symlink.  Less work for an upgrade.  The users
can always override such things.. Having a standard symlink(s) that can be
used gives a nice amount of control and consistency.


Except that JAVA_HOME is an environment variable already intended to 
allow you to point to the current version, allow you to override it etc.


JAVA_HOME pointing to a symlink is a double level of indirection. I 
don't see that the work for an upgrade is significantly different 
(update a symlink vs. update a file).


In answer to the original question, having SMP/E use the JAVA_HOME 
environment variable would be the clean way. It would be nice if there 
was somewhere you could set environment variables usable for any dubbed 
process, rather than requiring a shell. /etc/environment maybe?


Andrew Rowley

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

Re: Eighteen year old server trumped by functional 486 fleet!

[Elardus Engelbrecht]

Ed Gould wrote:

>Follow on story about 18 year old server

According to below article, it seemed that 18 year server is just a mere infant 
...

>http://www.theregister.co.uk/2016/01/20/486_fleet_still_in_production/

Hehehe. Thanks Ed. I really enjoyed that follow-up article.

The day will come that you can put a live running, but dusty machine in your 
will... ;-)

Groete / Greetings
Elardus Engelbrecht

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

HMC

[Steve Beaver]

I have come up against a problem I can seem to solve.  I am using HMC
Version 2.13.0.

If I am local to the HMC, everything works as expected.  The same is true
for all functions
EXCEPT for Single Object Operations when I am coming thru a Browser.

I select SOO and select the "Target Object", then Confirm the Object and
then Click Yes
Then the HMC freezes at attempting to access port 9950.

All the ports as open as listeners 

This one has every one befuddled


Steve

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

Re: STP Question

[Mark Jacobs - Listserv]

Our LPARs are being hosted on a single CEC which also might include 
other client LPARs. All I'm seeing in operlog is that the STP timing 
network for this CEC doesn't have backup or arbiter servers assigned.


Mark Jacobs

Vernooij, CP (ITOPT1) - KLM wrote:

Do you really get a stand-alone CEC or are your LPARs placed on one of the 
outsourcers machines?
If so, they will probably have STP and provide a reliable time.
And of course Gil is right: if not, you can configure STP to a timeserver to 
keep your time accurate.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: 20 January, 2016 13:15
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STP Question

It's being configured that way by our outsourcer, we no longer have
control over the configuration. I agree with you, but wanted to see if
there's any additional risk to our environment in this configuration.

Mark Jacobs

Vernooij, CP (ITOPT1) - KLM wrote:

The main reason of STP is to coordinate time between the CECs. When you have 
only one, there is nothing to coordinate anymore.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: 19 January, 2016 21:06
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: STP Question

We're moving from a three CEC configuration, with all STP rolls,
Primary/Backup/Arbiter defined, to a singe CEC that's defined as the
Primary, with no backup or arbiter defined to the STP network. I'm not
seeing any additional risks, since we're already running in "all our
eggs in one basket mode", but wanted to ask the hive mind for your input.
--
Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past, is the standard you accept.
Lieutenant General David Morrison

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

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


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



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

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

Re: STP Question

[Mark Jacobs - Listserv]

Yea, that was my thought too. Just wanted to ask around. Thanks.

Mark Jacobs

R.S. wrote:

W dniu 2016-01-20 o 15:52, Mark Jacobs - Listserv pisze:

Our LPARs are being hosted on a single CEC which also might include
other client LPARs. All I'm seeing in operlog is that the STP timing
network for this CEC doesn't have backup or arbiter servers assigned.


Well, it is single CEC, so you don't have spare STP servers. Actually
you don't need them, since STP failure in single CEC scenario means this
CEC failure.
BTW: the (not so) obvious advantage of STP on single CEC is ability to
use time signal from NTP. You cannot connect z/OS as ntp client, but the
CEC with STP can be ntp client.

--
Radoslaw Skorupka
Lodz, Poland






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


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


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



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


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




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

Dennis Malarky

[Ed Gould]

Sorry to relate the bad news of Dennis Malarky

I am sorry to pass on this sad news.  Dennis was diagnosed with  
cancer in November and didn't have a chance to have chemo, he entered  
hospice on 12/8 and died on 12/12 at 12:30 am.  He was interred in  
the Riverside National Cemetery on 12/28/15.  Hard to lose him after  
53 years.


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

Re: JES3 to JES2 Migration (was JES2 to JES3 Migration)

[Jackson, Robin W. Contractor]

I do not, but wish that I did.  I am in a JES3 environment right now and have 
been in JES2 environments my entire 30+ year career.  I will be closely 
monitoring this thread.  I have been reviewing a Redbook that deals with just 
this issue.  I have not gotten very far into it yet.

Thanks,

Rob Jackson
robin.w.jack...@ssa.gov
rwjackso...@msn.com
Office: 1-877-897-0598 ext. 10462
Cell: (615) 689-1435


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cheryl Watson
Sent: Thursday, January 14, 2016 9:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES3 to JES2 Migration (was JES2 to JES3 Migration)

Yes, Lizette - I meant to say JES3 to JES2.  Thanks!

Has anyone who has done this have an estimate of the amount of time it might 
take, and the effort?

Cheryl

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, January 14, 2016 9:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 to JES3 Migration

Cheryl,

I am guessing you meant the subject to say JES3 to JES2 migration???

The one challenge I see is the JCL is different between the two environments.  
JES2 use /* (eg. /*ROUTE) and JES3 uses //* (eg //*MAIN)   

JES2 has no master JES system, JES3 has a Master.  So in JES2 jobs can either 
run where the JCL is converted or anywhere in the JESMAS.


There is also the concept in JES3 that until all resources available, the job 
will not run.  JES2 it can run and wind up waiting on resources.

Those are about the differences I can think of off the top of my head.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Cheryl Watson
> Sent: Thursday, January 14, 2016 7:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JES2 to JES3 Migration
> 
> A customer asked us for suggestions for performing a JES3 to JES2 migration.
> Are there products that will help in this, or do you know any 
> companies who perform this migration?  You can reply off-list if you prefer.
> 
> Thanks so much,
> Cheryl
> cheryl at watsonwalker.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

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

Re: HMC

[Tony Thigpen]

You can see this if you are coming though a NAT based router. You would 
have to set up special port forwarding rules on the router.


Tony Thigpen

Steve Beaver wrote on 01/20/2016 09:50 AM:

I have come up against a problem I can seem to solve.  I am using HMC
Version 2.13.0.

If I am local to the HMC, everything works as expected.  The same is true
for all functions
EXCEPT for Single Object Operations when I am coming thru a Browser.

I select SOO and select the "Target Object", then Confirm the Object and
then Click Yes
Then the HMC freezes at attempting to access port 9950.

All the ports as open as listeners

This one has every one befuddled


Steve

--
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: STP Question

[R.S.]

W dniu 2016-01-20 o 15:52, Mark Jacobs - Listserv pisze:
Our LPARs are being hosted on a single CEC which also might include 
other client LPARs. All I'm seeing in operlog is that the STP timing 
network for this CEC doesn't have backup or arbiter servers assigned.


Well, it is single CEC, so you don't have spare STP servers. Actually 
you don't need them, since STP failure in single CEC scenario means this 
CEC failure.
BTW: the (not so) obvious advantage of STP on single CEC is ability to 
use time signal from NTP. You cannot connect z/OS as ntp client, but the 
CEC with STP can be ntp client.


--
Radoslaw Skorupka
Lodz, Poland






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

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

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


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

Re: JES3 to JES2 Migration (was JES2 to JES3 Migration)

[Cheryl Watson]

Can you use this as justification to get to the two Nationwide sessions planned 
at SHARE in San Antonio?

Cheryl

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jackson, Robin W. Contractor
Sent: Wednesday, January 20, 2016 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES3 to JES2 Migration (was JES2 to JES3 Migration)

I do not, but wish that I did.  I am in a JES3 environment right now and have 
been in JES2 environments my entire 30+ year career.  I will be closely 
monitoring this thread.  I have been reviewing a Redbook that deals with just 
this issue.  I have not gotten very far into it yet.

Thanks,

Rob Jackson
robin.w.jack...@ssa.gov
rwjackso...@msn.com
Office: 1-877-897-0598 ext. 10462
Cell: (615) 689-1435


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cheryl Watson
Sent: Thursday, January 14, 2016 9:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES3 to JES2 Migration (was JES2 to JES3 Migration)

Yes, Lizette - I meant to say JES3 to JES2.  Thanks!

Has anyone who has done this have an estimate of the amount of time it might 
take, and the effort?

Cheryl

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, January 14, 2016 9:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 to JES3 Migration

Cheryl,

I am guessing you meant the subject to say JES3 to JES2 migration???

The one challenge I see is the JCL is different between the two environments.  
JES2 use /* (eg. /*ROUTE) and JES3 uses //* (eg //*MAIN)   

JES2 has no master JES system, JES3 has a Master.  So in JES2 jobs can either 
run where the JCL is converted or anywhere in the JESMAS.


There is also the concept in JES3 that until all resources available, the job 
will not run.  JES2 it can run and wind up waiting on resources.

Those are about the differences I can think of off the top of my head.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Cheryl Watson
> Sent: Thursday, January 14, 2016 7:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JES2 to JES3 Migration
> 
> A customer asked us for suggestions for performing a JES3 to JES2 migration.
> Are there products that will help in this, or do you know any 
> companies who perform this migration?  You can reply off-list if you prefer.
> 
> Thanks so much,
> Cheryl
> cheryl at watsonwalker.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

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

[R.S.]

Things to check:
1. java
2. certificates

Ad 1. The easiest method is to use HMC with downlevel java version. 
Other means: Control Panel - Java - Security at High level (actually the 
lowest possible), also fill Exception Site List with https://ip.add.re.ss


Ad 2. You have to allow self-signed certificates to be acceptable and 
accept this site. Or you can issue certiticates for HMC and SE using 
your own CA.



HTH

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2016-01-20 o 15:50, Steve Beaver pisze:

I have come up against a problem I can seem to solve.  I am using HMC
Version 2.13.0.

If I am local to the HMC, everything works as expected.  The same is true
for all functions
EXCEPT for Single Object Operations when I am coming thru a Browser.

I select SOO and select the "Target Object", then Confirm the Object and
then Click Yes
Then the HMC freezes at attempting to access port 9950.

All the ports as open as listeners

This one has every one befuddled


Steve

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





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

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

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


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

Re: Dennis Malarky

[Mike Schwab]

http://www.findagrave.com/cgi-bin/fg.cgi?page=gr=156689949


On Wed, Jan 20, 2016 at 12:50 PM, Ed Gould  wrote:
> Sorry to relate the bad news of Dennis Malarky
>
> I am sorry to pass on this sad news.  Dennis was diagnosed with cancer in
> November and didn't have a chance to have chemo, he entered hospice on 12/8
> and died on 12/12 at 12:30 am.  He was interred in the Riverside National
> Cemetery on 12/28/15.  Hard to lose him after 53 years.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Why doesn't "="option work in SMP/E panels?

[John Mattson]

I have noticed that it also depends upon HOW you got to various ISPF
panels.  For example IN most cases when you enter 3.4 from the primary
panel enter END, you go back to where you were before 3.4   On the other
hand if you enter 3;4 from the primary panel (assuming ";" is your command
separator) and enter END, you go back to option 3.   This seems to be
modified by panels with PRIM, but seems generally true (note, this is
annecdotal, no claims of real science here).

What I really hate is products like BMC Control-M which have their own
home grown panel system which "looks" like ISPF, but do not follow all of
the rules, like requiring "X" to exit and ignoring PF3 set to END.

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

z/OS 2.2 3270 OMVS ssh masks passwords!

[Paul Gilmartin]

Really!  At last!

Many years ago I submitted an SR; Security; against tcsetattr() where
I suspected the problem lay.  (Before Ported Tools; I found breakage
with my own code.)  IBM whitewashed the problem in "stty -echo"
but left tcsetattr() broken.  I suppose their attitude was, "Don't do
that!"  I need to test whether tcsetattr() now works or whether there's
more whitewash in SSL.

-- gil

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

Re: z/OS 2.2 3270 OMVS ssh masks passwords!

[Kirk Wolf]

Hi Gil,

I'm not sure I understand exactly what you are referring to?

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, Jan 20, 2016 at 5:14 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> Really!  At last!
>
> Many years ago I submitted an SR; Security; against tcsetattr() where
> I suspected the problem lay.  (Before Ported Tools; I found breakage
> with my own code.)  IBM whitewashed the problem in "stty -echo"
> but left tcsetattr() broken.  I suppose their attitude was, "Don't do
> that!"  I need to test whether tcsetattr() now works or whether there's
> more whitewash in SSL.
>
> -- 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: Where's Java!? (SMP/E needs to know.)

[Rob Schramm]

I vote symlink as well.

Rob Schramm

On Wed, Jan 20, 2016, 4:45 PM John McKown 
wrote:

> I like the SYMLINK idea. I do that myself, "by hand".
>
> On Wed, Jan 20, 2016 at 3:34 PM, Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Dammit!  The path to Java changes with any z/OS release and/or
> > any Java release.  I need continually to add to my PATH variable
> > to keep up.  And there's nothing an ISV can supply in JCL samples
> > for SMP/E's SMPJHOME; the example in the SMP/E Reference is
> > woefully outdated.
> >
> > This makes as little sense as if programmers were required to
> > code "//SYSLIB  DD  DSN=SYS1.ZOSV2R2.MACLIB".
> >
> > I'm inclined to submit an RFE for either a utility to find Java or for
> > IBM's supplying a usable symbolic  link to a preferred Java.
> > Retroactive; I can't wait for everyone to be on z/OS 2.3
> >
> > Any suggestions on form or rationale for such an RFE?
> >
> > Thanks,
> > gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> Werner Heisenberg is driving down the autobahn. A police officer pulls
> him over. The officer says, "Excuse me, sir, do you know how fast you
> were going?"
> "No," replies Dr. Heisenberg, "but I know where I am."
>
> Computer Science is the only discipline in which we view adding a new wing
> to a building as being maintenance -- Jim Horning
>
> Schrodinger's backup: The condition of any backup is unknown until a
> restore is attempted.
>
> He's about as useful as a wax frying pan.
>
> 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: Where's Java!? (SMP/E needs to know.)

[Farley, Peter x23353]

Doesn't z/OS Unix have the equivalent of /etc/profile?  And doesn't Java 
installation create an entry or invoked script in /etc/profile to set the 
JAVAHOME environment variable as every other *ix system does?  Shouldn't that 
be the preferred method for compatibility with every other *ix Java environment?

Just asking  . . .

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, January 20, 2016 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Where's Java!? (SMP/E needs to know.)

Dammit!  The path to Java changes with any z/OS release and/or
any Java release.  I need continually to add to my PATH variable
to keep up.  And there's nothing an ISV can supply in JCL samples
for SMP/E's SMPJHOME; the example in the SMP/E Reference is
woefully outdated.

This makes as little sense as if programmers were required to
code "//SYSLIB  DD  DSN=SYS1.ZOSV2R2.MACLIB".

I'm inclined to submit an RFE for either a utility to find Java or for
IBM's supplying a usable symbolic  link to a preferred Java.
Retroactive; I can't wait for everyone to be on z/OS 2.3

Any suggestions on form or rationale for such an RFE?

Thanks,
gil

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

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Where's Java!? (SMP/E needs to know.)

[Paul Gilmartin]

Dammit!  The path to Java changes with any z/OS release and/or
any Java release.  I need continually to add to my PATH variable
to keep up.  And there's nothing an ISV can supply in JCL samples
for SMP/E's SMPJHOME; the example in the SMP/E Reference is
woefully outdated.

This makes as little sense as if programmers were required to
code "//SYSLIB  DD  DSN=SYS1.ZOSV2R2.MACLIB".

I'm inclined to submit an RFE for either a utility to find Java or for
IBM's supplying a usable symbolic  link to a preferred Java.
Retroactive; I can't wait for everyone to be on z/OS 2.3

Any suggestions on form or rationale for such an RFE?

Thanks,
gil

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

Re: Where's Java!? (SMP/E needs to know.)

[John McKown]

I like the SYMLINK idea. I do that myself, "by hand".

On Wed, Jan 20, 2016 at 3:34 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> Dammit!  The path to Java changes with any z/OS release and/or
> any Java release.  I need continually to add to my PATH variable
> to keep up.  And there's nothing an ISV can supply in JCL samples
> for SMP/E's SMPJHOME; the example in the SMP/E Reference is
> woefully outdated.
>
> This makes as little sense as if programmers were required to
> code "//SYSLIB  DD  DSN=SYS1.ZOSV2R2.MACLIB".
>
> I'm inclined to submit an RFE for either a utility to find Java or for
> IBM's supplying a usable symbolic  link to a preferred Java.
> Retroactive; I can't wait for everyone to be on z/OS 2.3
>
> Any suggestions on form or rationale for such an RFE?
>
> Thanks,
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Werner Heisenberg is driving down the autobahn. A police officer pulls
him over. The officer says, "Excuse me, sir, do you know how fast you
were going?"
"No," replies Dr. Heisenberg, "but I know where I am."

Computer Science is the only discipline in which we view adding a new wing
to a building as being maintenance -- Jim Horning

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

He's about as useful as a wax frying pan.

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: Where's Java!? (SMP/E needs to know.)

[Paul Gilmartin]

On 2016-01-20 15:28, Farley, Peter x23353 wrote:
> Doesn't z/OS Unix have the equivalent of /etc/profile? 
>
It has.

> And doesn't Java installation create an entry or invoked script in 
> /etc/profile
>to set the JAVAHOME environment variable
>
it doesn't

> as every other *ix system does?
>
I don't see that in a couple other *ix systems.  But those keep java ,or
at least a symlink in a stable path.  Presumably updating java updates
the symlink.

> Shouldn't that be the preferred method for compatibility with every other *ix 
> Java environment?
> 
IBM has a strict policy of not updating anything in /etc lest they
override a user mod.

> Just asking  . . .
> 
More:

user@OS/390.25.00: grep java /etc/* 2>/dev/null
/etc/csh.cshrc:set path = ( /bin /usr/lpp/java/J6.0.1/bin /usr/bin /usr/sbin .)
/etc/profile:PATH=/bin:/usr/lpp/java/J6.0.1/bin:/usr/lpp/sasc/bin:/usr/bin:/usr/sbin:.

user@OS/390.25.00: ls -ald /usr/lpp/java/*
drwxr-xr-x  11 OMVSKERN OMVS8192 Jul  8  2015 /usr/lpp/java/J6.0.1_64
drwxr-xr-x  11 OMVSKERN OMVS8192 Jul  8  2015 /usr/lpp/java/J6.0_64
drwxr-xr-x  12 OMVSKERN OMVS8192 Jul  8  2015 /usr/lpp/java/J7.1_64
drwxr-xr-x  12 OMVSKERN OMVS8192 Jul 16  2015 /usr/lpp/java/J8.0_64
user@OS/390.25.00:

... no match for z/OS 2.2.

user@OS/390.25.00: ls -al /etc/csh.cshrc /etc/profile
-rw-r--r--   1 OMVSKERN OMVS2208 Apr 22  2013 /etc/csh.cshrc
-rwxr-xr-x   1 OMVSKERN OMVS   10315 Apr 19  2013 /etc/profile
user@OS/390.25.00:
... of course.

So, I might try:
user@OS/390.25.00: cat `whence findjava`
/* Rexx */ signal on novalue;  /*
   Find newest Java library:
*/
trace R

JavaCmd = 'set -x; ls -1dt /usr/lpp/java/J*/bin |' ,
'   sed -n ''1 s/\/bin$//p'''
RC = BPXWUNIX( JavaCmd, , 'OUT.' )

say value( 'OUT.1' )


user@OS/390.25.00: findjava
 6 *-* JavaCmd = 'set -x; ls -1dt /usr/lpp/java/J*/bin |' ,'?sed -n ''1 
s/\/bin$//p'''
   >>>   "set -x; ls -1dt /usr/lpp/java/J*/bin | ?sed -n '1 s/\/bin$//p'"
 8 *-* RC = BPXWUNIX( JavaCmd, , 'OUT.' )
sh:0+ ls -1dt /usr/lpp/java/J6.0.1_64/bin /usr/lpp/java/J6.0_64/bin 
/usr/lpp/java/J7.1_64/bin /usr/lpp/java/J8.0_64/bin
sh:0+ sed -n 1 s/\/bin$//p
   >>>   "0"
10 *-* say value( 'OUT.1' )
   >>>   "/usr/lpp/java/J8.0_64"
/usr/lpp/java/J8.0_64
user@OS/390.25.00:

Grrr...,
gil

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

Re: Compile error

[R.S.]

W dniu 2016-01-20 o 03:11, Dale R. Smith pisze:

On Tue, 19 Jan 2016 12:33:44 -0800, Charles Mills  wrote:


"(c) International Business Machines Corporation 1974, 1976, 1981"

35 to 42 years old!

Charles

The last supported release of the OS/VS COBOL Compiler and Library was V1.2.4.  
It was withdrawn from marketing in June 1992 and withdrawn from support in June 
1994, so not quite that old!  EOS does not mean it doesn't still work and can 
create code that can still execute on a modern mainframe.  (Of course the 
source must not contain anything that OS/VS COBOL doesn't support!)  Not sure 
if it's still shipping as part of z/OS or if it was just left around on the 
OP's system.  We still have OS/VS COBOL programs that are running on VM/CMS, 
(none on z/OS).
Well, it has been unable to be ordered for almost 24 years (and replaced 
by some newer version even earlier).

24 years in IT. If it's not old, then what actually is old?

--
Radoslaw Skorupka
Lodz, Poland






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

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

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


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

Re: STP Question

[Mark Jacobs - Listserv]

It's being configured that way by our outsourcer, we no longer have 
control over the configuration. I agree with you, but wanted to see if 
there's any additional risk to our environment in this configuration.


Mark Jacobs

Vernooij, CP (ITOPT1) - KLM wrote:

The main reason of STP is to coordinate time between the CECs. When you have 
only one, there is nothing to coordinate anymore.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: 19 January, 2016 21:06
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: STP Question

We're moving from a three CEC configuration, with all STP rolls,
Primary/Backup/Arbiter defined, to a singe CEC that's defined as the
Primary, with no backup or arbiter defined to the STP network. I'm not
seeing any additional risks, since we're already running in "all our
eggs in one basket mode", but wanted to ask the hive mind for your input.
--
Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past, is the standard you accept.
Lieutenant General David Morrison

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

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


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



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

Re: STP Question

[Vernooij, CP (ITOPT1) - KLM]

Do you really get a stand-alone CEC or are your LPARs placed on one of the 
outsourcers machines? 
If so, they will probably have STP and provide a reliable time. 
And of course Gil is right: if not, you can configure STP to a timeserver to 
keep your time accurate.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: 20 January, 2016 13:15
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STP Question

It's being configured that way by our outsourcer, we no longer have 
control over the configuration. I agree with you, but wanted to see if 
there's any additional risk to our environment in this configuration.

Mark Jacobs

Vernooij, CP (ITOPT1) - KLM wrote:
> The main reason of STP is to coordinate time between the CECs. When you have 
> only one, there is nothing to coordinate anymore.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Mark Jacobs - Listserv
> Sent: 19 January, 2016 21:06
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: STP Question
>
> We're moving from a three CEC configuration, with all STP rolls,
> Primary/Backup/Arbiter defined, to a singe CEC that's defined as the
> Primary, with no backup or arbiter defined to the STP network. I'm not
> seeing any additional risks, since we're already running in "all our
> eggs in one basket mode", but wanted to ask the hive mind for your input.
> --
> Mark Jacobs
> Time Customer Service
> Technology and Product Engineering
>
> The standard you walk past, is the standard you accept.
> Lieutenant General David Morrison
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 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
>
>
> Please be alert for any emails that may ask you for login information or 
> directs you to login via a link. If you believe this message is a phish or 
> aren't sure whether this message is trustworthy, please send the original 
> message as an attachment to 'phish...@timeinc.com'.
>

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

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 

Re: STP Question

[Paul Gilmartin]

On Wed, 20 Jan 2016 07:08:18 +, Vernooij, CP (ITOPT1) - KLM wrote:

>The main reason of STP is to coordinate time between the CECs. When you have 
>only one, there is nothing to coordinate anymore.
> 
Some reference is necessary to steer the TOD clock in order to prevent
secular drift.  What are the alternatives to STP?  I suppose one might
rely on the operator's wristwatch and ad-hoc corrections entered at the
HMC.  But doesn't that in turn rely on STP?

-- gil

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