ASM370 and COBOL folks - where they are... 
Author Message
 ASM370 and COBOL folks - where they are...

In a message dated 04-15-97, Verne Arase said to All about Re: Vsam I/o
Performance

 >We could also address the issue of NSR and LSR buffer management,
 >especially since this is an assembler newsgroup. Is anybody interested?

VA>Yes.

Well, most of my previous append was predicated on the use of NSR buffering,
the access method default. This is what causes the expensive read-ahead on
the POINT macro. Since the RPL owns its own resource (i.e. buffer) pool, it
fills the lot on any sequential request, even when the intention is direct
positioning. The NSR buffer management also performs no lookasides on the
index buffers, which causes index reads even when the index CI's might
already be in the resource pool.

If the application were to use LSR buffer management instead, a single pool
shared by all RPL strings attached to ACB's that are party to the LSR pool
would mean that an RPL would receive only 1 data CI buffer for its request.
This means that no read-ahead is performed on sequential requests or direct
requests. Furthermore, for direct requests that require an index lookup, the
LSR pool's index CI's buffers are examined before any read of the VSAM index
component. This makes for huge savings when direct processing dominates the
access of a given file.

Until DFP/ESA, only assembler program could readily use LSR, since no
compiler languages support it. For some years, there have been various
vendor products available to permit programs written in HLL's to use LSR,
and DFP/ESA introduced the Batch LSR (BLSR) subsystem. So, these days,
anybody can use LSR if their systems programmer has switched on BLSR.

VA>I'd suggest also cutting out the other cross-posted newsgroups, as this
VA>may be off-topic in them.

I don't have control over which newsgroups the Fidonet->Internet gateway
software adds to my headers. I changed the message title to try to have it
posted only here, but the gateway seems to have detected that it was in
response to an earlier thread and cross-posted it to the original thread's
list of newsgroups.

VA>Whoever created this thread originally spammed it out across
VA>comp.software.year-2000, comp.lang.cobol, and alt.computer.consultants as
VA>well as comp.lang.asm370.

Someone after breathing bodies, I seem to recall.

Regards

Dave
<Team PL/I>
___
 * MR/2 2.25 #353 * Where do you want to go ... EVENTUALLY??
--
Please remove the '$' in the from line before reply via email.
Anti-UCE filter in operation.



Sat, 02 Oct 1999 03:00:00 GMT  
 ASM370 and COBOL folks - where they are...

Quote:



> > : > Steve the Recruiter interupts...
> > : > Help me understand something. I advertise (some would say spam) for
> > : > Cobol programmers on all the employment newsgroups. In the last 3 months
> > : > I've only gotten ONE person who was interested in programming Cobol and

> > Simple supply and demand.
> > Your bid price is not greater than their interest price.
> > Try bidding a number or a higher number.

> Did it ever occur to you that no one wants to work for a spammer?
> --

1) Steve is not a spammer.
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.

Regards,
Doug McKibbin



Sat, 02 Oct 1999 03:00:00 GMT  
 ASM370 and COBOL folks - where they are...


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.

I'd be careful about going too far here - I've not bothered to read Steve's
posts, so I don't know how he advertises positions.  He does state himself
that some would accuse him of spamming, so he's certainly realistic.  He's
also being quite reasonable in his attempts to figure out why his posts don't
work.  (Also at least one respondent has stated that Steve's not a spammer -
opinion perhaps, but It suggests that maybe Steve's not one of the worst...)

Let's assume, however, that Steve *is* a spammer - i.e. he blasts his posts
too widely and aggressively.  That says *nothing*, I repeat, *nothing*  about
his honesty.  Use of the term 'con man' always implies some form of fraud
or deceit.  If Steve's posts don't deliberately misrepresent the positions offered
then he's not a con man (how informative they are, or whether the rates are
reasonable may be another issue <g>)

I was raised to beleive that honesty and integrity are the most important
assets one can have.  As a result I tend to be extremely careful about
impugning the integrity of others without some pretty solid evidence.
I think 'liar' is one of the worst things you can call someone.

Spammers may annoy the heck out of a lot of us, but let's call a spade a
spade (a spam?) rather than attributing motives and behavior where
they may not be deserved...



Sun, 03 Oct 1999 03:00:00 GMT  
 ASM370 and COBOL folks - where they are...

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:

Slight?  Well slight in the number of words changed but huge in the
connotation of the changed words.
Quote:

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

First off, if you're going to hack my original post, leave off the
quotes so it is clear that I did not write this. And include my original
post so people can see how much you are twisting my words.  I strongly
resent you substituting in negative words in order to serve your needs.
By not addressing my original post, you have conceded the points I made.

Secondly... con man? con man?  Because a recruiter posts openings here,
that constitues a con?  A con leaves the victim with nothing or next to
nothing.  Unless you have personally worked with Steve, you are WAY off
base calling him (or even any recruiter) a con man.  Perhaps you got
burned in the past by a position that was not what you thought it would
be and you blame the recruiter.  If you don't trust what the recruiter
is telling you, ask the client.  Ask the programmers at the client
site.  Ask the other contractors at the client site.
I don't understand this personal crusade against recruiters and what you
hope to accomplish.  Nor do I want to.

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.

> Ron (user RT can be emailed at microfocus.com)

Oooooh!  We're not worthy! We're not worthy!  NOT!!!!!
Have a nice life,
Doug


Sun, 03 Oct 1999 03:00:00 GMT  
 ASM370 and COBOL folks - where they are...


 >I don't have control over which newsgroups the Fidonet->Internet gateway
 >software adds to my headers. I changed the message title to try to have
it
 >posted only here, but the gateway seems to have detected that it was in
 >response to an earlier thread and cross-posted it to the original
thread's
 >list of newsgroups.

Actually, my reply (which you replied to) cut out all the extraneous
groups; when I replied to your post just now it only listed
comp.lang.asm370.

Nice to know Fidonet's still around; I used to sysop a board and was unsure
if the internet had sent Fidonet the way of the dinosaur.

Anyhow, thanks for your discussion of advanced VSAM buffer management, but
I fear that I'm not quite up to your level of expertise. Any VSAM I/O I've
done has been strictly application level, and not utility level (even if it
does take place within a non-application piece of code like a TSO Command
Processor). I could benefit from a "what they are and why they're good for
you", though :-).



Mon, 04 Oct 1999 03:00:00 GMT  
 ASM370 and COBOL folks - where they are...

On Thursday, 97/04/17, Verne Arase wrote to All about "Vsam I/O
Performance" as follows:

VA> Anyhow, thanks for your discussion of advanced VSAM buffer
VA> management, but I fear that I'm not quite up to your level of
VA> expertise. Any VSAM I/O I've done has been strictly application
VA> level, and not utility level (even if it does take place within a
VA> non-application piece of code like a TSO Command Processor). I could
VA> benefit from a "what they are and why they're good for you", though

Firstly, the term "resource" is VSAM-speak for a buffer.

When you issue a GET or PUT macro for VSAM you use RPL=<symbol>, where
<symbol> is the label of the RPL macro that heads the string (usually
of length 1) of request parameters for the I/O to be performed. The RPL
contains stuff like whether the request is direct or sequential,
whether you want move mode or locate mode record access, the address of
your work area (for move mode) or pointer (for lcoate mode), the
address of the key to be positioned on, etc.

 NSR Buffers
 ===========
NSR stands for Non-Shared Resource, so a NSR pool is a buffer pool
that is the exclusive property of a RPL string. When a GET is performed
and the pool is either unpositioned or exhausted of its previous
position, the entire pool is filled with a read-ahead. Thus, the
subsequent GET macros are satisfied by extraction from the buffer pool
without physical I/O, until the pool is exhausted. A large NSR pool
gives excellent results for pre{*filter*}ly sequential processing of a
file.

Under NSR, there is no lookaside performed for requests that produce
positioning (POINT or keyed GET). Thus, index CI's must be read from
DASD even if they are already in a buffer somewhere. This makes direct
performance rather poor.

There are limits on how far the read-ahead will go, so sometimes the
pool is not filled completely. The most immediate problems in this area
are CI and CA splits. The read-ahead will not traverse a split CI, thus
requiring another physical I/O to complete the reading of the CA. Also,
the read-ahead will not cross a CA boundary, so physical reads that
start part way through a CA will only read to the CA boundary.

[Note: the following requires the cluster to be defined with SPEED
rather than RECOVERY.] Similarly, when using PUTs to write a file, the
buffer is filled until the CA boundary is reached or the buffer pool
filled, and only then is a physical I/O performed.

 LSR Buffers
 ===========
LSR stands for Local Shared Resource. Such a buffer pool is managed at
the address space level, rather than a particular ACB or RPL. Each
request has only 1 data buffer allotted to its RPL. This means that
sequential GETs require a physical I/O for each CI in the sequence,
unless a lookaside is successful. Unlike NSR, each positioning request
has a lookaside performed just in case the required CI is already in
the pool. This gives scintillating performance for direct processing.

By default, every PUT to a LSR pool produces a physical I/O, even if
the CI is to be updated again. There is an option to defer physical
writes until the buffer is to be stolen or the ACB closed. This can
reduce the number of EXCP's required by random update programs.

 Summary
 =======
For pre{*filter*}ly sequential processing NSR buffering is preferred.
For pre{*filter*}ly direct processing LSR buffering is preferred.

Regards

Dave
<Team PL/I>

 * KWQ/2 1.2i * "Give a man an inch and right away he thinks he's a ruler."
--
Please remove the '$' in the from line before reply via email.
Anti-UCE filter in operation.



Mon, 04 Oct 1999 03:00:00 GMT  
 ASM370 and COBOL folks - where they are...



Quote:


..snip...
>If the client wants the files expanded--LOOK OUT. You may be surprised
>at numeric date fields with space, low-values, high-values, etc. Be
>prepared for SOC7's! File conversion programs to be written must be
>quite detailed in editing the files.

>Richard J. Jackson
>Houston, Taxes. (d**n - I did it again)

If the system is really old expanding a field can cause byte alignment to get
thrown off. Look out for seemingly needless 1-3 byte FILLER statement
immediately preceeding any COMP field! Sometimes these need to begin on
halfword or fullword boundries.

If anyone doesn't know what halfword & fullword boundries are, they're in a
lot of company, (mostly people who think Y2K will be "easy").

--

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



Tue, 05 Oct 1999 03:00:00 GMT  
 ASM370 and COBOL folks - where they are...

Won't most of those programs contain the SYNCHRONIZED clause anyway??

--
The Programmer Has Spoken -- SO THERE!



Quote:



> ..snip...
> >If the client wants the files expanded--LOOK OUT. You may be surprised
> >at numeric date fields with space, low-values, high-values, etc. Be
> >prepared for SOC7's! File conversion programs to be written must be
> >quite detailed in editing the files.

> >Richard J. Jackson
> >Houston, Taxes. (d**n - I did it again)

> If the system is really old expanding a field can cause byte alignment to get
> thrown off. Look out for seemingly needless 1-3 byte FILLER statement
> immediately preceeding any COMP field! Sometimes these need to begin on
> halfword or fullword boundries.

> If anyone doesn't know what halfword & fullword boundries are, they're in a
> lot of company, (mostly people who think Y2K will be "easy").

> --

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



Tue, 05 Oct 1999 03:00:00 GMT  
 ASM370 and COBOL folks - where they are...

Quote:

> Won't most of those programs contain the SYNCHRONIZED clause anyway??

> --
> The Programmer Has Spoken -- SO THERE!






> > ..snip...
> > >If the client wants the files expanded--LOOK OUT. You may be
> > "Man will always find a difficult means to perform a simple task"
> >                                                    - Rube Goldberg

I haven't found a SYNC clause yet. I've checked out 139 Cobol
programs and 32 copybooks. The one assembler program that
requires a date expansion has the correct alignments.

Richard Jackson
Houston



Tue, 05 Oct 1999 03:00:00 GMT  
 ASM370 and COBOL folks - where they are...

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



Wed, 06 Oct 1999 03:00:00 GMT  
 ASM370 and COBOL folks - where they are...

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

'non-mainframe/Cobol positions' there is a reason for that.

If companies fix their legacy products they will get nothing in return
and all the expenses will be lost. Many IT shops have been sold in the
idea of moving to high technology in order to get something back, so
they are implementing client/server to get rid of the mainframe. Its
not a bad idea but is this the right time?

You can see many ads requesting Sybase, Powerbuilder, Visual Basic,
Oracle, Access, etc. to fill this positions.

Going back to moving to c/s. It is too late to think about doing the
move. If users are not in the middle of the effort, chances are they
are not going to make it. It is a risk they are taking.

They are changing applications that have been customized to the
company needs through the years for packages that will not do all
their functions. They are going from one change control to several
isolated units including individual hard disks. Instead of testing
date related applications, they have to test the entire system. The
list can go on but is the decision taken by those senior executives
that denied the year 2000 for a long time.

This move will take longer than they think and some will end up with
a system that doesn't work and a mainframe that is useless. Isn't the
$4 billion IRS failure a lesson?

Eduardo Garcia
Austin, Texas



Wed, 06 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