Re: SUBSYS= ?

[Elardus Engelbrecht]

Ed Jaffe wrote:

>On 11/6/2017 8:49 AM, Jesse 1 Robinson wrote:
>> Did IBM announce long ago that SUBSYS was being deprecated?

>Absolutely not!

100% correct. Indeed, there is nothing in big blue's SOD.  (Statement Of 
Direction)

If big blue has any plans to drop DD SUBSYS, then they would make plans with 
System Logger for things like LOGREC which is unlikely because need for 
backward compatibility.

Then jobs like this had to be changed to drop SUBSYS...

//EREPDALD EXEC PGM=IFCEREP1,PARM='CARD'  
//ACCINDD DSN=???, 
//SUBSYS=(LOGR,IFBSEXIT,,'LASTRUN'),  
//DCB=(???) 

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

Has anyone gotten some interesting (surprising?) numbers out of SMF type 31?

[Edward Gould]

I was reading IBM system Mag at 
http://ibmsystemsmag.com/mainframe/hot-topics/crypto-statistics-monitor/?utm_source=SilverpopMailing_medium=email_campaign=110717-a_IMFEXTRA%20(1)%20Live%20Send_content=Article%20Title%202=12299030=MTMzMzgyMTE0MjcxS0=1280551000=MTI4MDU1MTAwMAS2
 


(watch the wrap)

I thought was a nice intro cryptography reporting. There was a new FMID (at 
least to me) ICSF FMID HCR77C1.

Dose MXG or SAS have interesting reporting?

Has anyone got some numbers they would like to share? If not raw numbers then 
maybe a sentence or three talking about the numbers?

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

Re: PCOMM macro/script - Copy Screens, Copy Append

[Hank Oerlemans]

Our Team has used OpenRexx with the PCOMM HLLAPI for years for this sort of 
thing.

E,g. hrc = HLLAPI('Sendkey',ARG(1) ) 

To send a command to the current 3270 window.

Cheers Hank

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richard Zierdt
Sent: 04 November 2017 08:35
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PCOMM macro/script - Copy Screens, Copy Append

Using PCOMM Ver 6.0.  

The goal is to copy several CICS screens as a script (or macro) runs.  24x80 
green-screen stuff.  

First step is to create or record the macro or script. 
The problem is that PCOMM's  Edit-Copy  and  Edit-Append  are not supported 
under PCOMM's Start Recording, either as a macro or VBScript. 
Start Recording will record keystrokes, but not Edit-Copy, etc.  
[Edit-Copy (and Append) copies the text of a screen to the Windows clipboard.] 

The VBScript can be edited.  Are there VBScript statements that will copy 
screens (text) as they are presented? 
I'm studying VBScript syntax now (WshShell - SendKeys might work), but if the 
wheel's already been invented . . . 

Any help appreciated. 

Thanks -
Richard Zierdt  

--
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: What happened to IEBCPARM?

[Tony Harminc]

On 7 November 2017 at 15:00, John Eells  wrote:

> DFSMS Development will add this back in.  Basically, it got missed in APAR
> rollup for 2.2 by accident.  They plan to put it back via PTFs to 2.2 and
> 2.3.


Thanks for the investigation, John. So no dastardly plot to deprive us of
the macro. Just a glitch.

Tony H.

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

Re: C/C++ Runtime Library

[Paul Gilmartin]

On Tue, 7 Nov 2017 22:07:57 +, Frank Swarbrick wrote:

>Doesn't that make for fairly large executables?
>
That runtime is not monolithic, merely inconveniently megalithic.
Infuriatingly so to a vendor who has chosen to structure its own
product in numerous executables.  I believe Dignus acceded to
one customer's request for finer granularity in that runtime.

>From:  Thomas David Rivers 
>Sent: Monday, November 6, 2017 4:58 AM
>>
>Let me also speak as a vendor; for Dignus C/C++ (in he default mode of 
>operation)
>the runtime is linked with the program.  There is no dependency on an 
>externally
>loaded component - or LE.   So, you don't have to worry about version 
>compatibility.

-- gil

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

Re: Are JZOS JVM loader excutables installed in PDSE libraries?

[Paul Gilmartin]

On Tue, 7 Nov 2017 21:00:41 +, Farley, Peter x23353 wrote:
>
>As Gil has pointed out several times, you cannot *legally* use a Unix 
>directory in a STEPLIB  DD or concatenation (well, anyway it is not documented 
>that you can).  And in fact although this may occasionally work with an empty 
>PDS(E) as the first catenand, ...
>
I believe I was whining about SYSEXEC, not STEPLIB.  I've never tried the 
latter.

> my experience of trying this with the JZOS loader executables is that it 
> generates an S922 abend (fatal error in initiator, SVC dump taken).
> 
And Binder very explicitly prohibits catenation of UNIX directories
in SYSLIB; they must be singletons.  The Ref. pretty much states
that Binder performs no search of a UNIX SYSLIB, rather it extracts
the SYSLIB path (SVC 99?) and appends the member name.  (The
Ref. neglects to mention an intervening '/'.)

Three grists for the RFE mill:
o UNIX directories in SYSEXEC.
o UNIX directories in STEPLIB.  (How about //PDSE in PATH!?)
o Concatenated UNIX directories in Binder SYSLIB.

-- gil

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

Re: C/C++ Runtime Library

[Frank Swarbrick]

Doesn't that make for fairly large executables?

From: IBM Mainframe Discussion List  on behalf of 
Thomas David Rivers 
Sent: Monday, November 6, 2017 4:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C/C++ Runtime Library

Ze'ev Atlas wrote:

>I hope that I word my question correctlyIs the C/C++ Runtime Library installed 
>by default on z/OS  or is it a product that needs to be licensed separately?In 
>other words, if I distribute a software product, written in C, in binary form 
>(load modules) and that product rely on the runtime library, what is the 
>likelihood that the client's installations out there would not be able to run 
>the product because the runtime library is not present?
>Ze'ev Atlas
>
>
>
Let me also speak as a vendor; for Dignus C/C++ (in he default mode of
operation)
the runtime is linked with the program.  There is no dependency on an
externally
loaded component - or LE.   So, you don't have to worry about version
compatibility.

  - Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.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: Are JZOS JVM loader excutables installed in PDSE libraries?

[Farley, Peter x23353]

Yes, Mark also pointed this out.  Thanks for the quick response.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, November 07, 2017 4:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Are JZOS JVM loader excutables installed in PDSE libraries?

I believe the JAVA install will place the JZOS modules in SYS*.SIEALNKE

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Tuesday, November 7, 2017 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Are JZOS JVM loader excutables installed in PDSE libraries?

This is a JZOS installation and documentation question.  At our installation 
(z/OS V2.1), versions of the JZOS loader executables (JVMLDMxx) live in these 
Unix directories:

/usr/lpp/java/Jx.y/mvstools

/usr/lpp/java/Jx.y_64/mvstools

Where "x.y" is the Java version, like 6.0 or 7.0, etc.

As Gil has pointed out several times, you cannot *legally* use a Unix directory 
in a STEPLIB  DD or concatenation (well, anyway it is not documented that you 
can).  And in fact although this may occasionally work with an empty PDS(E) as 
the first catenand, my experience of trying this with the JZOS loader 
executables is that it generates an S922 abend (fatal error in initiator, SVC 
dump taken).

So my installation question is this:  Does the normal installation of the JZOS 
component also include automatic copying of the JVMLDMxx executable(s) into 
some system-maintained PDSE(s)?

If not, where is it documented how to copy these executable(s) into a PDSE 
library which can legally be used as a STEPLIB, and that it is the user's 
responsibility to do this in order to use JZOS?

I have figured out with help from the MVS-OE list (or maybe I had help here, 
ATM I do not remember) that "/bin/cp -X" is the "right" way to copy those 
executables into a PDSE, but I would like to see the actual documentation, if 
any, which references that (or some other) method as a user responsibility.

TIA for any info or RTFM you can provide.

Peter
--

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

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

Re: Are JZOS JVM loader excutables installed in PDSE libraries?

[Farley, Peter x23353]

Thanks Mark, that makes sense.  I will refer this to our systems staff.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Tuesday, November 07, 2017 4:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Are JZOS JVM loader excutables installed in PDSE libraries?

If they're installed with SMP/e, they should be placed in the dataset 
pointed to by DDDEF SIEALNKE


   Entry Type:  PROGRAM
   Entry Name:  JVMLDM60


FMID  HJVA600
RMID  UI14482
DISTLIB   AIEALNKE
SYSLIBSIEALNKE
    

Talk with your systems staff. They might help you find them.

Mark Jacobs
> Farley, Peter x23353 
> November 7, 2017 at 4:19 PM
> Yes those are the ones, but they are not present in that library on 
> our systems. Maybe your kind and generous systems staff made those 
> copies for you? Mine apparently did not.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Mark Jacobs - Listserv
> Sent: Tuesday, November 07, 2017 4:10 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Are JZOS JVM loader excutables installed in PDSE libraries?
>
> Are you talking about these?
>
> BROWSE SYS1.SIEALNKE
> Command ===>
> Name Prompt
> _ JVMLDM60
> _ JVMLDM61
> _ JVMLDM66
> _ JVMLDM67
> _ JVMLDM70
> _ JVMLDM71
> _ JVMLDM76
> _ JVMLDM77
> _ JVMLDM80
> _ JVMLDM86
>
> --
>
> 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
>
>
>
> 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 - Listserv 
> November 7, 2017 at 4:10 PM
> Are you talking about these?
>
> BROWSESYS1.SIEALNKE
> Command ===>
>Name Prompt
> _ JVMLDM60
> _ JVMLDM61
> _ JVMLDM66
> _ JVMLDM67
> _ JVMLDM70
> _ JVMLDM71
> _ JVMLDM76
> _ JVMLDM77
> _ JVMLDM80
> _ JVMLDM86
>
>
> Farley, Peter x23353 
> November 7, 2017 at 4:00 PM
> This is a JZOS installation and documentation question. At our 
> installation (z/OS V2.1), versions of the JZOS loader executables 
> (JVMLDMxx) live in these Unix directories:
>
> /usr/lpp/java/Jx.y/mvstools
>
> /usr/lpp/java/Jx.y_64/mvstools
>
> Where "x.y" is the Java version, like 6.0 or 7.0, etc.
>
> As Gil has pointed out several times, you cannot *legally* use a Unix 
> directory in a STEPLIB DD or concatenation (well, anyway it is not 
> documented that you can). And in fact although this may occasionally 
> work with an empty PDS(E) as the first catenand, my experience of 
> trying this with the JZOS loader executables is that it generates an 
> S922 abend (fatal error in initiator, SVC dump taken).
>
> So my installation question is this: Does the normal installation of 
> the JZOS component also include automatic copying of the JVMLDMxx 
> executable(s) into some system-maintained PDSE(s)?
>
> If not, where is it documented how to copy these executable(s) into a 
> PDSE library which can legally be used as a STEPLIB, and that it is 
> the user's responsibility to do this in order to use JZOS?
>
> I have figured out with help from the MVS-OE list (or maybe I had help 
> here, ATM I do not remember) that "/bin/cp -X" is the "right" way to 
> copy those executables into a PDSE, but I would like to see the actual 
> documentation, if any, which references that (or some other) method as 
> a user responsibility.
>
> TIA for any info or RTFM you can provide.
>
> Peter
--

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 

Re: Are JZOS JVM loader excutables installed in PDSE libraries?

[Allan Staller]

I believe the JAVA install will place the JZOS modules in SYS*.SIEALNKE

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Tuesday, November 7, 2017 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Are JZOS JVM loader excutables installed in PDSE libraries?

This is a JZOS installation and documentation question.  At our installation 
(z/OS V2.1), versions of the JZOS loader executables (JVMLDMxx) live in these 
Unix directories:

/usr/lpp/java/Jx.y/mvstools

/usr/lpp/java/Jx.y_64/mvstools

Where "x.y" is the Java version, like 6.0 or 7.0, etc.

As Gil has pointed out several times, you cannot *legally* use a Unix directory 
in a STEPLIB  DD or concatenation (well, anyway it is not documented that you 
can).  And in fact although this may occasionally work with an empty PDS(E) as 
the first catenand, my experience of trying this with the JZOS loader 
executables is that it generates an S922 abend (fatal error in initiator, SVC 
dump taken).

So my installation question is this:  Does the normal installation of the JZOS 
component also include automatic copying of the JVMLDMxx executable(s) into 
some system-maintained PDSE(s)?

If not, where is it documented how to copy these executable(s) into a PDSE 
library which can legally be used as a STEPLIB, and that it is the user's 
responsibility to do this in order to use JZOS?

I have figured out with help from the MVS-OE list (or maybe I had help here, 
ATM I do not remember) that "/bin/cp -X" is the "right" way to copy those 
executables into a PDSE, but I would like to see the actual documentation, if 
any, which references that (or some other) method as a user responsibility.

TIA for any info or RTFM you can provide.

Peter
--

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


::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: Are JZOS JVM loader excutables installed in PDSE libraries?

[Mark Jacobs - Listserv]

If they're installed with SMP/e, they should be placed in the dataset 
pointed to by DDDEF SIEALNKE



  Entry Type:  PROGRAM
  Entry Name:  JVMLDM60


FMID  HJVA600
RMID  UI14482
DISTLIB   AIEALNKE
SYSLIBSIEALNKE
   

Talk with your systems staff. They might help you find them.

Mark Jacobs

Farley, Peter x23353 
November 7, 2017 at 4:19 PM
Yes those are the ones, but they are not present in that library on 
our systems. Maybe your kind and generous systems staff made those 
copies for you? Mine apparently did not.


Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
On Behalf Of Mark Jacobs - Listserv

Sent: Tuesday, November 07, 2017 4:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Are JZOS JVM loader excutables installed in PDSE libraries?

Are you talking about these?

BROWSE SYS1.SIEALNKE
Command ===>
Name Prompt
_ JVMLDM60
_ JVMLDM61
_ JVMLDM66
_ JVMLDM67
_ JVMLDM70
_ JVMLDM71
_ JVMLDM76
_ JVMLDM77
_ JVMLDM80
_ JVMLDM86

--

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



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 - Listserv 
November 7, 2017 at 4:10 PM
Are you talking about these?

BROWSESYS1.SIEALNKE
Command ===>
   Name Prompt
_ JVMLDM60
_ JVMLDM61
_ JVMLDM66
_ JVMLDM67
_ JVMLDM70
_ JVMLDM71
_ JVMLDM76
_ JVMLDM77
_ JVMLDM80
_ JVMLDM86


Farley, Peter x23353 
November 7, 2017 at 4:00 PM
This is a JZOS installation and documentation question. At our 
installation (z/OS V2.1), versions of the JZOS loader executables 
(JVMLDMxx) live in these Unix directories:


/usr/lpp/java/Jx.y/mvstools

/usr/lpp/java/Jx.y_64/mvstools

Where "x.y" is the Java version, like 6.0 or 7.0, etc.

As Gil has pointed out several times, you cannot *legally* use a Unix 
directory in a STEPLIB DD or concatenation (well, anyway it is not 
documented that you can). And in fact although this may occasionally 
work with an empty PDS(E) as the first catenand, my experience of 
trying this with the JZOS loader executables is that it generates an 
S922 abend (fatal error in initiator, SVC dump taken).


So my installation question is this: Does the normal installation of 
the JZOS component also include automatic copying of the JVMLDMxx 
executable(s) into some system-maintained PDSE(s)?


If not, where is it documented how to copy these executable(s) into a 
PDSE library which can legally be used as a STEPLIB, and that it is 
the user's responsibility to do this in order to use JZOS?


I have figured out with help from the MVS-OE list (or maybe I had help 
here, ATM I do not remember) that "/bin/cp -X" is the "right" way to 
copy those executables into a PDSE, but I would like to see the actual 
documentation, if any, which references that (or some other) method as 
a user responsibility.


TIA for any info or RTFM you can provide.

Peter
--

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



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, 

Re: Are JZOS JVM loader excutables installed in PDSE libraries?

[Farley, Peter x23353]

Yes those are the ones, but they are not present in that library on our 
systems.  Maybe your kind and generous systems staff made those copies for you? 
 Mine apparently did not.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Tuesday, November 07, 2017 4:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Are JZOS JVM loader excutables installed in PDSE libraries?

Are you talking about these?

BROWSESYS1.SIEALNKE
Command ===>
Name Prompt
_ JVMLDM60
_ JVMLDM61
_ JVMLDM66
_ JVMLDM67
_ JVMLDM70
_ JVMLDM71
_ JVMLDM76
_ JVMLDM77
_ JVMLDM80
_ JVMLDM86

> Farley, Peter x23353 
> November 7, 2017 at 4:00 PM
> This is a JZOS installation and documentation question. At our 
> installation (z/OS V2.1), versions of the JZOS loader executables
> (JVMLDMxx) live in these Unix directories:
>
> /usr/lpp/java/Jx.y/mvstools
>
> /usr/lpp/java/Jx.y_64/mvstools
>
> Where "x.y" is the Java version, like 6.0 or 7.0, etc.
>
> As Gil has pointed out several times, you cannot *legally* use a Unix 
> directory in a STEPLIB DD or concatenation (well, anyway it is not 
> documented that you can). And in fact although this may occasionally 
> work with an empty PDS(E) as the first catenand, my experience of 
> trying this with the JZOS loader executables is that it generates an
> S922 abend (fatal error in initiator, SVC dump taken).
>
> So my installation question is this: Does the normal installation of 
> the JZOS component also include automatic copying of the JVMLDMxx
> executable(s) into some system-maintained PDSE(s)?
>
> If not, where is it documented how to copy these executable(s) into a 
> PDSE library which can legally be used as a STEPLIB, and that it is 
> the user's responsibility to do this in order to use JZOS?
>
> I have figured out with help from the MVS-OE list (or maybe I had help 
> here, ATM I do not remember) that "/bin/cp -X" is the "right" way to 
> copy those executables into a PDSE, but I would like to see the actual 
> documentation, if any, which references that (or some other) method as 
> a user responsibility.
>
> TIA for any info or RTFM you can provide.
>
> Peter
--

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

AW: Re: SUBSYS= ?

[Peter Hunkeler]

>... it is the interface that JES2 (and presumably JES3) use to provide DD* and 
>SYSOUT.  Those have an implied SUBSYS=JES2/3 (even though coding it is 
>illegal).


I have not really tried to find out how DD * and SYSOUT work under the covers. 
I was happy to understand OPEN does recognize it and prepares accordingly.


SUBSYS=JESx makes sense.  Duhhh, this just never occurred to me.


--
Peter Hunkeler



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

Re: Are JZOS JVM loader excutables installed in PDSE libraries?

[Mark Jacobs - Listserv]

Are you talking about these?

BROWSESYS1.SIEALNKE
Command ===>
   Name Prompt
_ JVMLDM60
_ JVMLDM61
_ JVMLDM66
_ JVMLDM67
_ JVMLDM70
_ JVMLDM71
_ JVMLDM76
_ JVMLDM77
_ JVMLDM80
_ JVMLDM86


Farley, Peter x23353 
November 7, 2017 at 4:00 PM
This is a JZOS installation and documentation question. At our 
installation (z/OS V2.1), versions of the JZOS loader executables 
(JVMLDMxx) live in these Unix directories:


/usr/lpp/java/Jx.y/mvstools

/usr/lpp/java/Jx.y_64/mvstools

Where "x.y" is the Java version, like 6.0 or 7.0, etc.

As Gil has pointed out several times, you cannot *legally* use a Unix 
directory in a STEPLIB DD or concatenation (well, anyway it is not 
documented that you can). And in fact although this may occasionally 
work with an empty PDS(E) as the first catenand, my experience of 
trying this with the JZOS loader executables is that it generates an 
S922 abend (fatal error in initiator, SVC dump taken).


So my installation question is this: Does the normal installation of 
the JZOS component also include automatic copying of the JVMLDMxx 
executable(s) into some system-maintained PDSE(s)?


If not, where is it documented how to copy these executable(s) into a 
PDSE library which can legally be used as a STEPLIB, and that it is 
the user's responsibility to do this in order to use JZOS?


I have figured out with help from the MVS-OE list (or maybe I had help 
here, ATM I do not remember) that "/bin/cp -X" is the "right" way to 
copy those executables into a PDSE, but I would like to see the actual 
documentation, if any, which references that (or some other) method as 
a user responsibility.


TIA for any info or RTFM you can provide.

Peter
--

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



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




--

Mark Jacobs
Time Customer Service
Global Technology Services

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


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

Are JZOS JVM loader excutables installed in PDSE libraries?

[Farley, Peter x23353]

This is a JZOS installation and documentation question.  At our installation 
(z/OS V2.1), versions of the JZOS loader executables (JVMLDMxx) live in these 
Unix directories:

/usr/lpp/java/Jx.y/mvstools

/usr/lpp/java/Jx.y_64/mvstools

Where "x.y" is the Java version, like 6.0 or 7.0, etc.

As Gil has pointed out several times, you cannot *legally* use a Unix directory 
in a STEPLIB  DD or concatenation (well, anyway it is not documented that you 
can).  And in fact although this may occasionally work with an empty PDS(E) as 
the first catenand, my experience of trying this with the JZOS loader 
executables is that it generates an S922 abend (fatal error in initiator, SVC 
dump taken).

So my installation question is this:  Does the normal installation of the JZOS 
component also include automatic copying of the JVMLDMxx executable(s) into 
some system-maintained PDSE(s)?

If not, where is it documented how to copy these executable(s) into a PDSE 
library which can legally be used as a STEPLIB, and that it is the user's 
responsibility to do this in order to use JZOS?

I have figured out with help from the MVS-OE list (or maybe I had help here, 
ATM I do not remember) that "/bin/cp -X" is the "right" way to copy those 
executables into a PDSE, but I would like to see the actual documentation, if 
any, which references that (or some other) method as a user responsibility.

TIA for any info or RTFM you can provide.

Peter
--

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

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

Re: What happened to IEBCPARM?

[John Eells]

DFSMS Development will add this back in.  Basically, it got missed in 
APAR rollup for 2.2 by accident.  They plan to put it back via PTFs to 
2.2 and 2.3.


John Eells wrote:

I sent a note to DFSMS Development.  I'll let everyone know what happens.

Tony Harminc wrote:

This macro is documented as mapping the argument list and exit parameters
for the various IEB utilities (well, at least IEBCOPY), and that doc is
referenced elsewhere, e.g. by AMATERSE in the Service Aids book. In
particular, it provides the only evident standard mapping for the
order of
DDNAME overrides that are supported by lots of programs and documented
individually with each program.

But the macro itself is gone from SYS1.MACLIB in z/OS 2.2 and 2.3, and I
don't see it anywhere else obvious. I find  a 2013 APAR OA42488 that
added
it to earlier z/OS versions, and IEBCPARM *is* present on a 2.1 system
here, but *poof*!

I have neither the time, need, or interest to re-APAR it, but maybe there
is some more interesting (or not) explanation of where it went.

Tony H.







--
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: Missing C module 'MSGDLL'

[John McKown]

Have you contacted the vendor? If so, did they say anything? What I might
also do is search all the libraries in your STEPLIB and the system LINKLIB
for the character string "MSGDLL". That will narrow down where is is most
likely being referenced and who is responsible.

On Mon, Nov 6, 2017 at 5:28 PM, Tony Thigpen  wrote:

> I am running a vendor supplied program and it is abending with:
>
> CEE3501S THE MODULE MSGDLL WAS NOT FOUND.
>
> The following is some of the logs. (I have masked the vendor program name
> and service.)
>
> CEE3DMP V1 R13.0: CONDITION PROCESSING RESULTED IN THE
> UNHANDLED CONDITION
>
> TRACEBACK:
>   DSA   ENTRYLOAD MOD PROGRAM UNIT SERVICE  STATUS
>   1 CEEHDSP  CEEPLPKA CEEHDSP  UK80866  CALL
>   2 CEEHSGLT CEEPLPKA CEEHSGLT HLE7780  EXCEPTION
>   3 CEEPTLOR CEEPLPKA CEEPTLOR HLE7780  CALL
>   4 @@TRGLOC CEEEV003   CALL
>   5 INITIALIZE   *masked*  ***  CALL
>   6 MAIN *masked*  ***  CALL
>   7 EDCZMINV CEEEV003   CALL
>   8 CEEBBEXT CEEPLPKA CEEBBEXT HLE7780  CALL
>
>   DSA   DSA ADDR  COMP DATE  COMPILE ATTRIBUTES
>   1 15430860  20120806   CEL   POSIX
>   2 1542FCD0  20110318   CEL   POSIX
>   3 1542F920  20110318   CEL   POSIX
>   4 1542F848  03/18/11   LIBRARYPOSIX
>   5 1542F648  20080221   C/C++ POSIX EBCDIC  HFP
>   6 1542F230  20080221   C/C++ POSIX EBCDIC  HFP
>   7 1542F118  20110318   LIBRARYPOSIX
>   8 1542F018  20110318   CEL   POSIX
>
> I am thinking I am missing a STEPLIB, but I can't seem to find 'MSGDLL'
> anywhere.
>
> Thoughts?
>
> --
> Tony Thigpen
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

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: SUBSYS= ?

[Steve Smith]

The SUBSYS= keyword is conceivably something could be done away with,
although I'd (also) consider that highly unlikely.  But the underlying
support is *certainly* not; it is the interface that JES2 (and
presumably JES3) use to provide DD* and SYSOUT.  Those have an implied
SUBSYS=JES2/3 (even though coding it is illegal).

sas

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

Re: SUBSYS= ?

[Ed Jaffe]

On 11/6/2017 8:49 AM, Jesse 1 Robinson wrote:

Did IBM announce long ago that SUBSYS was being deprecated?


Absolutely not!


If so, that might explain the dearth of doc. If not, then never mind.



--
Phoenix Software International
Edward E. Jaffe
Chief Technology Officer
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: What cryptographic algorithm is not supported?

[Charles Mills]

That could be another thread "most useless diagnostic ever."

Right, that is the API call (apparently) that failed, but I don't think one 
knows that just from the error message. As I said, I got the same error message 
for presenting a certificate with a SHA-1 digest (I think). Presumably a 
different CMS API call but the same external message. Different action for the 
user.

I display certificates all the time. My script that issues OpenSSL certificates 
displays them at the end.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Tuesday, November 7, 2017 8:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What cryptographic algorithm is not supported?

Its not the worst diagnostic situation that I have seen on z/OS ( that award 
would go to the C-library OS I/O stuff IMO).

In this case, the external API that failed is gsk_decode_import_key(), and if 
you look it up the error that you are getting is documented:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.gska100/msg34.htm

The algorithm codes can be found in /usr/include gskcms.h
x509_alg_pbeWithSha1And40BitRc2Cbc  = 36,  /* 1.2.840.113549.1.12.1.6   */

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS>  If you want some "fun", take you X.509 cert and load it into a 
PS> ASN.1
tool that displays the whole ugly thing

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

Re: AW: Odd SMF 30 data within IEFACTRT

[DanD]

Thank you peter.  You are correct and this was entirely my mistake.

I (incorrectly) assumed that if an offset and length existed for a SMF30 
segment that there must be at least 1.
WRONG, I need to check all three for non-zero values.
With the SMF that I've processed so far over the last couple weeks, the zEDC 
Usage Statistics Section is the only one that I've encountered that has an 
offset and length and a zero count.  Anyway, I was incorrect and have since 
updated my code.

Thanks again Peter and all those who pointed out my error.
Dan


The fields you show look to me as if they partly contain EBCDIC data. E.g. the 
first field has x'E2E3C5D7' which is c'STEP'. Has there been any zEDC 
compression in that step? If not, the section is not there and you are looking 
at random data.
-- 
Peter Hunkeler

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

Re: What cryptographic algorithm is not supported?

[Kirk Wolf]

Its not the worst diagnostic situation that I have seen on z/OS ( that
award would go to the C-library OS I/O stuff IMO).

In this case, the external API that failed is gsk_decode_import_key(), and
if you look it up the error that you are getting is documented:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.gska100/msg34.htm

The algorithm codes can be found in /usr/include gskcms.h
x509_alg_pbeWithSha1And40BitRc2Cbc  = 36,  /* 1.2.840.113549.1.12.1.6   */

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS>  If you want some "fun", take you X.509 cert and load it into a ASN.1
tool that displays the whole ugly thing

On Mon, Nov 6, 2017 at 7:55 PM, Charles Mills  wrote:

> Got it! The only password encryption algorithm (PBE) supported for FIPS
> mode is pbeWithSha1And3DesCbc.
>
> In OpenSSL PCKS12, I needed to add -certpbe PBE-SHA1-3DES
>
> Sheesh! Would a more specific error message kill them?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Monday, November 6, 2017 5:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What cryptographic algorithm is not supported?
>
> Okay, I got trace information out of gskkyman. What do you make of this?
>
> INFO crypto_des3_encrypt_ctx(): Clear key DES3 encryption performed for 8
> bytes
> INFO crypto_des3_decrypt_ctx(): Clear key DES3 decryption performed for 8
> bytes
> INFO crypto_des3_encrypt_ctx_alet(): Clear key DES3 encryption performed
> for 8 bytes
> INFO crypto_des3_decrypt_ctx_alet(): Clear key DES3 decryption performed
> for 8 bytes
> INFO crypto_aes_encrypt_ctx(): Clear key AES 128-bit encryption performed
> for 16 bytes
> INFO crypto_aes_decrypt_ctx(): Clear key AES 128-bit decryption performed
> for 16 bytes
> INFO crypto_aes_encrypt_ctx_alet(): Clear key AES 128-bit encryption
> performed for 16 bytes
> INFO crypto_aes_decrypt_ctx_alet(): Clear key AES 128-bit decryption
> performed for 16 bytes
> INFO crypto_aes_encrypt_ctx(): Clear key AES 256-bit encryption performed
> for 16 bytes
> INFO crypto_aes_decrypt_ctx(): Clear key AES 256-bit decryption performed
> for 16 bytes
> INFO crypto_aes_encrypt_ctx_alet(): Clear key AES 256-bit encryption
> performed for 16 bytes
> INFO crypto_aes_decrypt_ctx_alet(): Clear key AES 256-bit decryption
> performed for 16 bytes
> INFO crypto_rsa_public_encrypt(): RSA modulus is 2048 bits
> INFO crypto_rsa_public_encrypt(): Software RSA public key encryption
> performed
> INFO crypto_rsa_private_decrypt(): Using PKCS private key
> INFO crypto_rsa_private_decrypt(): RSA modulus is 2048 bits
> INFO crypto_rsa_private_decrypt(): Software RSA private key decryption
> performed
> INFO open_kdb_check_filedata(): Record size 5000, Record count 12
> INFO gsk_build_issuer_chains(): Record 'Equifax Secure Certificate
> Authority' is self-signed
> INFO gsk_build_issuer_chains(): Record 'Equifax Secure eBusiness CA-2' is
> self-signed
> INFO gsk_build_issuer_chains(): Record 'VeriSign Class 1 Public Primary CA
> - G2' is self-signed
> INFO gsk_build_issuer_chains(): Record 'VeriSign Class 2 Public Primary CA
> - G2' is self-signed
> INFO gsk_build_issuer_chains(): Record 'VeriSign Class 3 Public Primary CA
> - G2' is self-signed
> INFO gsk_build_issuer_chains(): Record 'VeriSign Class 4 Public Primary CA
> - G2' is self-signed
> INFO gsk_build_issuer_chains(): Record 'VeriSign Class 1 Public Primary CA
> - G3' is self-signed
> INFO gsk_build_issuer_chains(): Record 'VeriSign Class 2 Public Primary CA
> - G3' is self-signed
> INFO gsk_build_issuer_chains(): Record 'VeriSign Class 3 Public Primary CA
> - G3' is self-signed
> INFO gsk_build_issuer_chains(): Record 'VeriSign Class 4 Public Primary CA
> - G3' is self-signed
> INFO gsk_build_issuer_chains(): Record 'VeriSign Class 3 Public Primary CA
> - G5' is self-signed
> INFO gsk_build_issuer_chains(): Record 'CMC_root_Exp_2024a' is self-signed
> INFO open_kdb_check_filedata(): Record size 5000, Record count 0
> ERROR crypto_pbe_decrypt_data(): Algorithm 36 is not supported for PBE
> ERROR import_pkcs12v3(): Unable to decrypt EncryptedData message: Error
> 0x03353003
> ERROR gsk_decode_import_key(): Unable to import PKCS12 V3: Error 0x03353003
> ERROR gsk_import_key(): Unable to decode subject certificate or chain:
> Error 0x03353003
>
> Algorithm 36 (cipher suite 36?) is TLS_DH_DSS_WITH_AES_256_CBC_SHA. Where
> does that come into the picture? What is PBE?
>
> --
> 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: Determine tasks PSWA "next instruction to execute" from an STIMER exit?

[Peter Relson]

As was mentioned in one of the threads, you need to follow the RB chain 
(TCBRBP points to the newest).

The STIMER exit itself is running as an IRB. When any RB ends normally, 
the registers associated with the previously running RB (some saved in the 
current RB, some in the RB's XSB) and the PSW associated with the 
previously running RB (saved in that previous RB/XSB) is used to give 
control (thus has the next instruction address).

Peter Relson
z/OS Core Technology Design


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

Re: What cryptographic algorithm is not supported?

[Paul Gilmartin]

On Tue, 7 Nov 2017 08:53:48 -0600, Edward Gould wrote:
>
>May I make an observation, please?
>
>... IBM standards which indicate e,s,i etc at the end to indicate severity ...
> 
Oh, come on!  As long as I can remember, various fatal JCL and excution error
messages have had an "I" suffix.  This seems counterintuitive to me, but I 
expect
true blue readers of this form to rationalize it.

-- gil

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

Re: What cryptographic algorithm is not supported?

[Edward Gould]

> On Nov 6, 2017, at 7:55 PM, Charles Mills  wrote:
> 
> Got it! The only password encryption algorithm (PBE) supported for FIPS mode 
> is pbeWithSha1And3DesCbc.
> 
> In OpenSSL PCKS12, I needed to add -certpbe PBE-SHA1-3DES
> 
> Sheesh! Would a more specific error message kill them?
> 
> Charles

Charles:

May I make an observation, please?

Somewhere around the 1992-95 time frame, IBM went south as to documenting 
information that was critical, *I THINK* it was around the time that the UNIX 
people came in.
Messages that were easy to understand became pretty well gibberish with TCP, 
especially when it came time for TCP and the UNIX. The TCP people would put out 
a message and in the message was a rc. The RC never seemed to be documented in 
the message and as a result would require a call to the support line for help 
adding sometimes days (sometimes minutes though) to get an answer. OK then once 
you have that, sometimes that didn’t help as you had no idea what they were 
referencing, which started a new call to the support center. Problem 
determination seemed to take forever. If you were lucky the guy on the other 
end actually had an idea what the problem was and would give you a nudge, then 
there was the call back from level 2/3 and they (to me anyway) were talking 
about items that I did not have a clue on. Sometimes you were really unlucky 
and got two rc’s and then that was an automatic call.
I don’t know if any one else noticed that the TCP messages did not follow IBM 
standards which indicate e,s,i etc at the end to indicate severity and that the 
length of the messaged changed.. Then you pick up the TCP book on error 
messages and for a lot of them. The message was just reworded and echo’s back 
at you. I just hated TCP issues as they were like talking to a wall and add to 
the fact that they seem to be talking a different language than IBM used to 
talk and you were used to did  not help out a bit. Also, it seemed that none of 
the RC’s were documented.

After the initial brush with TCP I refused to go near it again. The damn TCP 
error message book was like a wooden stick to my heart. I tried to palm off any 
tcp issues to someone else as I got frustrated to the point of asking the boss 
to hire someone that was an expert as I never wanted to see another TCP message 
again.

Ed


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

AW: Re: SUBSYS= ?

[Peter Hunkeler]

>I don't think it is hidden information, I just found:
>z/OS MVS Using the Subsystem Interface SA38-0679-00
>One chapter is called: Why Write Your Own Subsystem?


Yes, it is well documented how to write your own subsystem, and it is well 
documented, what functions you can support. What is missing is the whole set of 
functions that you need to support in order to make your own support for DD 
SUBSYS=. That was once documented in an orange book.


>Each subsystem can deliver support for SUBSYS= in the JCL to handle DD 
>statements if it is useful, like Panvalet, Librarian, LOGR and others 
>mentioned. They have to document the interface for their SUBSYS= JCL parameter.


Yes. For me this is proof enough that the interface itself will not disappear 
anytime soon, or more probably, never. But it does not help to write your own 
code and that is what the OP wanted, I understood.


--
Peter Hunkeler



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

Re: LNKLST Question

[Peter Relson]

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

I don't know who wrote that document, but it wasn't me, and does not 
represent anything that anyone sane would think is suitable for production 
use.
The basic problem is the use of LNKLST UPDATE JOB=* which is unpredictably 
dangerous and can vary from "working" to abends to crashing your system 
(with little to no sympathy for those that suffer the latter symptom). It 
is basically a "I have nothing to lose because I'd have to re-IPL anyway 
if this didn't happen to work" option.

>would it be possible to activate LNKLST1 again instead of defining 
LNKLST3 ?

Going beyond "possible", activating LNKLST1 would be the recommended 
approach.

Peter Relson
z/OS Core Technology Design


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

Re: What cryptographic algorithm is not supported?

[Steve Smith]

I see what you did there ;-)

On Tue, Nov 7, 2017 at 1:34 AM, Timothy Sipples  wrote:

> However, it'd be lovely if you would submit a RFE (not PMR) to IBM to
> expand that PBE-related GSK error message handling in some reasonable way
> PDQ, possibly resulting in a PTF that you'd install in zFS via a TSO login.
> BTW, RFC standards like TLS and SSL with their SHA, RSA, DES, PKI, CBC,
> XTS, and other characteristics can sometimes be a PITA.
>
> http://www.ibm.com/developerworks/rfe
>
> Thx. :-)
>
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA
> E-Mail: sipp...@sg.ibm.com

sas

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

Re: SUBSYS= ?

[Vernooij, Kees (ITOPT1) - KLM]

I don't think it is hidden information, I just found: 
z/OS MVS Using the Subsystem Interface SA38-0679-00
One chapter is called: Why Write Your Own Subsystem?

Each subsystem can deliver support for SUBSYS= in the JCL to handle DD 
statements if it is useful, like Panvalet, Librarian, LOGR and others 
mentioned. They have to document the interface for their SUBSYS= JCL parameter.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: 07 November, 2017 12:19
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: SUBSYS= ?
> 
> 
> >My comment about deprecation was limited to the SUBSYS= keyword. I saw
> from other replies that Panvalet and Librarian use the keyword.
> 
> 
> 
> Just to remember: z/OS MVS's system logger provides support for SUBSYS
> JCL keyword to read either logrec or SMF directly from the logstream:
> 
> 
> From the z/OS MVS Tools and Service Aids manual:
> SUBSYS=(LOGR[,exit_routine_name][,'SUBSYS-options1'][,'SUBSYS-
> options2']) Specifies that processing of this DD is to be handled by the
> LOGR subsystem. The exit_routine_name is the second positional parameter
> and specifies the name of the exit routine to receive control from the
> LOGR subsystem.
> o Specify or use the default value to IXGSEXIT to use the log stream
> subsystem exit routine.
> o Specify IFBSEXIT to access records from the logrec log stream. See
> SUBSYS-options2 for logrec-specific paramters.
> o Specify IFASEXIT to access records from SMF log streams. See SUBSYS-
> options2 for SMF-specific parameters.
> 
> 
> I guess (I'm not a vendor) that vendors might get access to
> documentation related to SUBSYS= SSI function under some nondisclosure
> agreement or what ever.
> Curious to understand where the problems with SUBSYS= lie.
> 
> 
> --
> Peter Hunkeler
> 
> 
> 
> --
> 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

Re: Odd SMF 30 data within IEFACTRT

[Martin Packer]

Knowing the length of a section MIGHT be interesting, even if there are none of 
them. As it might indicate maintenance level (occasionally).

To be fair, I’d put it in the category of “interesting” but not necessarily 
“useful”. :-)

Cheers, Martin 

Sent from my iPad

> On 6 Nov 2017, at 22:43, Barry Merrill  wrote:
> 
> It is documented for many newer SMF records that the COUNT field is the
> sole indicator that there are in fact these segments in this record.
> The OFFSET seems always to be busy, and the value of the location of
> the next triplet, even when this is the last triplet.
> 
> As noted, the Length value of zero is now used to indicate that the
> actual length is in the first two bytes at the offsed, if COUNT is
> non-zero.
> 
> Barry
> 
> 
> Merrilly yours,
> 
> Herbert W. Barry Merrill, PhD
> President-Programmer
> Merrill Consultants
> MXG Software
> 10717 Cromwell Drive  technical questions: supp...@mxg.com
> Dallas, TX 75229
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mxg.com=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=iZuqNF3254ztNCrcdxK6gfQ5Iptbpeu3E3usulPRmChPA=Zf3L5YjVZ8H5zutL_KUf33-JuZKXrcPS6pFOYJSo5DI=
> admin questions: ad...@mxg.com
> tel: 214 351 1966
> fax: 214 350 3694
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of DanD
> Sent: Monday, November 6, 2017 2:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Odd SMF 30 data within IEFACTRT
> 
> Thanks everyone.
> 
> I WILL check all 3 fields for zeros in the future.
> It's still odd that the 1st record has an offset and length but the count is 
> zeros...
> 
> "Here's the section your looking for ... it's this big ... and there are 
> NONE"  what? ;-)
> 
> Dan
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

AW: Re: SUBSYS= ?

[Peter Hunkeler]

>My comment about deprecation was limited to the SUBSYS= keyword. I saw from 
>other replies that Panvalet and Librarian use the keyword.



Just to remember: z/OS MVS's system logger provides support for SUBSYS JCL 
keyword to read either logrec or SMF directly from the logstream:


>From the z/OS MVS Tools and Service Aids manual:
SUBSYS=(LOGR[,exit_routine_name][,'SUBSYS-options1'][,'SUBSYS-options2']) 
Specifies that processing of this DD is to be handled by the LOGR subsystem. 
The exit_routine_name is the second positional parameter and specifies the name 
of the exit routine to receive control from the LOGR subsystem.
o Specify or use the default value to IXGSEXIT to use the log stream subsystem 
exit routine.
o Specify IFBSEXIT to access records from the logrec log stream. See 
SUBSYS-options2 for logrec-specific paramters.
o Specify IFASEXIT to access records from SMF log streams. See SUBSYS-options2 
for SMF-specific parameters.


I guess (I'm not a vendor) that vendors might get access to documentation 
related to SUBSYS= SSI function under some nondisclosure agreement or what ever.
Curious to understand where the problems with SUBSYS= lie.


--
Peter Hunkeler



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