Re: Concatenations and blocksizes

[Ron Hawkins]

Paul,

I believe your problem occurs because you now have SYS1.MACLIB concatenated
with SYS1.MACLIB, except the first one in the concatenation has DCB in the
JCL that does not match the actual dataset - hence your error.

The override "X/" on statement 6 and before statement 7 is the clue.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Paul Gilmartin
> Sent: Monday, August 10, 2009 4:19 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Concatenations and blocksizes
> 
> On Mon, 10 Aug 2009 17:48:31 -0500, Richard Peurifoy wrote:
> 
> >Paul Gilmartin wrote:
> >> On Mon, 10 Aug 2009 16:52:59 -0500, Patrick O'Keefe wrote:
> >>> I'm just puzzled that the enhancement limited itself to QSAM.
> >>> No mention of BPAM.
> >>>
> >> I had hoped this was an oversight in the doc, but apparently
> >> not.  An assembly with:
> >>
> >> //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,1)),
> >> //  RECFM=FB,LRECL=80,BLKSIZE=80
> >> //  DD  DISP=SHR,DSN=SYS1.MACLIB
> >>
> >Unless there is a typo, you concatenated a seq file (no directories)
> >with the PDS.
> >
> You mean I need _two_ commas, not just one?
> 
> Why does OPEN let me do that, and not just ABEND?
> 
> OK.  I changed to:
> 
>6 //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,,1)),
>  //  DISP=NEW,DSN=&&MAC,
>  //  RECFM=FB,LRECL=80,BLKSIZE=80
>  X/SYSLIB   DD  DSN=SYS1.MACLIB,DISP=SHR
>7 //  DD  DISP=SHR,DSN=SYS1.MACLIB
> 
> I needed to specify DISP and DSN to override those in the
> library proc.
> 
> And it fails the same with:
> 
> * TOP OF DATA
> **
> ** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error
on
> SYSL
>  ,HELLO   ,C   ,4140,D,SYSLIB
> ,UNKOWN,WRNG.LEN.RECORD,1F7100030
>  BOTTOM OF DATA
> 
> 
> Experimental control: if I change BLKSIZE from 80 to 32760,
> it assembles with no errors, and library macros are fetched
> from the second catenand.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: VTAM security issue

[Maarten Slegtenhorst]

Almost correct ;)

Systems Network Architecture

http://www-01.ibm.com/software/globalization/terminology/s.jsp#s18 
http://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture

-- 
Maarten

-Oorspronkelijk bericht-
Van: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] Namens
Gibney, Dave
Verzonden: zondag 9 augustus 2009 23:46
Aan: IBM-MAIN@BAMA.UA.EDU
Onderwerp: Re: VTAM security issue


  Isn't the A Architecture? And the S Synchronous :) 

> >>
> >Now I'm confused.  What does the initialism "SNA" stand for?
> >
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Infoprint set up in zos

[Philip Chan]

Hi Howard, 

Thanks a lot for your information. 

Rgds,
Philip 


-Original Message-
From: Howard Turetzky [mailto:howa...@us.ibm.com] 
Sent: Tuesday, August 11, 2009 5:44 AM
To: IBM-MAIN@bama.ua.edu; Philip Chan
Subject: Re: Infoprint set up in zos


1) You must create VTAM APPL statements for each NetSpool LU name. See
Chapter 17. 
Defining NetSpool printer LUs to VTAM of Infoprint Server Operation and
Administration 
S544-5745-10.

2) No application changes are required. 

3) IP PrintWay can send output from JES or NetSpool to TCP/IP attached
printers using 
either the lpr/lpd protocol or the direct sockets protocol. The printers
must be visible to 
z/OS from TCP/IP.



On Sun, 9 Aug 2009 21:52:28 -0500, Philip Chan 
wrote:

>2 Question:
>
>1) For CICS printing, is it no change on current VTAM printer setup?
>2) No application programs needed to change?
>3) Implement IP Printway option will enable all printouts from normal 
>PC printers?
>
>Thanks,
>Philip
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
>Search the archives at http://bama.ua.edu/archives/ibm-main.html





__
Note:

This e-mail is confidential and is intended solely for the addressee.  Any 
unauthorized use of the contents is expressly prohibited.  If you are not the 
intended recipient, you are hereby notified that any use, distribution, 
disclosure or copying of this e-mail is strictly prohibited.  If you have 
received this e-mail in error, please immediately notify the sender and delete 
it from your system.  E-mail communication cannot be guaranteed to be reliable, 
secure, error-free or virus-free.  Accordingly, we cannot accept liability for 
any damage sustained as a result of any virus, error or incompleteness of this 
e-mail or any failure to deliver promptly or at all information exchanged 
between you and us by this means.  If you suspect that this e-mail may have 
been intercepted or amended, please contact the sender.
__

"Conserve the Environment" - Think before you print

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z10 and overlapping/destructive moves

[Wayne Bickerdike]

Peter,

I agree with Edward on this one, ie if you can avoid performing the instruction.

Something you wrote perhaps suggests that it may be a redundant move,


I had not thought of the cache-line problem.  This particular MOVE is in
a subroutine that is invoked multiple times per input record (> 10),
which is likely why it is showing up as a spike in Strobe for a file of
several million records.


If the subroutine is invoked multiple times per input record, can the
space move be done just once? Before the subroutine?

I recall many years ago in my days at IBM we had a read subroutine. It
was the biggest CPU consumer for the least lines of code.

This was what it did: (PL/1)

INPUT_RECORD = '';
READ FILE(IN) INTO(INPUT_RECORD);
RETURN;

INPUT_RECORD happened to have about 1200 fields of various types.

Since we were reading over that area, the initialise was redundant.

We removed the null assign, which PL/I was naturally generating a few
thousand instructions for. Problem solved.

Regards,


On Mon, Aug 10, 2009 at 10:56 PM, Chase, John wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of Robert A. Rosenberg
>>
>> At 17:31 -0400 on 08/07/2009, Bill Fairchild wrote about Re: z10 and
>> overlapping/destructive moves:
>>
>> >It certainly can't hurt to change the MVI/MVC to a single
> instruction:
>> >      MVC   254(3,120),=120c' '
>> >And, if possible, align the 120c' ' on at least a double word
> boundary.
>> >
>> >Bill Fairchild
>>
>> I think that should be MVC   254(120,3),=120c' '
>>
>> A MVCL might also do the job (if you have the 4 needed registers
>> free) and set the from length and location to 0 with x"20" as the
>> fill character.
>
> Probably "better" to use x'40' on an EBCDIC machine  :-)
>
>    -jc-
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

On Mon, 10 Aug 2009 17:48:31 -0500, Richard Peurifoy wrote:

>Paul Gilmartin wrote:
>> On Mon, 10 Aug 2009 16:52:59 -0500, Patrick O'Keefe wrote:
>>> I'm just puzzled that the enhancement limited itself to QSAM.
>>> No mention of BPAM.
>>>
>> I had hoped this was an oversight in the doc, but apparently
>> not.  An assembly with:
>>
>> //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,1)),
>> //  RECFM=FB,LRECL=80,BLKSIZE=80
>> //  DD  DISP=SHR,DSN=SYS1.MACLIB
>>
>Unless there is a typo, you concatenated a seq file (no directories)
>with the PDS.
>
You mean I need _two_ commas, not just one?

Why does OPEN let me do that, and not just ABEND?

OK.  I changed to:

   6 //SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,,1)),
 //  DISP=NEW,DSN=&&MAC,
 //  RECFM=FB,LRECL=80,BLKSIZE=80
 X/SYSLIB   DD  DSN=SYS1.MACLIB,DISP=SHR
   7 //  DD  DISP=SHR,DSN=SYS1.MACLIB

I needed to specify DISP and DSN to override those in the
library proc.

And it fails the same with:

* TOP OF DATA **
** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYSL
 ,HELLO   ,C   ,4140,D,SYSLIB  ,UNKOWN,WRNG.LEN.RECORD,1F7100030
 BOTTOM OF DATA 

Experimental control: if I change BLKSIZE from 80 to 32760,
it assembles with no errors, and library macros are fetched
from the second catenand.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Gerhard Postpischil]

Bill Fairchild wrote:

The block length is indicated by the data length within the
count field.  A DASD block is written on the track with a
Write Count, Key and Data or Write Count, Key, and Data Next
Track command.  The length of a count field is always 8.  If
you are to write a block length of zero onto a track, you put
the block length into an 8-byte area in which you are
building the count field and you set the CCW's byte count to
8, for the number of bytes to be transferred to the
controller and written onto the track as a count field.  When
your software tries to read this block back later, the
controller sees the data length of zero and signals unit
exception along with the other ending status, then the access
method interprets unit exception as end of file and invokes
your EOF routine if you have one.


Correct, but slightly (?) misleading. The CCW byte count alone 
won't do it, unless the count record also has a key length and 
data length of zero set (interesting I/O errors result 
otherwise). To complicate matters, it is valid and occasionally 
desirable to have a write length other than 8, by writing a key 
+ zero data length. It's one way of stopping a search CCW on a 
later I/O.




Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Richard Peurifoy]

Paul Gilmartin wrote:

On Mon, 10 Aug 2009 16:52:59 -0500, Patrick O'Keefe wrote:

I'm just puzzled that the enhancement limited itself to QSAM.
No mention of BPAM.


I had hoped this was an oversight in the doc, but apparently
not.  An assembly with:

//SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,1)),
//  RECFM=FB,LRECL=80,BLKSIZE=80
//  DD  DISP=SHR,DSN=SYS1.MACLIB

Fails with:

* TOP OF DATA **
** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYSL
 ,HELLO   ,C   ,4140,D,SYSLIB  ,UNKOWN,WRNG.LEN.RECORD,1F7100030
 BOTTOM OF DATA 



Unless there is a typo, you concatenated a seq file (no directories)
with the PDS.

--
Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Patrick O'Keefe]

On Mon, 10 Aug 2009 17:20:48 -0500, Paul Gilmartin 
 wrote:

>On Mon, 10 Aug 2009 16:52:59 -0500, Patrick O'Keefe wrote:
>>
>>I'm just puzzled that the enhancement limited itself to QSAM.
>>No mention of BPAM.
>>
>I had hoped this was an oversight in the doc, but apparently
>not.  An assembly with:
>
>//SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,1)),
>//  RECFM=FB,LRECL=80,BLKSIZE=80
>//  DD  DISP=SHR,DSN=SYS1.MACLIB
>
>Fails with:
>
>* TOP OF DATA 
**
>** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent 
I/O error on SYSL
> ,HELLO   ,C   ,4140,D,SYSLIB  ,UNKOWN,WRNG.LEN.RECORD,00
001F7100030
>...

Um, I've got a hunch that wasn't a concatenation problem.  Did you 
have another dataset in the concatenation with a large blocksize?
If not, you probably got a blocksize of 80 ... much smaller than the
length of the records (blocks) that have to be read.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

On Mon, 10 Aug 2009 16:52:59 -0500, Patrick O'Keefe wrote:
>
>I'm just puzzled that the enhancement limited itself to QSAM.
>No mention of BPAM.
>
I had hoped this was an oversight in the doc, but apparently
not.  An assembly with:

//SYSLIBDD  UNIT=SYSALLDA,SPACE=(80,(1,1)),
//  RECFM=FB,LRECL=80,BLKSIZE=80
//  DD  DISP=SHR,DSN=SYS1.MACLIB

Fails with:

* TOP OF DATA **
** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYSL
 ,HELLO   ,C   ,4140,D,SYSLIB  ,UNKOWN,WRNG.LEN.RECORD,1F7100030
 BOTTOM OF DATA 

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Missing QPAM (was: Concatenations and blocksizes)

[Patrick O'Keefe]

On Mon, 10 Aug 2009 16:31:31 -0500, Paul Gilmartin 
 wrote:

>...
>>(I could ask for the umpteenth time why there is no QPAM, but
>>I won't.)
>>
>If you had asked (which you didn't) someone might have answered
>that it's because the definition of the NOTE word has no
>provision for specifying the offset of the current record
>within a block.  But that merely regresses the question (which
>you didn't ask) one level.
>...

Ok.  I'll buy that.  But NOTE didn't return anything at all until they 
wrote it.   So I'll regress:  These smart people could also have 
written NOTEX or QNOTE that returned all that was required to 
do queued processing of the member.  There must have been 
some reason they did not.  I hope.  What was that reason?
Anybody know?  (Idle curiosity.)

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Patrick O'Keefe]

On Mon, 10 Aug 2009 17:36:44 -0400, Thompson, Steve 
 wrote:

>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] 
On
>Behalf Of Patrick O'Keefe
>Sent: Monday, August 10, 2009 4:15 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: Concatenations and blocksizes
>
>On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden
> wrote:
>...
>
>Interesting wording.
>"partitioned ... data sets ... accessed by QSAM ..."
>
>>f they really meant that, wouldn't that restrict this enhancement
>>to a concatenation sequential datasets and/or PDS members?

Ok.   I shouldn't have included that statement.  It just muddied the
water.

>Doesn't a PDS or concatenation of PDSs have to be accessed by
>BPAM?

That's what I was really trying to ask.  

>...
>No. If you take a program that uses a QSAM DCB and point the DD
>statement to a PDS with member name, it will read that member 
>and treat it as if it were reading a DSORG=PS data set. The QSAM
>code will detect end of member and treat that as if it were EOD 
>(and I think it even drives your EOV exit if you have one).

I know a single member can be read with QSAM.
I assume a concatenation of members can be read by QSAM.
I was actually trying to exclude that uninteresting case from 
consideration.

>...
>So if you concatenate a series of DSORG=PS data sets together, 
>you can't concatenate a PDS as a PDS in the middle. ...

And I didn't want to.

>...
>OTOH, if you concatenate PDSs together as PDS and then stick in a
>DSORG=PS I would imagine you will get a very interesting ABEND 

And luckily I didn't want to do that, either.

I'm just puzzled that the enhancement limited itself to QSAM.
No mention of BPAM.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Hyper-PAVs

[gsg]

Anyone using Hyper PAvs with EMC DMX or know where to find information on 
implementing Hyper PAVs?  We are currently using Dynamic PAVs on z/OS 1.9 
and EMC DMX-3.

TIA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Infoprint set up in zos

[Howard Turetzky]

1) You must create VTAM APPL statements for each NetSpool LU name. See Chapter 
17. 
Defining NetSpool printer LUs to VTAM of Infoprint Server Operation and 
Administration 
S544-5745-10.

2) No application changes are required. 

3) IP PrintWay can send output from JES or NetSpool to TCP/IP attached printers 
using 
either the lpr/lpd protocol or the direct sockets protocol. The printers must 
be visible to 
z/OS from TCP/IP.



On Sun, 9 Aug 2009 21:52:28 -0500, Philip Chan  wrote:

>2 Question:
>
>1) For CICS printing, is it no change on current VTAM printer setup?
>2) No application programs needed to change?
>3) Implement IP Printway option will enable all printouts from normal PC
>printers?
>
>Thanks,
>Philip
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Patrick O'Keefe
Sent: Monday, August 10, 2009 4:15 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Concatenations and blocksizes

On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden 
 wrote:

>...
>"CONCATENATION ENHANCEMENT:  Like-attribute concatenation will be
>allowed for eligible data sets with different block sizes in any
>order; the largest no longer need be first.  Eligible data sets are
>partitioned or sequential data sets that are DASD-resident, accessed
>by QSAM, and for which the system obtained buffer space.
>...

Interesting wording. 
"partitioned ... data sets ... accessed by QSAM ..."

If they really meant that, wouldn't that restrict this enhancement
to a concatenation sequential datasets and/or PDS members?
Doesn't a PDS or concatenation of PDSs have to be accessed by
BPAM? 



No. If you take a program that uses a QSAM DCB and point the DD
statement to a PDS with member name, it will read that member and treat
it as if it were reading a DSORG=PS data set. The QSAM code will detect
end of member and treat that as if it were EOD (and I think it even
drives your EOV exit if you have one).

So if you concatenate a series of DSORG=PS data sets together, you can't
concatenate a PDS as a PDS in the middle. Well, maybe you can, if you
forced RECFM=U and BUFL=32760. But enjoy the dir blocks followed by ALL
the data blocks (as gas or still in use). 

OTOH, if you concatenate PDSs together as PDS and then stick in a
DSORG=PS I would imagine you will get a very interesting ABEND when the
FIND or BLDL that you do doesn't find any directory blocks in the
DSORG=PS file (you might even get an early ABEND out of OPEN - I haven't
tried this trick in a while).

Regards,
Steve Thompson

-- Opinions expressed by this poster may not reflect those held by
poster's employer --

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

On Mon, 10 Aug 2009 16:15:18 -0500, Patrick O'Keefe  wrote:

>On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden wrote:
>>...
>>"CONCATENATION ENHANCEMENT:  Like-attribute concatenation will be
>>allowed for eligible data sets with different block sizes in any
>>order; the largest no longer need be first.  Eligible data sets are
>>partitioned or sequential data sets that are DASD-resident, accessed
>>by QSAM, and for which the system obtained buffer space.
>>...
>
I think an earlier contributor wrote "DASD or tape".  I
found that unlikely because each tape label would have
to be read by OPEN; I welcome the clarification.  But
I could believe it would suffice if either the largest
block size was DASD-resident or it was specified in the
DD statement.

>Interesting wording.
>"partitioned ... data sets ... accessed by QSAM ..."
>
>If they really meant that, wouldn't that restrict this enhancement
>to a concatenation sequential datasets and/or PDS members?
>Doesn't a PDS or concatenation of PDSs have to be accessed by
>BPAM?
>
>I assume they meant QSAM or BPAM.
>(I could ask for the umpteenth time why there is no QPAM, but
>I won't.)
>
If you had asked (which you didn't) someone might have answered
that it's because the definition of the NOTE word has no
provision for specifying the offset of the current record
within a block.  But that merely regresses the question (which
you didn't ask) one level.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Bill Fairchild]

The block length is indicated by the data length within the count field.  A 
DASD block is written on the track with a Write Count, Key and Data or Write 
Count, Key, and Data Next Track command.  The length of a count field is always 
8.  If you are to write a block length of zero onto a track, you put the block 
length into an 8-byte area in which you are building the count field and you 
set the CCW's byte count to 8, for the number of bytes to be transferred to the 
controller and written onto the track as a count field.  When your software 
tries to read this block back later, the controller sees the data length of 
zero and signals unit exception along with the other ending status, then the 
access method interprets unit exception as end of file and invokes your EOF 
routine if you have one.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Paul Gilmartin
Sent: Monday, August 10, 2009 4:18 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Concatenations and blocksizes

On Mon, 10 Aug 2009 16:55:31 -0400, Bill Fairchild wrote:

>You have always been able to write a block of only one byte, or even zero 
>bytes, onto a DASD.
>
I thought a count of zero was prohibited in a CCW.  (But
there may be other ways.)

As for the minimum of 18 for tape, how does the access
method deal with a program that does RECFM=VB; OPEN
PUT RDW has count of 4; CLOSE; which would generate
an 8-byte block.  This might easily happen inadvertently
if a preceding block was filled and the 8-byte (or up
to 17-byte) block was the last block written before
CLOSE.  If RECFM=VBS, the access method _could_
pad with a null segment, but I don't know that null
segments are allowed for non-Spanned RECFM.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Paul Gilmartin]

On Mon, 10 Aug 2009 16:55:31 -0400, Bill Fairchild wrote:

>You have always been able to write a block of only one byte, or even zero 
>bytes, onto a DASD.
>
I thought a count of zero was prohibited in a CCW.  (But
there may be other ways.)

As for the minimum of 18 for tape, how does the access
method deal with a program that does RECFM=VB; OPEN
PUT RDW has count of 4; CLOSE; which would generate
an 8-byte block.  This might easily happen inadvertently
if a preceding block was filled and the 8-byte (or up
to 17-byte) block was the last block written before
CLOSE.  If RECFM=VBS, the access method _could_
pad with a null segment, but I don't know that null
segments are allowed for non-Spanned RECFM.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Patrick O'Keefe]

On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden 
 wrote:

>...
>"CONCATENATION ENHANCEMENT:  Like-attribute concatenation will be
>allowed for eligible data sets with different block sizes in any
>order; the largest no longer need be first.  Eligible data sets are
>partitioned or sequential data sets that are DASD-resident, accessed
>by QSAM, and for which the system obtained buffer space.
>...

Interesting wording. 
"partitioned ... data sets ... accessed by QSAM ..."

If they really meant that, wouldn't that restrict this enhancement
to a concatenation sequential datasets and/or PDS members?
Doesn't a PDS or concatenation of PDSs have to be accessed by
BPAM? 

I assume they meant QSAM or BPAM.
(I could ask for the umpteenth time why there is no QPAM, but
I won't.)

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Bill Fairchild]

You have always been able to write a block of only one byte, or even zero 
bytes, onto a DASD.

Bill Fairchild

Software Developer 
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.4503 * Mobile: +1.508.341.1715
Email: bi...@mainstar.com 
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Rick Fochtman
Sent: Monday, August 10, 2009 3:50 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Concatenations and blocksizes

--
I don't think so, there used to be a minimum BLKSIZE of 18, but that's 
not detected until you try to open the DSN. No open; no error.
IEFBR14 does no open.
--
IIRC, that 18-byte minimum applied only to tape. It was necessary so 
that the drive could distinguish between inter-block gaps and legitimate 
blocks.

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Rick Fochtman]

-
Isn't a STEPLIB opened before the program is loaded? Does the DCB used 
in that open override the JCL and/or the DSCB?


Program Fetch uses the directory data and the control data imbedded in 
the load module to do its I/O at a channel program level. As long as 
it's a valid LMOD, the DCB info is completely meaningless to Fetch. 
IIRC, the DCB it uses is a "skeleton" DCB similar to that used during 
EXCP or XDAP processing. As long as it has a valid DEB, that's what 
really matters.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Robert A. Rosenberg]

At 18:28 -0500 on 08/06/2009, Paul Gilmartin wrote about Re: 
Concatenations and blocksizes:



It is a misdesign that the OS allows this ever to happen.  The
principal use of this facility is to correct errors that were
introduced by its earlier inadvertent use.  Simply, any OPEN for
WRITE with overriding attributes where the label contains different
nonzero attributes should ABEND for inconsistent attributes.


IMO: This is (or should be) only an error if the supplied Blocksize 
is SMALLER than the VTOC one. Making the Blocksize larger (so long as 
it is still a multiple of the LRECL for a FB file and the RECFM is 
not FBS) has no effect since the now shorter blocks will still be 
read correctly. Only REDUCING the VTOC Blocksize would make 
older/larger blocks unreadable.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Rick Fochtman]

--
I don't think so, there used to be a minimum BLKSIZE of 18, but that's 
not detected until you try to open the DSN. No open; no error.

IEFBR14 does no open.
--
IIRC, that 18-byte minimum applied only to tape. It was necessary so 
that the drive could distinguish between inter-block gaps and legitimate 
blocks.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Mark Zelden]

The answer to (what I think is) the original question is DFP 2.3.  Which
means it was included with DFP 3.1 (MVS/ESA) or MVS/XA 2.2.3 (which was
required to install DFP 3.1 under MVS/XA IIRC).


"CONCATENATION ENHANCEMENT:  Like-attribute concatenation will be
allowed for eligible data sets with different block sizes in any
order; the largest no longer need be first.  Eligible data sets are
partitioned or sequential data sets that are DASD-resident, accessed
by QSAM, and for which the system obtained buffer space.
   This enhancement responded to SHARE requirement SOMVSE85065."

http://www-01.ibm.com/common/ssi/ShowDoc.jsp?docURL=/common/ssi/rep_ca/8/897/ENUS292-308/index.html&breadCrum=DET001PT022&url=buttonpressed=DET002PT005&specific_index=DET001PEF502&DET015PGL002=DET001PEF011&submit.x=7&submit.y=8&lang=en_US

tinyurl:  http://tinyurl.com/nn7zk2

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html




On Mon, 10 Aug 2009 14:22:04 -0500, Mark Zelden 
wrote:

>MVS/ESA SP 4 JCL Reference (DFP V3.3):
>
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea4b608/11.6?ACTION=MATCHES&REQUEST=concatenate&TYPE=FUZZY&SHELF=HAS4BS15&DT=19951023140514&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
>
>tinyurl: http://tinyurl.com/m95evc
>
>
>MVS/ESA SP 5 JCL Reference (DFSMS V1):
>
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea4b601/11.6?ACTION=MATCHES&REQUEST=concatenate&TYPE=FUZZY&SHELF=HAS4BK13&DT=19920925103155&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
>
>tinyurl: http://tinyurl.com/m25p6y
>
>
>More info from DFP 3.3 Using Data Sets on concatenating like data sets:
>
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igg3d400/3.7.2.2.1?ACTION=MATCHES&REQUEST=blksize&TYPE=FUZZY&SHELF=IGG3BK04&DT=19911220191126&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
>
>tinyurl: http://tinyurl.com/lvonxq
>
>
>--
>Mark Zelden
>Sr. Software and Systems Architect - z/OS Team Lead
>Zurich North America / Farmers Insurance Group - ZFUS G-ITO
>mailto:mark.zel...@zurichna.com
>z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
>Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ron Hawkins]

Gil,

My statement is poorly worded. I know it is not a restriction from XA
forward. I was just surprised that it was not required prior to XA Fetch.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Paul Gilmartin
> Sent: Monday, August 10, 2009 11:37 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Concatenations and blocksizes
> 
> On Mon, 10 Aug 2009 10:43:55 -0700, Ron Hawkins wrote:
> >
> >So you are saying that the largest BLKSIZE first restriction on
> >JOBLIB/STEPLIB did not apply before XA. I did not know that, but I do
now.
> >
> And apparently still doesn't.  By a crude experiment:
> 
> //STEPEXEC PGM=IEFBR14
> //STEPLIB  DD  DISP=SHR,DSN=SYS1.LINKLIB,BLKSIZE=1
> 
> Worked fine.
> 
> (But did I really test what I thought I tested?)
> 
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> >Behalf Of
> >> Shmuel Metz (Seymour J.)
> >> Sent: Monday, August 10, 2009 8:00 AM
> >>
> >> >The largest blksize first restriction did go away with for Fetch in
XA,
> >>
> >> There was no such restriction for Fetch. The various restrictions for
PO
> >> and PS went away with various releases of DFP and DFSMS.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: $ Sysplex

[Scott Rowe]

Yes, you can do GRS-RING using XCF communications without a CF, which would be 
a basic Sysplex.  If you had a CF you would use GRS-STAR, which would use XES, 
and thus be a Parallel Sysplex.
 
Of course, I am running a Parallel Sysplex, and it still didn't cost any 
additional money.

>>> "Gibney, Dave"  8/10/2009 2:38 PM >>>
  I was still thinking CF Sysplex. I expect that I might, someday be
able to do GRS with CTC connections. I don't yet understand Mark's
implication that I can do XCF without a CF Lpar or two. If that's what
he is really implying :)

  It's been a fun discussion, but today, my bottom line is to get my 1.7
to 1.9 finished before 1.9 is the oldest supported level :) My schedule
is currently as soon after our begin of semester freeze is over on
September 27. I expect 1.11 will be GA or close then :)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Scott Rowe
> Sent: Monday, August 10, 2009 6:53 AM
> To: IBM-MAIN@bama.ua.edu 
> Subject: Re: DASD: to share or not to share
> 
> As the only Sysprog here (real or otherwise), I understand your time
> concerns.  However, in my situation I decided that the benefits
> outweighed the cost (in time).  I find that many of the features of
> SYSPLEX can save me quite a bit of time (once it is set up).  Just the
> simplicity of having all DASD online to all systems can be a benefit.
> Of course, YMMV, but I think many small shops decide against SYSLEX
> without ever considering the benefits.
> 
> I am curious why you still put a $ next to SYSPLEX?
> 
> >>> "Gibney, Dave"  8/9/2009 5:39 PM >>>
> VSAM (and all SMS datasets) can't exist without being cataloged.
Shared
> Catalogs are not "safe" without integrity protection. Integrity
> protection takes MIM ($) or Sysplex ($) and both require time to
> configure and maintain. As the only real z/OS Sysprog here, I'm hard
> pressed to keep up as it is, so it's unlikely I'll ever plex and I
know
> we'll never buy MIM.
> 
> I should have been more specific. I only share a limited set of
non-SMS
> volumes and I do not put VSAM on them. Our CIS guy uses his shared
> volumes for some VSAM, but the data is not really shared as the
> Catalogs
> are not shared.
> 
> I don't share any SMS pools. If they want Production data for testing,
> they have to make a copy (generally using a couple of shared volumes
> designated for that specific purpose). Most of the shared datasets are
> JCL, PROC, LOAD, ISPxLIB, PARMLIB(s), etc.
> 
> I am fully aware of the risks I'm taking (I think so anyway).
> 
> What I need to do to remain employed here until retirement is learn
> then
> convince the Powers that Be, that zLinux is the best platform for the
> Oracle based ERP that's almost inevitable.
> 
> >
> > Thanks for you patience in educating this lowly applications
> developer.
> >
> > Frank
> > --
> >
> > Frank Swarbrick
> > Applications Architect - Mainframe Applications Development
> > FirstBank Data Corporation
> > Lakewood, CO  USA
> > P: 303-235-1403
> > F: 303-235-2075
> >
> >
> > On 8/9/2009 at 11:45 AM, in message
> > , Mark Zelden
> >  wrote:
> > > If children play with fire, they will eventually get burned!
> > >
> > >
> > > On Sat, 8 Aug 2009 22:42:04 -0600, Frank Swarbrick
> > >  wrote:
> > >
> > >>That is exactly what I did.  Well, "as quickly as I could type",
in
> any
> > case.
> > >>We have PDSESHARING(NORMAL) in our IGDSMSxx file, for whatever
that
> > might
> > > be worth.
> > >>
> > >
> > > It's worth nothing in regards to sharing PDSE across sysplex
> boundaries
> > for
> > > anything but READ ONLY functions.
> > >
> > >>On 8/8/2009 at 1:31 AM, in message
> > >>,
> > "Gibney,
> > >>Dave"  wrote:
> > >>> Actually I was speculating about the ability to "refresh" in
> memory
> > >>> knowledge of the PDSE(s) in the other LPAR(s).
> > >
> > > There is no command or facility to do that.  There is the sledge
> hammer
> > > approach of IPLing.   :-)   Well... it may not be all that bad -
> more
> > below.
> > >
> > >
> > >>> What you describe is not
> > >>> guaranteed.
> > >>>   Try 1. Run existing copy of the program in LPAR-P. 2. Quickly
> update
> > >>> it from LPAR-other. 3. Quickly try in LPAR-P. I don't believe
you
> will
> > >>> always get the new version.
> > >
> > > Apparently he did.  But why?  (more below)
> > >
> > >>>
> >  -Original Message-
> >  From: IBM Mainframe Discussion List [mailto:IBM-
> m...@bama.ua.edu] 
> On
> >  Behalf Of Frank Swarbrick
> >  Sent: Friday, August 07, 2009 1:34 PM
> >  To: IBM-MAIN@bama.ua.edu 
> >  Subject: Re: DASD: to share or not to share
> > 
> >  So for example, if our change control process for applications
> runs
> > in
> > >>> DEV
> >  (which is how we have it in VSE) we should be able to update
our
> >  production application loadlib PDSE from DEV exclusively and
> this
> > will
> > >>

OT: Computer History from the early 1940's

[Lionel Dyck]

A little bit of history on computers that some (perhaps most) never knew:

http://topsecretrosies.wordpress.com/




Lionel B. Dyck, z/Linux Virtualization Specialist
IBM Global Services - Kaiser Permanente Team
Linux on System z Service Delivery Team
925-926-5332 (8-473-5332) | E-Mail: ld...@us.ibm.com
AIM: lbdyck | Yahoo IM: lbdyck


I never guess. It is a capital mistake to theorize before one has data.
Insensibly one
begins to twist facts to suit theories, instead of theories to suit facts.
- Sir Arthur Conan Doyle

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Mark Zelden]

MVS/ESA SP 4 JCL Reference (DFP V3.3):

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea4b608/11.6?ACTION=MATCHES&REQUEST=concatenate&TYPE=FUZZY&SHELF=HAS4BS15&DT=19951023140514&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT

tinyurl: http://tinyurl.com/m95evc


MVS/ESA SP 5 JCL Reference (DFSMS V1):

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea4b601/11.6?ACTION=MATCHES&REQUEST=concatenate&TYPE=FUZZY&SHELF=HAS4BK13&DT=19920925103155&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT

tinyurl: http://tinyurl.com/m25p6y


More info from DFP 3.3 Using Data Sets on concatenating like data sets:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igg3d400/3.7.2.2.1?ACTION=MATCHES&REQUEST=blksize&TYPE=FUZZY&SHELF=IGG3BK04&DT=19911220191126&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT

tinyurl: http://tinyurl.com/lvonxq


--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CEAServer Character Special File

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kopischke, David G.
> Sent: Monday, August 10, 2009 1:59 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: CEAServer Character Special File
> 
> Greetings,
>I came across this while trying to expand a /var linear file.
> 
> crwxrwxrwx   1 BPXDFLTU BPXDFLTG   6,  0 Jan 14  2009 CEAServer*
> 
>Since DSS likes to restore at the defined size, I defined a new
> VAR linear file and mounted it and copied all the entries from /var.
> This character special file won't copy.
> 
>I don't know what this is for other than Common Event Adapter. I
> searched the archives and find a couple references to the process,
> but not this file nor how to manage it. If I just leave it out of
> the new /var, will the process regenerate it ???
> 
> Thanks,
> Dave K.

How did you try to copy that? It is a "character special" file and "cp" won't 
copy it. Use "pax" or "tar". They should be able to copy it.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

CEAServer Character Special File

[Kopischke, David G.]

Greetings,
   I came across this while trying to expand a /var linear file.

crwxrwxrwx   1 BPXDFLTU BPXDFLTG   6,  0 Jan 14  2009 CEAServer*

   Since DSS likes to restore at the defined size, I defined a new
VAR linear file and mounted it and copied all the entries from /var.
This character special file won't copy.

   I don't know what this is for other than Common Event Adapter. I
searched the archives and find a couple references to the process,
but not this file nor how to manage it. If I just leave it out of
the new /var, will the process regenerate it ???

Thanks,
Dave K.


--
This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications. 
==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ted MacNEIL]

>Isn't a STEPLIB opened before the program is loaded?

Sorry, my bad.
Poor eyesight and a BlackBerry means I missed the DDNAME.

>Does the DCB used in that open override the JCL and/or the DSCB?

I'm not actually sure what BLKSIZE is used for a STEPLIB, actual or specified.

I'll go back into my hole, now!
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Richard Peurifoy]

Ted MacNEIL wrote:

And apparently still doesn't.  By a crude experiment:



   //STEPEXEC PGM=IEFBR14
   //STEPLIB  DD  DISP=SHR,DSN=SYS1.LINKLIB,BLKSIZE=1



Worked fine.


Of course it did!
IEFBR14 has (effectively) two instructions:

   SR 15,15
   BR 14

NO open.


(But did I really test what I thought I tested?)


I don't think so, there used to be a minimum BLKSIZE of 18, but that's not 
detected until you try to open the DSN.
No open; no error.
IEFBR14 does no open.


I think what he Gill was testing was that program fetch didn't care
about blksize, in which case I think he did test it, and got the
result I would expect. There may have been a time when program fetch
cared, but if so, I don't remember it.

By the way I think the 18 byte minimum was only for tape.

--
Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Schwarz, Barry A]

Isn't a STEPLIB opened before the program is loaded?  Does the DCB used
in that open override the JCL and/or the DSCB?

-Original Message-
From: Ted MacNEIL [mailto:eamacn...@yahoo.ca] 
Sent: Monday, August 10, 2009 11:44 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Concatenations and blocksizes

>And apparently still doesn't.  By a crude experiment:

>//STEPEXEC PGM=IEFBR14
>//STEPLIB  DD  DISP=SHR,DSN=SYS1.LINKLIB,BLKSIZE=1

>Worked fine.

Of course it did!
IEFBR14 has (effectively) two instructions:

   SR 15,15
   BR 14

NO open.

>(But did I really test what I thought I tested?)

I don't think so, there used to be a minimum BLKSIZE of 18, but that's
not detected until you try to open the DSN.
No open; no error.
IEFBR14 does no open.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ted MacNEIL]

>And apparently still doesn't.  By a crude experiment:

>//STEPEXEC PGM=IEFBR14
>//STEPLIB  DD  DISP=SHR,DSN=SYS1.LINKLIB,BLKSIZE=1

>Worked fine.

Of course it did!
IEFBR14 has (effectively) two instructions:

   SR 15,15
   BR 14

NO open.

>(But did I really test what I thought I tested?)

I don't think so, there used to be a minimum BLKSIZE of 18, but that's not 
detected until you try to open the DSN.
No open; no error.
IEFBR14 does no open.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DASD: to share or not to share

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of R.S.
> Sent: Monday, August 10, 2009 4:53 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DASD: to share or not to share
> 
> Gibney, Dave pisze:
> > VSAM (and all SMS datasets) can't exist without being cataloged.
> 
> Well... To be accurate: they cannot be *used* without being cataloged.
> But they can exist.
> 
> 
> > Shared
> > Catalogs are not "safe" without integrity protection.
> 
> Huh? AFAIK It is safe and fully supported to share an UCAT without GRS
> or MIM. That means RESERVEs and can hurt performance, but it is
> possible
> to safely and effectively share low-used UCAT. BTDT.

OK, I'll take yours and Mark's word for it. I'm sure I remember a problem with 
shared Catalogs sometime in the past. This memory could be a figment. 

I can have any volume online to any LPAR, IF I NEED TO, but in general, I 
isolate most application data volumes (SMS pools) to the correct LPAR. 


> 
> So, it is possible to share volumes, including SMS managed volumes and
> VSAM files. Application files.
> I would be very careful when talking about sharing system datasets and
> volumes because the system is the most breaking rules user of the
> datasets.
> Last but not least: sharing datasets doesn't mean that many
> applications
> can update them concurrently. It can or (more likely) cannot be don
> even
> within single MVS image.
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> --
> BRE Bank SA
> ul. Senatorska 18
> 00-950 Warszawa
> www.brebank.pl
> 
> Sd Rejonowy dla m. st. Warszawy
> XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
> nr rejestru przedsibiorców KRS 025237
> NIP: 526-021-50-88
> Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w
> caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj
> warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI
> WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika
> 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w
> podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

$ Sysplex

[Gibney, Dave]

  I was still thinking CF Sysplex. I expect that I might, someday be
able to do GRS with CTC connections. I don't yet understand Mark's
implication that I can do XCF without a CF Lpar or two. If that's what
he is really implying :)

  It's been a fun discussion, but today, my bottom line is to get my 1.7
to 1.9 finished before 1.9 is the oldest supported level :) My schedule
is currently as soon after our begin of semester freeze is over on
September 27. I expect 1.11 will be GA or close then :)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Scott Rowe
> Sent: Monday, August 10, 2009 6:53 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DASD: to share or not to share
> 
> As the only Sysprog here (real or otherwise), I understand your time
> concerns.  However, in my situation I decided that the benefits
> outweighed the cost (in time).  I find that many of the features of
> SYSPLEX can save me quite a bit of time (once it is set up).  Just the
> simplicity of having all DASD online to all systems can be a benefit.
> Of course, YMMV, but I think many small shops decide against SYSLEX
> without ever considering the benefits.
> 
> I am curious why you still put a $ next to SYSPLEX?
> 
> >>> "Gibney, Dave"  8/9/2009 5:39 PM >>>
> VSAM (and all SMS datasets) can't exist without being cataloged.
Shared
> Catalogs are not "safe" without integrity protection. Integrity
> protection takes MIM ($) or Sysplex ($) and both require time to
> configure and maintain. As the only real z/OS Sysprog here, I'm hard
> pressed to keep up as it is, so it's unlikely I'll ever plex and I
know
> we'll never buy MIM.
> 
> I should have been more specific. I only share a limited set of
non-SMS
> volumes and I do not put VSAM on them. Our CIS guy uses his shared
> volumes for some VSAM, but the data is not really shared as the
> Catalogs
> are not shared.
> 
> I don't share any SMS pools. If they want Production data for testing,
> they have to make a copy (generally using a couple of shared volumes
> designated for that specific purpose). Most of the shared datasets are
> JCL, PROC, LOAD, ISPxLIB, PARMLIB(s), etc.
> 
> I am fully aware of the risks I'm taking (I think so anyway).
> 
> What I need to do to remain employed here until retirement is learn
> then
> convince the Powers that Be, that zLinux is the best platform for the
> Oracle based ERP that's almost inevitable.
> 
> >
> > Thanks for you patience in educating this lowly applications
> developer.
> >
> > Frank
> > --
> >
> > Frank Swarbrick
> > Applications Architect - Mainframe Applications Development
> > FirstBank Data Corporation
> > Lakewood, CO  USA
> > P: 303-235-1403
> > F: 303-235-2075
> >
> >
> > On 8/9/2009 at 11:45 AM, in message
> > , Mark Zelden
> >  wrote:
> > > If children play with fire, they will eventually get burned!
> > >
> > >
> > > On Sat, 8 Aug 2009 22:42:04 -0600, Frank Swarbrick
> > >  wrote:
> > >
> > >>That is exactly what I did.  Well, "as quickly as I could type",
in
> any
> > case.
> > >>We have PDSESHARING(NORMAL) in our IGDSMSxx file, for whatever
that
> > might
> > > be worth.
> > >>
> > >
> > > It's worth nothing in regards to sharing PDSE across sysplex
> boundaries
> > for
> > > anything but READ ONLY functions.
> > >
> > >>On 8/8/2009 at 1:31 AM, in message
> > >>,
> > "Gibney,
> > >>Dave"  wrote:
> > >>> Actually I was speculating about the ability to "refresh" in
> memory
> > >>> knowledge of the PDSE(s) in the other LPAR(s).
> > >
> > > There is no command or facility to do that.  There is the sledge
> hammer
> > > approach of IPLing.   :-)   Well... it may not be all that bad -
> more
> > below.
> > >
> > >
> > >>> What you describe is not
> > >>> guaranteed.
> > >>>   Try 1. Run existing copy of the program in LPAR-P. 2. Quickly
> update
> > >>> it from LPAR-other. 3. Quickly try in LPAR-P. I don't believe
you
> will
> > >>> always get the new version.
> > >
> > > Apparently he did.  But why?  (more below)
> > >
> > >>>
> >  -Original Message-
> >  From: IBM Mainframe Discussion List [mailto:IBM-
> m...@bama.ua.edu]
> On
> >  Behalf Of Frank Swarbrick
> >  Sent: Friday, August 07, 2009 1:34 PM
> >  To: IBM-MAIN@bama.ua.edu
> >  Subject: Re: DASD: to share or not to share
> > 
> >  So for example, if our change control process for applications
> runs
> > in
> > >>> DEV
> >  (which is how we have it in VSE) we should be able to update
our
> >  production application loadlib PDSE from DEV exclusively and
> this
> > will
> > >>> not
> >  be a problem, even without a Sysplex?  I am curious as to where
> I
> > find
> >  this PDSE address space refresh command, and if it's really
> needed.
> > I
> >  just compiled a program in to a PDSE in DEV and ran it in PROD
> and it
> > >>> ran
> >  the new version just fine.  Did it twice just to make

Re: Concatenations and blocksizes

[Paul Gilmartin]

On Mon, 10 Aug 2009 10:43:55 -0700, Ron Hawkins wrote:
>
>So you are saying that the largest BLKSIZE first restriction on
>JOBLIB/STEPLIB did not apply before XA. I did not know that, but I do now.
>
And apparently still doesn't.  By a crude experiment:

//STEPEXEC PGM=IEFBR14
//STEPLIB  DD  DISP=SHR,DSN=SYS1.LINKLIB,BLKSIZE=1

Worked fine.

(But did I really test what I thought I tested?)

>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>Behalf Of
>> Shmuel Metz (Seymour J.)
>> Sent: Monday, August 10, 2009 8:00 AM
>>
>> >The largest blksize first restriction did go away with for Fetch in XA,
>>
>> There was no such restriction for Fetch. The various restrictions for PO
>> and PS went away with various releases of DFP and DFSMS.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SNA: conflicting opinions

[Anne & Lynn Wheeler]

chrisma...@belgacom.net (Chris Mason) writes:
> Probably the "architects" had one in mind to be rolled out eventually. After 
> all, 
> OSI was supposed to take over the world - starting with the governments.[2]
>
> Incidentally, you are guilty of violating the ISO model here. A "layer" is 
> placed 
> between a lower "layer" and an "upper" layer, accepts services from the lower 
> layer and provides services to the "upper" layer. It can be said to have a 
> *vertical* function. Although we probably have some difficulty agreeing 
> mutually what "internetworking" might mean, it cannot logically be a layer 
> since I would expect the broadest interpretation of "internetworking" to 
> imply 
> an *horizontal* function.

re:
http://www.garlic.com/~lynn/2009l.html#3 VTAM security issue
http://www.garlic.com/~lynn/2009l.html#7 VTAM security issue
http://www.garlic.com/~lynn/2009l.html#11 VTAM security issue

as an aside ... the network layers on different nodes can interact
... i.e. like ARP and ARP cache operations. most implementation also
have service definitions which can be things that sit outside the layers
(as defined in OSI model).

I was on the XTP technical advisory board and participated in taking
"HSP protocol" (high-speed protocol) to x3s3.3 for standardization
(x3s3.3 was US iso-chartered organization for level 3 & level 4
standards ... i.e.  networking layer and transport layer). ISO had a
policy that it would not accept work for standards that violated the OSI
model.

HSP protocol was rejected by x3s3.3 for standardization because
it violated OSI model:

1) HSP supported internetworking ... which doesn't exist in the OSI
model ... and therefor couldn't be considered for standardization by ISO
or ISO chartered organization. Internetworking corresponds approximately
to a non-existing layer between layer 3/network and layer 4/transport.

2) HSP went directly from level 4/transport directly to LAN MAC interface
... bypassing the layer 3/4 (networking/transport) interface
... violating the OSI model ... and therefor couldn't be considered for
standardization by ISO or ISO chartered organization

3) HSP went directly from level 4/transport directly to LAN MAC
interface ... LAN MAC interface doesn't exist in the OSI model ... the
LAN MAC interface sits approximately in the middle of the networking
layer (LAN/MAC subsumes part of the feature/function defined in the
network layer). Since HSP went directly to LAN MAC interface, something
that doesn't exist in the OSI model, it couldn't be considered for
standardization by ISO or ISO chartered organization.

misc. past posts mentioning XTP and HSP standardization work (and ISO
policy of not accepting standards work items that violate OSI model):
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

there is lots of past folklore about why OSI&ISO was the way it was.

part of the folklore is that it was done by traditional telco and
communication people ... that actually had little experience trying to
deal with interoperability between multiple different networks.  The
people in the govs. tended to even have much less experience dealing
with interoperability between multiple networks (than the people in the
standards group).

another distinction periodically cited was that IETF (the internet
standardization organization) has required at least two different
interoperable implementations before something could be standardized. 
ISO doesn't require any actual implementation prior to standardization
(it is periodically claimed it is possible to have ISO standards that
are impossible to implement).

I had mentioned interop88 ... misc. past posts
http://www.garlic.com/~lynn/subnetwork.html#interop88

 ... and the (US Federal) GOSIP mandates were starting to come on strong
(internet will be eliminated and everything replaced by products that
conformed to OSI/ISO standards) ... so even though interop88 was
nominally annual internetworking (TCP/IP) ... lots of the vendors (&
booths) were showing "OSI" products.  Part of this was that many of the
vendors had little more experience with the difficulty of interoperating
between networks (than the GOSIP people, other gov. people and/or the
ISO/OSI standards people).

a few old posts mentioning bits & pieces of GOSIP:
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
http://www.garlic.com/~lynn/2002g.html#21 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#30 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My 
Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#45 Hey! Keep Your Hands Out Of My 
Abstraction Layer!

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar1970

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

The weather in Endicott

[Pamela Christina - humid and hot in Endicott]

Hi Gil,
Sorry to disappoint...no weather bot.  Just a low-tech
typing over where note puts my tel num and replace it with weather.
Today actually feels like the first day of summer -hot and humid.

>gil said
> I keep imagining that Pamela Christina has a weatherbot
>that connects to a local weather site and automatically
>extracts the adjective to insert in her return address.
>

Hope you're all enjoying great weather wherever you are.

Regards, PLC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Ron Hawkins]

Shmuel,

Thanks. I'm an XA child, and I was under the impression that the IO
mechanism for Fetch changed going from SP2 to XA.

So you are saying that the largest BLKSIZE first restriction on
JOBLIB/STEPLIB did not apply before XA. I did not know that, but I do now.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Shmuel Metz (Seymour J.)
> Sent: Monday, August 10, 2009 8:00 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Concatenations and blocksizes
> 
> In <000301ca1735$86fa8130$94ef83...@hawkins1960@sbcglobal.net>, on
> 08/07/2009
>at 01:03 AM, Ron Hawkins  said:
> 
> >The largest blksize first restriction did go away with for Fetch in XA,
> 
> There was no such restriction for Fetch. The various restrictions for PO
> and PS went away with various releases of DFP and DFSMS.
> 
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Loading SMF data into a DB2 database.

[Ron Hawkins]

Here's a clue: most people call him "Barry."

> Last but not least: I wonder if any human being is able to understand
> and *remeber* all the SMF record formats.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DASD: to share or not to share

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S.
> Sent: Monday, August 10, 2009 11:41 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DASD: to share or not to share

> 
> In fact VSAM datasets are safe as long as an application respects 
> shareoptions. For PS datasets - there is no system-supported way to 
> share it within single image (EXCEPT DISP=SHR), however it is 
> worth to 
> mention that there is no GRS ENQ. That means the ENQ is not 
> visible on 
> another system.

Enhanced Data Integrity,

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2DI30/4.4


Enhanced data integrity prevents accidental data loss when concurrent users are 
writing to a shared sequential data set. 


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D470/3.4.1


 You can concurrently access a shared sequential data set for output or update 
processing. In some cases, you can lose or destroy data when you update the 
data set, because one user could, at the same time, overwrite another user's 
updates.

The enhanced data integrity function prevents this type of data loss. This data 
integrity function either ends the program that is opening a sequential data 
set that is already opened for writing, or it writes only a warning message but 
allows the data set to open. Only sequential data sets can use the enhanced 
data integrity function. 



> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland



John McKown 

Systems Engineer IV

IT

 

Administrative Services Group

 

HealthMarkets(r)

 

9151 Boulevard 26 * N. Richland Hills * TX 76010

(817) 255-3225 phone * (817)-961-6183 cell

john.mck...@healthmarkets.com * www.HealthMarkets.com

 

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Shmuel Metz (Seymour J.)]

In <000301ca1735$86fa8130$94ef83...@hawkins1960@sbcglobal.net>, on
08/07/2009
   at 01:03 AM, Ron Hawkins  said:

>The largest blksize first restriction did go away with for Fetch in XA,

There was no such restriction for Fetch. The various restrictions for PO
and PS went away with various releases of DFP and DFSMS.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Concatenations and blocksizes

[Shmuel Metz (Seymour J.)]

In , on 08/06/2009
   at 12:21 PM, "Patrick O'Keefe"  said:

>1.  How long ago did this requirement disappear?

Which requirement? For PO? For PS? There are multiple dates, depending on
what you're asking.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DASD: to share or not to share

[R.S.]

Mark Zelden pisze:
[[[.]

It is safe and fully supported to share an UCAT without GRS
or MIM. That means RESERVEs and can hurt performance, but it is possible
to safely and effectively share low-used UCAT. BTDT.



Somehow I missed commenting on that part in my last response.  Yes,
RESERVE will protect the catalog (but again, not the data sets cataloged in the 
catalog).  [...]


In fact VSAM datasets are safe as long as an application respects 
shareoptions. For PS datasets - there is no system-supported way to 
share it within single image (EXCEPT DISP=SHR), however it is worth to 
mention that there is no GRS ENQ. That means the ENQ is not visible on 
another system.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DASD: to share or not to share

[Walter Marguccio]

> - Original Message 
> From: Mark Zelden mark.zel...@zurichna.com

> Out of curiosity:  What type of XCF inks (ESCON or FICON)?  How many?

we have ESCON XCF links. Every LPAR has 4 PATHIN and 4 PATHOUT
which connect to/from either LPARs.

> Do you have XCF transport classes set up / tuned?

I have a DEFAULT TC (956 Class length) and a BIG TC (16316 CL).
Only one PATHOUT amongs the 4 is associated to the BIG TC.


Walter Marguccio
z/OS Systems Programmer
BELENUS LOB Informatic GmbH
Munich - Germany

Send instant messages to your online friends http://uk.messenger.yahoo.com 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Job Posting

[Chris Mason]

John

Identifying the post to which you are referring can, however, be a 
worthwhile "referral".

Chris Mason

On Mon, 10 Aug 2009 09:10:28 -0500, Eatherly, John D[EQ] 
 wrote:

>I am not interested in the referral money.  I just wanted to send it out to 
get it to someone who needs it.
>
>Thanks.
>
>
>John

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DASD: to share or not to share

[Scott Rowe]

Yes, GRS using XCF is far superior in many ways, I would certainly not advise 
using GRS ring (without XCF) for a 4 way GRSplex, but using XCF it would 
certainly work.  Of course, GRS-Star would be even better, but that is a little 
trickier.
 
BTW, for small packets of data, I believe ESCON links are actually faster than 
FICON.  I think I have seen a paper on this, but I can't remember where.

>>> Mark Zelden  8/10/2009 9:41 AM >>>
On Sun, 9 Aug 2009 21:01:42 -0700, Gibney, Dave  wrote:


>
>True, and last time we revamped the IODF I had the required CTC(s)
>added. That was over a year ago when we brought in the z9-BC and is the
>last time I had a chance to take a baby step that direction. Also, on
>this list, I'm led to understand that our four would LPARs push or
>exceed GRS ring performance.
>

Yes, for the "old" GRS ring, 4 systems would probably be a bigger performance
hit than you would ever want.   However, if you set up a basic sysplex, GRS 
performance using XCF is better than dedicated CTC links.  Especially since
you can have FICON CTCs.  Dedicated GRS links (what I referred to as "old"
above) can't get any faster than ESCON in basic mode.  So even XCF links
using ESCON in CTC mode is faster and may give you acceptable performance
with 4 systems.  As usual, YMMV.I can't say I have been in any 4 system
GRS ring (using XCF) shops in the last 10 years, so perhaps someone with
that configuration can share.  I do have plenty of experience with GRS ring
prior to sysplex and I can say that even a 3 system ring presented some 
performance.. um... challenges.  :-)

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com 
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ 
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html 



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SNA: conflicting opinions (was Re: VTAM Security issue)

[Chris Mason]

Lynn (I guess[1])

I see this is no longer discussing "VTAM security" but is hinged to one of my 
lead-in comment regarding "an universal network".

There are some policemen in this list who require subject drift properly to be 
documented - or they will complain - even if the complaint is unjustified and 
there has not been any subject drift - but in this case, there has been.

-

Once I had got deep into this post I realised why SNA was being slagged off 
so much. It's all down to lost political fights within IBM over which it is now 
pointless to keep mulling. Just about all these negative comments regarding 
SNA should be ignored as futile raving. Do they contain any useful messages 
for now and the future?

It would be helpful - and this may even be "on topic" regarding the origin of 
the thread - if  posters would declare their interests at the beginning so that 
biased comments can be seen as such - as is required of politicians in some 
legislatures.

-

> SNA isn't a networking infrastructure, it is large closed dumb terminal 
> control 
infrastructure.

Correct only if referring to SNA as originally announced up until VTAM was 
offered as ACF/VTAM in 1980/81. Otherwise profoundly wrong!

> It is even more restrictive than OSI ...

Arguable. OSI in my experience with the IBM products which implemented it - 
for teaching purposes only - never really got developed very far.

> ... which also wasn't an open infrastructure.

Again arguable. Theoretically it was "open". In practical terms, it may not 
have delivered the possibilities that the label "open" suggested. My experience 
was only with one vendor's products so obviously I can't comment much about 
that. I heard the Japanese were still giving it a go after everyone else 
abandoned the architecture.

> SNA lacked both a network layer ...

True of pre-ACF VTAM and NCP, not afterwards. Skipping releases 1 and 2, 
release 3 (SNA 4.2) offered the virtual route network layer between VTAM 
(type 5) and NCP (type 4) nodes - not to bother with TCAM to keep matters 
simpler. This may be cumbersome in comparison with the IP networks of the 
mid-80's - when I first paid attention to them - which could involve much 
smaller machines than those running VTAM and NCP, but it's still routing from 
node to node.

I tried to see on what narrow definition of the capabilities a "network" layer 
should have  could allow IP to pass and SNA to fail. I failed I'm unhappy to 
say! I had an idea that maybe the header used for routing - surely the key 
characteristic of a "network" layer - which is built in the source node should 
not be changed in reaching the destination node. But subarea SNA actually 
qualifies here - over the virtual route - whereas APPN Intermediate Session 
Routing (ISR) and High Performance Routing (HPR) do not. Actually all this 
requires no segmenting over the virtual route - and no fragmentation in IP.

> ... as well as a internetworking layer ...

Perhaps SNI introduced with ACF/VTAM and NCP V2R2 IIRC has been 
overlooked for some reason I could not possibly guess. Perhaps again there is 
more than one understanding of what "internetworking" could be intended to 
mean. It defies belief that anyone anywhere near IBM in the '80s and '90s 
could overlook the pervasive nature of enterprises with their own SNA 
networks interlinking them with other enterprises, with or without the aid of 
the IBM networks.

I'm supposed to have overlooked a joke post or two in a thread recently. 
Perhaps I'm being blind to a joke here.

> ... while OSI had a network layer ...

OSI even called it a "network layer" - sandwiched between the "data link 
control layer" and the "transport layer" just as the ISO model says it should 
be. When VIPAs appeared I was intrigued to note that the entities of the 
OSI "network layer" comprised one which corresponds to one of the uses of 
the static VIPA in the Communications Server IP component.

> ... but also lacked an internetworking layer.

Probably the "architects" had one in mind to be rolled out eventually. After 
all, 
OSI was supposed to take over the world - starting with the governments.[2]

Incidentally, you are guilty of violating the ISO model here. A "layer" is 
placed 
between a lower "layer" and an "upper" layer, accepts services from the lower 
layer and provides services to the "upper" layer. It can be said to have a 
*vertical* function. Although we probably have some difficulty agreeing 
mutually what "internetworking" might mean, it cannot logically be a layer 
since I would expect the broadest interpretation of "internetworking" to imply 
an *horizontal* function.

I'd better ignore "layer" following "internetworking" in what follows.

> The internetworking layer (found in IP) was necessary for creating an open 
infrastructure (as a layer that would internetwork networks).

I don't believe it is necessary to have invented IP in order to 
have "internetworking". If you are relying on the normal IP terminology

Re: DASD: to share or not to share

[Mark Zelden]

On Mon, 10 Aug 2009 07:20:35 -0700, Walter Marguccio
 wrote:

>>>On Sun, 9 Aug 2009 21:01:42 -0700, Gibney, Dave  wrote:
>
>>> I'm led to understand that our four would LPARs push or exceed GRS ring
performance.
>
>>From: Mark Zelden mark.zel...@zurichna.com
>
>> I can't say I have been in any 4 system GRS ring (using XCF) shops
>> in the last 10 years, so perhaps someone with that configuration can share.
>
>we have such configuration. We recently added a 4th LPAR to our existing
>3-LPARs basic sysplex. I had the same concerns as Dave's, but after more than
>one month I can say GRS ring (exploiting XCF) is not a problem.
>I use RMF PM to keep on eye on XCF delays, and the average delay GRS shows
>is around 4 %.  Which is acceptable to me. We have still a 2086-230, z/OS 1.7
>everywhere except z/OS 1.9 on the sandbox LPAR.
>
>
>Walter Marguccio
>z/OS Systems Programmer
>BELENUS LOB Informatic GmbH
>Munich - Germany
>

Out of curiosity:  What type of XCF inks (ESCON or FICON)?   How many?
Do you have XCF transport classes set up / tuned?

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Trigger CICS transaction from Batch Job

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jan MOEYERSONS
> Sent: Monday, August 10, 2009 5:41 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Trigger CICS transaction from Batch Job
> 
> On Fri, 7 Aug 2009 08:01:34 -0500, McKown, John 
>  wrote:
> 
> >
> >What he needs to do is use REXX sockets to write a z/OS 
> TN3270 client. 
> >This client could then connect as a 3270 terminal to the 
> CICS region and 
> 
> 
> But instead of connecting to a 3270 terminal, the connection 
> should be made 
> to the CICS listener CSKL. Works like a charm. With security 
> if you need it and 
> no sweat exchanging information back and forth between the 
> batch program 
> and the CICS transaction.
> 
> Cheers,
> 
> Jantje.

That is a good idea! I'll put it in my "bag of tricks"!

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: VTAM security issue

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2009l.html#3 VTAM security issue
http://www.garlic.com/~lynn/2009l.html#7 VTAM security issue

the communication division did provide the basis for rapid uptake of
personal computers via terminal (communication) emulation. A customer
could get an ibm/pc with terminal (communication) emulation for about
the same price as a 3270 terminal ... which would both provide for
3270 terminal function as well as some local computing ... in a single
desktop foot-print. For a lot of customers ... is was nearly
brain-dead task to change already justified 3270 terminals to IBM/PCs
... significantly simplifying what was needed to order tens of
thousands of IBM/PCs.

The result, was the communication division grew a significantly
terminal emulation install base. Later, as PCs became more powerful
and were starting to implement all sorts of networking features ...
there was determined effort by the communication division to preserve
its terminal emulation install base.

The result was that lots of data started leaking out of the datacenter
into distributed environment ... because the limited "terminal
emulation" spigot was starting to represent a significant business
bottleneck. The disk division developed some number of powerful
solutions ... which were constantly being vetoed by the communication
division (my earlier reference to the truce with my wife that
everything that crossed the datacenter walls had to be SNA).

In the late 80s, the situation had gotten so bad that a senior engineer
from the disk division managed to get a talk scheduled at the annual,
world-wide, internal communication division conference. They began their
talk with the statement that the head of the communication division was
going to be responsible for the demise of the disk division (because the
terminal emulation communication was becoming an increasingly severe
bottleneck for use of the mainframe data and so users were taking the
data completely out of the mainframe/datacenter to more friendly
environs).

misc. past posts discussing the terminal emulation (communication)
issue
http://www.garlic.com/~lynn/subnetwork.html#emulation

in that same time-frame we had come up with 3-tier (middle layer,
middleware, etc) networking architecture and were out pitching it to
customer executives. We were taking lots of barbs from the
communication division ... that was trying to preserve the terminal
emulation communication paradigm. misc. past posts about 3-tier
networking architecture
http://www.garlic.com/~lynn/subnetwork.html#3tier

this also played a factor in the internet exceeding the size of the
internal network in late '85 (possibly early '86). arpanet/internet
saw big limitating factor removed with the great change-over to
interworking protocol on 1jan83. This somewhat put it on level footing
with internal networking with gateway capability (w/o gateways, there
tends to be much higher level of end-to-end coordination and
management of all the components in the network, representing a
barrier to adding new components).

Then tcp/ip full networking capability was being deployed on
workstations and PCs ... while internally, such computers were limited
to connectivity by terminal emulation communication. The number of
internet network nodes really exploded by including workstations and
PCs.



-- 
40+yrs virtualization experience (since Jan68), online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DASD: to share or not to share

[Walter Marguccio]

>>On Sun, 9 Aug 2009 21:01:42 -0700, Gibney, Dave  wrote:

>> I'm led to understand that our four would LPARs push or exceed GRS ring 
>>performance.

>From: Mark Zelden mark.zel...@zurichna.com

> I can't say I have been in any 4 system GRS ring (using XCF) shops
> in the last 10 years, so perhaps someone with that configuration can share.

we have such configuration. We recently added a 4th LPAR to our existing 
3-LPARs basic sysplex. I had the same concerns as Dave's, but after more than 
one month I can say GRS ring (exploiting XCF) is not a problem.
I use RMF PM to keep on eye on XCF delays, and the average delay GRS shows
is around 4 %.  Which is acceptable to me. We have still a 2086-230, z/OS 1.7
everywhere except z/OS 1.9 on the sandbox LPAR.


Walter Marguccio
z/OS Systems Programmer
BELENUS LOB Informatic GmbH
Munich - Germany 


  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Job Posting

[Eatherly, John D[EQ]]

I am not interested in the referral money.  I just wanted to send it out to get 
it to someone who needs it.

Thanks.


John



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

FW: ZSeries Analyst Perm Opportunity 14607

[Eatherly, John D[EQ]]

In case there is interest...



From: rbr...@tacworldwide.com [mailto:rbr...@tacworldwide.com]
Sent: Tuesday, August 04, 2009 5:41 PM
To: johngalla...@ebby.com
Subject: ZSeries Analyst Perm Opportunity 14607
I realize that this position that this opportunity might not be of interest to 
you and if you are not I was hoping you know some one that might be qualified & 
interested in this opportunity. I've included a brief description below.  
Please feel free to forward this on if you know someone who might be 
interested.  We do offer a referral fee, so if you pass this on, please keep me 
in the loop.

This is a permanent job position in the Central Texas area. This position pays 
$65-75k per year (+ an aggressive yearly bonus) in accordance to the level of 
experience & qualifications of the candidates. This is for one of the largest 
Food Products Distribution Companies in the U.S that serves more than 50,000 
customer locations around the world including the convenience store, drug 
store, mass merchandise, quick service restaurant and movie theater 
industries.recently bought by Warren Buffet making it a wholly owned 
subsidiary of Berkshire Hathaway, The company operates 20 wholesale grocery 
distribution centers, 20 food service restaurant distribution centers, an 
industry-specific software company and an international third party Logistics 
company and employs 15,000 people in the United States.
Below is the job description as given to us by our client:

Install and maintain all software on the Zseries.
Assist applications staff with problem determination and resolution on problems 
or projects.
Assist Operations and Scheduling teams with the day to day operation of the 
zSeries platform and productions install on that platform to allow them to 
perform their required duties.
 Work Experience Required:
Maintaining a zSeries server, applying PTF's, installing new releases of the 
zOS operating systems, tunning the environment.
Maintaining a LPAR environment on the zSeries platform.
Be able to install associated software and work with those products, to include 
like (but not only) RMM, MQ, TMON/MVS/CICS/DB2, INControl and ViewDirect.
Other Qualifications Required:  Be able to work in a team environment, good 
written as well as communication skills.
Other than skill sets, the normal overall requirements apply...stable work 
history, good communication skills, etc...
Perm salary is in the $65-75k base range with a 7.5%-15.5% Bonus.
Excellent Benefits Package that includes VERY STRONG 401k matching program
Full relocation Package
This is a $30+ Billion dollar per year company
Special Note: Cost of living in Central Texas area is about $14-17k less than 
in Dallas, Houston, Austin or most major metropolitan areas.
*** Note: Candidates MUST be U.S. / Canadian Citizen or current Green Card 
Holders***
Ref# 14607

If you know someone that might be qualified & interested in pursuing this 
opportunity, please feel free to send them my information concerning this!!! 
Also, if you feel that your skills & qualifications match up with this job 
description & you would be interested in pursuing it yourself, please email a 
copy of your latest resume to: rbr...@tacworldwide.com & I will give you call.

Sincerely,

Lyle Brown
South Central Recruiting Team Lead

rbr...@tacworldwide.com

Visit us at www.tacworldwide.com



[http://jobs.tacworldwide.com/TAC/private/images/pic_02.gif]
For more than 38 years, professionals have trusted TAC Worldwide to match their 
job skills and deliver opportunities that complement their interests and 
personalities. We provide associates with benefits programs, online technical 
training, career counseling, and on-going HR support. In addition, TAC 
Worldwide communicates with all associates throughout their work assignments 
and strives to find new and interesting opportunities on their behalf.



Note: I chose to contact you because your resume had been posted to one of the 
internet job sites to which we subscribe, or you had previously submitted your 
resume to TAC Worldwide.   If you are not currently seeking employment, or if 
you would prefer I contact you at some later date, please indicate your date of 
availability so that I may honor your request.  We respect your privacy, so if 
you would rather choose to be removed from our mailing list, please use the 
"opt out" link attached.


If you are interested in this position, please click 
here.

If you would like to unsubscribe, please click 
here.



Lookup 
Candidate

Re: DASD: to share or not to share

[Scott Rowe]

As the only Sysprog here (real or otherwise), I understand your time concerns.  
However, in my situation I decided that the benefits outweighed the cost (in 
time).  I find that many of the features of SYSPLEX can save me quite a bit of 
time (once it is set up).  Just the simplicity of having all DASD online to all 
systems can be a benefit.  Of course, YMMV, but I think many small shops decide 
against SYSLEX without ever considering the benefits.
 
I am curious why you still put a $ next to SYSPLEX?

>>> "Gibney, Dave"  8/9/2009 5:39 PM >>>
VSAM (and all SMS datasets) can't exist without being cataloged. Shared
Catalogs are not "safe" without integrity protection. Integrity
protection takes MIM ($) or Sysplex ($) and both require time to
configure and maintain. As the only real z/OS Sysprog here, I'm hard
pressed to keep up as it is, so it's unlikely I'll ever plex and I know
we'll never buy MIM.

I should have been more specific. I only share a limited set of non-SMS
volumes and I do not put VSAM on them. Our CIS guy uses his shared
volumes for some VSAM, but the data is not really shared as the Catalogs
are not shared.

I don't share any SMS pools. If they want Production data for testing,
they have to make a copy (generally using a couple of shared volumes
designated for that specific purpose). Most of the shared datasets are
JCL, PROC, LOAD, ISPxLIB, PARMLIB(s), etc. 

I am fully aware of the risks I'm taking (I think so anyway). 

What I need to do to remain employed here until retirement is learn then
convince the Powers that Be, that zLinux is the best platform for the
Oracle based ERP that's almost inevitable.

> 
> Thanks for you patience in educating this lowly applications
developer.
> 
> Frank
> --
> 
> Frank Swarbrick
> Applications Architect - Mainframe Applications Development
> FirstBank Data Corporation
> Lakewood, CO  USA
> P: 303-235-1403
> F: 303-235-2075
> 
> 
> On 8/9/2009 at 11:45 AM, in message
> , Mark Zelden
>  wrote:
> > If children play with fire, they will eventually get burned!
> >
> >
> > On Sat, 8 Aug 2009 22:42:04 -0600, Frank Swarbrick
> >  wrote:
> >
> >>That is exactly what I did.  Well, "as quickly as I could type", in
any
> case.
> >>We have PDSESHARING(NORMAL) in our IGDSMSxx file, for whatever that
> might
> > be worth.
> >>
> >
> > It's worth nothing in regards to sharing PDSE across sysplex
boundaries
> for
> > anything but READ ONLY functions.
> >
> >>On 8/8/2009 at 1:31 AM, in message
> >>,
> "Gibney,
> >>Dave"  wrote:
> >>> Actually I was speculating about the ability to "refresh" in
memory
> >>> knowledge of the PDSE(s) in the other LPAR(s).
> >
> > There is no command or facility to do that.  There is the sledge
hammer
> > approach of IPLing.   :-)   Well... it may not be all that bad -
more
> below.
> >
> >
> >>> What you describe is not
> >>> guaranteed.
> >>>   Try 1. Run existing copy of the program in LPAR-P. 2. Quickly
update
> >>> it from LPAR-other. 3. Quickly try in LPAR-P. I don't believe you
will
> >>> always get the new version.
> >
> > Apparently he did.  But why?  (more below)
> >
> >>>
>  -Original Message-
>  From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] 
On
>  Behalf Of Frank Swarbrick
>  Sent: Friday, August 07, 2009 1:34 PM
>  To: IBM-MAIN@bama.ua.edu 
>  Subject: Re: DASD: to share or not to share
> 
>  So for example, if our change control process for applications
runs
> in
> >>> DEV
>  (which is how we have it in VSE) we should be able to update our
>  production application loadlib PDSE from DEV exclusively and this
> will
> >>> not
>  be a problem, even without a Sysplex?  I am curious as to where I
> find
>  this PDSE address space refresh command, and if it's really
needed.
> I
>  just compiled a program in to a PDSE in DEV and ran it in PROD
and it
> >>> ran
>  the new version just fine.  Did it twice just to make sure.  No
> >>> problem
>  either time.
> 
> >
> > This probably worked for 2 reasons:
> >
> > 1) Nothing else had the target loadlib allocated and / or opened.
> >
> > 2) PDSE(1)_BUFFER_BEYOND_CLOSE was not set to YES.
> >
> > Try the same test again with the target (output) PDSE loadlib that
is in
> > use by a long running address space, say... a CICS region.  Or how
about
> > a library that happens to be in LLA or the LNKLST.
> >
> > Changes to PDSE data sets in a sysplex are communicated via XCF.
Which
> > means if you don't have a sysplex, you are S.O.L. when it comes to
> sharing
> > PDSEs that need to have changes made (update).
> >
> > I mentioned the sledge hammer approach of IPLing above.   The same
goal
> > can probably be achieved (reading a "fresh copy" of the PDSE) if you
can
> > make sure no address spaces are using the PDSE and you aren't using
the
> > PDSE(1)_BUFFER_BEYOND_CLOSE=YES option. But that could be a
> > really difficult task in a production environment depending on the
> library.
> >
> > Mark
> > -

Re: DASD: to share or not to share

[Mark Zelden]

On Sun, 9 Aug 2009 21:01:42 -0700, Gibney, Dave  wrote:


>
>True, and last time we revamped the IODF I had the required CTC(s)
>added. That was over a year ago when we brought in the z9-BC and is the
>last time I had a chance to take a baby step that direction. Also, on
>this list, I'm led to understand that our four would LPARs push or
>exceed GRS ring performance.
>

Yes, for the "old" GRS ring, 4 systems would probably be a bigger performance
hit than you would ever want.   However, if you set up a basic sysplex, GRS 
performance using XCF is better than dedicated CTC links.  Especially since
you can have FICON CTCs.  Dedicated GRS links (what I referred to as "old"
above) can't get any faster than ESCON in basic mode.  So even XCF links
using ESCON in CTC mode is faster and may give you acceptable performance
with 4 systems.  As usual, YMMV.I can't say I have been in any 4 system
GRS ring (using XCF) shops in the last 10 years, so perhaps someone with
that configuration can share.  I do have plenty of experience with GRS ring
prior to sysplex and I can say that even a 3 system ring presented some 
performance.. um... challenges.  :-)

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[no subject]

[Adams, Tracy]

INFO REFCARD


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z10 performance problem

[Joel Wolpert]

You went from more engines to less engines so you can do less concurrent 
tasks. More info is needed. Does this happen all of the time? Are there 
heavy cpu jobs running at that time? What does RMF Monitor III say as far as 
job delays for the tso users having problems?
- Original Message - 
From: "Tolga" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Monday, August 10, 2009 9:14 AM
Subject: z10 performance problem



Hello,
Last week we upgraded our machine 2084 (8 CPU) to 2097 (5 CPU) Everything
looks ok. but when we try to log on TSO It takes more response seconds 
from

the previous machine
Did anybody faced with this kind of problem ?
thanks / Regards
Tolga

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SIGNOFF IBM-MAIN

[Chokalingam Thangavelu]

Hi,

I do not want receive mails from different consultants. So please block
these mails.

Regards,
Chokalingam Thangavelu
TWUL Mainframe Support
Thames Water IS
In Partnership with Wipro Technologies
Mobile: +91(0)-96864 33224

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Sarath Babu
Sent: Monday, August 10, 2009 12:54 PM
To: IBM-MAIN@bama.ua.edu
Subject: SIGNOFF IBM-MAIN

"SIGNOFF  IBM-MAIN"

 

 

 

 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email. 

www.wipro.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

z10 performance problem

[Tolga]

Hello,
Last week we upgraded our machine 2084 (8 CPU) to 2097 (5 CPU) Everything 
looks ok. but when we try to log on TSO It takes more response seconds from 
the previous machine 
Did anybody faced with this kind of problem ?
thanks / Regards 
Tolga

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DASD: to share or not to share

[Mark Zelden]

On Mon, 10 Aug 2009 13:53:29 +0200, R.S.  wrote:

>Gibney, Dave pisze:
>> VSAM (and all SMS datasets) can't exist without being cataloged.
>
>Well... To be accurate: they cannot be *used* without being cataloged.
>But they can exist.
>
>
>> Shared
>> Catalogs are not "safe" without integrity protection.
>
>Huh? AFAIK It is safe and fully supported to share an UCAT without GRS
>or MIM. That means RESERVEs and can hurt performance, but it is possible
>to safely and effectively share low-used UCAT. BTDT.
>

Somehow I missed commenting on that part in my last response.  Yes,
RESERVE will protect the catalog (but again, not the data sets cataloged in the 
catalog).  From the Managing Catalogs manual:

"CATALOG MANAGEMENT uses the SYSIGGV2 reserve while serializing
access to catalogs. The SYSIGGV2 reserve is used to serialize the entire 
catalog BCS component across all I/O as well as to serialize access to
specific catalog entries. The SYSZVVDS reserve is used to serialize 
access to associated VVDS records. The SYSZVVDS reserve along
with the SYSIGGV2 reserve provide an essential mechanism to facilitate 
cross system sharing of catalogs."

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Convert signed COMP-3 variable into unsigned integer

[Don Leahy]

All you really need is:

MOVE WS-VAR1  TO WS-VAR4

COBOL takes care of unpacking the data, dropping the sign. and
truncating the decimal places.

On Mon, Aug 10, 2009 at 8:40 AM, Gangar, Parin
(MLITS) wrote:
> Hi,
>
> I want to convert S9(13)V99 COMP-3 to simply 9(13).
>
> I declared following in Working Storage section -
>
> 01  WS-VAR1             PIC S9(13)V99  COMP-3.
>
> 01  WS-VAR2             PIC S9(13)V99.
>
> 01  WS-VAR3  redefines  WS-VAR2.
>      05   WS-VAR3-redef           PIC 9(13)V99.
>
> 01  WS-VAR4               PIC 9(13).
>
> I am now doing following in Procedure division -
>
> MOVE WS-VAR1    to      WS-VAR2.
>
> COMPUTE WS-VAR3-REDEF  ROUNDED = WS-VAR3-REDEF.
>
> MOVE  WS-VAR3-REDEF     to WS-VAR4.
>
> Please let me know if the above would work? I don't need the SIGN.
>
> Thanks,
> Parin
>
>
> --
> This message w/attachments (message) may be privileged, confidential or 
> proprietary, and if you are not an intended recipient, please notify the 
> sender, do not use or share it and delete it. Unless specifically indicated, 
> this message is not an offer to sell or a solicitation of any investment 
> products or other financial product or service, an official confirmation of 
> any transaction, or an official statement of Merrill Lynch. Subject to 
> applicable law, Merrill Lynch may monitor, review and retain e-communications 
> (EC) traveling through its networks/systems. The laws of the country of each 
> sender/recipient may impact the handling of EC, and EC may be archived, 
> supervised and produced in countries other than the country in which you are 
> located. This message cannot be guaranteed to be secure or error-free. 
> References to "Merrill Lynch" are references to any company in the Merrill 
> Lynch & Co., Inc. group of companies, which are wholly-owned by Bank of 
> America Corporation. Se!
 curities and Insurance Products: * Are Not FDIC Insured * Are Not Bank 
Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to 
Any Banking Service or Activity * Are Not Insured by Any Federal Government 
Agency. Attachments that are part of this E-communication may have additional 
important disclosures and disclaimers, which you should read. This message is 
subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.
> --
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z10 and overlapping/destructive moves

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Robert A. Rosenberg
> 
> At 17:31 -0400 on 08/07/2009, Bill Fairchild wrote about Re: z10 and
> overlapping/destructive moves:
> 
> >It certainly can't hurt to change the MVI/MVC to a single
instruction:
> >  MVC   254(3,120),=120c' '
> >And, if possible, align the 120c' ' on at least a double word
boundary.
> >
> >Bill Fairchild
> 
> I think that should be MVC   254(120,3),=120c' '
> 
> A MVCL might also do the job (if you have the 4 needed registers
> free) and set the from length and location to 0 with x"20" as the
> fill character.

Probably "better" to use x'40' on an EBCDIC machine  :-)

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z10 and overlapping/destructive moves

[Chase, John]

What's in the other 46 bytes?


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Farley, Peter x23353
> Sent: Friday, August 07, 2009 7:15 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z10 and overlapping/destructive moves
> 
> Indeed, that is what I am doing.  That COBOL MOVE is the first of 56
> bytes highlighted by Strobe.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> > Behalf Of Joel Wolpert
> > Sent: Friday, August 07, 2009 7:00 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: z10 and overlapping/destructive moves
> >
> > Strobe can also be indexed so that it shows the actual COBOL
> statements.
> > This is the most accurate way to use STROBE with COBOL programs.
> >
> > - Original Message -
> > From: "Edward Jaffe" 
> > Newsgroups: bit.listserv.ibm-main
> > To: 
> > Sent: Friday, August 07, 2009 6:46 PM
> > Subject: Re: z10 and overlapping/destructive moves
> >
> > > Farley, Peter x23353 wrote:
> > >> The reason I ask is that Strobe highlights this place in the code
> as a
> > >> high-usage point, and I am struggling to understand why.
> > >
> > > By default, STROBE usually segments your program into (at least)
> 64-byte
> > > "chunks". That's usually quite a few instructions. How exactly do
> you
> > > know the MVC is "slow"? How small is your segment size?
> 
> 
> This message and any attachments are intended only for the use of the
addressee and
> may contain information that is privileged and confidential. If the
reader of the
> message is not the intended recipient or an authorized representative
of the
> intended recipient, you are hereby notified that any dissemination of
this
> communication is strictly prohibited. If you have received this
communication in
> error, please notify us immediately by e-mail and delete the message
and any
> attachments from your system.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Convert signed COMP-3 variable into unsigned integer

[Gangar, Parin (MLITS)]

Hi,

I want to convert S9(13)V99 COMP-3 to simply 9(13). 

I declared following in Working Storage section - 

01  WS-VAR1 PIC S9(13)V99  COMP-3.

01  WS-VAR2 PIC S9(13)V99.

01  WS-VAR3  redefines  WS-VAR2.
  05   WS-VAR3-redef   PIC 9(13)V99.

01  WS-VAR4   PIC 9(13).

I am now doing following in Procedure division - 

MOVE WS-VAR1to  WS-VAR2.

COMPUTE WS-VAR3-REDEF  ROUNDED = WS-VAR3-REDEF.

MOVE  WS-VAR3-REDEF to WS-VAR4.

Please let me know if the above would work? I don't need the SIGN.

Thanks,
Parin


--
This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. 
References to "Merrill Lynch" are references to any company in the Merrill 
Lynch & Co., Inc. group of companies, which are wholly-owned by Bank of America 
Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are 
Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a 
Condition to Any Banking Service or Activity * Are Not Insured by Any Federal 
Government Agency. Attachments that are part of this E-communication may have 
additional important disclosures and disclaimers, which you should read. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.
--
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SIGNOFF IBM-MAIN

[Sarath Babu]

"SIGNOFF  IBM-MAIN"

 

 

 

 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "SIGNOFF IBM-MAIN"

[Sarath Babu]

"SIGNOFF  IBM-MAIN"

Thanks
Sarath Babu
 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DASD: to share or not to share

[R.S.]

Gibney, Dave pisze:
VSAM (and all SMS datasets) can't exist without being cataloged. 


Well... To be accurate: they cannot be *used* without being cataloged. 
But they can exist.




Shared
Catalogs are not "safe" without integrity protection. 


Huh? AFAIK It is safe and fully supported to share an UCAT without GRS 
or MIM. That means RESERVEs and can hurt performance, but it is possible 
to safely and effectively share low-used UCAT. BTDT.


So, it is possible to share volumes, including SMS managed volumes and 
VSAM files. Application files.
I would be very careful when talking about sharing system datasets and 
volumes because the system is the most breaking rules user of the datasets.
Last but not least: sharing datasets doesn't mean that many applications 
can update them concurrently. It can or (more likely) cannot be don even 
within single MVS image.



--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

"SIGNOFF IBM-MAIN"

[Chokalingam Thangavelu]

"SIGNOFF  IBM-MAIN"

Regards,
Chokalingam Thangavelu
TWUL Mainframe Support
Thames Water IS
In Partnership with Wipro Technologies
Mobile: +91(0)-96864 33224



Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email. 

www.wipro.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Loading SMF data into a DB2 database.

[R.S.]

(I couldn't resist)

Yes, it is feasible to load SMF data into a DB2 database. The simplest 
method is to define a table with one column containing whole SMF record, 
regardless of its type. And yes, such approach is completely unreasonable.
However any other approach means that you have to choose what records 
you want in DB2 tables. This is quite complex since even one record type 
can have multiple layouts. A good example is SMF80 - RACF. You can 
contvert it to flat text file (or XML), then you have multiple record 
subtypes, described across 100+ pages in the manual (RACF Macros and 
Interfaces). It is also possible to load the data into DB2 tables. 
Multiple tables.
Regarding to the topic - what would be a reason to have common database 
of all SMF data? I.e. SMF80 and SMF110?
Last but not least: I wonder if any human being is able to understand 
and *remeber* all the SMF record formats.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: VTAM security issue

[Jim Marshall]

>
>I believe Jim Marshall is just trying to dismiss a fact inconvenient for the
>product he is promoting? FUD! See previous comments from the Chris Mason
>
>
I will spare all who have been reading all the history of this on IBMMAIN about 
my strong recommendation for those running SNA networks to strongly 
consider the need for a "SNA Firewall". Native SNA with VTAM no matter how 
it is configured in the eyes of even those who do it well, does not meet US 
Government security mandates. There are all too few people who even 
understand VTAM any more to make a good attempt at it. 

Hopefully those who are skeptical will do independent research, consult with 
really smart people in the know and make a decision as to whether it is wise 
move to bullet proof your SNA network.  I made my replies back in January 
2009 in IBM items 97253 and 97522. No one has contacted me further for 
specific information (which I remember - am a very old guy and maybe it 
slipped by me). My intention was to alert people to the 1+ years of 
investigation, skepticism, and proof others were accessing my SNA network 
and not having a clue how it could be happening. The interconnection of SNA 
networks to a trading partner also means you very, very likely connected to 
their interconnections, etc. I do not have the time and expertise to take up a 
skeptical world to prove this is true. That is why I have sought out very smart 
people who specialize in areas. Google can be a great starter using "SNA 
FIREWALL APPN" and one should never take the word of someone on IBMMAIN 
without doing their homework. 

I do very much agree with agree I am indeed spreading FUD, as stated in 
January.  Oh yes, most people on IBMMAIN take great pains not to promote 
products and to inspire our younger brethren to do their own research.   

F - Fear and indeed there is, AND STILL SHOULD BE IN THE FUTURE
U - Uncertainty no more 
D - Doubt is doubt no more ALTHOUGH WILL LINGER WITH MANY forever

Your mileage may vary.jim 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: VTAM security issue

[Anne & Lynn Wheeler]

patrick.oke...@wamu.net (Patrick O'Keefe) writes:
> Well, the N is "Network", not "Networking", but I don't think that 
> clarifies anything.   Lynn apparently has some very specific defibition
> of "Networking" in mind.   His comment may be accurate (His comments 
> usually are.) but I'm not sure what that comment really was.
>
> SNA does not have a universal addressing scheme and IP does.
> Perhaps that was the point.  But SNI provided that in sort of the 
> same way that NATing allows interconnection of 2 IP networks that
> use private IP addresses.
>
> SNA does not provide a universal name space for resources, but 
> neither does IP.   The Domain Name space used by IP hosts is
> not provided by, or dependent on IP.

re:
http://www.garlic.com/~lynn/2009l.html#3 VTAM security issue

it was the communication division ... not the networking division.

vtam/ncp (pu5/pu4) formed part of a communication hierarchy.

networking has tended to apply to talking to other peers ... it was the
source of my comment that only in situation where "network" had been
co-opt to apply to communication hierarchy that it was necessary to
qualify AWP39 networking architecture by "peer-to-peer networking
architecture".

arpanet ... prior to great converstion to tcp/ip on 1jan83 ... had hosts
and network nodes (IMPS). The IMPS talked to other IMPS (network nodes)
... and they talked to attached devices (which happened to be hosts,
later there were also "terminal" IMPS). IMPS (network nodes) exchanged
information about what other IMPS (network nodes) they were connected to
... so it was possible to dynamically discover network nodes and paths
to network nodes and paths to connected devices/hosts.

The IMPS/host configuration had some physical similarity to pu4/pu5
... but the IMPS were full network nodes that managed the dynamic
network configuration and then forwarded communication to/from
destination hosts. At the time of the great change over ... there was
something like 100 IMPS (network nodes) and 255 (connected) HOSTs.

TCP/IP has both a network layer and an internetworking layer (gateways
and other conventions for supporting the internetworking of networks).
At the TCP/IP network layer there is ARP (address resolution protocol)
and ARP caches (dynamic maps of IP-addresses to "data link" ... if using
the OSI madel), as well as some maintenance/control gorp with ICMP
messages (redirects, not reachable, etc). These are networking
layer/node to networking layer/node

The great change-over to TCP/IP effectively merged the IMP function into
the hosts ... with hosts executing networking layer code and higher
layer code. It was possible to do (dynamic, networking layer) router
function in the hosts and/or custom "router" boxes. The "router" boxes
could also provide the gateway/internetworking function for
internetworking of networks.

the internal network ... some past posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

originated at the science center (virtual machines, lots of interactive
computing, GML ... precursor to SGML, HTML, etc, lots of other stuff)
... some past posts mentioning science center
http://www.garlic.com/~lynn/subtopic.html#545tech

I've claimed that one of the reasons that the internal network (not SNA)
was larger than the arpanet/internet from just about the beginning until
sometime late 85 (or early 86) was that the prevailing internal
networking nodes contained a form of gateway function (significantly
easing the addition of nodes in different parts of the network)
... which arpanet/internet didn't get until the 1jan83 great
change-over.

We were in a booth at interop88 ... but not the ibm booth ... and
starting late sunday night before the start of the show ... the (four)
floor nets started crashing ... this continued into the wee hours of
monday morning before being diagnosed and corrected. The problem was
that a large number of nodes (lots & lots of workstations) had
connections to all four floor nets ... and all had "ip-forwarding"
turned on by default (router function). Any ARP request was
automagically being rebroadcast by nearly all nodes on all networks
... which led to ARP storms. In the wake of interop88 ... RFC1122 (IETF
internet standard) specified that IP-forwarding should be turned off by
default.

my internet standard index
http://www.garlic.com/~lynn/rfcietff.htm

summary entry for 1122

http://www.garlic.com/~lynn/rfcidx3.htm#1122
1122  S

Requirements for Internet hosts - communication layers, Braden R.,
1989/10/01 (116pp) (.txt=289148) (STD-3) (Updated by 4379) (See Also
1123)

 

misc. past posts mentioning interop88
http://www.garlic.com/~lynn/subnetwork.html#interop88

TCP/IP is the technology basis for the modern internet, NSFNET backbone
was the operational basis for the modern internet, and CIX was the
business basis for the modern internet. some number of past posts
mentioning NSFNET backbone
http://www.garlic.com/~lynn/subnetwork.html#ns

Re: Trigger CICS transaction from Batch Job

[Jan MOEYERSONS]

On Fri, 7 Aug 2009 08:01:34 -0500, McKown, John 
 wrote:

>
>What he needs to do is use REXX sockets to write a z/OS TN3270 client. 
>This client could then connect as a 3270 terminal to the CICS region and 


But instead of connecting to a 3270 terminal, the connection should be made 
to the CICS listener CSKL. Works like a charm. With security if you need it and 
no sweat exchanging information back and forth between the batch program 
and the CICS transaction.

Cheers,

Jantje.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Loading SMF data into a DB2 database.

[Erik Janssen]

Hello Mike,

I've tried it a couple of years ago with MXG/SAS. I think that was quite easy 
to do if I recall, but the problem I had was with time fields in SAS exceeding 
24 hours (ie a job/stc that ran more than a day). SAS is ok with that, but it 
converted those fields to a DB2 time column which doesn't accept times 
greater than 24 hours. Perhaps more recent releases of DB2 / SAS have a 
solution for that. If you have SAS (and MXG) available I think (not sure 
though) it was as easy as setting a 'libname PDB DB2 SSID= 
AUTHID=xxx;' and SAS will create the tables if you have the proper 
authorization. 

Regards,

Erik Janssen.

On Thu, 6 Aug 2009 11:44:47 -0500, Michael Wickman 
 wrote:

>Does anyone try to load SMF records into a database (DB2) for
>performance and capacity usage data mining?  Just trying from keep from
>re-typing all the DB2 definitions if somebody has already done it or
>have any suggestions along that line.  Thanks.
>
>
>Mike Wickman
>
>
>
>
>
>
>
>
>"This email is intended to be reviewed by only the intended recipient
> and may contain information that is privileged and/or confidential.
> If you are not the intended recipient, you are hereby notified that
> any review, use, dissemination, disclosure or copying of this email
> and its attachments, if any, is strictly prohibited.  If you have
> received this email in error, please immediately notify the sender by
> return email and delete this email from your system."
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html