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

In a message dated 04-23-97, Arnold Trembley said to All about Re: Vsam I/o
Performance

AT>In my shop we have a general-purpose assembler subprogram for accessing
AT>VSAM files (KSDS, ESDS, or RRDS).  It has an internal table to manage
AT>control blocks for something like 24 different VSAM files concurrently.

How do you control the way it opens an ACB? The parameter list from Hell?

AT>As far as I know, it was developed a long time ago for a DOS/VSE COBOL
AT>compiler which only knew ISAM.  No one wants to do the work to convert it
AT>to 31-bit addressability.  Basically, you need to pass it a control
AT>record with all the values needed to populate the appropriate MVS VSAM
AT>macros, and an address of a record buffer.  I still use it when I need
AT>to POINT into the middle of an ESDS file using a saved RBA, otherwise I
AT>prefer to use native COBOL.

Well, as a PL/I bigot, I don't need it even for that. ... :-)

AT>If your primary concern on VSAM performance is batch wall-clock run time,
AT>I can tell you that we normally unload our VSAM files to QSAM for major
AT>maintenance and then reload them for CICS.  Even for detail or ad hoc
AT>reporting, we find it to be much quicker to process the data as a QSAM
AT>file, provided your application is adaptable to sequential processing.

You need to look at your cluster definitions and NSR buffering parameters.
Most people make the data CI size too small for VSAM clusters. The old rule
of small CI's for random access is bunk. Make the CI size 22K for 3380 and
26K for 3390 drives -- regardless of the {*filter*} of random or sequential
processing. Indeed, when using LSR buffering, lookasides can use less CPU
time if the CI size is larger.

AT>If you want to write something like what I described, it's a fairly large
AT> assembler program, at least 2000 lines.  You would need a good reference
AT> manual on VSAM macros.  

There should be one on the MVS Application Development Collection CD (in
BookManager format).

But why would anybody write something like that these days? The days of
ISAM/BDAM-only COBOL are long gone and such interface modules should be too.

Regards

Dave
<Team PL/I>
___
 * MR/2 2.25 #353 * Drink your coffee! There are poor people in India sleeping!
--
Please remove the '$' in the from line before reply via email.
Anti-UCE filter in operation.



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



Quote:
> the job market.  One of my criteria for considering a position is that it
> is NOT Y2K work.  I want to work for a company that already has this
fixed.
>  So far - based on this single criteria - I have found NO company that
> qualifies.  It's BAD BAD BAD out there.  I am afraid when these companies
> can't find enough programmers to work on Y2K, they will start offering
> "Perm" positions, and then rightsize after the fix is complete.  That is
> what I want to avoid in any new employ.

Yep, give it another year and no-one of any real use for Y2K will want to
jump ship at any price.

Unless of course ten year contracts with no escape clauses are offered.  
The hot shot Execs. have been exactly playing this game for ages now.
But be careful, inflation will be back in the next decade.  Count on it.



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


Quote:

> Newsgroups: comp.software.year-2000, alt.computer.consultants,
>             comp.lang.cobol,comp.lang.asm370
> [snip: 53 lines] Cory Hamasaki

No, down, bad dog!  You forgot to mention COBOL (again).

Or (please) just delete the technical language groups from your
cross-posted newsgroups as you chat about jobs and Year 2000.

Thanks
--
Richard Ross-Langley



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


Quote:


>> the job market.  One of my criteria for considering a position is that it
>> is NOT Y2K work.  I want to work for a company that already has this
>fixed.
>>  So far - based on this single criteria - I have found NO company that
>> qualifies.  It's BAD BAD BAD out there.  I am afraid when these companies
>> can't find enough programmers to work on Y2K, they will start offering
>> "Perm" positions, and then rightsize after the fix is complete.  That is
>> what I want to avoid in any new employ.

>Yep, give it another year and no-one of any real use for Y2K will want to
>jump ship at any price.

>Unless of course ten year contracts with no escape clauses are offered.  
>The hot shot Execs. have been exactly playing this game for ages now.
>But be careful, inflation will be back in the next decade.  Count
>on it.

N.R.H.,

More info please.  We've seen flat inflation for 10 years now and
in this area, slow housing sales.  Last month, I noticed that
houses in my neighborhood are selling very, very fast.  I take
regular walks and now houses are on the market only days or hours.
I've also noticed that several products have crept up in price.  I
attribute some of this to the Fed's recent policy of inflaming
inflation by raising interest rates.

I've believed for years that something causes the Federal Reserve
to hallucinate the spectre of inflation so they raise interest
rates.  The higher rates causes companies and people to borrow now
before rates go higher.  Companies and people to buy now, before
prices go higher.

I don't know why the Fed thinks that raising interest rates
dampens inflation when it reasonably should cause inflation and
historic evidence is that inflation follows the Fed's actions.

But back to Y2K.  I expect rates to be reasonable within 6 months.
Reasonable means high enough that I can pay off my house and fund
my pension by working until 2003.  I hope to earn much, much more
but my minimal expectations are: $120/hour by year end 1997.
$150/hour 1998, and somewhat more in 1999-2003.

Given that lots of tier 1 and tier 2 companies already charge
those rates, this should be easy to attain.

Cory Hamasaki



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

Quote:
> Using COBOL I/O statements resulted in huge EXCP counts, indicating that
> blocks (CI's?) were being written and reread for every insert.  My
> reading told me I could write in Assembler and avoid such behavior, and
> reduce I/O (EXCP counts) by as much as 90%+.  (I did not code any
> routines to prove this, however.)

This is certainly true.  When (years ago) we converted from a tape to tape
update system to a VSAM update system we learned that tape was FASTER for
mass adds.  Adding records to a VSAM file is expensive.  We hired an
assembler whiz to write the assembler calls for a "mass add" program that
we still use today.  It DOES speed it up by 90% or more.  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!

Quote:
> Finally, the question:
> Do most shops which use VSAM heavily write Assembler VSAM I/O modules?
> Should they?  Can this sort of routine be generalized, or must it be
> specific?  Do you know of any sources for more detailed information on
> this subject?

No we don't write a lot of them.  Just that one!  We make the calls from
the COBOL programs, and that's it!


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


 >> Always wanted to learn PL/1, but, alas, never got the chance...
::sigh::
 >
 >  You ain't missed anything.

Why do you say that?

I think among the HLLs I've experienced, PL/I is the "best of breed".



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

Some comments on VSAM performance.
FIRST: Get statistics on your major problem areas. Logical I-O counts and  
physical i-o counts (excps) are a must.

Second. Do NOT use IMBED and REPLICATE.  On the new DASD they are a space  
wasting disaster and also hinder performance.  The indicies may well be  
cached if they are not replicated and imbedded.

Now the fun gets interesting.  For true sequential access set BUFND to a full  
cylinder's worth of buffers and BUFNI to 2 - 4.  For random access set BUFND  
to 2 and BUFNI to the number of higher level indicies (all the index buffers  
that are not in the sequence set which is 1 buffer per control area - CA) if  
you are not using BLSR (SUBSYS=BLSR) which came in with ESA.  If the data set  
is being updated be sure that DEFERW=YES is coded to allow the writes to be  
done only when needed.  Be aware that if a COBOL program is doing sequential  
processing and BLSR is in use, a START must be issued after the OPEN.  

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.  

Learn how to use those statistics mentioned at the first step.  VSAM doesn't  
always work in the manner you think it would.  Most of your VSAM tuning can  
be done with JCL.  Specifying Random or Sequential Access in some cases can  
bring a performance benefit over Dynamic Access but normally it doesn't seem  
to have that much of an effect for the effort needed on existing programs.    
It also helps to pinpoint cases of reading the same record or small groups of  
records thousands of time and possibly do program caching.  BLSR is  
especially helpful in this case.              

Quote:


> >With respect to the discussion of using VSAM and getting good
> >performance:

> >I would like to ask a general question, since some parts of our
> >application inventory use VSAM, and we may have to touch them for Y2K
> >repair purposes, or even take over their long term maintenance.

> >I have little experience with VSAM, except that I tried it out from
> >COBOL a few years ago.  We were trying to figure out whether to use an
> >IMS D/B, DB2, VSAM, or Sequential Data Sets for storing a LARGE amount
> >of financial data.  We eventually settled on QSAM Variable length
> >records, and time has appeared to show this was the correct (low-cost)
> >choice.

> >My "study" of VSAM involved observing EXCP counts (which was how we
> >billed) when processing file actions, especially updates and insertions,
> >since the application would have :
> >1. inception to date records which would get updated monthly,  
> >2. month to date records which would get created at the start of the
> >month, then updated weekly (last month's records would be dropped at the
> >start of a new month), and  
> >3. weekly records, which would be inserted each week, while the previous
> >week's records were deleted.

> >This study did not take into account how the data might be used outside
> >of the "master file update" process.  However, over time, it appears
> >that  
> >1. the full set of data is used for reporting purposes, and  
> >2. selected subsets of the data are used for ad-hoc purposes.

> >Using COBOL I/O statements resulted in huge EXCP counts, indicating that
> >blocks (CI's?) were being written and reread for every insert.  My
> >reading told me I could write in Assembler and avoid such behavior, and
> >reduce I/O (EXCP counts) by as much as 90%+.  (I did not code any
> >routines to prove this, however.)

> >Finally, the question:
> >Do most shops which use VSAM heavily write Assembler VSAM I/O modules?  

> In the shops I've been in, not most.

> >Should they?  

> That may depend on such things as:
> 1. size and speed of the computer.  
> 2. Online? or just batch?
> 3. If online, is there a high number of users accessing same modules
> at the same time.

> I have run into Assembler programs written in strategic locations for
> CICS to add speed to execution.

> > Can this sort of routine be generalized, or must it be
> >specific?  Do you know of any sources for more detailed information on
> >this subject?

> Colin what you might need is just to tune your VSAM files.  Tuning
> VSAM is like tuning an old sports car.  The first things that must be
> known are:

> 1. Record length
> 2. Is the file KSDS, ESDS, RRDS
> 3. Is this for online, batch or both
> 4. type of disk pack

> And based off of these items, there is formula to find optimum CI
> size.  I have the formula, but I'm currently unable to find it.
> However, most calculations result in an optimum value of 4096, and
> many times 8192 will tie 4096 as the optimum value.  When this occurs,
> and the file is only for batch, use a CI size of 8192, otherwise use
> 4096.

> One shop I've worked at ran the online at 4092, and reorg'd the file
> to 8192 before batch processing.

> For online, use the IMBED option.  

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

> Next is Freespace.  Does your file have ample free space?  This is
> reserve space to accommodate record insertions.  Without it, will
> cause CI/CA splits, which will cause performance to suffer.

> Run a LISTCAT after execution.  A rapid increase in the number of CI
> splits indicates that the amount of free space is insufficient.

> Also, redefine/reorg your files on some kind of regular basis to keep
> CI/CA splits low.

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

> Some this info might be dated.  I used to be pretty good at this 5-6
> years ago, but haven't done it recently, MVS has gotten better in the
> meantime.

> I used to rely on the IBM Wasington Systems Center Technical
> Bulletins.  I'm not sure if they are still in circulation.

> A fairly decent book is "Practical VSAM for Today's Programmers" by
> Janossy and Guzik.  That book shouldn't be difficult to find.

> I hope that helps!

> Tim Oxler
> TEO Computer Technologies Inc.

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

Clark F. Morris, Jr.
CFM Technical Programming Services
Bridgetown, Nova Scotia, Canada




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

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



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


Quote:



>>> the job market.  One of my criteria for considering a position is that it
>>> is NOT Y2K work.  I want to work for a company that already has this
>>fixed.
>>>  So far - based on this single criteria - I have found NO company that
>>> qualifies.  It's BAD BAD BAD out there.  I am afraid when these companies
>>> can't find enough programmers to work on Y2K, they will start offering
>>> "Perm" positions, and then rightsize after the fix is complete.  That is
>>> what I want to avoid in any new employ.

>>Yep, give it another year and no-one of any real use for Y2K will want to
>>jump ship at any price.

>>Unless of course ten year contracts with no escape clauses are offered.  
>>The hot shot Execs. have been exactly playing this game for ages now.
>>But be careful, inflation will be back in the next decade.  Count
>>on it.
>>N.R.H.,
>But back to Y2K.  I expect rates to be reasonable within 6 months.
>Reasonable means high enough that I can pay off my house and fund
>my pension by working until 2003.  I hope to earn much, much more
>but my minimal expectations are: $120/hour by year end 1997.
>$150/hour 1998, and somewhat more in 1999-2003.
>Given that lots of tier 1 and tier 2 companies already charge
>those rates, this should be easy to attain.
>Cory Hamasaki

Here in the midwest (central US), the rates have gone up, all the
really good contractors are working, usually long term.  Past
employers are trying to coax those who went into consulting back to
work with them by offering better pay along with re-instating any lost
seniority for benefits.

Five years ago, I'd never get past HR and their "preferred vendor
list", now I'm getting calls from those companies.  Agencies and
brokers are calling with more frequency, and offering cash for
qualified referrals.  Much of this is for Y2K, but much of it isn't.

Companies are becoming more flexible because they have to (not because
they want to).  I've picked up a second contract from a past client
who has agreed to let me work on their stuff, in more of a
"moonlighting" role.  I'll work some days there, but much of it at
home, and still spend the majority of my work time with my other main
client.  Three years ago, they demanded that I be on-site, 8-5, five
days a week.  But, today they know that I would not agree to that.
IMO, supply and demand has tilted in the other direction.

But, on the other side of the coin....the programmers.  Most of what
I'm seeing, they are either:

A.  looking to avoid Y2K work
B.  willing to work it, if it at least doubles their income.
C.  willing to work it as additional income, keeping their current
jobs/contracts, and "moonlight" at night and/or weekends.

This moonlighting aspect is becoming more pre{*filter*}.  I've gotten
calls locally from programmers inquiring about the possiblity, and
I've also received inquirys nationally off of my webpage.

But, I've yet to find a company willing organize second shift/weekend
or any other "moonlight" friendly arrangements.  Yet some of these
companies are looking at offshoring.  Go figure.

Tim Oxler -
TEO Computer Technologies Inc.

http://www.*-*-*.com/ ~troxler
http://www.*-*-*.com/



Tue, 12 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