Re: Spam from my account

[Shmuel Metz (Seymour J.)]

In <1317167294.89974.yahoomailmob...@web161422.mail.bf1.yahoo.com>, on
09/27/2011
   at 04:48 PM, Ed Gould  said:

> I have been told

By whom?

>my email account has been hacked and email was sent using it.

Have you seen evidence that the mail was actually sent from your
account? it is common for spammers to send using bogus addresses in
the reverse path and in the header. If your have a sample of the spam
in question, look at the Received header fields to see whether it was
actually sent by yahoo.

Note: I'm not denying that yahoo has security and spam issues, just
noting that there may be an alternative explanation for what you've
seen.

-- 
 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: Spam from my account

[Ivan Warren]

On 9/28/2011 1:52 AM, Ed Gould wrote:

  All, I have been advised my email account has been hacked.
I apologize.


Unfortunately, this won't change a thing.

The originator of an e-mail address is no more valid as a method of 
authentication than the return address at the back of a snail-mail envelope


There are methods that allow to determine the sender is actually who he 
claims to be, but this doesn't work on this mailing list because 
attachments are prohibited, therefore prohibiting S/MIME digital signatures.


--Ivan

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

[Rick Fochtman]

---


Q: How many personal injury attorneys does it take to change a light bulb?

A: Three–one to turn the bulb, one to shake him off the ladder, and the third 
to sue the ladder company.
 


-
Don't forget the maker of the bulb that fell and broke on the floor, for 
producing something as terribly (gasp) dangerous as a GLASS bulb. :-)


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

[Elardus Engelbrecht]

Shmuel Metz (Seymour J.) wrote:

>>What are you using to do tracing, if I may ask, please?

>I'm using a modified version of BWwhois[1] to do lookups. I've also got a RYO 
>utility[2] that scans the entire e-mail and looks up all of the relevant names 
>and addresses for use in reporting the spam.

>[1] The unmodified version is at 

>[2] The stable version is at
>

Shmuel, many many thanks for your really kind reply, I appreciate it very much! 
I learned something new today! :-) 

Please keep up with your excellent educational posts. Again many thanks! :-D

Groete / Greetings
Elardus Engelbrecht


Question: How many lawyers take it to change a lightbulb?

Answer: I don't know, but this is gonna cost you a lot for consulting fee, fee 
for actual work done and the bulb itself! :-)


Q: How many personal injury attorneys does it take to change a light bulb?
 
A: Three–one to turn the bulb, one to shake him off the ladder, and the third 
to sue the ladder company.

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

[Shmuel Metz (Seymour J.)]

In <0407320875097141.wa.elardus.engelbrechtsita.co...@bama.ua.edu>, on
08/05/2011
   at 07:56 AM, Elardus Engelbrecht 
said:

>What are you using to do tracing, if I may ask, please?

I'm using a modified version of BWwhois[1] to do lookups. I've also
got a RYO utility[2] that scans the entire e-mail and looks up all of
the relevant names and addresses for use in reporting the spam.

[1] The unmodified version is at 

[2] The stable version is at

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

[Elardus Engelbrecht]

Shmuel Metz (Seymour J.) wrote:

>The legitimate messages also went through hotmail. However, compare the 
>originating IP addresses; [108.20.159.218] is verizon while [65.55.90.239] is 
>microsoft.

Before I posted, I have traced only that domain name ending with hotmail. I 
initially did not bother to trace the 2 IP addresses.

Anyway I got the same results for these 2 IP addresses with www.dnsstuff.com. 
Thanks for confirming. It is much appreciated.

What are you using to do tracing, if I may ask, please?

Groete / Greetings
Elardus Engelbrecht

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

[Shmuel Metz (Seymour J.)]

In <4702673754796316.wa.elardus.engelbrechtsita.co...@bama.ua.edu>, on
08/05/2011
   at 06:59 AM, Elardus Engelbrecht 
said:

>I also got that one too. That one came from
>'snt0-omc4-s4.snt0.hotmail.com' located in USA despite trying to fake
>a msn address. 

The legitimate messages also went through hotmail. However, compare
the originating IP addresses; [108.20.159.218] is verizon while
[65.55.90.239] is microsoft.
 
-- 
 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: Spam

[Elardus Engelbrecht]

Shane Ginnane wrote:

>My ISP just harvested some junk (supposedly) from John G - a vacation reply.

I also got that one too. That one came from 'snt0-omc4-s4.snt0.hotmail.com' 
located in USA despite trying to fake a msn address. 

Hmm, I need a vacation from all those spam, spam and more spam ... ;-D

Groete / Greetings
Elardus Engelbrecht

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

[Elardus Engelbrecht]

Shane Ginnane wrote:

>Sorry - that would be Beijing in plain text.

For three and half nanoseconds I was thinking you're trying mixing English and 
Mandarin languages... :-)

Groete / Greetings
Elardus Engelbrecht

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

[Shane Ginnane]

Sorry - that would be Beijing in plain text.

--
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: SPAM-LOW: Re: CA-OPS/MVS to IBM's System Automation?

[John McKown]

The reason to convert would be money. We would be forced to do the
conversion in house, or not at all.

--
John McKown
Maranatha! <><
Sent from my Vibrant Android phone.

On Oct 22, 2010 6:24 AM, "Marc Heimlich"  wrote:

SFI (www.streamfoundry.com) has done 3 TSA migrations in the last six
months.  We can help.

Marc
heiml...@streamfoundry.com
--Original Message--
From: Andreas Steinberg
Sender: IBM-MAIN
To: IBM-MAIN
ReplyTo: IBM-MAIN
Subject: SPAM-LOW:  Re: CA-OPS/MVS to IBM's System Automation?
Sent: Oct 22, 2010 3:46 AM

John,
we did it 5 years ago with a lot of help by consultants. Because we dropped
NetView off before that, it came back again through the backdoor. And
because of the pricing model we were not amused.
IMHO many things are easier using OPS, some don't work, so you need to have
System Automation if you want to use GDPS for example. On the other hand the
IBM software is very huge, for our things to do it is too big, we are using
less than 50% of the features.
My operators actually are able to handle it, but they don't like it, cause
it is too complicated.

HTH Andreas

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


Sent from my Verizon Wireless BlackBerry

--
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: SPAM-LOW: Re: CA-OPS/MVS to IBM's System Automation?

[Marc Heimlich]

SFI (www.streamfoundry.com) has done 3 TSA migrations in the last six months.  
We can help.

Marc
heiml...@streamfoundry.com
--Original Message--
From: Andreas Steinberg
Sender: IBM-MAIN
To: IBM-MAIN
ReplyTo: IBM-MAIN
Subject: SPAM-LOW:  Re: CA-OPS/MVS to IBM's System Automation?
Sent: Oct 22, 2010 3:46 AM

John,
we did it 5 years ago with a lot of help by consultants. Because we dropped
NetView off before that, it came back again through the backdoor. And
because of the pricing model we were not amused.
IMHO many things are easier using OPS, some don't work, so you need to have
System Automation if you want to use GDPS for example. On the other hand the
IBM software is very huge, for our things to do it is too big, we are using
less than 50% of the features.
My operators actually are able to handle it, but they don't like it, cause
it is too complicated.

HTH Andreas

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


Sent from my Verizon Wireless BlackBerry

--
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: [**SPAM**] Re: More FUD on the demise of the Mainframe

[J. D. Cassidy]

Serious topic yaw here. Koyma was / is more "famous"..



=> better yet, to Vorkuta  (or did they dismantle that place after 1989?)
=>
=> /s/ tuco bonno;
=> Graduate, College of Conflict Management;
=> University of SouthEast Asia;
=> "I partied on the Ho Chi Minh Trail - tiến lên !! "
=>
=>
=>
=>>Too much trouble.. send him and the other mouse-twitching folks
=>> to Kolyma.
=>
=>
=> =>
=>
-
=> =>
=> =>>I would not worry about FUD given the following statement from the
=> =>> article.
=> =>>
=> =>>"Some companies still employ an older mainframe with a screen known as
=> a
=> =>>3270 terminal emulator, which evokes the decades-old Disk Operating
=> =>> System,
=> =>>or DOS, that predated Microsoft (MSFT) Windows"
=> =>>
=> =>>
=> =>
=>
--
=> => Set this guy down in front of a basic set of manuals. Warm his drawers
=> => with a riding crop or similar instrument untill he's digested some
=> => modern information and started to learn about a serious system.  :-)
=> =>
=> => 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
=> =>
=>
=>
=> John Cassidy (Dipl.-Ingr.)
=>
=> Kapellenstr. 21a
=>
=> D-65193 Wiesbaden
=>
=> EU
=>
=>
=>
=> Mobile: +49 (0) 170 794 3616
=>
=>
=> http://www.JDCassidy.net
=>
=> http://en.federaleurope.org/
=>
=> http://sva-zhosting.com/en/index.php
=>
=> --
=> 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
=>


John Cassidy (Dipl.-Ingr.)

Kapellenstr. 21a

D-65193 Wiesbaden

EU



Mobile: +49 (0) 170 794 3616


http://www.JDCassidy.net

http://en.federaleurope.org/

http://sva-zhosting.com/en/index.php

--
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: ***SPAM*** Re: easy access to the current cpu-peak-time status or cpu load

[Itschak Mugzach]

Ok. Suggest him to read those 12K records on product startup ;-)

On Thu, Jul 29, 2010 at 3:30 PM, Paul Gillis  wrote:

> What? Millions of type 89 SMF records. Nah, about 12,000 a month. Or report
> on SMF70LAC field in type 70 records, I do this daily for one of my
> customers.
>
> Cheers, Paul Gillis
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> > Behalf Of Itschak Mugzach
> > Sent: Thursday, 29 July 2010 9:49 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: ***SPAM*** Re: easy access to the current cpu-peak-time status
> or
> > cpu load
> >
> > This "invoice factor" is a number that is caluleted reading milions of
> SMF
> > recods. Why don't you just keep this number in your product DB ad let
> your
> > customer enter this once a month?
> >
> > ITschak
> >
> > On Thu, Jul 29, 2010 at 2:38 PM, Dr. Stephen Fedtke <
> > max_mainframe_...@fedtke.com> wrote:
> >
> > > hi all,
> > >
> > > we need to know in realtime how close the system is to its cpu peak
> > > interval/time (meaning that peak time representing the z user's major
> > > invoice factor).
> > >
> > > does anybody have an idea on how to EASILY determine key information
> > > in the field of "cpu load" etc., such as via reading control blocks,
> > > or issuing a console command? using sdsf or similar is no possible way
> in
> > our situation.
> > >
> > > many thanks!
> > >
> > > best
> > > stephen
> > >
> > >
> > > ---
> > > Dr. Stephen Fedtke
> > > Enterprise-IT-Security.com
> > >
> > > Seestrasse 3a
> > > CH-6300  Zug
> > > Switzerland
> > > Tel. ++41-(0)41-710-4005
> > > www.enterprise-it-security.com
> > >
> > >
> > > ++NEWS++ SF-LoginHood provides state-of-the-art password, phrase and
> > > ++NEWS++ login
> > > security for z/OS ++NEWS++
> > >
> > > --
> > > 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
>
> --
> 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: ***SPAM*** Re: easy access to the current cpu-peak-time status or cpu load

[Paul Gillis]

What? Millions of type 89 SMF records. Nah, about 12,000 a month. Or report
on SMF70LAC field in type 70 records, I do this daily for one of my
customers.

Cheers, Paul Gillis

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Itschak Mugzach
> Sent: Thursday, 29 July 2010 9:49 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: ***SPAM*** Re: easy access to the current cpu-peak-time status or
> cpu load
> 
> This "invoice factor" is a number that is caluleted reading milions of SMF
> recods. Why don't you just keep this number in your product DB ad let your
> customer enter this once a month?
> 
> ITschak
> 
> On Thu, Jul 29, 2010 at 2:38 PM, Dr. Stephen Fedtke <
> max_mainframe_...@fedtke.com> wrote:
> 
> > hi all,
> >
> > we need to know in realtime how close the system is to its cpu peak
> > interval/time (meaning that peak time representing the z user's major
> > invoice factor).
> >
> > does anybody have an idea on how to EASILY determine key information
> > in the field of "cpu load" etc., such as via reading control blocks,
> > or issuing a console command? using sdsf or similar is no possible way
in
> our situation.
> >
> > many thanks!
> >
> > best
> > stephen
> >
> >
> > ---
> > Dr. Stephen Fedtke
> > Enterprise-IT-Security.com
> >
> > Seestrasse 3a
> > CH-6300  Zug
> > Switzerland
> > Tel. ++41-(0)41-710-4005
> > www.enterprise-it-security.com
> >
> >
> > ++NEWS++ SF-LoginHood provides state-of-the-art password, phrase and
> > ++NEWS++ login
> > security for z/OS ++NEWS++
> >
> > --
> > 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

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

[Mary Anne Matyaz]

I didn't get it.
MA

On Tue, Jun 30, 2009 at 12:33 PM, Rick Fochtman  wrote:

>  Shane wrote:
>
> Anyone else get spam from ittrader ?.
>> Just wondering if my address was harvested from here.
>>
>> Shane ...
>>
>> --
>> 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
>>
>>
>>
> I got it too.
>
>
> --
> 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: spam

[Rick Fochtman]

Shane wrote:


Anyone else get spam from ittrader ?.
Just wondering if my address was harvested from here.

Shane ...

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

 


I got it too.

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

[A L Hughes]

Shane, been getting this c r a p for a couple of weeks now. They generally used 
to harvest Hotmail addresses. So they've now advanced to more sophisticated 
ways. As Steve The Trainer said, Delete works well. 
Personally, I find if I intersperse some Welsh into it, it works even better! 
Aled


-Original Message-
From: Shane 
To: IBM-MAIN@bama.ua.edu
Sent: Tue, Jun 30, 2009 2:20 pm
Subject: spam



Anyone else get spam from ittrader ?.
Just wondering if my address was harvested from here.

Shane ...

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

[Steve Comstock]

Shane wrote:

Anyone else get spam from ittrader ?.
Just wondering if my address was harvested from here.

Shane ...


I got one, but I'm on several lists, so it's hard to
tell where it came from. Anyway, 'Delete' works fast.


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> Ask about being added to our opt-in list:  <==
==>   * Early announcement of new courses  <==
==>   * Early announcement of new techincal papers <==
==>   * Early announcement of new promotions   <==


--
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: ****SPAM**** Re: Is Xrc a reasonable solution between two databases created separately(in DB2)?

[Ron Hawkins]

Farzad,

That's true, but it does not change me answer. There's no free lunch in
this. XRC, TrueCopy, PPRC, SRDF, HUR, etc are all designed to copy volumes.
The volume is the only level of granularity that is understood. These
products are not aware of VTOC, Datasets, VVDS, UCAT or DB2 System Tables,
all they track is whether there is a change to a track or not.

If you are using a DB2 instance on one LPAR to access tablespaces that are
being updated, via XRC, on another system then you must expect to
continuously have database integrity problems as the changes propagated by
XRC will not be reflected in theDB2 buffers or catalogs. I've been forced to
try this with CICS/VSAM and DB2 on SRDF and failed as expected. I've also
tried it with RRDF and CA/IDMS and it was problematic with around four
failures a day.

If any of your source tablespaces take another extent on another volume, the
secondary DB2 will have no idea. The only method I'm aware of that is
problem free is IBM InfoSphere Replication Server for z/OS (thanks Tim) as
it publishes and applies changes through the secondary database instance,
with a lot of granularity as to what is copied. With the updates applied as
a UOW through the DB2 instance there are no integrity problems to deal with.

So if you want real time data I'm not aware of a way to do it without
burning MIPS on the primary LPAR.

Ron 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> farzad yazdi
> Sent: Thursday, April 16, 2009 10:42 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] SPAM Re: Is Xrc a reasonable solution
between
> two databases created separately(in DB2)?
> 
> Ron I don't know about PRDF but Progagator does put a load on the source
CPU
> which isn't desirable. This is what's different and quite nice about XRC.
> 

--
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: ****SPAM**** Re: Is Xrc a reasonable solution between two databases created separately(in DB2)?

[farzad yazdi]

Ron I don't know about PRDF but Progagator does put a load on the source CPU 
which isn't desirable. This is what's different and quite nice about XRC.



From: IBM Mainframe Discussion List on behalf of Ron Hawkins
Sent: Thu 16/04/2009 03:06
To: IBM-MAIN@bama.ua.edu
Subject: SPAM Re: Is Xrc a reasonable solution between two databases 
created separately(in DB2)?



Sanaz,

>From what I read of your intent you may be better of using DB2 Data
Propagator from IBM,  or RRDF from ENET Corp.

These products are working with the Database rather than the volumes, so
that dataset allocation and extensions will be transparent.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Sanaz Pourdarab
> Sent: Thursday, April 16, 2009 1:59 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Is Xrc a reasonable solution between two databases
> created separately(in DB2)?
>
> I 'm trying to do this and I have some problem to have data everytime
> available there.
> I 'm doing this for a large table defined as partitioned , some of Its
Indexes
> were extended on 2 volumes selected from its storage group on db2 in
source
> side . I have to define them in the target system using Vcat  to force
which
> volumes be copied to each other . The problem is that I do'nt know what
> happened when an  index dataset wants to get extend on the third volume.I
> think I should check in target to add the new volume which contains new
> copied extend to the cluster I made.
> This is the problem happened when I try to make this XRC between to
> different database ( with  similar  objects' names) .Since I have to
define
> the
> target objects with use of vcat not storage group to manage how datasets
> being distributed on which volumes, I have to monitor the extension of
> datasets in source system.
> Is there any other ways to avoid this situation?
> And generally I asked whether the xrc is a reasonable solution for this
> situation or not.
>
> --
> 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



--
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: [spam] Re: IBM buys PSI

[R.S.]

Jim McAlpine wrote:

On 7/3/08, R.S. <[EMAIL PROTECTED]> wrote:

I disagree. Real competition is second hand market. You can buy small z/800

almost for peanuts (few k$, less than FLEX). It's definitely not obsoleted.
You can run any version of supported OSes, including future z/OS 1.10.
There are HW features available only on newer models, but it is irrelevant
for vast majority of ISVs.

--
Radoslaw Skorupka
Lodz, Poland



AFAIK you can't licence the ADCD software package on these machines.  Please
tell me if I'm wrong.


I don't know.
However I know guy, who owns 2 machines and run parallel sysplex. z/OS.e
He doesn't write any software , he's HW broker.
According to him, it's cheaper than charlady.

More seriously, there are other licenses, like zNALC, and other 
possibilities, like telecommuting to third party system, even dedicated 
system (LPAR, VM guest).


However I agree, having FLEX as an option would be even better. And I 
would love real HW competition! I mean big machines.


--
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.2008 r. kapita zakadowy BRE Banku SA  wynosi 
118.642.672 zote i zosta w caoci wpacony.

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

Re: [spam] Re: IBM buys PSI

[Jim McAlpine]

On 7/3/08, R.S. <[EMAIL PROTECTED]> wrote:
>
> I disagree. Real competition is second hand market. You can buy small z/800
>> almost for peanuts (few k$, less than FLEX). It's definitely not obsoleted.
>> You can run any version of supported OSes, including future z/OS 1.10.
>> There are HW features available only on newer models, but it is irrelevant
>> for vast majority of ISVs.
>>
>> --
>> Radoslaw Skorupka
>> Lodz, Poland
>
>
AFAIK you can't licence the ADCD software package on these machines.  Please
tell me if I'm wrong.

Jim McAlpine

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

Re: [spam] Re: IBM buys PSI

[R.S.]

Pinnacle wrote:
[...]
Bastids.  This is bad news for PWD/FLEX suckers.  IBM's next red herring 
for developers will be a PSI box which we will all stumble over 
ourselves buying, only to have it obsoleted three years later (see R390, 
P390, Integrated Server, MP3000, FLEX, etc.).  They'll be sure to keep 
us spending 5-6 figures for the hardware every few years, just like 
they've been doing for the last 2 decades.  The shell game continues


I disagree. Real competition is second hand market. You can buy small 
z/800 almost for peanuts (few k$, less than FLEX). It's definitely not 
obsoleted. You can run any version of supported OSes, including future 
z/OS 1.10.
There are HW features available only on newer models, but it is 
irrelevant for vast majority of ISVs.


--
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.2008 r. kapita zakadowy BRE Banku SA  wynosi 
118.642.672 zote i zosta w caoci wpacony.

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

Re: SPAM: Re: clock, daylight savings time

[Rick Fochtman]

---

But Rick, 


do your users all reside in different time zones like mine do???

Isn't amazing how much railroad schedules and saving daylight make our lives 
so difficult at times. 


Decisions, decisions!
 


--
No, we were split only across 5 different time zones. (GMT, on London 
and Liverpool, plus the continental US)


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

Re: SPAM: RACF Tool PWDCOPY (ichwpin/ichpwout)

[Rick Fochtman]

-

I tried to run the ´sample´ IBM password copy utility (PWDCOPY on the 
IBM RACF website) on z/OS 1.7 and

z/OS 1.8. The tool runs without errors, but the copied password could
not be used. Has anyone recently used this tool? Or has someone used 
an alternative to copy passwords between RACF databases or users.


In my case, userids are going to be renamed. Since this will be done 
using ´big bang´ it´s not a good idea to give everyone a new password, 
transporting the old password would be a great help.


I´ld really like to use something ´proven´ before I start to twiddle 
around with RACROUTE EXTRACT requests :-)


---
IIRC, RACF uses a one-way function using the USERID as the key in 
encrypting the user-supplied password, then compares that result to the 
password in the database. So if you're trying to copy the password to a 
different userid, it's not likely to work.


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

Re: SPAM: Re: Transfer reports from lpar to lpar

[Brian Westerman]

Setting up NJE really isn't that difficult.  I can send you a short set of
directions for how to set it up if you want.  If your systems are both on
the same physical processor (2 LPARs), and if it's a z-series box with an
OSA/e or similar, it's even easier.  

I would bet that your systems people probably already have all of the pieces
there, they just need to put them in place.

Let me know.

Brian

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

Re: SPAM: Re: Transfer reports from lpar to lpar

[John S. Giltner, Jr.]

Gilbert Cardenas wrote:

On Sat, 8 Mar 2008 12:45:28 EST, Ed Finnell <[EMAIL PROTECTED]> wrote:


Guess if all you got is PFCSKs  DEST='IP:ipaddr' might suffice w/o NJE

<<>>
  DEST=destination
The destination subparameter for JES2 is one of the following:
LOCAL|ANYLOCAL
'IP:ipaddr'
name
|  Nn
|  NnRm
NnnR
NnnnRmmm
NRmm
|  NnRm
|  (node,remote)
nodename.userid
'nodename.IP:ipaddr'

<<>>



I would like to use this option however, if I use the 'IP:ipaddr' the jcl reference 
states that a functional subsystem that can process IP-distributed data sets 
sends the data to the specified host system.

Could you please translate what that means.
I see the report in the output queue sitting with a dest of  but how does 
the report get transmitted across?


Regards,
Gil. 



The remote still must be either a NJE node or a RJE node/workstation.

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

Re: SPAM: Re: Transfer reports from lpar to lpar

[Gilbert Cardenas]

On Sat, 8 Mar 2008 12:45:28 EST, Ed Finnell <[EMAIL PROTECTED]> wrote:

>Guess if all you got is PFCSKs  DEST='IP:ipaddr' might suffice w/o NJE
>
><<>>
>   DEST=destination
>The destination subparameter for JES2 is one of the following:
>LOCAL|ANYLOCAL
>'IP:ipaddr'
>name
>|  Nn
>|  NnRm
>NnnR
>NnnnRmmm
>NRmm
>|  NnRm
>|  (node,remote)
>nodename.userid
>'nodename.IP:ipaddr'
>
><<>>


I would like to use this option however, if I use the 'IP:ipaddr' the jcl 
reference 
states that a functional subsystem that can process IP-distributed data sets 
sends the data to the specified host system.
Could you please translate what that means.
I see the report in the output queue sitting with a dest of  but how does 
the report get transmitted across?

Regards,
Gil. 

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

Re: SPAM: Re: Transfer reports from lpar to lpar

[Gilbert Cardenas]

On Sat, 8 Mar 2008 09:21:53 -0800, Edward Jaffe 
>The OP indicates that he already has TCP/IP connectivity between all
>LPARs and FTP servers running on each. Therefore, the JES FTP interface
>should be available without any additional configuration. (Though I
>would highly recommend specifying "JESINTERFACELEVEL 2" for the FTP
>server configurations.)
>
>--
>Edward E Jaffe
>Phoenix Software International, Inc
>5200 W Century Blvd, Suite 800
>Los Angeles, CA 90045
>310-338-0400 x318
>[EMAIL PROTECTED]
>http://www.phoenixsoftware.com/


Thank you all for all the great ideas.  Sounds like I am restricted to using 
FTP 
to transfer the report files.

I looked up info on the JESINTERFACELEVEL 2 option and it appears this will 
allow me to pull reports/sysouts that do not match my userid or owner among 
other things.  Does this parameter have to be coded in the TCPIP parameter 
library or can it be specified as a parameter in a batch jcl?

Also can you ftp a report directly from one jes spool to another jes spool or 
do 
I have to put the report in an intermediary dataset and then ftp that file to 
the desired jes spool output?

Regards,
Gil.

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

Re: SPAM: Re: Transfer reports from lpar to lpar

[Ed Finnell]

 
In a message dated 3/8/2008 11:03:41 A.M. Central Standard Time,  r
[EMAIL PROTECTED] writes:

vote for a NJE connection, with routing JECL where appropriate. It's a  
LOT less prone to error than trying to do spool OFFLOAD and  LOAD.

Shared spool may be out for valid reasons.


>>
Guess if all you got is PFCSKs  DEST='IP:ipaddr' might suffice w/o NJE
 
<<>>
   DEST=destination
The destination subparameter for JES2 is one of the following:  
LOCAL|ANYLOCAL 
'IP:ipaddr'
name   
|  Nn 
|  NnRm   
NnnR   
NnnnRmmm   
NRmm   
|  NnRm   
|  (node,remote)  
nodename.userid
'nodename.IP:ipaddr'
 
<<>>







**It's Tax Time! Get tips, forms, and advice on AOL Money & 
Finance.  (http://money.aol.com/tax?NCID=aolprf000301)

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

Re: SPAM: Re: Transfer reports from lpar to lpar

[Edward Jaffe]

Rick Fochtman wrote:
That will make a very reasonable physical connection; the next step is 
to configure software to actually use it. :-)


I vote for a NJE connection, with routing JECL where appropriate. It's 
a LOT less prone to error than trying to do spool OFFLOAD and LOAD.


The OP indicates that he already has TCP/IP connectivity between all 
LPARs and FTP servers running on each. Therefore, the JES FTP interface 
should be available without any additional configuration. (Though I 
would highly recommend specifying "JESINTERFACELEVEL 2" for the FTP 
server configurations.)


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: SPAM: Re: Transfer reports from lpar to lpar

[Rick Fochtman]

-

I haven't been following this but has anyone suggested setting up a CTC 
between the LPAR's. The connection is setup over Escon channels.
 


---
That will make a very reasonable physical connection; the next step is 
to configure software to actually use it. :-)


I vote for a NJE connection, with routing JECL where appropriate. It's a 
LOT less prone to error than trying to do spool OFFLOAD and LOAD.


Shared spool may be out for valid reasons.

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

Re: SPAM: Re: Tapeless backup

[Rick Fochtman]

We have a similar issue in our shop.  The midrange area wants tapeless.  the 
Mainframe side TAPE.

We have a VTS and ATL.  We use the product DRVI to stack the VTS Tape backups 
to an real tape and ship it offsite for DR purposes.  Tape is cheap.  tape can 
survive years in a dusty hole and still be usable.  You can encrypt it.  You 
can send it where it needs to go when it is needed.

Or you can pay a DR site to have a tapeless solution there in case you need it. 
 You just have to figure out how much you want to pay for a disaster.

The only thought I have is:  If you have a tapeless solution how do you get 
your data to DR site should your primary site fail?
 


--
Consider also this: depending on what industry you're in, there may 
exist legal requirements for data archiving and retrieval. I spent my 
last 23 years in an industry where we had a ten-year retrieval 
requirement, imposed by Department of Commerce rules.


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

Re: SPAM: Migration/Coexistence with z/OS 1.10

[Rick Fochtman]

--

Why am I seeing APARs for coexistence or toleration with z/OS 1.10  
that go back to z/OS 1.6 (which is already past EOS)?  I am seeing them 
via ASAP notification.   I saw one for WLM today and I know I saw one for

"sysplex join"  as soon as z/OS 1.10 was previewed and perhaps a couple
of others.  


http://www-03.ibm.com/systems/z/os/zos/support/zos_cmf.html

I know that 1.10 isn't in the table yet since it is only previewed, but even
the z/OS 1.9 table doesn't document lower than z/OS 1.7 as coexisting.  
So how can z/OS 1.6 exist with z/OS 1.10 if it can't with z/OS 1.9?  
 


--
I would surmise, with no facts to back me up, that the affected 
components haven't changed since the 1.6 release. Just a guess.


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

Re: SPAM: Re: new Feb2008 zPOP: Execute Relative Long

[Edward Jaffe]

Rick Fochtman wrote:
Let's all quit trying to second-guess IBM and instead just wait a 
while. I'm certain that there will be additional upgrades as the z/10 
goes through evolution. Let's see what time brings us.


Customer dialog helps influence IBM's design and direction. If customers 
always took a "wait and see" approach to everything "z", IBM might just 
now be coming out with MVS/XA! ;-)


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: SPAM: Abend S013 using ICHDSM00 procedure

[Rick Fochtman]

-


Please, somebody can help me with this:  i tried to use the ICHDSM00 program 
using SYS1.BRODCAST library, then using a DSMON sentences to get RACF report.


so, i get an abend S013 when jcl fails; what are the main reason for this abend?
 



Carlos, you need to tell us more about what you're trying to accomplish. 
Perhaps the RACF list MIGHT be a better place to explore this issue. Can 
you share your JCL and control statements?


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

Re: SPAM: Re: new Feb2008 zPOP: Execute Relative Long

[Rick Fochtman]

---

Why not also allow the EXreg instruction to execute UP TO 8 bytes worth of 
the register contents?  In other words, if you have less than 6 byte 
instructions to execute (say a 2-byte plus a 6-byte instruction) why not allow 
BOTH of them to potentially execute within the single EXreg instruction?  

Then why not also allow an EXreg-multiple instruction to support up to 16 (or 
15) registers worth of instructions preloaded into the registers to operate, 
much like the PDPs of old did?  (Not that slow, of course.)  
 
Or just leave it all alone and be grateful that Ed got his wish.
 


--
Let's all quit trying to second-guess IBM and instead just wait a while. 
I'm certain that there will be additional upgrades as the z/10 goes 
through evolution. Let's see what time brings us.


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

Re: SPAM: Re: Large Page Datasets APAR OA20749

[Rick Fochtman]

---

I am curious about the unintended affect of OA20749.  Do you know if it 
"in general" remove the restriction of non-SMS VSAM being limited to 4GB?
 



I would tend to doubt that. A PAGE file more closely resembles a BDAM 
file, rather than a VSAM cluster. Since VSAM uses relative-byte 
addressing, in the basic form that I learned 20+ years ago, I would 
expect that restriction to 4GB will continue. Wouldn't want to "break 
it" for older clusters.


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

Re: SPAM: Re: SHARE & no handouts(?)

[Rick Fochtman]

--


Handout hogs still roam from room to room grabbing handouts, making >it
   

hard to have enough for the people who actually stay and listen. 
 

Why? Either they are too lazy to download a pdf (or thee won't be 
one). ...

... ... I have watched people sit up front where there
is a greater certainty of getting a handout, receive one, and dash out to
another room.
...
   



It happens.  It also happens that people cannot tell they are in the 
wrong session until they see the handout.  Session descriptions

don't always tell it all.
 


--
Guilty as charged! Sometimes I want to get to multiple sessions that all 
happen to be scheduled at the same time, too. Having the handouts is at 
least better than missing a session entirely.  :-)


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

Re: SPAM: Re: SHARE & no handouts(?)

[Rick Fochtman]

---
What I would love to see happen is that the handouts are on flash drives 
or they could load the handouts on my flash drive so I can take notes 
directly on my computer.

-
Or on CD-ROM or DVD. Then there would be two CD's: handouts and proceedings.

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

Re: SPAM: Re: 256 bytes again

[Rick Fochtman]

-

he guy who precipitated all this extra  discussion was 
trying to get the thread oriented to remembering that the key  length
must be  considered when determining how many blocks will fit on the 
track.
   



That's part of it. There's also code that reads the directory and examines
the key; the buffer length for such code must be 264 rather than 256. 
 


-
BLDL/FIND use a channel programm that still requires a key as well. The 
basic search (IIRC) is:


  CCW   Search-Key-High-Or-Equal
  CCW   Transfer-in-Channel *-8
  CCW   Read-Data

Other CCWs in the program are device-dependant, and AFAIK 3390 SLEDs are 
still supported.


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

Re: SPAM: Re: RACF callable service to check (new) password

[Rick Fochtman]

---


RACF itself has practically all the functionality built-in that you are
looking for.
If I remember correctly, 
- RACF Configuration options allow the retention of (x) previous passwords

within the RACF database.
- password syntax options (length, valid characters, repeat strings, etc.)
- a password validation exit that allows you to perform additional checks
above and beyond those provided by RACF

Once the rules (and/or exit) have been set up, a user who changes the
password will not be able to create a new password that violates these
rules. No need for a homegrown application ...
 


---
This is quite correct. If more restrictive password rules are desired, 
you can also write a password validation exit, wherein you can impose 
any other rules you like. Look in the RACF System Programmers Guide for 
more information.


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

Re: SPAM: ACBUSER

[Rick Fochtman]

Has anyone ever encountered use of (or indeed had cause to use) the ACBUSER
field in a VSAM ACB?

Just curious. 
 


---
I've used it, in the distant past, to point to a VTAM terminal message 
queue. I also used it once in a VSAM application to track a queue of 
buffers to be written to a VSAM cluster.  IIRC, the application 
separated records from a single input file to an indeterminate number of 
output files. VSAM I/O was handled in a subtask and there was a 
WAIT/POST mechanism to tell the VSAM subtask that another buffer was 
ready to write.


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

Re: SPAM: Re: LZW Compression/Expansion

[Rick Fochtman]

Edward Jaffe wrote:


Rick Fochtman wrote:

I can't say for sure what compression algorithm I'll use in the 
updated ARCHIVER; overall performance and some of the technical 
details will still need exploration but I've got some starting points 
now.



Remember that there are high-performance, hardware-assisted 
compression and expansion services available in z/OS.


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a670/23.0

I'm well aware of that, and it's a serious consideration. I need to 
explore, and understand, how those facilities are used.


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

Re: SPAM: Re: LZW Compression/Expansion

[Edward Jaffe]

Rick Fochtman wrote:
I can't say for sure what compression algorithm I'll use in the 
updated ARCHIVER; overall performance and some of the technical 
details will still need exploration but I've got some starting points now.


Remember that there are high-performance, hardware-assisted compression 
and expansion services available in z/OS.


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a670/23.0

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: SPAM: Re: Newbie RACROUTE question: how to *test* authorization?

[Rick Fochtman]

My advice in another message about letting the system do the checking 
still stands.

---
I strongly agree.

Consider that a potential customer may WANT all the logging he can get, 
possibly weeding out dishonest employees, or at least preventing them 
from doing damage and revealing their presence. Other shops, like the 
ones I've been involved with, may want their own complete control. And 
auditors LOVE audit trails, the more complete the better.


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

Re: SPAM: Re: Questions Regarding Disk Cache

[Rick Fochtman]

-
"Virtual Storage Access Method - The Complete Source Book for VSAM File 
Structures" by Ronald K Ferguson.


Now out of box number 2. Mine hasn't got a signature, but it has a 
coffee stain :-)


You mean coffee was around that far back?

My copy was printed in 1982 and I don't think I've touched it since I 
move into this house.


There was another good reference out called "The VSAM Bible"; I forget 
the author since I gave it away about 20 years ago.


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

Re: SPAM from data21.com

[Rick Fochtman]

--


It appears as a reward for posting regarding CA-TPX, I received SPAM from
data21.com trying to sell their product.

Gentlemen from data21.com - not a good idea to SPAM based on posts to this
list.
 


---
Agreed. It qualifies as a high-power turn-off here as well.

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

Re: SPAM from data21.com

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Binyamin Dissen
> Sent: Thursday, February 21, 2008 9:06 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: SPAM from data21.com
> 
> 
> It appears as a reward for posting regarding CA-TPX, I 
> received SPAM from
> data21.com trying to sell their product.
> 
> Gentlemen from data21.com - not a good idea to SPAM based on 
> posts to this
> list.
> 
> --
> Binyamin Dissen <[EMAIL PROTECTED]>

I haven't gotten any from them, but have from some other vendors.

Note to vendors: (1) I'm just a grunt, I don't make purchasing
decisions. (2) I'm old and easily irritated. If you irritate me, I will
remember you. And not in a good light. LEAVE ME ALONE!

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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

Re: SPAM: Re: LZW Compression/Expansion

[Rick Fochtman]

Many thanks to all who responded to my LZW query. I now have a plethora 
of references available, thanks to many helpful responses both onlist 
and offlist.


I can't say for sure what compression algorithm I'll use in the updated 
ARCHIVER; overall performance and some of the technical details will 
still need exploration but I've got some starting points now.


Thanks again to all who helped.

Rick :-)

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

Re: SPAM: Re: COMPRESS QUESTION

[Rick Fochtman]

--


In the last shop I was in, all but one member of the application staff
considered it was "beneath them" to define their own PDS datasets.
They'd just send a request to systems staff, and management said we had
to do it, period.
   



I'd guess that must have been before S-Ox.  These days it would be unusual 
for a sysprog to have allocate authority to an application programmers data 
sets.  In this case, an auditor would be your friend.
 



Not a question of authority; just pure out-and-out laziness, coupled 
with a double dose of stupid pills.



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

Re: SPAM: Re: COMPRESS QUESTION

[Ted MacNEIL]

>In this case, an auditor would be your friend.

No. A compliance officer.

SME: Sets standards with help from compliance.
Auditor: Reports on how much/little is complied with.
Compliance: Enforces standards and ensures deviations are rectified.

Auditors should have no enforcement authority.

-
Too busy driving to stop for gas!

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

Re: SPAM: Re: COMPRESS QUESTION

[Tom Marchant]

On Tue, 19 Feb 2008 11:06:13 -0600, Rick Fochtman wrote:

>In the last shop I was in, all but one member of the application staff
>considered it was "beneath them" to define their own PDS datasets.
>They'd just send a request to systems staff, and management said we had
>to do it, period.

I'd guess that must have been before S-Ox.  These days it would be unusual 
for a sysprog to have allocate authority to an application programmers data 
sets.  In this case, an auditor would be your friend.

-- 
Tom Marchant

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

Re: SPAM: Re: COMPRESS QUESTION

[Rick Fochtman]

It's always best to consider the audience; I got into the habit of 
referring to the 256-byte data portion of the actual record as the 
directory block, ignoring the key and count portions, when talking to 
application folks.
   



Doesn't that confuse them when they need to specify sizes? Or do they add
in a large enough fudge factor that it doesn't cause problems?
 


---
In the last shop I was in, all but one member of the application staff 
considered it was "beneath them" to define their own PDS datasets. 
They'd just send a request to systems staff, and management said we had 
to do it, period. Stupid attitude from stupid managers. Go figure.


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

Re: SPAM: Re: COMPRESS QUESTION

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/18/2008
   at 04:26 PM, Rick Fochtman <[EMAIL PROTECTED]> said:

>It's always best to consider the audience; I got into the habit of 
>referring to the 256-byte data portion of the actual record as the 
>directory block, ignoring the key and count portions, when talking to 
>application folks.

Doesn't that confuse them when they need to specify sizes? Or do they add
in a large enough fudge factor that it doesn't cause problems?
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SPAM: Re: COMPRESS QUESTION

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/18/2008
   at 04:33 PM, "(IBM Mainframe Discussion List)" <[EMAIL PROTECTED]>
said:

>The meaning of the word "size"  depends on 
>whether you mean in virtual storage or stored on a disk track.

That's an additional complication; I was not taking gaps into account.

>In virtual storage, the size of a directory block is 272 bytes  
>(count+key+data),

Well, if you're using BSAM to read the directory then your buffer only
needs room for 256 or 264, depending on whether you're reading the key.
Tho IOB, of course, includes the current or next count area, depending on
the options used.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SPAM: Re: COMPRESS QUESTION

[Rick Fochtman]

-
I now see the source of the communications problem, which was 
exacerbated by Seymour's predilection to post one-word cryptic replies 
or, in the case of his reply to my post, a riddle. The poster wrote 
">Just to clarify: size of dir. block is always 256 B". The meaning of 
the word "size" depends on whether you mean in virtual storage or stored 
on a disk track. In virtual storage, the size of a directory block is 
272 bytes (count+key+data), as I described in my previous post. But if 
stored on a disk track, it depends on the device type but is always a 
lot more than 272, which Seymour had in mind but did not reveal to us. 
The word "block" might (correctly) mean to some the entire stored record 
(count+key+data) while (incorrectly) only the data area to others. This 
confusion has also not been helped by IBM documentation, which sometimes 
refers to a DASD block stored on a track as a "block" and at other times 
a "record".

---
It's always best to consider the audience; I got into the habit of 
referring to the 256-byte data portion of the actual record as the 
directory block, ignoring the key and count portions, when talking to 
application folks. They didn't understand (or want to understand) the 
actual details. When talking to people that know, I generally (not 
always) prefer to speak of directory entries, leaving out the blocking 
details.


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

Re: SPAM: Re: COMPRESS QUESTION

[(IBM Mainframe Discussion List)]

 
 
In a message dated 2/18/2008 11:18:35 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:
>I THINK the difference arises because of the key. While many of us tend  
to ignore the key when referring to directory block, Seymour chooses NOT  
to ignore this value.
 
I now see the source of the communications problem, which was exacerbated  by 
Seymour's predilection to post one-word cryptic replies or, in the case of  
his reply to my post, a riddle.  The poster wrote ">Just to clarify:  size of 
dir. block is always 256 B".  The meaning of the word "size"  depends on 
whether you mean in virtual storage or stored on a disk  track.  In virtual 
storage, 
the size of a directory block is 272 bytes  (count+key+data), as I described 
in my previous post.  But if stored on a  disk track, it depends on the device 
type but is always a lot more than 272,  which Seymour had in mind but did 
not reveal to us.  The word "block"  might (correctly) mean to some the entire 
stored record (count+key+data)  while (incorrectly) only the data area to 
others.  This confusion has also  not been helped by IBM documentation, which 
sometimes refers to a DASD block  stored on a track as a "block" and at other 
times 
a "record".
 
Bill  Fairchild





**Ideas to please picky eaters. Watch video on AOL Living.  
(http://living.aol.com/video/how-to-please-your-picky-eater/rachel-campos-duffy/
2050827?NCID=aolcmp0030002598)

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

Re: SPAM: Re: COMPRESS QUESTION

[Rick Fochtman]

<>OK, I'll bite. A PDS directory block has an 8-byte count area, an
8-byte key area, and a 256-byte data area.
Aha!



<>When is a directory block not 256 bytes long?




<>When 8 is not equal to 0. Which is why the number of directory 
blocks per

3390 track is what it is and not larger.

I admit that you sucked me into your guessing game of wits once more. 
Since
8 is always "not equal to 0", therefore a PDS directory block always 
has a
data area that is not 256 bytes. Since this is impossible, I am now 
supposed
to plead with you to reveal this latest conundrum of yours. You can 
explain
in plain language what I am overlooking if you wish, but I give up on 
the
guessing game. You win again, Seymour, as you always must. Oh please, 
please

tell me the secret. Pretty please with sugar on top.




I THINK the difference arises because of the key. While many of us tend 
to ignore the key when referring to directory block, Seymour chooses NOT 
to ignore this value.


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

Re: SPAM: Re: OT: D/R situation in an Airliner

[Rick Fochtman]

--


D/R is just not an option at  10K (or more)  meters up.

The closest time I ever got to fly a plane was in the Caribbean
between islands. My knuckles were wrapped around a steering wheel so
tightly that my hands were white. The pilot was right there but it is
a scary deal to fly a twin engine plane at 500 feet let alone any
higher. Congrats.

   


You sound acrophobic.  Perhaps you should have asked the pilot to
let you try at 50 feet where you might have been more comfortable.
 


---
That's downright cruel, Gil.  :-)

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

Re: SPAM: Re: Linux zSeries questions

[Rick Fochtman]

---

From what I've seen in looking at various bits and pieces of source 
code, PL/S or its replacement(s) have been most heavily used in the MVS 
code; not so much in OS/360, except SMP.
   



Do you count BSL as being PL/S? It was heavily used in OS/360, for TSO.
 


--
I can't speak for that, since I've never looked at TSO source. I think 
it's reasonable to add BSL to the PL/S set of languages.


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

Re: SPAM: Re: COMPRESS QUESTION

[(IBM Mainframe Discussion List)]

 
 
In a message dated 2/18/2008 10:09:09 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

>OK,  I'll bite.  A PDS directory block has an 8-byte count area, an  
>8-byte  key area, and a 256-byte data area.  

Aha!

>When is a directory block not 256 bytes  long?

When 8 is not equal to 0. Which is why the number of directory  blocks per
3390 track is what it is and not larger.

I admit that you sucked me into your guessing game of wits once more.   Since 
8 is always "not equal to 0", therefore a PDS directory block  always has a 
data area that is not 256 bytes.  Since this is  impossible, I am now supposed 
to plead with you to reveal this latest conundrum  of yours.  You can explain 
in plain language what I am overlooking if you  wish, but I give up on the 
guessing game.  You win again, Seymour, as you  always must.  Oh please, please 
tell me the secret.  Pretty please  with sugar on top.

 
Bill  Fairchild

"An important art of politicians is to find new names for  institutions which 
under old names have become odious to the people."  [Talleyrand]



**Ideas to please picky eaters. Watch video on AOL Living.  
(http://living.aol.com/video/how-to-please-your-picky-eater/rachel-campos-duffy/
2050827?NCID=aolcmp0030002598)

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

Re: SPAM: Re: COMPRESS QUESTION

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/15/2008
   at 06:53 PM, "(IBM Mainframe Discussion List)" <[EMAIL PROTECTED]>
said:

>OK, I'll bite.  A PDS directory block has an 8-byte count area, an 
>8-byte  key area, and a 256-byte data area. 

Aha!

>When is a directory block not 256 bytes long?

When 8 is not equal to 0. Which is why the number of directory blocks per
3390 track is what it is and not larger.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SPAM: Re: Linux zSeries questions

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


[EMAIL PROTECTED] (Rick Fochtman) writes:
> IMHO, the programming language, whether for applications or operating
> systems, is unimportant, PROVIDED that all the necessary functions can
> be provided in an efficient manner. The important matter is whether
> the desired end can be reached efficiently or not. There lots of ways
> to drive from Chicago to Houston; which route best serves your needs?

lots of past posts discussing common C language environment having a
paradigm that promotes buffer length programming errors.
http://www.garlic.com/~lynn/subintegrity.html#overflow

up threw 1999, (c-language related) buffer overflow exploits accounted
for the majority of all internet related vulnerabilities.

the majority of these buffer overflow exploits wouldn't happen in PLI
and PASCAL. They also wouldn't occur in 360 assembler conforming to
standard system services (because os/360 system services avoided buffer
length shortcoming convention that was part of common C language
programming convention).

in the early part of this decade ... there was a big increase in
internet-related exploits involving the greater use in some platforms
and/or associated (personal) applications which would automatically
execute scripts arriving over the network. this increased until
automagic script execution exploits were about equal to buffer length
related exploits.

a couple past posts related to doing frequency analysis on the CVE
vulnerability database ... and having difficulty categorizing exploits
... and lobbying the CVE interests to improve the strucuture/nature of
CVE reports.
http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
http://www.garlic.com/~lynn/2005c.html#28 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#32 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2007q.html#20 Hackers Attack Apps While Still in 
Development

some amount of the problem was that common personal computer platforms
had started out on stand-alone environment with possible terminal
emulation connection
http://www.garlic.com/~lynn/subnetwork.html#emulation

and then LAN connections were introduced for local departmental
networking. The automatic scripting grewup (as purely content enrichment
enhancement) in a purely non-hostile environment.

The problem was treating the LAN connections, in a purely non-hostile
departmental networking environment, as the same as LAN connections in
the extremely hostile internet networking environment ... and not having
evolved the appropriate countermeasures for the wide variety of possibly
attacks.

for other drift, recent reference to the cms xmas exec 
http://www.garlic.com/~lynn/2007u.html#87 CompUSA to Close after Jan. 1st 2008
http://www.garlic.com/~lynn/2008c.html#2 folklore indeed

on bitnet 
http://www.garlic.com/~lynn/subnetwork.html#bitnet

a year before the morris worm 
http://en.wikipedia.org/wiki/Morris_worm

on the internet
http://www.garlic.com/~lynn/subnetwork.html#internet

and for other topic drift ... attempted reproduction (in html) of an
old '81 3279 xmas tree exec
http://www.garlic.com/~lynn/2007v.html#54 An old fashioned Christmas
http://www.garlic.com/~lynn/2007v.html#55 An old fashioned Christmas
http://www.garlic.com/~lynn/2007v.html#56 An old fashioned Christmas

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

Re: SPAM: Re: DFSMS APAR OA22738 - IGD17295I

[Rick Fochtman]

It seems that IBM is attacking the symptom not the problem. Since PDSEs 
are only allowed to be single version, why not just FORCE the vol-count 
to be 1 and issue a message STATING this was done if the dynamic 
allocation requests/allows allocation of more than one volume?

---
Wouldn't that be done best in a Allocation exit?

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

Re: SPAM: Re: Linux zSeries questions

[Rick Fochtman]

-
Mark Post wrote:


On Sat, Feb 16, 2008 at  5:14 PM, in message
   


<[EMAIL PROTECTED]>, Ed Gould
<[EMAIL PROTECTED]> wrote: 
-A whole mess of drivel completely out of touch with reality-


Sad to see that his general level of coherency and intelligence hasn't risen 
any over the last 6-7 years.

 


On Feb 16, 2008, at 1:21 AM, Jim Elliott, IBM wrote:
   



Jim, you were way too polite.  If you have to tell someone you're flaming them, 
you're not doing it right.  :)  Then again, I'm not sure Ed would ever figure 
it out, even with a warning.  Just do what I (and several others) did 6.5 years 
ago, and just kill-file the poor slob.
 



I have to admit that I disagree with Ed far more often than I agree, but 
he does make one significant point: security. At best, Windoze security 
is abysmal; Linux and Unix security aren't really bad, but there's a lot 
of room for improvement. z/OS security is far and away more 
comprehensive and robust than any of the "smaller platform" security 
mechanisms. That's one of the biggest reasons for using z/OS in 
security-conscious environments, such as banking and financial 
management. Many health-care providers and insurers also use z/OS, where 
security and privacy protection are important considerations.


IMHO, the programming language, whether for applications or operating 
systems, is unimportant, PROVIDED that all the necessary functions can 
be provided in an efficient manner. The important matter is whether the 
desired end can be reached efficiently or not. There lots of ways to 
drive from Chicago to Houston; which route best serves your needs?


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

Re: SPAM: Need Urgent Help...Sorry for this post.

[Rick Fochtman]

See if you can find Ira Nitzberg in the Manhattan phone book. Tell him I 
sent you.


Howard Rifkind wrote:


Hello folks;

Sorry to post this message like this but it is urgent.

Yesterday at 1500 the management who I work for laid
me off, eliminated my position … whatever it is I’m
now out of a job.  They said that there wasn’t
anything left to do on the mainframe being it’s life
will end in 6/30/2008.  Some severance pay but not
that much.

Would have been nice if they would have told me this
and given me until June to look around for a new
position being how tight things are now on the
mainframe side.

The mainframe is being elimated on June 30, 2008 and I
was the last systems programmer in the house.  They
also let one other person go, he was a mainframe
scheduler.  I have some Novell/Console 1/Imanager
experience and can find my way around Linux but not an
expert.

Installed z/OS 1.4 – CICS TS 2.3  Installed and ran
z/VM 4.4.

Looking for work in the New York/New Jersey Metro
area…anyone know of anything out there or a real good
head hunter?  If so please let me know off line.

Saw Dice posting, 15 postings for 3 or so jobs.

Again sorry about this post but I need help.

Thanks



 

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SPAM: Re: COMPRESS QUESTION

[(IBM Mainframe Discussion List)]

 
 
In a message dated 2/15/2008 3:07:03 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Re: SPAM: Re: COMPRESS QUESTION

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/14/2008
   at 03:12 PM, "R.S." <[EMAIL PROTECTED]> said:

>Just to clarify: size of dir. block is always 256 B,

No.

>but the size of entry is varying.

Correct.

>The longest entries are for load modules,

Perhaps at your shop.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SPAM: Re: COMPRESS QUESTION

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/14/2008
   at 07:49 AM, Tom Marchant <[EMAIL PROTECTED]> said:

>Beats me, but if you'd looked at a dump of a pds directory, you'd know
>this  isn't true.

Don't confuse him with facts.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SPAM: Re: COMPRESS QUESTION

[Tom Marchant]

On Fri, 15 Feb 2008 09:05:59 EST, IBM Mainframe Discussion List wrote:
>
>The reason that a PDS directory entry that describes a load module is  larger
>than a directory entry for other types of data is that load modules store
>info in the entry that is used by program fetch when the load module is being
>loaded.

It's called the user data field.  ISPF also uses it

>I don't remember the exact format of a directory entry, but there  is
>at least one TTR stored in the entry as well as part of a byte telling how
>many halfwords of the directory entry are used for storing such data.

Yes.  5 bits, allowing for up to 31 halfwords.

>Non-load modules have all these bytes containing zero.

ITYM bits.  Members with no user data.  This is what defines the length of the 
entry.  12 bytes plus as many halfwords as specified

>Some non-IBM  products use
>this feature of a directory entry to store useful info, like date  last used 
>for
>the member.  So non-load module entries will be larger than  the mininum
>length (12 bytes, I think) if such software is installed and  managing that 
PDS.
>There is a DSECT describing the directory entry  somewhere in
>SYS1.MACLIB/MODGEN, I believe.

IHAPDS

-- 
Tom Marchant

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

Re: SPAM: Re: COMPRESS QUESTION

[(IBM Mainframe Discussion List)]

 
 
In a message dated 2/14/2008 11:06:10 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:
>In 35+ years, I've never seen a directory 
block count stored  anywhere; only the count of blocks used. The classic 
method of counting the  total of directory blocks is to open the 
directory as a sequential dataset  and read until EOF is encountered.
 
I also have never seen the directory block count stored anywhere in a  vani
lla IBM system.  Perhaps the poster was referring to a non-IBM use of  some 
reserved field in the Format 1 DSCB.  Also I have never heard of  storing the 
count of blocks used anywhere.  Where is this piece of data  stored in vanilla 
IBM 
metadata?  The Format 1 DSCB has a one-byte field for  the number of bytes 
used in the last directory block and a 3-byte field for the  TTR of the last 
used block in the entire data set.  Perhaps you were  thinking of one of those 
fields.
 
The reason that a PDS directory entry that describes a load module is  larger 
than a directory entry for other types of data is that load modules store  
info in the entry that is used by program fetch when the load module is being  
loaded.  I don't remember the exact format of a directory entry, but there  is 
at least one TTR stored in the entry as well as part of a byte telling how  
many halfwords of the directory entry are used for storing such data.   
Non-load 
modules have all these bytes containing zero.  Some non-IBM  products use 
this feature of a directory entry to store useful info, like date  last used 
for 
the member.  So non-load module entries will be larger than  the mininum 
length (12 bytes, I think) if such software is installed and  managing that 
PDS.  
There is a DSECT describing the directory entry  somewhere in 
SYS1.MACLIB/MODGEN, I believe.  Or maybe I saw this documented  in a logic 
manual.
 
Bill  Fairchild
Rocket Software

"The truth which makes men free is for the  most part the truth which men 
prefer not to hear." [Jim Bishop; 1955; The Day  Lincoln Was Shot]





**The year's hottest artists on the red carpet at the Grammy 
Awards. Go to AOL Music.  
(http://music.aol.com/grammys?NCID=aolcmp0030002565)

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

Re: SPAM: Re: COMPRESS QUESTION

[Vernooy, C.P. - SPLXM]

"Rick Fochtman" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> -
> 
> >I think when the space available on the last track of the directory
is less than the blocksize of the file, the space is not used.
> >  
> >
> -
> On the rare occaision that a complete member doesn't fill a full
block. 
> and the space after the directory is large enough to hold it, that
space 
> WILL be used by inserting the short block.

I don't think it is rare: every member containing 10 or 20 lines of JCL
(quite typical) will be in a short block of its own, assuming a decent
blocksize. For a small JCL PDS, you could have your directory and
members residing on 1 track.

Kees.
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

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

Re: SPAM: SNA Printer driver / tester

[Matthew Stitt]

You might also take a look at the InfoPrint Server product.  I has
components which can translate PDF, PS, AFP, etc.  Also has a piece which
can talk to SNA attached printers.


On Thu, 14 Feb 2008 11:31:35 -0600, Rick Fochtman <[EMAIL PROTECTED]> wrote:

>
>
>>I have been asked to provide a software tool capable of sending "whatever"
>>documents, reports or just strings of text to one among a variety of SNA
>>printer types defined in VTAM.
>>
>>The purpose it to have a tool to help isolate printing problems arising from
>>often very subtle inconsistencies among various SNA printer emulations.
>>
>>Before I start writing a VTAM appl from scratch I'd like to know if I'm
about to
>>reinvent the wheel. Searching this forum, the CBTTAPE and Google is
>>inconclusive. Either there is nothing to be found or I am using the wrong
>>search criteria.
>>
>>Perhaps there is indeed nothing but you might know about some Assembler
>>source code (OS/390, z/OS 1.4 level) in the public domain (or in your hands),
>>containing a lot of VTAM error handling code, I could use as a base.
>>
>>
>
>Check with MacKinney Systems; they might have a product you can use, and
>you might be able to work out acceptable terms.
>
>Also, try and find an old copy of IBM's DSPRINT product. I haven't seen
>it since the late 70's but it might provide a framework. It was
>distributed in source form.
>

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

Re: SPAM: SNA Printer driver / tester

[Rick Fochtman]

I have been asked to provide a software tool capable of sending "whatever" 
documents, reports or just strings of text to one among a variety of SNA 
printer types defined in VTAM.


The purpose it to have a tool to help isolate printing problems arising from 
often very subtle inconsistencies among various SNA printer emulations.


Before I start writing a VTAM appl from scratch I'd like to know if I'm about to 
reinvent the wheel. Searching this forum, the CBTTAPE and Google is 
inconclusive. Either there is nothing to be found or I am using the wrong 
search criteria.


Perhaps there is indeed nothing but you might know about some Assembler 
source code (OS/390, z/OS 1.4 level) in the public domain (or in your hands), 
containing a lot of VTAM error handling code, I could use as a base. 
 



Check with MacKinney Systems; they might have a product you can use, and 
you might be able to work out acceptable terms.


Also, try and find an old copy of IBM's DSPRINT product. I haven't seen 
it since the late 70's but it might provide a framework. It was 
distributed in source form.


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

Re: SPAM: Re: COMPRESS QUESTION

[Rick Fochtman]

-


I think when the space available on the last track of the directory is less 
than the blocksize of the file, the space is not used.
 


-
On the rare occaision that a complete member doesn't fill a full block. 
and the space after the directory is large enough to hold it, that space 
WILL be used by inserting the short block.


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

Re: SPAM: Re: COMPRESS QUESTION

[Rick Fochtman]

---


Then, how come I can zap the directory count up to a multiple of 44, and have 
them available.

I also saw some (old) documentation stating this.
 



You should share that with us. In 35+ years, I've never seen a directory 
block count stored anywhere; only the count of blocks used. The classic 
method of counting the total of directory blocks is to open the 
directory as a sequential dataset and read until EOF is encountered. And 
I'm sure we'd like to see, or know about, this old documentation you 
mention.


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

Re: SPAM: Re: COMPRESS QUESTION

[R.S.]

Tom Marchant wrote:

On Wed, 13 Feb 2008 19:33:08 -0600, Ed Gould wrote:

I think that load module directory entries are larger than say FB
(source) type directory entries.
I know we are talking about FB type libraries in the thread.


The size of the directory entries is irrelevant to this discussion. 
All PDS directories are 256 byte blocks.


Just to clarify: size of dir. block is always 256 B, but the size of 
entry is varying.
The longest entries are for load modules, the shortest for "text" 
members without ISPF stats.


--
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.2008 r. kapita zakadowy BRE Banku SA  wynosi 
118.642.672 zote i zosta w caoci wpacony.

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

Re: SPAM: Re: COMPRESS QUESTION

[Tom Marchant]

On Wed, 13 Feb 2008 21:48:10 +, Ted MacNEIL wrote:

>>Eh?  The directory contains the number of blocks that is specified.  The 
remainder of the last directory track is available for use by PDS members.
>
>Then, how come I can zap the directory count up to a multiple of 44, and 
have them available.

Beats me, but if you'd looked at a dump of a pds directory, you'd know this 
isn't true.

>
>I also saw some (old) documentation stating this.

I doubt it.  Show it if you have it.  Otherwise, I'll have to assume that you 
are 
just blowing smoke again.
>-
>Too busy driving to stop for gas!

Make that too busy talking to check your "facts".

-- 
Tom Marchant

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

Re: SPAM: Re: COMPRESS QUESTION

[Tom Marchant]

On Wed, 13 Feb 2008 19:33:08 -0600, Ed Gould wrote:
>
>I think that load module directory entries are larger than say FB
>(source) type directory entries.
>I know we are talking about FB type libraries in the thread.

The size of the directory entries is irrelevant to this discussion. 
All PDS directories are 256 byte blocks.

-- 
Tom Marchant

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

Re: SPAM: Re: COMPRESS QUESTION

[Ed Gould]

On Feb 13, 2008, at 3:48 PM, Ted MacNEIL wrote:

Eh?  The directory contains the number of blocks that is  
specified.  The remainder of the last directory track is available  
for use by PDS members.


Then, how come I can zap the directory count up to a multiple of  
44, and have them available.


I also saw some (old) documentation stating this.
-
Too busy driving to stop for gas!


Ted:

I think that load module directory entries are larger than say FB  
(source) type directory entries.

I know we are talking about FB type libraries in the thread.

Ed

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

Re: SPAM: Re: COMPRESS QUESTION

[Richard Peurifoy]

Ted MacNEIL wrote:

Eh?  The directory contains the number of blocks that is specified.  The 
remainder of the last directory track is available for use by PDS members.


Then, how come I can zap the directory count up to a multiple of 44, and have 
them available.

I also saw some (old) documentation stating this.


Following is a track dump of a PDS with 1 directory block allocated,
and 1 member stored in it. The member immediately follows the directory
block. Could it be that you used PDS from the CBT tape to add directory
blocks?

Note: I truncated the right half of the dump to avoid line wrap.


FDR522   COUNT FIELD 038E000501080100

00    

00   001EE3C5 E2E34040 4040 030216028044 
20       
  LINES 40-E0 SAME AS ABOVE
FDR522   COUNT FIELD 038E00050200 -- END OF FILE

FDR522   COUNT FIELD 038E00050350

00   E3C5E2E3 40404040 40404040 4040404040404040 40404040
20   40404040 40404040 40404040 4040404040404040 40404040
40   40404040 40404040 40404040 40404040
FDR522   COUNT FIELD 038E00050400 -- END OF FILE


--
Richard

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

Re: SPAM: Re: COMPRESS QUESTION

[Scott Rowe]

How come I can create a 1 track PDS with 1 directory block and store a member 
in it?

>>> Ted MacNEIL <[EMAIL PROTECTED]> 2/13/2008 4:48 PM >>>
>Eh?  The directory contains the number of blocks that is specified.  The 
>remainder of the last directory track is available for use by PDS members.

Then, how come I can zap the directory count up to a multiple of 44, and have 
them available.

I also saw some (old) documentation stating this.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SPAM: Re: COMPRESS QUESTION

[Ted MacNEIL]

>Eh?  The directory contains the number of blocks that is specified.  The 
>remainder of the last directory track is available for use by PDS members.

Then, how come I can zap the directory count up to a multiple of 44, and have 
them available.

I also saw some (old) documentation stating this.
-
Too busy driving to stop for gas!

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

Re: SPAM: Re: COMPRESS QUESTION

[Tom Marchant]

On Wed, 13 Feb 2008 16:03:30 +, Ted MacNEIL wrote:
>
>There are 44 directory blocks per track.

Well, there are 45 directory blocks per track on a 3390, except that the last 
track can only hold up to 44.

>They are all formatted, but only the number you specify are addrressible.

Eh?  The directory contains the number of blocks that is specified.  The 
remainder of the last directory track is available for use by PDS members.

-- 
Tom Marchant

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

Re: SPAM: Re: COMPRESS QUESTION

[R.S.]

John Dawes wrote:

Besides re-allocating the dsn what else should I do to I tackle this problem?
   
  Current Allocation
 Allocated tracks  . : 5,000  
 Allocated extents . : 16 
 Maximum dir. blocks : 400
  
  
Current Utilization   
 Used tracks . . . . : 1,643  
 Used extents  . . . : 3  
 Used dir. blocks  . : 25 
 Number of members . : 425
  
Am I intepreting something wrong?  It shows that the dsn was using 1,643 tracks even though it allocated 5,000 trakcs.  How should I fix the discrepancy between the "Current Allocation"   and "Current Utilization" 


There is no discrepancy between "Current Allocation" and "Current 
Utilization". This is MVS specific: allocated space does not mean used 
space. That's why we have both "Current's".
It's like fuel tank - sometimes it's half empty. However when filling 
up, it cannot obtain secondary extents 






--
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.2008 r. kapita zakadowy BRE Banku SA  wynosi 
118.642.672 zote i zosta w caoci wpacony.

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

Re: SPAM: Re: COMPRESS QUESTION

[Ted MacNEIL]

>If you aren't going to add a lot of new members, drop the 400 down to 30-50.

There are 44 directory blocks per track.
They are all formatted, but only the number you specify are addrressible.
Also, I wouldn't worry about having 400.
It takes less than 10 tracks.

-
Too busy driving to stop for gas!

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

Re: SPAM: Re: COMPRESS QUESTION

[Ted MacNEIL]

>I have allocated a larger pds and it seemed to have worked.  Just scratching 
>my head as to why when I ran the compress batch job it didn't do anything, 
>leaving the allocated extents at 16.

Compress does not release unused space.
You need to free it with a utility.

-
Too busy driving to stop for gas!

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

Re: SPAM: Re: COMPRESS QUESTION

[Rick Fochtman]

Also, get PDS 8.6 as I suggested. You won't regret it.
-

BIG AMEN to that, too. I consider it to be the most useful Systems 
Programming tool on the entire CBT site!


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

Re: SPAM: Re: COMPRESS QUESTION

[Rick Fochtman]

---


Besides re-allocating the dsn what else should I do to I tackle this problem?
  
 Current Allocation
Allocated tracks  . : 5,000  
Allocated extents . : 16 
Maximum dir. blocks : 400
 
 
Current Utilization   
Used tracks . . . . : 1,643  
Used extents  . . . : 3  
Used dir. blocks  . : 25 
Number of members . : 425
 
Am I intepreting something wrong?  It shows that the dsn was using 1,643 tracks even though it allocated 5,000 trakcs.  How should I fix the discrepancy between the "Current Allocation"   and "Current Utilization"  
 



Why do you consider it a "discrepancy"?

Lots of PDS's have some unused space; taking another extent is an 
expensive process, even with SMS management.


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

Re: SPAM: Re: COMPRESS QUESTION

[Rick Fochtman]

-

 The member had already 2,304 lines in it.  
  
 I have allocated a larger pds and it seemed to have worked.  Just scratching my head as to why when I ran the compress batch job it didn't do anything, leaving the allocated extents at 16.
 



1. IEBCOPY simple compress will not release unused extents. Look at the 
number of used extents. To release empty extents, try using ISPF 3.4.


2. Is the program writing the report multiple times?  That would account 
for the difference between PS dataset and PDS member sizes. When a 
sequential file is re-opened, it starts back at the beginning; but a new 
PDS member starts at the end of the last member. And since in this 
situation you would have the same member name, you might have multiple 
copies of the report and the directory pointer would indicate only the 
last occurence. Just for grins, try writing the report to SYSOUT and see 
how many copies you get.


I've seen this behaviour before, when the programmer (improperly) 
PERFORMed the reporting paragraph(s) from within a loop.


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

Re: SPAM: Re: COMPRESS QUESTION

[Vernooy, C.P. - SPLXM]

"John Dawes" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Besides re-allocating the dsn what else should I do to I tackle this
problem?
>
>   Current Allocation
>  Allocated tracks  . : 5,000  
>  Allocated extents . : 16 
>  Maximum dir. blocks : 400
>   
>   
> Current Utilization   
>  Used tracks . . . . : 1,643  
>  Used extents  . . . : 3  
>  Used dir. blocks  . : 25 
>  Number of members . : 425
>   
> Am I intepreting something wrong?  It shows that the dsn was using
1,643 tracks even though it allocated 5,000 trakcs.  How should I fix
the discrepancy between the "Current Allocation"   and "Current
Utilization"  

John, I don't understand your question: what do you want to fix?

The dataset has allocated 5000 tracks, 1643 tracks used and 3347 tracks
free for you to write into. If you need to write more, the dataset needs
to extend, but it cannot because it already has 16 extents and a PDS
cannot go multivolume. Therefor you need to allocate a larger dataset.

Kees.
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

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

Re: SPAM: Re: COMPRESS QUESTION

[Richards, Robert B.]

John,

How often do you update it? If quite a lot, leave it alone. If once a
year, reduce it. Same thing applies to the # of directory blocks. If you
aren't going to add a lot of new members, drop the 400 down to 30-50.

Also, get PDS 8.6 as I suggested. You won't regret it.

Bob


-
Robert B. Richards(Bob)   
US Office of Personnel Management
1900 E Street NW Room: BH04L   
Washington, D.C.  20415  
Phone: (202) 606-1195  
Email: [EMAIL PROTECTED] 
-

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of John Dawes
Sent: Wednesday, February 13, 2008 8:32 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: SPAM: Re: COMPRESS QUESTION

Besides re-allocating the dsn what else should I do to I tackle this
problem?
   
  Current Allocation
 Allocated tracks  . : 5,000  
 Allocated extents . : 16 
 Maximum dir. blocks : 400
  
  
Current Utilization   
 Used tracks . . . . : 1,643  
 Used extents  . . . : 3  
 Used dir. blocks  . : 25 
 Number of members . : 425
  
Am I intepreting something wrong?  It shows that the dsn was using 1,643
tracks even though it allocated 5,000 trakcs.  How should I fix the
discrepancy between the "Current Allocation"   and "Current Utilization"

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

Re: SPAM: Re: COMPRESS QUESTION

[John Dawes]

Besides re-allocating the dsn what else should I do to I tackle this problem?
   
  Current Allocation
 Allocated tracks  . : 5,000  
 Allocated extents . : 16 
 Maximum dir. blocks : 400
  
  
Current Utilization   
 Used tracks . . . . : 1,643  
 Used extents  . . . : 3  
 Used dir. blocks  . : 25 
 Number of members . : 425
  
Am I intepreting something wrong?  It shows that the dsn was using 1,643 tracks 
even though it allocated 5,000 trakcs.  How should I fix the discrepancy 
between the "Current Allocation"   and "Current Utilization"  

"Vernooy, C.P. - SPLXM" <[EMAIL PROTECTED]> wrote:
  "John Dawes" wrote in message
news:<[EMAIL PROTECTED]>...
> Rick,
> 
> The member had already 2,304 lines in it. 
> 
> I have allocated a larger pds and it seemed to have worked. Just
scratching my head as to why when I ran the compress batch job it didn't
do anything, leaving the allocated extents at 16.
> 


John,

Compress only compresses the data in the dataset, moves data to the
front and leaves all free space at the end. It does not change the size
of the dataset.

Kees.
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

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


   
-
Get the name you always wanted with the new y7mail email address.

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

Re: SPAM: Re: COMPRESS QUESTION

[Vernooy, C.P. - SPLXM]

"John Dawes" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Rick,
>
>   The member had already 2,304 lines in it.  
>
>   I have allocated a larger pds and it seemed to have worked.  Just
scratching my head as to why when I ran the compress batch job it didn't
do anything, leaving the allocated extents at 16.
> 


John,

Compress only compresses the data in the dataset, moves data to the
front and leaves all free space at the end. It does not change the size
of the dataset.

Kees.
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

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

Re: SPAM: Re: COMPRESS QUESTION

[John Dawes]

Rick,
   
  The member had already 2,304 lines in it.  
   
  I have allocated a larger pds and it seemed to have worked.  Just scratching 
my head as to why when I ran the compress batch job it didn't do anything, 
leaving the allocated extents at 16.

Rick Fochtman <[EMAIL PROTECTED]> wrote:
  

>>Hallo To all
>>
>> A batch job abended on a IEC032I E37-04. The job was trying to write out to 
>> a member in a PDS library. I checked the status of the library and it showed 
>> that it had the following allocation:
>>
>> Current Allocation
>> Allocated tracks . : 5,000
>> Allocated extents . : 16
>> Maximum dir. blocks : 400
>>
>>
>>Current Utilization
>> Used tracks . . . . : 958
>> Used extents . . . : 1
>> Used dir. blocks . : 25
>> Number of members . : 425
>>
>>I executed a compress (via batch successfully). However, when I perform an 
>>"I" it shows the same statistics. Is there something else that I am supposed 
>>to do even though I compressed the library?
>>
>> Thanks in advance for your replies to my post.
>> 
>>
--
How big is the member you're trying to write into the PDS? Try writing 
it to a BIG sequential file, just to get a size value.

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


   
-
Make the switch to the world's best email. Get the new Yahoo!7 Mail now.

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

Re: SPAM: Re: JES2 NJE question: SNA(CTC) vs. TCPIP

[Rick Fochtman]

--
IMO, setting up the TCPIP parms is easier than setting up a VTAM cross 
domain. Also, in my case, getting the CTCs "cross connected"  between 
the LPARs in the HCD is a bit mind numbing. However, I still need the  
cross domain for TSO traffic.

-
Having set up CTC's in 2-way, 3-way and 4-way connections, I have to 
admit it's not really so mind numbing to me. A pad of 4x4 graph paper 
makes a wonderful planning aid. :-) Now a 5-way can be a real challenge! 
Actually, by drawing it out, it can get a LOT easier. Actually drew out 
a 9-way once, for a customer who shall remain unnamed. Visualization 
helps IMMENSELY.


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

Re: SPAM: Re: COMPRESS QUESTION

[Rick Fochtman]

Hallo To all

 A batch job abended on a IEC032I E37-04.  The job was trying to write out to a 
member in a PDS library.  I checked the status of the library and it showed 
that it had the following allocation:

 Current Allocation
Allocated tracks  . : 5,000
Allocated extents . : 16
Maximum dir. blocks : 400


Current Utilization
Used tracks . . . . : 958
Used extents  . . . : 1
Used dir. blocks  . : 25
Number of members . : 425

I executed a compress (via batch successfully).  However, when I perform an "I" 
it shows the same statistics.  Is there something else that  I am supposed to do even 
though I compressed the library?

 Thanks in advance for your replies to my post.
   


--
How big is the member you're trying to write into the PDS? Try writing 
it to a BIG sequential file, just to get a size value.


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

Re: SPAM: Two COBOL questions

[Rick Fochtman]

--:


Both questions regard COBOL

1. JCL EXEC ...,PARM='parameter'
Can I read data from PARM field in EXEC statement ?
Any ACCEPT ?


-
Can't answer; never learned COBOL.

--


2. Dynamic allocation
Can I use permanent dataset without DDNAME ?
In other words can I specify dataset name instead of ddname ?


-
No. But you CAN make use of the DYNAM subroutine, from the CBT site. 
Works very well.


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