TIME Macro Expansion MVS/ESA 
Author Message
 TIME Macro Expansion MVS/ESA

I was going to put one example of a TIME Macro expansion on here with an
operational code fragment that processes the returned data for a
(scintillating?) Y2K discussion. Then I got to thinking that maybe that
wasn't legal and IBM would sue me out of my retirement and everything
else I own (which isn't very much to them but a lot to me). Can anyone
tell me with authority whether I can put this expansion out there for
discussion? Thanks.

Jim

--
James E. Smith, Jr.



Tue, 31 Aug 1999 03:00:00 GMT  
 TIME Macro Expansion MVS/ESA


Quote:
>I was going to put one example of a TIME Macro expansion on here with an
>operational code fragment that processes the returned data for a
>(scintillating?) Y2K discussion. Then I got to thinking that maybe that
>wasn't legal and IBM would sue me out of my retirement and everything
>else I own (which isn't very much to them but a lot to me). Can anyone
>tell me with authority whether I can put this expansion out there for
>discussion? Thanks.

>Jim

>--
>James E. Smith, Jr.

Does the Macro expansion say: (c) 1987 IBM Corporation?  If not, they're
not making a reasonable effort to protect their rights.

Anyway, they might sue you for embarrassing them.  Where else does '0'b
= '19'X and '1'b = '20'X?  Who else would decide that a change during a
release, when teams of systems programmers, applications programmers,
and operations specialists are looking for problems, was shocking,
dangerous, and too scary for words but the same change, made suddenly in
the middle of the night, on a holiday weekend, was well thought out,
safe, and not a problem.

Cory Hamasaki     http://www.kiyoinc.com
HHResearch Co.    OS/2 Webstore & Newsletter
REDWOOD      



Tue, 31 Aug 1999 03:00:00 GMT  
 TIME Macro Expansion MVS/ESA


 >Does the Macro expansion say: (c) 1987 IBM Corporation?  If not, they're
 >not making a reasonable effort to protect their rights.
 >
 >Anyway, they might sue you for embarrassing them.  Where else does '0'b
 >= '19'X and '1'b = '20'X?  Who else would decide that a change during a
 >release, when teams of systems programmers, applications programmers,
 >and operations specialists are looking for problems, was shocking,
 >dangerous, and too scary for words but the same change, made suddenly in
 >the middle of the night, on a holiday weekend, was well thought out,
 >safe, and not a problem.

Cory, by your own admission you weren't around when the decision was
originally made - I was. Sure it would've broken a *lot* of apps and
spilled a lot of {*filter*} at the time, but hey - you weren't around at the
time to have suffered through it, right?

Folks on other platforms would've snickered about the stupidity of IBM, and
support by business would've drindled for this platform which would break
existing perfectly serviceable apps so callously.

I wish social security had been fixed before I bought into the system; but
it wasn't, so I have to live with it. I can {*filter*} about it, but can't help
but wonder if I'd be justified to say they should've just created a
seperate annuity, and only given the destitude elderly back what they'd put
into the system.

IBM (as usual) took the position that they'd better produce a solution
compatible with existing apps.

The turn of the century (like all natural disasters) is just something
we're all going to have to live with.

BTW, just what makes you think that having broken a large number of apps
implementing a century return ten years ago would preclude also having them
fail at the turn of the century?

If you think that making a century propogated date easily available would
actually get all applications programmers to actually _use_ that
information, you haven't seen as much multi-generational application code
as I have.

"Hmmm ... we can just bump the offset by one, and change the length of the
packed field from four to three; then we don't have to mess with that stuff
down there that adds 1900 to the year ..."



Wed, 01 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion MVS/ESA


Quote:


> >Does the Macro expansion say: (c) 1987 IBM Corporation?  If not, they're
> >not making a reasonable effort to protect their rights.

> >Anyway, they might sue you for embarrassing them.  Where else does '0'b
> >= '19'X and '1'b = '20'X?  Who else would decide that a change during a
> >release, when teams of systems programmers, applications programmers,
> >and operations specialists are looking for problems, was shocking,
> >dangerous, and too scary for words but the same change, made suddenly in
> >the middle of the night, on a holiday weekend, was well thought out,
> >safe, and not a problem.

>Cory, by your own admission you weren't around when the decision was
>originally made - I was. Sure it would've broken a *lot* of apps and
>spilled a lot of {*filter*} at the time, but hey - you weren't around at the
>time to have suffered through it, right?

Yeah, during that time, 1987 roughly, I dropped out the S/370 MVS game
and was playing with C and PC's and was working on an M.S. Computer
Science at the George Washington University's school of Engineering and
Applied Science.

Quote:
>Folks on other platforms would've snickered about the stupidity of IBM, and
>support by business would've drindled for this platform which would break
>existing perfectly serviceable apps so callously.

The DEC heads could laugh but I'd slap them around for IBM.

Quote:
>I wish social security had been fixed before I bought into the system; but
>it wasn't, so I have to live with it. I can {*filter*} about it, but can't help
>but wonder if I'd be justified to say they should've just created a
>seperate annuity, and only given the destitude elderly back what they'd put
>into the system.

You didn't buy into Social Security, you didn't sign up for it; you were
shanghai'ed.  I don't {*filter*} about SS, I pay into the Ponzi scheme
knowing clearly that it is a stupid system but at least mom, who has
been leaching off the system for few years, will continue to bleed SS
dry.

Quote:
>IBM (as usual) took the position that they'd better produce a solution
>compatible with existing apps.

IBM wimped out.  I'm sure they argued internally until someone had to go
take a potty break.

Quote:
>The turn of the century (like all natural disasters) is just something
>we're all going to have to live with.

>BTW, just what makes you think that having broken a large number of apps
>implementing a century return ten years ago would preclude also having them
>fail at the turn of the century?

<shout mode on>

Because it would have been a change made in the harsh, clear light of
day.  Made while teams of systems programmers are monitoring production,
while reps from all applications departments are reviewing the output.

Because it would have been made during a release test.

The choice was break it during the day while everyone is watching during
a release test or break it in the middle of the night on a holiday
weekend.

Of course, to be fair to IBM, they could not have anticipated the
Dilberization of the computer industry.  Do you realize that lots of
systems programmers cannot read S/370 object code?  That a large
percentage of systems 'experts' can't program, don't know what 05 EF
means, don't howl with laughter when I tell my "then I found '000197AF'
in the dump." story.

Time has passed, we've had years of 'right sizing'.  I know lots of
assembly language programmers who have died, retired, converted to being
LAN admins (and they're not going back at any price.)

The way the decision looked to IBM was, 1) break it while I'm still on
the MVS team or 2) break it after I've retired and they can't yell at
me.  Hmmmm, looks like '2' wins.

IBM's decision was wrong.  I accept it and am ready to run Rex Widmar's
SVC 11 scanner for hire.  I will also happily, dare I say gleefully, fix
the assembler language as needed.  In fact, I'm darn glad that someone
wimped out 10 years ago.  I'd like to know who it was so I can send them
a box of candy.  If they're not too ugly, I'll kiss them too.

I am not going to fix MVS S/370 assembly language for $1.50 an
instruction.  Those are COBOL rates.

<shout mode off>

Quote:
>If you think that making a century propogated date easily available would
>actually get all applications programmers to actually _use_ that
>information, you haven't seen as much multi-generational application code
>as I have.

>"Hmmm ... we can just bump the offset by one, and change the length of the
>packed field from four to three; then we don't have to mess with that stuff
>down there that adds 1900 to the year ..."

As Gyro Gearloose said, "No one can make a machine so smart that someone
is stupid enough to mess it up."

Cory Hamasaki     http://www.*-*-*.com/
HHResearch Co.   OS/2 Webstore & Newsletter
REDWOOD      



Fri, 03 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion MVS/ESA

Quote:

. . . . . (snip)
> Does the Macro expansion say: (c) 1987 IBM Corporation?  If not, they're
> not making a reasonable effort to protect their rights.

The macro expansions generally do not carry a copyright clause (at least
what I have seen), but the macros themselves sure do in their source
code.

That must imply that the generated code is free, but the program (macro)
generating this code is protected.

fair enough?

regards Sven
. . . . . (snip)



Fri, 03 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion MVS/ESA

Quote:




>> >Does the Macro expansion say: (c) 1987 IBM Corporation?  If not, they're
>> >not making a reasonable effort to protect their rights.

>> >Anyway, they might sue you for embarrassing them.  Where else does '0'b
>> >= '19'X and '1'b = '20'X?  Who else would decide that a change during a
>> >release, when teams of systems programmers, applications programmers,
>> >and operations specialists are looking for problems, was shocking,
>> >dangerous, and too scary for words but the same change, made suddenly in
>> >the middle of the night, on a holiday weekend, was well thought out,
>> >safe, and not a problem.

>>Cory, by your own admission you weren't around when the decision was
>>originally made - I was. Sure it would've broken a *lot* of apps and
>>spilled a lot of {*filter*} at the time, but hey - you weren't around at the
>>time to have suffered through it, right?

>Yeah, during that time, 1987 roughly, I dropped out the S/370 MVS game
>and was playing with C and PC's and was working on an M.S. Computer
>Science at the George Washington University's school of Engineering and
>Applied Science.
>>Folks on other platforms would've snickered about the stupidity of IBM, and
>>support by business would've drindled for this platform which would break
>>existing perfectly serviceable apps so callously.

>The DEC heads could laugh but I'd slap them around for IBM.
>>I wish social security had been fixed before I bought into the system; but
>>it wasn't, so I have to live with it. I can {*filter*} about it, but can't help
>>but wonder if I'd be justified to say they should've just created a
>>seperate annuity, and only given the destitude elderly back what they'd put
>>into the system.

>You didn't buy into Social Security, you didn't sign up for it; you were
>shanghai'ed.  I don't {*filter*} about SS, I pay into the Ponzi scheme
>knowing clearly that it is a stupid system but at least mom, who has
>been leaching off the system for few years, will continue to bleed SS
>dry.
>>IBM (as usual) took the position that they'd better produce a solution
>>compatible with existing apps.

>IBM wimped out.  I'm sure they argued internally until someone had to go
>take a potty break.
>>The turn of the century (like all natural disasters) is just something
>>we're all going to have to live with.

>>BTW, just what makes you think that having broken a large number of apps
>>implementing a century return ten years ago would preclude also having them
>>fail at the turn of the century?

><shout mode on>
>Because it would have been a change made in the harsh, clear light of
>day.  Made while teams of systems programmers are monitoring production,
>while reps from all applications departments are reviewing the output.
>Because it would have been made during a release test.
>The choice was break it during the day while everyone is watching during
>a release test or break it in the middle of the night on a holiday
>weekend.
>Of course, to be fair to IBM, they could not have anticipated the
>Dilberization of the computer industry.  Do you realize that lots of
>systems programmers cannot read S/370 object code?  That a large
>percentage of systems 'experts' can't program, don't know what 05 EF
>means, don't howl with laughter when I tell my "then I found '000197AF'
>in the dump." story.
>Time has passed, we've had years of 'right sizing'.  I know lots of
>assembly language programmers who have died, retired, converted to being
>LAN admins (and they're not going back at any price.)
>The way the decision looked to IBM was, 1) break it while I'm still on
>the MVS team or 2) break it after I've retired and they can't yell at
>me.  Hmmmm, looks like '2' wins.
>IBM's decision was wrong.  I accept it and am ready to run Rex Widmar's
>SVC 11 scanner for hire.  I will also happily, dare I say gleefully, fix
>the assembler language as needed.  In fact, I'm darn glad that someone
>wimped out 10 years ago.  I'd like to know who it was so I can send them
>a box of candy.  If they're not too ugly, I'll kiss them too.
>I am not going to fix MVS S/370 assembly language for $1.50 an
>instruction.  Those are COBOL rates.
><shout mode off>
>>If you think that making a century propogated date easily available would
>>actually get all applications programmers to actually _use_ that
>>information, you haven't seen as much multi-generational application code
>>as I have.

>>"Hmmm ... we can just bump the offset by one, and change the length of the
>>packed field from four to three; then we don't have to mess with that stuff
>>down there that adds 1900 to the year ..."

>As Gyro Gearloose said, "No one can make a machine so smart that someone
>is stupid enough to mess it up."
>Cory Hamasaki     http://www.*-*-*.com/
>HHResearch Co.   OS/2 Webstore & Newsletter
>REDWOOD      

It's 1986 and Cory is presenting at  the IBM Business Phase review
held to approve MVS release content.

Cory has only one overhead, in contrast to other presenters who are
carrying several folders overstuffed with transparencies.

Service Planning:  " You want to do what?" The phones will never stop
ringing.  The service cost estimate will skyrocket".

Marketing:  "Forget about the sales projections we gave you earlier.
We'll never be able to sell this thing.  Marketing reps will treat
this release like a dead rat."

Release Manager:  'Cory, I appreciate your concerns about the next
century, but this is a business and we need to make money on this
product.  Besides, if I get alot of flack on this, I'm headed for the
penalty box(Branch office in North Dakota?).  "Let's take a potty
break & get back together in 15 minutes."

BTW, IBM has a large ad in yesterdays New York Times(Mar. 16) looking
for Year 2000 staff.  They may yet be able to make some money fixing
these problems.

George Calafut(12 years in IBM Software Development & Service).



Fri, 03 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion MVS/ESA


Quote:

>><shout mode on>

..
>>IBM's decision was wrong.  I accept it and am ready to run Rex Widmar's
>>SVC 11 scanner for hire.  I will also happily, dare I say gleefully, fix
>>the assembler language as needed.  In fact, I'm darn glad that someone
>>wimped out 10 years ago.  I'd like to know who it was so I can send them
>>a box of candy.  If they're not too ugly, I'll kiss them too.
..
>><shout mode off>

>It's 1986 and Cory is presenting at  the IBM Business Phase review
>held to approve MVS release content.

>Cory has only one overhead, in contrast to other presenters who are
>carrying several folders overstuffed with transparencies.

>Service Planning:  " You want to do what?" The phones will never stop
>ringing.  The service cost estimate will skyrocket".

>Marketing:  "Forget about the sales projections we gave you earlier.
>We'll never be able to sell this thing.  Marketing reps will treat
>this release like a dead rat."

>Release Manager:  'Cory, I appreciate your concerns about the next
>century, but this is a business and we need to make money on this
>product.  Besides, if I get alot of flack on this, I'm headed for the
>penalty box(Branch office in North Dakota?).  "Let's take a potty
>break & get back together in 15 minutes."

>BTW, IBM has a large ad in yesterdays New York Times(Mar. 16) looking
>for Year 2000 staff.  They may yet be able to make some money fixing
>these problems.

>George Calafut(12 years in IBM Software Development & Service).


I had lunch yesterday with an Access/W95 programmer. He mentioned that he missed
working on VM/CMS, started on PL/I applications in the early 1970's and that a
Payroll system he worked on in 1973 was still running in production.  "There
have been two massive failures to replace the system", he said, "Now they're
starting on a third effort."   His former employer wants to close down legacy
applications.  They have been spending millions of dollars on these attempts but
the projects to replace the systems fail.

He talked about the second system he worked on, some kind of inventory system.
They tried to replace it 3 times, dozens of programmers working for a total of
13 years and the replacement went into production last year. It still doesn't do
all the things that the 1970's system did.

Then another programmer joined us at the cafe, it turned out that his company
won the contract to build the replacement payroll system.  I mentioned that
there are 1,016 days left. "It seems to take years to replace these old
mainframe systems."  He and I had discussed Y2K before.  There was a lot of head
shaking, some laughter at lunch.

Later that night, I saw a piece on TV about how workers in the former Soviet
Union have not been paid for several months.  The 'shock' part was a close up
of the blue glow from a nuclear device of some kind, they interviewed the safety
director of the reactor (or whatever it was, glowing blue at the bottom of a
pool of water.)  Most of his safety team has left because they need to earn a
living.

We're all stupid and I'm the biggest stupe.  The former employer of my lunch pal
has a 20+ year old payroll system that they've tried to replace twice at a cost
of millions of dollars for each effort.  They're about to try again.  Later that
day, I see a 'shock' TV piece about a nuclear accident about to happen because
former Soviet nuclear safety workers haven't been paid in months.

How dense can I be?  Obviously Y2K will not be a problem.  Obviously there is
no way a date problem will kill people.  Y2K is just a bunch of hype from
fat-headed marketeers.

Nothing to worry about.  Even though 2 multi-million dollar, multi-year efforts
failed and the third effort will very likely fail and almost certainly not
make Jan 1, 2000, it's just payroll.  It's just one of the systems that holds
civilization together.

(We discussed a few of the problems with payroll systems.  These things are more
complicated than the appear to be.)

How many PL/I programmers are there?  What are their billing rates now?

Cory Hamasaki          http://www.kiyoinc.com        
HHResearch             OS/2 Newsletter & OS/2 Web Store



Wed, 08 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion MVS/ESA

.>
.> I had lunch yesterday with an Access/W95 programmer. He mentioned
that .he missed
.> working on VM/CMS, started on PL/I applications in the early 1970's
.and that a
.> Payroll system he worked on in 1973 was still running in production.
."There
.> have been two massive failures to replace the system", he said, "Now
.they're
.> starting on a third effort."   His former employer wants to close
down .legacy
.> applications.  They have been spending millions of dollars on these
.attempts but
.> the projects to replace the systems fail.
.>
.> He talked about the second system he worked on, some kind of
inventory .system.
.> They tried to replace it 3 times, dozens of programmers working for a
.total of
.> 13 years and the replacement went into production last year. It still
.doesn't do
.> all the things that the 1970's system did.
.>
.> Then another programmer joined us at the cafe, it turned out that his
.company
.> won the contract to build the replacement payroll system.  I
mentioned .that
.> there are 1,016 days left. "It seems to take years to replace these
.old
.> mainframe systems."  He and I had discussed Y2K before.  There was a
.lot of head
.> shaking, some laughter at lunch.
.>
.> Later that night, I saw a piece on TV about how workers in the former
.Soviet
.> Union have not been paid for several months.  The 'shock' part was a
.close up
.> of the blue glow from a nuclear device of some kind, they interviewed
.the safety
.> director of the reactor (or whatever it was, glowing blue at the
.bottom of a
.> pool of water.)  Most of his safety team has left because they need
to .earn a
.> living.
.>
.> We're all stupid and I'm the biggest stupe.  The former employer of
my .lunch pal
.> has a 20+ year old payroll system that they've tried to replace twice
.at a cost
.> of millions of dollars for each effort.  They're about to try again.
.Later that
.> day, I see a 'shock' TV piece about a nuclear accident about to
happen .because
.> former Soviet nuclear safety workers haven't been paid in months.
.>
.> How dense can I be?  Obviously Y2K will not be a problem.  Obviously
.there is
.> no way a date problem will kill people.  Y2K is just a bunch of hype
.from
.> fat-headed marketeers.
.>
.> Nothing to worry about.  Even though 2 multi-million dollar,
.multi-year efforts
.> failed and the third effort will very likely fail and almost
certainly .not
.> make Jan 1, 2000, it's just payroll.  It's just one of the systems
.that holds
.> civilization together.
.>
.> (We discussed a few of the problems with payroll systems.  These
.things are more
.> complicated than the appear to be.)
.>
.> How many PL/I programmers are there?  What are their billing rates
.now?
.>
.> Cory Hamasaki          http://www.kiyoinc.com
.> HHResearch             OS/2 Newsletter & OS/2 Web Store

You know, I think what is so disturbing about incidents like the one
Cory has mentioned is how universal this attitude is.  It's almost like
the people who are in the positions to make the decisions to proceed
with these multi-million dollar fiascos, over and over again, are sent
to some kind of executive training course in "how to do their own
companies in". I just can't seem to come up with a better explanation.
Who in their right mind would risk their business operations like this,
particularlly when they have already failed at the same attempts?  I
have personnaly witnessed this mindless process and continue to see this
happening right now.

I don't resist new technology--I'm just very critical of it.  You have
to be.  To me, it is a crucial point that helps **protect** the interest
and survival of your employer.  I think that this is one of the biggest
differences between the computer people of the last 30 years and many of
the so-called "new-age" computer people of today.  So many of the
younger people coming into the ITS business of today can't see beyond
the PC sitting on their desk.  They just don't see that there is an
entire organization and entity beyond the video display. I don't believe
they are doing it deliberately--the ITS industry simply does not
emphasise it any more.  Worse, management is operating the same way.  To
most of us who have been in the business 20-30 years, this concept is as
foreign as being able to naturally breath under water, and it is
unacceptable.

One of the very few positive things to come out of the Y2K situation is
that it might weed out the incompetence in the ITS departments and
finally force the organization to decide what is truly necessary and
important for their computing needs.  But long before that happens, the
havoc and damage that will be created might be unrepairable.  Could this
be one of those mythical parables of the phoenix bird, consuming itself
in fire and rising renewed from the ashes?  Or will we just sustain
third-degree burns and be maimed for years.

Not to worry, Cory--**They** have yours and my best interests at heart.
Keep looking at the watch swining from the little chain and repeat after
me:  "There is no problem, there is no problem, ZZZZZzzzzzz......".

Mike Dodas



Thu, 09 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion MVS/ESA

Quote:



>(We discussed a few of the problems with payroll systems.  These things are more
>complicated than the appear to be.)

>How many PL/I programmers are there?  What are their billing rates now?

I have often wondered why there is more than one payroll system. It
feels like featherbedding...

john alvord



Mon, 13 Sep 1999 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. TIME Macro Expansion MVS/ESA

2. TIME Macro Expansion

3. Macro expansion, times.

4. MVS/ESA assembly book wanted

5. MVS XA/ESA

6. DB2, MVS/ESA, PL1 (newbee)

7. mvs/esa sp5 application symbol table

8. Linking PL/I and C on MVS/ESA

9. VM Open Edition and MVS/ESA Open Edition

10. REXX compiler on MVS/ESA 3.1.3

11. MVS/ESA Rexx Compiler

12. CLIST vs. REXX (was: MVS/ESA)

 

 
Powered by phpBB® Forum Software