Where is the programmer manager during all this? Did he not bother to do even
a basic code review? It looks like he did not control his people so things
went down fast.
Yes, sort of my point, partly.
-Ursprüngliche Nachricht-
Von: IBM Mainframe Assembler List
Personal point of view, but most management doesn't have vision, except for
their own personal political agendas. THAT they see very clearly.
On Wed, 7/23/14, ASSEMBLER-LIST automatic digest system
lists...@listserv.uga.edu wrote:
Subject:
May be faster to have the main build a queue of records and let the
subtasks
feed themselves. There are interesting serialization concerns with
multiple
eaters. The feeder can post all waiting tasks when food is available.
I know this is a very old thread...
I have been re-reading it
Tony,
I am also not aware of any specific examples out in the wild. However, you may
have some luck examining the area that the CS kids call design patterns.
These patterns mostly seem to be applied to object-oriented programming, but
the principles are the same for z/OS subtasking, just
It's called a producer consumer pattern.
It's directly applicable here - the producer creates the work and the
consumer(s) process it.
Consumers can either be in separate address spaces or attached subtasks.
It doesn't matter for purposes of what they are doing.
You - as it says below - link
On 2014-07-24, at 06:50, Tony Thigpen wrote:
May be faster to have the main build a queue of records and let the subtasks
feed themselves. There are interesting serialization concerns with multiple
eaters. The feeder can post all waiting tasks when food is available.
I've done something
I use the following technique for YES/NO type variables:
FOO UPCB=YES
uUPCB SETC (UPPER 'UPCB')
AIF ('uUPCB' EQ 'NO').OK
AIF ('uUPCB' EQ 'YES').OK
MNOTE 8,'Invalid UPCB= value, specify either YES or NO'
MEXIT
.OK ANOP ,
All subsequent
Robert Ngan's scheme makes [only] yes|no case-insensitive.
I was using yes|no a a VERY simple example of recognizing CIDTs of one
of the elements of a set.
For his announced purposes his scheme is, of course, unobjectionable.
I personally would still strongly prefer the use of a macro to meet
And in principle I much prefer the communication between invoker and macro te
be as explicit as possible. I see no value at all in
allowing the programmer to omit one or two letters (or any amount) from the
value of a keyword. The time saved by not having to
press those few keys cannot
