SHARE Nearly Sold Out - Move Quickly NOW or Forever Hold Your Peace

[Ed Jaffe]

If you are considering attending SHARE in San Jose, you'd better move 
quickly. Just received this 1/2 an hour ago:




Marriott is completely sold out.

Hilton is completely sold out of standard rooms and only has Executive 
Level rooms left and the SHARE rate does not apply to those.


Hyatt the additional 20 rooms they gave us are completely sold out (that 
is 40 rooms sold out at this location) and they were able to give us 
another 15 and those are nearly gone.  They have no more to give us.


Westin has agreed to give us a courtesy block with 20 rooms and I signed 
the contract for that today and this now shows as available on the 
website.  They have no more rooms to give us once these are gone.




--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Program now working, but why?

[Bill Woodger]

"Thank Steve, I only mentioned it because Bill had discounted the idea and I 
was pleased with your confirmation it was possible. 
 
:) "

"Discounted" for a reason. The AMBLIST outputs were compared. AMODE is in the 
heading. I'd be more than mildly surprised if the OS/VS COBOL program with an 
Assembler program last assembled in 1989 has an AMODE other than 24. With an 
AMODE of 24, how could you possibly get 31-bit-addressed IO areas from a COBOL 
program? 

On the available evidence, and subject to review if the evidence changed, I 
didn't discount it, I *utterly dismissed it*. Following a fluffy puppy up a 
country lane because in an entirely different situation (causes of S0C4 are 
hardly of a limited number of specific things) a fluffy puppy was the answer 
is... how useful?

Multiple people concurring on a suggestion doesn't in itself make it any more 
valid. In other situations it is spot on, but here?

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

Re: Program now working, but why?

[Bill Woodger]

On Wed, 8 Feb 2017 10:34:28 -0600, Peter Ten Eyck 
 wrote:

>At this point I am thinking the coding change is required due a difference in 
>how the COBOL compilers work. I was attempting to identify what that 
>difference may be or find something in the migration guide that highlighted 
>it. ...

I think that is essentially correct. The compiler, or the runtime - a more 
slight chance. You've eliminated "data" as an issue, and, except as an 
incidental, the Assembler program.

If R4 is zero and you review my requests, I think you will be there. I don't 
think it is documented in a Migration Guide, but there is some "supporting 
material". 

Of course, I can be wrong :-) There's not enough information to fully support 
what I think, but nothing has countered it yet. Other evidence could do so.

If R4 is zero, then I'm still 100% (that's rounded), sure it is not DATA(31) 
being an issue (unless there is weird code in the Assembler program which 
coincidentally makes R4 zero when whatever circumstances cause this - never say 
never).

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

Re: The "Cobol and 00A Program Check" Story - Some insight gained

[Bill Woodger]

Good progress Peter.

The debugger turning the bit on seems to be... wrong. Interestingly wrong ("oh, 
we're in the debugger, let's do something different...") :-)

The bit is only ever set (to zero or one, as appropriate) once by LE per 
"environment that needs to be established" (my wording). If the first program 
is C/C++, the bit is on, and left on. If it is explicitly turned off, it will 
stay turned off. 

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

Re: SFTP on z/OS

[Kirk Wolf]

Starting with IBM Ported Tools OpenSSH 1.3, or z/OS OpenSSH 2.2, you need
to have ICSF running for /dev/random support.   A crypto card is not
required.  This is because later versions of OpenSSH wisely do not support
"ssh rand helper" any longer.

But all that use OpenSSH on z/OS should run ICSF with CPACF, since it will
save you a bunch of CPU cycles.

See on of the z/OS OpenSSH "Quick Install" Guides here (depending on your
version):
http://dovetail.com/docs/coz/coz_index.html


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Mon, Feb 6, 2017 at 8:05 AM, John McKown 
wrote:

> On Sat, Feb 4, 2017 at 3:15 PM, scott Ford  wrote:
>
> > Guys:
> >
> > I have a SSH question, we dont have a ICSF , do i need one to do SSH ? We
> > want to do scp from Windows to
> > z/OS  . I want stepping thru the ICSF stc doc and read about 'head
> > 'dev/random' and its not working returning an error
> >
>
> ​I am running SSH on z/OS 1.12 without having ICSF running. It is a bit
> more CPU intensive. In this case, the "/dev/random" device does not work,
> but SSH basically doesn't use it in this case. At least, that has been my
> experience.​
>
>
>
> >
> > Scott
> >
> >
>
> --
> Our calculus classes are an integral part of your education.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Job postings?

[Blaicher, Christopher Y.]

I don't think anyone has a problem with a legitimate posting, either looking 
for work or offering a position as long as it is mainframe related.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
2 Blue Hill Plaza #1563, Pearl River, NY 10965

P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com

CONNECTING BIG IRON TO BIG DATA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith III
Sent: Wednesday, February 8, 2017 5:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Job postings?

What's the current stance on posting job openings here?


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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

Job postings?

[Phil Smith III]

What's the current stance on posting job openings here?


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

AW: Re: Problem with java 64-bit

[Peter Hunkeler]

 
> Hum, I really wondering about how the OP is running java in TSO. The  
"java" command is not a TSO command, it is a UNIX command. Which, I think,  
means that the OP must be running it from the TSO OMVS command environment.  
Which means that the java command is not running in the TSO address space  
at all, it is running in a separate UNIX shell address space.  
 
 
Running a shell via TSO -> OMVS will run the shell *in* the TSO address space, 
unless you specify NOSHAREAS when invoking OMVS.  
 
 
And if you have the recommended "export _BPX_SHAREAS=YES" in your shell setup, 
java will also run in the TSO address space. (Or is the "java" binary installed 
with the share-as extended attribute cleared? Can't check now). So java runs 
with the TSO region size. 
 
 
> The size of which, I think, is determined by the OMVS segment in RACF, not 
> the logged  
on TSO region size.​  
 
 
It used to be that the ASSIZEMAX and MAXASSIZE were only used for UNIX address 
space born out of daemon activity, such as inetd, or ftpd, where a user region 
could not be determined by other means, e.g TSO SIZE, or JCL REGION=.


--
Peter Hunkeler


  
  
  
 
 
 
-- 
Peter Hunkeler  
 
-- 
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: Problem with java 64-bit

[Peter Hunkeler]

> Hum, I really wondering about how the OP is running java in TSO. The 
"java" command is not a TSO command, it is a UNIX command. Which, I think, 
means that the OP must be running it from the TSO OMVS command environment. 
Which means that the java command is not running in the TSO address space 
at all, it is running in a separate UNIX shell address space. 


Running a shell via TSO -> OMVS will run the shell *in* the TSO address space, 
unless you specify NOSHAREAS when invoking OMVS. 


And if you have the recommended "export _BPX_SHAREAS=YES" in your shell setup, 
java will also run in the TSO address space. (Or is the "java" binary installed 
with the share-as extended attribute cleared? Can't check now). So java runs 
with the TSO region size.


> The size of which, I think, is determined by the OMVS segment in RACF, not 
> the logged 
on TSO region size.​ 


It used to be that the ASSIZEMAX and MAXASSIZE only 
 
 
 



--
Peter Hunkeler 

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

Re: "Fraud detection failure" messages

[zMan]

"Fraud detection failure" is actually pretty funny: "There was fraud, but
we failed to detect it"!!

On Wed, Feb 8, 2017 at 8:01 AM, van der Grijn, Bart (B) <
bvandergr...@dow.com> wrote:

> I get the same. I figured it was some software we're running internally.
> I assume it's because the message comes in disguised as me but from a
> userid that's not me.
> Bart
>
> -Original Message-
>
> > Does anyone else get these messages when they respond? I have noticed
> this
> > the last several times I have posted. Not so much before that, though.
> >
> > [This sender failed our fraud detection checks and may not be who they
> > appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
> >
> > Bill Hitefield
> > Dino-Software Corporation
> > 800.480.DINO
> > 423.878.5660
> > www.dino-software.com
>
> --
> 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

Re: SFTP on z/OS

[Jack J. Woehr]

venkat kulkarni wrote:

MBR of a physical file


And this is bin mode?

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: TASID bug

[Jousma, David]

We don't have an esoteric call CART, but here are all of mine.

| SYS348XR |  (esoteric)512 devices  480 online |
| SYS348XR | I05933 H12059 E83769 D38189 G07319 J07644 J04218 H74049|
| SYS348XR | E52728 G50863 G65154   |
|--+|
| SYS3480R |  (esoteric)512 devices  480 online |
| SYS3480R | I05933 H12059 E83769 D38189 G07319 J07644 J04218 H74049|
| SYS3480R | E52728 G50863 G65154   |
| VTSALL   |  (esoteric)512 devices  480 online |
| VTSALL   | I05933 H12059 E83769 D38189 G07319 J07644 J04218 H74049|
| VTSALL   | E52728 G50863 G65154   |
|--+|
| VTSGRID  |  (esoteric)512 devices  480 online |
| VTSGRID  | I05933 H12059 E83769 D38189 G07319 J07644 J04218 H74049|
| VTSGRID  | E52728 G50863 G65154   |
|--+|
| VTS1FL   |  (esoteric)512 devices  480 online |
| VTS1FL   | I05933 H12059 E83769 D38189 G07319 J07644 J04218 H74049|
| VTS1FL   | E52728 G50863 G65154   |
| 3490 |512 devices  480 online | 
| 3490 | I05933 H12059 E83769 D38189 G07319 J07644 J04218 H74049| 
| 3490 | E52728 G50863 G65154   |

_
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 Feller, Paul
Sent: Wednesday, February 08, 2017 2:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TASID bug

I'm running Version 5.21 on z/OS 2.2.  All our tape are defined as 3490 in the 
IOGEN.  We have two IBM TS7760 boxes. 

Depending on which lpar I run TASID on I get different answers from UNI.

This is on an lpar with lots of tape and DASD.  I do have 288 devices defined 
to CART but it is listing the same DASD VOLSER.
+--++
| CART |  (esoteric)288 devices  288 online |
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|


On a different lpar (same CEC as above) with less tape and DASD defined I get a 
different answer.  There are 96 tape devices in CART and they are all really 
online.
+--++
| CART |  (esoteric) 96 devices0 online |



Thanks..

Paul Feller
AGT Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Wednesday, February 08, 2017 13:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TASID bug

Using z/OS 2.2 and TASID 5.21

The issue appears only for tape:

CART |  (esoteric)512 devices  512 online
CART | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1
CART | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

SYS348XR |  (esoteric)512 devices  512 online
SYS348XR | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 SYS348XR | 
2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

SYS3480R |  (esoteric)512 devices  512 online
SYS3480R | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 SYS3480R | 
2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

3490 |512 devices  512 online
3490 | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1
3490 | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

This is the only one that is correct:

3590-1   | 32 devices   16 online
 3590-1   | E11761 E11077 E10540 E11921 

Re: TASID bug

[Feller, Paul]

I'm running Version 5.21 on z/OS 2.2.  All our tape are defined as 3490 in the 
IOGEN.  We have two IBM TS7760 boxes. 

Depending on which lpar I run TASID on I get different answers from UNI.

This is on an lpar with lots of tape and DASD.  I do have 288 devices defined 
to CART but it is listing the same DASD VOLSER.
+--++
| CART |  (esoteric)288 devices  288 online |
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|
| CART | S94682 S94682 S94682 S94682 S94682 S94682 S94682 S94682|


On a different lpar (same CEC as above) with less tape and DASD defined I get a 
different answer.  There are 96 tape devices in CART and they are all really 
online.
+--++
| CART |  (esoteric) 96 devices0 online |



Thanks..

Paul Feller
AGT Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Wednesday, February 08, 2017 13:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TASID bug

Using z/OS 2.2 and TASID 5.21

The issue appears only for tape:

CART |  (esoteric)512 devices  512 online
CART | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1
CART | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

SYS348XR |  (esoteric)512 devices  512 online
SYS348XR | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1
SYS348XR | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

SYS3480R |  (esoteric)512 devices  512 online
SYS3480R | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1
SYS3480R | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

3490 |512 devices  512 online
3490 | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1
3490 | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

This is the only one that is correct:

3590-1   | 32 devices   16 online
 3590-1   | E11761 E11077 E10540 E11921 E11435 E11861

I've compared to SHOWZOS which is correct :-)


--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10)
Information and Technology, IT Operations and Services



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Wednesday, February 08, 2017 1:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: TASID bug

Which version of TASID are you running?  I have version 5.20 (z/OS 1.13 still) 
and I am not seeing the problem described.
We have 3480 & 3490 (Luminex VTS) and a real 3590 TLS.

Could your esoterics be pointing to the wrong unit addresses on your system?

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Wednesday, February 08, 2017 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TASID bug

Had a bug reported to me in TASID and I'm hoping someone on this list may have 
insight into how to fix it;

Using option 5 (miscellaneous) and then UNI (available units) is valid for disk 
but for tape esoterics and 3490 it is showing disk volsers. Device type 3590 
correctly shows tape volsers.

(too bad Doug isn't around to help)

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services


--
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: TASID bug

[Dyck, Lionel B. (TRA)]

Using z/OS 2.2 and TASID 5.21

The issue appears only for tape:

CART |  (esoteric)512 devices  512 online
CART | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1
CART | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

SYS348XR |  (esoteric)512 devices  512 online
SYS348XR | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1
SYS348XR | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

SYS3480R |  (esoteric)512 devices  512 online
SYS3480R | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1
SYS3480R | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

3490 |512 devices  512 online
3490 | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1
3490 | 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1 2PRDM1

This is the only one that is correct:

3590-1   | 32 devices   16 online
 3590-1   | E11761 E11077 E10540 E11921 E11435 E11861

I've compared to SHOWZOS which is correct :-)


--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10)
Information and Technology, IT Operations and Services



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Wednesday, February 08, 2017 1:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: TASID bug

Which version of TASID are you running?  I have version 5.20 (z/OS 1.13 still) 
and I am not seeing the problem described.
We have 3480 & 3490 (Luminex VTS) and a real 3590 TLS.

Could your esoterics be pointing to the wrong unit addresses on your system?

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Wednesday, February 08, 2017 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TASID bug

Had a bug reported to me in TASID and I'm hoping someone on this list may have 
insight into how to fix it;

Using option 5 (miscellaneous) and then UNI (available units) is valid for disk 
but for tape esoterics and 3490 it is showing disk volsers. Device type 3590 
correctly shows tape volsers.

(too bad Doug isn't around to help)

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services


--
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: RES: SFTP on z/OS

[John McKown]

On Wed, Feb 8, 2017 at 12:35 PM, saurabh khandelwal <
sourabhkhandelwal...@gmail.com> wrote:

> But is there any way to resolve this issue without any third party product.
>

​When I do a batch transfer using sftp, I make sure that the SSH
certificate used on the z/OS side does not have a "passphrase". I think
that is why it is complaining about /dev/tty​ not existing. My JCL looks
like:

//PS001   EXEC PGM=BPXBATCH,REGION=0M,
// PARM='SH echo "quit" | sftp -v rsid@${LINUX}'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDIN DD PATH='/dev/null',
// PATHOPTS=(ORDONLY)
//STDENV DD *
/*

​Of course, this can be a very bad security gap. I avoid this by having the
id on the remote side be "special purpose" so that it can't do much of
anything. That is, it has a unique GID all of its own.



>
> On Jan 31, 2017 3:33 PM, "Carlos Bodra - Pessoal" 
> wrote:
>
> > Check MDI product at luminex.com for fast and secure SFTP or FTP
> >
> > Carlos Bodra
> > IBM System Certified System z
> > São Paulo - Brazil
> >
> > -Mensagem original-
> > De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em
> > nome de venkat kulkarni
> > Enviada em: domingo, 29 de janeiro de 2017 14:38
> > Para: IBM-MAIN@LISTSERV.UA.EDU
> > Assunto: SFTP on z/OS
> >
> > Hello Group,
> >
> >
> >
> > We tested SFTP on our test z/OS system to Test AIX box and we are able to
> > transfer data between these host. But now, I am trying in production
> system
> > with below detail.
> >
> >
> >
> > 1) Our aim is to convert all our FTP jobs into SFTP.
> >
> > 2) We are using $universe as scheduler for submitting these FTP jobs on
> > time to time.
> >
> > 3) We using user called "STCSYS" all these jobs.
> >
> > 4) But in FTP jobs, for every other host ( Ex AIX1, AIX2,AIX3 etc) we are
> > using different user id password to login to target host and then start
> FTP
> > process.
> >
> > 5) But in SFTP, it create TSO env using IKJEFT01 program and then run
> SFTP
> > commands to transfer files between systems.
> >
> >
> >
> > Example of SFTP Job, we using
> >
> >
> >
> >
> >
> > //SFTPSFT JOB (7330),MSGCLASS=X,MSGLEVEL=(1,1),CLASS=P,
> >
> > //  NOTIFY=
> >
> > //STEP1   EXEC PGM=IKJEFT01,REGION=0M
> >
> > //SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC
> >
> > //SYSTSIN   DD DSN=SFTPSFT.TEST.JCL(FTPTST1),DISP=SHR
> >
> > //OUTPUT DD SYSOUT=*
> >
> > //SYSTSPRT DD SYSOUT=*
> >
> > /*
> >
> >
> >
> > EDIT   SFTPSFT.TEST.JCL(FTPTST1) - 01.02
> >
> > Command ===>
> >
> > ** * Top of Data 
> >
> > 000800 OPUT 'SFTPSFT.SFTP.TEST(SFTP1)'  '/u/SFTPSFT/vp12'
> >
> > 000900 OSHELL { echo 'lcd /u/stcsys' ; +
> >
> > 001000  echo 'ascii'; +
> >
> > 001100  echo 'cd /home/ftp4rpt/';  +
> >
> > 001200  echo 'mput test.txt'; } | +
> >
> > 001300sftp -v ftprpt@10.22.22.220
> >
> > 001400 /*
> >
> >
> >
> >
> >
> > So, now I have stcsys user id created on mainframe with all
> >
> >
> >
> > # cd .ssh
> >
> > # ls -al
> >
> > total 96
> >
> > drwx--   2 MEAS OMVSGRP 8192 Jan 24 08:23 .
> >
> > drwxr-xr-x   3 MEAS OMVSGRP 8192 Jan 24 08:22 ..
> >
> > -rw---   1 MEAS OMVSGRP  791 Jan 24 08:36 authorized_keys
> >
> > -rw---   1 MEAS OMVSGRP 1675 Jan 24 08:23 id_rsa
> >
> > -rw-r--r--   1 MEAS OMVSGRP  396 Jan 24 08:25 id_rsa.pub
> >
> > -rw-r--r--   1 MEAS OMVSGRP  697 Jan 29 10:26 known_hosts
> >
> > # pwd
> >
> > /u/stcsys/.ssh
> >
> >
> >
> >
> > and in AIX1 side, I have ftprpt user defined and
> >
> >
> >
> > $ cd /home/ftprpt /.ssh
> >
> > $ ls -al
> >
> > total 48
> >
> > drwx--2 ftprpt staff   256 Jan 13 15:37 .
> >
> > drwxr-xr-x3 ftprpt staff  4096 Jan 15 12:15 ..
> >
> > -rw-r--r--1 ftprptstaff   791 Jan 15 12:12
> authorized_keys
> >
> > -rw-r--r--1 ftprpt staff   395 Jan 13 15:37
> > authorized_keys.old
> >
> > -rw---1 ftprpt staff  1675 Dec 11 14:25 id_rsa
> >
> > -rw-r--r--1 ftprpt staff   394 Dec 11 14:25 id_rsa.pub
> >
> > -rw-r--r--1 ftprpt staff   352 Jan 15 10:31 known_hosts
> >
> > $
> >
> >
> >
> >
> >
> >
> >
> > and we exchanged rsa.pub key in authorized_keys file and exchanged
> > ECDSA.pub key in  known_hosts file but while running Job, I am getting
> > below issue.
> >
> >
> >
> > OpenSSH_6.4, OpenSSL 1.0.1c 10 May 2012
> >
> >
> > debug1: Reading configuration data /etc/ssh/ssh_config
> >
> >
> > debug1: Reading configuration data /etc/ssh/zos_ssh_config
> >
> >
> > debug1: zsshSmfSetConnSmfStatus: SMF status is 0
> >
> >
> > debug1: Connecting to 10.22.22.220 Ý10.22.22.220¨ port 22.
> >
> >
> > debug1: Connection established.
> >
> >
> > debug1: cipher_init: none from source OpenSSL
> >
> >
> > debug1: cipher_init: none from source OpenSSL
> >
> >
> > debug1: permanently_set_uid: 0/1000
> >
> >
> > debug1: identity file /u/stcsys/.ssh/id_rsa type 1
> >
> >
> > debug1: 

AW: Re: A further question regarding COBOL5 and CEEDUMP

[Peter Hunkeler]

> URL to the APAR please? Google cannot find it.

Sorry, could not find it myself from home right before posting. Was looking it 
up from the PMR. Will check from the office tomorrow and post.


--
Peter Hunkeler



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

Re: TASID bug

[Jousma, David]

I am as well.

_
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 Dyck, Lionel B. (TRA)
Sent: Wednesday, February 08, 2017 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TASID bug

I'm using tasid 5.21 if that helps

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, February 08, 2017 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: TASID bug

In TASID on my 2.2 system, the UNI display shows tape volsers for all my tape 
esoterics.

_
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 Dyck, Lionel B. (TRA)
Sent: Wednesday, February 08, 2017 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TASID bug

Had a bug reported to me in TASID and I'm hoping someone on this list may have 
insight into how to fix it;

Using option 5 (miscellaneous) and then UNI (available units) is valid for disk 
but for tape esoterics and 3490 it is showing disk volsers. Device type 3590 
correctly shows tape volsers.

(too bad Doug isn't around to help)

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services


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

--
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 "Cobol and 00A Program Check" Story - Some insight gained

[Peter Hunkeler]

Remember, I was posting a couple of times about the 00A program checks that 
started to cause us trouble late last year? For those interested here comes 
some insight I gained so far.




- We run Smart/Restart with the default options ESTAE(ON) and ESPIE(ON). This 
made us belive that the 00A program checks will be intercepted by S/R's ESPIE 
exit. Therefore we thought that exit needs to properly handle 00A's from Cobol, 
namely by retrying. After long, it turned out that S/R is actually RESETting 
the ESPIE when ESPIE(ON) is specified, and not registering its own exit. This 
in fact *cancelles* LE's ESPIE exit that was established by LE because we run 
with LE option TRAP(ON,SPIE). Umhh...




- We are currently convinced that we should run S/R with ESPIE(OFF); we cannot 
imagine why on earth S/R would need an ESPIE exit at all. But we're still in 
discussion if there is any drawback of this. With S/R ESPIE(OFF), LE's ESPIE 
exit will gain control for program checks and will properly handle the Cobol 
00As.






- Why are we seenig those 00As more often recently? It seems to turn out that 
Cobol V5.2 is generating a completely different instruction stream for certain 
MOVE instructions that involve moving numbers, especially fractions parts. 
Cobol up to V5.1 was generating instruciton streams that could not raise a 
decimal overflow; Cobol V5.2 is. It is making use of the SRP (shift and rund 
decimal) instruction, and this is where our applications are generating the 
00As.





- My modification of the IGZCFCC and IGZXFCA1 Cobol runtime module succeded 
(remember the "binder" questions I had). I was able to see that running job 
using the IBM debugger, the decimal overflow mask was not get turned on as long 
as only Cobol V4.2 code was running. But as soon as some Cobol V5.2 code was 
being called, the mask was set. However, strangely enough, the problem did not 
occur if the same Cobol V5.2 code was being called when *not* running under the 
debugger.


Also, I was able to trace a job where Cobol V4.2 and V5.2 modules were heavily 
being used intermixed. To my astonishment, the decimal overflow mask was seen 
to be turne ON after about 2000 CALLs to both Cobol V4.2 and V5.2 modules. 
Still investigating, but with lower priority, since I'm convinced the solution 
is runinng S/R with ESPIE(OFF), as explained above.



Not finished yet, but at least big steps forward.



--
Peter Hunkeler

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

Re: zOS SYSPROG jobs

[Edward Gould]

> On Feb 8, 2017, at 9:14 AM, R.S.  wrote:
> 
> W dniu 2017-02-07 o 17:58, Bobbie Justice pisze:
>> I've seen several for NYC and places close to NYC (no thank you).
>> 
>> There are companies that don't like U.S. employees doing remote work for 
>> whatever bogus reason. They will post the job as "onsite only", then six 
>> months later they will outsource those jobs to India falsely claiming that 
>> "they can't find workers in the U.S.".
> Would it change much if they'd said "we moved those jobs to India, because 
> it's cheaper" or even ""we moved those jobs to India, becausewe wanted to”?

I worked at such a place a while ago. They off shored the work to India. Some 
of the staff got “lucky” and got a job at the company that did the off shoring 
(IBM).
I was happy to be out of the place for multiple reasons and never missed any of 
the people there at all. They were of the types that liked to scream at others 
and liked to bully people around.
Ed

> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> ---
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być 
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś 
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej 
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, 
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie 
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, 
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale 
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub 
> zapisane na dysku.
> 
> This e-mail may contain legally privileged information of the Bank and is 
> intended solely for business use of the addressee. This e-mail may only be 
> received by the addressee and may not be disclosed to any third parties. If 
> you are not the intended addressee of this e-mail or the employee authorized 
> to forward it to the addressee, be advised that any dissemination, copying, 
> distribution or any other similar activity is legally prohibited and may be 
> punishable. If you received this e-mail by mistake please advise the sender 
> immediately by using the reply facility in your e-mail software and delete 
> permanently this e-mail including any copies of it either printed or saved to 
> hard drive.
> 
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
> www.mBank.pl, e-mail: kont...@mbank.pl
> Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
> Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
> Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
> wpłacony) wynosi 168.955.696 złotych.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: TASID bug

[Carmen Vitullo]

I'm runing 5.21 on a 2.1 system, - are you talking UNI or UCB, I don't see any 
volsers in the UNI display, but the UCB display I do 

0F2A CTC ? '07'x ? 
0F2B CTC ? '07'x ? 
0F2C CTC ? '07'x ? 
0F2D CTC ? '07'x ? 
0F2E CTC ? '07'x ? 
0F2F CTC ? '07'x ? 
4000 S9TL70 DASD 3390-9 60,102 Perm SysShr Private SMS 
4001 S9TL78 DASD 3390-9 60,102 Perm SysShr Private SMS 
4002 S9TL7G DASD 3390-9 60,102 Perm SysShr Private SMS 
4003 S9TL7O DASD 3390-9 60,102 Perm SysShr Private SMS 
4004 S9LG50 DASD 3390-9 60,102 Perm SysShr Private SMS 
4005 S9LG58 DASD 3390-9 60,102 Perm SysShr Private SMS 
4006 S9LG5G DASD 3390-9 60,102 Perm SysShr Private SMS 
4007 S9LG5O DASD 3390-9 60,102 Perm SysShr Private SMS 
4008 S9LG5W DASD 3390-9 60,102 Perm SysShr Private SMS 
4009 S9LG64 DASD 3390-9 60,102 Perm SysShr Private SMS 
400A S9LG6S DASD 3390-9 60,102 Perm SysShr Private SMS 
- Original Message -

From: "Lionel B. Dyck (TRA)"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 8, 2017 12:19:43 PM 
Subject: TASID bug 

Had a bug reported to me in TASID and I'm hoping someone on this list may have 
insight into how to fix it; 

Using option 5 (miscellaneous) and then UNI (available units) is valid for disk 
but for tape esoterics and 3490 it is showing disk volsers. Device type 3590 
correctly shows tape volsers. 

(too bad Doug isn't around to help) 

-- 
Lionel B. Dyck 
Mainframe Systems Programmer - TRA 
Enterprise Operations (Station 200) (005OP6.3.10) 
Information and Technology, IT Operations and Services 


-- 
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: TASID bug

[Dyck, Lionel B. (TRA)]

I'm using tasid 5.21 if that helps

--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10)
Information and Technology, IT Operations and Services


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, February 08, 2017 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: TASID bug

In TASID on my 2.2 system, the UNI display shows tape volsers for all my tape 
esoterics.

_
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 Dyck, Lionel B. (TRA)
Sent: Wednesday, February 08, 2017 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TASID bug

Had a bug reported to me in TASID and I'm hoping someone on this list may have 
insight into how to fix it;

Using option 5 (miscellaneous) and then UNI (available units) is valid for disk 
but for tape esoterics and 3490 it is showing disk volsers. Device type 3590 
correctly shows tape volsers.

(too bad Doug isn't around to help)

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services


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

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

Re: TASID bug

[Nims,Alva John (Al)]

Which version of TASID are you running?  I have version 5.20 (z/OS 1.13 still) 
and I am not seeing the problem described.
We have 3480 & 3490 (Luminex VTS) and a real 3590 TLS.

Could your esoterics be pointing to the wrong unit addresses on your system?

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Wednesday, February 08, 2017 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TASID bug

Had a bug reported to me in TASID and I'm hoping someone on this list may have 
insight into how to fix it;

Using option 5 (miscellaneous) and then UNI (available units) is valid for disk 
but for tape esoterics and 3490 it is showing disk volsers. Device type 3590 
correctly shows tape volsers.

(too bad Doug isn't around to help)

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services


--
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: TASID bug

[Jousma, David]

In TASID on my 2.2 system, the UNI display shows tape volsers for all my tape 
esoterics.

_
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 Dyck, Lionel B. (TRA)
Sent: Wednesday, February 08, 2017 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TASID bug

Had a bug reported to me in TASID and I'm hoping someone on this list may have 
insight into how to fix it;

Using option 5 (miscellaneous) and then UNI (available units) is valid for disk 
but for tape esoterics and 3490 it is showing disk volsers. Device type 3590 
correctly shows tape volsers.

(too bad Doug isn't around to help)

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services


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

Re: A further question regarding COBOL5 and CEEDUMP

[Farley, Peter x23353]

URL to the APAR please?  Google cannot find it.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Wednesday, February 08, 2017 1:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: A further question regarding COBOL5 and CEEDUMP

>Anyway, TEST is much improved with COBOL V5/V6, we put the Debug data 
>in a NOLOAD class segment in the Program Object, so that it is always 
>available, always in sync with the load, and never takes up memory at runtime 
>unless it is needed.  An example of when it is needed is when a CEEDUMP is 
>being written/created by LE! 
 
But BEWARE the fact that each and every transaction abending in, say CICS, will 
now list all the working storage to the CICS SYSOUT if the LE options are 
TERMTHDACT(TRACE,,24)! This caused us a productin issue!

We do compile with TEST, but we did not copy the side files to production, so 
LE was not able to list the working storage; a simple single line message 
informed us about this. Fine.

Now with Cobol V5 (and later) the debug information is *always* there, there is 
no way to avoid this. Basically, a good thing, however not for your CICS 
regions. We ended up with millions of lines of TRACE output being written to 
CICS SYSOUT.

IBM LE/Compiler people should have thought of an additional TERMTHDACT option 
to *suppress* the listing of the working storage when not desired, suchas 
withing CICS. I had envisioned something like TERMTHDACT(TRACESHORT...) which 
would give us the same information a TRACE but without lilsting the working 
storage. 

We opened a PMR and the solution was to implement some Cobol runtime option via 
assembled module IGZUOPT (shudder, but unfortunately my voice was not heard). 
There is APAR PI75601 that will implement that change and is targeted for 
February.

--

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

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

Re: Eight-character TSO Userid Support

[Paul Gilmartin]

On Wed, 8 Feb 2017 12:08:47 -0600, Walt Farrell wrote:
>
>In theory, similar supported located at the "edge" between z/OS and network 
>apps would also allow mapping from a 32-character Linux ID to an 8-character 
>z/OS ID, without user action. 
> 
Or even 7, for maximum TSO compatibility?  

>It's not a perfect solution for what gil wants to see, but it would solve a 
>lot of compatibility issues without requiring all the applications to change. 
>Only the security products. 
>
This seems to meet most requirements: TSO, UNIX, and LDAP.  Why, then, is there
any need for OA51203 or USERIDALIASTABLE?  And EIM appears to be done with RACF
which is the correct component for identity management.

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


>z/OS also provides functions, today, that applications can use for something 
>similar: z/OS Enerprise Identity Mapping. For more about that you can see its 
>Guide and Reference:
>  
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/eima1170/CCONTENTS?SHELF=all13be9=SA22-7875-09=20100617152016
>or
>  http://preview.tinyurl.com/znostgd

Thanks.


On Mon, 6 Feb 2017 20:37:41 -0500, Tom Conley wrote:
>
>> Dismayingly ironically, the need has been addressed by UNIX System Services:
>>  � z/OS 2.2.0
>>  � z/OS UNIX System Services
>>  � z/OS UNIX System Services Planning
>>  � Customizing z/OS UNIX
>>  � Customizing the BPXPRMxx member of SYS1.PARMLIB
>>  � Defining system features
>>  � USERIDALIASTABLE
>   ...
>I must say one thing.  This entire post by Gil is untrue.  His
>conjecture about we should have done 32 characters would have made this
>project wait at least another, and possibly two releases of z/OS.  The
>line about deficient communication is unadulterated bull@#$%.  A large
>number of people at both IBM and OEM vendors have been working for years
>to deliver 8-character TSO support.  The work these people have done is
>worthy of praise, not damnation.  A non-disclosure prevents me from
>saying more at this time, but for the folks on the list, you need to
>know that Gil is completely wrong on this issue.
>
And I'll continue to disagree.  Not so much with Tom as with IBM's chaotic
design practices.  Given two very similar requirements (and perhaps a third),
expanding the user name spaces in TSO and UNIX System services, why:
o provide two separate solutions, OA51203 and USERIDALIASTABLE for UNIX
  when a single one should suffice?
o And why implement USERIDALIASTABLE, at the expense of decreased
  performance, outside RACF, the proper platform for identity management?

It appears that EIM should have been the single solution.

-- gil

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

Re: RES: SFTP on z/OS

[saurabh khandelwal]

But is there any way to resolve this issue without any third party product.

On Jan 31, 2017 3:33 PM, "Carlos Bodra - Pessoal" 
wrote:

> Check MDI product at luminex.com for fast and secure SFTP or FTP
>
> Carlos Bodra
> IBM System Certified System z
> São Paulo - Brazil
>
> -Mensagem original-
> De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em
> nome de venkat kulkarni
> Enviada em: domingo, 29 de janeiro de 2017 14:38
> Para: IBM-MAIN@LISTSERV.UA.EDU
> Assunto: SFTP on z/OS
>
> Hello Group,
>
>
>
> We tested SFTP on our test z/OS system to Test AIX box and we are able to
> transfer data between these host. But now, I am trying in production system
> with below detail.
>
>
>
> 1) Our aim is to convert all our FTP jobs into SFTP.
>
> 2) We are using $universe as scheduler for submitting these FTP jobs on
> time to time.
>
> 3) We using user called "STCSYS" all these jobs.
>
> 4) But in FTP jobs, for every other host ( Ex AIX1, AIX2,AIX3 etc) we are
> using different user id password to login to target host and then start FTP
> process.
>
> 5) But in SFTP, it create TSO env using IKJEFT01 program and then run SFTP
> commands to transfer files between systems.
>
>
>
> Example of SFTP Job, we using
>
>
>
>
>
> //SFTPSFT JOB (7330),MSGCLASS=X,MSGLEVEL=(1,1),CLASS=P,
>
> //  NOTIFY=
>
> //STEP1   EXEC PGM=IKJEFT01,REGION=0M
>
> //SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC
>
> //SYSTSIN   DD DSN=SFTPSFT.TEST.JCL(FTPTST1),DISP=SHR
>
> //OUTPUT DD SYSOUT=*
>
> //SYSTSPRT DD SYSOUT=*
>
> /*
>
>
>
> EDIT   SFTPSFT.TEST.JCL(FTPTST1) - 01.02
>
> Command ===>
>
> ** * Top of Data 
>
> 000800 OPUT 'SFTPSFT.SFTP.TEST(SFTP1)'  '/u/SFTPSFT/vp12'
>
> 000900 OSHELL { echo 'lcd /u/stcsys' ; +
>
> 001000  echo 'ascii'; +
>
> 001100  echo 'cd /home/ftp4rpt/';  +
>
> 001200  echo 'mput test.txt'; } | +
>
> 001300sftp -v ftprpt@10.22.22.220
>
> 001400 /*
>
>
>
>
>
> So, now I have stcsys user id created on mainframe with all
>
>
>
> # cd .ssh
>
> # ls -al
>
> total 96
>
> drwx--   2 MEAS OMVSGRP 8192 Jan 24 08:23 .
>
> drwxr-xr-x   3 MEAS OMVSGRP 8192 Jan 24 08:22 ..
>
> -rw---   1 MEAS OMVSGRP  791 Jan 24 08:36 authorized_keys
>
> -rw---   1 MEAS OMVSGRP 1675 Jan 24 08:23 id_rsa
>
> -rw-r--r--   1 MEAS OMVSGRP  396 Jan 24 08:25 id_rsa.pub
>
> -rw-r--r--   1 MEAS OMVSGRP  697 Jan 29 10:26 known_hosts
>
> # pwd
>
> /u/stcsys/.ssh
>
>
>
>
> and in AIX1 side, I have ftprpt user defined and
>
>
>
> $ cd /home/ftprpt /.ssh
>
> $ ls -al
>
> total 48
>
> drwx--2 ftprpt staff   256 Jan 13 15:37 .
>
> drwxr-xr-x3 ftprpt staff  4096 Jan 15 12:15 ..
>
> -rw-r--r--1 ftprptstaff   791 Jan 15 12:12 authorized_keys
>
> -rw-r--r--1 ftprpt staff   395 Jan 13 15:37
> authorized_keys.old
>
> -rw---1 ftprpt staff  1675 Dec 11 14:25 id_rsa
>
> -rw-r--r--1 ftprpt staff   394 Dec 11 14:25 id_rsa.pub
>
> -rw-r--r--1 ftprpt staff   352 Jan 15 10:31 known_hosts
>
> $
>
>
>
>
>
>
>
> and we exchanged rsa.pub key in authorized_keys file and exchanged
> ECDSA.pub key in  known_hosts file but while running Job, I am getting
> below issue.
>
>
>
> OpenSSH_6.4, OpenSSL 1.0.1c 10 May 2012
>
>
> debug1: Reading configuration data /etc/ssh/ssh_config
>
>
> debug1: Reading configuration data /etc/ssh/zos_ssh_config
>
>
> debug1: zsshSmfSetConnSmfStatus: SMF status is 0
>
>
> debug1: Connecting to 10.22.22.220 Ý10.22.22.220¨ port 22.
>
>
> debug1: Connection established.
>
>
> debug1: cipher_init: none from source OpenSSL
>
>
> debug1: cipher_init: none from source OpenSSL
>
>
> debug1: permanently_set_uid: 0/1000
>
>
> debug1: identity file /u/stcsys/.ssh/id_rsa type 1
>
>
> debug1: identity file /u/stcsys/.ssh/id_rsa-cert type -1
>
>
> debug1: Enabling compatibility mode for protocol 2.0
>
>
> debug1: Local version string SSH-2.0-OpenSSH_6.4
>
>
> debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0
>
>
> debug1: match: OpenSSH_6.0 pat OpenSSH*
>
>
> FOTS1061 key_read: uudecode E2VjZHNhLXNoYTItbmlzdHAyNTYIbm
> lzdHAyNTYAAAB
>
>  failed
>
>
> debug1: SSH2_MSG_KEXINIT sent
>
>
> debug1: SSH2_MSG_KEXINIT received
>
>
> debug1: mac_setup_by_alg: hmac-sha1 from source OpenSSL
>
>
> debug1: kex: server->client aes128-ctr hmac-sha1 none
>
>
> debug1: mac_setup_by_alg: hmac-sha1 from source OpenSSL
>
>
> debug1: kex: client->server aes128-ctr hmac-sha1 none
>
>
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
>
>
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
>
>
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
>
>
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
>
>
> debug1: Server host key: RSA ce:14:d1:2f:b2:d1:7c:83:12:9a:
> 16:1e:31:9d:b6:b7
>
>
> FOTS1061 key_read: uudecode E2VjZHNhLXNoYTItbmlzdHAyNTYIbm
> lzdHAyNTYAAAB
>
>  failed
>
>
> 

AW: A further question regarding COBOL5 and CEEDUMP

[Peter Hunkeler]

>Anyway, TEST is much improved with COBOL V5/V6, we put the Debug data in a
NOLOAD class segment in the Program Object, so that it is always available,
always in sync with the load, and never takes up memory at runtime unless
it is needed.  An example of when it is needed is when a CEEDUMP is being
written/created by LE!





But BEWARE the fact that each and every transaction abending in, say CICS, will 
now list all the working storage to the CICS SYSOUT if the LE options are 
TERMTHDACT(TRACE,,24)! This caused us a productin issue!


We do compile with TEST, but we did not copy the side files to production, so 
LE was not able to list the working storage; a simple single line message 
informed us about this. Fine.


Now with Cobol V5 (and later) the debug information is *always* there, there is 
no way to avoid this. Basically, a good thing, however not for your CICS 
regions. We ended up with millions of lines of TRACE output being written to 
CICS SYSOUT.


IBM LE/Compiler people should have thought of an additional TERMTHDACT option 
to *suppress* the listing of the working storage when not desired, suchas 
withing CICS. I had envisioned something like TERMTHDACT(TRACESHORT...) which 
would give us the same information a TRACE but without lilsting the working 
storage.


We openend a PMR and the solution was to implement some Cobol runtime option 
via assembled module IGZUOPT (shudder, but unfortunately my voice was not 
heard). There is APAR PI75601 that will implement that change and is targeted 
for February.




--
Peter Hunkeler









--
Peter Hunkeler

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

TASID bug

[Dyck, Lionel B. (TRA)]

Had a bug reported to me in TASID and I'm hoping someone on this list may have 
insight into how to fix it;

Using option 5 (miscellaneous) and then UNI (available units) is valid for disk 
but for tape esoterics and 3490 it is showing disk volsers. Device type 3590 
correctly shows tape volsers.

(too bad Doug isn't around to help)

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10)
Information and Technology, IT Operations and Services


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

Re: IBM SR process -- brilliant

[Elardus Engelbrecht]

ICM = IBM Contract Negotiations  (From Acronym Finder attic)


>I Care Not ...

Actually ICN = Idiots Coming Nearer! ;-)

Sorry and sorry. ;-)

It must be Friday today! I think...

I can't believe I have only one Friday this month so far...

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: Eight-character TSO Userid Support

[Walt Farrell]

On Tue, 7 Feb 2017 12:35:10 -0800, Ed Jaffe  wrote:

>Any notion of extending to 32 characters would be sheer folly. That
>would require changes to the three major security products, z/OS
>subsystems, ISV products, customer code, etc. It would never get done.
>Never, ever...

RACF (and presumably the other security products if they're properly 
maintaining RACF compatibility) already support mapping long identities into 
8-character user IDs. Think, for example, of scenarios such as a user's tn3270e 
client presenting a digital certificate to the server over SSL/TLS and getting 
logged on to an application such as TSO/E, CICS, etc. automatically without 
further action on the user's part.

In theory, similar supported located at the "edge" between z/OS and network 
apps would also allow mapping from a 32-character Linux ID to an 8-character 
z/OS ID, without user action. 

It's not a perfect solution for what gil wants to see, but it would solve a lot 
of compatibility issues without requiring all the applications to change. Only 
the security products. 

z/OS also provides functions, today, that applications can use for something 
similar: z/OS Enerprise Identity Mapping. For more about that you can see its 
Guide and Reference:
  
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/eima1170/CCONTENTS?SHELF=all13be9=SA22-7875-09=20100617152016
or
  http://preview.tinyurl.com/znostgd

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

Re: SFTP on z/OS

[venkat kulkarni]

MBR of a physical file

On Feb 8, 2017 8:27 PM, "Jack J. Woehr"  wrote:

> venkat kulkarni wrote:
>
>> But when I try to sftp file from as400 to mainframe , data file
>> getting trauncated . T
>>
>
> What kind of a file is it? a MBR of a Physical File? a text file from the
> IFS?
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Program now working, but why?

[Elardus Engelbrecht]

Time for me to jump in in this thread.

Bill Woodger wrote:

>And Abend-Aid shows R4 as zero?

Hmmm, first B somewhere, then MVI 0(R4),X'40' then B same place, then MVI   
  0(R4),X'00'.

What Source Code + what Variable is used for above? Is that about some padding 
with space and then with zero?



To Peter (OP), what is inside that header record which is causing a S0C4? 
Please post it if you can.

I believe you have never posted the full and all related messages and the 
relevant COBOL statements [1] and declarations about that Abend. If I missed 
it, just tell me, I'll search again to see if I can help you.

Please post what I asked if you can. Then we can look again at RMODE and AMODE 
and friends and other suggestions kindly given by others.


Peter, you said: 'Using the shops default compile and link settings'. Are they 
really, really, really the defaults? Could you review them again and perhaps 
post them if they differ from IBM's own defaults?

Trust me, someone changed a default thing and you're then SOL.

Also, 'Program moves from the FD to WORKING-STORAGE before the call to the 
assembler program for all “input” parameters.' Please post the statements and 
all keywords which calls that assembler program.


PS: I am at v2.1, not v2.2 where Peter is working on. 

PS2: I have encountered S0C4 abends in COBOL progs in the past, but that was 
usually related to something 'unexpected'. Trust me. ;-)

Groete / Greetings
Elardus Engelbrecht

[1] - yes, you have posted that 2 lines of bypass statements, but that is not 
helping here.

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

Re: zOS SYSPROG jobs

[Don Poitras]

In article  
you wrote:
> On Wed, Feb 8, 2017 at 10:58 AM, John Mattson 
> wrote:

> > (sorry, finger check)
> > And often they have no experience with zOS and therefore only a hazy
> > idea of what we are doing.
> >
> >
> ?That is exactly why the management here was "All Windows, All The Time!".
> They didn't understand z/OS. They didn't understand what the z/OS people
> did, or how to manage them. And it was easier for them to "eliminate? the
> problem" rather than learn something different. Management is slightly
> different now. Current management doesn't want many employees. Most work is
> done either by a contractor on site, or by an outside firm (at their
> location). The company is now _mainly_ management.
> -- 
> Our calculus classes are an integral part of your education.
> Maranatha! <><
> John McKown

I don't think this is anything new. I remember a VP of a company I was
working for in 1982 tell me, "As far as I'm concerned, those guys work
for IBM. I just rent them."

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

AW: Re: Program now working, but why?

[Peter Hunkeler]

>Rather than trying to infer the cause by tweaking everything in sight, how 
>about this: Set a SLIP PER trap to catch an SVC dump for the first abend of 
>any kind, S0C4 or otherwise. That dump may tell you the exact cause far more 
>quickly than trial-and-error with recompiles/reassemblies/logic-changes.


In case it is not so easy for the developer to have the friendly sysprog set a 
slip trap, the following might also give you what you need:


//CEEOPTS DD *
  TERMTHDACT(UAIMM,,96)
/*


and make sure the last "dump" DD statement is what you prefer, either 
//SYSMDUMP if you know how to use IPCS, or //SYSABEND DD SYSOUT=* if you do 
not. The beauty with SYSMDUMP: You don't need access permission to the SVC dump 
data sets; you can choose your own name.


That will give you a dump before LE starts with its condition handling. The 
system trace listing is worth a look.


Code //SYSMDUMP something like:


//SYSMDUMP DD DISP=(NEW,CATLG),DSN=your.dump.dsn,
//   RECFM=FBS,LRECL=4160,
//   SPACE=(1,(50,200),RLSE),AVGREC=M


--
Peter Hunkeler



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

Re: IBM SR process -- brilliant

[Charles Mills]

I Care Not would seem to apply to Phil's experience.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Mattson
Sent: Wednesday, February 08, 2017 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM SR process -- brilliant

AcronymFinder.com  finds 93 possible for TLA   I choose True Love Always

ICN Only 54... Not sure if I prefer "Inter-Array Correlation-Neglecting"
(WTF) or "I Care Not" better.

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

Re: SFTP on z/OS

[Jack J. Woehr]

venkat kulkarni wrote:

But when I try to sftp file from as400 to mainframe , data file
getting trauncated . T


What kind of a file is it? a MBR of a Physical File? a text file from the IFS?

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: IBM SR process -- brilliant

[Dale R. Smith]

On Tue, 7 Feb 2017 14:59:24 -0500, Phil Smith III  wrote:


>Meanwhile, the pages are full of the TLA "ICN". In 35+ years of being an IBM
>customer I'd never seen it before; it happens that I was able to infer what
>it was, but gee, they sure are being parsimonious, saving those letters
>instead of spelling it out.
>
>My question is: how many people here look at "ICN" and say "Oh yeah, I
>instantly know what that means? Don't post what it means here and ruin it
>for everyone else, just say whether you knew it or not!
>
>.phsiii

Never heard of it before, but I think I know what it is, (after a little 
searching).  I won't post what I think it means, but I will post what it should 
stand for, based on Phil's experience:

ICN = "I Can't Navigate!"  :-)>

(This is close to what I think it really stands for!)

-- 
Dale R. Smith

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

Re: IBM SR process -- brilliant

[John McKown]

On Wed, Feb 8, 2017 at 11:17 AM, John Mattson 
wrote:

> AcronymFinder.com  finds 93 possible for TLA   I choose True Love Always
>
> ICN Only 54... Not sure if I prefer "Inter-Array Correlation-Neglecting"
> (WTF) or "I Care Not" better.
>

​I like "Internet Cranial Noogie"​

​Is it Friday already?​


-- 
Our calculus classes are an integral part of your education.

Maranatha! <><
John McKown

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

Re: IBM SR process -- brilliant

[John Mattson]

AcronymFinder.com  finds 93 possible for TLA   I choose True Love Always

ICN Only 54... Not sure if I prefer "Inter-Array Correlation-Neglecting"
(WTF) or "I Care Not" better.

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

Re: zOS SYSPROG jobs

[John McKown]

On Wed, Feb 8, 2017 at 10:58 AM, John Mattson 
wrote:

> (sorry, finger check)
> And often they have no experience with zOS and therefore only a hazy
> idea of what we are doing.
>
>
​That is exactly why the management here was "All Windows, All The Time!".
They didn't understand z/OS. They didn't understand what the z/OS people
did, or how to manage them. And it was easier for them to "eliminate​ the
problem" rather than learn something different. Management is slightly
different now. Current management doesn't want many employees. Most work is
done either by a contractor on site, or by an outside firm (at their
location). The company is now _mainly_ management.


-- 
Our calculus classes are an integral part of your education.

Maranatha! <><
John McKown

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

Re: zOS SYSPROG jobs

[John Mattson]

(sorry, finger check)
And often they have no experience with zOS and therefore only a hazy
idea of what we are doing.

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

Re: zOS SYSPROG jobs

[John Mattson]

Laid off May 2014 after 18 years at Epson, could not find anything for
about four months and then suddenly I had multiple offers... the nature of
life... rather like dating, feast or famine.  Was lucky to snag a job five
miles from my house, and the MF system is due to be replaced about the time
I intended to retire anyhow.  Sweet.
I suspect they will not meet their turnover date, so I have let it be
known that I will stay on if I am paid a retainer and come in as needed.
Seems reasonable to me, but who knows what management will do.
The unwillingness for most companies to allow remote work is because
they do not know how to manage it.  Often managers are younger than the
SYSPROGS

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

Re: Program now working, but why?

[Bill Woodger]

And Abend-Aid shows R4 as zero?

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

Re: Program now working, but why?

[Bill Woodger]

Ah, but we enjoy it. Please don't take it away from us...

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

Re: Program now working, but why?

[Bill Woodger]

Thanks Peter.

Can you provide the COBOL compile options, the linkedit map for the EXEC PGM= 
program and the AMBLIST output for the original program?

Did you discover why someone suspected the header?

Any code (including whether it is PERFORMed) which CALLs the Assembler program.

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

Re: Program now working, but why?

[Peter Ten Eyck]

Sorry not much help here, I do not know assembler.

Here is the code snippet shown in Abend-Aid for the SOC4:

   0072  47F0C0AC  B   172(,R12)
   0076  92404000  MVI 0(R4),X'40'  
   007A  47F0C0AC  B   172(,R12)
   007E  92004000  MVI 0(R4),X'00'  
NSI==> 0082  47F0C0AC  B   172(,R12)
   0086  1884  LR  R8,R4
   0088  5B80C178  S   R8,376(,R12) 
   008C  D20040008000  MVC 0(1,R4),0(R8)
   0092  47F0C0AC  B   172(,R12)

Note: NSI is next sequential instruction.

At this point I am thinking the coding change is required due a difference in 
how the COBOL compilers work. I was attempting to identify what that difference 
may be or find something in the migration guide that highlighted it. I do not 
want to take up more of other's time. Thank you for all the input and 
suggestions.

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

Re: Program now working, but why?

[Lou Losee]

What are the details of the 0C4 in the assembler program:

- what was it trying to access?
- was it a read or a write?


Lou

--
Artificial Intelligence is no match for Natural Stupidity
  - Unknown

On Wed, Feb 8, 2017 at 9:26 AM, Peter Ten Eyck <
peter.tene...@americannational.com> wrote:

> Job TNCA1300 runs three times on the same LPAR with the same data and id.
>
> Run 1 – production COBOL program, calls production assembler program, runs
> successfully.
>
> Bring production COBOL program into a development PDS and compile program
> without changes.
>
> Run 2- development program, calls production assembler program, fails with
> SOC4 in assembler program.
>
> Add these two lines of code to COBOL program to bypass header record on
> input dataset:
>
>  IF WS-NA-RECORDS-READ EQUAL 1
> GO TO 1200-READ-MASTER.
>
> Compile COBOL program with change. Compile output messages identical to
> first compile.
>
> Run 3 – development COBOL program (changed), calls production assembler
> program, runs successfully.
>
> Note: No overrides or changes to AMODE, RMODE or DATA during the test.
> Using the shops default compile and link settings.
>
> Program moves from the FD to WORKING-STORAGE before the call to the
> assembler program for all “input” parameters.
>
> I am missing something here; I do not see why this code would resolve the
> SOC4. Or has mentioned, missing something else… the unknown unknowns
>
> --
> 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: SMPE Receive Order failing?

[Jousma, David]

Reporting back to the list for completeness.  I found from my network team that 
manages our firewall that orders I placed last week were downloaded all on PORT 
21 successfully, however starting this week, the data connection had switched 
to PORT 443 and was failing at the firewall.   I'm inquiring with my network 
brethren if any TCPIP changes were made, because I made none.   As Bob 
suggested, adding FWFRIENDLY TRUE fixed the problem.

Sorry I "blamed" IBM software delivery for this problem, when it wasn't.

Dave

_
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 Jousma, David
Sent: Tuesday, February 07, 2017 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order failing?

Will do.  I'm also verifying with my network team that there wasn't some 
firewall change that was made.   BTW, I tried your suggestions, that did not 
help, nor did trying HTTPS(IBM's suggestion).   All time out on the data 
connection.   Call me a Negative Nancy, but this smells like a problem on IBM 
side.

_
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 Richards, Robert B.
Sent: Tuesday, February 07, 2017 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order failing?

Dave,

My nightly job getting the full enhanced holddata file failed over the weekend, 
but I did not need it then. If I had, I would have been upset at my inability 
to order a PTF that I urgently  needed.

Please post the resolution that IBM provides, if it is informative. :-)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 07, 2017 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order failing?

Thanks Bob.  I have a ticket open with IBM for these seemingly weekly issues.   
I've been using TLS FTP now for a couple years and every single time there is a 
problem, it has been on IBM's side.   He is suggesting I try the https method 
instead.   I will do that, but I guess my rant today is that its not apparent 
to me, who to open the PMR too when RECEIVE ORDER fails.

_
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 Richards, Robert B.
Sent: Tuesday, February 07, 2017 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order failing?

David,

I added these to the TCPPARMS member that I use for SMPE's FTP:

EPSV4 TRUE 
FWFRIENDLYTRUE

Bob 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 07, 2017 9:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order failing?

Resending with entire message listing for completeness.  This is TLS download, 
and the security negotiations work.  Same job ran fine last week:

> /bin/ftp -e -v -f "//'SYS1.TCPPARMS(FTPSECUR)'" 
> deliverycb-bld.dhe.ibm.com

EZY2640I Using 'SYS1.TCPPARMS(FTPSECUR)' for local site configuration 
parameters .
EZYFT25I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
co ntrol connection.
EZYFT31I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
da ta connection.
EZA1450I IBM FTP CS V2R2
EZA1772I FTP: EXIT has been set.
EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
220-IBM's internal systems must only be used for conducting IBM's 220-business 
or for purposes authorized by IBM management.
220-
220-Use is subject to audit at any time by IBM management.
220-
220-
220-dhebpcb01 secure FTP server
220  ready.
EZA1701I >>> AUTH TLS
234 TLSv1
EZA2895I Authentication negotiation succeeded EZA1701I >>> PBSZ 0
200 PBSZ=0
EZA1701I >>> PROT P
200 Command PROT okay.
EZA2906I Data connection protection is private EZA1459I NAME 
(deliverycb-bld.dhe.ibm.com:E008058):

> xx
EZA1701I >>> USER x
331 Password required for x.
EZA1789I PASSWORD:

> 
EZA1701I >>> PASS
230 virtual user x logged in from /192.152.100.50:26899.
EZA1460I Command:

> CCC

> BINARY
EZA1701I >>> 

Re: Program now working, but why?

[Massimo Biancucci]

Is the program reading INTO variable or not ?

If not, double check the FD definition, the length of the record and
"normal strange conditions" like empty file.

There're lot of difference in such area between OSVS or Cobol2 and
Enterprise compilers.

Best regards.
Massimo

2017-02-08 16:26 GMT+01:00 Peter Ten Eyck <
peter.tene...@americannational.com>:

> Job TNCA1300 runs three times on the same LPAR with the same data and id.
>
> Run 1 – production COBOL program, calls production assembler program, runs
> successfully.
>
> Bring production COBOL program into a development PDS and compile program
> without changes.
>
> Run 2- development program, calls production assembler program, fails with
> SOC4 in assembler program.
>
> Add these two lines of code to COBOL program to bypass header record on
> input dataset:
>
>  IF WS-NA-RECORDS-READ EQUAL 1
> GO TO 1200-READ-MASTER.
>
> Compile COBOL program with change. Compile output messages identical to
> first compile.
>
> Run 3 – development COBOL program (changed), calls production assembler
> program, runs successfully.
>
> Note: No overrides or changes to AMODE, RMODE or DATA during the test.
> Using the shops default compile and link settings.
>
> Program moves from the FD to WORKING-STORAGE before the call to the
> assembler program for all “input” parameters.
>
> I am missing something here; I do not see why this code would resolve the
> SOC4. Or has mentioned, missing something else… the unknown unknowns
>
> --
> 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: Program now working, but why?

[Peter Ten Eyck]

Job TNCA1300 runs three times on the same LPAR with the same data and id.

Run 1 – production COBOL program, calls production assembler program, runs 
successfully.

Bring production COBOL program into a development PDS and compile program 
without changes.

Run 2- development program, calls production assembler program, fails with SOC4 
in assembler program.

Add these two lines of code to COBOL program to bypass header record on input 
dataset:

 IF WS-NA-RECORDS-READ EQUAL 1
GO TO 1200-READ-MASTER.

Compile COBOL program with change. Compile output messages identical to first 
compile.

Run 3 – development COBOL program (changed), calls production assembler 
program, runs successfully.

Note: No overrides or changes to AMODE, RMODE or DATA during the test. Using 
the shops default compile and link settings.

Program moves from the FD to WORKING-STORAGE before the call to the assembler 
program for all “input” parameters.

I am missing something here; I do not see why this code would resolve the SOC4. 
Or has mentioned, missing something else… the unknown unknowns

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

Re: zOS SYSPROG jobs

[R.S.]

W dniu 2017-02-07 o 17:58, Bobbie Justice pisze:

I've seen several for NYC and places close to NYC (no thank you).

There are companies that don't like U.S. employees doing remote work for whatever bogus reason. 
They will post the job as "onsite only", then six months later they will outsource those 
jobs to India falsely claiming that "they can't find workers in the U.S.".
Would it change much if they'd said "we moved those jobs to India, 
because it's cheaper" or even ""we moved those jobs to India, becausewe 
wanted to"?


--
Radoslaw Skorupka
Lodz, Poland






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

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

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


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

Re: IBM's Marissa Mayer moment: Staff ordered to work in one of 6 main offices – or face the axe

[Chuck Kreiter]

Great...following the path of a failed company and leader.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Regan
Sent: Wednesday, February 8, 2017 7:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM's Marissa Mayer moment: Staff ordered to work in one of 6 main 
offices – or face the axe

https://www.theregister.co.uk/2017/02/08/ibm_no_more_telecommuting/


--
Mark T. Regan, K8MTR

--
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: CPACF DES/TDES enablement feature 3863 with no Co Processors/Express Cards

[Crispin Hugo]

Will do. It will be some as this whole area is new to me.

Crispin Hugo
Systems Specialist
Macro 4 Limited
d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | www.macro4.com

      

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: 08 February 2017 14:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPACF DES/TDES enablement feature 3863 with no Co 
Processors/Express Cards

Inquiring minds and all, keep us posted if you can about MFA on Z, we're using 
MFA for Winders, and so far I'm not a fan. 
thanks
Carmen 

- Original Message -

From: "Crispin Hugo" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, February 8, 2017 7:55:29 AM
Subject: Re: CPACF DES/TDES enablement feature 3863 with no Co 
Processors/Express Cards 

Many thanks. I was overreading the install. 
Onto Multi Factor Authentication!. 

Crispin Hugo
Systems Specialist
Macro 4 Limited
d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | www.macro4.com 



Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS Registered in England no: 00927588 

Please consider the environment and only print this email if you really need 
to. 

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: 08 February 2017 13:37
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPACF DES/TDES enablement feature 3863 with no Co 
Processors/Express Cards 

There should be no differences in ICSF setup in a CPACF only environment. ICSF 
will query the system at startup for available hardware support. Anything that 
can't be done either by CPACF machine instructions or via software emulation 
will fail. These failures mostly relate to secure/protected encryption key 
operations. 

Mark Jacobs 

> Crispin Hugo  February 8, 2017 at 8:11 
> AM I have been tasked with setting up ICSF . We have CPACF DES/TDES 
> enablement feature 3863 with no Co Processors/Express Card on zBC12.
> All the manuals I have read only seem to show configuration as you had 
> Express cards.
> Anybody able to point me in the direction of some manuals that will 
> help me or willing to give some advice offline.
> 
> Crispin Hugo
> Systems Specialist
> Macro 4 Limited
> d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | 
> www.macro4.com
> 
> 
> 
> Registered office: The Orangery, Turners Hill Road, Worth, Crawley, 
> West Sussex, RH10 4SS Registered in England no: 00927588
> 
> Please consider the environment and only print this email if you 
> really need to.
> 
> This message (including any attachments) contains confidential 
> information that is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK 
> PRODUCT and is intended only for the individual(s) named herein. If 
> you are not the intended recipient, you are hereby notified that any 
> dissemination, distribution or copying of this email is strictly 
> prohibited. If you have received this message in error, please notify 
> the Macro 4 Postmaster (postmas...@macro4.com) of the error 
> immediately, do not read or use the email and any attachments in any 
> manner, destroy all copies, and delete it from your system if the 
> communication was sent via email. Macro 4 Limited, Tel: +44 1293
> 

Re: CPACF DES/TDES enablement feature 3863 with no Co Processors/Express Cards

[Carmen Vitullo]

Inquiring minds and all, keep us posted if you can about MFA on Z, we're using 
MFA for Winders, and so far I'm not a fan. 
thanks 
Carmen 

- Original Message -

From: "Crispin Hugo"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 8, 2017 7:55:29 AM 
Subject: Re: CPACF DES/TDES enablement feature 3863 with no Co 
Processors/Express Cards 

Many thanks. I was overreading the install. 
Onto Multi Factor Authentication!. 

Crispin Hugo 
Systems Specialist 
Macro 4 Limited 
d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | www.macro4.com 



Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS 
Registered in England no: 00927588 

Please consider the environment and only print this email if you really need 
to. 

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001. 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv 
Sent: 08 February 2017 13:37 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: CPACF DES/TDES enablement feature 3863 with no Co 
Processors/Express Cards 

There should be no differences in ICSF setup in a CPACF only environment. ICSF 
will query the system at startup for available hardware support. Anything that 
can't be done either by CPACF machine instructions or via software emulation 
will fail. These failures mostly relate to secure/protected encryption key 
operations. 

Mark Jacobs 

> Crispin Hugo  February 8, 2017 at 8:11 
> AM I have been tasked with setting up ICSF . We have CPACF DES/TDES 
> enablement feature 3863 with no Co Processors/Express Card on zBC12. 
> All the manuals I have read only seem to show configuration as you had 
> Express cards. 
> Anybody able to point me in the direction of some manuals that will 
> help me or willing to give some advice offline. 
> 
> Crispin Hugo 
> Systems Specialist 
> Macro 4 Limited 
> d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | 
> www.macro4.com 
> 
> 
> 
> Registered office: The Orangery, Turners Hill Road, Worth, Crawley, 
> West Sussex, RH10 4SS Registered in England no: 00927588 
> 
> Please consider the environment and only print this email if you 
> really need to. 
> 
> This message (including any attachments) contains confidential 
> information that is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK 
> PRODUCT and is intended only for the individual(s) named herein. If 
> you are not the intended recipient, you are hereby notified that any 
> dissemination, distribution or copying of this email is strictly 
> prohibited. If you have received this message in error, please notify 
> the Macro 4 Postmaster (postmas...@macro4.com) of the error 
> immediately, do not read or use the email and any attachments in any 
> manner, destroy all copies, and delete it from your system if the 
> communication was sent via email. Macro 4 Limited, Tel: +44 1293 
> 872000 Fax: +44 1293 872001. 
> 
> 
> 
> -- 
> This e-mail message has been scanned and cleared by Google Message 
> Security and the UNICOM Global security systems. This message is for 
> the named person's use only. If you receive this message in error, 
> please delete it and notify the sender. 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> 
> 
> Please be alert for any emails that may ask you for login information 
> or directs you to login via a link. If you believe this message is a 
> phish or aren't sure whether this message is trustworthy, please send 
> the original message as an attachment to 'phish...@timeinc.com'. 
> 

-- 

Mark Jacobs 
Time Customer Service 
Global Technology Services 

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


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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you 

Re: Program now working, but why?

[Peter Ten Eyck]

Good morning, great feedback overnight. I am going to go back to the beginning, 
reproduce the successful run and error run myself. Not that I do not trust the 
programmer, but I need to be sure of the order of events and the changes made. 
I will report back my findings.

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

Re: CPACF DES/TDES enablement feature 3863 with no Co Processors/Express Cards

[Crispin Hugo]

Many thanks. I was overreading the install.
Onto Multi Factor Authentication!.

Crispin Hugo
Systems Specialist
Macro 4 Limited
d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | www.macro4.com

      

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: 08 February 2017 13:37
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPACF DES/TDES enablement feature 3863 with no Co 
Processors/Express Cards

There should be no differences in ICSF setup in a CPACF only environment. ICSF 
will query the system at startup for available hardware support. Anything that 
can't be done either by CPACF machine instructions or via software emulation 
will fail. These failures mostly relate to secure/protected encryption key 
operations.

Mark Jacobs

> Crispin Hugo  February 8, 2017 at 8:11 
> AM I have been tasked with setting up ICSF . We have CPACF DES/TDES 
> enablement feature 3863 with no Co Processors/Express Card on zBC12.
> All the manuals I have read only seem to show configuration as you had 
> Express cards.
> Anybody able to point me in the direction of some manuals that will 
> help me or willing to give some advice offline.
>
> Crispin Hugo
> Systems Specialist
> Macro 4 Limited
> d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | 
> www.macro4.com
>
>
>
> Registered office: The Orangery, Turners Hill Road, Worth, Crawley, 
> West Sussex, RH10 4SS Registered in England no: 00927588
>
> Please consider the environment and only print this email if you 
> really need to.
>
> This message (including any attachments) contains confidential 
> information that is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK 
> PRODUCT and is intended only for the individual(s) named herein. If 
> you are not the intended recipient, you are hereby notified that any 
> dissemination, distribution or copying of this email is strictly 
> prohibited. If you have received this message in error, please notify 
> the Macro 4 Postmaster (postmas...@macro4.com) of the error 
> immediately, do not read or use the email and any attachments in any 
> manner, destroy all copies, and delete it from your system if the 
> communication was sent via email. Macro 4 Limited, Tel: +44 1293
> 872000 Fax: +44 1293 872001.
>
>
>
> --
> This e-mail message has been scanned and cleared by Google Message 
> Security and the UNICOM Global security systems. This message is for 
> the named person's use only. If you receive this message in error, 
> please delete it and notify the sender.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> Please be alert for any emails that may ask you for login information 
> or directs you to login via a link. If you believe this message is a 
> phish or aren't sure whether this message is trustworthy, please send 
> the original message as an attachment to 'phish...@timeinc.com'.
>

-- 

Mark Jacobs
Time Customer Service
Global Technology Services

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


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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: CPACF DES/TDES enablement feature 3863 with no Co Processors/Express Cards

[R.S.]

W dniu 2017-02-08 o 14:11, Crispin Hugo pisze:

I have been tasked with setting up ICSF . We  have CPACF DES/TDES enablement 
feature 3863 with no Co Processors/Express Card on zBC12.
All the manuals I have read only seem to show configuration as you had Express 
cards.
Anybody able to point me in the direction of some manuals that will help me or 
willing to give some advice offline.


Just start CSF started task.

--
Radoslaw Skorupka
Lodz, Poland






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

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

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


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

Re: CPACF DES/TDES enablement feature 3863 with no Co Processors/Express Cards

[Mark Jacobs - Listserv]

There should be no differences in ICSF setup in a CPACF only 
environment. ICSF will query the system at startup for available 
hardware support. Anything that can't be done either by CPACF machine 
instructions or via software emulation will fail. These failures mostly 
relate to secure/protected encryption key operations.


Mark Jacobs


Crispin Hugo 
February 8, 2017 at 8:11 AM
I have been tasked with setting up ICSF . We have CPACF DES/TDES 
enablement feature 3863 with no Co Processors/Express Card on zBC12.
All the manuals I have read only seem to show configuration as you had 
Express cards.
Anybody able to point me in the direction of some manuals that will 
help me or willing to give some advice offline.


Crispin Hugo
Systems Specialist
Macro 4 Limited
d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | 
www.macro4.com




Registered office: The Orangery, Turners Hill Road, Worth, Crawley, 
West Sussex, RH10 4SS

Registered in England no: 00927588

Please consider the environment and only print this email if you 
really need to.


This message (including any attachments) contains confidential 
information that is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK 
PRODUCT and is intended only for the individual(s) named herein. If 
you are not the intended recipient, you are hereby notified that any 
dissemination, distribution or copying of this email is strictly 
prohibited. If you have received this message in error, please notify 
the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any 
manner, destroy all copies, and delete it from your system if the 
communication was sent via email. Macro 4 Limited, Tel: +44 1293 
872000 Fax: +44 1293 872001.




--
This e-mail message has been scanned and cleared by Google Message 
Security

and the UNICOM Global security systems. This message is for the named
person's use only. If you receive this message in error, please delete it
and notify the sender.

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


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




--

Mark Jacobs
Time Customer Service
Global Technology Services

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


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

CPACF DES/TDES enablement feature 3863 with no Co Processors/Express Cards

[Crispin Hugo]

I have been tasked with setting up ICSF . We  have CPACF DES/TDES enablement 
feature 3863 with no Co Processors/Express Card on zBC12.
All the manuals I have read only seem to show configuration as you had Express 
cards.
Anybody able to point me in the direction of some manuals that will help me or 
willing to give some advice offline.

Crispin Hugo
Systems Specialist
Macro 4 Limited
d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | www.macro4.com

      

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001.



-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: "Fraud detection failure" messages

[van der Grijn, Bart (B)]

I get the same. I figured it was some software we're running internally. 
I assume it's because the message comes in disguised as me but from a userid 
that's not me. 
Bart

-Original Message-

> Does anyone else get these messages when they respond? I have noticed this
> the last several times I have posted. Not so much before that, though.
>
> [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>
> Bill Hitefield
> Dino-Software Corporation
> 800.480.DINO
> 423.878.5660
> www.dino-software.com

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

Re: HMC V2.x max USB flash drive size

[R.S.]

W dniu 2017-02-08 o 05:12, Brian Westerman pisze:

HI,

Does anyone know what the maximum USB flash drive size is you can use on the 
HMC for the Version 2.x (Linux based) HMC's?

We added some maintenance to the z13s this weekend, and when the next backup 
ran, it ended up giving us a message that it couldn't create it because it was 
larger than 4GB (which is the VFAT restriction), we reformatted it as EXT2, but 
we were wondering if there was any reason to not just go out and get a 128GB or 
256GB USB drive (or a USB hard drive) and format it as EXT2, instead of the 
small one that was provided with the z13s.  it really is a handy place to keep 
the documentation and some recovery files, but we don't want to constrict the 
backups by using space without knowing the limitations.


I expect the only restriction is EXT2 limit, which is at least 4TB (it 
depends on other factors).


BTW: If you really want to know, why don't you check it? Take any 
USB-attached HDD, format it as EXT2 and plug to HMC.


BTW2: I believe that limit for the size is not big issue, the problem 
could be with USB pendrives with some "fancy" feature like HW 
encryption, additional microSD reader, etc.

It has to be "plain" USB drive, with proper filesystem and nothing else.

--
Radoslaw Skorupka
Lodz, Poland






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

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

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


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

IBM's Marissa Mayer moment: Staff ordered to work in one of 6 main offices – or face the axe

[Mark Regan]

https://www.theregister.co.uk/2017/02/08/ibm_no_more_telecommuting/


-- 
Mark T. Regan, K8MTR

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

Re: SFTP on z/OS

[Allan Staller]

Most likely transfer options. You have "proved" sftp works, so this issue is 
probably unique to the specific transfer.


Almost all issue are resolved for transferring file using sftp but now we have 
got requirement to get receive file from as400 to mainframe using sftp. But 
when I try to sftp file from as400 to mainframe , data file getting trauncated 
. To isolate this issue I even tried checking file in omvs before coming to 
dataset level but in omvs also file is truncated.
Please suggest.



::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: IBM SR process -- brilliant

[Allan Staller]

Refrain: The "new" tools are neither as reliable, available or functional as 
those they replace


So today I'm trying to open an ETR. I fight my way to the page, enter the info, 
and it offers me CANCEL or SAVE AS DRAFT. So I do the latter; that still offers 
me no way to submit it.

I open a help request on the ETR process. First response: they ask me for my 
email address - VIA EMAIL, with the email ID already in the body of what 
they're sending, not to mention, of course, being on the To: line. They also 
want a screenshot. Which I send. That gets me a response:

After reviewing the information in the system and your account, we couldn't 
find the solution at this moment, please recreate the ticket and close this one 
or delete it after creating a new one.

So, um, your system is demonstrably broken, and you think trying again will 
work? I don't think so.

 I finally figured it out (no thanks to IBM): there was an *earlier* page where 
I was supposed to select which customer this was for. But there were no 
customers displayed, so I just clicked Submit, which it accepted.

So rather than just offering "Save as draft", that earlier Submit should have 
failed, or at least told me "You're gonna need to associate a customer with 
this ticket before you'll be able to submit it". And of course the "Add" wasn't 
marked as a link, so was easy to miss (what is it with web page designers 
deliberately hiding links??).

Meanwhile, the pages are full of the TLA "ICN". In 35+ years of being an IBM 
customer I'd never seen it before; it happens that I was able to infer what it 
was, but gee, they sure are being parsimonious, saving those letters instead of 
spelling it out.

My question is: how many people here look at "ICN" and say "Oh yeah, I 
instantly know what that means? Don't post what it means here and ruin it for 
everyone else, just say whether you knew it or not!



::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: IBM Netview Session Manager replacement

[Timothy Sipples]

"Don't panic." IBM Tivoli NetView Access Services ("NVAS"), IBM Program
Number 5698-NAS, will be withdrawn from marketing on October 2, 2017. There
is no End of Service date listed, so full support for NVAS continues.

IBM CL/SUPERSESSION Version 2.1, which became generally available in
December, 2015, is the replacement product. That's IBM Program Number
5601-B28. If you're interested in CL/SUPERSESSION, "talk to your friendly
IBM representative." However, again, no need to panic.

IBM Session Manager for z/OS (5655-U98) was withdrawn from marketing on
January 2, 2017. The End of Service date is December 31, 2018.


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: HMC V2.x max USB flash drive size

[Tom Mathias]

Brian,

Parwez provided a good list of the drives that have been formally tested and 
therefore are supported.  As stated, a drive up to 32 GB is supported.  Other 
drives may or may not work.  In my personal experience I have seen most other 
drives work properly, but I have encountered some brands/types that failed to 
properly mount or otherwise work.  The issues I've seen were not related to the 
size, but instead it was specific to the brand/type.  So, to directly answer 
your question, I do not know of any explicit code to limit the size of the USB 
(although the underlying OS might), but it has to work with the underlying 
Operating System.

Regardless of the type of USB you use (one on the list or a different one), it 
is important that you follow good backup procedures, such as performing regular 
backups, using more than one device, and making sure they are kept in a safe, 
secure location.  Sadly there have been cases where only one backup was made 
and the device was either lost or turned out to be bad when it was really 
needed.  And there were other cases where regular backups were scheduled, but 
unfortunately the device was removed at some point and messages about backup 
failures were ignored and...I think you get the point.

Tom

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

Re: HMC V2.x max USB flash drive size

[Parwez Hamid]

This is what's in the HMC documentation.

USB flash memory drives

If you are instructed to use a USB flash memory drive for any procedure, the 
following drives have been
tested and approved:
v P/N 22P9229 - IBM USB 2.0 High Speed Memory Key - 128 MB
v P/N 40Y8596 - Lenovo USB 2.0 Memory Key - 512 MB
v P/N 41U5118 - Lenovo USB 2.0 Security Memory Key - 1.0 GB (The security 
feature is not supported.)
v P/N 77P9278 - Smart Modular Technology (SMT) 4GB Memory Key
v P/N 77P9279 - Smart Modular Technology (SMT) 8GB Memory Key
v P/N 78P3777 - Smart Modular Technology (SMT) 32GB Memory Key

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