Re: How to find the Global zone names in SMP/E via REXX

[Nims,Alva John (Al)]

You will not get any argument from me about GIMAPI being "REXX Hostile," but 
that is why I mentioned the CBTTAPE, I believe more than one person has created 
the interface between REXX and GIMAPI, to let REXX work with it.

Al Nims
UFIT
University of Florida
(352) 273-1298
@Home

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, August 08, 2017 3:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to find the Global zone names in SMP/E via REXX

On 2017-08-08, at 11:01, Nims,Alva John (Al) wrote:

> It is documented in "SA23-2276-02 SMP/E for z/OS Reference" look for GIMAPI, 
> on the CBTTAPE are some routines that provide an interface between REXX and 
> GIMAPI.
>  
I don't consider GIMAPI a Rexx API; it's Rexx-hostile.  It requires that the 
caller supply pointers in argument blocks, and pointers are not a capability of 
Rexx.  So an interface to the interface is necessary.

ICSF did far better with its API -- its arguments are Rexx-friendly without 
being Rexx-peculiar.  It's a pity that the designers of GIMAPI lacked such 
foresight.

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

Oracle Database Provider for DRDA

[Frank Swarbrick]

Is anyone familiar with this?  Appears to allow DB2 client applications to 
connect "directly" to Oracle databases.  In the case of z/OS I imagine it would 
be similar to using DDF to connect from z/OS to a non-z/OS DB2 database.

Frank


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

Re: z13s IOCP with FTP issue

[Tony Thigpen]

We don't let *anybody* into the network between the HMC and the SE. Too 
many SEs have default passwords on some of the 'special' IDs that can 
not be easily changed.


We bought a small two-nic nas box and placed it on both the SE network 
and the company network. IOCPs and ICCs go to it as an interim location. 
I.E., copy the IOCP to the nas. Then, access the nas via the company 
network. You could just add another nic card to your FTP server, but 
make sure that the server has all routing turned off.


Also, we set the default route on the SE to 0.0.0.0. An additional 
protection against anybody getting into that network segment.


Tony Thigpen

Eric Chevalier wrote on 08/08/2017 04:42 PM:

On 8/3/17 10:13 AM, Tony Thigpen wrote:


1) The ip address has to be available from SE laptop in the cpu. If
you have the connections between the HMC and the SE on a isolated
network, then the ftp box has to also be on that same isolated network.


We have our HMC on an internal company network so it can be accessed
from anywhere, even remotely via VPN. Is there any good technical reason
why the SE can't also be on that network for better access to FTP
servers in our organization? I realize that having the SE on a separate
private network might be better security, but that caused some grief
recently. We needed to import an IOCDS into our z13, but that file was
in our headquarters office. Because port forwarding isn't enabled on the
HMC, so we couldn't get access to the FTP server hosting the IOCDS.

--
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: Info and Orlando

[Tony Thigpen]

Contact me off-list. We have some stuff. It depends what you need.

Tony Thigpen

W Mainframe wrote on 08/08/2017 05:54 PM:

Guys,I am on vacation in Orlando. Does anyone know some place to buy IBM parts 
of ISeries and PSeries?
Thank youDan


Sent from Yahoo Mail for iPhone

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

Info and Orlando

[W Mainframe]

Guys,I am on vacation in Orlando. Does anyone know some place to buy IBM parts 
of ISeries and PSeries?
Thank youDan


Sent from Yahoo Mail for iPhone

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

Re: How to find the Global zone names in SMP/E via REXX

[ITschak Mugzach]

Have a look at the catalog interface (sys1.samplib(IGG*)). They use rexx to
invoke the utility. I believe same way can br used with the smpe api. I
once tried that, but didn't have the time to complete the work...

ITschak

On Tue, Aug 8, 2017 at 10:07 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On 2017-08-08, at 11:01, Nims,Alva John (Al) wrote:
>
> > It is documented in "SA23-2276-02 SMP/E for z/OS Reference" look for
> GIMAPI, on the CBTTAPE are some routines that provide an interface between
> REXX and GIMAPI.
> >
> I don't consider GIMAPI a Rexx API; it's Rexx-hostile.  It requires
> that the caller supply pointers in argument blocks, and pointers are
> not a capability of Rexx.  So an interface to the interface is
> necessary.
>
> ICSF did far better with its API -- its arguments are Rexx-friendly
> without being Rexx-peculiar.  It's a pity that the designers of GIMAPI
> lacked such foresight.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|** Automatic ISCM**  (Information Security
Contiguous Monitoring) **|  *

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

Re: z13s IOCP with FTP issue

[Eric Chevalier]

On 8/3/17 10:13 AM, Tony Thigpen wrote:

1) The ip address has to be available from SE laptop in the cpu. If you 
have the connections between the HMC and the SE on a isolated network, 
then the ftp box has to also be on that same isolated network.


We have our HMC on an internal company network so it can be accessed 
from anywhere, even remotely via VPN. Is there any good technical reason 
why the SE can't also be on that network for better access to FTP 
servers in our organization? I realize that having the SE on a separate 
private network might be better security, but that caused some grief 
recently. We needed to import an IOCDS into our z13, but that file was 
in our headquarters office. Because port forwarding isn't enabled on the 
HMC, so we couldn't get access to the FTP server hosting the IOCDS.


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

Re: Curse you, L-Soft!

[David W Noon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 8 Aug 2017 12:36:00 -0500, Elardus Engelbrecht
(elardus.engelbre...@sita.co.za) wrote about "Curse you, L-Soft!" (in
<8733075135946583.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>):

> David W Noon wrote:
[snip]
>> Hash: SHA1
> 
> You're using SHA1, not SHA256? Ok, what e-mail software are you
> using. If you don't want to answer, this is fine with me.

The hash does not need to be particularly secure for signing, so SHA1 is
plenty good enough. Even MD5 can still be used.

I used Claws Mail to send that message. I am using Thunderbird to send
this one. Claws is much more RFC-compliant than Thunderbird.

>> You might see this message encoded as Base64. I am including a 
>> cryptographic signature and that usually requires a binary-safe 
>> encoding.
> 
> Yes and I see this too: "-BEGIN PGP SIGNATURE-"

I'll add a PGP signature to this message too. Thunderbird probably will
not encode it as Base64 as T'bird is not RFC-compliant (or at least not
as compliant as Claws). The only reason I do not use Claws all the time
is because it does not always play nice with the MDA I use.

SECOND ATTEMPT:
===

LISTSERV does not accept messages signed with an attachment, only with
an inline signature. The first attempt was rejected by LISTSERV. So
we'll try again.

> I don't remember I ever see that, but I can see your reply on
> IBM-MAIN properly, but when I "quote" your reply while composing my
> own reply to you and to IBM-MAIN via web-site, all your reply is
> encrypted.

I don't know what MUA(s) you are using, but I would feel inclined to use
something else if I were you.

> I believe someone posted an URL where you can place that encoded 
> message and that site can translate it for you into readable text.

All UNIX-like systems have command-line utilities to decode Base64 into
original text (or even binary).

It has been many years since I last used Windows. I don't think I could
live with its limitations these days.
- -- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


-BEGIN PGP SIGNATURE-

iHoEARECADoWIQQj5Jtua8i7AnGK26uiBiBwjhb/lAUCWYoYohwcZGF2aWQudy5u
b29uQGdvb2dsZW1haWwuY29tAAoJEKIGIHCOFv+UOIsAoLka/l+PWUvbLKC5fcAx
ve+/4TI5AJ9CskfP8ZF3m+5R+x1yr8zswW4ymQ==
=WN/U
-END PGP SIGNATURE-

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

Base64 (was: z/OS Secure FTP Question)

[Paul Gilmartin]

On Tue, 8 Aug 2017 14:29:00 -0500, Walt Farrell wrote:

>On Tue, 8 Aug 2017 10:35:08 -0600, Paul Gilmartin wrote:
>
>>(Interesting: another base64 body I can't quote on the Web interface.)
>
>If you use Firefox you might consider installing the LeetKey extension, which 
>will allow such quoting with relative ease. Just select the encoded text, 
>right-click, choose LeetKey, Text Tranformers, Base64 Decode.
>
Why should that be necessary?  LISTSERV is broken; it should be fixed.

As it is, I just reply to such messages from the email interfact.

The existence of a circumvention does not remove the desirability of a repair;
the first thing a user tries should work, not the second, or third, or ...

Thanks,
gil

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

Researching Destination z article on non-US mainframes

[Gabe Goldberg]

Here's a query I've sent to a few individuals, and I'll send a couple 
more to people outside US who I've seen post here or elsewhere. If 
you're running a non-US mainframe -- or have done so, or know people who 
have, or have thoughts on this -- and might chat a bit via email, please 
get in touch.


As usual, if you reply to the list, please copy me directly so your note 
isn't buried in the daily list digest.


Thanks!

 Forwarded Message 
Subject:Researching article on international mainframes
Date:   Tue, 8 Aug 2017 14:36:50 -0400
From:   Gabe Goldberg 
To: 



First, I have to call this "non-US use of mainframes" rather than 
"international", since to the rest of the world, the US is "international".


My point to editor proposing this article was that it's too easy to 
forget that US isn't only -- and maybe isn't main! -- user of mainframes.


I'd like to include brief non-US mainframe usage profiles plus comments 
on differences in mainframe applications/issues world-wide.


So I'll appreciate whatever you can provide...

 * Your thoughts on this
 * Suggestions of interesting non-US sites which might be willing to
   chat (via email) for brief profiles
 * Pointers to mainframe user groups around the world
 * Introduction to similar mainframe experts/advocates elsewhere
 * Noteworthy regional variations in mainframe usage/applications/issues

Thanks!

--
Gabriel Goldberg, Computers and Publishing, inc.g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn:http://www.linkedin.com/in/gabegold Twitter: GabeG0


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

Re: z/OS Secure FTP Question

[Walt Farrell]

On Tue, 8 Aug 2017 10:35:08 -0600, Paul Gilmartin  wrote:

>(Interesting: another base64 body I can't quote on the Web interface.)

If you use Firefox you might consider installing the LeetKey extension, which 
will allow such quoting with relative ease. Just select the encoded text, 
right-click, choose LeetKey, Text Tranformers, Base64 Decode.

-- 
Walt

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

Re: How to find the Global zone names in SMP/E via REXX

[Paul Gilmartin]

On 2017-08-08, at 11:01, Nims,Alva John (Al) wrote:

> It is documented in "SA23-2276-02 SMP/E for z/OS Reference" look for GIMAPI, 
> on the CBTTAPE are some routines that provide an interface between REXX and 
> GIMAPI.
>  
I don't consider GIMAPI a Rexx API; it's Rexx-hostile.  It requires
that the caller supply pointers in argument blocks, and pointers are
not a capability of Rexx.  So an interface to the interface is
necessary.

ICSF did far better with its API -- its arguments are Rexx-friendly
without being Rexx-peculiar.  It's a pity that the designers of GIMAPI
lacked such foresight.

-- gil

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

Re: Curse you, L-Soft!

[Paul Gilmartin]

On Tue, 8 Aug 2017 18:24:29 +0100, David W Noon wrote:
>
>Mutt has always been very RFC-compliant.
> 
Meaning both that it obeys the rules in the RFCs and doesn't invent any
of its own.

>Microsoft sets the standards.
> 
I'm mad as hell, and I'm not going to take it anymore!

>Another problem with a non-breaking blank is finding a MUA that
>respects the non-breaking attribute.
> 
Sigh.  That might be more of the OS's text viewer than of the MUA itself.

>RFC 822 has been doubly obsoleted, by RFC 2822 and RFC 5322. The latter
>specifies 998 bytes as the line limit with a CR/LF pair added to make
>1000. It also recommends a limit of 78 bytes, plus CR/LF. This is why
>lines of more than 80 bytes in total can induce encoding.
> 
That strikes me as a cowardly accommodation to broken MUAs such as
VM's RSCS.  But even that can be configured to deliver messages in
NETDATA format rather than printer spool images.  An overzealous
application of Postel's Principle.

>> And encoding might be needed to protect a "From" message separator.  I
>> recall one MUA that encoded every "F" anywhere in a message as hex 46.
>> My first guess at its motivation was probably wrong.
>
>The "From" separator is peculiar to Berkeley/Eudora mbox mail storage,
>although there are many recensions of this. Anything else should not
>escape this as ">From", even though some MDAs and even some MTAs do
>this, but the usual culprit seems to be mailing list forwarders. I see
>lots of paragraphs that begin with "From" that have been decorated to
>">From" even though no mbox storage has occurred along the way.
>
Heavy sigh.

-- gil

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

Re: Curse you, L-Soft!

[Elardus Engelbrecht]

David W Noon wrote:

>-BEGIN PGP SIGNED MESSAGE- 

First time I see this prefix message with PGP and word MESSAGE. Hmmm, 
interesting. I really need to do drink coffee and then RTFM... 


>Hash: SHA1 
 
You're using SHA1, not SHA256? Ok, what e-mail software are you using. If you 
don't want to answer, this is fine with me. 


>Shmuel Metz has something to say about almost everything. ... :-) 

Hahahahahaha! LOL! ;-D

He [and Chris Mason] sometimes flamed me [privately] for every comment I make, 
but that is Ok with me, I just say "thank you" and move on.

 
>You might see this message encoded as Base64. I am including a cryptographic 
>signature and that usually requires a binary-safe encoding. 

Yes and I see this too: "-BEGIN PGP SIGNATURE-"

I don't remember I ever see that, but I can see your reply on IBM-MAIN 
properly, but when I "quote" your reply while composing my own reply to you and 
to IBM-MAIN via web-site, all your reply is encrypted. 

I believe someone posted an URL where you can place that encoded message and 
that site can translate it for you into readable text.

David, please continue with your posts. I (and probably others too) learn and 
value your kind posts.

Thank you and all of the very best to you! 

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

Re: Curse you, L-Soft!

[David W Noon]

On Tue, 8 Aug 2017 09:16:18 -0500, Paul Gilmartin (Paul Gilmartin) wrote
about Curse you, L-Soft!:

[snip]
> According to various experiments and headers of off-list messages:
> 
> MacOS Mail.app sends utf-8 as quoted-printable but deals corectly with
> incoming 8-bit/
> 
> From one set of mail headers:
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
>  Thunderbird/52.2.1
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 8bit

Mutt has always been very RFC-compliant.

> From another sent from Outlook/Windoze:
> Content-Type: text/plain;
>  charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> WTF!?  Why encode us-ascii?  7bit should suffice.  But every blank
> was encoded as hex 20!?

Microsoft sets the standards.

> A message I sent with mutt to IBM-MAIN; Cc: e...@univie.ac.at was
> reflected by echo with an 8bit header so I assume that's what mutt
> uses. But IBM-MAIN REPROed it as quoted-printable.  Still phobic of
> 8bit.
> 
> A "non-blank blank" might be either a nonbreaking space or an
> en-space.  8bit utf-8 should suffice for those; no need for base64.

Another problem with a non-breaking blank is finding a MUA that
respects the non-breaking attribute.

> RFC 822 limits records to 999 bytes, give or take a .  Longer
> records require some encoding.  But some MUAs, phobically, encode any
> message containing records longer than 80 bytes.  I blame a desire to
> accommodate antediluvian IBM conventions for this compulsion.

RFC 822 has been doubly obsoleted, by RFC 2822 and RFC 5322. The latter
specifies 998 bytes as the line limit with a CR/LF pair added to make
1000. It also recommends a limit of 78 bytes, plus CR/LF. This is why
lines of more than 80 bytes in total can induce encoding.

> And encoding might be needed to protect a "From" message separator.  I
> recall one MUA that encoded every "F" anywhere in a message as hex 46.
> My first guess at its motivation was probably wrong.

The "From" separator is peculiar to Berkeley/Eudora mbox mail storage,
although there are many recensions of this. Anything else should not
escape this as ">From", even though some MDAs and even some MTAs do
this, but the usual culprit seems to be mailing list forwarders. I see
lots of paragraphs that begin with "From" that have been decorated to
">From" even though no mbox storage has occurred along the way.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: Curse you, L-Soft!

[Paul Gilmartin]

(off-list)
On 2017-08-08, at 10:50, David W Noon wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Tue, 8 Aug 2017 01:45:22 -0500, Elardus Engelbrecht (Elardus
> Engelbrecht ) wrote about Re: Curse
> you, L-Soft!:
> 
>> David W Noon wrote:
>> 
>>> Sometimes Base64 or other binary-safe encoding is required by RFC.  
>> 
>> So I see. Thanks. Wish Shmuel is here, he certainly has something to
>> say about all these RFC requirements...
> 
> Shmuel Metz has something to say about almost everything. ... :-)
> 
> You might see this message encoded as Base64. I am including a
> cryptographic signature and that usually requires a binary-safe
> encoding.
>  
Indeed:
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=US-ASCII

-- 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 Secure FTP Question

[Jousma, David]

It all depends on how often you order/receive maintenance.   I do it weekly, 
and get by with a 4Gb NTS.   If I wait several weeks, and some "large" 
maintenance comes out(think java replacements) then I've run out.   I currently 
run with a 8Gb NTS.   When I order a new Serverpack, I go by what the doc says, 
but I typically allocate a temporary 30-40Gb NTS that stays around long enough 
to populate all the datasets, and then it goes away.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Veryl Ellis
Sent: Tuesday, August 08, 2017 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Secure FTP Question

CAUTION EXTERNAL EMAIL

Another question.

Any idea how much DASD space to allocate for the SMPNTS and/or SMPWKDIR ZFS 
files?
I seem to keep running out.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Tuesday, August 08, 2017 12:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Secure FTP Question

I agree, HTTPS is much easier to both implement and use.  IBM supplies the 
directions on every order in ShopZSeries (off on the right side).  I think they 
also tell you right in each shipment, but I could be wrong.

Brian

--
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 **DO NOT open 
attachments or click on links from unknown senders or unexpected emails**

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


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

Re: How to find the Global zone names in SMP/E via REXX

[Nims,Alva John (Al)]

It is documented in "SA23-2276-02 SMP/E for z/OS Reference" look for GIMAPI, on 
the CBTTAPE are some routines that provide an interface between REXX and GIMAPI.


"Overview of GIMAPI

GIMAPI is a program (load module) provided with IBM SMP/E for z/OS, V3R6 that 
can be called by a user-written application program to query the contents of 
the CSI.

GIMAPI uses data structures both to receive the query parameters from the 
caller and to return the query output to the caller. To request a query, you 
must set up the data structure containing the appropriate query parameters and 
call GIMAPI.
The general form of the GIMAPI call is:

GIMAPI(apicmd,parmptr,outptr,language,rc,cc,msgbuff)
where apicmd specifies the API command that GIMAPI is to process (either QUERY, 
FREE or VERSION). See QUERY command, FREE command and VERSION command for 
descriptions of these commands and a detailed description of how the remaining 
parameters parmptr, outptr, language, rc, cc, and msgbuff) are used on those 
commands.
Parent topic: SMP/E CSI application programming interface"


Al Nims
UFIT
University of Florida
(352) 273-1298
@Home

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, August 08, 2017 11:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to find the Global zone names in SMP/E via REXX

On Tue, 8 Aug 2017 13:44:03 +, Nims,Alva John (Al) wrote:

>Does any of the CBT Tape REXX programs that access the SMP/e API do the job?
> 
I see no mention of an API for Rexx in the SMP/E User's Guide, Reference, or 
Commands.
Where is an API for Rexx documented?

-- 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: Curse you, L-Soft!

[David W Noon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 8 Aug 2017 01:45:22 -0500, Elardus Engelbrecht (Elardus
Engelbrecht ) wrote about Re: Curse
you, L-Soft!:

> David W Noon wrote:
> 
> >Sometimes Base64 or other binary-safe encoding is required by RFC.  
> 
> So I see. Thanks. Wish Shmuel is here, he certainly has something to
> say about all these RFC requirements...

Shmuel Metz has something to say about almost everything. ... :-)

You might see this message encoded as Base64. I am including a
cryptographic signature and that usually requires a binary-safe
encoding.

> >MTA = Mail Transfer Agent
> >This is/are the SMTP server(s) used to move email around.
> >Using a fully RFC-compliant MUA can cause many problems for those
> >who use "cowboy coded" MUAs.  
> 
> >And to complete the email glossary:
> >MUA = Mail User Agent (your mail reader)
> >MDA = Mail Delivery Agent (the server from which your MUA downloads
> >mail)  
> 
> Thanks for your kind help and the list of those glossary. I'll ask my
> SMTP colleague about this.
> 
> Thanks again! Much appreciated.

My pleasure.
- -- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQQj5Jtua8i7AnGK26uiBiBwjhb/lAUCWYnrugAKCRCiBiBwjhb/
lL5CAKDT8paMZN7aHzjYKlkxniKHDRUteACeJlLOx2LiWzEuXaWQbrWlgk+eemA=
=b6P2
-END PGP SIGNATURE-

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

Re: z/OS Secure FTP Question

[Paul Gilmartin]

(Interesting: another base64 body I can't quote on the Web interface.)
On 2017-08-08, at 09:55, Allan Staller wrote:

> SMPWKDIR should be at least 3 times the size of the package.
> IIRC, there is a minimal increase in the root filesystem.
> 
> -Original Message-
> From: Veryl Ellis
> Sent: Tuesday, August 8, 2017 10:47 AM
> 
> Any idea how much DASD space to allocate for the SMPNTS and/or SMPWKDIR ZFS 
> files?
> I seem to keep running out.
>  
Interesting.  But a quality client could send an HTTP HEAD request and
use a "Content-Length:" header (if the server supplies one) to verify
sufficient target space or make a recommendation.

-- 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 Secure FTP Question

[Allan Staller]

SMPWKDIR should be at least 3 times the size of the package.
IIRC, there is a minimal increase in the root filesystem.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Veryl Ellis
Sent: Tuesday, August 8, 2017 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Secure FTP Question

Another question.

Any idea how much DASD space to allocate for the SMPNTS and/or SMPWKDIR ZFS 
files?
I seem to keep running out.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Tuesday, August 08, 2017 12:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Secure FTP Question

I agree, HTTPS is much easier to both implement and use.  IBM supplies the 
directions on every order in ShopZSeries (off on the right side).  I think they 
also tell you right in each shipment, but I could be wrong.

Brian

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

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


::DISCLAIMER::


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




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

Re: z/OS Secure FTP Question

[Carmen Vitullo]

my shopz zfs is 10,000 Cyl's 
SMPWRKDIR is a tfs for me 

MOUNT FILESYSTEM('TMPSMPWK') 
MOUNTPOINT('/SYST/usr/local/smpe/workdir') 
TYPE(TFS) /* Filesystem type TFS */ 
MODE(RDWR) /* Mounted for read/write */ 
PARM('-s 2147380171 -b 1') 


- Original Message -

From: "Veryl Ellis"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, August 8, 2017 10:46:51 AM 
Subject: Re: z/OS Secure FTP Question 

Another question. 

Any idea how much DASD space to allocate for the SMPNTS and/or SMPWKDIR ZFS 
files? 
I seem to keep running out. 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman 
Sent: Tuesday, August 08, 2017 12:48 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: z/OS Secure FTP Question 

I agree, HTTPS is much easier to both implement and use. IBM supplies the 
directions on every order in ShopZSeries (off on the right side). I think they 
also tell you right in each shipment, but I could be wrong. 

Brian 

-- 
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: z/OS Secure FTP Question

[Veryl Ellis]

Another question.

Any idea how much DASD space to allocate for the SMPNTS and/or SMPWKDIR ZFS 
files?
I seem to keep running out.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Tuesday, August 08, 2017 12:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Secure FTP Question

I agree, HTTPS is much easier to both implement and use.  IBM supplies the 
directions on every order in ShopZSeries (off on the right side).  I think they 
also tell you right in each shipment, but I could be wrong.

Brian

--
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: Need referral - Websphere script w/o passwords

[Linda Hagedorn]

Thank you.  I'll read up.

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

Re: How to find the Global zone names in SMP/E via REXX

[Paul Gilmartin]

On Tue, 8 Aug 2017 13:44:03 +, Nims,Alva John (Al) wrote:

>Does any of the CBT Tape REXX programs that access the SMP/e API do the job?
> 
I see no mention of an API for Rexx in the SMP/E User's Guide, Reference, or 
Commands.
Where is an API for Rexx documented?

-- gil

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

Re: Curse you, L-Soft!

[Paul Gilmartin]

(sent via web interface)
On Tue, 8 Aug 2017 01:45:22 -0500, Elardus Engelbrecht wrote:

>David W Noon wrote:
>
>>Sometimes Base64 or other binary-safe encoding is required by RFC.
>
>So I see. Thanks. Wish Shmuel is here, he certainly has something to say about 
>all these RFC requirements...
>
According to various experiments and headers of off-list messages:

MacOS Mail.app sends utf-8 as quoted-printable but deals corectly with
incoming 8-bit/

From one set of mail headers:
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

From another sent from Outlook/Windoze:
Content-Type: text/plain;
 charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

WTF!?  Why encode us-ascii?  7bit should suffice.  But every blank was encoded
as hex 20!?

A message I sent with mutt to IBM-MAIN; Cc: e...@univie.ac.at was reflected
by echo with an 8bit header so I assume that's what mutt uses. But IBM-MAIN
REPROed it as quoted-printable.  Still phobic of 8bit.

A "non-blank blank" might be either a nonbreaking space or an en-space.  8bit
utf-8 should suffice for those; no need for base64.

RFC 822 limits records to 999 bytes, give or take a .  Longer records
require some encoding.  But some MUAs, phobically, encode any message
containing records longer than 80 bytes.  I blame a desire to accommodate
antediluvian IBM conventions for this compulsion.

And encoding might be needed to protect a "From" message separator.  I
recall one MUA that encoded every "F" anywhere in a message as hex 46.
My first guess at its motivation was probably wrong.

-- gil

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

Re: How to find the Global zone names in SMP/E via REXX

[Lizette Koehler]

I will check those out closer.

Thanks

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nims,Alva John (Al)
> Sent: Tuesday, August 08, 2017 6:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How to find the Global zone names in SMP/E via REXX
> 
> Does any of the CBT Tape REXX programs that access the SMP/e API do the job?
> 
> Al Nims
> UFIT
> University of Florida
> (352) 273-1298
> @Home
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Monday, August 07, 2017 7:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How to find the Global zone names in SMP/E via REXX
> 
> I have a requirement to create a process that is dependent on knowing the
> TLIB/DLIB zone names from the Global CSI.
> 
> At this time, I do not see any type of ADDRESS SMPEXEC or other API process
> to do the extract.
> 
> So I am guessing I will need to run an SMPE Process to do a listzone then
> parse the output for the names I need.
> 
> Unless someone has an easier way to do this, this is the process I will take.
> 
> This process will eventually do a copyzone or mergezone.  Just trying to
> automate the process so the user does not need to tell the REXX that much
> information other than the GLOBAL CSI.
> 
> Any thoughts or suggestions are appreciated.
> 
> 
> Lizette Koehler
> statistics: A precise and logical method for stating a half-truth
> inaccurately
> 

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

Re: SVCDUMP consideration

[Lizette Koehler]

SVCDUMPs can go to SYS1.DUMPx or a dynamic allocation based on your settings in 
z/OS

Look at the mvs command for Dump Datasets (DD) for what your shop is using.

See this link:  
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieag100/dumpds.htm


SVC Dumps can contain as much or as little as specified.  Some products dump a 
large amount of control blocks (Think DB2) 

So just a few.

The Dump process has a Dataspace it dumps to.  So the process is fast.  Once 
the Dump goes to the dataspace, it is then dumped to your designated SVC Dump 
dataset

A quick search on the www.ibm.com for SVCDUMP DD pulls up this link

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieav100/seqdat.htm

It should be a good starting point.

How SVCDUMP behaves is going to be dependent on how you have it set up.  There 
is not a one size fits all process.

Lizette
 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: Tuesday, August 08, 2017 6:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SVCDUMP consideration
> 
> Hi
> 
> General questions. Since when we set SAD for zOS we keep that based on the
> size of Real storage.
> 
> When we are setting up an SVCDUMP for a particular product. How does that
> dumping takes place ? Is it only the control block occupied by the specific
> product ? Or it scans the entire RSM dedicated to the OS ?
> 
> On 08-Aug-2017 3:56 PM, "Elardus Engelbrecht" <
> elardus.engelbre...@sita.co.za> wrote:
> 
> > Jake Anderson wrote:
> >
> > >Is there any constraint when we are taking SVCDUMP ? Are there any
> > >CPU
> > spike due to SVCDUMP ?
> >
> > It depends. Sometimes you get a CPU spike or something slows down your
> > system. YMMV of course.
> >
> > It also depends on how the application or job is handling the dump itself.
> >
> >
> > >Generally what are the factors needs to be considered while taking
> > SVCDUMP ?
> >
> > Check Kees good reply to you. The command he gave is a good starting point.
> >
> > Also look in your PARMLIB to see how your DD and CD commands are setup.
> > These commands are usually in COMMNDxx or IEACMDxx.
> >
> > Depending on the dump, you may need to add the right DD statement to
> > your STC or job ___before__ taking a dump.
> >
> > Are you also going to set a SLIP?
> >
> > 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

Re: SVCDUMP consideration

[Jake Anderson]

Hi

General questions. Since when we set SAD for zOS we keep that based on the
size of Real storage.

When we are setting up an SVCDUMP for a particular product. How does that
dumping takes place ? Is it only the control block occupied by the specific
product ? Or it scans the entire RSM dedicated to the OS ?

On 08-Aug-2017 3:56 PM, "Elardus Engelbrecht" <
elardus.engelbre...@sita.co.za> wrote:

> Jake Anderson wrote:
>
> >Is there any constraint when we are taking SVCDUMP ? Are there any CPU
> spike due to SVCDUMP ?
>
> It depends. Sometimes you get a CPU spike or something slows down your
> system. YMMV of course.
>
> It also depends on how the application or job is handling the dump itself.
>
>
> >Generally what are the factors needs to be considered while taking
> SVCDUMP ?
>
> Check Kees good reply to you. The command he gave is a good starting point.
>
> Also look in your PARMLIB to see how your DD and CD commands are setup.
> These commands are usually in COMMNDxx or IEACMDxx.
>
> Depending on the dump, you may need to add the right DD statement to your
> STC or job ___before__ taking a dump.
>
> Are you also going to set a SLIP?
>
> 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
>

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

Re: How to find the Global zone names in SMP/E via REXX

[Nims,Alva John (Al)]

Does any of the CBT Tape REXX programs that access the SMP/e API do the job?

Al Nims
UFIT
University of Florida
(352) 273-1298
@Home

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, August 07, 2017 7:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to find the Global zone names in SMP/E via REXX

I have a requirement to create a process that is dependent on knowing the 
TLIB/DLIB zone names from the Global CSI.

At this time, I do not see any type of ADDRESS SMPEXEC or other API process to 
do the extract.

So I am guessing I will need to run an SMPE Process to do a listzone then parse 
the output for the names I need.

Unless someone has an easier way to do this, this is the process I will take.

This process will eventually do a copyzone or mergezone.  Just trying to 
automate the process so the user does not need to tell the REXX that much 
information other than the GLOBAL CSI.

Any thoughts or suggestions are appreciated.


Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

--
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; Various 052 abends with LINKAGE=SYSTEM calls in SRB

[Peter Relson]

0101: you did not show the rest of the expansion or the registers at the 
time of the error, or what the contents of the parameter area was.
This is basic diagnosis upon reading the reason for an abend that 
indicates that the problem is that reserved fields in a parameter area are 
non-zero.

LINKAGE=SYSTEM has nothing to do with SRB mode or task mode. A service 
documents in what dispatchable modes it may be invoked.

>Thanks that's what I thought

The odds are far better that you did not get this on the VSMLOC than that 
you overlaid the system function table.
But anything is possible.

Capture an SVC Dump and look at the system trace entries for the PC's and 
demonstrate that what you say happened did happen by showing the relevant 
trace entries and the actual code identified by the trace entries (since 
the trace entry will identify the address of the PC).

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: Various 052 abends with LINKAGE=SYSTEM calls in SRB

[Joseph Reichman]

It was primary mode I did a SAC 0
Right before the VSMLOC



> On Aug 8, 2017, at 3:01 AM, Binyamin Dissen  
> wrote:
> 
> On Mon, 7 Aug 2017 21:30:08 -0400 Jim Mulder  wrote:
> 
> :>It should not be possible to get a 052 abend from VSMLOC,
> :>unless some rogue code on your system has messed with the
> :>System Function Table so that the wrong PC number is being issued,
> :>or some rogue code on your system has messes with the Entry Table Entry 
> :>for the VSMLOC PC so that something other than the VSMLOC service
> :>routine is being invoked by the VSMLOC PC.
> 
> Or if a routine requiring primary mode is not called in primary mode?
> 
> :> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> :>Poughkeepsie NY
> 
> :>> From: Joe Reichman 
> :>> To: IBM-MAIN@LISTSERV.UA.EDU
> :>> Date: 08/07/2017 09:24 PM
> :>> Subject: Various 052 abends with LINKAGE=SYSTEM calls in SRB
> :>> Sent by: IBM Mainframe Discussion List 
> 
> :>> I am getting intermittent abends with a couple of macros that use
> :>> linkage=system in a SRB
> 
> :>> The first is with AXSET macro
> 
> :>> LAR2,1  Give us the  
> :>> AXSET AX=(R2)   Power  
> :>> XRR8,8  Clear r8  
> :>> ICM   R8,B'0011',NOW.HASID Get Server Asid 
> :>> SSAR  R8Set secondary Asid
> 
> :>> The reason code for the AXSET is 0101
> 
> :>> The Abends happens (sometimes) after the PC  0(14) call in the AXSET
> 
> :>> To other is in the VSMLOC macro again after the PC  0(14) The reason 
> :>code in
> :>> the VSMLOC is 0103
> 
> :>> From my understanding there is no restriction using LINKAGE=SYSTEM in a 
> :>SRB
> 
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
> 
> Director, Dissen Software, Bar & Grill - Israel
> 
> 
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
> 
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
> 
> --
> 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: SVCDUMP consideration

[Elardus Engelbrecht]

Jake Anderson wrote:

>Is there any constraint when we are taking SVCDUMP ? Are there any CPU spike 
>due to SVCDUMP ?

It depends. Sometimes you get a CPU spike or something slows down your system. 
YMMV of course.

It also depends on how the application or job is handling the dump itself.


>Generally what are the factors needs to be considered while taking SVCDUMP ?

Check Kees good reply to you. The command he gave is a good starting point.

Also look in your PARMLIB to see how your DD and CD commands are setup. These 
commands are usually in COMMNDxx or IEACMDxx.

Depending on the dump, you may need to add the right DD statement to your STC 
or job ___before__ taking a dump.

Are you also going to set a SLIP? 

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

Re: Various 052 abends with LINKAGE=SYSTEM calls in SRB

[Binyamin Dissen]

On Tue, 8 Aug 2017 04:18:55 -0400 Jim Mulder  wrote:

:>  No,  052 abends are issued by service routines for PCAUTH services.
:>VSMLOC is not a PCAUTH service. and its service routine does not
:>issue 052 abends.

Might the wrong addressing mode cause an incorrect PC number to be loaded?

:>Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
:>Poughkeepsie NY
:>
:>> From: Binyamin Dissen 
:>> To: IBM-MAIN@LISTSERV.UA.EDU
:>> Date: 08/08/2017 04:16 AM
:>> Subject: Re: Various 052 abends with LINKAGE=SYSTEM calls in SRB
:>> Sent by: IBM Mainframe Discussion List 
:>> 
:>> On Mon, 7 Aug 2017 21:30:08 -0400 Jim Mulder  wrote:
:>> 
:>> :>It should not be possible to get a 052 abend from VSMLOC,
:>> :>unless some rogue code on your system has messed with the
:>> :>System Function Table so that the wrong PC number is being issued,
:>> :>or some rogue code on your system has messes with the Entry Table 
:>Entry 
:>> :>for the VSMLOC PC so that something other than the VSMLOC service
:>> :>routine is being invoked by the VSMLOC PC.
:>> 
:>> Or if a routine requiring primary mode is not called in primary mode?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: SVCDUMP consideration

[Vernooij, Kees (ITOPT1) - KLM]

Have a look at the Q= SDUMP option, this specifies if the system will be 
quiesced while dumping common storage.
Command: D DUMP,O.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: 08 August, 2017 11:25
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SVCDUMP consideration
> 
> Hi
> 
> Is there any constraint when we are taking SVCDUMP ? Are there any CPU
> spike due to SVCDUMP ?
> 
> Generally what are the factors needs to be considered while taking
> SVCDUMP ?
> 
> Jake
> 
> --
> 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

SVCDUMP consideration

[Jake Anderson]

Hi

Is there any constraint when we are taking SVCDUMP ? Are there any CPU
spike due to SVCDUMP ?

Generally what are the factors needs to be considered while taking SVCDUMP ?

Jake

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

Re: Various 052 abends with LINKAGE=SYSTEM calls in SRB

[Jim Mulder]

  No,  052 abends are issued by service routines for PCAUTH services.
VSMLOC is not a PCAUTH service. and its service routine does not
issue 052 abends.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> From: Binyamin Dissen 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/08/2017 04:16 AM
> Subject: Re: Various 052 abends with LINKAGE=SYSTEM calls in SRB
> Sent by: IBM Mainframe Discussion List 
> 
> On Mon, 7 Aug 2017 21:30:08 -0400 Jim Mulder  wrote:
> 
> :>It should not be possible to get a 052 abend from VSMLOC,
> :>unless some rogue code on your system has messed with the
> :>System Function Table so that the wrong PC number is being issued,
> :>or some rogue code on your system has messes with the Entry Table 
Entry 
> :>for the VSMLOC PC so that something other than the VSMLOC service
> :>routine is being invoked by the VSMLOC PC.
> 
> Or if a routine requiring primary mode is not called in primary mode?



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

Re: Need referral - Websphere script w/o passwords

[Melich, Istvan]

Hi Linda,

Years ago I used soap.client.props for this, base64 decoded passwords are not 
so secure, but with strict file permissions (e.g. perm 660 or 640) this way 
might be acceptable. If you use wsadmin, it can be configured to use 
soap.client.props files for authentication purposes.

On Mon, Aug 07, 2017 at 05:59:20PM -0500, Linda Hagedorn wrote:
> This is regarding Websphere.  I've inherited a WAS platform with scripts 
> containing passwords in clear text.  I have to remediate this, and came to 
> ibm-main for advice.  This is on AIX.  I normally manage DB2 on Z, and just 
> accepted the WAS area.  
> 
> Can anyone refer me to a manual, Redbook, or best practice for options?  
> Encrypted pw file? System parm for NOPASSWORD?  Any information or referral 
> is appreciated.  Thanks, Linda
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

-- 
Thanks and regards: Melich, Istvan

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

Re: Various 052 abends with LINKAGE=SYSTEM calls in SRB

[Binyamin Dissen]

On Mon, 7 Aug 2017 21:30:08 -0400 Jim Mulder  wrote:

:>It should not be possible to get a 052 abend from VSMLOC,
:>unless some rogue code on your system has messed with the
:>System Function Table so that the wrong PC number is being issued,
:>or some rogue code on your system has messes with the Entry Table Entry 
:>for the VSMLOC PC so that something other than the VSMLOC service
:>routine is being invoked by the VSMLOC PC.

Or if a routine requiring primary mode is not called in primary mode?

:> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
:>Poughkeepsie NY

:>> From: Joe Reichman 
:>> To: IBM-MAIN@LISTSERV.UA.EDU
:>> Date: 08/07/2017 09:24 PM
:>> Subject: Various 052 abends with LINKAGE=SYSTEM calls in SRB
:>> Sent by: IBM Mainframe Discussion List 

:>> I am getting intermittent abends with a couple of macros that use
:>> linkage=system in a SRB

:>> The first is with AXSET macro
 
:>> LAR2,1  Give us the  
:>> AXSET AX=(R2)   Power  
:>> XRR8,8  Clear r8  
:>> ICM   R8,B'0011',NOW.HASID Get Server Asid 
:>> SSAR  R8Set secondary Asid
 
:>> The reason code for the AXSET is 0101
 
:>> The Abends happens (sometimes) after the PC  0(14) call in the AXSET
 
:>> To other is in the VSMLOC macro again after the PC  0(14) The reason 
:>code in
:>> the VSMLOC is 0103

:>> From my understanding there is no restriction using LINKAGE=SYSTEM in a 
:>SRB

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

z/OS Data Set Encryption Now Generally Available

[Timothy Sipples]

z/OS Data Set Encryption is a critical new security feature to help you
better protect sensitive data. It's a key ingredient in an overall, stepped
up enterprise privacy and data protection strategy. And, importantly, z/OS
Data Set Encryption does not require any application changes, so you can
press it into service right away

And "right away" means right away, because z/OS Data Set Encryption is
now generally available! To get started you'll need at least one LPAR or
z/VM guest running z/OS 2.2 with the PTF for APAR OA50569:

http://www.ibm.com/support/docview.wss?crawler=1=isg1OA50569

z/OS 2.3, right from the start, will include this support. Any z/OS 2.1
instances you have, with this PTF applied, will be able to read/write
encrypted data sets but will not be able to create them.

The official minimum machine requirement is an IBM z196 (or z114), or
higher. Newer models are better, of course, and the IBM z14 machines really
scream. Strictly speaking, Crypto Express features are not required, but
they are strongly recommended for production.

BSAM, QSAM, and VSAM extended format data sets are all supported. DB2
Version 11 and higher will be supported when the enabling PTFs are
available, very soon. IMS Database Version 13 and higher are supported now,
and no PTFs are required. WebSphere MQ Version 8 and above also support
z/OS data set encryption, also without PTFs.

For more information, please refer to this FAQ document:

https://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FQ131494


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: Curse you, L-Soft!

[Elardus Engelbrecht]

David W Noon wrote:

>Sometimes Base64 or other binary-safe encoding is required by RFC.

So I see. Thanks. Wish Shmuel is here, he certainly has something to say about 
all these RFC requirements...


>MTA = Mail Transfer Agent
>This is/are the SMTP server(s) used to move email around.
>Using a fully RFC-compliant MUA can cause many problems for those who use 
>"cowboy coded" MUAs.

>And to complete the email glossary:
>MUA = Mail User Agent (your mail reader)
>MDA = Mail Delivery Agent (the server from which your MUA downloads mail)

Thanks for your kind help and the list of those glossary. I'll ask my SMTP 
colleague about this.

Thanks again! Much appreciated.

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