Re: IBM getting out of the Ed business?

2013-07-20 Thread Ed Jaffe 

On 7/20/2013 9:26 PM, Ed Gould wrote:

Big Blue cedes software and systems training biz to partners
>http://www.channelregister.co.uk/2013/07/16/ibm_software_systems_training_channel/< 



*IF* this is true... is Z/os may not be far behind.


Why? What's the connection?

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

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

Re: DCOLLECT QUESTION -RESULTS PUZZLING -

2013-07-20 Thread Lizette Koehler 
If you go to CBTTAPE.ORG and go for FILE206, it seems to have a REXX parser
for DCOLLECT records

/*TOTAL FROM D, M AND B RECORDS:  */
/*   L0+ML1+ML2 DSN COUNT */
/*   TOTAL L0 + ML1 +ML2 ALLOCATED*/
/*   TOTAL BACKUP KBYTES  */
/*   L0 DSN COUNT */
/*   L0 ALLOCATED KBYTES  */
/*   L0 USED KBYTES   */
/*   SMS DSN COUNT*/
/*   SMS ALLOCATED KBYTES */
/*   ML1 DSN COUNT*/
/*   ML1 ALLOCATED KBYTES */
/*   ML1 ORIGINAL KBYTES  */
/*   ML2 DSN COUNT*/
/*   ML2 ALLOCATED KBYTES */
/*   ML2 ORIGINAL KBYTES  */
/*

This may do what you want.  It takes a DCOLLECT input file and creates a
report.  I have not tried it yet, but this maybe helpful.

Lizette



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Saturday, July 20, 2013 1:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

I ran this process and received data in the DATASET.REPORT file.  But it was
only for ONLINE dasd.  This is expected.

Your messages indicate the process ran.  Most likely no data to format.

Please run a FULL DCOLLECT for all record types then try this process again.

Remember my comment:  ACBQBAR7 does not get MIGRATED data.  Only ONLINE
data.  It only parses D records not M records.

To test this I have a full DCOLLECT dataset.  Has all of the Migrated, Capd,
vols, etc. when it was run.  I run the ACBQBAR7 against that file and only
ONLINE datasets were in the list.  If it was migrated or tape it was not in
the list.

Does that help?

Lizette



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Saturday, July 20, 2013 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lisa,
 
Just to let you know that I was able to get the dsn list with the job
(examples in the z/OS V1R12.0 DFSMSdfp Storage Administration
SC26-7402-14  pages 382 &383) however for some reason it does not list any
of the MIGRATED dsns.  I tried another test just to select MIGRATEDATA there
are no dsns listed.  David spotted my error but I couldn't find it where it
is.  Hopefully he will see this post and let me know where it is.  



From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, July 20, 2013 10:38:12 AM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


According to the Naviquest manual: 


ACBQBAR7 is called by SYS1.SACBCNTL member ACBJBARD to generate a flat file
from DCOLLECT data taken from data set records and lists the fields of your
choice, in the order you specify.

Does not appear to handle Migrated data.

So, you could run a plain dcollect as I described, or review the Naviquest
manual (you can find them on the IBM.COM website)

http://www.redbooks.ibm.com/abstracts/sg244720.html
http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.
zos.r11.idas200/naviquest.htm


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Saturday, July 20, 2013 6:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lizette,
 
Here is what I had said earlier (see below).  I cannot figure out why the 
output dsn   SYS2.DATASET.REPORT does not show is that dsn list but only
system stats.  David Devine said that "The problem is that you want to get a
report on M type (migration) dcollect records and the job deck you are
running will only select D type dataset records."  I cannot seem to find
where the M type records are being selected in the job deck.  This is where
my problem is.


 
Next I ran the following job  (I took this from the IBM manual z/OS V1R12.0
DFSMSdfp Storage Administration SC26-7402-14) : 
 
//GENREP   EXEC  ACBJBAOB,

//    PLIB1=SYS1.DGTPLIB, 

//    TABL2=SYS2.TEST.ISPTABL 

//DCOLIN  DD  DSN=SYS2.DCOLLECT.DATA1,DISP=SHR

//ISPFILE DD  DSN=SYS2.DATASET.REPORT,DISP=OLD 

//SYSTSIN  DD *

PROFILE PREFIX(ZWA6PWG) 

ISPSTART CMD(ACBQBAR7) +
BATSCRW(132) BATSCRD(27) BREDIMAX(3) BDISPMAX() 

//SYSIN DD  *

DSN VOLSER ALLOCSP RECFM TITLE=DATA SET REPORT FROM DCOLLECT DATA -
17/07/2013 TOTALS BLKSIZE DSORG MGMTCLAS STORGRP
/*

IBM getting out of the Ed business?

2013-07-20 Thread Ed Gould 

Big Blue cedes software and systems training biz to partners
>http://www.channelregister.co.uk/2013/07/16/ 
ibm_software_systems_training_channel/<


*IF* this is true... is Z/os may not be far behind.

Ed

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

Re: Default

2013-07-20 Thread Paul Gilmartin 
On Sat, 20 Jul 2013 22:33:38 -0400, Shmuel Metz (Seymour J.)  wrote:
>
>on 07/19/2013 at 09:58 AM, Ron Wells said:
>
>>is there some thing on Windows that would strip the CRLF off??
>
>Why would you want to? If your data are not text then you should be
>transmitting them as binary.
> 
The OP never really made his requirement clear: whether he's
getting CRLF and prefers not to have it, or lacking CRLF and
prefers to have it.

-- gil

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

Re: Default

2013-07-20 Thread Shmuel Metz (Seymour J.) 
In
,
on 07/19/2013
   at 09:58 AM, Ron Wells  said:

>is there some thing on Windows that would strip the CRLF off??

Why would you want to? If your data are not text then you should be
transmitting them as binary.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Default

2013-07-20 Thread Shmuel Metz (Seymour J.) 
In
<985915eee6984740ae93f8495c624c6c2319c1e...@jscpcwexmaa1.bsg.ad.adp.com>,
on 07/19/2013
   at 11:19 AM, "Farley, Peter x23353" 
said:

>If Ron's question is your second one, there is dos2unix:

Wouldn't that change CRLF to LF rather than deleting it entirely?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL was: COBOL Parser

2013-07-20 Thread Shmuel Metz (Seymour J.) 
In <4983992839630034.wa.paulgboulderaim@listserv.ua.edu>, on
07/19/2013
   at 09:15 AM, Paul Gilmartin  said:

>Mathematical/scientific notation tends to use single-character 
>identifiers, to be case-sensitive, and to admit characters from 
>Greek, Hebrew, ...

Also. face and font are typically significant.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [MVS-OE] Looking for help with an obscure C integer problem

2013-07-20 Thread David Crayford 
I don't like it because it's a hack to work around an puzzling  issue. I 
want to know why the optimizer is not generating the correct code. It's 
disconcerting and I've experienced it myself,
but only in situations where the code was convoluted (double pointers 
and casts). I ended up rewriting that code! The optimizer takes no 
prisoners. In my experience it finds bugs.


On 21/07/2013 9:24 AM, Charles Mills wrote:

Okay. What do you think of the union approach?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

Your casting a uint64_t to a uint64_t which is pointless. You should cast to
the return value (uint32_t).

I've just tried your example and I can't recreate the problem, with or
without casts and compiled with both OPT and NOOPT.

#include 
#include 
#include 
#include 

int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n >> 32;
uint32_t c = static_cast(n >> 32);
printf( "%08X %08X\n", b, c );
}

I can only assume that the optimizer is throwing away valueToTest for some
arcane reason. I've seen this happen with convoluted code with lots of
pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable optimizations
on that variable.

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


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

Re: [MVS-OE] Looking for help with an obscure C integer problem

2013-07-20 Thread Charles Mills 
Okay. What do you think of the union approach?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

Your casting a uint64_t to a uint64_t which is pointless. You should cast to
the return value (uint32_t).

I've just tried your example and I can't recreate the problem, with or
without casts and compiled with both OPT and NOOPT.

#include 
#include 
#include 
#include 

int main( int argc, char **argv )
{
   uint64_t n = 0x0034LLU;
   uint32_t b = n >> 32;
   uint32_t c = static_cast(n >> 32);
   printf( "%08X %08X\n", b, c );
}

I can only assume that the optimizer is throwing away valueToTest for some
arcane reason. I've seen this happen with convoluted code with lots of
pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable optimizations
on that variable.

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

OT - HP plans to close the book on OpenVMS in 2020

2013-07-20 Thread Ed Gould 
http://www.computerworld.com/s/article/9240729/ 
HP_plans_to_close_the_book_on_OpenVMS_in_2020



Hope IBM doesn't do the same to Z/os

Ed

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

Re: [MVS-OE] Looking for help with an obscure C integer problem

2013-07-20 Thread David Crayford 
Your casting a uint64_t to a uint64_t which is pointless. You should 
cast to the return value (uint32_t).


I've just tried your example and I can't recreate the problem, with or 
without casts and compiled with both OPT and NOOPT.


#include 
#include 
#include 
#include 

int main( int argc, char **argv )
{
  uint64_t n = 0x0034LLU;
  uint32_t b = n >> 32;
  uint32_t c = static_cast(n >> 32);
  printf( "%08X %08X\n", b, c );
}

I can only assume that the optimizer is throwing away valueToTest for 
some arcane reason. I've seen this happen with convoluted code with lots 
of pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable 
optimizations on that variable.


On 21/07/2013 8:27 AM, Charles Mills wrote:

Hmmm. Not following your logic but I may give it a try.

Charles

-Original Message-
From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
Crayford
Sent: Saturday, July 20, 2013 4:51 PM
To: mvs...@vm.marist.edu
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

If static_cast(valueToTest >> 32) doesn't fix it then the compiler
is broken. Note the cast to uint32_t not uint64_t.

On 21/07/2013, at 6:36 AM, Charles Mills  wrote:


Thanks. How would I solve this with a cast? I can force it to be wrong
LOL but can I force it to be right?

It seems to me like testWord = static_cast(valueToTest

32) might not solve the problem because that cast seems to me to
imply

that the expression inside the parentheses is *not* 64 bits.

Frankly, I am now leaning toward

union {
unsigned long long ll;
struct {unsigned int hi; unsigned int lo} s; } u;

u.ll = valueToTest;

and then using u.s.hi where I now use testWord.

I generally avoid unions because they can be a tad problematic. I
think the above actually violates the C standard which says you can't
assign to member x and then read member y (which pretty much negates
the whole purpose of unions other than, as Stroustrup suggests, saving

space in memory).

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

As a general ROT I always use explicit casts.

On 21/07/2013, at 4:24 AM, Charles Mills  wrote:


Cross-posted to IBM-MAIN and MVS-OE.

I have the following code fragment in an inline function, compiled by
the IBM XLC compiler as C++:

unsigned long long valueToTest;
unsigned int testWord;
testWord = valueToTest >> 32;

It *appears* to me (from somewhat circumstantial evidence in a much
more complex big picture) when valueToTest has a value of
0x0034 then

- If I compile Opt(0),NoInline then testWord gets the value I expect,
0x0034; but
- If I compile Opt(2),Inline then testWord gets a value of 0.

Questions:

1. Does that seem plausible? That the code would work as intended
Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
guessing here) first cast valueToTest to an int of 0, then shift it
right 32, and then assign it to testWord?

2. What should I code to avoid that? I guess I could shift
valueToTest first (I don't need it again) and then in a separate
statement assign it to testWord. Is that the "proper" coding technique?

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


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

Re: [MVS-OE] Looking for help with an obscure C integer problem

2013-07-20 Thread Charles Mills 
Hmmm. Not following your logic but I may give it a try.

Charles

-Original Message-
From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
Crayford
Sent: Saturday, July 20, 2013 4:51 PM
To: mvs...@vm.marist.edu
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

If static_cast(valueToTest >> 32) doesn't fix it then the compiler
is broken. Note the cast to uint32_t not uint64_t. 

On 21/07/2013, at 6:36 AM, Charles Mills  wrote:

> Thanks. How would I solve this with a cast? I can force it to be wrong 
> LOL but can I force it to be right?
> 
> It seems to me like testWord = static_cast long>(valueToTest
>>> 32) might not solve the problem because that cast seems to me to 
>>> imply
> that the expression inside the parentheses is *not* 64 bits.
> 
> Frankly, I am now leaning toward
> 
> union {
> unsigned long long ll;
> struct {unsigned int hi; unsigned int lo} s; } u;
> 
> u.ll = valueToTest;
> 
> and then using u.s.hi where I now use testWord.
> 
> I generally avoid unions because they can be a tad problematic. I 
> think the above actually violates the C standard which says you can't 
> assign to member x and then read member y (which pretty much negates 
> the whole purpose of unions other than, as Stroustrup suggests, saving
space in memory).
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of David Crayford
> Sent: Saturday, July 20, 2013 2:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Looking for help with an obscure C integer problem
> 
> As a general ROT I always use explicit casts.
> 
> On 21/07/2013, at 4:24 AM, Charles Mills  wrote:
> 
>> Cross-posted to IBM-MAIN and MVS-OE.
>> 
>> I have the following code fragment in an inline function, compiled by 
>> the IBM XLC compiler as C++:
>> 
>> unsigned long long valueToTest;
>> unsigned int testWord;
>> testWord = valueToTest >> 32;
>> 
>> It *appears* to me (from somewhat circumstantial evidence in a much 
>> more complex big picture) when valueToTest has a value of
>> 0x0034 then
>> 
>> - If I compile Opt(0),NoInline then testWord gets the value I expect, 
>> 0x0034; but
>> - If I compile Opt(2),Inline then testWord gets a value of 0.
>> 
>> Questions:
>> 
>> 1. Does that seem plausible? That the code would work as intended 
>> Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am 
>> guessing here) first cast valueToTest to an int of 0, then shift it 
>> right 32, and then assign it to testWord?
>> 
>> 2. What should I code to avoid that? I guess I could shift 
>> valueToTest first (I don't need it again) and then in a separate 
>> statement assign it to testWord. Is that the "proper" coding technique?

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

Re: Looking for help with an obscure C integer problem

2013-07-20 Thread Charles Mills 
Thanks. How would I solve this with a cast? I can force it to be wrong LOL
but can I force it to be right?

It seems to me like testWord = static_cast(valueToTest
>> 32) might not solve the problem because that cast seems to me to imply
that the expression inside the parentheses is *not* 64 bits.

Frankly, I am now leaning toward

union {
unsigned long long ll;
struct {unsigned int hi; unsigned int lo} s; } u;

u.ll = valueToTest;

and then using u.s.hi where I now use testWord.

I generally avoid unions because they can be a tad problematic. I think the
above actually violates the C standard which says you can't assign to member
x and then read member y (which pretty much negates the whole purpose of
unions other than, as Stroustrup suggests, saving space in memory). 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

As a general ROT I always use explicit casts.

On 21/07/2013, at 4:24 AM, Charles Mills  wrote:

> Cross-posted to IBM-MAIN and MVS-OE.
> 
> I have the following code fragment in an inline function, compiled by 
> the IBM XLC compiler as C++:
> 
> unsigned long long valueToTest;
> unsigned int testWord;
> testWord = valueToTest >> 32;
> 
> It *appears* to me (from somewhat circumstantial evidence in a much 
> more complex big picture) when valueToTest has a value of 
> 0x0034 then
> 
> - If I compile Opt(0),NoInline then testWord gets the value I expect, 
> 0x0034; but
> - If I compile Opt(2),Inline then testWord gets a value of 0.
> 
> Questions: 
> 
> 1. Does that seem plausible? That the code would work as intended 
> Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am 
> guessing here) first cast valueToTest to an int of 0, then shift it 
> right 32, and then assign it to testWord?
> 
> 2. What should I code to avoid that? I guess I could shift valueToTest 
> first (I don't need it again) and then in a separate statement assign 
> it to testWord. Is that the "proper" coding technique?
> 
> It's fairly involved to test the whole thing so I took the liberty of 
> imposing on you folks rather than just trying stuff. Thanks much.
> 
> Charles
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Looking for help with an obscure C integer problem

2013-07-20 Thread David Crayford 
As a general ROT I always use explicit casts.

On 21/07/2013, at 4:24 AM, Charles Mills  wrote:

> Cross-posted to IBM-MAIN and MVS-OE.
> 
> I have the following code fragment in an inline function, compiled by the
> IBM XLC compiler as C++:
> 
> unsigned long long valueToTest;
> unsigned int testWord;
> testWord = valueToTest >> 32;
> 
> It *appears* to me (from somewhat circumstantial evidence in a much more
> complex big picture) when valueToTest has a value of 0x0034 then
> 
> - If I compile Opt(0),NoInline then testWord gets the value I expect,
> 0x0034; but
> - If I compile Opt(2),Inline then testWord gets a value of 0.
> 
> Questions: 
> 
> 1. Does that seem plausible? That the code would work as intended
> Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
> guessing here) first cast valueToTest to an int of 0, then shift it right
> 32, and then assign it to testWord?
> 
> 2. What should I code to avoid that? I guess I could shift valueToTest first
> (I don't need it again) and then in a separate statement assign it to
> testWord. Is that the "proper" coding technique?
> 
> It's fairly involved to test the whole thing so I took the liberty of
> imposing on you folks rather than just trying stuff. Thanks much.
> 
> Charles 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Looking for help with an obscure C integer problem

2013-07-20 Thread Charles Mills 
Cross-posted to IBM-MAIN and MVS-OE.

I have the following code fragment in an inline function, compiled by the
IBM XLC compiler as C++:

unsigned long long valueToTest;
unsigned int testWord;
testWord = valueToTest >> 32;

It *appears* to me (from somewhat circumstantial evidence in a much more
complex big picture) when valueToTest has a value of 0x0034 then

- If I compile Opt(0),NoInline then testWord gets the value I expect,
0x0034; but
- If I compile Opt(2),Inline then testWord gets a value of 0.

Questions: 

1. Does that seem plausible? That the code would work as intended
Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
guessing here) first cast valueToTest to an int of 0, then shift it right
32, and then assign it to testWord?

2. What should I code to avoid that? I guess I could shift valueToTest first
(I don't need it again) and then in a separate statement assign it to
testWord. Is that the "proper" coding technique?

It's fairly involved to test the whole thing so I took the liberty of
imposing on you folks rather than just trying stuff. Thanks much.

Charles 

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

Re: DCOLLECT QUESTION -RESULTS PUZZLING -

2013-07-20 Thread Lizette Koehler 
I ran this process and received data in the DATASET.REPORT file.  But it was
only for ONLINE dasd.  This is expected.

Your messages indicate the process ran.  Most likely no data to format.

Please run a FULL DCOLLECT for all record types then try this process again.

Remember my comment:  ACBQBAR7 does not get MIGRATED data.  Only ONLINE
data.  It only parses D records not M records.

To test this I have a full DCOLLECT dataset.  Has all of the Migrated, Capd,
vols, etc. when it was run.  I run the ACBQBAR7 against that file and only
ONLINE datasets were in the list.  If it was migrated or tape it was not in
the list.

Does that help?

Lizette



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Saturday, July 20, 2013 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lisa,
 
Just to let you know that I was able to get the dsn list with the job
(examples in the z/OS V1R12.0 DFSMSdfp Storage Administration   
SC26-7402-14  pages 382 &383) however for some reason it does not list any
of the MIGRATED dsns.  I tried another test just to select MIGRATEDATA there
are no dsns listed.  David spotted my error but I couldn't find it where it
is.  Hopefully he will see this post and let me know where it is.  



From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Saturday, July 20, 2013 10:38:12 AM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


According to the Naviquest manual: 


ACBQBAR7 is called by SYS1.SACBCNTL member ACBJBARD to generate a flat file
from DCOLLECT data taken from data set records and lists the fields of your
choice, in the order you specify.

Does not appear to handle Migrated data.

So, you could run a plain dcollect as I described, or review the Naviquest
manual (you can find them on the IBM.COM website)

http://www.redbooks.ibm.com/abstracts/sg244720.html
http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.
zos.r11.idas200/naviquest.htm


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Saturday, July 20, 2013 6:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lizette,
 
Here is what I had said earlier (see below).  I cannot figure out why the 
output dsn   SYS2.DATASET.REPORT does not show is that dsn list but only
system stats.  David Devine said that "The problem is that you want to get a
report on M type (migration) dcollect records and the job deck you are
running will only select D type dataset records."  I cannot seem to find
where the M type records are being selected in the job deck.  This is where
my problem is.


 
Next I ran the following job  (I took this from the IBM manual z/OS V1R12.0
DFSMSdfp Storage Administration SC26-7402-14) : 
 
//GENREP   EXEC  ACBJBAOB,

//    PLIB1=SYS1.DGTPLIB, 

//    TABL2=SYS2.TEST.ISPTABL 

//DCOLIN  DD  DSN=SYS2.DCOLLECT.DATA1,DISP=SHR

//ISPFILE DD  DSN=SYS2.DATASET.REPORT,DISP=OLD 

//SYSTSIN  DD *

PROFILE PREFIX(ZWA6PWG) 

ISPSTART CMD(ACBQBAR7) +
BATSCRW(132) BATSCRD(27) BREDIMAX(3) BDISPMAX() 

//SYSIN DD  *

DSN VOLSER ALLOCSP RECFM TITLE=DATA SET REPORT FROM DCOLLECT DATA -
17/07/2013 TOTALS BLKSIZE DSORG MGMTCLAS STORGRP
/*
However, when I check the output dsn   SYS2.DATASET.REPORT this is what I
find and I cannot understand why. 

READY PROFILE PREFIX(ZWA6PWG) 

READY ISPSTART CMD(ACBQBAR7)  BATSCRW(132) BATSCRD(27) BREDIMAX(3)
BDISPMAX() 

Number 1 parameter was: DSN 

Number 2 parameter was: VOLSER 

Number 3 parameter was: ALLOCSP

Number 4 parameter was: RECFM 

Number 5 parameter was: TITLE 

Number 6 parameter was: TOTALS 

Number 7 parameter was: BLKSIZE 

Number 8 parameter was: DSORG 

Number 9 parameter was: MGMTCLAS 

Number 10 parameter was: STORGRP

  Time    *** ISPF transaction log ***  
Us  Userid: ZWA6PWG    Date: 13/07/19   Page: 1  


  08:41   Start of ISPF Log - - -  - Session # 1
---
  08:41  TSO - Command  -  - ACBQBAR7
  08:54    End of ISPF Log - - - - - Session # 1
-
 




From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, July 19, 2013 1:25:08 PM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


Then I would run DCOLLECT with all the parms (MIGD, CAPD VOL(*) etc...) and
then check SYSPRINT and see what records are being produced.  There is a
summary at the end of the message indicating how many of each record is
found.

For example

IDC01811I NUMBER OF 'D ' RECORDS PROCESSED WAS 442789            
IDC01811I NUMBER OF 'A ' RECORDS PROCESSED WAS 378331            
IDC01811I NUMBER OF 'V ' RECORDS PROCESSED WAS 1333 

Re: DCOLLECT QUESTION -RESULTS PUZZLING -

2013-07-20 Thread esmie moo 
Lizette,
 
Sorry I addressed you as Lisa.  My apologies.



From: esmie moo 
To: IBM Mainframe Discussion List  
Sent: Saturday, July 20, 2013 2:03:09 PM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -



Lisa,
 
Just to let you know that I was able to get the dsn list with the job (examples 
in the z/OS V1R12.0 DFSMSdfp Storage Administration    SC26-7402-14  
pages 382 &383) however for some reason it does not list any of the MIGRATED 
dsns.  I tried another test just to select MIGRATEDATA there are no dsns 
listed.  David spotted my error but I couldn't find it where it is.  Hopefully 
he will see this post and let me know where it is.  



From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Saturday, July 20, 2013 10:38:12 AM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


According to the Naviquest manual: 


ACBQBAR7 is called by SYS1.SACBCNTL member ACBJBARD to generate a flat file
from DCOLLECT data taken from data set records and lists the fields of your
choice, in the order you specify.

Does not appear to handle Migrated data.

So, you could run a plain dcollect as I described, or review the Naviquest
manual (you can find them on the IBM.COM website)

http://www.redbooks.ibm.com/abstracts/sg244720.html
http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.
zos.r11.idas200/naviquest.htm


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Saturday, July 20, 2013 6:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lizette,
 
Here is what I had said earlier (see below).  I cannot figure out why the 
output dsn   SYS2.DATASET.REPORT does not show is that dsn list but only
system stats.  David Devine said that "The problem is that you want to get a
report on M type (migration) dcollect records and the job deck you are
running will only select D type dataset records."  I cannot seem to find
where the M type records are being selected in the job deck.  This is where
my problem is.


 
Next I ran the following job  (I took this from the IBM manual z/OS V1R12.0
DFSMSdfp Storage Administration SC26-7402-14) : 
 
//GENREP   EXEC  ACBJBAOB,

//    PLIB1=SYS1.DGTPLIB, 

//    TABL2=SYS2.TEST.ISPTABL 

//DCOLIN  DD  DSN=SYS2.DCOLLECT.DATA1,DISP=SHR

//ISPFILE DD  DSN=SYS2.DATASET.REPORT,DISP=OLD 

//SYSTSIN  DD *

PROFILE PREFIX(ZWA6PWG) 

ISPSTART CMD(ACBQBAR7) +
BATSCRW(132) BATSCRD(27) BREDIMAX(3) BDISPMAX() 

//SYSIN DD  *

DSN VOLSER ALLOCSP RECFM TITLE=DATA SET REPORT FROM DCOLLECT DATA -
17/07/2013 TOTALS BLKSIZE DSORG MGMTCLAS STORGRP
/*
However, when I check the output dsn   SYS2.DATASET.REPORT this is what I
find and I cannot understand why. 

READY PROFILE PREFIX(ZWA6PWG) 

READY ISPSTART CMD(ACBQBAR7)  BATSCRW(132) BATSCRD(27) BREDIMAX(3)
BDISPMAX() 

Number 1 parameter was: DSN 

Number 2 parameter was: VOLSER 

Number 3 parameter was: ALLOCSP

Number 4 parameter was: RECFM 

Number 5 parameter was: TITLE 

Number 6 parameter was: TOTALS 

Number 7 parameter was: BLKSIZE 

Number 8 parameter was: DSORG 

Number 9 parameter was: MGMTCLAS 

Number 10 parameter was: STORGRP

  Time    *** ISPF transaction log ***  
Us  Userid: ZWA6PWG    Date: 13/07/19   Page: 1  


  08:41   Start of ISPF Log - - -  - Session # 1
---
  08:41  TSO - Command  -  - ACBQBAR7
  08:54    End of ISPF Log - - - - - Session # 1
-
 




From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, July 19, 2013 1:25:08 PM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


Then I would run DCOLLECT with all the parms (MIGD, CAPD VOL(*) etc...) and
then check SYSPRINT and see what records are being produced.  There is a
summary at the end of the message indicating how many of each record is
found.

For example

IDC01811I NUMBER OF 'D ' RECORDS PROCESSED WAS 442789            
IDC01811I NUMBER OF 'A ' RECORDS PROCESSED WAS 378331            
IDC01811I NUMBER OF 'V ' RECORDS PROCESSED WAS 1333              
IDC01811I NUMBER OF 'M ' RECORDS PROCESSED WAS 38429              
IDC01811I NUMBER OF 'B ' RECORDS PROCESSED WAS 61141              
IDC01811I NUMBER OF 'C ' RECORDS PROCESSED WAS 3405              
IDC01811I NUMBER OF 'T ' RECORDS PROCESSED WAS 3                  

It helps us that you try things and provide details back.  Each shop is
unique and we need to see the details in order to help.


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Friday, July 19, 2013 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZ

Re: DCOLLECT QUESTION -RESULTS PUZZLING -

2013-07-20 Thread esmie moo 
Lisa,
 
Just to let you know that I was able to get the dsn list with the job (examples 
in the z/OS V1R12.0 DFSMSdfp Storage Administration    SC26-7402-14  
pages 382 &383) however for some reason it does not list any of the MIGRATED 
dsns.  I tried another test just to select MIGRATEDATA there are no dsns 
listed.  David spotted my error but I couldn't find it where it is.  Hopefully 
he will see this post and let me know where it is.  



From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Saturday, July 20, 2013 10:38:12 AM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


According to the Naviquest manual: 


ACBQBAR7 is called by SYS1.SACBCNTL member ACBJBARD to generate a flat file
from DCOLLECT data taken from data set records and lists the fields of your
choice, in the order you specify.

Does not appear to handle Migrated data.

So, you could run a plain dcollect as I described, or review the Naviquest
manual (you can find them on the IBM.COM website)

http://www.redbooks.ibm.com/abstracts/sg244720.html
http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.
zos.r11.idas200/naviquest.htm


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Saturday, July 20, 2013 6:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lizette,
 
Here is what I had said earlier (see below).  I cannot figure out why the 
output dsn   SYS2.DATASET.REPORT does not show is that dsn list but only
system stats.  David Devine said that "The problem is that you want to get a
report on M type (migration) dcollect records and the job deck you are
running will only select D type dataset records."  I cannot seem to find
where the M type records are being selected in the job deck.  This is where
my problem is.


 
Next I ran the following job  (I took this from the IBM manual z/OS V1R12.0
DFSMSdfp Storage Administration SC26-7402-14) : 
 
//GENREP   EXEC  ACBJBAOB,

//    PLIB1=SYS1.DGTPLIB, 

//    TABL2=SYS2.TEST.ISPTABL 

//DCOLIN  DD  DSN=SYS2.DCOLLECT.DATA1,DISP=SHR

//ISPFILE DD  DSN=SYS2.DATASET.REPORT,DISP=OLD 

//SYSTSIN  DD *

PROFILE PREFIX(ZWA6PWG) 

ISPSTART CMD(ACBQBAR7) +
BATSCRW(132) BATSCRD(27) BREDIMAX(3) BDISPMAX() 

//SYSIN DD  *

DSN VOLSER ALLOCSP RECFM TITLE=DATA SET REPORT FROM DCOLLECT DATA -
17/07/2013 TOTALS BLKSIZE DSORG MGMTCLAS STORGRP
/*
However, when I check the output dsn   SYS2.DATASET.REPORT this is what I
find and I cannot understand why. 

READY PROFILE PREFIX(ZWA6PWG) 

READY ISPSTART CMD(ACBQBAR7)  BATSCRW(132) BATSCRD(27) BREDIMAX(3)
BDISPMAX() 

Number 1 parameter was: DSN 

Number 2 parameter was: VOLSER 

Number 3 parameter was: ALLOCSP

Number 4 parameter was: RECFM 

Number 5 parameter was: TITLE 

Number 6 parameter was: TOTALS 

Number 7 parameter was: BLKSIZE 

Number 8 parameter was: DSORG 

Number 9 parameter was: MGMTCLAS 

Number 10 parameter was: STORGRP

  Time    *** ISPF transaction log ***  
Us  Userid: ZWA6PWG    Date: 13/07/19   Page: 1  


  08:41   Start of ISPF Log - - -  - Session # 1
---
  08:41  TSO - Command  -  - ACBQBAR7
  08:54    End of ISPF Log - - - - - Session # 1
-
 




From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, July 19, 2013 1:25:08 PM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


Then I would run DCOLLECT with all the parms (MIGD, CAPD VOL(*) etc...) and
then check SYSPRINT and see what records are being produced.  There is a
summary at the end of the message indicating how many of each record is
found.

For example

IDC01811I NUMBER OF 'D ' RECORDS PROCESSED WAS 442789            
IDC01811I NUMBER OF 'A ' RECORDS PROCESSED WAS 378331            
IDC01811I NUMBER OF 'V ' RECORDS PROCESSED WAS 1333              
IDC01811I NUMBER OF 'M ' RECORDS PROCESSED WAS 38429              
IDC01811I NUMBER OF 'B ' RECORDS PROCESSED WAS 61141              
IDC01811I NUMBER OF 'C ' RECORDS PROCESSED WAS 3405              
IDC01811I NUMBER OF 'T ' RECORDS PROCESSED WAS 3                  

It helps us that you try things and provide details back.  Each shop is
unique and we need to see the details in order to help.


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Friday, July 19, 2013 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lizette,
 
I was limiting to using MIGRATEDATA just to ensure that DCOLLECT was working
correctly.  We are running z/OS 1.13.  I cannot use the ISMF Option G
because some of the RMM modules have not been installed. (confirmed by the

Re: DCOLLECT QUESTION -RESULTS PUZZLING -

2013-07-20 Thread esmie moo 
Lizette,
 
Thanks for your help.  I have the NAVIQUEST manual and I will take a look.



From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Saturday, July 20, 2013 10:38:12 AM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


According to the Naviquest manual: 


ACBQBAR7 is called by SYS1.SACBCNTL member ACBJBARD to generate a flat file
from DCOLLECT data taken from data set records and lists the fields of your
choice, in the order you specify.

Does not appear to handle Migrated data.

So, you could run a plain dcollect as I described, or review the Naviquest
manual (you can find them on the IBM.COM website)

http://www.redbooks.ibm.com/abstracts/sg244720.html
http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.
zos.r11.idas200/naviquest.htm


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Saturday, July 20, 2013 6:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lizette,
 
Here is what I had said earlier (see below).  I cannot figure out why the 
output dsn   SYS2.DATASET.REPORT does not show is that dsn list but only
system stats.  David Devine said that "The problem is that you want to get a
report on M type (migration) dcollect records and the job deck you are
running will only select D type dataset records."  I cannot seem to find
where the M type records are being selected in the job deck.  This is where
my problem is.


 
Next I ran the following job  (I took this from the IBM manual z/OS V1R12.0
DFSMSdfp Storage Administration SC26-7402-14) : 
 
//GENREP   EXEC  ACBJBAOB,

//    PLIB1=SYS1.DGTPLIB, 

//    TABL2=SYS2.TEST.ISPTABL 

//DCOLIN  DD  DSN=SYS2.DCOLLECT.DATA1,DISP=SHR

//ISPFILE DD  DSN=SYS2.DATASET.REPORT,DISP=OLD 

//SYSTSIN  DD *

PROFILE PREFIX(ZWA6PWG) 

ISPSTART CMD(ACBQBAR7) +
BATSCRW(132) BATSCRD(27) BREDIMAX(3) BDISPMAX() 

//SYSIN DD  *

DSN VOLSER ALLOCSP RECFM TITLE=DATA SET REPORT FROM DCOLLECT DATA -
17/07/2013 TOTALS BLKSIZE DSORG MGMTCLAS STORGRP
/*
However, when I check the output dsn   SYS2.DATASET.REPORT this is what I
find and I cannot understand why. 

READY PROFILE PREFIX(ZWA6PWG) 

READY ISPSTART CMD(ACBQBAR7)  BATSCRW(132) BATSCRD(27) BREDIMAX(3)
BDISPMAX() 

Number 1 parameter was: DSN 

Number 2 parameter was: VOLSER 

Number 3 parameter was: ALLOCSP

Number 4 parameter was: RECFM 

Number 5 parameter was: TITLE 

Number 6 parameter was: TOTALS 

Number 7 parameter was: BLKSIZE 

Number 8 parameter was: DSORG 

Number 9 parameter was: MGMTCLAS 

Number 10 parameter was: STORGRP

  Time    *** ISPF transaction log ***  
Us  Userid: ZWA6PWG    Date: 13/07/19   Page: 1  


  08:41   Start of ISPF Log - - -  - Session # 1
---
  08:41  TSO - Command  -  - ACBQBAR7
  08:54    End of ISPF Log - - - - - Session # 1
-
 




From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, July 19, 2013 1:25:08 PM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


Then I would run DCOLLECT with all the parms (MIGD, CAPD VOL(*) etc...) and
then check SYSPRINT and see what records are being produced.  There is a
summary at the end of the message indicating how many of each record is
found.

For example

IDC01811I NUMBER OF 'D ' RECORDS PROCESSED WAS 442789            
IDC01811I NUMBER OF 'A ' RECORDS PROCESSED WAS 378331            
IDC01811I NUMBER OF 'V ' RECORDS PROCESSED WAS 1333              
IDC01811I NUMBER OF 'M ' RECORDS PROCESSED WAS 38429              
IDC01811I NUMBER OF 'B ' RECORDS PROCESSED WAS 61141              
IDC01811I NUMBER OF 'C ' RECORDS PROCESSED WAS 3405              
IDC01811I NUMBER OF 'T ' RECORDS PROCESSED WAS 3                  

It helps us that you try things and provide details back.  Each shop is
unique and we need to see the details in order to help.


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Friday, July 19, 2013 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lizette,
 
I was limiting to using MIGRATEDATA just to ensure that DCOLLECT was working
correctly.  We are running z/OS 1.13.  I cannot use the ISMF Option G
because some of the RMM modules have not been installed. (confirmed by the
MVS group).  I am using SAS to parse the output once the records from the
DCOLLECT has been created.  



From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 19, 2013 12:40:47 PM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


Try checking out this link.  It describes the DCOLLECT function

http://publib.bo

Re: gzip zOS data set into zOS omvs file

2013-07-20 Thread Paul Gilmartin 
On Sat, 20 Jul 2013 07:33:52 -0700, John Mattson wrote:
>  
>SO to start all over IS there a way to
>1) On zOS MVS convert a file to ascii and/then
>2) Zip, compress whatever, it into something which gzip can unzip in unix?
>
Most easy; tested on an Ubuntu Linux system under Virtualbox on OS X:

572 $ ssh user@mvs "cp \"//'sys1.maclib(splevel)'\" /dev/fd/1" |
gzip >foosplevel.gz
password: 

573 $ gunzip ASCII; sometimes undesirable, but a boon
for your requirement.)

o Uses no temporary file space on z/OS and only the zipped
  payload on Linux.

o Uses no non-IBM software on z/OS; runs gzip on Linux.

o could readily be inverted to use ssh client on z/OS; server
  on Linux (untested).

o Isn't escaping quotation marks fun!?

-- gil


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

Re: gzip zOS data set into zOS omvs file

2013-07-20 Thread Paul Gilmartin 
On Sat, 20 Jul 2013 07:33:52 -0700, John Mattson wrote:

>After looking into this more deeply I realize I have to start all
>over.  I do not have enough disk on OMVS to copy to OMVS and then gzip,
>and I have no spare disk to add.  So that is out.  Even the stdout still
>requires disk be available.
>SO to start all over IS there a way to
>1) On zOS MVS convert a file to ascii and/then
>2) Zip, compress whatever, it into something which gzip can unzip in unix?
> 
I used IEBGENER to transfer between UNIX and legacy before "cp"
gained the ability to process legacy data sets.  I still use it because:

o I like the control it provides over attributes of SYSUT2.

o Inertia.  (Does that make me "laudator temporis acti"?)

(I believe a similar suggestion using "cp" has previously
been made here.)

So, I would in a Rexx EXEC:

call BPXWDYN 'alloc dd(SYSUT2) filedata(TEXT) path(''/dev/fd/1'') ... '
...
address ATTCHMVS IEBGENER

then, in the Rexx, or easier outside, pipe that:

... | iconv -f IBM-1047 -t ISO8859-1 | gzip | ...

Redirect to UNIX file.  Or pipe to ssh to avoid spending any more
z/OS DASD.  Newer versions of z/OS FTP also support (named?)
pipes.

-- gil

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

Re: ACS routine imbed/include function?

2013-07-20 Thread Lizette Koehler 
Also here

Additional Storage Administration Functions

z/OS V1R11.0 DFSMSdfp Storage Administration z/OS V1R10.0-V1R11.0 SC26-7402-13

The following are additional storage administration functions:

QSAVE and QRETRIEV ISMF commands

The QSAVE and QRETRIEV ISMF commands let you save a "query" of frequently 
used parameters under ISMF. You can then retrieve the parameters by their query 
names. The QSAVE and QRETRIEV ISMF commands can be used while running the ISMF 
data set list or volume list options, interactively or in batch.
Model Command Generator (ACBQFLM1 EXEC for saved ISMF lists and ACBQADM2 
EXEC for DCOLLECT data)

The Model Command Generator option creates a "model" command against each 
entry in a data set saved ISMF list, a saved ISMF volume list, or from DCOLLECT 
data. NaviQuest does the symbolic substitution.
COPYFILT macro

Using the COPYFILT macro you can create synchronized filter lists (FILTLISTs) 
that can be applied across all ACS routines. Create a FILTLIST member in your 
ACS routine source data set. Make all filter list updates there. Then call the 
COPYFILT macro from the command line to have the changes replicated across all 
of the ACS routines.

Lizette

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Saturday, July 20, 2013 8:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ACS routine imbed/include function?

I found the Naviquest Manual has some info on COPYFILT in it

International Technical Support Organization NaviQuest Demonstration and 
Hands-On Usage Guide April 1996  SG24-4720

· Use COPYFILT for ACS filters
Commonly the ACS changes that you make to include a new data subtype to be 
SMS-managed are to FILTLISTs. The DFSMS FIT process recommends that you have a 
single member that includes all FILTLISTs used by all ACS routines. You then 
make changes to the FILTLISTs in this single member.
After all changes are made, you can move all FILTLISTs from the single member 
to each of the ACS routines.

NaviQuest has a COPYFILT command to help you in the maintenance of FILTLISTs. 
The COPYFILT command automatically moves the FILTLISTs from a single PDS member 
to each of your ACS routines. COPYFILT also enforces change control 
documentation.


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Monday, July 15, 2013 6:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ACS routine imbed/include function?

Vernooij, CP wrote:

>So I probably mixed some historical info in my memory. It would be nice to 
>have, e.g. for dsname- of volser-filtlists used in more than one routine. 
>However, there are not many enhancements in ACS routines the last decades, so 
>I expect this will remain a wish. 

You've got my curiousity turned on and I searched my *ss off since your first 
post! It was indeed a long time I saw any announcement for ACS enhancements if 
at all. 

But then I wonder if you were thinking about 'COPYFILT macro: COPYLIB facility 
for FILTLISTs'. Granted that is for initial SMS setup.

On the otherside, I wonder if you were refering to FILTERDD in DFDSS. There you 
can probably concatenate at your leisure...

Hmmm, perhaps time for a Share thing? Think of it: one set of Include/exclude 
for DB2 folks, another for other dbas, etc.

Groete / Greetings
Elardus Engelbrecht

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

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

Re: ACS routine imbed/include function?

2013-07-20 Thread Lizette Koehler 
I found the Naviquest Manual has some info on COPYFILT in it

International Technical Support Organization NaviQuest Demonstration and 
Hands-On Usage Guide April 1996  SG24-4720

· Use COPYFILT for ACS filters
Commonly the ACS changes that you make to include a new data subtype to
be SMS-managed are to FILTLISTs. The DFSMS FIT process recommends
that you have a single member that includes all FILTLISTs used by all ACS
routines. You then make changes to the FILTLISTs in this single member.
After all changes are made, you can move all FILTLISTs from the single
member to each of the ACS routines.

NaviQuest has a COPYFILT command to help you in the maintenance of
FILTLISTs. The COPYFILT command automatically moves the FILTLISTs from
a single PDS member to each of your ACS routines. COPYFILT also
enforces change control documentation.


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Monday, July 15, 2013 6:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ACS routine imbed/include function?

Vernooij, CP wrote:

>So I probably mixed some historical info in my memory. It would be nice to 
>have, e.g. for dsname- of volser-filtlists used in more than one routine. 
>However, there are not many enhancements in ACS routines the last decades, so 
>I expect this will remain a wish. 

You've got my curiousity turned on and I searched my *ss off since your first 
post! It was indeed a long time I saw any announcement for ACS enhancements if 
at all. 

But then I wonder if you were thinking about 'COPYFILT macro: COPYLIB facility 
for FILTLISTs'. Granted that is for initial SMS setup.

On the otherside, I wonder if you were refering to FILTERDD in DFDSS. There you 
can probably concatenate at your leisure...

Hmmm, perhaps time for a Share thing? Think of it: one set of Include/exclude 
for DB2 folks, another for other dbas, etc.

Groete / Greetings
Elardus Engelbrecht

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

Re: DCOLLECT QUESTION -RESULTS PUZZLING -

2013-07-20 Thread Lizette Koehler 
According to the Naviquest manual: 


ACBQBAR7 is called by SYS1.SACBCNTL member ACBJBARD to generate a flat file
from DCOLLECT data taken from data set records and lists the fields of your
choice, in the order you specify.

Does not appear to handle Migrated data.

So, you could run a plain dcollect as I described, or review the Naviquest
manual (you can find them on the IBM.COM website)

http://www.redbooks.ibm.com/abstracts/sg244720.html
http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.
zos.r11.idas200/naviquest.htm


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Saturday, July 20, 2013 6:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lizette,
 
Here is what I had said earlier (see below).  I cannot figure out why the 
output dsn   SYS2.DATASET.REPORT does not show is that dsn list but only
system stats.  David Devine said that "The problem is that you want to get a
report on M type (migration) dcollect records and the job deck you are
running will only select D type dataset records."  I cannot seem to find
where the M type records are being selected in the job deck.  This is where
my problem is.


 
Next I ran the following job  (I took this from the IBM manual z/OS V1R12.0
DFSMSdfp Storage Administration SC26-7402-14) : 
 
//GENREP   EXEC  ACBJBAOB,

 //    PLIB1=SYS1.DGTPLIB, 

//    TABL2=SYS2.TEST.ISPTABL 

//DCOLIN  DD  DSN=SYS2.DCOLLECT.DATA1,DISP=SHR

 //ISPFILE DD  DSN=SYS2.DATASET.REPORT,DISP=OLD 

//SYSTSIN  DD *

 PROFILE PREFIX(ZWA6PWG) 

ISPSTART CMD(ACBQBAR7) +
BATSCRW(132) BATSCRD(27) BREDIMAX(3) BDISPMAX() 

//SYSIN DD  *

 DSN VOLSER ALLOCSP RECFM TITLE=DATA SET REPORT FROM DCOLLECT DATA -
17/07/2013 TOTALS BLKSIZE DSORG MGMTCLAS STORGRP
/*
However, when I check the output dsn   SYS2.DATASET.REPORT this is what I
find and I cannot understand why. 

READY PROFILE PREFIX(ZWA6PWG) 

READY ISPSTART CMD(ACBQBAR7)  BATSCRW(132) BATSCRD(27) BREDIMAX(3)
BDISPMAX() 

Number 1 parameter was: DSN 

Number 2 parameter was: VOLSER 

Number 3 parameter was: ALLOCSP

Number 4 parameter was: RECFM 

Number 5 parameter was: TITLE 

Number 6 parameter was: TOTALS 

Number 7 parameter was: BLKSIZE 

Number 8 parameter was: DSORG 

Number 9 parameter was: MGMTCLAS 

Number 10 parameter was: STORGRP

  Time    *** ISPF transaction log ***  
Us  Userid: ZWA6PWG    Date: 13/07/19   Page: 1  


  08:41   Start of ISPF Log - - -  - Session # 1
---
  08:41  TSO - Command  -  - ACBQBAR7
  08:54    End of ISPF Log - - - - - Session # 1
-
 




From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, July 19, 2013 1:25:08 PM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


Then I would run DCOLLECT with all the parms (MIGD, CAPD VOL(*) etc...) and
then check SYSPRINT and see what records are being produced.  There is a
summary at the end of the message indicating how many of each record is
found.

For example

IDC01811I NUMBER OF 'D ' RECORDS PROCESSED WAS 442789            
IDC01811I NUMBER OF 'A ' RECORDS PROCESSED WAS 378331            
IDC01811I NUMBER OF 'V ' RECORDS PROCESSED WAS 1333              
IDC01811I NUMBER OF 'M ' RECORDS PROCESSED WAS 38429              
IDC01811I NUMBER OF 'B ' RECORDS PROCESSED WAS 61141              
IDC01811I NUMBER OF 'C ' RECORDS PROCESSED WAS 3405              
IDC01811I NUMBER OF 'T ' RECORDS PROCESSED WAS 3                  

It helps us that you try things and provide details back.  Each shop is
unique and we need to see the details in order to help.


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Friday, July 19, 2013 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lizette,
 
I was limiting to using MIGRATEDATA just to ensure that DCOLLECT was working
correctly.  We are running z/OS 1.13.  I cannot use the ISMF Option G
because some of the RMM modules have not been installed. (confirmed by the
MVS group).  I am using SAS to parse the output once the records from the
DCOLLECT has been created.  



From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 19, 2013 12:40:47 PM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


Try checking out this link.  It describes the DCOLLECT function

http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.
zos.r11.idai200/dcoll.htm

What version of z/OS do you run?
Do you use SAS, SAS/MXG, SAS/MICS, Tivoli or other analysis tools?  ICETOOL?

Perhaps you could use the ISMF Option G (report tool)?

I am not s

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-20 Thread Ted MacNEIL 
>Are you suggesting this parms has no performance implication? as documented in 
>  IGGHC104E  message

He stated: No significant performance impact to justify an outage for removal.

There's a difference between significant and none.

I agree with the expert:
1. The 'impact' is more than mitigated by the performance of today's DASD.
2. The cost of space is so little compared to what it was when these parameters 
were introduced.
3. How do you justify the outage for something this insignificant?
4. Rather than listening to the scare tactics (and ridicule) of others on this 
list, cost it out for your shop (not others). If the numbers work, then do it 
(I'd be surprised if you manage to justify it).
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

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

Re: gzip zOS data set into zOS omvs file

2013-07-20 Thread John Mattson 
After looking into this more deeply I realize I have to start all 
over.  I do not have enough disk on OMVS to copy to OMVS and then gzip, 
and I have no spare disk to add.  So that is out.  Even the stdout still 
requires disk be available. 
SO to start all over IS there a way to 
1) On zOS MVS convert a file to ascii and/then
2) Zip, compress whatever, it into something which gzip can unzip in unix? 
 
I am willing to look at any OEM software if that is what it takes. 

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-20 Thread Joel C. Ewing 
There is a small performance hit on current DASD with keeping the
obsolete IMBED REPLICATE structures , as John Eells has already implied
by use of "significant" in his statement that there is "no SIGNIFICANT
performance or space advantage".  The consensus in shops requiring 24x7
availability is the small, "no significant impact" is much preferred to
any outage or risk required to reorganize a catalog.

Now if you have any IMBED REPLICATE catalogs defined with
sub-cylinder-sized CA's, which would probably be unusual, then that
could increase the hit:  a catalog defined with a CA size of 3 tracks
would be throwing away 1/3 of its space on useless replicated INDEX CI
overhead, and a much higher percentage of its physical reads and writes
would be for redundant data. But that would be unusual, as typically
CYLINDER allocation was used for even small catalogs, which assured a
15-track CA size, precisely because even with old DASD that gave the
maximum benefit from IMBED REPLICATE at the minimum overhead cost.

If you are not constrained by 24x7 requirements, or have to take an
outage to move or resize a catalog anyway, then getting rid of the
obsolete structures at the same time is goodness.  We always went to a
new master catalog with a new release of z/OS, so for us only the
USERCATs were an issue, and over a period of years we eventually had to
resize or move all of them and took care of the issue at that point for
each.
JC Ewing

On 07/20/2013 06:17 AM, Shameem .K .Shoukath wrote:
> hi John,
> 
>   The Health checker points these parms as a performance affecting parms. 
> Also IGGHC104E in MVS System
> Messages Vol 9 for z/OS .13  Says
> The
> IMBED and REPLICATE attributes were intended as performance improvements but
> have proven to be otherwise. They have proven
> towaste
> DASD space and degrade performance. They have been obsoleted  by the
> newer, cached DASD devices. In some cases, unplanned
> outages have
> occured. No supported release of z/OS allows you to define a  user catalog
> or master catalog with either the IMBED or
> REPLICATE   attributes.
> IBM intends to drop support for these attributes in the
>  future.   
>  in our shop we have many catalogs (defined a long time back) has these parms 
> coded and Health checker warns about this. 
> 
> Are you suggesting this parms has no performance implication? as documented 
> in   IGGHC104E  message
>  
> 
> 
> 
> 
> Thanks and Regards
> Shameem K Shoukath
>  
>  
> 
> 
> 
>> 
>> From: John Eells 
>> To: IBM-MAIN@LISTSERV.UA.EDU 
>> Sent: Wednesday, July 17, 2013 6:01 PM
>> Subject: Re: Old usercatalogs with IMBED and REPLICATE
>>
>>
>> Richard Marchant wrote:
>>> Before you install Z/OS 1.13 do you need to remove the IMBED and REPLICATE 
>>> parameters from your old Usercatalogs or will they co-exist with  Z/OS 
>>> 1.13?  We are currently running Z/OS 1.11 and a number of the Usercatalogs 
>>> have the IMBED parameter with no obvious ill affect.
>>
>> As others have said, "No."  You need not do anything.  There are no 
>> current plans for removing this support, either.
>>
>> Also, I am reliably told that there is no significant performance or 
>> space advantage to be had that justifies making a catalog unavailable 
>> solely for the purpose of removing these attributes.
>>
>> -- 
>> John Eells
>> z/OS Technical Marketing
>> IBM Poughkeepsie
>> ee...@us.ibm.com
>>
...


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

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

«Enigma» vita e morte di Alan Turing

2013-07-20 Thread John Gilmore 
For and unfortunately only for those of you who read Italian there is
a beguiling fumetto of this title by Tuono Pettinato and Francesca
Riccioni accessible via the Corriere della Sera Cultura website

John Gilmore, Ashland, MA 01721 - USA

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

Re: DCOLLECT QUESTION -RESULTS PUZZLING -

2013-07-20 Thread esmie moo 
Lizette,
 
Here is what I had said earlier (see below).  I cannot figure out why the  
output dsn   SYS2.DATASET.REPORT does not show is that dsn list but only system 
stats.  David Devine said that "The problem is that you want to get a report on 
M type (migration) dcollect records and the job deck you are running will only 
select D type dataset records."  I cannot seem to find where the M type records 
are being selected in the job deck.  This is where my problem is.


 
Next I ran the following job  (I took this from the IBM manual z/OS V1R12.0 
DFSMSdfp Storage Administration SC26-7402-14) : 
 
//GENREP   EXEC  ACBJBAOB, 
//    PLIB1=SYS1.DGTPLIB,  
//    TABL2=SYS2.TEST.ISPTABL  
//DCOLIN  DD  DSN=SYS2.DCOLLECT.DATA1,DISP=SHR 
//ISPFILE DD  DSN=SYS2.DATASET.REPORT,DISP=OLD 
//SYSTSIN  DD *    
PROFILE PREFIX(ZWA6PWG)    
ISPSTART CMD(ACBQBAR7) +   
BATSCRW(132) BATSCRD(27) BREDIMAX(3) BDISPMAX()    
//SYSIN DD  *  
DSN    
VOLSER 
ALLOCSP    
RECFM  
TITLE=DATA SET REPORT FROM DCOLLECT DATA - 17/07/2013  
TOTALS 
BLKSIZE    
DSORG  
MGMTCLAS   
STORGRP    
/*
However, when I check the output dsn   SYS2.DATASET.REPORT this is what I find 
and I cannot understand why. 
READY   
PROFILE PREFIX(ZWA6PWG) 
 
READY   
ISPSTART CMD(ACBQBAR7) BATSCRW(132) BATSCRD(27) BREDIMAX(3) BDISPMAX()  
Number 1 parameter was: DSN 
Number 2 parameter was: VOLSER  
Number 3 parameter was: ALLOCSP 
Number 4 parameter was: RECFM   
Number 5 parameter was: TITLE   
Number 6 parameter was: TOTALS  
Number 7 parameter was: BLKSIZE 
Number 8 parameter was: DSORG   
Number 9 parameter was: MGMTCLAS    
Number 10 parameter was: STORGRP    
  Time    *** ISPF transaction log ***   Us 
 Userid: ZWA6PWG    Date: 13/07/19   Page: 1  

  08:41   Start of ISPF Log - - -  - Session # 1 ---
  08:41  TSO - Command  -  - ACBQBAR7 
  08:54    End of ISPF Log - - - - - Session # 1 -  
  
 




From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, July 19, 2013 1:25:08 PM
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -


Then I would run DCOLLECT with all the parms (MIGD, CAPD VOL(*) etc...) and
then check SYSPRINT and see what records are being produced.  There is a
summary at the end of the message indicating how many of each record is
found.

For example

IDC01811I NUMBER OF 'D ' RECORDS PROCESSED WAS 442789            
IDC01811I NUMBER OF 'A ' RECORDS PROCESSED WAS 378331            
IDC01811I NUMBER OF 'V ' RECORDS PROCESSED WAS 1333              
IDC01811I NUMBER OF 'M ' RECORDS PROCESSED WAS 38429              
IDC01811I NUMBER OF 'B ' RECORDS PROCESSED WAS 61141              
IDC01811I NUMBER OF 'C ' RECORDS PROCESSED WAS 3405              
IDC01811I NUMBER OF 'T ' RECORDS PROCESSED WAS 3                  

It helps us that you try things and provide details back.  Each shop is
unique and we need to see the details in order to help.


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esmie moo
Sent: Friday, July 19, 2013 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DCOLLECT QUESTION -RESULTS PUZZLING -

Lizette,
 
I was limiting to using MIGRATEDATA just to ensure that DCOLLECT was working
correctly.  We are runni

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-20 Thread John Gilmore 
This post is a response to a question that was, I am all but certain,
addressed not to me but to another John, John Eells.

z/OS is a large, powerful, and complex operating system.  It is
heterogeneous too.  Some of it has been rearchitected (a barbarous but
now inescapable word) to reflect z/Architecture; some, much of it, is
yet to be updated; and some, we arfe told, may never be.

It is thus full of vermiform appendices, no longer relevant facilities
left behind as it evolved that are now perhaps dysfunctional but not
crippling.

IMBED and REPLICATE are excellent examples.  They are today without
function. They are indeed mildly dysfunctional.

IBM's efforts to shed such facilities always meet with a storm of
protest from customer management, which almost never has any very
clear idea of what it is protesting about but does know that it is
being asked to expend resources 'gratuitously'.  Why not let sleeping
dogs lie?

The real objection to old, usually very old, catalogs containing IMBED
and REPLICATE is not that they waste resources in a very small way.
It is that they should long since have been replaced by more modern
catalog structures and, in organizations dedicated to stasis, have not
been.

These organizations are reactionary, but they do not wish to be called
reactionary, and here some latin is actually useful: 'reactionary' can
be replaced by 'laudator temporis acti' or even by the acronym LTI,
which is much less offensive restated in what Gibbon called "the
decent obscurity of a learned language".

Problems of this kind are not of course new.  Many of the automobiles,
'horseless carriages', produced in the late nineteenth century in both
Europe and North America came equipped with buggy-whip holders.  It
was pointed out early on that these holders were now dispensable.
Internal combustion engines are at best unresponsive to flagellation.
Some nevertheless wished to retain them 1) for sentimental reasons or
2) because it would be costly and diversionary to remove them.

Topics of this kind arise with some frequency on IBM-MAIN; and they
often stir up more interest and participation than substantively
important ones, perhaps because they are easier to understand.   All
this is drôle.  What is less so is the spectacle of able men and women
crafting careful defenses of the indefensible.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-20 Thread Shameem .K .Shoukath 
hi John,

  The Health checker points these parms as a performance affecting parms. Also 
IGGHC104E in MVS System
Messages Vol 9 for z/OS .13  Says
The
IMBED and REPLICATE attributes were intended as performance improvements but
have proven to be otherwise. They have proven
towaste
DASD space and degrade performance. They have been obsoleted  by the
newer, cached DASD devices. In some cases, unplanned
outages have
occured. No supported release of z/OS allows you to define a  user catalog
or master catalog with either the IMBED or
REPLICATE   attributes.
IBM intends to drop support for these attributes in the
 future.                                                               
 in our shop we have many catalogs (defined a long time back) has these parms 
coded and Health checker warns about this. 

Are you suggesting this parms has no performance implication? as documented in  
 IGGHC104E  message
 




Thanks and Regards
Shameem K Shoukath
 
 



>
> From: John Eells 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Wednesday, July 17, 2013 6:01 PM
>Subject: Re: Old usercatalogs with IMBED and REPLICATE
> 
>
>Richard Marchant wrote:
>> Before you install Z/OS 1.13 do you need to remove the IMBED and REPLICATE 
>> parameters from your old Usercatalogs or will they co-exist with  Z/OS 1.13? 
>>  We are currently running Z/OS 1.11 and a number of the Usercatalogs have 
>> the IMBED parameter with no obvious ill affect.
>
>As others have said, "No."  You need not do anything.  There are no 
>current plans for removing this support, either.
>
>Also, I am reliably told that there is no significant performance or 
>space advantage to be had that justifies making a catalog unavailable 
>solely for the purpose of removing these attributes.
>
>-- 
>John Eells
>z/OS Technical Marketing
>IBM Poughkeepsie
>ee...@us.ibm.com
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>

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

Re: Encryption of data written to disks FICON channels

2013-07-20 Thread R.S. 

W dniu 2013-07-20 09:12, Ron Hawkins pisze:

Radoslaw,

I agree with your question up to a point. Encryption of data at rest covers
most of the disk related scenarios to do with data protection. It especially
makes my favorite soapbox of erasing  disks with multiple overwrites a
redundant task.

But it is not encryption of data in flight. Data on the channel, in cache,
and transmitted from cache to cache by remote copy products is not encrypted
by controllers that support encryption of data at rest.
Well, I haven't considered encryption of the (FICON) network, simply 
assumed the server room is safe enough. For remote copy see below

I don't have any problem with field, record or file level encryption, but
there is a downside if you are doing remote copy over a network, as it
encrypted data usually compresses very poorly. It's not a problem for
everyone.

100% agreed.

Arye, Decru used to provide encryption devices for SCSI on Fibre Channel,
but I don't know if they ever extended that support to FICON.
DWDM solutions provide encryption, despite of the protocol used (FICON, 
SCSI-FC, Eth). Of course at the second end of DWDM it is again decrypted.



--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

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


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



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

Re: Partition a VTS 7720

2013-07-20 Thread R.S. 

W dniu 2013-07-19 22:55, subscribe ibm-main Jerry Bergman pisze:

We recently purchased a 7720 and need to partition it. We are a monoplex with 
TEST and PROD Lpars. The Redbook I was pointed to refers to the DEVSUPxx 
Parmlib member and relates it to the Fast Ready Categories on the TS7700 
Virtulization Engine. I see no reason to do this as the 7720 has no physical 
volumes and we use CA's TLMS  as our TMS which manages scratches just fine. 
What does make sense is the part about using HCD to define 1 control unit (16 
devices) to TEST and  the other 15 to PROD and then using Library Port Access 
Groups on the TS7700 Virtualization Engine to define the VOLSER ranges. 
Currently the Library Port Access Group does not show up on the TS7700 
Virtulization Engine. I'm guessing I'm missing a License Code, but I also left 
the LIBPORT-ID blank in HCD and need to add it. Any insight woul be appreciated.


1. Do you really need to partition it? Even non-sysplexed systems can 
share it, depending on configuration.
2. When you decide to partition it the DEVSUP category statements are 
the way to do it. Each system have its own category set.
3. When partitioning you take care about volumes, not the drives. The 
drives can be varied ON-OFFline by the operator or software like ATAM. 
Last, but not least: you have plenty of (virtual) drives, so you can 
assign them to the systems statically, that means assign once and never 
change.
4. Don't forget about wise naming convention for the volumes and proper 
settings in TLMS. For RMM it would be REJECT ANYUSE statement(s).
5. The above is needed for erroneous volume specific mount requests (job 
on TEST want to read from volume belonging to PROD).
6. (pilosophical). No method of sharing provides 100% isolation between 
the systems. It is always up to local (TEST) sysadmin to make other 
systems (PROD) data unavailable. So the administration on both (each) 
systems must trust each other.


--
Radoslaw Skorupka
Lodz, Poland






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

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


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



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

AUTO: John D Levine Vacation - Week of July 22, 2013 (returning 07/29/2013)

2013-07-20 Thread John D Levine 
I am out of the office until 07/29/2013.

For technical assistance, please contact my team's dispatcher Kenneth R
Percy/Columbia/IBM or backup dispatcher Carl R Arrington/Columbia/IBM.

Dave Edwards/St Louis/IBM, Mainframe Configuration FLM


Note: This is an automated response to your message  "Re: NFS automount
help requested" sent on 07/19/2013 23:01:02.

This is the only notification you will receive while this person is away.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL Parser

2013-07-20 Thread Timothy Sipples 
Peter Farley writes:
>And unfortunately [Enterprise COBOL V5.1] does NOT allow the same range
>of values that the C/C++ compiler's ARCH option allows.

Enterprise COBOL V5.1 supports compilation for ARCH(6) and above, i.e.
z990/z890 processors and above. Enterprise COBOL V4.2 is still available if
there's a requirement to target older processors.

>It would appear that either I was wrong in my assumption that COBOL had
>adopted the C/C++ back end or else in adopting it they restricted the
>possible values which can be used to z990/z890 and up.

Or possibly both?

Additional ARCH settings would have required additional testing,
presumably. I can see the wisdom in spending those testing resources in
other ways.


Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: sipp...@sg.ibm.com

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

Re: NFS automount help requested

2013-07-20 Thread Miklos Szigetvari 

Hi
- For the automount to work, you have to go into a directory in the 
/u/cics/wsbinds

- I guess you already defined this in the auto.master
- You should have to get an error message if the automount would fail .

On 19.07.2013 21:10, Alan Field wrote:

I have an NFS Server task running on LPAR A.

I export a directory /u/cics/wsbinds.

On LPAR B I can issue a mount for this directory using

MOUNT FILESYSTEM(wsbinds)  +
   TYPE(NFS)+
   MOUNTPOINT('/u/cics/wsbinds')+
   MODE(RDWR)   +
   parm('mvssysa:/u/cics/wsbinds')

  and access the files within.

But I really want this to be automounted on LPAR B.

On LPAR B I have a /u/cics/wsbinds defined.

I update my u.map file with

name  cics/wsbinds
type  NFS
mode  RDWR
filesystemwsbinds
parm  "mvssysa:/u/cics/wsbinds"
duration  nolimit

and restart automount.

No matter what I try I cannot get this to automount.

Given the MOUNT command works I suspect I have some confusion over the
u.map definitions but hours of googling haven't resulted in anything
useful.

TIA

Alan Field
Technical Engineer Principal
BCBS Minnesota
  



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





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

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

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

Re: Encryption of data written to disks FICON channels

2013-07-20 Thread Ron Hawkins 
Radoslaw,

I agree with your question up to a point. Encryption of data at rest covers
most of the disk related scenarios to do with data protection. It especially
makes my favorite soapbox of erasing  disks with multiple overwrites a
redundant task.

But it is not encryption of data in flight. Data on the channel, in cache,
and transmitted from cache to cache by remote copy products is not encrypted
by controllers that support encryption of data at rest.

I don't have any problem with field, record or file level encryption, but
there is a downside if you are doing remote copy over a network, as it
encrypted data usually compresses very poorly. It's not a problem for
everyone.

Arye, Decru used to provide encryption devices for SCSI on Fibre Channel,
but I don't know if they ever extended that support to FICON.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of R.S.
> Sent: Thursday, July 18, 2013 3:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Encryption of data written to disks FICON channels
> 
> W dniu 2013-07-18 21:08, Phil Smith pisze:
> > Arye Shemer wrote:
> >> I am looking for an Encryption solution for 'Data in Rest' for old
> >> disks (disks without self encryption capability).
> >> One of the options we thought of, was to encrypt the data through
> >> some FICON facility which sit on the FICON channel.
> >> I could not find provider for such device on the internet (maybe I
> >> used wrong semantics).
> >> If someone is using or know about such solution willing to send me a
> >> link of the web site's manufacturer ?
> > So you want whole-disk encryption, not encryption of specific fields?
> What's the use case/problem you're trying to solve? We're strong believers
> in field-level data protection, as it provides the best security. I'd be
> interested in hearing more details...
> >
> >
> Well,
> I vaguely remember such device for ESCON and (emulated) tape CU. (Note, I
> don't mean encryption feature on tape drives.) I'm not aware of any such
> device for FICON.
> BTW: What's wrong with whole disk encryption? Why field-level encryption
is
> better? IMHO it addresses different needs.
> 
> BTW2: There is an option for whole disk encryption, but this is a feature
of
> DASD box, so "old disk without self-encrypting facility" need to be
replaced.
> 
> BTW3: There are other solutions, like Encryption Facility, SecureZip,
which
> encrypt datasets, the dataset can be a addrdssu dump, so it can containt
any
> dataset or whole volume. Note, that costs license and consumes CPU cycles.
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> --
> Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
> przeznaczone wycznie do uytku subowego adresata. Odbiorc moe
> by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie
> jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym
> do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie,
> kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze
> jest prawnie zabronione i moe by karalne. Jeeli otrzymae t
> wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc
> wysyajc odpowied oraz trwale usun t wiadomo wczajc w to
> wszelkie jej kopie wydrukowane lub zapisane na dysku.
> 
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties.
If
> you are not the intended addressee of this e-mail or the employee
> authorised to forward it to the addressee, be advised that any
dissemination,
> copying, distribution or any other similar activity is legally prohibited
and may
> be punishable. If you received this e-mail by mistake please advise the
> sender immediately by using the reply facility in your e-mail software and
> delete permanently this e-mail including any copies of it either printed
or
> saved to hard drive.
> 
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
fax
> +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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.2013 r. kapita zakadowy BRE Banku SA (w
> caoci wpacony) wynosi 168.555.904 zotych.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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