Re: Scrubbing sensitive data in dumps

[Skeldum, William]

There was a patent filed by IBM on Locating and altering sensitive information 
in core dumps.
http://www.google.com.pg/patents/US20080126301
Bill Skeldum


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Holst, Jeffrey A
Sent: Friday, August 11, 2017 2:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Scrubbing sensitive data in dumps

A year or two ago I attended a webinar that was discussing (selling) a product 
that would scrub sensitive information (generally PII) from dumps (SVC dumps, 
SYSMDUMPs and the like) prior to sending these to a software vendor.

I told my management about it, and there was no interest, so I didn't retain 
any information on it.

Fast forward to today. My manager calls me up and asks if I know of any 
products that can scrub sensitive information from dumps. My response was that 
I had attended a webinar on one. I was asked what the product was and who the 
vendor might be, and I could not recall and I didn't have anything saved.

Does anyone know of such a product? I know there is one out there but I haven't 
figured out a search argument to locate it yet.

Jeffrey Holst
Infrastructure Configuration Consultant
Technology and Operations, Shared Services

PNC Bank
Columbus Whitehall Service Center 2
4653 E Main St
Columbus, OH 43213
(614) 856-5443
jeffrey.ho...@pnc.com




The contents of this email are the property of PNC. If it was not addressed to 
you, you have no legal right to read it. If you think you received it in error, 
please notify the sender. Do not forward or copy without permission of the 
sender. This message may be considered a commercial electronic message under 
Canadian law or this message may contain an advertisement of a product or 
service and thus may constitute a commercial electronic mail message under US 
law. You may unsubscribe at any time from receiving commercial electronic 
messages from PNC at http://pages.e.pnc.com/globalunsub/
PNC, 249 Fifth Avenue, Pittsburgh, PA 15222; pnc.com




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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: Logstreams

[Skeldum, William]

We use logstreams, including for logrec and do not have any SYS1.LOGREC 
datasets defined.  Our IEASYSxx parmlib specifies LOGREC=LOGSTREAM.  We have no 
issues IPLing.  Early in the IPL we receive message:
IFB085I LOGREC RECORDING TO LOG STREAM SYSPLEX.LOGREC.ALLRECS
Bill Skeldum

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Wilkie
Sent: Thursday, June 29, 2017 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

Thanks, and yes, It does fail without sys1.logrec.


I can't believe the system can't come up without LOGREC. I would think it 
should issue messages but at least let you IPL.  Once you're up you can 
allocate a new one.  Maybe Z/os could even dynamically allocate one and just 
keep going.


From what I can gather so far about Logstreams, it just holds a bunch of 
different logs like Operlog, LOGREC, etc. but the data is still in it's 
original form as if it were read directly from the original data set.


Bill



From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Thursday, June 29, 2017 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

Logstream cannot substitute for the LOGREC data set at IPL, which others 
suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. It 
is however named in IEASYSxx, where we have coded 
LOGREC=SYS1.LOGREC.$SYS ever since we moved to sysplex in the mid-90s. 
I cannot recall trying to IPL without LOGREC, but I imagine it would fail.

There are good reasons for moving to logstream, but the ability to IPL is not 
one of them.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, June 29, 2017 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Logstreams

So does this mean the problem you are trying to solve by asking about 
logstreams is

Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC?  Will 
the logstream still allow me to IPL eve if SYS1.LOGREC is gone?

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 5:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> Lizette:
>
>
> I am not using logstreams yet. I am just looking into it.
>
>
> The SYS1.LOGREC data set got deleted on our test system so we couldn't
> IPL it. We ran a job from our other system to create a new one and it IPL'd 
> OK.
>
>
> Thanks
>
> Bill
>
>
> 
> From: IBM Mainframe Discussion List  on
> behalf of Lizette Koehler 
> Sent: Thursday, June 29, 2017 12:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> When you say you deleted a logstream - which one?
>
> If it is for Logrec, did you have the SYS1.LOGREC dataset still
> cataloged and on the system?
>
> What was the corrective action that allowed you to IPL
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie
> > Sent: Thursday, June 29, 2017 2:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > We accidentally deleted Logrec on one system, and couldn't IPL. Not
> > sure if logstream being available would have made a difference.
> >
> >
> > Bill
> >


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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: Domino vs. Apache Web Server and Encoding Issue from CGI Program

[Skeldum, William]

Yes z/OS 2.2 now includes Apache in place of Domino.
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.e0zm100/IHS_V2R2_RemoveDomino.htm
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lindy Mayfield
Sent: Monday, January 30, 2017 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Domino vs. Apache Web Server and Encoding Issue from CGI Program

Hi group,

Did something change from z/OS 2.1 to 2.2 specifically that would mean that the 
Domino web server changed to the Apache web server?  Has anyone experienced 
this with their upgrade?

More specifically to my problem,  has anyone experience with going from Domino 
to Apache, and encountered issues with the encoding used by cgi applications 
and had to fix them?  I don’t mean something like 1143 vs. 1047 encoding, but 
ebcdic vs. asciii.  What once returned from a call, for example, “Hello world”, 
now looks something like “çè(<žŽ çá àžŽ”. ☺

I’ve no idea which end to look at first on this, at the app or at the server 
configuration, which is why I ask.  Also, I don’t know how big a change Domino 
is to Apache is, if it was meant to be a plug-and-play replacement or not.

Many thanks for any help or advice.

Kind regards,
Lindy Mayfield


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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: ASG Zeke and time change

[Skeldum, William]

We use Zeke and have TZ=MST7MDT coded in the ENVIRON file.  I agree with 
Charles, no need to change it for the time change.  We do not cycle Zeke, IPL, 
or anything.  At 2:00 AM MDT Sunday morning the clock will revert to 1:00 AM 
MST.
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, November 04, 2016 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASG Zeke and time change

I know nada about Zeke but you should not have to change the TZ specification 
(generally -- again I know nada about Zeke specifically). CST6CDT says 
(simplifying the details here) that your winter offset is UTC-6 and your summer 
offset is UTC-5.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Friday, November 04, 2016 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ASG Zeke and time change

In Zeke there is an ENVIRON file that contains.



* TZ:

*   Time zone.  See your IBM Language Environment Customization

*   documentation for more information on how to set your time zone.

*TZ=CST5CDT  *

* spring is 5; fall is 6

* TZ=CST5CDT



This customer is in the Central Time Zone.

So for the time change it needs to be updated to TZ=CST6CDT



My question is –

When can I update this file?  Can I do it now and it will be picked up on the 
next IPL?  Or does Zeke look at this file all the time and I would have to wait 
until Zeke is taken down before the IPL?



Thank you to anyone with Zeke experience.


--
The postings on this site are my own and don’t necessarily represent Mainline’s 
positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: RACF99

[Skeldum, William]

This site lists a RACF99 utility for certificates.
http://www.nigelpentland.co.uk/readme.htm
Bill Skeldum

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, June 01, 2016 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF99

I know that this question should go to RACF-L, but I cannot seem to get their 
email posts into my inbox. I've been asked to pursue the 'RACF99 utility' to 
query the status of certificates. I've Googled the heck out of that name but 
cannot find any official (IBM) doc. Could someone point me in the right 
direction? Thanks.

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


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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: rsync anyone?

[Skeldum, William]

The pax command is a good choice because it can copy all files, directories, 
and symbolic links in a directory using a single command without overlaying any 
existing files.   For example:
cd /Service/ZOS113/var
pax -rvwk -pe * /var
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hansen, Dave L - Eagan, MN
Sent: Monday, December 28, 2015 10:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: rsync anyone?

Hi,  I have been working with IBM to identify how to move a USS directory that 
has files and subdirectories to a different LPAR.  They said Ported Tools and 
the scp command.  However, OpenSSH has had security issues IIRC.  The other 
thing they mentioned was to port rsync over to z/OS.  I also have directions on 
how to voice this as a requirement to USS development using the RFE process.

Q).  Does anyone have a better way to move a directory that has files and 
subdirectories to a different LPAR?  Or do you just keep installing the same 
code for each instance?

Q).  Is anyone requesting rsync for z/OS via RFE or working on a port for 
rsync?  We do not have shared DASD and need something.


  Thank you,  Dave

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: rsync anyone?

[Skeldum, William]

Gil,
Thanks for the correction.  I was thinking if he was doing a one-time move he 
could mount a filesystem on the originating LPAR, do the pax command, dismount, 
and then mount again on the receiving LPAR.  Cumbersome, but works for a one 
time move.
If it is going to be an ongoing process then I'm sure Dave would desire a 
better solution.
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, December 28, 2015 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: rsync anyone?

On Mon, 28 Dec 2015 18:12:05 +, Skeldum, William wrote:

>The pax command is a good choice because it can copy all files, directories, 
>and symbolic links in a directory using a single command without overlaying 
>any existing files.   For example:
>cd /Service/ZOS113/var
>pax -rvwk -pe * /var
>
For rsync-like behavior, one often wants to overwrite older files and preserve 
newer.
For this, "-u" may be a better choice than "-k".

... and your command moves files only within an LPAR.  Across LPARs, you need 
something such as:

ssh other-LPAR "pax -w bin" |  # (Yes, the dreaded "ssh".)
pax -rvu

-- gil



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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: IBM's PDUU utility

[Skeldum, William]

I have been using the PDUU for quite some time now and love it.  Most of my use 
has been to upload problem data for DFHSM, but have worked with other groups 
also.
Bill Skeldum

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, October 20, 2015 7:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM's PDUU utility

Thanks Chris, that's good to hear.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering 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 Chris Hoelscher
Sent: Tuesday, October 20, 2015 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM's PDUU utility

Back in 2013 - we encountered a major problem in DB2 - IBM strongly requested 
(required?) that we use the PDUU utility to send them dump or test output


//FTP EXEC PGM=AMAPDUPL
//SYSUDUMP DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=dump input
//SYSINDD  *
USERID=anonymous
PASSWORD=my email address
TARGET_SYS=testcase.boulder.ibm.com
TARGET_DSN=the remote file name
WORK_DSN=a valid temp dsn
CC_FTP=05
WORK_DSN_SIZE=5000
DIRECTORY=/toibm/im/
PMR=38836.082.000


Chris Hoelscher
Technology Architect, Database Infrastructure Services Technology Solution 
Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538


The information transmitted is intended only for the person or entity to which 
it is addressed and may contain CONFIDENTIAL material.  If you receive this 
material/information in error, please contact the sender and delete or destroy 
the material/information.

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

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: Aliases (was: z/OS 2.2 announcement)

[Skeldum, William]

 Must a symbol replace an entire qualifier, or part of one, such as

  SYMBOLICRELATE(TEST.JNULL.CL.CNTL)?

The symbol can replace part of a qualifier as in your example:

DEFINE ALIAS (NAME(TEST.NEWER.JCL.CNTL) SYMBOLICRELATE(TEST.JNULL.CL.CNTL))

Referencing TEST.NEWER.JCL.CNTL translates to TEST.JCL.CNTL.

 Is the SYMBOLICRELATE name limited to 44 characters before substitution, or 
 only after substitution?

It is limited to 44 characters before substitution:

DEFINE ALIAS (NAME(TEST.NEWER.JCL.CNTL) -

 SYMBOLICRELATE( -

   TEST.SOME.DATASET.NULL.NAME.LONGER.THAN.FORTY4))

IDC3201I CONSTANT 'TEST.SOME.DATASET.' EXCEEDS LENGTH LIMIT

IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS 12



Bill



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, July 29, 2015 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Aliases (was: z/OS 2.2 announcement)



On 2015-07-29, at 09:59, Skeldum, William wrote:



 A symbolic symbol can be defined as: 'NULL='.

 I then defined an alias as follows:

 DEFINE ALIAS (NAME(TEST.NEW.JCL.CNTL)

 SYMBOLICRELATE(TEST.NULL.JCL.CNTL))

 When I reference TEST.NEW.JCL.CNTL in DSLIST (ISPF 3.4) TEST.JCL.CNTL is 
 displayed.



Thanks for the research.  I haven't the entitlement to create a symbolic symbol 
in my systemic system.



Yaaay!



o Hmmm... That ought to be a standard feature, just like DSN NULLFILE.

  (Does NULLFILE appear in a catalog?)



o Nice: it swallows the terminating . so you don't get TEST..JCL.CNTL.



o Must a symbol replace an entire qualifier, or part of one, such as

  SYMBOLICRELATE(TEST.JNULL.CL.CNTL)?



o Is the SYMBOLICRELATE name limited to 44 characters before substitution,

  or only after substitution?



-- gil



--

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: Aliases (was: z/OS 2.2 announcement)

[Skeldum, William]

A symbolic symbol can be defined as: 'NULL='.
I then defined an alias as follows:
DEFINE ALIAS (NAME(TEST.NEW.JCL.CNTL)  SYMBOLICRELATE(TEST.NULL.JCL.CNTL))
When I reference TEST.NEW.JCL.CNTL in DSLIST (ISPF 3.4) TEST.JCL.CNTL is 
displayed.
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, July 29, 2015 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Aliases (was: z/OS 2.2 announcement)

On Wed, 29 Jul 2015 14:38:50 +, Staller, Allan wrote:
...
Once *EVERYTHING has moved to the alias, the original dataset can be deleted 
and the process repeated in the other direction.
This make take several (days, weeks, months,) depending on the 
installations policies and procedures.
...
Merely re-point the existing alias to the new dataset. No problem here.

Is there a utility to enumerate all ALIASes to a given RELATED DSN?  If not,
there's a problem.The information must exist: if the RELATED DSN is
deleted, the ALIASes are quietly deleted.  Integrity flaw: deleting a DSN when 
ALIASes exist ought at least to require confirmation.

There's a minuscule timing window.

SYMBOLIC aliases would be better; they persist when the referenced data set is 
deleted.  But a SYMBOLIC alias must contain at least one substitutable symbol.  
Stupid rule!  (Might one define a system symbol naming the null string, for 
incorporation in SYMBOLIC aliases?)

-- gil

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: SMP/E question

[Skeldum, William]

It would be a manual process and would take a while, but you could go through 
the program directory for each product.
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Juergen Kehr
Sent: Wednesday, July 22, 2015 12:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E question

Thanks for your reply, but LIST FORFMID(...) doesn't do the job. AFAIK it's 
because DDDEFs are not directly assigned to FMIDs like SYSMOD (for example PTF) 
entries. So LIST FORFMID(...) does not list any DDDEF related information.

The only idea I had was, to walk thru the CSI starting with an FMID, listing 
its components, looking for SYSLIB (for MOD entries you first have to identify 
the LMOD entry), the SYSLIB gives you the name of the DDDEF involved. But 
that's a fairly complicate way to check the used DDDEFs.

Regards
Juergen

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: NO response to java -version

[Skeldum, William]

Try putting a ./ in front of the command to tell it to look in the current 
directory:

$ cd /usr/lpp/java/J7.0/bin

$ java -cp . -version

java: FSUM7351 not found

$ ./java -cp . -version

java version 1.7.0

Java(TM) SE Runtime Environment (build pmz3170sr6fp1-20140108_01(SR6 FP1))

IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390-31 20140106_181350 (JIT enabled, AOT 
enabled)

J9VM - R26_Java726_SR6_20140106_1601_B181350

JIT  - r11.b05_20131003_47443.02

GC   - R26_Java726_SR6_20140106_1601_B181350

J9CL - 20140106_181350)

JCL - 20140103_01 based on Oracle 7u51-b11

$



Although if the path is indeed in your path statement you shouldn’t need the ./ 
at the beginning.

Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barkow, Eileen
Sent: Friday, February 06, 2015 11:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NO response to java -version



I  had this problem a while ago with an older version of java that was going 
out to TCP/IP when trying to get the version number.

There was something wrong with TCP/IP on the sysprog test lpar at the time and 
it looked like java was hanging.

But newer releases of java did away with the TCP/IP access.



-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bonno, Tuco

Sent: Friday, February 06, 2015 1:53 PM

To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU

Subject: NO response to java -version



cross-posting to ibm-main, mvs-oe

i'm in z/os 1.13



located in  /usr/lpp/java/bin

when i issue  ls –la

i can see that the executable java is there



when i issue a printenv PATH i get this:

.:bin:/usr/lpp/java/bin:/usr/sbin:/



again located in /usr/lpp/java/bin

at the prompt i issue

(the fully qualifed path name is on purpose here):

/usr/lpp/java/bin/java  java –version

and i never get any meaningful response i.e, i never get the  ... java(tm) SE 
runtime environment blah blah blah stuff in stead, brhc of the screen shows 
running and then input and then 

nothing; just sits there forever in input mode



i've even tried this

/usr/lpp/java/bin/java  java –cp .  –version with no different outcome



what's wrong here?



thanks in advance

/s/ tuco bonno;

graduate, college of conflict management; University of Southeast Asia; I 
partied on the Ho Chi Minh trail; tiến lên !! 



--

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



--

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: Boston - what a place

[Skeldum, William]

I'm originally from North Dakota and experienced -41F in the winter and 108F in 
the summer.  I finally had enough of that and moved to Colorado 18 years ago.
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Monday, January 12, 2015 9:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Boston - what a place

In Illinois, we get 0F every winter and 100F most summers.  -20F a few times, I 
don't think I've experienced 110F.

On Mon, Jan 12, 2015 at 8:04 AM, Bob Shannon bshan...@rocketsoftware.com 
wrote:
 When I was in Boston in August and walked up to Fenway, it was bloody hot. I 
 mean seriously hot. And the footy was just played in sub-zero.

 I live outside of Boston and am used to it (and the sub-zero would have 
 been wind chill, not temperature). When we lived in Minnesota in the 
 mid-1990s my mother visited twice. The first time it was -15F and the second 
 time +95F. That's a 110 degree difference. She couldn't believe it.

 Bob Shannon
 Rocket Software
 
 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial
 Email – unsubscr...@rocketsoftware.com Manage Your Subscription
 Preferences -
 http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter
 _SubscriptionCenter.html Privacy Policy -
 http://www.rocketsoftware.com/company/legal/privacy-policy
 

 This communication and any attachments may contain confidential information 
 of Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
 prohibited. If you are not the intended recipient, please notify Rocket 
 Software immediately and destroy all copies of this communication. Thank you.

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



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

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: ShopzSeries problems?

[Skeldum, William]

Our nightly job to download PTFs also failed last night.

GIM69207S ** THE CONNECTION WITH THE SERVER FAILED. java.net.ConnectException:
 EDC8128I Connection refused.

HTTP Server Error: 502 Bad Gateway
Connection attempt: 60, WAIT time remaining: 1 minute.
Will retry connection to the order server in 1 minute.
Connection failed.
Connection attempt: 61, WAIT time remaining: 0 minutes.

smpeCC:10 smpeRoutine:GIMJVREQ smpeMsgLen:55 smpeMsg:java.net.ConnectExc
eption: EDC8128I Connection refused.

Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roger Mihay
Sent: Wednesday, November 26, 2014 6:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ShopzSeries problems?

I also am having a problem with downloads from ShopzSeries.  I wasn't on 
IBM-MAIN yesterday.  I started a PMR yesterday afternoon and got this relpy:

There was an issue reported that was making that message appear.
The internal teams have been working over the issue and it should be fixed by 
now.

Could you please help us out by trying to download your order once again?

I've checked your ID and I was able to get to the download link of your
order:

But today all I get is the page stating:

*The page you requested cannot be displayed* .



On Wed, Nov 26, 2014 at 4:20 AM, Richards, Robert B.  robert.richa...@opm.gov 
wrote:

 Thanks for confirming it ain't just me! :-)


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Jousma, David
 Sent: Wednesday, November 26, 2014 7:19 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: ShopzSeries problems?

 Ok, getting a little further, site is really slow.

 And then I get the same error as you:

 ERROR: SHP0003E: An unexpected error occurred. Please try again later.
 If the problem persists, please contact us (visit our Customer Service
 page for contact information).

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




 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

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: What are STC, JOB and TSU?

[Skeldum, William]

I think it is Started Task Control.

Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zMan
Sent: Thursday, November 20, 2014 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What are STC, JOB and TSU?

Any guesses what STC *means*? Started TasC?

On Thu, Nov 20, 2014 at 12:07 PM, Peter Hunkeler p...@gmx.ch wrote:

 We run APPC/ASCH. Here's what I see in SDSF. APPC and ASCH have no
 JES
 jobid. (Excuse the spacing; I can't seem to set the font in this
 note.)

 JOBNAME  Sys StepName JobIDASIDX
 APPC XX  APPC  0049
 ASCH XX  ASCH  004E
 ASCHINT  XX  ASCHINT  STC00503 0061




 APPC and ASCH are the system address spaces for APPC, ASCHINts are the
 initiator ASs analoguous to JES initiators seen as INIT. Both show up
 as STC when idle. JES Inits show up as Jnnn with the current
 jobname when a job is running inside. ASCHINTs probably show up as
 Annn (with what
 jobname) when an APPC transaction is running inside.


 --
 Peter Hunkeler



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




--
zMan -- I've got a mainframe and I'm not afraid to use it

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: RECEIVE ORDER server problems?

[Skeldum, William]

I have been having the issue with GIM6931I and timeouts intermittently for the 
past couple weeks.  I have a daily scheduled job that receives holddata and 
critical PTFs with steps for z/OS, CICS, IMS, etc.  Usually most of the steps 
work with only one that times out, and not the same step every time.

Bill Skeldum

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chase, John
Sent: Friday, August 01, 2014 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RECEIVE ORDER server problems?

I'm the OP, and that RECEIVE ORDER job timed out at 120 minutes.  I 
resubmitted, and the new job just wrote the 60-minute wait message.

-jc-

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Chris Hoelscher
 Sent: Friday, August 01, 2014 2:06 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: RECEIVE ORDER server problems?

 I am running a holddata receive - I have gotten GIM693I at the 15 and
 30 minute marks - so yes - the OP is not the only one

 Chris hoelscher
 Technology Architect | Database Infrastructure Services Technology
 Solution Services

 123 East Main Street |Louisville, KY 40202 choelsc...@humana.com
 Humana.com
 (502) 476-2538 - office
 (502) 714-8615 - blackberry
 Keeping CAS and Metavance safe for all HUMANAty


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Chase, John
 Sent: Friday, August 01, 2014 1:20 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: [IBM-MAIN] RECEIVE ORDER server problems?

  -Original Message-
  From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B.
 
  John,
 
  I have had three orders today, the last at 10:25am. No GIM693I issues.

 Likewise, an earlier order took all of three minutes.  Current job
 just posted the 75-minute wait message.

-jc-

 **
 Information contained in this e-mail message and in any attachments
 thereto is confidential. If you are not the intended recipient, please
 destroy this message, delete any copies held on your systems, notify
 the sender immediately, and refrain from using or disclosing all or any part 
 of its content to any other person.

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

 The information transmitted is intended only for the person or entity
 to which it is addressed and may contain CONFIDENTIAL material.  If
 you receive this material/information in error, please contact the sender and 
 delete or destroy the material/information.

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: Fixcat and/or PSP Buckets?

[Skeldum, William]

When I expand fixcat IBM.DEVICE,TAPE in my SMPE environment I see the following:
IBM.Device.Tape.TS3500-TapeLibrary-3584
IBM.Device.Tape.TS7700-3957

If you regularly receive holddata (we do it daily) you should be covered.

Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Staller, Allan
Sent: Wednesday, May 28, 2014 8:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fixcat and/or PSP Buckets?

Have no clue. I have always used the PSP buckets and not the FIXCAT info..

snip
Maybe the question really is, what is the difference between fixcat 
(IBM.DEVICE.TAPE.*) and UPGRADE3957DEVICE?
/snip


snip
Search IBM LINK for UPDGRADEDEVICE, Where XXX is the official machine 
type.

E.G. Z/10 BC is d/T 2098 so the search would be for UPGRADE2098DEVICE

HTH,
snip
We may be getting an IBM TS7720 grid and a TS3500 library frame. I ran a fixcat 
report using IBM.DEVICE.TAPE.* to see if there are any PTF's I should put on. 
There were about 9 PTF's that showed up in the report. We are running zos1.13 
on a z10bc-2098

Browsing the TS7700 customer information center it mentions 'refer to PSP 
bucket planning' for the list of applicable maintenance.

Does Fixcat (IBM.DEVICE.TAPE.*) cover all the bases or do I have to be 
concerned with PSP buckets also?

/snip

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: Emulator Screen Size with Attachmate Extra X-treme 9.3

[Skeldum, William]

I am using 80 x 160 which is 12,800 bytes.  I am using Vista Tn3270 by Tom 
Brennan.

Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of George, William@FTB
Sent: Friday, April 11, 2014 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Emulator Screen Size with Attachmate Extra X-treme 9.3

Thanks Peter!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, April 11, 2014 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Emulator Screen Size with Attachmate Extra X-treme 9.3

From a VTAM logon screen, this works for any screen size you can implement in 
your emulator, though I believe there is a limitation of maximum bytes per 
screen = 8192 (60 x 132 = 8184 bytes):

logon applid=TSO,logmode=D4C32XX3

That logmode is supplied by IBM by default unless your VTAM network 
administrator has deleted it.

If you have Netview Access or some other terminal distributor or interface this 
logmode may or may not be available to you.  I only know that it works from a 
VTAM logon screen.

Can't help with your Attachmate issue though, sorry.

HTH

Peter

__
CONFIDENTIALITY NOTICE: This email from the State of California is for the sole 
use of the intended recipient and may contain confidential and privileged 
information. Any unauthorized review or use, including disclosure or 
distribution, is prohibited. If you are not the intended recipient, please 
contact the sender and destroy all copies of this email.

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: APF authorization and JOBLIB DD card

[Skeldum, William]

I just ran a test, and if a STEPLIB is present JOBLIB is definitely ignored.  
This works:
//XYZ002 JOB 'BILL SKELDUM',MSGCLASS=H,CLASS=A,NOTIFY=SYSUID
//JOBLIB  DDDISP=SHR,DSN=XYZ.LOADLIB
//STEP1   EXEC  PGM=HELLO

This gets an 806 abend:
//wyz002 JOB 'BILL SKELDUM',MSGCLASS=H,CLASS=A,NOTIFY=SYSUID
//JOBLIB  DDDISP=SHR,DSN=XYZ.LOADLIB
//STEP1   EXEC  PGM=HELLO
//STEPLIB DDDISP=SHR,DSN=SYSX.LPAR.LOADLIB

The HELLO module resides in XYZ.LOADLIB.

Bill Skeldum


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, December 20, 2013 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: APF authorization and JOBLIB DD card

And the other question is

If I have a STEPLIB and a JOBLIB and the module I need is only in the JOBLIB, 
would not the step with the STEPLIB looking for that module fail?

//JOBLIB DD DSN=MYLOAD.LIB,DISP=SHR  Module XYZ resides here
//S1   EXEC  PGM=XYZ
//STEPLIB DD DISP=SHR,DSN=APPL.LIB  Module XYZ does not exist in
this library


Would not S1 then abend with a S806 due to the JOBLIB being ignored?

My understanding has been that if you code a JOBLIB any module not found in the 
STEPLIB would then search the JOBLIB and hopefully not fail.  This would also 
allow for testing a new version without having to alter JCL by swapping load 
libraries on JOBLIB and STEPLIB.  I could have the production version of the 
module in JOBLIB and a testing version in the STEPLIB.  If it is bad, I delete 
the version in STEPLIB and the job will find it in the JOBLIB.

That as soon as the module was found, then no more searching no matter where it 
was found.

So if it is in the STEPLIB, then searching stops If it is found in the JOBLIB 
then searching stops If it is found in the JPA, then searching stops.

So perhaps the intent is not that the JOBLIB is ignored. But that searching 
stops if the module is found in the STEPLIB



Lizette



 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of John Gilmore
 Sent: Friday, December 20, 2013 7:34 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: APF authorization and JOBLIB DD card

 The last time I looked at the text Lizette quotes was a long time ago,
 and
its current
 version contains the subtext

 begin extract from extract
 The directory is located on DASD with the data set, and is updated
whenever the
 module is changed. The directory entry contains information about the
module and
 where it is located in storage.
 /end extract from extract

 which is at best misleading.  The data-set directory contains no
information about
 where in virtual or real storage any copy of a member may have been
 loaded
and
 no indicator that it is currently resident.  The phrase 'in storage'
should replaced by
 'in the data set'.

 John Gilmore, Ashland, MA 01721 - USA

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: Deinstall software, for example BDT

[Skeldum, William]

In the past I've written a function sysmod that deletes the FMID(s) I want to 
delete (DELETE operand on ++VER).  I have not had to do this for a long, so 
there may be a newer/better way.

Bill Skeldum
Systems Programmer
303-231-2561

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Miklos Szigetvari
Sent: Tuesday, December 17, 2013 7:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deinstall software, for example BDT

 Hi

How would you deinstall (if it is the proper expression) software, for 
example BDT (Bulk Data Transfer) ?

--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new 
extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally binding. 
Unauthorised use, publication, reproduction or disclosure of the content of 
this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts no 
responsibility for malicious or inappropriate content.
---

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: Lookat

[Skeldum, William]

IEC036I is the entire message.  If you want to use just IEC036 use a wildcard 
such as IEC036*.

I don't use Lookat too much so I don't know if this is new behavior.

Bill Skeldum

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, December 13, 2013 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lookat

That Lookat web page may be there but it is not working very well.  A search 
for message IEC036 generated this result:

Message id IEC036 was not found.

Ensure the message id is complete/correct.

It is possible this message id is documented in a book that is not yet 
LookAt-enabled. You might try a newer release.

You may use LookAt feedback to inform IBM.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gonzalo Cengotita
Sent: Friday, December 13, 2013 8:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lookat

I'm using http://www-03.ibm.com/systems/z/os/zos/bkserv/lookat/ and it's 
working at this moment


2013/12/13 Staller, Allan allan.stal...@kbmg.com

 What URL are you using.

 I used www.ibm.com/systems/z/os/zos/bkserv/lookat/
 And got re-directed to
 http://www-03.ibm.com/systems/z/os/zos/library/bkserv/index.html

 which *IS NOT* the LOOKAT I was expecting.

 ???

 snip
 I just tried it ! Lookat is back !! Now that's what I call good news.
 /snip
--

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: When should we ACCEPT DB2 PTFs?

[Skeldum, William]

Use NOPURGE in the global zone options member to not delete the PTFs when they 
are accepted (if that's what is desired).  A cross zone query can be done to 
see if a resolving PTF for an APAR has been applied.  Just replace the first 
character of the APAR number with an 'A'.In your example PMx would 
become AMx.  If a superseding PTF has been replied it will show SUP.

Bill Skeldum


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Hoelscher
Sent: Tuesday, December 03, 2013 8:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: When should we ACCEPT DB2 PTFs?

I NEVER accept PTFS - but for an entirely different reason

I like to build meaningful reports as to what has been applied - when applied, 
the corresponding APAR#, a description, is it hiper? The RSU to which it 
belongs, and the owning product affected by the PTF

To build this report - I run a LISTMCS to create a ptf/apar xref - BUT 
ACCEPTING the ptf removes entry from the MCS (when I ACCEPTED the FMIDs at 
instell time, I first captured the apar/ptf xref for the ptfs that were bundled 
with the install - otherwise - after our semi-annual RSU apply (we are limited 
in how often we can apply proactive maint) - I run my report - but ACCEPTING 
PTFS would limit the effectiveness of my report - I am amazed how often I get a 
call - do we have PMx installed? To save a trip the IBM website - the xref 
comes in handy


Chris hoelscher
Technology Architect | Database Infrastructure Services Technology Solution 
Services

123 East Main Street |Louisville, KY 40202 choelsc...@humana.com Humana.com
(502) 476-2538 - office
(502) 714-8615 - blackberry
Keeping CAS and Metavance safe for all HUMANAty


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel C. Ewing
Sent: Saturday, November 23, 2013 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] When should we ACCEPT DB2 PTFs?

I can't recall ever seeing such an ACCEPT recommendation from IBM, probably 
because your own installation maintenance practices play such a major role here.

The only reason for not ACCEPTing PTFs (USERMODS and APAR fixes should 
typically never be accepted) is because you might need to RESTORE a PTF; but if 
you have been successfully running with a PTF installed for months, it is 
highly unlikely you would ever need to RESTORE it, and even if some subsequent 
error HOLD was placed on the PTF, if it is not an issue that has caused 
problems in your environment it is just as likely that a resolving PTF will 
become available allowing you to go forward in maintenance rather than having 
to back out the PTF.  I have even had a few rare cases where I have bypassed an 
ERROR HOLD to force an ACCEPT of a PTF and clean up a zone when the nature of 
the error HOLD was such that it would clearly never be an issue for us.

The most likely point at which you might actually need to do a RESTORE would be 
shortly after another mass APPLY of PTF's (not just any next APPLY).  Failure 
to ACCEPT previous mass maintenance for PTFs already running in production 
sometime before doing the next mass APPLY means any RESTORE after that point is 
likely to also force a back out of PTFs with which you have been successfully 
running for months.  I would expect this to add unnecessary risk by placing 
your system in configurations further at variance from those with which IBM and 
others (including your own installation) have done rigorous RSU-level testing.
Joel C. Ewing

On 11/22/2013 05:30 PM, Mike Schwab wrote:
 How about not until IBM tells you to?  As in you must accept 
 before apply this PTF?

 On Fri, Nov 22, 2013 at 8:40 AM, Staller, Allan allan.stal...@kbmg.com 
 wrote:
 IMO, the short answer is just before the next APPLY.

 HTH,




--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org

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

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain CONFIDENTIAL material.  If you receive this 
material/information in error, please contact the sender and delete or destroy 
the material/information.

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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified