Re: Visara CNA8000 question

[Peter Bishop]

Hi,

currently we have a TR link going into a FEP which connects via bus and tag to 
a 9034 which then connects via ESCON to a z196, but we're going z13 and so need 
FICON link.  The CNA8000 would appear to be able to replace both the FEP and 
the 9034 if we configure it right as it has TR and FICON ports.  We're stuck 
with TR.

cheers,
Peter 




On Fri, 21 Jul 2017 12:30:24 +, Jim Stefanik  wrote:

>I would ask the same question - what's the end-goal?  If you're just trying to 
>test something or revive some old gear for a while, an IBM 8229 LAN Bridge can 
>be had for bugger all off eBay.  It just bridges traffic between an Ethernet 
>LAN and a token ring LAN.  If this is a more permanent thing, there are 
>probably more modern and better supported solutions, since the 8229 is quite 
>old (20+ years...!).  I wouldn't recommend using an 8229 in a production 
>environment for anything critical due to its age and lack of support from IBM.

-Jim



From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Friday, July 21, 2017 06:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Visara CNA8000 question

W dniu 2017-07-21 o 07:49, Peter Bishop pisze:
> Hi,
>
> we have a possible need to connect a token-ring link to a z13 (don't ask) and 
> were considering one option, but now another has appeared.
>
> We're wondering if anyone else is using a Visara CNA8000 for this?  It seems 
> a simpler option than the other one as it takes a token-ring link on one side 
> and a FICON link on the other.

What's your goal?
For that excercise I would ask what about TR and Eth networks connected
via some router supporting TCP/IP protocol.
For Visara I bet you could get something like local (non-SNA) console
with TR connection, but from host point of view it works like OSA-ICC
console/terminal.

--
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.pls�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

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

Re: What to do with PTF dogies?

[Paul Gilmartin]

On 2017-07-21, at 18:38, Jesse 1 Robinson wrote:

> Another mystery. The full.txt HOLDDATA file contains no ++ASSIGN entries at 
> all. 
>  
Don't those have to appear in SMPPTFIN, whereas ++HOLD appears in SMPHOLD
(except for SYSTEM, which may appear in either.)

(Well, I've put ++ASSIGN only in SMPPTFIN.  I sometimes use an otiose
++ASSIGN in lieu of ++NULL, which can appear only in SMPHOLD.)

Rules, rules, rules.

-- gil

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

Re: What to do with PTF dogies?

[Jesse 1 Robinson]

Another mystery. The full.txt HOLDDATA file contains no ++ASSIGN entries at 
all. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, July 21, 2017 4:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What to do with PTF dogies?

We may have the answer for this PTF and probably others in a similar state. 
FMID HNVL11B is SUPBY HNVL12B in the target, but there are remnants of it in 
the GLOBAL *not* including the FMID entry itself. 

OTOH the full.txt file I just pulled does not mention UA74273 at all. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Longabaugh, Robert E
Sent: Friday, July 21, 2017 4:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What to do with PTF dogies?

Maybe try a REPORT SOURCEID and see if any RSU show up.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, July 21, 2017 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What to do with PTF dogies?

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


This may be at least in part a mechanical problem. Before I open an SR, I'd 
like to show one example. In our GLOBAL, UA74273 looks like this:

SOURCEID ALLAVAIL
 ORD00020
 PUT1410
 SMCCOR

No RSU assigned. However, SIS shows this:

RSU ...   1503

We routinely receive full HOLDDATA. I just did it again with 'get full.txt'. No 
entry for UA74273. Any obvious mistake on our part?

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Thursday, July 20, 2017 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What to do with PTF dogies?

Since I wound up in a meeting with someone on the CST team, I verified that 
everything is supposed to eventually be marked RSU, even PTFs for products that 
are not part of CST, based on age.  There are windowing factors make the delay 
between COR-close and RSU vary, but generally we would expect everything that 
was COR-closed by March to have been marked RSU by now.

The simplest way to see if something else is holding up your dogies (other than 
a lariat) is to run an APPLY CHECK with a SELECT list and see whether:

(a) they are actually not applicable to the zone for one reason or another; or,
(b) some PRE or IF chain is holding them up (e.g., due to a PE); or,
(c) they are not old enough to be summarily marked RSU by age; or,
(d) we somehow missed marking them RSU when they came of age.

If you think your dogies are in (d), please send me some examples and I'll 
forward to the team.  Maybe we need to "steer" something in the right direction.

Jesse 1 Robinson wrote:
> I have reviewed our current list of unapplied PTFs from LIST NOAPPLY(). The 
> real (unexplained) dogies are way fewer than I expected, fewer than I've seen 
> in the past. Maybe this has become a non-problem. I do want to make a point 
> that some folks may have missed. From the get-go, RSU was not merely a 
> relabeling of PTF bundling. PTFs included in an RSU have been tested 
> together, providing a new level of confidence over PUT, which was a temporal 
> packaging concept, not a functional one. With PUT, the chance of 
> incompatibility among PTFs is greater than with RSU.
>
> I agree that a small number of dogies should be taken to IBM for explanation.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tom Marchant
> Sent: Thursday, July 20, 2017 7:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: What to do with PTF dogies?
>
> On Thu, 20 Jul 2017 09:57:31 -0400, Tom Conley wrote:
>
>> I'd ask the question "How come these PTF's aren't in an RSU?"
>> Shouldn't they have gone through CST at some point?
>
> I would think so too, unless they have been SUP'ed.
>
> --
> Tom Marchant
--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

Re: What to do with PTF dogies?

[Jesse 1 Robinson]

We may have the answer for this PTF and probably others in a similar state. 
FMID HNVL11B is SUPBY HNVL12B in the target, but there are remnants of it in 
the GLOBAL *not* including the FMID entry itself. 

OTOH the full.txt file I just pulled does not mention UA74273 at all. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Longabaugh, Robert E
Sent: Friday, July 21, 2017 4:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What to do with PTF dogies?

Maybe try a REPORT SOURCEID and see if any RSU show up.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, July 21, 2017 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What to do with PTF dogies?

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


This may be at least in part a mechanical problem. Before I open an SR, I'd 
like to show one example. In our GLOBAL, UA74273 looks like this:

SOURCEID ALLAVAIL
 ORD00020
 PUT1410
 SMCCOR

No RSU assigned. However, SIS shows this:

RSU ...   1503

We routinely receive full HOLDDATA. I just did it again with 'get full.txt'. No 
entry for UA74273. Any obvious mistake on our part?

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Thursday, July 20, 2017 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What to do with PTF dogies?

Since I wound up in a meeting with someone on the CST team, I verified that 
everything is supposed to eventually be marked RSU, even PTFs for products that 
are not part of CST, based on age.  There are windowing factors make the delay 
between COR-close and RSU vary, but generally we would expect everything that 
was COR-closed by March to have been marked RSU by now.

The simplest way to see if something else is holding up your dogies (other than 
a lariat) is to run an APPLY CHECK with a SELECT list and see whether:

(a) they are actually not applicable to the zone for one reason or another; or,
(b) some PRE or IF chain is holding them up (e.g., due to a PE); or,
(c) they are not old enough to be summarily marked RSU by age; or,
(d) we somehow missed marking them RSU when they came of age.

If you think your dogies are in (d), please send me some examples and I'll 
forward to the team.  Maybe we need to "steer" something in the right direction.

Jesse 1 Robinson wrote:
> I have reviewed our current list of unapplied PTFs from LIST NOAPPLY(). The 
> real (unexplained) dogies are way fewer than I expected, fewer than I've seen 
> in the past. Maybe this has become a non-problem. I do want to make a point 
> that some folks may have missed. From the get-go, RSU was not merely a 
> relabeling of PTF bundling. PTFs included in an RSU have been tested 
> together, providing a new level of confidence over PUT, which was a temporal 
> packaging concept, not a functional one. With PUT, the chance of 
> incompatibility among PTFs is greater than with RSU.
>
> I agree that a small number of dogies should be taken to IBM for explanation.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tom Marchant
> Sent: Thursday, July 20, 2017 7:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: What to do with PTF dogies?
>
> On Thu, 20 Jul 2017 09:57:31 -0400, Tom Conley wrote:
>
>> I'd ask the question "How come these PTF's aren't in an RSU?"
>> Shouldn't they have gone through CST at some point?
>
> I would think so too, unless they have been SUP'ed.
>
> --
> Tom Marchant
--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com


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

Re: What to do with PTF dogies?

[Longabaugh, Robert E]

Maybe try a REPORT SOURCEID and see if any RSU show up.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, July 21, 2017 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What to do with PTF dogies?

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


This may be at least in part a mechanical problem. Before I open an SR, I'd 
like to show one example. In our GLOBAL, UA74273 looks like this:

SOURCEID ALLAVAIL
 ORD00020
 PUT1410
 SMCCOR

No RSU assigned. However, SIS shows this:

RSU ...   1503

We routinely receive full HOLDDATA. I just did it again with 'get full.txt'. No 
entry for UA74273. Any obvious mistake on our part?

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Thursday, July 20, 2017 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What to do with PTF dogies?

Since I wound up in a meeting with someone on the CST team, I verified that 
everything is supposed to eventually be marked RSU, even PTFs for products that 
are not part of CST, based on age.  There are windowing factors make the delay 
between COR-close and RSU vary, but generally we would expect everything that 
was COR-closed by March to have been marked RSU by now.

The simplest way to see if something else is holding up your dogies (other than 
a lariat) is to run an APPLY CHECK with a SELECT list and see whether:

(a) they are actually not applicable to the zone for one reason or another; or,
(b) some PRE or IF chain is holding them up (e.g., due to a PE); or,
(c) they are not old enough to be summarily marked RSU by age; or,
(d) we somehow missed marking them RSU when they came of age.

If you think your dogies are in (d), please send me some examples and I'll 
forward to the team.  Maybe we need to "steer" something in the right direction.

Jesse 1 Robinson wrote:
> I have reviewed our current list of unapplied PTFs from LIST NOAPPLY(). The 
> real (unexplained) dogies are way fewer than I expected, fewer than I've seen 
> in the past. Maybe this has become a non-problem. I do want to make a point 
> that some folks may have missed. From the get-go, RSU was not merely a 
> relabeling of PTF bundling. PTFs included in an RSU have been tested 
> together, providing a new level of confidence over PUT, which was a temporal 
> packaging concept, not a functional one. With PUT, the chance of 
> incompatibility among PTFs is greater than with RSU.
>
> I agree that a small number of dogies should be taken to IBM for explanation.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tom Marchant
> Sent: Thursday, July 20, 2017 7:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: What to do with PTF dogies?
>
> On Thu, 20 Jul 2017 09:57:31 -0400, Tom Conley wrote:
>
>> I'd ask the question "How come these PTF's aren't in an RSU?"
>> Shouldn't they have gone through CST at some point?
>
> I would think so too, unless they have been SUP'ed.
>
> --
> Tom Marchant
--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com


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

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

Re: What to do with PTF dogies?

[Jesse 1 Robinson]

This may be at least in part a mechanical problem. Before I open an SR, I'd 
like to show one example. In our GLOBAL, UA74273 looks like this:

SOURCEID ALLAVAIL
 ORD00020
 PUT1410 
 SMCCOR  

No RSU assigned. However, SIS shows this:

RSU ...   1503

We routinely receive full HOLDDATA. I just did it again with 'get full.txt'. No 
entry for UA74273. Any obvious mistake on our part?

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Thursday, July 20, 2017 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What to do with PTF dogies?

Since I wound up in a meeting with someone on the CST team, I verified that 
everything is supposed to eventually be marked RSU, even PTFs for products that 
are not part of CST, based on age.  There are windowing factors make the delay 
between COR-close and RSU vary, but generally we would expect everything that 
was COR-closed by March to have been marked RSU by now.

The simplest way to see if something else is holding up your dogies (other than 
a lariat) is to run an APPLY CHECK with a SELECT list and see whether:

(a) they are actually not applicable to the zone for one reason or another; or,
(b) some PRE or IF chain is holding them up (e.g., due to a PE); or,
(c) they are not old enough to be summarily marked RSU by age; or,
(d) we somehow missed marking them RSU when they came of age.

If you think your dogies are in (d), please send me some examples and I'll 
forward to the team.  Maybe we need to "steer" something in the right direction.

Jesse 1 Robinson wrote:
> I have reviewed our current list of unapplied PTFs from LIST NOAPPLY(). The 
> real (unexplained) dogies are way fewer than I expected, fewer than I've seen 
> in the past. Maybe this has become a non-problem. I do want to make a point 
> that some folks may have missed. From the get-go, RSU was not merely a 
> relabeling of PTF bundling. PTFs included in an RSU have been tested 
> together, providing a new level of confidence over PUT, which was a temporal 
> packaging concept, not a functional one. With PUT, the chance of 
> incompatibility among PTFs is greater than with RSU.
>
> I agree that a small number of dogies should be taken to IBM for explanation.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tom Marchant
> Sent: Thursday, July 20, 2017 7:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: What to do with PTF dogies?
>
> On Thu, 20 Jul 2017 09:57:31 -0400, Tom Conley wrote:
>
>> I'd ask the question "How come these PTF's aren't in an RSU?"
>> Shouldn't they have gone through CST at some point?
>
> I would think so too, unless they have been SUP'ed.
>
> --
> Tom Marchant
--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com


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

Re: Graph HCD Reports

[Edward Finnell]

That's sorta what we ended up doing. Only used the DCF to create a Post  
Script file as input to AUTOCAD.
 
 
In a message dated 7/21/2017 7:31:30 A.M. Central Daylight Time,  
randy.hoeks...@haworth.com writes:

HCD  option 4 Create or view graphical configuration report will create a 
DCF  output file when you choose Output = 2. I found a DCF to HTML REXX that 
will  convert the downloaded file to HTML, the output is not perfect but 
very  useable. I ran it on my Windows machine using the Regina REXX  
Interpreter.


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

Re: IOCDF issue

[Matthew Stitt]

For what it's worth, here is the parts of my I/O configuration which deals with 
the CTC.  Sorry for the long post, but we do have cross CSS definitions which 
are active.  Please note the CUADD is the DESTINATION LPAR.  The first digit of 
the CUADD is the CSS, the second digit is the LPAR.

CHPID PATH=(CSS(0,1),53),SHARED,  *
  NOTPART=((CSS(0),(CF1,CF2),(=)),(CSS(1),(ZOSWK1,ZOSWK2),*
  (=))),PCHID=1E5,TYPE=FC  
 CHPID PATH=(CSS(0,1),D3),SHARED,  *
   NOTPART=((CSS(0),(CF1,CF2),(=)),(CSS(1),(ZOSWK1,ZOSWK2),*
   (=))),PCHID=125,TYPE=FC 
CNTLUNIT CUNUMBR=5301,PATH=((CSS(0),53),(CSS(1),53)), * 
  UNITADD=((00,008)),CUADD=1,UNIT=FCTC  
IODEVICE ADDRESS=(5310,004),UNITADD=00,CUNUMBR=(5301),* 
  STADET=Y,UNIT=FCTC
CNTLUNIT CUNUMBR=5302,PATH=((CSS(0),53),(CSS(1),53)), * 
  UNITADD=((00,008)),CUADD=2,UNIT=FCTC  
IODEVICE ADDRESS=(5320,004),UNITADD=00,CUNUMBR=(5302),* 
  STADET=Y,UNIT=FCTC
CNTLUNIT CUNUMBR=5303,PATH=((CSS(0),53),(CSS(1),53)), * 
  UNITADD=((00,008)),CUADD=3,UNIT=FCTC  
IODEVICE ADDRESS=(5330,004),UNITADD=00,CUNUMBR=(5303),* 
  STADET=Y,UNIT=FCTC
CNTLUNIT CUNUMBR=5304,PATH=((CSS(0),53),(CSS(1),53)), * 
  UNITADD=((00,008)),CUADD=4,UNIT=FCTC  
IODEVICE ADDRESS=(5340,004),UNITADD=00,CUNUMBR=(5304),* 
  STADET=Y,UNIT=FCTC
CNTLUNIT CUNUMBR=5305,PATH=((CSS(0),53),(CSS(1),53)), * 
  UNITADD=((00,008)),CUADD=5,UNIT=FCTC  
IODEVICE ADDRESS=(5350,004),UNITADD=00,CUNUMBR=(5305),* 
  STADET=Y,UNIT=FCTC
CNTLUNIT CUNUMBR=5306,PATH=((CSS(0),53),(CSS(1),53)), * 
  UNITADD=((00,008)),CUADD=6,UNIT=FCTC  
IODEVICE ADDRESS=(5360,004),UNITADD=00,CUNUMBR=(5306),* 
  STADET=Y,UNIT=FCTC
CNTLUNIT CUNUMBR=5307,PATH=((CSS(0),53),(CSS(1),53)), * 
  UNITADD=((00,008)),CUADD=7,UNIT=FCTC  
IODEVICE ADDRESS=(5370,004),UNITADD=00,CUNUMBR=(5307),* 
  STADET=Y,UNIT=FCTC
CNTLUNIT CUNUMBR=5308,PATH=((CSS(0),53),(CSS(1),53)), * 
  UNITADD=((00,008)),CUADD=8,UNIT=FCTC  
IODEVICE ADDRESS=(5380,004),UNITADD=00,CUNUMBR=(5308),* 
  STADET=Y,UNIT=FCTC
CNTLUNIT CUNUMBR=5309,PATH=((CSS(0),53),(CSS(1),53)), * 
  UNITADD=((00,008)),CUADD=9,UNIT=FCTC  
IODEVICE ADDRESS=(5390,004),UNITADD=00,CUNUMBR=(5309),* 
  STADET=Y,UNIT=FCTC
CNTLUNIT CUNUMBR=530A,PATH=((CSS(0),53),(CSS(1),53)), * 
  UNITADD=((00,008)),CUADD=A,UNIT=FCTC  
IODEVICE ADDRESS=(53A0,004),UNITADD=00,CUNUMBR=(530A),*
  STADET=Y,UNIT=FCTC   
CNTLUNIT CUNUMBR=530B,PATH=((CSS(0),53),(CSS(1),53)), *
  UNITADD=((00,008)),CUADD=B,UNIT=FCTC 
IODEVICE ADDRESS=(53B0,004),UNITADD=00,CUNUMBR=(530B),*
  STADET=Y,UNIT=FCTC   
CNTLUNIT CUNUMBR=530C,PATH=((CSS(0),53),(CSS(1),53)), *
  UNITADD=((00,008)),CUADD=C,UNIT=FCTC 
IODEVICE ADDRESS=(53C0,004),UNITADD=00,CUNUMBR=(530C),*
  STADET=Y,UNIT=FCTC   
CNTLUNIT CUNUMBR=530D,PATH=((CSS(0),53),(CSS(1),53)), *
  UNITADD=((00,008)),CUADD=D,UNIT=FCTC 
CNTLUNIT CUNUMBR=530E,PATH=((CSS(0),53),(CSS(1),53)), *
  UNITADD=((00,008)),CUADD=E,UNIT=FCTC 
CNTLUNIT CUNUMBR=530F,PATH=((CSS(0),53),(CSS(1),53)), *
  UNITADD=((00,008)),CUADD=F,UNIT=FCTC 
CNTLUNIT CUNUMBR=5311,PATH=((CSS(0),53),(CSS(1),53)), *
  UNITADD=((00,004)),CUADD=11,UNIT=FCTC
IODEVICE ADDRESS=(5318,004),UNITADD=00,CUNUMBR=(5311),*
  STADET=Y,UNIT=FCTC   
CNTLUNIT CUNUMBR=5312,PATH=((CSS(0),53),(CSS(1),53)), *
  UNITADD=((00,004)),CUADD=12,UNIT=FCTC
IODEVICE ADDRESS=(5328,004),UNITADD=00,CUNUMBR=(5312),*
  STADET=Y,UNIT=FCTC   
CNTLUNIT CUNUMBR=5313,PATH=((CSS(0),53),(CSS(1),53)), *
  UNITADD=((00,004)),CUADD=13,UNIT=FCTC
IODEVICE ADDRESS=(5338,004),UNITADD=00,CUNUMBR=(5313),*
  STADET=Y,UNIT=FCTC   
CNTLUNIT 

Re: Backing up EMC DLM

[Tom Brennan]

Thanks Jerry, that helps.

Jerry Whitteridge wrote:

Tom - Think of the DLM as the head of string Tape controller (from the old 
days) that provides the UCB's. Then there is some form of Storage attached 
(think the physical tape that got mounted)  - in our case this is a DD4500 as 
an example. EMC allows only certain Storage to attach to the DLM.

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
623 869 5523
Corporate Tieline - 85523

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, July 21, 2017 4:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Backing up EMC DLM

Tom

I may be wrong, but the DLm is more like a database for the tapes.  There is no 
storage on it.  The needs to be another piece of equipment to provide the 
storage for the actual tape usage.

I think you are asking can you use a storage device other than EMC equipment to 
hold the actual tape data.

Is that correct?

If so, I have not seen any documentation that would indicate anything other 
than EMC equipment can be used for the DLm for their actual tape data.

This link does not show anything other than EMC equipment. Currently, VMAX, 
VNX, DD are the only devices I have seen that works with the DLm.

https://www.emc.com/collateral/hardware/data-sheet/h4207-disk-library-mainframe-
ds.pdf


So, you are probably trying to see if anyone used something other than EMC 
equipment with the DLm and was successful.



Lizette




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Tom Brennan
Sent: Thursday, July 20, 2017 7:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Backing up EMC DLM

Is anyone using a Quantum (quantum.com) device to back up data from an
EMC DLM? (Disk Library for Mainframe - looks like tape to the
mainframe)




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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


--
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: IOCDF issue

[Neubert, Kevin]

Don't believe multiple channel subsystems should be an issue if the CPC 
supports it.  CUADD=03 represents a combination of CSS 0 and MIF image ID 3.

What does your CHPID PATH=(CSS(0),08) look like?  L05 and L06 are in the access 
list?

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dave Jones
Sent: Friday, July 21, 2017 7:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IOCDF issue

All of the CTC devices at 73xx are offline and not available. so it's not just 
7302  and 7303, either.

Maybe I should delete all CTCs out of the IOCDS and recreate them all in the 
same CSS...?

--
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: Enterprise COBOL V6.2

[Jesse 1 Robinson]

Had a similar problem once with an MVS upgrade. A (very savvy) user called up 
and reported getting a JCL with a very old job. On closer inspection he 
discovered some error with a comma. Job had run for years with no problem. 
Suddenly boom. Grin and move on.

I could see a larger issue with lots of COBOL programs being no laughing matter.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Friday, July 21, 2017 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Enterprise COBOL V6.2

I don't have the answer to that one.  I imagine it's possible!  But I don't 
believe there was any specific intent for this to "uncover bad code" in 6.1, so 
you'll probably just have to see what you run in to with 6.2.

Frank


From: IBM Mainframe Discussion List  on behalf of 
Cameron Conacher 
Sent: Friday, July 21, 2017 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL V6.2

Thanks Frank.
I agree this is bad code.

I was curious if the new COBOL 6.2 compiler would uncover any other bad code.
I like that it is identified at compile time.


Sent from my iPhone

> On Jul 21, 2017, at 11:55 AM, Frank Swarbrick  
> wrote:
>
> The error is not that there is a VALUE clause in the linkage section, but 
> rather the value clause now being allowed and respected, in conjunction with 
> the fact that the particular value clause is invalid.  It should be VALUE 
> '1234', not VALUE 1234.  You would get the same error in COBOL V4 and V5 if 
> the item had been in working-storage rather than linkage.
>
> You could use a compiler exit to "downgrade" the error to a warning, if you 
> are so inclined.
>
> Frank
>
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Cameron Conacher 
> Sent: Friday, July 21, 2017 9:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Enterprise COBOL V6.2
>
> Here is a snippet from someone else's observations:
> Hi
> Just wondering has anyone confronted this compile issue stated for COBOL 6.1?
>
> Version 6.1
>
>
> COBOL source code differences in Enterprise COBOL Version 6
>
> In Enterprise COBOL V5 and earlier versions, a non-88 level VALUE 
> clause in the LINKAGE SECTION or FILE SECTION was treated as a 
> comment. However, starting in Enterprise COBOL V6.1, the VALUE clause 
> for LINKAGE SECTION and FILE SECTION items is now syntax checked and 
> has meaning. This means that a program that is compiled with RC=0 with 
> COBOL V5 could get RC=12 with COBOL V6.
>
> For example, with Enterprise COBOL V5 and earlier versions:
> 000224 LINKAGE SECTION.
> 000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
>
>
> ==000225==> IGYDS1158-I A non-level-88 "VALUE" clause was found in the 
> "FILE SECTION" or "LINKAGE SECTION". The "VALUE" clause was treated as 
> comments.
>
> With Enterprise COBOL V6:
>
> 000224 LINKAGE SECTION.
> 000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
>
> ==000225==> IGYGR1080-S A "VALUE" clause literal was not compatible 
> with the data category of the subject data item. The "VALUE" clause was 
> discarded.
>
>
> Hope that helps
>
> Sent from my iPhone
>
>> On Jul 20, 2017, at 5:25 PM, Frank Swarbrick  
>> wrote:
>>
>> I'm not clear on what you are saying here.  Can you give an example of both 
>> the code and the error message?
>>
>> 
>> From: IBM Mainframe Discussion List  on 
>> behalf of Cameron Conacher 
>> Sent: Thursday, July 20, 2017 2:43 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Enterprise COBOL V6.2
>>
>> Hello everyone.
>> COBOL 6.1 introduced a "feature" where VALUE clauses that are used 
>> for initialization are flagged as errors.
>> Ever since I began using COBL in the seventies, this would be treated 
>> as a warning.
>> Personally, I consider it bad form, but the compiler happily marched on.
>> We have a number of COPYBOOKs that are occasionally used in LINKAGE, 
>> and these items have raised issues during recompiles.
>> Nothing terrible, but still a bump in the development road.
>>
>> Are there any new features like this in COBOL 6.2?
>>
>> Thanks,
>>
>> ...Cameron
>>
>>> On Thu, Jul 20, 2017 at 8:33 AM, Tim Deller  wrote:
>>>
>>> "Conditional complication"?
>>> Sounds about right...


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

Re: EXTERNAL: Re: Backing up EMC DLM

[Jerry Whitteridge]

Tom - Think of the DLM as the head of string Tape controller (from the old 
days) that provides the UCB's. Then there is some form of Storage attached 
(think the physical tape that got mounted)  - in our case this is a DD4500 as 
an example. EMC allows only certain Storage to attach to the DLM.

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
623 869 5523
Corporate Tieline - 85523

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, July 21, 2017 4:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Backing up EMC DLM

Tom

I may be wrong, but the DLm is more like a database for the tapes.  There is no 
storage on it.  The needs to be another piece of equipment to provide the 
storage for the actual tape usage.

I think you are asking can you use a storage device other than EMC equipment to 
hold the actual tape data.

Is that correct?

If so, I have not seen any documentation that would indicate anything other 
than EMC equipment can be used for the DLm for their actual tape data.

This link does not show anything other than EMC equipment. Currently, VMAX, 
VNX, DD are the only devices I have seen that works with the DLm.

https://www.emc.com/collateral/hardware/data-sheet/h4207-disk-library-mainframe-
ds.pdf


So, you are probably trying to see if anyone used something other than EMC 
equipment with the DLm and was successful.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tom Brennan
> Sent: Thursday, July 20, 2017 7:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Backing up EMC DLM
>
> Is anyone using a Quantum (quantum.com) device to back up data from an
> EMC DLM? (Disk Library for Mainframe - looks like tape to the
> mainframe)
>

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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

Re: RES: EMC DLm to the Cloud

[Carmen Vitullo]

In my limited experience with DD (Data Domain) and DLM (emulated virtual tape) 
the issues we had was time to replicate and since we wanted the less-expensive 
solution we shared our DD with the distributed systems. 
We replicated to a local DR site, over black fiber and to a DR site almost 800 
miles away, many issue getting the bandwidth even after the initial replication 
was complete, I forget how much data we were replicating but it was not the 
entire 8870 we had. 
at DR we had support issues because at the time there was one person, maybe 2 
in the US that knew anything about DD and DLM configuration, we were left at DR 
with no support till the last minute, there were some replication issue that 
should not have been replicated, also fighting for I/O with the distributed 
folks, they had to shut down most of their TSM servers to allow us to get any 
I/O thru put. 
most if the issue I think were related to trying to get a good solution for the 
cheapest price. 
I would hope EMC has more support folks for this solution on the mainframe. 


my 2 cents 


Carmen 


- Original Message -

From: "Carlos Bodra - Pessoal"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 21, 2017 11:37:09 AM 
Subject: RES: EMC DLm to the Cloud 

I did some tests with another Vendor similar to DellEMC solution moving data 
from virtual tape to cloud and results was not good. A bigger bigger reclaim 
time to get dataset available to mainframe, and very expensive. 
I need to store about 240TB in cloud and cost quiet project. We buy more 
midrange storage and save a lot of money and get a much more fast reclaim time 
to get dataset available to restore. 

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 
R.S. 
Enviada em: sexta-feira, 21 de julho de 2017 11:52 
Para: IBM-MAIN@LISTSERV.UA.EDU 
Assunto: Re: EMC DLm to the Cloud 

W dniu 2017-07-21 o 16:32, Lizette Koehler pisze: 
> http://www.storagereview.com/dell_emc_announce_dlm_45_to_eliminate_phy 
> sical_tape 
> 
> 
> Today at SHARE 2017, Dell EMC announced the latest version of its Disk 
> Library for mainframe (DLm) virtual tape, version 4.5. The latest 
> version of Dell EMC's cloud-based virtual tape is aiming to replace 
> physical tape as the go to long-term retention strategy. Dell EMC 
> states that DLm 4.5 can make the mainframe data center more efficient 
> by moving mainframe virtual tape data to the cloud. 
> 
> 
> I am not sure how big the "cloud" would have to be for some shops. 

That's simple: a company sells no tapes. Only disk systems. 
What can they claim? 

BTW: real tapes, on foreground or just background of some VTS are really give 
way to disks. 
>From the other hand, spinning disks give way to SSDs. 
SSDs disks (more exactly: SSD with disk interface) give way to flash systems... 


-- 
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.plsą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 

Re: Enterprise COBOL V6.2

[Frank Swarbrick]

I don't have the answer to that one.  I imagine it's possible!  But I don't 
believe there was any specific intent for this to "uncover bad code" in 6.1, so 
you'll probably just have to see what you run in to with 6.2.

Frank


From: IBM Mainframe Discussion List  on behalf of 
Cameron Conacher 
Sent: Friday, July 21, 2017 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL V6.2

Thanks Frank.
I agree this is bad code.

I was curious if the new COBOL 6.2 compiler would uncover any other bad code.
I like that it is identified at compile time.


Sent from my iPhone

> On Jul 21, 2017, at 11:55 AM, Frank Swarbrick  
> wrote:
>
> The error is not that there is a VALUE clause in the linkage section, but 
> rather the value clause now being allowed and respected, in conjunction with 
> the fact that the particular value clause is invalid.  It should be VALUE 
> '1234', not VALUE 1234.  You would get the same error in COBOL V4 and V5 if 
> the item had been in working-storage rather than linkage.
>
> You could use a compiler exit to "downgrade" the error to a warning, if you 
> are so inclined.
>
> Frank
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Cameron Conacher 
> Sent: Friday, July 21, 2017 9:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Enterprise COBOL V6.2
>
> Here is a snippet from someone else's observations:
> Hi
> Just wondering has anyone confronted this compile issue stated for COBOL 6.1?
>
> Version 6.1
>
>
> COBOL source code differences in Enterprise COBOL Version 6
>
> In Enterprise COBOL V5 and earlier versions, a non-88 level VALUE clause in 
> the
> LINKAGE SECTION or FILE SECTION was treated as a comment. However,
> starting in Enterprise COBOL V6.1, the VALUE clause for LINKAGE SECTION and
> FILE SECTION items is now syntax checked and has meaning. This means that a
> program that is compiled with RC=0 with COBOL V5 could get RC=12 with
> COBOL V6.
>
> For example, with Enterprise COBOL V5 and earlier versions:
> 000224 LINKAGE SECTION.
> 000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
>
>
> ==000225==> IGYDS1158-I A non-level-88 "VALUE" clause was found in the
> "FILE SECTION" or "LINKAGE SECTION". The "VALUE" clause was treated as 
> comments.
>
> With Enterprise COBOL V6:
>
> 000224 LINKAGE SECTION.
> 000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
>
> ==000225==> IGYGR1080-S A "VALUE" clause literal was not compatible with the 
> data
> category of the subject data item. The "VALUE" clause was discarded.
>
>
> Hope that helps
>
> Sent from my iPhone
>
>> On Jul 20, 2017, at 5:25 PM, Frank Swarbrick  
>> wrote:
>>
>> I'm not clear on what you are saying here.  Can you give an example of both 
>> the code and the error message?
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Cameron Conacher 
>> Sent: Thursday, July 20, 2017 2:43 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Enterprise COBOL V6.2
>>
>> Hello everyone.
>> COBOL 6.1 introduced a "feature" where VALUE clauses that are used for
>> initialization are flagged as errors.
>> Ever since I began using COBL in the seventies, this would be treated as a
>> warning.
>> Personally, I consider it bad form, but the compiler happily marched on.
>> We have a number of COPYBOOKs that are occasionally used in LINKAGE, and
>> these items have raised issues during recompiles.
>> Nothing terrible, but still a bump in the development road.
>>
>> Are there any new features like this in COBOL 6.2?
>>
>> Thanks,
>>
>> ...Cameron
>>
>>> On Thu, Jul 20, 2017 at 8:33 AM, Tim Deller  wrote:
>>>
>>> "Conditional complication"?
>>> Sounds about right...
>>>
>>> --
>>> 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
>
> --
> 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 

RES: EMC DLm to the Cloud

[Carlos Bodra - Pessoal]

I did some tests with another Vendor similar to DellEMC solution moving data 
from virtual tape to cloud and results was not good. A bigger bigger reclaim 
time to get dataset available to mainframe, and very expensive.
I need to store about 240TB in cloud and cost quiet project. We buy more 
midrange storage and save a lot of money and get a much more fast reclaim time 
to get dataset available to restore.

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 
R.S.
Enviada em: sexta-feira, 21 de julho de 2017 11:52
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: Re: EMC DLm to the Cloud

W dniu 2017-07-21 o 16:32, Lizette Koehler pisze:
> http://www.storagereview.com/dell_emc_announce_dlm_45_to_eliminate_phy
> sical_tape
>
>
> Today at SHARE 2017, Dell EMC announced the latest version of its Disk 
> Library for mainframe (DLm) virtual tape, version 4.5. The latest 
> version of Dell EMC's cloud-based virtual tape is aiming to replace 
> physical tape as the go to long-term retention strategy. Dell EMC 
> states that DLm 4.5 can make the mainframe data center more efficient 
> by moving mainframe virtual tape data to the cloud.
>
>
> I am not sure how big the "cloud" would have to be for some shops.

That's simple: a company sells no tapes. Only disk systems.
What can they claim?

BTW: real tapes, on foreground or just background of some VTS are really give 
way to disks.
 From the other hand, spinning disks give way to SSDs.
SSDs disks (more exactly: SSD with disk interface) give way to flash systems...


--
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.plsą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: Enterprise COBOL V6.2

[Cameron Conacher]

Thanks Frank.
I agree this is bad code. 

I was curious if the new COBOL 6.2 compiler would uncover any other bad code.
I like that it is identified at compile time.


Sent from my iPhone

> On Jul 21, 2017, at 11:55 AM, Frank Swarbrick  
> wrote:
> 
> The error is not that there is a VALUE clause in the linkage section, but 
> rather the value clause now being allowed and respected, in conjunction with 
> the fact that the particular value clause is invalid.  It should be VALUE 
> '1234', not VALUE 1234.  You would get the same error in COBOL V4 and V5 if 
> the item had been in working-storage rather than linkage.
> 
> You could use a compiler exit to "downgrade" the error to a warning, if you 
> are so inclined.
> 
> Frank
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Cameron Conacher 
> Sent: Friday, July 21, 2017 9:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Enterprise COBOL V6.2
> 
> Here is a snippet from someone else's observations:
> Hi
> Just wondering has anyone confronted this compile issue stated for COBOL 6.1?
> 
> Version 6.1
> 
> 
> COBOL source code differences in Enterprise COBOL Version 6
> 
> In Enterprise COBOL V5 and earlier versions, a non-88 level VALUE clause in 
> the
> LINKAGE SECTION or FILE SECTION was treated as a comment. However,
> starting in Enterprise COBOL V6.1, the VALUE clause for LINKAGE SECTION and
> FILE SECTION items is now syntax checked and has meaning. This means that a
> program that is compiled with RC=0 with COBOL V5 could get RC=12 with
> COBOL V6.
> 
> For example, with Enterprise COBOL V5 and earlier versions:
> 000224 LINKAGE SECTION.
> 000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
> 
> 
> ==000225==> IGYDS1158-I A non-level-88 "VALUE" clause was found in the
> "FILE SECTION" or "LINKAGE SECTION". The "VALUE" clause was treated as 
> comments.
> 
> With Enterprise COBOL V6:
> 
> 000224 LINKAGE SECTION.
> 000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
> 
> ==000225==> IGYGR1080-S A "VALUE" clause literal was not compatible with the 
> data
> category of the subject data item. The "VALUE" clause was discarded.
> 
> 
> Hope that helps
> 
> Sent from my iPhone
> 
>> On Jul 20, 2017, at 5:25 PM, Frank Swarbrick  
>> wrote:
>> 
>> I'm not clear on what you are saying here.  Can you give an example of both 
>> the code and the error message?
>> 
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Cameron Conacher 
>> Sent: Thursday, July 20, 2017 2:43 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Enterprise COBOL V6.2
>> 
>> Hello everyone.
>> COBOL 6.1 introduced a "feature" where VALUE clauses that are used for
>> initialization are flagged as errors.
>> Ever since I began using COBL in the seventies, this would be treated as a
>> warning.
>> Personally, I consider it bad form, but the compiler happily marched on.
>> We have a number of COPYBOOKs that are occasionally used in LINKAGE, and
>> these items have raised issues during recompiles.
>> Nothing terrible, but still a bump in the development road.
>> 
>> Are there any new features like this in COBOL 6.2?
>> 
>> Thanks,
>> 
>> ...Cameron
>> 
>>> On Thu, Jul 20, 2017 at 8:33 AM, Tim Deller  wrote:
>>> 
>>> "Conditional complication"?
>>> Sounds about right...
>>> 
>>> --
>>> 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
> 
> --
> 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: Enterprise COBOL V6.2

[Cameron Conacher]

I completely agree this was at best a hidden error previously
My question was not so much how to work around it but whether there were other 
similar nuggets with COBOL 6.2


Sent from my iPhone

> On Jul 21, 2017, at 11:48 AM, Bernd Oppolzer  
> wrote:
> 
> This has already been brilliantly explained by Frank Swarbrick;
> 
> the new COBOL compiler version has a new INITIALIZE statement
> which is able to INITIALIZE variables of the LINKAGE SECTION,
> so that the VALUEs coded there are not comments any more,
> but instead the have a meaning !!
> 
> In the past, when they were comments, there was a warning,
> regardless if they were coded right or wrong.
> 
> Now, when they are no comments any more, they may be coded right:
> RC = 0
> or wrong:
> RC = 12
> as in your case
> 
> This is, IMO, a "hidden syntax error", which was not visible in the past,
> because the old compiler treated the VALUE clause as a comment in
> the linkage section; now it is visible, and you have to change your
> sources due to this compiler release change. Perfectly normal.
> 
> Kind regards
> 
> Bernd
> 
> 
> 
>> Am 21.07.2017 um 17:20 schrieb Cameron Conacher:
>> Here is a snippet from someone else's observations:
>> Hi
>> Just wondering has anyone confronted this compile issue stated for COBOL 6.1?
>>  Version 6.1
>>COBOL source code differences in Enterprise COBOL Version 6
>>  In Enterprise COBOL V5 and earlier versions, a non-88 level VALUE clause in 
>> the
>> LINKAGE SECTION or FILE SECTION was treated as a comment. However,
>> starting in Enterprise COBOL V6.1, the VALUE clause for LINKAGE SECTION and
>> FILE SECTION items is now syntax checked and has meaning. This means that a
>> program that is compiled with RC=0 with COBOL V5 could get RC=12 with
>> COBOL V6.
>>  For example, with Enterprise COBOL V5 and earlier versions:
>> 000224 LINKAGE SECTION.
>> 000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
>>==000225==> IGYDS1158-I A non-level-88 "VALUE" clause was found in the
>> "FILE SECTION" or "LINKAGE SECTION". The "VALUE" clause was treated as 
>> comments.
>>  With Enterprise COBOL V6:
>>  000224 LINKAGE SECTION.
>> 000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
>>  ==000225==> IGYGR1080-S A "VALUE" clause literal was not compatible with 
>> the data
>> category of the subject data item. The "VALUE" clause was discarded.
>> 
>> 
>> Hope that helps
>> 
>> Sent from my iPhone
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Backing up EMC DLM

[Tom Brennan]

I'm new to this so I can't answer your question yet, but thanks for 
responding and for the web reference.  And by coincidence I also see 
your DLM post about cloud too!


Lizette Koehler wrote:

Tom

I may be wrong, but the DLm is more like a database for the tapes.  There is no
storage on it.  The needs to be another piece of equipment to provide the
storage for the actual tape usage.

I think you are asking can you use a storage device other than EMC equipment to
hold the actual tape data.

Is that correct?

If so, I have not seen any documentation that would indicate anything other than
EMC equipment can be used for the DLm for their actual tape data.

This link does not show anything other than EMC equipment. Currently, VMAX, VNX,
DD are the only devices I have seen that works with the DLm.

https://www.emc.com/collateral/hardware/data-sheet/h4207-disk-library-mainframe-
ds.pdf


So, you are probably trying to see if anyone used something other than EMC
equipment with the DLm and was successful.



Lizette




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tom Brennan
Sent: Thursday, July 20, 2017 7:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Backing up EMC DLM

Is anyone using a Quantum (quantum.com) device to back up data from an EMC
DLM? (Disk Library for Mainframe - looks like tape to the mainframe)




--
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: Backing up EMC DLM

[Tom Brennan]

Thanks Radoslaw, I appreciate it.

R.S. wrote:

W dniu 2017-07-21 o 04:27, Tom Brennan pisze:

Is anyone using a Quantum (quantum.com) device to back up data from an 
EMC DLM? (Disk Library for Mainframe - looks like tape to the mainframe)




AFAIK it is not possible since EMC limited DLM to connect only to EMC 
storage.
Before that DLM was named BusTech and could use various disk & tape 
vendors.




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

Re: Enterprise COBOL V6.2

[Frank Swarbrick]

The error is not that there is a VALUE clause in the linkage section, but 
rather the value clause now being allowed and respected, in conjunction with 
the fact that the particular value clause is invalid.  It should be VALUE 
'1234', not VALUE 1234.  You would get the same error in COBOL V4 and V5 if the 
item had been in working-storage rather than linkage.

You could use a compiler exit to "downgrade" the error to a warning, if you are 
so inclined.

Frank


From: IBM Mainframe Discussion List  on behalf of 
Cameron Conacher 
Sent: Friday, July 21, 2017 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enterprise COBOL V6.2

Here is a snippet from someone else's observations:
Hi
Just wondering has anyone confronted this compile issue stated for COBOL 6.1?

Version 6.1


COBOL source code differences in Enterprise COBOL Version 6

In Enterprise COBOL V5 and earlier versions, a non-88 level VALUE clause in the
LINKAGE SECTION or FILE SECTION was treated as a comment. However,
starting in Enterprise COBOL V6.1, the VALUE clause for LINKAGE SECTION and
FILE SECTION items is now syntax checked and has meaning. This means that a
program that is compiled with RC=0 with COBOL V5 could get RC=12 with
COBOL V6.

For example, with Enterprise COBOL V5 and earlier versions:
000224 LINKAGE SECTION.
000225 01 ALPH-ITEM PIC X(4) VALUE 1234.


==000225==> IGYDS1158-I A non-level-88 "VALUE" clause was found in the
"FILE SECTION" or "LINKAGE SECTION". The "VALUE" clause was treated as comments.

With Enterprise COBOL V6:

000224 LINKAGE SECTION.
000225 01 ALPH-ITEM PIC X(4) VALUE 1234.

==000225==> IGYGR1080-S A "VALUE" clause literal was not compatible with the 
data
category of the subject data item. The "VALUE" clause was discarded.


Hope that helps

Sent from my iPhone

> On Jul 20, 2017, at 5:25 PM, Frank Swarbrick  
> wrote:
>
> I'm not clear on what you are saying here.  Can you give an example of both 
> the code and the error message?
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Cameron Conacher 
> Sent: Thursday, July 20, 2017 2:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Enterprise COBOL V6.2
>
> Hello everyone.
> COBOL 6.1 introduced a "feature" where VALUE clauses that are used for
> initialization are flagged as errors.
> Ever since I began using COBL in the seventies, this would be treated as a
> warning.
> Personally, I consider it bad form, but the compiler happily marched on.
> We have a number of COPYBOOKs that are occasionally used in LINKAGE, and
> these items have raised issues during recompiles.
> Nothing terrible, but still a bump in the development road.
>
> Are there any new features like this in COBOL 6.2?
>
> Thanks,
>
> ...Cameron
>
>> On Thu, Jul 20, 2017 at 8:33 AM, Tim Deller  wrote:
>>
>> "Conditional complication"?
>> Sounds about right...
>>
>> --
>> 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

--
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: Enterprise COBOL V6.2

[Bernd Oppolzer]

This has already been brilliantly explained by Frank Swarbrick;

the new COBOL compiler version has a new INITIALIZE statement
which is able to INITIALIZE variables of the LINKAGE SECTION,
so that the VALUEs coded there are not comments any more,
but instead the have a meaning !!

In the past, when they were comments, there was a warning,
regardless if they were coded right or wrong.

Now, when they are no comments any more, they may be coded right:
RC = 0
or wrong:
RC = 12
as in your case

This is, IMO, a "hidden syntax error", which was not visible in the past,
because the old compiler treated the VALUE clause as a comment in
the linkage section; now it is visible, and you have to change your
sources due to this compiler release change. Perfectly normal.

Kind regards

Bernd



Am 21.07.2017 um 17:20 schrieb Cameron Conacher:

Here is a snippet from someone else's observations:
Hi
Just wondering has anyone confronted this compile issue stated for COBOL 6.1?
  
Version 6.1
  
  
COBOL source code differences in Enterprise COBOL Version 6
  
In Enterprise COBOL V5 and earlier versions, a non-88 level VALUE clause in the

LINKAGE SECTION or FILE SECTION was treated as a comment. However,
starting in Enterprise COBOL V6.1, the VALUE clause for LINKAGE SECTION and
FILE SECTION items is now syntax checked and has meaning. This means that a
program that is compiled with RC=0 with COBOL V5 could get RC=12 with
COBOL V6.
  
For example, with Enterprise COBOL V5 and earlier versions:

000224 LINKAGE SECTION.
000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
  
  
==000225==> IGYDS1158-I A non-level-88 "VALUE" clause was found in the

"FILE SECTION" or "LINKAGE SECTION". The "VALUE" clause was treated as comments.
  
With Enterprise COBOL V6:
  
000224 LINKAGE SECTION.

000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
  
==000225==> IGYGR1080-S A "VALUE" clause literal was not compatible with the data

category of the subject data item. The "VALUE" clause was discarded.


Hope that helps

Sent from my iPhone



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

Re: Enterprise COBOL V6.2

[Cameron Conacher]

Here is a snippet from someone else's observations:
Hi
Just wondering has anyone confronted this compile issue stated for COBOL 6.1?
 
Version 6.1
 
 
COBOL source code differences in Enterprise COBOL Version 6
 
In Enterprise COBOL V5 and earlier versions, a non-88 level VALUE clause in the
LINKAGE SECTION or FILE SECTION was treated as a comment. However,
starting in Enterprise COBOL V6.1, the VALUE clause for LINKAGE SECTION and
FILE SECTION items is now syntax checked and has meaning. This means that a
program that is compiled with RC=0 with COBOL V5 could get RC=12 with
COBOL V6.
 
For example, with Enterprise COBOL V5 and earlier versions:
000224 LINKAGE SECTION.
000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
 
 
==000225==> IGYDS1158-I A non-level-88 "VALUE" clause was found in the
"FILE SECTION" or "LINKAGE SECTION". The "VALUE" clause was treated as comments.
 
With Enterprise COBOL V6:
 
000224 LINKAGE SECTION.
000225 01 ALPH-ITEM PIC X(4) VALUE 1234.
 
==000225==> IGYGR1080-S A "VALUE" clause literal was not compatible with the 
data
category of the subject data item. The "VALUE" clause was discarded.


Hope that helps

Sent from my iPhone

> On Jul 20, 2017, at 5:25 PM, Frank Swarbrick  
> wrote:
> 
> I'm not clear on what you are saying here.  Can you give an example of both 
> the code and the error message?
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Cameron Conacher 
> Sent: Thursday, July 20, 2017 2:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Enterprise COBOL V6.2
> 
> Hello everyone.
> COBOL 6.1 introduced a "feature" where VALUE clauses that are used for
> initialization are flagged as errors.
> Ever since I began using COBL in the seventies, this would be treated as a
> warning.
> Personally, I consider it bad form, but the compiler happily marched on.
> We have a number of COPYBOOKs that are occasionally used in LINKAGE, and
> these items have raised issues during recompiles.
> Nothing terrible, but still a bump in the development road.
> 
> Are there any new features like this in COBOL 6.2?
> 
> Thanks,
> 
> ...Cameron
> 
>> On Thu, Jul 20, 2017 at 8:33 AM, Tim Deller  wrote:
>> 
>> "Conditional complication"?
>> Sounds about right...
>> 
>> --
>> 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

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

Re: IOCDF issue

[Carmen Vitullo]

I would, if there's no need to cross CSS's I would 


Carmen 

- Original Message -

From: "Dave Jones"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 21, 2017 9:57:33 AM 
Subject: Re: IOCDF issue 

All of the CTC devices at 73xx are offline and not available. so it's not just 
7302 and 7303, either. 

Maybe I should delete all CTCs out of the IOCDS and recreate them all in the 
same CSS...? 

-- 
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: IOCDF issue

[Dave Jones]

All of the CTC devices at 73xx are offline and not available. so it's not just 
7302  and 7303, either.

Maybe I should delete all CTCs out of the IOCDS and recreate them all in the 
same CSS...?

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

Re: EMC DLm to the Cloud

[R.S.]

W dniu 2017-07-21 o 16:32, Lizette Koehler pisze:

http://www.storagereview.com/dell_emc_announce_dlm_45_to_eliminate_physical_tape


Today at SHARE 2017, Dell EMC announced the latest version of its Disk Library
for mainframe (DLm) virtual tape, version 4.5. The latest version of Dell EMC's
cloud-based virtual tape is aiming to replace physical tape as the go to
long-term retention strategy. Dell EMC states that DLm 4.5 can make the
mainframe data center more efficient by moving mainframe virtual tape data to
the cloud.


I am not sure how big the "cloud" would have to be for some shops.


That's simple: a company sells no tapes. Only disk systems.
What can they claim?

BTW: real tapes, on foreground or just background of some VTS are really 
give way to disks.

From the other hand, spinning disks give way to SSDs.
SSDs disks (more exactly: SSD with disk interface) give way to flash 
systems...



--
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.plsą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: EMC DLm to the Cloud

[Carmen Vitullo]

It would have to be a big improvement over the last iteration. we had many 
issues with a DR DD and DLM from Arkansas to Boulder. 


- Original Message -

From: "Lizette Koehler"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 21, 2017 9:32:28 AM 
Subject: EMC DLm to the Cloud 

http://www.storagereview.com/dell_emc_announce_dlm_45_to_eliminate_physical_tape
 


Today at SHARE 2017, Dell EMC announced the latest version of its Disk Library 
for mainframe (DLm) virtual tape, version 4.5. The latest version of Dell EMC’s 
cloud-based virtual tape is aiming to replace physical tape as the go to 
long-term retention strategy. Dell EMC states that DLm 4.5 can make the 
mainframe data center more efficient by moving mainframe virtual tape data to 
the cloud. 


I am not sure how big the "cloud" would have to be for some shops. 


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

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


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

Re: IOCDF issue

[Carmen Vitullo]

Since it seems its only one or two devices I have to assume the Chanel path is 
online? to all LPARS 
since FCTC are all LPARS on the same physical box? 



maybe plugged into the wrong PCHID? 


- Original Message -

From: "Dave Jones"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 21, 2017 9:29:49 AM 
Subject: Re: IOCDF issue 

Hi, Carmen. 

The actual message is this: 

"Device 7302 cannot be varied online because no channel path is available." 

I don't know if that means the fiber is plugged in or not. 
Thanks. 
DJ 

-- 
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: IOCDF issue

[Dave Jones]

Hello, Lizette.

Sorry no MVS here, this is a pure z/VM complex running on a z12. 

The system is about 1200 miles away from where I am, so I can't tell if any 
lights on the cables are on or notI do have access to the HMC, thou.

I'm asking here on IBM-MAIN because I suspect there is a lot more expertise 
here than on the VM lists. :-)
DJ

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

Re: IOCDF issue

[Carmen Vitullo]

Agree, I've never had the need to cross channel subsystem or CSS's either 


- Original Message -

From: "Doug"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 21, 2017 9:32:31 AM 
Subject: Re: IOCDF issue 

Never tried crossing CSS for FCTC. 
Spanned channels perhaps? 
Regards, Doug 

. 

On Jul 21, 2017, at 10:24, Lizette Koehler  wrote: 

Can you issue the 

D M commands 

DEV Serve commands - DS Q for example 

And see what MVS and IOS thinks? 

I do not have the syntax in front of me. 

Are any of the devices on 7300 available and it is just 7302 and 7303 that are 
not available? 


Do the connections have light end to end 


Lizette 

> -Original Message- 
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Dave Jones 
> Sent: Friday, July 21, 2017 6:45 AM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: IOCDF issue 
> 
> Hello, guys. 
> 
> I'm stuck here with an IOCDS problem that I can't figure out and need the 
> help of some experts. 
> Here's the problem...I have an IOCDS that looks like this: 
>> *ICP ICP152I SYSTEM=(2827,1) USED BY ICP IOCP 
>> RESOURCE PARTITION=((CSS(0),(L01,1),(L02,2),(L03,3),(L04,4), * 
>> (L05,5),(L06,6),(L07,7)), * 
>> (CSS(1),(L11,1),(L12,2),(L13,3),(L14,4),(L15,5), * 
>> (L16,6),(L17,7),(L41,8),(L42,9),(L43,A),(L44,B), * 
>> (L45,C),(L46,D),(L47,E),(L48,F)), * 
>> (CSS(2),(L21,1),(L22,2),(L23,3),(L24,4),(L25,5), * 
>> (L26,6),(L27,7)), * 
>> (CSS(3),(L31,1),(L32,2),(L33,3),(L34,4),(L35,5), * 
>> (L36,6),(L37,7))) 
>> 
>> 
>> 
>> CNTLUNIT CUNUMBR=4067,PATH=((CSS(3),1C,3C)), * 
>> UNIT=2107,UNITADD=((00,256)),CUADD=67 
>> CNTLUNIT CUNUMBR=7000,PATH=((CSS(2),08)),UNITADD=((00,32)), * 
>> CUADD=25,UNIT=FCTC 
>> IODEVICE ADDRESS=(7000,032),CUNUMBR=(7000),STADET=Y, * 
>> PARTITION=((CSS(2),L24)),UNIT=FCTC 
>> CNTLUNIT CUNUMBR=7100,PATH=((CSS(2),18)),UNITADD=((00,32)), * 
>> CUADD=24,UNIT=FCTC 
>> IODEVICE ADDRESS=(7100,032),CUNUMBR=(7100),STADET=Y, * 
>> PARTITION=((CSS(2),L25)),UNIT=FCTC 
>> CNTLUNIT CUNUMBR=7300,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
>> CUADD=03,UNIT=FCTC 
>> IODEVICE ADDRESS=(7300,016),CUNUMBR=(7300),STADET=Y, * 
>> PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC 
>> CNTLUNIT CUNUMBR=7310,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
>> CUADD=03,UNIT=FCTC 
>> IODEVICE ADDRESS=(7310,016),CUNUMBR=(7310),STADET=Y, * 
>> PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC 
>> CNTLUNIT CUNUMBR=7400,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
>> CUADD=04,UNIT=FCTC 
>> IODEVICE ADDRESS=(7400,016),CUNUMBR=(7400),STADET=Y, * 
>> PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC 
>> CNTLUNIT CUNUMBR=7410,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
>> CUADD=04,UNIT=FCTC 
>> IODEVICE ADDRESS=(7410,016),CUNUMBR=(7410),STADET=Y, * 
>> PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC 
>> CNTLUNIT CUNUMBR=7500,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
>> CUADD=05,UNIT=FCTC 
>> IODEVICE ADDRESS=(7500,016),CUNUMBR=(7500),STADET=Y, * 
>> PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC 
>> CNTLUNIT CUNUMBR=7510,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
>> CUADD=05,UNIT=FCTC 
>> IODEVICE ADDRESS=(7510,016),CUNUMBR=(7510),STADET=Y, * 
>> PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC 
>> CNTLUNIT CUNUMBR=7600,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
>> CUADD=06,UNIT=FCTC 
>> IODEVICE ADDRESS=(7600,016),CUNUMBR=(7600),STADET=Y, * 
>> PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC 
>> CNTLUNIT CUNUMBR=7610,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
>> CUADD=06,UNIT=FCTC 
>> IODEVICE ADDRESS=(7610,016),CUNUMBR=(7610),STADET=Y, * 
>> PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC 
> and the problem is that LPARs L05 and L06 can not see FCTC devices 7302 and 
> 7303. they are both marked offline at IPL time. An attempt to vary them 
> online gets a message that "no channel paths are available". 
> What am I missing here? 
> Thanks, 
> 
> 

-- 
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: IOCDF issue

[Doug]

Never tried crossing CSS for FCTC.
Spanned channels perhaps?
Regards, Doug 

.

On Jul 21, 2017, at 10:24, Lizette Koehler  wrote:

Can you issue the 

D M commands

DEV Serve commands - DS Q for example

And see what MVS and IOS thinks?

I do not have the syntax in front of me.

Are any of the devices on 7300 available and it is just 7302 and 7303 that are 
not available?


Do the connections have light end to end


Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dave Jones
> Sent: Friday, July 21, 2017 6:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IOCDF issue
> 
> Hello, guys.
> 
> I'm stuck here with an IOCDS problem that I can't figure out and need the
> help of some experts.
> Here's the problem...I have an IOCDS that looks like this:
>> *ICP  ICP152I SYSTEM=(2827,1) USED BY ICP IOCP
>>  RESOURCE PARTITION=((CSS(0),(L01,1),(L02,2),(L03,3),(L04,4),  *
>>(L05,5),(L06,6),(L07,7)),   *
>>(CSS(1),(L11,1),(L12,2),(L13,3),(L14,4),(L15,5),*
>>(L16,6),(L17,7),(L41,8),(L42,9),(L43,A),(L44,B),*
>>(L45,C),(L46,D),(L47,E),(L48,F)),   *
>>(CSS(2),(L21,1),(L22,2),(L23,3),(L24,4),(L25,5),*
>>(L26,6),(L27,7)),   *
>>(CSS(3),(L31,1),(L32,2),(L33,3),(L34,4),(L35,5),*
>>(L36,6),(L37,7)))
>> 
>> 
>> 
>>  CNTLUNIT CUNUMBR=4067,PATH=((CSS(3),1C,3C)),  *
>>UNIT=2107,UNITADD=((00,256)),CUADD=67
>>  CNTLUNIT CUNUMBR=7000,PATH=((CSS(2),08)),UNITADD=((00,32)),   *
>>CUADD=25,UNIT=FCTC
>>  IODEVICE ADDRESS=(7000,032),CUNUMBR=(7000),STADET=Y,  *
>>PARTITION=((CSS(2),L24)),UNIT=FCTC
>>  CNTLUNIT CUNUMBR=7100,PATH=((CSS(2),18)),UNITADD=((00,32)),   *
>>CUADD=24,UNIT=FCTC
>>  IODEVICE ADDRESS=(7100,032),CUNUMBR=(7100),STADET=Y,  *
>>PARTITION=((CSS(2),L25)),UNIT=FCTC
>>  CNTLUNIT CUNUMBR=7300,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
>>CUADD=03,UNIT=FCTC
>>  IODEVICE ADDRESS=(7300,016),CUNUMBR=(7300),STADET=Y,  *
>>PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC
>>  CNTLUNIT CUNUMBR=7310,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
>>CUADD=03,UNIT=FCTC
>>  IODEVICE ADDRESS=(7310,016),CUNUMBR=(7310),STADET=Y,  *
>>PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC
>>  CNTLUNIT CUNUMBR=7400,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
>>CUADD=04,UNIT=FCTC
>>  IODEVICE ADDRESS=(7400,016),CUNUMBR=(7400),STADET=Y,  *
>>PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC
>>  CNTLUNIT CUNUMBR=7410,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
>>CUADD=04,UNIT=FCTC
>>  IODEVICE ADDRESS=(7410,016),CUNUMBR=(7410),STADET=Y,  *
>>PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC
>>  CNTLUNIT CUNUMBR=7500,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
>>CUADD=05,UNIT=FCTC
>>  IODEVICE ADDRESS=(7500,016),CUNUMBR=(7500),STADET=Y,  *
>>PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC
>>  CNTLUNIT CUNUMBR=7510,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
>>CUADD=05,UNIT=FCTC
>>  IODEVICE ADDRESS=(7510,016),CUNUMBR=(7510),STADET=Y,  *
>>PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC
>>  CNTLUNIT CUNUMBR=7600,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
>>CUADD=06,UNIT=FCTC
>>  IODEVICE ADDRESS=(7600,016),CUNUMBR=(7600),STADET=Y,  *
>>PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC
>>  CNTLUNIT CUNUMBR=7610,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
>>CUADD=06,UNIT=FCTC
>>  IODEVICE ADDRESS=(7610,016),CUNUMBR=(7610),STADET=Y,  *
>>PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC
> and the problem is that LPARs L05 and L06 can not see FCTC devices 7302 and
> 7303. they are both marked offline at IPL time. An attempt to vary them
> online gets a message that "no channel paths are available".
> What am I missing here?
> Thanks,
> 
> 

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

EMC DLm to the Cloud

[Lizette Koehler]

http://www.storagereview.com/dell_emc_announce_dlm_45_to_eliminate_physical_tape


Today at SHARE 2017, Dell EMC announced the latest version of its Disk Library
for mainframe (DLm) virtual tape, version 4.5. The latest version of Dell EMC’s
cloud-based virtual tape is aiming to replace physical tape as the go to
long-term retention strategy. Dell EMC states that DLm 4.5 can make the
mainframe data center more efficient by moving mainframe virtual tape data to
the cloud.


I am not sure how big the "cloud" would have to be for some shops.


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

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

Re: IOCDF issue

[Dave Jones]

Hi, Carmen.

The actual message is this:

"Device 7302 cannot be varied online because no channel path is available."

I don't know if that means the fiber is plugged in or not.
Thanks.
DJ

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

Re: IOCDF issue

[Lizette Koehler]

Can you issue the 

D M commands

DEV Serve commands - DS Q for example

And see what MVS and IOS thinks?

I do not have the syntax in front of me.

Are any of the devices on 7300 available and it is just 7302 and 7303 that are 
not available?


Do the connections have light end to end


Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dave Jones
> Sent: Friday, July 21, 2017 6:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IOCDF issue
> 
> Hello, guys.
> 
> I'm stuck here with an IOCDS problem that I can't figure out and need the
> help of some experts.
> Here's the problem...I have an IOCDS that looks like this:
> > *ICP  ICP152I SYSTEM=(2827,1) USED BY ICP IOCP
> >   RESOURCE PARTITION=((CSS(0),(L01,1),(L02,2),(L03,3),(L04,4),  *
> > (L05,5),(L06,6),(L07,7)),   *
> > (CSS(1),(L11,1),(L12,2),(L13,3),(L14,4),(L15,5),*
> > (L16,6),(L17,7),(L41,8),(L42,9),(L43,A),(L44,B),*
> > (L45,C),(L46,D),(L47,E),(L48,F)),   *
> > (CSS(2),(L21,1),(L22,2),(L23,3),(L24,4),(L25,5),*
> > (L26,6),(L27,7)),   *
> > (CSS(3),(L31,1),(L32,2),(L33,3),(L34,4),(L35,5),*
> > (L36,6),(L37,7)))
> >
> >
> >
> >   CNTLUNIT CUNUMBR=4067,PATH=((CSS(3),1C,3C)),  *
> > UNIT=2107,UNITADD=((00,256)),CUADD=67
> >   CNTLUNIT CUNUMBR=7000,PATH=((CSS(2),08)),UNITADD=((00,32)),   *
> > CUADD=25,UNIT=FCTC
> >   IODEVICE ADDRESS=(7000,032),CUNUMBR=(7000),STADET=Y,  *
> > PARTITION=((CSS(2),L24)),UNIT=FCTC
> >   CNTLUNIT CUNUMBR=7100,PATH=((CSS(2),18)),UNITADD=((00,32)),   *
> > CUADD=24,UNIT=FCTC
> >   IODEVICE ADDRESS=(7100,032),CUNUMBR=(7100),STADET=Y,  *
> > PARTITION=((CSS(2),L25)),UNIT=FCTC
> >   CNTLUNIT CUNUMBR=7300,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
> > CUADD=03,UNIT=FCTC
> >   IODEVICE ADDRESS=(7300,016),CUNUMBR=(7300),STADET=Y,  *
> > PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC
> >   CNTLUNIT CUNUMBR=7310,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
> > CUADD=03,UNIT=FCTC
> >   IODEVICE ADDRESS=(7310,016),CUNUMBR=(7310),STADET=Y,  *
> > PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC
> >   CNTLUNIT CUNUMBR=7400,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
> > CUADD=04,UNIT=FCTC
> >   IODEVICE ADDRESS=(7400,016),CUNUMBR=(7400),STADET=Y,  *
> > PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC
> >   CNTLUNIT CUNUMBR=7410,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
> > CUADD=04,UNIT=FCTC
> >   IODEVICE ADDRESS=(7410,016),CUNUMBR=(7410),STADET=Y,  *
> > PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC
> >   CNTLUNIT CUNUMBR=7500,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
> > CUADD=05,UNIT=FCTC
> >   IODEVICE ADDRESS=(7500,016),CUNUMBR=(7500),STADET=Y,  *
> > PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC
> >   CNTLUNIT CUNUMBR=7510,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
> > CUADD=05,UNIT=FCTC
> >   IODEVICE ADDRESS=(7510,016),CUNUMBR=(7510),STADET=Y,  *
> > PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC
> >   CNTLUNIT CUNUMBR=7600,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
> > CUADD=06,UNIT=FCTC
> >   IODEVICE ADDRESS=(7600,016),CUNUMBR=(7600),STADET=Y,  *
> > PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC
> >   CNTLUNIT CUNUMBR=7610,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
> > CUADD=06,UNIT=FCTC
> >   IODEVICE ADDRESS=(7610,016),CUNUMBR=(7610),STADET=Y,  *
> > PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC
> and the problem is that LPARs L05 and L06 can not see FCTC devices 7302 and
> 7303. they are both marked offline at IPL time. An attempt to vary them
> online gets a message that "no channel paths are available".
> What am I missing here?
> Thanks,
> 
> 

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

Re: IOCDF issue

[Carmen Vitullo]

looking again, I wonder about 


IODEVICE ADDRESS=(7000,032),CUNUMBR=(7000),STADET=Y, * 
> PARTITION=((CSS(2),L24)),UNIT=FCTC 


last time I did a gen was back y2k, :( 

- Original Message -

From: "Dave Jones"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 21, 2017 8:44:37 AM 
Subject: IOCDF issue 

Hello, guys. 

I'm stuck here with an IOCDS problem that I can't figure out and need the help 
of some experts. 
Here's the problem...I have an IOCDS that looks like this: 
> *ICP ICP152I SYSTEM=(2827,1) USED BY ICP IOCP 
> RESOURCE PARTITION=((CSS(0),(L01,1),(L02,2),(L03,3),(L04,4), * 
> (L05,5),(L06,6),(L07,7)), * 
> (CSS(1),(L11,1),(L12,2),(L13,3),(L14,4),(L15,5), * 
> (L16,6),(L17,7),(L41,8),(L42,9),(L43,A),(L44,B), * 
> (L45,C),(L46,D),(L47,E),(L48,F)), * 
> (CSS(2),(L21,1),(L22,2),(L23,3),(L24,4),(L25,5), * 
> (L26,6),(L27,7)), * 
> (CSS(3),(L31,1),(L32,2),(L33,3),(L34,4),(L35,5), * 
> (L36,6),(L37,7))) 
> 
> 
> 
> CNTLUNIT CUNUMBR=4067,PATH=((CSS(3),1C,3C)), * 
> UNIT=2107,UNITADD=((00,256)),CUADD=67 
> CNTLUNIT CUNUMBR=7000,PATH=((CSS(2),08)),UNITADD=((00,32)), * 
> CUADD=25,UNIT=FCTC 
> IODEVICE ADDRESS=(7000,032),CUNUMBR=(7000),STADET=Y, * 
> PARTITION=((CSS(2),L24)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7100,PATH=((CSS(2),18)),UNITADD=((00,32)), * 
> CUADD=24,UNIT=FCTC 
> IODEVICE ADDRESS=(7100,032),CUNUMBR=(7100),STADET=Y, * 
> PARTITION=((CSS(2),L25)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7300,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
> CUADD=03,UNIT=FCTC 
> IODEVICE ADDRESS=(7300,016),CUNUMBR=(7300),STADET=Y, * 
> PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7310,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
> CUADD=03,UNIT=FCTC 
> IODEVICE ADDRESS=(7310,016),CUNUMBR=(7310),STADET=Y, * 
> PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7400,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
> CUADD=04,UNIT=FCTC 
> IODEVICE ADDRESS=(7400,016),CUNUMBR=(7400),STADET=Y, * 
> PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7410,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
> CUADD=04,UNIT=FCTC 
> IODEVICE ADDRESS=(7410,016),CUNUMBR=(7410),STADET=Y, * 
> PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7500,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
> CUADD=05,UNIT=FCTC 
> IODEVICE ADDRESS=(7500,016),CUNUMBR=(7500),STADET=Y, * 
> PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7510,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
> CUADD=05,UNIT=FCTC 
> IODEVICE ADDRESS=(7510,016),CUNUMBR=(7510),STADET=Y, * 
> PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7600,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
> CUADD=06,UNIT=FCTC 
> IODEVICE ADDRESS=(7600,016),CUNUMBR=(7600),STADET=Y, * 
> PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7610,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
> CUADD=06,UNIT=FCTC 
> IODEVICE ADDRESS=(7610,016),CUNUMBR=(7610),STADET=Y, * 
> PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC 
and the problem is that LPARs L05 and L06 can not see FCTC devices 7302 and 
7303. they are both marked offline at IPL time. An attempt to vary them online 
gets a message that "no channel paths are available". 
What am I missing here? 
Thanks, 

-- 
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: IOCDF issue

[Carmen Vitullo]

Is there a physical connection between these LPARS , fiber in/out ? 
is the message no physical paths available ? 
just eyeballing the gen looks correct 

Carmen 
- Original Message -

From: "Dave Jones"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 21, 2017 8:44:37 AM 
Subject: IOCDF issue 

Hello, guys. 

I'm stuck here with an IOCDS problem that I can't figure out and need the help 
of some experts. 
Here's the problem...I have an IOCDS that looks like this: 
> *ICP ICP152I SYSTEM=(2827,1) USED BY ICP IOCP 
> RESOURCE PARTITION=((CSS(0),(L01,1),(L02,2),(L03,3),(L04,4), * 
> (L05,5),(L06,6),(L07,7)), * 
> (CSS(1),(L11,1),(L12,2),(L13,3),(L14,4),(L15,5), * 
> (L16,6),(L17,7),(L41,8),(L42,9),(L43,A),(L44,B), * 
> (L45,C),(L46,D),(L47,E),(L48,F)), * 
> (CSS(2),(L21,1),(L22,2),(L23,3),(L24,4),(L25,5), * 
> (L26,6),(L27,7)), * 
> (CSS(3),(L31,1),(L32,2),(L33,3),(L34,4),(L35,5), * 
> (L36,6),(L37,7))) 
> 
> 
> 
> CNTLUNIT CUNUMBR=4067,PATH=((CSS(3),1C,3C)), * 
> UNIT=2107,UNITADD=((00,256)),CUADD=67 
> CNTLUNIT CUNUMBR=7000,PATH=((CSS(2),08)),UNITADD=((00,32)), * 
> CUADD=25,UNIT=FCTC 
> IODEVICE ADDRESS=(7000,032),CUNUMBR=(7000),STADET=Y, * 
> PARTITION=((CSS(2),L24)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7100,PATH=((CSS(2),18)),UNITADD=((00,32)), * 
> CUADD=24,UNIT=FCTC 
> IODEVICE ADDRESS=(7100,032),CUNUMBR=(7100),STADET=Y, * 
> PARTITION=((CSS(2),L25)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7300,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
> CUADD=03,UNIT=FCTC 
> IODEVICE ADDRESS=(7300,016),CUNUMBR=(7300),STADET=Y, * 
> PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7310,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
> CUADD=03,UNIT=FCTC 
> IODEVICE ADDRESS=(7310,016),CUNUMBR=(7310),STADET=Y, * 
> PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7400,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
> CUADD=04,UNIT=FCTC 
> IODEVICE ADDRESS=(7400,016),CUNUMBR=(7400),STADET=Y, * 
> PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7410,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
> CUADD=04,UNIT=FCTC 
> IODEVICE ADDRESS=(7410,016),CUNUMBR=(7410),STADET=Y, * 
> PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7500,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
> CUADD=05,UNIT=FCTC 
> IODEVICE ADDRESS=(7500,016),CUNUMBR=(7500),STADET=Y, * 
> PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7510,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
> CUADD=05,UNIT=FCTC 
> IODEVICE ADDRESS=(7510,016),CUNUMBR=(7510),STADET=Y, * 
> PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7600,PATH=((CSS(0),08)),UNITADD=((00,16)), * 
> CUADD=06,UNIT=FCTC 
> IODEVICE ADDRESS=(7600,016),CUNUMBR=(7600),STADET=Y, * 
> PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC 
> CNTLUNIT CUNUMBR=7610,PATH=((CSS(0),18)),UNITADD=((10,16)), * 
> CUADD=06,UNIT=FCTC 
> IODEVICE ADDRESS=(7610,016),CUNUMBR=(7610),STADET=Y, * 
> PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC 
and the problem is that LPARs L05 and L06 can not see FCTC devices 7302 and 
7303. they are both marked offline at IPL time. An attempt to vary them online 
gets a message that "no channel paths are available". 
What am I missing here? 
Thanks, 

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

IOCDF issue

[Dave Jones]

Hello, guys.

I'm stuck here with an IOCDS problem that I can't figure out and need the help 
of some experts.
Here's the problem...I have an IOCDS that looks like this:
> *ICP  ICP152I SYSTEM=(2827,1) USED BY ICP IOCP
>   RESOURCE PARTITION=((CSS(0),(L01,1),(L02,2),(L03,3),(L04,4),  *
> (L05,5),(L06,6),(L07,7)),   *
> (CSS(1),(L11,1),(L12,2),(L13,3),(L14,4),(L15,5),*
> (L16,6),(L17,7),(L41,8),(L42,9),(L43,A),(L44,B),*
> (L45,C),(L46,D),(L47,E),(L48,F)),   *
> (CSS(2),(L21,1),(L22,2),(L23,3),(L24,4),(L25,5),*
> (L26,6),(L27,7)),   *
> (CSS(3),(L31,1),(L32,2),(L33,3),(L34,4),(L35,5),*
> (L36,6),(L37,7)))
>
>
>
>   CNTLUNIT CUNUMBR=4067,PATH=((CSS(3),1C,3C)),  *
> UNIT=2107,UNITADD=((00,256)),CUADD=67
>   CNTLUNIT CUNUMBR=7000,PATH=((CSS(2),08)),UNITADD=((00,32)),   *
> CUADD=25,UNIT=FCTC
>   IODEVICE ADDRESS=(7000,032),CUNUMBR=(7000),STADET=Y,  *
> PARTITION=((CSS(2),L24)),UNIT=FCTC
>   CNTLUNIT CUNUMBR=7100,PATH=((CSS(2),18)),UNITADD=((00,32)),   *
> CUADD=24,UNIT=FCTC
>   IODEVICE ADDRESS=(7100,032),CUNUMBR=(7100),STADET=Y,  *
> PARTITION=((CSS(2),L25)),UNIT=FCTC
>   CNTLUNIT CUNUMBR=7300,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
> CUADD=03,UNIT=FCTC
>   IODEVICE ADDRESS=(7300,016),CUNUMBR=(7300),STADET=Y,  *
> PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC
>   CNTLUNIT CUNUMBR=7310,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
> CUADD=03,UNIT=FCTC
>   IODEVICE ADDRESS=(7310,016),CUNUMBR=(7310),STADET=Y,  *
> PARTITION=((CSS(0),L04,L05,L06)),UNIT=FCTC
>   CNTLUNIT CUNUMBR=7400,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
> CUADD=04,UNIT=FCTC
>   IODEVICE ADDRESS=(7400,016),CUNUMBR=(7400),STADET=Y,  *
> PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC
>   CNTLUNIT CUNUMBR=7410,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
> CUADD=04,UNIT=FCTC
>   IODEVICE ADDRESS=(7410,016),CUNUMBR=(7410),STADET=Y,  *
> PARTITION=((CSS(0),L03,L05,L06)),UNIT=FCTC
>   CNTLUNIT CUNUMBR=7500,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
> CUADD=05,UNIT=FCTC
>   IODEVICE ADDRESS=(7500,016),CUNUMBR=(7500),STADET=Y,  *
> PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC
>   CNTLUNIT CUNUMBR=7510,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
> CUADD=05,UNIT=FCTC
>   IODEVICE ADDRESS=(7510,016),CUNUMBR=(7510),STADET=Y,  *
> PARTITION=((CSS(0),L03,L04,L06)),UNIT=FCTC
>   CNTLUNIT CUNUMBR=7600,PATH=((CSS(0),08)),UNITADD=((00,16)),   *
> CUADD=06,UNIT=FCTC
>   IODEVICE ADDRESS=(7600,016),CUNUMBR=(7600),STADET=Y,  *
> PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC
>   CNTLUNIT CUNUMBR=7610,PATH=((CSS(0),18)),UNITADD=((10,16)),   *
> CUADD=06,UNIT=FCTC
>   IODEVICE ADDRESS=(7610,016),CUNUMBR=(7610),STADET=Y,  *
> PARTITION=((CSS(0),L03,L04,L05)),UNIT=FCTC
and the problem is that LPARs L05 and L06 can not see FCTC devices 7302 and 
7303. they are both marked offline at IPL time. An attempt to vary them online 
gets a message that "no channel paths are available".
What am I missing here?
Thanks, 

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

Re: Graph HCD Reports

[Randy Hoekstra]

HCD option 4 Create or view graphical configuration report will create a DCF 
output file when you choose Output = 2. I found a DCF to HTML REXX that will 
convert the downloaded file to HTML, the output is not perfect but very 
useable. I ran it on my Windows machine using the Regina REXX Interpreter.

Look here: http://www.vm.ibm.com/download/packages/descript.cgi?B2H  or I can 
send you the zip file, contact me offline.

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

Re: Visara CNA8000 question

[Jim Stefanik]

I would ask the same question - what's the end-goal?  If you're just trying to 
test something or revive some old gear for a while, an IBM 8229 LAN Bridge can 
be had for bugger all off eBay.  It just bridges traffic between an Ethernet 
LAN and a token ring LAN.  If this is a more permanent thing, there are 
probably more modern and better supported solutions, since the 8229 is quite 
old (20+ years...!).  I wouldn't recommend using an 8229 in a production 
environment for anything critical due to its age and lack of support from IBM.

-Jim



From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Friday, July 21, 2017 06:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Visara CNA8000 question

W dniu 2017-07-21 o 07:49, Peter Bishop pisze:
> Hi,
>
> we have a possible need to connect a token-ring link to a z13 (don't ask) and 
> were considering one option, but now another has appeared.
>
> We're wondering if anyone else is using a Visara CNA8000 for this?  It seems 
> a simpler option than the other one as it takes a token-ring link on one side 
> and a FICON link on the other.

What's your goal?
For that excercise I would ask what about TR and Eth networks connected
via some router supporting TCP/IP protocol.
For Visara I bet you could get something like local (non-SNA) console
with TR connection, but from host point of view it works like OSA-ICC
console/terminal.

--
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.plsą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: Backing up EMC DLM

[Lizette Koehler]

Tom

I may be wrong, but the DLm is more like a database for the tapes.  There is no
storage on it.  The needs to be another piece of equipment to provide the
storage for the actual tape usage.

I think you are asking can you use a storage device other than EMC equipment to
hold the actual tape data.

Is that correct?

If so, I have not seen any documentation that would indicate anything other than
EMC equipment can be used for the DLm for their actual tape data.

This link does not show anything other than EMC equipment. Currently, VMAX, VNX,
DD are the only devices I have seen that works with the DLm.

https://www.emc.com/collateral/hardware/data-sheet/h4207-disk-library-mainframe-
ds.pdf


So, you are probably trying to see if anyone used something other than EMC
equipment with the DLm and was successful.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Brennan
> Sent: Thursday, July 20, 2017 7:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Backing up EMC DLM
> 
> Is anyone using a Quantum (quantum.com) device to back up data from an EMC
> DLM? (Disk Library for Mainframe - looks like tape to the mainframe)
> 

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

Re: Visara CNA8000 question

[R.S.]

W dniu 2017-07-21 o 07:49, Peter Bishop pisze:

Hi,

we have a possible need to connect a token-ring link to a z13 (don't ask) and 
were considering one option, but now another has appeared.

We're wondering if anyone else is using a Visara CNA8000 for this?  It seems a 
simpler option than the other one as it takes a token-ring link on one side and 
a FICON link on the other.


What's your goal?
For that excercise I would ask what about TR and Eth networks connected 
via some router supporting TCP/IP protocol.
For Visara I bet you could get something like local (non-SNA) console 
with TR connection, but from host point of view it works like OSA-ICC 
console/terminal.


--
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.plsą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: Backing up EMC DLM

[R.S.]

W dniu 2017-07-21 o 04:27, Tom Brennan pisze:
Is anyone using a Quantum (quantum.com) device to back up data from an 
EMC DLM? (Disk Library for Mainframe - looks like tape to the mainframe)



AFAIK it is not possible since EMC limited DLM to connect only to EMC 
storage.
Before that DLM was named BusTech and could use various disk & tape 
vendors.


--
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.plsą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