Re: Nanosecond resolution timestamps for HLL's?

[Jim Mulder]

  Yes, I did carefully avoid making any representation about multiple 
partitions.  On z16, I believe that
it is possible to get the same value from STCK in different partitions.  If you 
need unique values within a z/OS sysplex,  STCKE provides that.  

Jim Mulder

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, February 27, 2024 9:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

On Tue, 27 Feb 2024 16:46:00 -0600, Jon Perryman wrote:

>On Sat, 24 Feb 2024 19:50:32 +, Jim Mulder wrote:
>
>>STCK, which inserts a processor related value in the low order bits to meet 
>>the "unique with a partition" requirement. 
> 
You (carefully) avoided making any representation about multiple partitions.

And a "processor related value" can guarantee uniqueness but not monotonicity:
Suppose a processor with a higher value does STCK.  On detecting this, a 
processor with a lower value does its own STCK before the clock changes.
Clearly the value stored later and differing only in the "processor related 
value"
will be algebraically  less.

The PoOps guarantees no such inconsistency will be detectable.
"detectable" is a  tricky word.  Schrödinger's cat comes to mind: if you can't 
see it, you can't say it happened.

What's the fastest way one processor can signal the other?  Spinning on a 
storage content?  Then a cache fault might provide sufficient delay to 
guarantee consistency.

>If there's not a simple answer, I'll take your word this is monotonic, Out of 
>curiosity, what is the precision of STCK and how does it guarantee monotonic 
>time? In other words, how does STCK distinguish between 10 STCK's on the same 
>CPU in the same partition within 49 microseconds? Multiply 244 picoseconds 
>(TOD bit 63) by 200 CPU IDs, STCK precision is 49 microseconds. With a 5Ghz 
>Telum processor, single cycle instructions take 191 picoseconds which means a 
>single CPU can potentially execute 256 instructions during that 49 microsecond 
>timeframe.

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Nanosecond resolution timestamps for HLL's?

[Jim Mulder]

  You don't need to take my word that STCK on a processor is monotonic.  That 
is stated in Principles of Operation.
As I described in a  prior post a week ago, " Monotonic increasing on a 
processor is done by delaying, when two STCKs are issued too close together on 
the same processor. "
In other words, the hardware delays the execution of a subsequent STCK as 
needed to wait until a higher value will be returned than for the previous STCK 
on the same processor.
Principles of Operation does not talk about the delaying, but you can infer 
that since there is no other possible way to implement the monotonic 
requirement.

  Principles of Operation does say:

"For STORE CLOCK, when the value of a running clock is stored,
nonzero values may be stored in positions to the right
of the rightmost incremented bit; this is to ensure that
a unique value is stored."

 Due to this, the precision of STCK is model and configuration dependent.  
Prior to the z16, for a given generation of processor, the number of bits was 
constant and related to the maximum number of processors in a CEC for that 
generation.  So as newer generations supported more processors in a CEC, the 
precision of STCK  (and the amount of delaying required) got worse.
On z16, in order to reduce the delaying in some cases,  when there are fewer 
than some number of processor in the partition, the low order bits are related 
to the logical processor ID within the partition instead of a physical 
processor ID,
so that fewer bits are needed to ensure uniqueness within the partition.  That 
means that partitions with more than that number of logical processors have 
lower STCK precision and longer delays.
(I do know what the number is, but I don't know if that is intended to be 
public knowledge, so I am avoiding stating the number).  There are of course 
other performance effects of large partitions, like cross drawer cache and 
memory access time. 
A sufficiently motivated programmer might experimentally determine some of 
these things for various machine generations and configurations by writing a 
program to issue some number of sequential STCKs  and analyzing the returned 
values to see how many
low order bits stay the same in many successive values.   I am not sufficiently 
motivated, because I know the hardware engineers and can ask them whatever I 
need to know about it.

  If you really need monotonic behavior (but not uniqueness within the 
partition),  you would get better precision and possibly better performance by 
issuing STCKF and then looping issuing STCKF until you get a different 
value than the first STCKF, and then using that final value.   

  My rule is, if your just want to know what time it is, use STCKF or STCKE.  
Use STCK only if you require a unique value within the partition to use as a 
token, or you require monotonic behavior and don't care about the delays and 
lower precision.   

  As to the precision of the clock itself, and STCKF,  Principles of Operation 
says:

" For STORE CLOCK FAST, when the value of a running clock is stored, bits to 
the right of the rightmost bit that is incremented are
stored as zeros."

   In a dump, you can do SYSTRACE ALL and look at the unformatted time stamp 
(which is like an STCKF value) to see how many of the low order bits are always 
0.  On a z16, I see 

DEB714CB848F3C82
DEB714CB848F4A42
DEB714CB848F52A2
DEB714CB848F563A
DEB714CB848F691A
DEB714CB848F6A68
DEB714CB848F7174
DEB714CB848F761A
DEB714CB848F867A
DEB714CB848F8904
DEB714CB848F8A88
DEB714CB848F8B96
DEB714CB848F975A
DEB714CB848FA078
DEB714CB848FA7B4
DEB714CB848FAE50
DEB714CB848FB426
DEB714CB848FC078
DEB714CB848FC880
DEB714CB848FD06C
DEB714CB848FD862
DEB714CB848FDA24
DEB714CB848FEA0A

  Only bit 63 is always zero in those entries, so I would infer that the 
precision of the clock and of STCK on z16 is bits 0-62 (i.e., 63 bits).

Jim Mulder   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Tuesday, February 27, 2024 5:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

On Sat, 24 Feb 2024 19:50:32 +, Jim Mulder  wrote:

>STCK, which inserts a processor related value in the low order bits to meet 
>the "unique with a partition" requirement. 

If there's not a simple answer, I'll take your word this is monotonic, Out of 
curiosity, what is the precision of STCK and how does it guarantee monotonic 
time? In other words, how does STCK distinguish between 10 STCK's on the same 
CPU in the same partition within 49 microseconds? Multiply 244 picoseconds (TOD 
bit 63) by 200 CPU IDs, STCK precision is 49 microseconds. With a 5Ghz Telum 
processor, single cycle instructions take 191 picoseconds which means a single 
CPU can potentially execute 256 instructions during that 49 microsecond 
timeframe.

--
For IBM-MAIN subscribe / signoff / archive access 

Re: SDWAEC1

[zMan]

>
> Don’t challenge the list gods. Or risk meeting the same fate as Bill
> Johnson.
>

...wrote Bill Johnson in his "Dave Beagle" disguise. Your not fooling
anyone Bill.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Getting rid of a z14 zr1 - any value in the host cards?

[P H]

Re: What is supported in which system, you will find the relevant information 
in the System z Functional Matrix

https://www.redbooks.ibm.com/abstracts/redp5157.html
[https://www.redbooks.ibm.com/images/thumbs/redp-5157-07_x2.jpg]
IBM Z Functional Matrix
This IBM® Redpaper publication can help you quickly understand the features, 
functions, and connectivity options that are available with the IBM z16™, IBM 
z15®, and IBM z14®. The intention of this publication is to compare the 
standard and optional
www.redbooks.ibm.com




From: IBM Mainframe Discussion List  on behalf of 
Laurence Chiu <05c4ba336ee7-dmarc-requ...@listserv.ua.edu>
Sent: 27 February 2024 03:54
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Getting rid of a z14 zr1 - any value in the host cards?

Somebody said to me the z14 cards cannot be used in a Z15 or z16 because of
a difference in form factor!  This seemed like an ill-informed comment to
me since all the cards probably use some sort of PCI connector and IBM
would not change them between model Z's. But it would be nice to be able to
quote some authoritative source as this person appears to have the ear of
some of our senior managers.

On Sun, Feb 25, 2024 at 3:19 AM Mike Smith  wrote:

> I would imagine that the FICON and OSA cards might have value to someone.
> These cards can still be used in other z14's, z15's and z16's.  With the
> hardware WKFM date for z15's having passed, the only way to add an adapter
> to a z15 is to acquire it from the secondary market (aka used).  You could
> try posting them on eBay or contact some of the companies that trade in
> used IBM parts.
>
> Good luck!
> Mike
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Laurence Chiu
> Sent: Friday, February 23, 2024 6:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Getting rid of a z14 zr1 - any value in the host cards?
>
> Sorry. Z14
>
> On Sat, Feb 24, 2024, 2:59 PM Charles Mills  wrote:
>
> > z14 as in the Subject or z16 as in the body?
> >
> > CM
> >
> > On Sat, 24 Feb 2024 12:04:39 +1300, Laurence Chiu 
> > wrote:
> >
> > >I need to decommission and remove for potential destruction z16 zr1.
> > >It only has one active engine so it's capped at 88 mips which isn't
> > >very useful. But for a number of reasons it has a ton of 16G fibre
> > >channel cards (6 or 8 I think). They might have some value so I was
> > >thinking I would remove them before having the host removed. There
> > >are
> > also
> > >4 OSA Express cards (10G). Our IBM SE said IBM do not support used
> > >cards
> > in
> > >CEC's but that does not mean they won't work?
> > >
> > >Another thought was it could be used as a sysprog play pen, carving
> > >up
> > some
> > >storage of the DS8K we have and creating a small z/OS image. But how
> > >much play can you do in 88 MIPS?
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SDWAEC1

[Joseph Reichman]

Who is bill johnson ?

> On Feb 27, 2024, at 10:04 PM, Dave Beagle 
> <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Don’t challenge the list gods. Or risk meeting the same fate as Bill Johnson.
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Tuesday, February 27, 2024, 6:30 PM, Joseph Reichman 
> <05812645a43c-dmarc-requ...@listserv.ua.edu> wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I work for the IRS 
> 
> 
> 
> All the current production tax code is assembler they are trying to change to 
> Java
> 
> I used to work for vendors 
> 
> But found myself spending a lot of time on the unemployment line thank g-d 
> for the government 
> 
> You can see and down load my code when I’m finished updating shortly 
> 
> Member Grecov was about 592 lines 
> 
> 
> 
> It’s now over 2200
> 
> 
> 
> 
> 
> I added a lot 
> 
> 
> 
> I look over my last posts in thread to see how I can improve my posts 
> 
> 
> 
> Thanks all 
> 
> 
> 
> 
> 
> On Feb 27, 2024, at 3:52 PM, Joseph Reichman   > wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> Joe Reichman
> 
> 
> 
> 
> 
> On Tue, Feb 27, 2024 at 3:49 PM Paul Gilmartin 
> <042bfe9c879d-dmarc-requ...@listserv.ua.edu 
>  > wrote:
> 
>> On Tue, 27 Feb 2024 13:48:18 -0600, Jon Perryman wrote:
>> 
>> Joseph, you missed Peter's point. Clearly you don't understand this is not 
>> about "seems like". By ignoring several clarification requests, you caused 
>> lots of confusing posts because you forced false speculation that would have 
>> been avoided by the clarifications.  ...
>> 
> I have never known Joseph to supply actual code samples when
> invited, even urged, to do so.  I can readily suspect that terms
> of his employment preclude that for reasons such as work product
> or confidentiality.
> 
> --
> gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu   
> with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SDWAEC1

[Dave Beagle]

Don’t challenge the list gods. Or risk meeting the same fate as Bill Johnson.


Sent from Yahoo Mail for iPhone


On Tuesday, February 27, 2024, 6:30 PM, Joseph Reichman 
<05812645a43c-dmarc-requ...@listserv.ua.edu> wrote:

 

 

 

 

I work for the IRS 

 

All the current production tax code is assembler they are trying to change to 
Java

I used to work for vendors 

But found myself spending a lot of time on the unemployment line thank g-d for 
the government 

You can see and down load my code when I’m finished updating shortly 

Member Grecov was about 592 lines 

 

It’s now over 2200

 

 

I added a lot 

 

I look over my last posts in thread to see how I can improve my posts 

 

Thanks all 





On Feb 27, 2024, at 3:52 PM, Joseph Reichman mailto:reichman...@gmail.com> > wrote:



 




Joe Reichman

 

 

On Tue, Feb 27, 2024 at 3:49 PM Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu 
 > wrote:

On Tue, 27 Feb 2024 13:48:18 -0600, Jon Perryman wrote:
>
>Joseph, you missed Peter's point. Clearly you don't understand this is not 
>about "seems like". By ignoring several clarification requests, you caused 
>lots of confusing posts because you forced false speculation that would have 
>been avoided by the clarifications.  ...
>
I have never known Joseph to supply actual code samples when
invited, even urged, to do so.  I can readily suspect that terms
of his employment preclude that for reasons such as work product
or confidentiality.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu   with 
the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Nanosecond resolution timestamps for HLL's?

[Paul Gilmartin]

On Tue, 27 Feb 2024 16:46:00 -0600, Jon Perryman wrote:

>On Sat, 24 Feb 2024 19:50:32 +, Jim Mulder wrote:
>
>>STCK, which inserts a processor related value in the low order bits to meet 
>>the "unique with a partition" requirement. 
> 
You (carefully) avoided making any representation about multiple partitions.

And a "processor related value" can guarantee uniqueness but not monotonicity:
Suppose a processor with a higher value does STCK.  On detecting this, a
processor with a lower value does its own STCK before the clock changes.
Clearly the value stored later and differing only in the "processor related 
value"
will be algebraically  less.

The PoOps guarantees no such inconsistency will be detectable.
"detectable" is a  tricky word.  Schrödinger's cat comes to mind: if
you can't see it, you can't say it happened.

What's the fastest way one processor can signal the other?  Spinning
on a storage content?  Then a cache fault might provide sufficient
delay to guarantee consistency.

>If there's not a simple answer, I'll take your word this is monotonic, Out of 
>curiosity, what is the precision of STCK and how does it guarantee monotonic 
>time? In other words, how does STCK distinguish between 10 STCK's on the same 
>CPU in the same partition within 49 microseconds? Multiply 244 picoseconds 
>(TOD bit 63) by 200 CPU IDs, STCK precision is 49 microseconds. With a 5Ghz 
>Telum processor, single cycle instructions take 191 picoseconds which means a 
>single CPU can potentially execute 256 instructions during that 49 microsecond 
>timeframe.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SDWAEC1

[Joseph Reichman]

What does my job 

Have to do with the CBTTAPE 


I will spell it out in clear cut letters 

I WORK AS A TESTER FOR THE IRS

I have Zpdt personal edition license 

> On Feb 27, 2024, at 6:39 PM, Tom Marchant 
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> 
> I very much doubt that he is changing code supplied on the CBT tape
> at his employer's direction or as part of his employment.
> 
> --
> Tom Marchant
> 
>> On Tue, 27 Feb 2024 14:49:30 -0600, Paul Gilmartin  
>> wrote:
>> 
>>> On Tue, 27 Feb 2024 13:48:18 -0600, Jon Perryman wrote:
>>> 
>>> Joseph, you missed Peter's point. Clearly you don't understand this is not 
>>> about "seems like". By ignoring several clarification requests, you caused 
>>> lots of confusing posts because you forced false speculation that would 
>>> have been avoided by the clarifications.  ...
>>> 
>> I have never known Joseph to supply actual code samples when
>> invited, even urged, to do so.  I can readily suspect that terms
>> of his employment preclude that for reasons such as work product
>> or confidentiality.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SDWAEC1

[Tom Marchant]

I very much doubt that he is changing code supplied on the CBT tape 
at his employer's direction or as part of his employment.

-- 
Tom Marchant

On Tue, 27 Feb 2024 14:49:30 -0600, Paul Gilmartin  wrote:

>On Tue, 27 Feb 2024 13:48:18 -0600, Jon Perryman wrote:
>>
>>Joseph, you missed Peter's point. Clearly you don't understand this is not 
>>about "seems like". By ignoring several clarification requests, you caused 
>>lots of confusing posts because you forced false speculation that would have 
>>been avoided by the clarifications.  ...
>>
>I have never known Joseph to supply actual code samples when
>invited, even urged, to do so.  I can readily suspect that terms
>of his employment preclude that for reasons such as work product
>or confidentiality.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SDWAEC1

[Joseph Reichman]

 

 

 

 

I work for the IRS 

 

All the current production tax code is assembler they are trying to change to 
Java

I used to work for vendors 

But found myself spending a lot of time on the unemployment line thank g-d for 
the government 

You can see and down load my code when I’m finished updating shortly 

Member Grecov was about 592 lines 

 

It’s now over 2200

 

 

I added a lot 

 

I look over my last posts in thread to see how I can improve my posts 

 

Thanks all 





On Feb 27, 2024, at 3:52 PM, Joseph Reichman mailto:reichman...@gmail.com> > wrote:



 




Joe Reichman

 

 

On Tue, Feb 27, 2024 at 3:49 PM Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu 
 > wrote:

On Tue, 27 Feb 2024 13:48:18 -0600, Jon Perryman wrote:
>
>Joseph, you missed Peter's point. Clearly you don't understand this is not 
>about "seems like". By ignoring several clarification requests, you caused 
>lots of confusing posts because you forced false speculation that would have 
>been avoided by the clarifications.  ...
>
I have never known Joseph to supply actual code samples when
invited, even urged, to do so.  I can readily suspect that terms
of his employment preclude that for reasons such as work product
or confidentiality.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu   with 
the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Nanosecond resolution timestamps for HLL's?

[Farley, Peter]

I suspect that to know that level of detail you would have to be authorized to 
read the occasionally hinted-at “Red Book” version of the PoOPS that IBM never 
releases to anyone outside of a VERY small circle of IBM employees.

I am content with the statement of monotonicity, given the well-respected 
source of the statement.

Peter

From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Tuesday, February 27, 2024 5:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


On Sat, 24 Feb 2024 19:50:32 +, Jim Mulder 
mailto:d10j...@us.ibm.com>> wrote:



>STCK, which inserts a processor related value in the low order bits to meet 
>the "unique with a partition" requirement.



If there's not a simple answer, I'll take your word this is monotonic, Out of 
curiosity, what is the precision of STCK and how does it guarantee monotonic 
time? In other words, how does STCK distinguish between 10 STCK's on the same 
CPU in the same partition within 49 microseconds? Multiply 244 picoseconds (TOD 
bit 63) by 200 CPU IDs, STCK precision is 49 microseconds. With a 5Ghz Telum 
processor, single cycle instructions take 191 picoseconds which means a single 
CPU can potentially execute 256 instructions during that 49 microsecond 
timeframe.

--



This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Nanosecond resolution timestamps for HLL's?

[Charles Mills]

And THAT is why you should strongly consider STCKF or STCKE.

STCK spins in microcode until it can come up with a time greater than any time 
it has previously reported, consuming CPU cycles that are charged to your 
program.

If all you need is the time of day, accurate to some very, very small 
increment, use STCKF. 

If you need monotonically increasing timestamps, re-program for STCKE.

The precision of STCK is model-dependent, not architectural, and I am not 
certain that IBM documents it.

Charles

On Tue, 27 Feb 2024 16:46:00 -0600, Jon Perryman  wrote:

>On Sat, 24 Feb 2024 19:50:32 +, Jim Mulder  wrote:
>
>>STCK, which inserts a processor related value in the low order bits to meet 
>>the "unique with a partition" requirement. 
>
>If there's not a simple answer, I'll take your word this is monotonic, Out of 
>curiosity, what is the precision of STCK and how does it guarantee monotonic 
>time? In other words, how does STCK distinguish between 10 STCK's on the same 
>CPU in the same partition within 49 microseconds? Multiply 244 picoseconds 
>(TOD bit 63) by 200 CPU IDs, STCK precision is 49 microseconds. With a 5Ghz 
>Telum processor, single cycle instructions take 191 picoseconds which means a 
>single CPU can potentially execute 256 instructions during that 49 microsecond 
>timeframe.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Nanosecond resolution timestamps for HLL's?

[Jon Perryman]

On Sat, 24 Feb 2024 19:50:32 +, Jim Mulder  wrote:

>STCK, which inserts a processor related value in the low order bits to meet 
>the "unique with a partition" requirement. 

If there's not a simple answer, I'll take your word this is monotonic, Out of 
curiosity, what is the precision of STCK and how does it guarantee monotonic 
time? In other words, how does STCK distinguish between 10 STCK's on the same 
CPU in the same partition within 49 microseconds? Multiply 244 picoseconds (TOD 
bit 63) by 200 CPU IDs, STCK precision is 49 microseconds. With a 5Ghz Telum 
processor, single cycle instructions take 191 picoseconds which means a single 
CPU can potentially execute 256 instructions during that 49 microsecond 
timeframe.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SDWAEC1

[Paul Gilmartin]

On Tue, 27 Feb 2024 13:48:18 -0600, Jon Perryman wrote:
>
>Joseph, you missed Peter's point. Clearly you don't understand this is not 
>about "seems like". By ignoring several clarification requests, you caused 
>lots of confusing posts because you forced false speculation that would have 
>been avoided by the clarifications.  ...
>
I have never known Joseph to supply actual code samples when
invited, even urged, to do so.  I can readily suspect that terms
of his employment preclude that for reasons such as work product
or confidentiality.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Understanding, Language and Comminication

[Itschak Mugzach]

It is an inappropriate statement.

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





בתאריך יום ג׳, 27 בפבר׳ 2024 ב-22:17 מאת Gibney, Dave <
03b5261cfd78-dmarc-requ...@listserv.ua.edu>:

> I believe it was explicitly stated some years ago, but it is clear that
> English is not Mr. Reichman's native language. He doesn't catch many
> nuances. I suspect there may also be some issues that are sometimes
> described as location on the spectrum.
>
> I also think it unfortunate (but understandable) that legal concerns keep
> the very helpful IBM people like Peter from directly looking at CBT files,
> forcing them to derive context from incomplete questions like this and
> other threads.
>
> > > Thanks and I apologize if sone of my posts made it seem like I wasn’t
> > > listening to what you were telling me
> >
> > Joseph, you missed Peter's point. Clearly you don't understand this is
> not
> > about "seems like". By ignoring several clarification requests, you
> caused lots
> > of confusing posts because you forced false speculation that would have
> been
> > avoided by the clarifications. Everyone is wasting their time reading
> irrelevant
> > posts (not just the poster) because you couldn't be bothered to respond.
> Do
> > you not consider this rude?
> >
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Understanding, Language and Comminication

[Gibney, Dave]

I believe it was explicitly stated some years ago, but it is clear that English 
is not Mr. Reichman's native language. He doesn't catch many nuances. I suspect 
there may also be some issues that are sometimes described as location on the 
spectrum.

I also think it unfortunate (but understandable) that legal concerns keep the 
very helpful IBM people like Peter from directly looking at CBT files, forcing 
them to derive context from incomplete questions like this and other threads. 

> > Thanks and I apologize if sone of my posts made it seem like I wasn’t
> > listening to what you were telling me
> 
> Joseph, you missed Peter's point. Clearly you don't understand this is not
> about "seems like". By ignoring several clarification requests, you caused 
> lots
> of confusing posts because you forced false speculation that would have been
> avoided by the clarifications. Everyone is wasting their time reading 
> irrelevant
> posts (not just the poster) because you couldn't be bothered to respond. Do
> you not consider this rude?
> 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SDWAEC1

[Joseph Reichman]

I didn’t look at email thread

But the clarification I was looking at was relevance of SDWAEC2

Everything else I was pretty clear if I  wasn’t clear on this  maybe it’s
the way I communicated

So for that I’m sorry I look back at what I wrote

Thanks




On Tue, Feb 27, 2024 at 2:48 PM Jon Perryman  wrote:

> On Mon, 26 Feb 2024 20:24:09 -0500, Joseph Reichman 
> wrote:
>
> > Thanks and I apologize if sone of my posts made it seem like I wasn’t
> listening to what you were telling me
>
> Joseph, you missed Peter's point. Clearly you don't understand this is not
> about "seems like". By ignoring several clarification requests, you caused
> lots of confusing posts because you forced false speculation that would
> have been avoided by the clarifications. Everyone is wasting their time
> reading irrelevant posts (not just the poster) because you couldn't be
> bothered to respond. Do you not consider this rude?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SDWAEC1

[Jon Perryman]

On Mon, 26 Feb 2024 20:24:09 -0500, Joseph Reichman  
wrote:

> Thanks and I apologize if sone of my posts made it seem like I wasn’t 
> listening to what you were telling me 

Joseph, you missed Peter's point. Clearly you don't understand this is not 
about "seems like". By ignoring several clarification requests, you caused lots 
of confusing posts because you forced false speculation that would have been 
avoided by the clarifications. Everyone is wasting their time reading 
irrelevant posts (not just the poster) because you couldn't be bothered to 
respond. Do you not consider this rude?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/osmf

[Ward, Mike S]

Try here. 
https://www.ibm.com/docs/en/zos/3.1.0?topic=consider-zos-upgrade-workflows


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Chalk, Shelia
Sent: Tuesday, February 27, 2024 7:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] z/osmf

Please Note: This email is from an [EXTERNAL] sender. Do not click on links or 
attachments unless you expect them from the sender and know the content is 
safe. Please contact the Service Desk if you have any concerns regarding this 
message.



Hello,
I am wanting to download the z/osmf workflow for z/os 3.1. Can someone send me 
the link where I can find this?

Thanks

Shelia Chalk
Mainframe System Programmer
sch...@ssfcu.org


==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SDWAEC1

[Joseph Reichman]

Peter 

Thanks the history of this that Sam Golob asked me to update file 192 general 
Recovery 

As it was old and at the time it was written there were not any 64 bit 
registers 

I added a scenario of, if the  abend occurred  in a IBM service 

Was this too much ?

Honestly couldn’t of done this with out your help 


Thank you 

> On Feb 27, 2024, at 8:23 AM, Peter Relson  wrote:
> 
> 
> If for instance the user was running amode 64
> I don't think SDWASRSV has 64 bit area but if I have the correlating RB I can 
> get the 64 bit regs from XSB
> 
> SDWASRSV doesn't have them because it is 4-bytes per register. Have you 
> looked at SDWAG64 and/or SDWAG64H?
> 
> For purposes of first level diagnosis it is rarely needed to have the regs 
> from the RB/linkage stack except when they give you easy access to the 
> registers that were input to the target routine when the error is due to bad 
> input (so, for example, if you are in a PC target, sure; if you are in a type 
> 2/3/4 SVC routine, sure), but very rarely would your recovery routine care 
> about that. What you generally want are the time of error registers, and the 
> ability to track back to where the register values came from.
> 
> 
> modifying file 192 general recovery.
> 
> As far as I recall, you have yet to share with the group the design points of 
> the modifications you are trying to make.
> Several folks have previously questioned some of the approaches that it 
> appears you might be trying to implement.
> 
> SDWANAME, SDWAMODN, SDWACSCT might be of interest to a diagnostician but 
> rarely to a recovery routine itself.
> Some of these are sometimes provided by RTM; SDWAMODN and SDWACSCT are often 
> set by the recovery routine itself.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Getting rid of a z14 zr1 - any value in the host cards?

[Paul Feller]

If you have access to IBM Redbooks, you can look for things like the IBM z15
(8561) Technical Guide or IBM z15 (8562) Technical Guide to get information
about what I/O features can the carried over from one model to the next.
There are similar manuals for the z16-A01 and z16-A02.

But like Ed has mentioned depending on the feature code the card(s) may not
work.

Paul


_
From: IBM Mainframe Discussion List
 On Behalf Of Ed Jaffe
Sent: Monday, February 26, 2024 10:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Getting rid of a z14 zr1 - any value in the
host cards?


On 2/26/2024 7:54 PM, Laurence Chiu wrote:
> Somebody said to me the z14 cards cannot be used in a Z15
or z16 
> because of a difference in form factor!  This seemed like
an 
> ill-informed comment to me since all the cards probably
use some sort 
> of PCI connector and IBM would not change them between
model Z's. But 
> it would be nice to be able to quote some authoritative
source as this 
> person appears to have the ear of some of our senior
managers.

Most cards work, some cards don't.

We put a bunch of cards from our decommissioned z13s into
our z15-T02 -- skipping past the z14 generation entirely.

Doing so was far, Far, FAR cheaper than buying them "net
new..."

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/





This e-mail message, including any attachments, appended
messages and the
information contained therein, is for the sole use of the
intended
recipient(s). If you are not an intended recipient or have
otherwise
received this email message in error, any use,
dissemination, distribution,
review, storage or copying of this e-mail message and the
information
contained therein is strictly prohibited. If you are not an
intended
recipient, please contact the sender by reply e-mail and
destroy all copies
of this email message and do not otherwise utilize or retain
this email
message or any or all of the information contained therein.
Although this
email message and any attachments or appended messages are
believed to be
free of any virus or other defect that might affect any
computer system into
which it is received and opened, it is the responsibility of
the recipient
to ensure that it is virus free and no responsibility is
accepted by the
sender for any loss or damage arising in any way from its
opening or use.


--
For IBM-MAIN subscribe / signoff / archive access
instructions,
send email to lists...@listserv.ua.edu with the message:
INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SDWAEC1

[Peter Relson]

If for instance the user was running amode 64
I don't think SDWASRSV has 64 bit area but if I have the correlating RB I can 
get the 64 bit regs from XSB

SDWASRSV doesn't have them because it is 4-bytes per register. Have you looked 
at SDWAG64 and/or SDWAG64H?

For purposes of first level diagnosis it is rarely needed to have the regs from 
the RB/linkage stack except when they give you easy access to the registers 
that were input to the target routine when the error is due to bad input (so, 
for example, if you are in a PC target, sure; if you are in a type 2/3/4 SVC 
routine, sure), but very rarely would your recovery routine care about that. 
What you generally want are the time of error registers, and the ability to 
track back to where the register values came from.


modifying file 192 general recovery.

As far as I recall, you have yet to share with the group the design points of 
the modifications you are trying to make.
Several folks have previously questioned some of the approaches that it appears 
you might be trying to implement.

SDWANAME, SDWAMODN, SDWACSCT might be of interest to a diagnostician but rarely 
to a recovery routine itself.
Some of these are sometimes provided by RTM; SDWAMODN and SDWACSCT are often 
set by the recovery routine itself.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

z/osmf

[Chalk, Shelia]

Hello,
I am wanting to download the z/osmf workflow for z/os 3.1. Can someone send me 
the link where I can find this?

Thanks

Shelia Chalk
Mainframe System Programmer
sch...@ssfcu.org


==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Signing off

[Seymour J Metz]

IBM 65? Should that be 650?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Clement Clarke <05cb6e944c87-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, February 27, 2024 6:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Signing off

My first computer was a 1902 in Melbourne Australia.

I then went to Shell Oil and worked on an English Electric Leo.

Then an IBM 65 arrived.

And I wrote the first version of Jol to replace JCL in about 1968 or 1969
in PL/1 and converted it Assembler to run in a 16K (?) Partition.

The ICL 1902 was assembler only then. Cobol was just being "played" with.
It needed 4 tape decks to do a compile.

The LEO at Shell could multi program back in the '60s. It also had a
compiler language called CLEO that was a bit similar to COBOL.  A bit...



On Tue, 27 Feb. 2024, 8:47 pm Martin Packer, 
wrote:

> My Dad (now long since retired) worked with 1904’s and then 29xx and 39xx.
>
> (He also had IBM kit in the end – 3090 – but that isn’t really how I got
> into IBM.) 
>
> I think there was / is a 1904 in the Science Museum in London.
>
> Cheers, Martin
>
> From: IBM Mainframe Discussion List  on behalf
> of Steve Thompson 
> Date: Monday, 26 February 2024 at 22:02
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: [EXTERNAL] Re: Signing off
> I had to re-read that line "first started on an ICL 1904" a few
> times before I my brain realized that was a model number and not
> a year.
>
> Blue skies and tail winds.
>
> Enjoy your next set of activities.
>
> Regards,
> Steve Thompson
>
> On 2/26/2024 2:51 PM, Sean Gleann wrote:
> > This list has been a great source of ideas and information, although I've
> > never really been a 'contributor' here, but more of a 'lurker'. Whenever
> > I've seen a thread that I might be able to respond to, someone else gets
> in
> > first with a response very similar to the one that I thought of.
> >
> > So, I hope you won't mind me speaking up now to say that it's time for
> this
> > tired old mainframer to toddle off into the sunset... after 50 years of
> > working with mainframe systems, I feel it's time to hang up my keyboard
> and
> > call it a day.
> >
> > I first started on an ICL 1904 - punched cards, paper tape, core memory,
> > 60MB disks, GEORGE II - but quickly saw the light and moved to another
> > employer that used a 360/30 roughly 8 years after the series was first
> > marketed. Since then, aside from a brief entanglement with a Burroughs
> > B4700, it's been IBM all the way.
> >
> > I have to say that it's (mostly) been a lot of fun. From one aspect, I've
> > never really worked a day in my life. Instead, I've been paid a lot of
> > money to play on other people's expensive toys.
> >
> > Here's wishing all of you good luck and good fortune for the future. I'll
> > be thinking about doing some travelling - haven't made it to South
> America
> > or Africa yet.
> >
> > Regards
> > Sean o'bhaile na Gleann
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> Regards, Steve Thompson
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Signing off

[Clement Clarke]

My first computer was a 1902 in Melbourne Australia.

I then went to Shell Oil and worked on an English Electric Leo.

Then an IBM 65 arrived.

And I wrote the first version of Jol to replace JCL in about 1968 or 1969
in PL/1 and converted it Assembler to run in a 16K (?) Partition.

The ICL 1902 was assembler only then. Cobol was just being "played" with.
It needed 4 tape decks to do a compile.

The LEO at Shell could multi program back in the '60s. It also had a
compiler language called CLEO that was a bit similar to COBOL.  A bit...



On Tue, 27 Feb. 2024, 8:47 pm Martin Packer, 
wrote:

> My Dad (now long since retired) worked with 1904’s and then 29xx and 39xx.
>
> (He also had IBM kit in the end – 3090 – but that isn’t really how I got
> into IBM.) 
>
> I think there was / is a 1904 in the Science Museum in London.
>
> Cheers, Martin
>
> From: IBM Mainframe Discussion List  on behalf
> of Steve Thompson 
> Date: Monday, 26 February 2024 at 22:02
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: [EXTERNAL] Re: Signing off
> I had to re-read that line "first started on an ICL 1904" a few
> times before I my brain realized that was a model number and not
> a year.
>
> Blue skies and tail winds.
>
> Enjoy your next set of activities.
>
> Regards,
> Steve Thompson
>
> On 2/26/2024 2:51 PM, Sean Gleann wrote:
> > This list has been a great source of ideas and information, although I've
> > never really been a 'contributor' here, but more of a 'lurker'. Whenever
> > I've seen a thread that I might be able to respond to, someone else gets
> in
> > first with a response very similar to the one that I thought of.
> >
> > So, I hope you won't mind me speaking up now to say that it's time for
> this
> > tired old mainframer to toddle off into the sunset... after 50 years of
> > working with mainframe systems, I feel it's time to hang up my keyboard
> and
> > call it a day.
> >
> > I first started on an ICL 1904 - punched cards, paper tape, core memory,
> > 60MB disks, GEORGE II - but quickly saw the light and moved to another
> > employer that used a 360/30 roughly 8 years after the series was first
> > marketed. Since then, aside from a brief entanglement with a Burroughs
> > B4700, it's been IBM all the way.
> >
> > I have to say that it's (mostly) been a lot of fun. From one aspect, I've
> > never really worked a day in my life. Instead, I've been paid a lot of
> > money to play on other people's expensive toys.
> >
> > Here's wishing all of you good luck and good fortune for the future. I'll
> > be thinking about doing some travelling - haven't made it to South
> America
> > or Africa yet.
> >
> > Regards
> > Sean o'bhaile na Gleann
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> Regards, Steve Thompson
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Signing off

[Martin Packer]

My Dad (now long since retired) worked with 1904’s and then 29xx and 39xx.

(He also had IBM kit in the end – 3090 – but that isn’t really how I got into 
IBM.) 

I think there was / is a 1904 in the Science Museum in London.

Cheers, Martin

From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Date: Monday, 26 February 2024 at 22:02
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [EXTERNAL] Re: Signing off
I had to re-read that line "first started on an ICL 1904" a few
times before I my brain realized that was a model number and not
a year.

Blue skies and tail winds.

Enjoy your next set of activities.

Regards,
Steve Thompson

On 2/26/2024 2:51 PM, Sean Gleann wrote:
> This list has been a great source of ideas and information, although I've
> never really been a 'contributor' here, but more of a 'lurker'. Whenever
> I've seen a thread that I might be able to respond to, someone else gets in
> first with a response very similar to the one that I thought of.
>
> So, I hope you won't mind me speaking up now to say that it's time for this
> tired old mainframer to toddle off into the sunset... after 50 years of
> working with mainframe systems, I feel it's time to hang up my keyboard and
> call it a day.
>
> I first started on an ICL 1904 - punched cards, paper tape, core memory,
> 60MB disks, GEORGE II - but quickly saw the light and moved to another
> employer that used a 360/30 roughly 8 years after the series was first
> marketed. Since then, aside from a brief entanglement with a Burroughs
> B4700, it's been IBM all the way.
>
> I have to say that it's (mostly) been a lot of fun. From one aspect, I've
> never really worked a day in my life. Instead, I've been paid a lot of
> money to play on other people's expensive toys.
>
> Here's wishing all of you good luck and good fortune for the future. I'll
> be thinking about doing some travelling - haven't made it to South America
> or Africa yet.
>
> Regards
> Sean o'bhaile na Gleann
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Regards, Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN