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 p
I was reading IBM system Mag at
http://ibmsystemsmag.com/mainframe/hot-topics/crypto-statistics-monitor/?utm_source=SilverpopMailing&utm_medium=email&utm_campaign=110717-a_IMFEXTRA%20(1)%20Live%20Send&utm_content=Article%20Title%202&spMailingID=12299030&spUserID=MTMzMzgyMTE0MjcxS0&spJobID=12805510
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 Rich
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. Jus
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
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
>
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
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 loade
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: Ar
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 loa
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 hel
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
>... 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 an
Are you talking about these?
BROWSESYS1.SIEALNKE
Command ===>
Name Prompt
_ JVMLDM60
_ JVMLDM61
_ JVMLDM66
_ JVMLDM67
_ JVMLDM70
_ JVMLDM71
_ JVMLDM76
_ JVMLDM77
_ JVMLDM80
_ JVMLDM86
Farl
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
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 a
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
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 thou
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 Nort
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
diffe
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 we
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/knowledge
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
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 seem
> 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
>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 missin
> 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
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
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 oth
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, B
>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/O
31 matches
Mail list logo
