Y2K Weather Report # 8 - A Y2K spring. 
Author Message
 Y2K Weather Report # 8 - A Y2K spring.


Quote:
>> Moral, spelled out for those who might be analogy-impaired:
>>   Some of us do have a sufficient sense of morality and ethics such
>> that there are some low-lifes we wouldn't work for regardless of
>> the possible rewards.
>ow does a spam posting possibly transcend to mean that a person is
>without sense of morality or ethics? Excuse me for saying but that is a
>REALLY REALLY big s-t-r-e-t-c-h. My 2 cents....

Spamming is stealing from everybody else on the net.  Some people
won't work for thieves.

Note followups.

Seth



Tue, 12 Oct 1999 03:00:00 GMT  
 Y2K Weather Report # 8 - A Y2K spring.

Quote:


>>2) I would work for a spammer, given the right conditions.  What is your
>>correlation between spammers and lack of good opportunities for us?  I
>>can see none.  Regardless of their posting habits, if they had a
>>position that fits your needs better/equal to any other, why would you
>>not take it?  Seems rather unwise to take your stance/view on this to
>>me.

>How about a very slight change:

>"I would work for a con man, given the right conditions.  What is your
>correlation between con man and lack of good opportunities for us?  I
>can see none.  Regardless of their predatory habits, if they had a
>position that fits your needs better/equal to any other, why would you
>not take it?  Seems rather unwise to take your stance/view on this to
>me."

>Moral, spelled out for those who might be analogy-impaired:
>  Some of us do have a sufficient sense of morality and ethics such
>that there are some low-lifes we wouldn't work for regardless of
>the possible rewards.

While spammers are annoying, aggravating and display poor netiquitte, they
are, unlike con men, perfoming a perfectly legal activity; although I can
actually justify making spamming illegal.

A better analogy would be whether one would go to work for a {*filter*}ographer.
Personally, my sense of ethics & m{*filter*}values would never allow me to work for
a {*filter*}ographer regardless of the money. However {*filter*}ography is perfectly legal
and a lot of people have no qualms about producing or distributing it.

--

"Man will always find a difficult means to perform a simple task"
                                                   - Rube Goldberg



Tue, 12 Oct 1999 03:00:00 GMT  
 Y2K Weather Report # 8 - A Y2K spring.

Quote:




> > > > American Stores has been running ads from everything from systems
> > > > programmers to programmer/analyst.  They're trying to swipe anyone they
> > > > can.  No salaries listed.  They have lured people from state government

> > > Aha!  This may explain the recent increase in the *.jobs and *.ads
> > > groups from Utah.  I was wondering what companies up there are in need
> > > of mainframe skills...

> > > Regards,
> > > Doug McKibbin

> > Unfortunately, most of the ads in the local newspaper are for
> > non-mainframe/Cobol positions.  For Utah's size, there has always been a
> > fairly large mainframe-based usage here.  There must be a lot of
> > placement through private agencies or work through contractors these
> > days.  I have heard of individuals being gobbled up by banks.

> > Mike Dodas
> Could you tell me which local papers are listing for non-mainframe/Cobol
> positions.  I am very interested in this area.

> Charles W.

The two major local papers in Salt Lake City are the Deseret News and
the Salt Lake Tribune.

Sorry for the delay in the response.  Some posts are ten days old when
my service get them.

Mike Dodas



Wed, 13 Oct 1999 03:00:00 GMT  
 Y2K Weather Report # 8 - A Y2K spring.

The IBM Optimizing VSAM Performance guidelines can be found at:

http://TS.adm.ilstu.edu:80/cgi-bin/bookmgr/bookmgr.cmd/books/DGT1D400...

Tim Oxler

TEO Computer Technologies Inc.

http://www.i1.net/~troxler
http://users.aol.com/TEOcorp



Wed, 13 Oct 1999 03:00:00 GMT  
 Vsam I/O Performance

Quote:


> >In every other respect VSAM performs admirably - for us.
> >Also, it is my understanding the
> >DB2 uses VSAM.  I don't know much more than that!

> Under MVS, DB2 uses linear data sets as containers, but does
> not use VSAM to access them.  Instead it uses Media Manager,
> which is a much lower level and much faster I/O interface.
> VSAM and Media Manager use a common I/O driver as the interface
> to IOS and much of the Open/Close logic is common.

> At least this was true 3 years ago.  I haven't looked deeply
> into it since then.

> David Bond - Tachyon Software
> http://www.tachyonsoft.com/tachyon

Early on, DB2 used an invalid VSAM file format. DB2 was storing user
data in the RDA (Record Descriptor Area). This prevented logical record
access. All I/O had to be done at the control interval level. Because of
this HSM was unable to migrate VSAM data sets that were DB2 clusters.
HSM used IDCAMS EXPORT and IMPORT to migrate VSAM data sets.

So I wrote the EXPORT CIMODE and IMPORT CIMODE feature of IDCAMS.
Someone else changed HSM to use the CIMODE option. At the same time IBM
was working on a spec for LDS (Linear Data Sets).

At least now the DB2 clusters are valid VSAM.
--
---

Beyond Software, Inc.      http://www.beyond-software.com
"The Mainframe/Internet Company"



Sat, 16 Oct 1999 03:00:00 GMT  
 Vsam I/O Performance

Subject: Re: Vsam I/O Performance

Date: Wed, 23 Apr 1997 14:42:25 GMT

Quote:

writes

>For online, use the IMBED option.

>If disk space is not a problem, use the REPLICATE option

If you have any "modern" equipment (caching controllers, specifically), DO
NOT use  either IMBED or REPLICATE.  Hardware caches run in the
controller, and  you just waste cache space at no performance improvement.
 If you are using these datasets in an online mode (I.E. CICS), use LSR
pools and/or data tables (MVS land) as these do all of the deferred writes
and reduced I/O techniques.

Quote:

>Next is your JCL.  All of your DD's for your VSAM files should have
>AMP= parameters for bufferspace of data and index.  

Be careful of the AMP parameter ... if you are doing direct key reads and
VSAM somehow thinks you need look-ahead (it can happen), your costs go
dramatically up as VSAM retrieves 10-20 buffers of useless data.  That
being said, it is great if your application can take advantage of it ...

Finally, we use a rule of thumb where I work ... if you update more than
5% of a VSAM file or insert more than 1% of a file in a run, it should be
unloaded and done using QSAM ...

Good Luck!!!!
             Mike



Sun, 17 Oct 1999 03:00:00 GMT  
 Vsam I/O Performance



Quote:
>I hear what you are saying but the original question was something like
>"Why won't ex-mainframers come back at *any* price?" I am an
>ex-mainframer and was explaining why *I* won't come back at any price.
>Others may have different reasons. At the end of the day we each have to
>call it the way we see it.

This is the very, very interesting question!
My personal idea is that among others, the trade press (pc magazine,
pc week, etc.etc.) are doing their best to pretend that the world
circulates around the pc platform. It actually does to some extent, of
course. So, this contributes to make the average code-shark (or
wanna-be :) ) go after jobs there - "just so much kewler" :)

Another thing is that much of the work we did in 89 on the mainframes
were often done in a situation of being understaffed, and
overburdened. It's often done in haste, and not always 100% like we
would want to  do it with enough time on our hands.
And who wants to go back to such programs and maintain them?

I have found that it wasn't so tough going back. It's also got to do
with having a different hold of the situation - you are here to do a
specific job - put out a fire in a system, or start a y2k conversion.
You actually - amazingly - can get away with saying NO to all the
other stuff. Remember? Time sheets, weekly status reports, meetings,
meetings, meetings, making large tapes for the government agencies to
impossible, ever changing specs?

I still do that, now, again. But one task at a time, and I can call in
assistance when i am overloaded. Think about it. Cobol isnt a bad
language - one can write so elegantly in it :) Just assume a better
position.

Henrik PM
* Cobol instructor at large



Mon, 18 Oct 1999 03:00:00 GMT  
 Vsam I/O Performance

Quote:



> >I hear what you are saying but the original question was something like
> >"Why won't ex-mainframers come back at *any* price?" I am an
> >ex-mainframer and was explaining why *I* won't come back at any price.
> >Others may have different reasons. At the end of the day we each have to
> >call it the way we see it.

> This is the very, very interesting question!
> My personal idea is that among others, the trade press (pc magazine,
> pc week, etc.etc.) are doing their best to pretend that the world
> circulates around the pc platform. It actually does to some extent, of
> course. So, this contributes to make the average code-shark (or
> wanna-be :) ) go after jobs there - "just so much kewler" :)

Guilty <G>. I believe there are two phases to life, learning and dying.
There wasn't much left for me to learn on the mainframes and I'm not
(quite) ready to start dying yet <G>. On the PCs I get something new to
learn about every 4 days!

Quote:
> Another thing is that much of the work we did in 89 on the mainframes
> were often done in a situation of being understaffed, and
> overburdened. It's often done in haste, and not always 100% like we
> would want to  do it with enough time on our hands.
> And who wants to go back to such programs and maintain them?

Not me. I'm not ashamed of any project that I've ever worked on but
decisions were made based on the "realities" at the time. A lot of those
constraints no longer apply (and some new ones do) and it would be
painful to have to work within them. Starting in 1990 I tried to get a 4
digit year built into every system I worked on. Some listened, most
didn't.

Quote:
> I have found that it wasn't so tough going back. It's also got to do
> with having a different hold of the situation - you are here to do a
> specific job - put out a fire in a system, or start a y2k conversion.
> You actually - amazingly - can get away with saying NO to all the
> other stuff.

I will believe it when I see it. I have a hard time believing that the
people that could create this mess will get out of the way and let the
people who know what they are doing get it fixed. That would require
them to admit they made a mistake. I don't expect things to get to that
stage until June 1999 or, maybe, January 2000!

Quote:
> Remember? Time sheets, weekly status reports, meetings,
> meetings, meetings, making large tapes for the government agencies to
> impossible, ever changing specs?

Never have so few been managed by so many while so many others stood
around and watched.

Quote:
> I still do that, now, again. But one task at a time, and I can call in
> assistance when i am overloaded. Think about it. Cobol isnt a bad
> language - one can write so elegantly in it :)

You can write elegant maintainable code in any language. Some just make
it a little more difficult. Whenever I write COBOL I always feel I
should start out with "Once upon a time..."

<Henrick, in English this is how childrens' stories begin. Excuse me if
you knew that.>

Quote:
> Just assume a better
> position.

In the USA, "Assume the position" is what a policeman says when you have
to bend over for a rather embarrasing search. I don't think you meant
that <G>

Quote:
> Henrik PM
> * Cobol instructor at large

Terry Richards
Terry Richards Software


Mon, 18 Oct 1999 03:00:00 GMT  
 Vsam I/O Performance

Quote:

> On data set allocation, make certain that the secondary is as big as the
> primary allocation if the primary allocation is less than 1 cylinder and at
> least one cylinder if the primary is greater than 1 cylinder.  Also make sure
> that the index CI is large enough to address the entire CA.

Just curious: why is it important to make the secondary allocation >=1
cyl?

In some environments (e.g. CICS LSR) you may not be able to use
arbitrary
CI sizes for index components.  Seems to me that using a CA size smaller
than 1
cyl (and therefore, creating fewer CIs per CA) is a potential cure for
situations
where poor key compression would require very large index CI sizes (with
a data
CA size of 1 cyl).

I'm not arguing; I just suspect that I can learn something.
--

University Technology Services : 1121 Kinnear Rd         : whatever it
Ohio State University          : Columbus, OH 43212-1153 : takes."



Mon, 18 Oct 1999 03:00:00 GMT  
 Vsam I/O Performance


Quote:
>I will believe it when I see it. I have a hard time believing that the
>people that could create this mess will get out of the way and let the
>people who know what they are doing get it fixed. That would require
>them to admit they made a mistake.

No, it wouldn't.  They play musical jobs, and each one gets to say "Oh
my God!  Look what a mess my predecessor left!"

Seth



Tue, 19 Oct 1999 03:00:00 GMT  
 
 [ 165 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software