Re: TOD clock values, leap seconds and BLSUXTOD conversion service

[Farley, Peter x23353]

I stand corrected.  Thanks for decreasing my ignorance in this area with those 
links.

Peter R., apologies for my mistaken understanding of the TOD clock value.  I 
now much better appreciate your repeated statements about the TOD clock value 
being architecturally TAI - 10.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, December 29, 2018 1:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service

On Fri, 28 Dec 2018 23:52:07 -0600, Paul Gilmartin wrote:
>> ...
>I believe otherwise.  In order to avoid discontinuities at leap seconds of the 
>sort
>that cause network failures:
>
> https://en.wikipedia.org/wiki/Leap_second#Examples_of_problems_associated_with_the_leap_second
>the TOD clock runs (**at IBM's strong recommendation**) at a constant rate,
>TAI - 10 seconds.  (I know no clear documentation of this (can someone help 
>me?),
>but inferred it by converting the hex values in the PoOps.)
>
Ah!  Found it!

4.6.1.5 "z/Architecture Principles of Operation" IBM Library Server

https://www.ibm.com/support/libraryserver_os390/BOOKS/DZ9ZR003/4.6.1.5?SHELF=ez2vse00=20040504121320
 4.6.1.5 TOD Programmable Register
...
For the same reasons, conversion between ETR time and UTC does not take
into consideration the time adjustments prior to 1972, and, thus, ETR time
differs from TAI by a fixed amount of 10 seconds. Because of the occurrence
of 22 leap seconds, UTC now is behind TAI by 32 seconds.

--


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: TOD clock values, leap seconds and BLSUXTOD conversion service

[Paul Gilmartin]

On Fri, 28 Dec 2018 23:52:07 -0600, Paul Gilmartin wrote:
>> ...
>I believe otherwise.  In order to avoid discontinuities at leap seconds of the 
>sort
>that cause network failures:
>
> https://en.wikipedia.org/wiki/Leap_second#Examples_of_problems_associated_with_the_leap_second
>the TOD clock runs (**at IBM's strong recommendation**) at a constant rate,
>TAI - 10 seconds.  (I know no clear documentation of this (can someone help 
>me?),
>but inferred it by converting the hex values in the PoOps.)
>
Ah!  Found it!

4.6.1.5 "z/Architecture Principles of Operation" IBM Library Server

https://www.ibm.com/support/libraryserver_os390/BOOKS/DZ9ZR003/4.6.1.5?SHELF=ez2vse00=20040504121320
 4.6.1.5 TOD Programmable Register
...
For the same reasons, conversion between ETR time and UTC does not take
into consideration the time adjustments prior to 1972, and, thus, ETR time
differs from TAI by a fixed amount of 10 seconds. Because of the occurrence
of 22 leap seconds, UTC now is behind TAI by 32 seconds.

-- gil

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

Re: TOD clock values, leap seconds and BLSUXTOD conversion service

[Paul Gilmartin]

On Sat, 29 Dec 2018 05:21:30 +, Farley, Peter x23353 wrote:

>"A STCK value came from the clock and is not to be considered UTC time."
>
>Then what is STP/NTP (or whatever the current mechanism is named) supposed to 
>do?  Isn't the entire point of a hardware clock-setting mechanism to set the 
>hardware clock to some agreed-upon and internationally-supported standard 
>time?  Isn't that agreed-upon time (**at IBM's strong recommendation**) at 
>least UTC time?  If so then STCK/STCKE/STCKF do indeed produce UTC time as a 
>function of the IBM-chosen hardware epoch.  QED.
> 
I believe otherwise.  In order to avoid discontinuities at leap seconds of the 
sort
that cause network failures:

https://en.wikipedia.org/wiki/Leap_second#Examples_of_problems_associated_with_the_leap_second
the TOD clock runs (**at IBM's strong recommendation**) at a constant rate,
TAI - 10 seconds.  (I know no clear documentation of this (can someone help 
me?),
but inferred it by converting the hex values in the PoOps.)  So I believe that 
STCK
followed by STCKCONV will return TAI - 10 seconds at the instant of the STCK.  
Not
very useful, nor intuitive.  The more reason for documenting affirmatively, not
merely stating what it *does*not*do*.

-- gil

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

Re: TOD clock values, leap seconds and BLSUXTOD conversion service

[Farley, Peter x23353]

"A STCK value came from the clock and is not to be considered UTC time."

Then what is STP/NTP (or whatever the current mechanism is named) supposed to 
do?  Isn't the entire point of a hardware clock-setting mechanism to set the 
hardware clock to some agreed-upon and internationally-supported standard time? 
 Isn't that agreed-upon time (**at IBM's strong recommendation**) at least UTC 
time?  If so then STCK/STCKE/STCKF do indeed produce UTC time as a function of 
the IBM-chosen hardware epoch.  QED.

As I said in my prior reply, I agree that the existing conversion services 
should not change.  I have no argument with you on that subject.

"Make the case . . . " The case is for IBM z/OS developers to make why to do 
it, not for its users to make for them.  Have a little pride, make the system 
the best that it can be regardless of whether users think it is "needed" or not 
(many of us DO think it is "needed" but are in no political position to "make a 
case" to anyone).  You seem to want user CIO's and CEO's to "make the case" for 
you to your management instead of z/OS developers making the case themselves, 
when user CIO's and CEO's couldn't care a fig for whether it's accurate or not, 
only whether it affects their yearly bonus or not.

Don't subscribe to "the minimum necessary effort that is profitable" cavil.  
That rabbit-hole is endless and evil, even if it is the common corporate 
thinking these days.  Subscribe instead to "the best that I can produce despite 
management roadblocks".  You will be much happier for it, and in the end so 
will your management.

>From my personal perspective, yes it is about "locale-ly correct" time.  Human 
>users of the output from z/OS systems may indeed be able to "deal with it" 
>when the time is not "locale-ly correct", but it does not mean they are happy 
>to do so.  A z/OS programmer's job is to make those people happy.  So please 
>make z/OS programmers happy so they can make their users happy too.  That is a 
>"win-win" in the current vernacular.

And I am sorry, but I do not buy into the notion of "limited resources" at a 
multi-billion-dollar company.  Your management can make just as much "resource" 
available as they think will affect their own yearly bonus.  It's your job to 
make your management think that it does affect their bonus, not your users' job.

Don't ask for a reason; create one that makes your management happy and then 
"just do it".

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Friday, December 28, 2018 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service

There is an architectural definition of what a tick in bit 51 of the 64-bit TOD 
clock.
Thus a given clock value (bits 0-51) represents the number of microseconds 
since the start of the epoch being used.
It seems true that STCKCONV assumes the standard epoch. As I said, if that is 
not mentioned in the doc, I'd be in favor of doing so.

A STCK value came from the clock and is not to be considered UTC time. Why then 
should STCKCONV which is converting an input STCK value (not an input UTC 
value) provide a UTC date/time? If you want to provide a UTC clock value, then 
you could presumably do so.

Should the service(s) factor in leap seconds? It no longer matters. They could 
not be changed to do so, since it would be incompatible. They could be enhanced 
to do so with a new non-default option but there would have to be a business 
case for that, and at this point no one has come close to making one. Therefore 
the thing to do is to document the current behavior, for which I've already 
said that I'm OK with indicating that this does not factor in leap seconds. I 
think Gil indicated he had submitted, or would submit, an RCF.

As far as I know, none of the BCP-provided time services (TIME, STCKCONV, 
CONVTOD, BLSUXTOD, etc) pay attention to leap seconds. Nor are they likely ever 
to do so, if only because no one wants to have to update them whenever a leap 
second "shows up". 

If you want a service that does something with a historical time stamp and leap 
seconds, make the case. It hasn't been made in all the years since the first 
leap second. Maybe that's because humans don't truly need to know that level of 
precision for "old dates". 

Is this discussion similar to the question about "local time"?  I don't see 
many people trying to factor into a display of time/date from a historical time 
stamp just when day light savings kicked in or out. I think local time is 
considered to be for humans and that it is thought that humans can "deal with 
it". 

--

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 

Re: BLSUXTOD

[Paul Gilmartin]

On Fri, 28 Dec 2018 21:57:43 -0600, Joe Monk wrote:

>>"By my arithmetic,  January 1, 1900 + 143 years = January 1, 2043".
>
>Ummm ... Did you forget the year 1900? Theres only 142 years left after you
>subtract the Year 1900.
>
WTF!?

So, by that reasoning, January 1, 1900 + 1 year = January 1, 1900 because
there are 0 years left after you subtract the year 1900.

>> On Fri, 28 Dec 2018 18:18:51 -0600, Joe Monk wrote:
>>
>> >So, January 1, 1900 + 143 years = January 1, 2042, which is when the 104
>> >bit clock will roll over, and bit 0 will return to zero.

-- gil

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

Re: BLSUXTOD

[Joe Monk]

"By my arithmetic,  January 1, 1900 + 143 years = January 1, 2043".

Ummm ... Did you forget the year 1900? Theres only 142 years left after you
subtract the Year 1900.

"How are those bits numbered?  0 to 103?  What's the value of bit 0?  What's
the value of bit 103?"

Yes, 0 to 103. Bit 51 is incremented every 1 microsecond. Carries are
propagated out of bit 0.

Joe



On Fri, Dec 28, 2018 at 8:32 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 28 Dec 2018 18:18:51 -0600, Joe Monk wrote:
>
> >So if you read the POO, you see:
> >
> >   - Communication between systems is facilitated by establishing a
> >   standard time origin that is the calendar date and time to which a
> clock
> >   value of zero corresponds. January 1, 1900, 0 a.m. Coordinated
> Universal
> >   Time (UTC) is recommended as this origin, and it is said to begin the
> >   standard epoch for the clock.
> >
> >   - The time-of-day (TOD) clock provides a high- resolution measure of
> >   real time suitable for the indication of date and time of day. The
> cycle of
> >   the clock is approximately 143 years.
> >
> >   - The TOD clock is a 104-bit register.
> >
> How are those bits numbered?  0 to 103?  What's the value of bit 0?  What's
> the value of bit 103?
>
> >So, January 1, 1900 + 143 years = January 1, 2042, which is when the 104
> >bit clock will roll over, and bit 0 will return to zero.
> >
> By my arithmetic,  January 1, 1900 + 143 years = January 1, 2043.
>
> Doesn't forcing bit 0 to 1 as described below restrict the cycle of the
> clock
> to 71 years rather than the 143 years from 1971 to 2114 stated below?
>
> >On Fri, Dec 28, 2018 at 5:06 PM Paul Gilmartin wrote:
> >
> >> In: MVS Interactive Problem Control System (IPCS) Customization
> >> Version 2 Release 3  SA23-1383-30
> >>
> >> I read:
> >> TOD Clock Service
> >> The time-of-day (TOD) clock service provides a caller, including
> your exit routine,
> >> with a TOD clock image. In the clock image, bit 0 is set on to
> allow the service to
> >> handle values from May 11,1971, at 11:56:53.685248 to January 25,
> 2114, at
> >> 11:50:41.055743.
> >>
> >> ???
> >> But in PoOps I see
> >> ...
> >> If the programming support uses the standard epoch, bit 0 of the
> clock
> >> remains one
> >> through the years 1972-2041. (Bit 0 turned on at 11:56:53.685248
> (UTC)
> >> May 11, 1971.)
> >>
> >> I'm inclined to believe the latter, and that Bit 0 returns to 0, not 1,
> in
> >> September, 2042.
> >> Is there an error in the IPCS doc?
>
> -- 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: BLSUXTOD

[Paul Gilmartin]

On Fri, 28 Dec 2018 18:18:51 -0600, Joe Monk wrote:

>So if you read the POO, you see:
>
>   - Communication between systems is facilitated by establishing a
>   standard time origin that is the calendar date and time to which a clock
>   value of zero corresponds. January 1, 1900, 0 a.m. Coordinated Universal
>   Time (UTC) is recommended as this origin, and it is said to begin the
>   standard epoch for the clock.
>
>   - The time-of-day (TOD) clock provides a high- resolution measure of
>   real time suitable for the indication of date and time of day. The cycle of
>   the clock is approximately 143 years.
>
>   - The TOD clock is a 104-bit register.
>
How are those bits numbered?  0 to 103?  What's the value of bit 0?  What's
the value of bit 103?

>So, January 1, 1900 + 143 years = January 1, 2042, which is when the 104
>bit clock will roll over, and bit 0 will return to zero.
>
By my arithmetic,  January 1, 1900 + 143 years = January 1, 2043.

Doesn't forcing bit 0 to 1 as described below restrict the cycle of the clock
to 71 years rather than the 143 years from 1971 to 2114 stated below?

>On Fri, Dec 28, 2018 at 5:06 PM Paul Gilmartin wrote:
>
>> In: MVS Interactive Problem Control System (IPCS) Customization
>> Version 2 Release 3  SA23-1383-30
>>
>> I read:
>> TOD Clock Service
>> The time-of-day (TOD) clock service provides a caller, including your 
>> exit routine,
>> with a TOD clock image. In the clock image, bit 0 is set on to allow the 
>> service to
>> handle values from May 11,1971, at 11:56:53.685248 to January 25, 2114, 
>> at
>> 11:50:41.055743.
>>
>> ???
>> But in PoOps I see
>> ...
>> If the programming support uses the standard epoch, bit 0 of the clock
>> remains one
>> through the years 1972-2041. (Bit 0 turned on at 11:56:53.685248 (UTC)
>> May 11, 1971.)
>>
>> I'm inclined to believe the latter, and that Bit 0 returns to 0, not 1, in
>> September, 2042.
>> Is there an error in the IPCS doc?

-- gil

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

Re: How about a little Christmas fudge? | Computerworld Shark tank

[scott Ford]

All I can say is computers, Mainframe and PC have changed so much, who can
keep up.
I am kinda there now, Java Java is all I hear and no IBM z type projects.
Time moves on..

Scott

On Fri, Dec 28, 2018 at 5:22 PM Seymour J Metz  wrote:

> Well, I started on a 650, but I once saw a post here from Werner Buchholz;
> you don't get much old timer than that.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of scott Ford 
> Sent: Friday, December 28, 2018 4:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How about a little Christmas fudge? | Computerworld Shark tank
>
> Boy I thought I was an old timer, BAL on a 360-20 ...I feel better,
> your..lol
>
> Scott
>
> On Fri, Dec 28, 2018 at 4:37 PM Seymour J Metz  wrote:
>
> > I never mentioned the Altos; you did.
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Wayne Bickerdike 
> > Sent: Friday, December 28, 2018 3:41 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
> tank
> >
> > "If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's
> not
> > a mainframe, nor is the 1401."
> >
> > I'll pick nits. Altos was not S100 bus.Cromemco was. Next?
> >
> > I was in short pants when 1401 was a mainframe. Long pants with Z80. So
> my
> > memory is hazy. Just remember older peers talking about 1401 autocoder.
> >
> > On Sat, Dec 29, 2018 at 7:10 AM Seymour J Metz  wrote:
> >
> > > If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's
> > not
> > > a mainframe, nor is the 1401.
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> behalf
> > > of Wayne Bickerdike 
> > > Sent: Thursday, December 27, 2018 10:20 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
> > tank
> > >
> > > Z80 was a processor. How could it possibly crop up in a discussion
> about
> > > what constitutes a mainframe?
> > >
> > > The Altos 8000 was Z80 based as was the North Star Horizon and the
> > Cromemco
> > > System 3. I worked with these in the 70's to *escape* from the
> mainframe,
> > > the demise of which was imminent. LOL.
> > >
> > > Anything you can carry to the boot (trunk) of your car cannot be a
> > > mainframe:)
> > >
> > > On Fri, Dec 28, 2018 at 6:35 AM Seymour J Metz  wrote:
> > >
> > > > > Well, ...  the IBM 1401 was built in a substantial frame;
> > > >
> > > > Substantial? Look at Figure 1 in
> > > >
> > >
> >
> http://secure-web.cisco.com/1zGfHVf_OSYTQR-iZeSwUT8hxfRxttRuC64KrmAu3AhbMnt6LyyW-Hp7yUNcU7paWuZbaHN-dbxbJnuJHOx9LIqoVZWk7vzR-Zf_OX4a-ClGtjfSbOPIVMFxIYkYFtcTq3wcZWdiCj-mXgIPGWhxl28vAMZ1aONn5mbNieTKHYzw1k0c2PV0LwDte-VgAq97Jx2hDglzP552wj1RSpk5G_qZ_RDsEi7dChi57va08L87z1kDPeqAKuNsBN2Q7B6n_eifj13cYJcD8Yt0Kvnqcp-EOUAILLbudkLUwdnk4-_f08qEDAsB2PwtlvypFOcQPHqfJ0Xr4VAHmbroBTURny__aAFNQh_eMyKMzSVkqdPg3lYYZ6mCOVtUUmQe7i0Z4HxuWC0BQn26sEcrnl20BORwkDAq-Yvee0rnuF4AyYxT2sKH_bL1pTZCR5VLHMUzp/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F1401%2FA24-1401-1_1401_System_Summary_Sep64.pdf
> > > > .
> > > >
> > > > >  it appears to have the only
> > > >
> > > > If a Z-80 had been the only computer mentioned, would you have called
> > it
> > > a
> > > > mainframe?
> > > >
> > > > > Other members of the same general family like IBM 1410 were
> certainly
> > > > regarded as a mainframe.
> > > >
> > > >
> > > > The 7010 was certainly called a mainframe, and possibly the 1410, but
> > > > never the 1440 or 1460.
> > > >
> > > > > With a recent MS in Comp Sci, I found myself in the U.S. Army
> > 1969-1971
> > > > > (started in Infantry but ended up as head Company Clerk at HHC of
> > "The
> > > > > Old Guard" at Ft Myer VA).  I remember reading some memo that came
> > down
> > > > > from above the Battalion suggesting the possibility of using a
> > > > > punched-card-based system for maintaining and producing our Company
> > > > > Roster.  That might have involved an IBM 1401,
> > > >
> > > > More likely a UNIVAC 1005.
> > > >
> > > > --
> > > > Shmuel (Seymour J.) Metz
> > > > http://mason.gmu.edu/~smetz3
> > > >
> > > > 
> > > > From: IBM Mainframe Discussion List  on
> > behalf
> > > > of Joel C. Ewing 
> > > > Sent: Wednesday, December 26, 2018 11:56 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: How about a little Christmas fudge? | Computerworld
> Shark
> > > tank
> > > >
> > > > Well, ...  the IBM 1401 was built in a substantial frame; and in the
> > > > context cited it appears to have the only (hence surely the "main")
> > > > computer present.  Other members of the same general family like IBM
> > > > 1410 were 

Re: IBM Mapping macro for ISPF statistics in PDS Directory entries?

[Ed Jaffe]

On 12/28/2018 2:40 PM, David Cole wrote:


I'm looking for an IBM written mapping macro for the ISPF statistics 
found in PDS directory entries. I've searched high and low, but I'm 
not having much luck.


We had the same issue and ended up constructing our own.

We never would have done so if an IBM macro existed...


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

Re: BLSUXTOD

[Joe Monk]

So if you read the POO, you see:


   - Communication between systems is facilitated by establishing a
   standard time origin that is the calendar date and time to which a clock
   value of zero corresponds. January 1, 1900, 0 a.m. Coordinated Universal
   Time (UTC) is recommended as this origin, and it is said to begin the
   standard epoch for the clock.



   - The time-of-day (TOD) clock provides a high- resolution measure of
   real time suitable for the indication of date and time of day. The cycle of
   the clock is approximately 143 years.



   - The TOD clock is a 104-bit register.


So, January 1, 1900 + 143 years = January 1, 2042, which is when the 104
bit clock will roll over, and bit 0 will return to zero.

Joe

On Fri, Dec 28, 2018 at 5:06 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> In: MVS Interactive Problem Control System (IPCS) Customization
> Version 2 Release 3  SA23-1383-30
>
> I read:
> TOD Clock Service
> The time-of-day (TOD) clock service provides a caller, including your
> exit routine,
> with a TOD clock image. In the clock image, bit 0 is set on to allow
> the service to
> handle values from May 11,1971, at 11:56:53.685248 to January 25,
> 2114, at
> 11:50:41.055743.
>
> ???
> But in PoOps I see
> ...
> If the programming support uses the standard epoch, bit 0 of the clock
> remains one
> through the years 1972-2041. (Bit 0 turned on at 11:56:53.685248 (UTC)
> May 11, 1971.)
>
> I'm inclined to believe the latter, and that Bit 0 returns to 0, not 1, in
> September, 2042.
> Is there an error in the IPCS doc?
>
> -- 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: TOD clock values, leap seconds and BLSUXTOD conversion service

[Paul Gilmartin]

On Fri, 28 Dec 2018 14:46:41 -0500, Peter Relson wrote:

>I shouldn't have included "TIME" among the services I mentioned because 
>that's "current", not "historic" (so only has to deal with "current" leap 
>seconds) and because it does not let you choose STCK as the "zone" -- you 
>
Not as the "xone", but as the format.

>must choose between local and UTC, both of which are defined with respect 
>to leap seconds. 
>
>Thus it must handle leap seconds, but also is not in the position of 
>needing update for a "new" leap second.
> 
I believe STP does this magically, in CVTLSO.  And user tasks are paused, 
magically, during a leap second.  PoOps has tables of leap seconds, almost
up-to-date.  That's what TNLs used to be for.

>And, in case you're wondering, at the "instant" of bringing in a new leap 
>second, there are various approaches in play that customers choose to 
>adopt and I doubt that it is deterministic on which side of the fence you 
>would necessarily fall if you used some service such as TIME (or if you 
>did it yourself) -- perhaps the STCK was done "just before" but reference 
>to CVTLSO was "just after". Something similar could happen with respect to 
>time zone offset changes.
> 
Does TIME protect against this improbable occurrence?  Remember Murphy!

I can imagine only:
RETRY: copy CVTLSO and CVTLDTO into private storage
   STCK
   compare copied values to CVTLSO and CVTLDTO
   BNE RETRY
   proceed with conversion

Does TIME do something similar?  Does STP serialize updates to CVTLSO
and CVTLDTO?  Does TIME use STCK or STCKF?  Does this reload cache
for the compare if necessary?

Suspending user tasks during leap second doesn't help.

Remember Murphy.

-- gil

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

BLSUXTOD

[Paul Gilmartin]

In: MVS Interactive Problem Control System (IPCS) Customization
Version 2 Release 3  SA23-1383-30

I read:
TOD Clock Service
The time-of-day (TOD) clock service provides a caller, including your exit 
routine,
with a TOD clock image. In the clock image, bit 0 is set on to allow the 
service to
handle values from May 11,1971, at 11:56:53.685248 to January 25, 2114, at
11:50:41.055743.

???
But in PoOps I see
...
If the programming support uses the standard epoch, bit 0 of the clock 
remains one
through the years 1972-2041. (Bit 0 turned on at 11:56:53.685248 (UTC) May 
11, 1971.)

I'm inclined to believe the latter, and that Bit 0 returns to 0, not 1, in 
September, 2042.
Is there an error in the IPCS doc?

-- gil

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

IBM Mapping macro for ISPF statistics in PDS Directory entries?

[David Cole]

Hi,

I'm looking for an IBM written mapping macro for the ISPF statistics 
found in PDS directory entries. I've searched high and low, but I'm 
not having much luck.


Certainly, I could write a mapping macro myself, but I'd rather not 
if IBM already has one.




I know about IHAPDS, but that maps load module related data, not ISPF 
statistics.


I know about the doc that's present in ISPF's "Dialog Developer's 
Guide and Reference", but that's not what I'm looking for. (I already 
know what the fields are.)




Thanks in advance.

Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware

Tools:   z/XDC for Assembler debugging
 c/XDC 
for C debugging  


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

Re: How about a little Christmas fudge? | Computerworld Shark tank

[Seymour J Metz]

Well, I started on a 650, but I once saw a post here from Werner Buchholz; you 
don't get much old timer than that.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
scott Ford 
Sent: Friday, December 28, 2018 4:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How about a little Christmas fudge? | Computerworld Shark tank

Boy I thought I was an old timer, BAL on a 360-20 ...I feel better,
your..lol

Scott

On Fri, Dec 28, 2018 at 4:37 PM Seymour J Metz  wrote:

> I never mentioned the Altos; you did.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Wayne Bickerdike 
> Sent: Friday, December 28, 2018 3:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How about a little Christmas fudge? | Computerworld Shark tank
>
> "If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's not
> a mainframe, nor is the 1401."
>
> I'll pick nits. Altos was not S100 bus.Cromemco was. Next?
>
> I was in short pants when 1401 was a mainframe. Long pants with Z80. So my
> memory is hazy. Just remember older peers talking about 1401 autocoder.
>
> On Sat, Dec 29, 2018 at 7:10 AM Seymour J Metz  wrote:
>
> > If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's
> not
> > a mainframe, nor is the 1401.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Wayne Bickerdike 
> > Sent: Thursday, December 27, 2018 10:20 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
> tank
> >
> > Z80 was a processor. How could it possibly crop up in a discussion about
> > what constitutes a mainframe?
> >
> > The Altos 8000 was Z80 based as was the North Star Horizon and the
> Cromemco
> > System 3. I worked with these in the 70's to *escape* from the mainframe,
> > the demise of which was imminent. LOL.
> >
> > Anything you can carry to the boot (trunk) of your car cannot be a
> > mainframe:)
> >
> > On Fri, Dec 28, 2018 at 6:35 AM Seymour J Metz  wrote:
> >
> > > > Well, ...  the IBM 1401 was built in a substantial frame;
> > >
> > > Substantial? Look at Figure 1 in
> > >
> >
> http://secure-web.cisco.com/1zGfHVf_OSYTQR-iZeSwUT8hxfRxttRuC64KrmAu3AhbMnt6LyyW-Hp7yUNcU7paWuZbaHN-dbxbJnuJHOx9LIqoVZWk7vzR-Zf_OX4a-ClGtjfSbOPIVMFxIYkYFtcTq3wcZWdiCj-mXgIPGWhxl28vAMZ1aONn5mbNieTKHYzw1k0c2PV0LwDte-VgAq97Jx2hDglzP552wj1RSpk5G_qZ_RDsEi7dChi57va08L87z1kDPeqAKuNsBN2Q7B6n_eifj13cYJcD8Yt0Kvnqcp-EOUAILLbudkLUwdnk4-_f08qEDAsB2PwtlvypFOcQPHqfJ0Xr4VAHmbroBTURny__aAFNQh_eMyKMzSVkqdPg3lYYZ6mCOVtUUmQe7i0Z4HxuWC0BQn26sEcrnl20BORwkDAq-Yvee0rnuF4AyYxT2sKH_bL1pTZCR5VLHMUzp/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F1401%2FA24-1401-1_1401_System_Summary_Sep64.pdf
> > > .
> > >
> > > >  it appears to have the only
> > >
> > > If a Z-80 had been the only computer mentioned, would you have called
> it
> > a
> > > mainframe?
> > >
> > > > Other members of the same general family like IBM 1410 were certainly
> > > regarded as a mainframe.
> > >
> > >
> > > The 7010 was certainly called a mainframe, and possibly the 1410, but
> > > never the 1440 or 1460.
> > >
> > > > With a recent MS in Comp Sci, I found myself in the U.S. Army
> 1969-1971
> > > > (started in Infantry but ended up as head Company Clerk at HHC of
> "The
> > > > Old Guard" at Ft Myer VA).  I remember reading some memo that came
> down
> > > > from above the Battalion suggesting the possibility of using a
> > > > punched-card-based system for maintaining and producing our Company
> > > > Roster.  That might have involved an IBM 1401,
> > >
> > > More likely a UNIVAC 1005.
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> behalf
> > > of Joel C. Ewing 
> > > Sent: Wednesday, December 26, 2018 11:56 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
> > tank
> > >
> > > Well, ...  the IBM 1401 was built in a substantial frame; and in the
> > > context cited it appears to have the only (hence surely the "main")
> > > computer present.  Other members of the same general family like IBM
> > > 1410 were certainly regarded as a mainframe.  I'm pretty sure any
> > > computer large enough to require one or more dedicated frames  was
> > > called a "mainframe" in those days.  When mini-computers first came
> out,
> > > they weren't considered mainframes because they were typically only the
> > > size of a single rack and could even be carried.
> > >
> > >  With a recent MS in Comp Sci, I found myself in the U.S. Army
> 1969-1971
> > > (started in Infantry but ended up as head Company Clerk at HHC of 

Re: How about a little Christmas fudge? | Computerworld Shark tank

[scott Ford]

Boy I thought I was an old timer, BAL on a 360-20 ...I feel better,
your..lol

Scott

On Fri, Dec 28, 2018 at 4:37 PM Seymour J Metz  wrote:

> I never mentioned the Altos; you did.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Wayne Bickerdike 
> Sent: Friday, December 28, 2018 3:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How about a little Christmas fudge? | Computerworld Shark tank
>
> "If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's not
> a mainframe, nor is the 1401."
>
> I'll pick nits. Altos was not S100 bus.Cromemco was. Next?
>
> I was in short pants when 1401 was a mainframe. Long pants with Z80. So my
> memory is hazy. Just remember older peers talking about 1401 autocoder.
>
> On Sat, Dec 29, 2018 at 7:10 AM Seymour J Metz  wrote:
>
> > If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's
> not
> > a mainframe, nor is the 1401.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Wayne Bickerdike 
> > Sent: Thursday, December 27, 2018 10:20 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
> tank
> >
> > Z80 was a processor. How could it possibly crop up in a discussion about
> > what constitutes a mainframe?
> >
> > The Altos 8000 was Z80 based as was the North Star Horizon and the
> Cromemco
> > System 3. I worked with these in the 70's to *escape* from the mainframe,
> > the demise of which was imminent. LOL.
> >
> > Anything you can carry to the boot (trunk) of your car cannot be a
> > mainframe:)
> >
> > On Fri, Dec 28, 2018 at 6:35 AM Seymour J Metz  wrote:
> >
> > > > Well, ...  the IBM 1401 was built in a substantial frame;
> > >
> > > Substantial? Look at Figure 1 in
> > >
> >
> http://secure-web.cisco.com/1zGfHVf_OSYTQR-iZeSwUT8hxfRxttRuC64KrmAu3AhbMnt6LyyW-Hp7yUNcU7paWuZbaHN-dbxbJnuJHOx9LIqoVZWk7vzR-Zf_OX4a-ClGtjfSbOPIVMFxIYkYFtcTq3wcZWdiCj-mXgIPGWhxl28vAMZ1aONn5mbNieTKHYzw1k0c2PV0LwDte-VgAq97Jx2hDglzP552wj1RSpk5G_qZ_RDsEi7dChi57va08L87z1kDPeqAKuNsBN2Q7B6n_eifj13cYJcD8Yt0Kvnqcp-EOUAILLbudkLUwdnk4-_f08qEDAsB2PwtlvypFOcQPHqfJ0Xr4VAHmbroBTURny__aAFNQh_eMyKMzSVkqdPg3lYYZ6mCOVtUUmQe7i0Z4HxuWC0BQn26sEcrnl20BORwkDAq-Yvee0rnuF4AyYxT2sKH_bL1pTZCR5VLHMUzp/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F1401%2FA24-1401-1_1401_System_Summary_Sep64.pdf
> > > .
> > >
> > > >  it appears to have the only
> > >
> > > If a Z-80 had been the only computer mentioned, would you have called
> it
> > a
> > > mainframe?
> > >
> > > > Other members of the same general family like IBM 1410 were certainly
> > > regarded as a mainframe.
> > >
> > >
> > > The 7010 was certainly called a mainframe, and possibly the 1410, but
> > > never the 1440 or 1460.
> > >
> > > > With a recent MS in Comp Sci, I found myself in the U.S. Army
> 1969-1971
> > > > (started in Infantry but ended up as head Company Clerk at HHC of
> "The
> > > > Old Guard" at Ft Myer VA).  I remember reading some memo that came
> down
> > > > from above the Battalion suggesting the possibility of using a
> > > > punched-card-based system for maintaining and producing our Company
> > > > Roster.  That might have involved an IBM 1401,
> > >
> > > More likely a UNIVAC 1005.
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> behalf
> > > of Joel C. Ewing 
> > > Sent: Wednesday, December 26, 2018 11:56 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
> > tank
> > >
> > > Well, ...  the IBM 1401 was built in a substantial frame; and in the
> > > context cited it appears to have the only (hence surely the "main")
> > > computer present.  Other members of the same general family like IBM
> > > 1410 were certainly regarded as a mainframe.  I'm pretty sure any
> > > computer large enough to require one or more dedicated frames  was
> > > called a "mainframe" in those days.  When mini-computers first came
> out,
> > > they weren't considered mainframes because they were typically only the
> > > size of a single rack and could even be carried.
> > >
> > >  With a recent MS in Comp Sci, I found myself in the U.S. Army
> 1969-1971
> > > (started in Infantry but ended up as head Company Clerk at HHC of "The
> > > Old Guard" at Ft Myer VA).  I remember reading some memo that came down
> > > from above the Battalion suggesting the possibility of using a
> > > punched-card-based system for maintaining and producing our Company
> > > Roster.  That might have involved an IBM 1401, but my impression at the
> > > time was that the functions they were describing could easily have been
> > > done with just unit-record equipment.  

Re: How about a little Christmas fudge? | Computerworld Shark tank

[Seymour J Metz]

I never mentioned the Altos; you did.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Wayne Bickerdike 
Sent: Friday, December 28, 2018 3:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How about a little Christmas fudge? | Computerworld Shark tank

"If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's not
a mainframe, nor is the 1401."

I'll pick nits. Altos was not S100 bus.Cromemco was. Next?

I was in short pants when 1401 was a mainframe. Long pants with Z80. So my
memory is hazy. Just remember older peers talking about 1401 autocoder.

On Sat, Dec 29, 2018 at 7:10 AM Seymour J Metz  wrote:

> If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's not
> a mainframe, nor is the 1401.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Wayne Bickerdike 
> Sent: Thursday, December 27, 2018 10:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How about a little Christmas fudge? | Computerworld Shark tank
>
> Z80 was a processor. How could it possibly crop up in a discussion about
> what constitutes a mainframe?
>
> The Altos 8000 was Z80 based as was the North Star Horizon and the Cromemco
> System 3. I worked with these in the 70's to *escape* from the mainframe,
> the demise of which was imminent. LOL.
>
> Anything you can carry to the boot (trunk) of your car cannot be a
> mainframe:)
>
> On Fri, Dec 28, 2018 at 6:35 AM Seymour J Metz  wrote:
>
> > > Well, ...  the IBM 1401 was built in a substantial frame;
> >
> > Substantial? Look at Figure 1 in
> >
> http://secure-web.cisco.com/1zGfHVf_OSYTQR-iZeSwUT8hxfRxttRuC64KrmAu3AhbMnt6LyyW-Hp7yUNcU7paWuZbaHN-dbxbJnuJHOx9LIqoVZWk7vzR-Zf_OX4a-ClGtjfSbOPIVMFxIYkYFtcTq3wcZWdiCj-mXgIPGWhxl28vAMZ1aONn5mbNieTKHYzw1k0c2PV0LwDte-VgAq97Jx2hDglzP552wj1RSpk5G_qZ_RDsEi7dChi57va08L87z1kDPeqAKuNsBN2Q7B6n_eifj13cYJcD8Yt0Kvnqcp-EOUAILLbudkLUwdnk4-_f08qEDAsB2PwtlvypFOcQPHqfJ0Xr4VAHmbroBTURny__aAFNQh_eMyKMzSVkqdPg3lYYZ6mCOVtUUmQe7i0Z4HxuWC0BQn26sEcrnl20BORwkDAq-Yvee0rnuF4AyYxT2sKH_bL1pTZCR5VLHMUzp/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F1401%2FA24-1401-1_1401_System_Summary_Sep64.pdf
> > .
> >
> > >  it appears to have the only
> >
> > If a Z-80 had been the only computer mentioned, would you have called it
> a
> > mainframe?
> >
> > > Other members of the same general family like IBM 1410 were certainly
> > regarded as a mainframe.
> >
> >
> > The 7010 was certainly called a mainframe, and possibly the 1410, but
> > never the 1440 or 1460.
> >
> > > With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
> > > (started in Infantry but ended up as head Company Clerk at HHC of "The
> > > Old Guard" at Ft Myer VA).  I remember reading some memo that came down
> > > from above the Battalion suggesting the possibility of using a
> > > punched-card-based system for maintaining and producing our Company
> > > Roster.  That might have involved an IBM 1401,
> >
> > More likely a UNIVAC 1005.
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Joel C. Ewing 
> > Sent: Wednesday, December 26, 2018 11:56 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
> tank
> >
> > Well, ...  the IBM 1401 was built in a substantial frame; and in the
> > context cited it appears to have the only (hence surely the "main")
> > computer present.  Other members of the same general family like IBM
> > 1410 were certainly regarded as a mainframe.  I'm pretty sure any
> > computer large enough to require one or more dedicated frames  was
> > called a "mainframe" in those days.  When mini-computers first came out,
> > they weren't considered mainframes because they were typically only the
> > size of a single rack and could even be carried.
> >
> >  With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
> > (started in Infantry but ended up as head Company Clerk at HHC of "The
> > Old Guard" at Ft Myer VA).  I remember reading some memo that came down
> > from above the Battalion suggesting the possibility of using a
> > punched-card-based system for maintaining and producing our Company
> > Roster.  That might have involved an IBM 1401, but my impression at the
> > time was that the functions they were describing could easily have been
> > done with just unit-record equipment.  Nothing ever came of it while I
> > was there.   It would have saved us the periodic tedium of one or more
> > man-hours of manually typing up a new roster in which few names changed,
> > but given that our time was cheap and available, there would have been
> > no way to cost-justify using a process that would save our time but slow
> > down the overall process by 

Re: How about a little Christmas fudge? | Computerworld Shark tank

[Seymour J Metz]

Look at the date on that; it's revisionist history. You won't find any 
contemporaneous documents referring to the 1401 as a mainframe.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Wayne Bickerdike 
Sent: Friday, December 28, 2018 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How about a little Christmas fudge? | Computerworld Shark tank

Even IBM are confusing:

IBM 1401: The Mainframe

https://secure-web.cisco.com/1tXx7lvP7_-qQ4_0fpJWQlfLcb9u2Q7d9RdP4of0wfOC6mDgMJUjUutIIbHwBmHWUeHLYjBGBjNmFYMLDLIfsW_cEcanP6CR88t3CV4ksCmMZBpHXMXxXYYkiEpCLO9LDY83kKgrq_RoklCchjzdM1yv-nUoa0vu4Wz3QgXRCd63n-TGvN5Ie4rJpDfGaPIR2ycDTh9EF4d9k61iSqSE7fckTAAkzDCkn9HGgmvaZ-o1r3DFti6wHmeeKg4i3itcf3nq-qB6gfYDxIJqg8oXpu7MeOdXxy-5MmIsG73-SyH5aR1NXBSGM1a2HfJwpdj6Uo-MExgkCd7o-_txboBKFq53jyolH9NmG63Gv483lxcbML23igRCkxNkIXh4WbmpQ/https%3A%2F%2Fwww.ibm.com%2Fibm%2Fhistory%2Fibm100%2Fus%2Fen%2Ficons%2Fmainframe%2F



On Sat, Dec 29, 2018 at 7:41 AM Wayne Bickerdike  wrote:

> "If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's
> not a mainframe, nor is the 1401."
>
> I'll pick nits. Altos was not S100 bus.Cromemco was. Next?
>
> I was in short pants when 1401 was a mainframe. Long pants with Z80. So my
> memory is hazy. Just remember older peers talking about 1401 autocoder.
>
> On Sat, Dec 29, 2018 at 7:10 AM Seymour J Metz  wrote:
>
>> If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's
>> not a mainframe, nor is the 1401.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf
>> of Wayne Bickerdike 
>> Sent: Thursday, December 27, 2018 10:20 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: How about a little Christmas fudge? | Computerworld Shark
>> tank
>>
>> Z80 was a processor. How could it possibly crop up in a discussion about
>> what constitutes a mainframe?
>>
>> The Altos 8000 was Z80 based as was the North Star Horizon and the
>> Cromemco
>> System 3. I worked with these in the 70's to *escape* from the mainframe,
>> the demise of which was imminent. LOL.
>>
>> Anything you can carry to the boot (trunk) of your car cannot be a
>> mainframe:)
>>
>> On Fri, Dec 28, 2018 at 6:35 AM Seymour J Metz  wrote:
>>
>> > > Well, ...  the IBM 1401 was built in a substantial frame;
>> >
>> > Substantial? Look at Figure 1 in
>> >
>> http://secure-web.cisco.com/1zGfHVf_OSYTQR-iZeSwUT8hxfRxttRuC64KrmAu3AhbMnt6LyyW-Hp7yUNcU7paWuZbaHN-dbxbJnuJHOx9LIqoVZWk7vzR-Zf_OX4a-ClGtjfSbOPIVMFxIYkYFtcTq3wcZWdiCj-mXgIPGWhxl28vAMZ1aONn5mbNieTKHYzw1k0c2PV0LwDte-VgAq97Jx2hDglzP552wj1RSpk5G_qZ_RDsEi7dChi57va08L87z1kDPeqAKuNsBN2Q7B6n_eifj13cYJcD8Yt0Kvnqcp-EOUAILLbudkLUwdnk4-_f08qEDAsB2PwtlvypFOcQPHqfJ0Xr4VAHmbroBTURny__aAFNQh_eMyKMzSVkqdPg3lYYZ6mCOVtUUmQe7i0Z4HxuWC0BQn26sEcrnl20BORwkDAq-Yvee0rnuF4AyYxT2sKH_bL1pTZCR5VLHMUzp/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F1401%2FA24-1401-1_1401_System_Summary_Sep64.pdf
>> > .
>> >
>> > >  it appears to have the only
>> >
>> > If a Z-80 had been the only computer mentioned, would you have called
>> it a
>> > mainframe?
>> >
>> > > Other members of the same general family like IBM 1410 were certainly
>> > regarded as a mainframe.
>> >
>> >
>> > The 7010 was certainly called a mainframe, and possibly the 1410, but
>> > never the 1440 or 1460.
>> >
>> > > With a recent MS in Comp Sci, I found myself in the U.S. Army
>> 1969-1971
>> > > (started in Infantry but ended up as head Company Clerk at HHC of "The
>> > > Old Guard" at Ft Myer VA).  I remember reading some memo that came
>> down
>> > > from above the Battalion suggesting the possibility of using a
>> > > punched-card-based system for maintaining and producing our Company
>> > > Roster.  That might have involved an IBM 1401,
>> >
>> > More likely a UNIVAC 1005.
>> >
>> > --
>> > Shmuel (Seymour J.) Metz
>> > http://mason.gmu.edu/~smetz3
>> >
>> > 
>> > From: IBM Mainframe Discussion List  on
>> behalf
>> > of Joel C. Ewing 
>> > Sent: Wednesday, December 26, 2018 11:56 PM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
>> tank
>> >
>> > Well, ...  the IBM 1401 was built in a substantial frame; and in the
>> > context cited it appears to have the only (hence surely the "main")
>> > computer present.  Other members of the same general family like IBM
>> > 1410 were certainly regarded as a mainframe.  I'm pretty sure any
>> > computer large enough to require one or more dedicated frames  was
>> > called a "mainframe" in those days.  When mini-computers first came out,
>> > they weren't considered mainframes because they were typically only the
>> > size of a single rack and could even be carried.
>> >
>> >  With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
>> > (started in Infantry but ended up 

Re: System Symbols

[scott Ford]

Rob,

My friend big thanks, answer is 'yes'. This is great.
Happy Holidays, also.

Scott

On Fri, Dec 28, 2018 at 3:52 PM Rob Schramm  wrote:

> Is this along the lines of what you are looking for?
>
> https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/6SlkPC-irSc
>
> Rob
>
> On Fri, Dec 28, 2018 at 12:09 PM scott Ford  wrote:
>
> > All,
> >
> > Has anyone created their own system symbol and then referenced it in
> HLASM
> > ?
> > If so I need some points on how to do it. I saw in the manual how to
> define
> > it, what I am not clear on is how to have HLASM code read the system
> symbol
> > table and compare for the desired symbol..What i want to do is if we
> find a
> > specific symbol set, have a exit perform conditional logic.
> >
> > Regards,
> >
> > Scott
> >
> > --
> >
> >
> >
> > *IDMWORKS *
> >
> > Scott Ford
> >
> > z/OS Dev.
> >
> >
> >
> >
> > “By elevating a friend or Collegue you elevate yourself, by demeaning a
> > friend or collegue you demean yourself”
> >
> >
> >
> > www.idmworks.com
> >
> > scott.f...@idmworks.com
> >
> > Blog: www.idmworks.com/blog
> >
> >
> >
> >
> >
> > *The information contained in this email message and any attachment may
> be
> > privileged, confidential, proprietary or otherwise protected from
> > disclosure. If the reader of this message is not the intended recipient,
> > you are hereby notified that any dissemination, distribution, copying or
> > use of this message and any attachment is strictly prohibited. If you
> have
> > received this message in error, please notify us immediately by replying
> to
> > the message and permanently delete it from your computer and destroy any
> > printout thereof.*
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> --
>
> Rob Schramm
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: System Symbols

[Rob Schramm]

Is this along the lines of what you are looking for?

https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/6SlkPC-irSc

Rob

On Fri, Dec 28, 2018 at 12:09 PM scott Ford  wrote:

> All,
>
> Has anyone created their own system symbol and then referenced it in HLASM
> ?
> If so I need some points on how to do it. I saw in the manual how to define
> it, what I am not clear on is how to have HLASM code read the system symbol
> table and compare for the desired symbol..What i want to do is if we find a
> specific symbol set, have a exit perform conditional logic.
>
> Regards,
>
> Scott
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
> www.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: www.idmworks.com/blog
>
>
>
>
>
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Re: How about a little Christmas fudge? | Computerworld Shark tank

[Wayne Bickerdike]

On a roll here...

They weren't hyphenated either. Z80 and S100.

Give me a Z28 anyday.


On Sat, Dec 29, 2018 at 7:45 AM Wayne Bickerdike  wrote:

> Even IBM are confusing:
>
> IBM 1401: The Mainframe
>
> https://www.ibm.com/ibm/history/ibm100/us/en/icons/mainframe/
>
>
>
> On Sat, Dec 29, 2018 at 7:41 AM Wayne Bickerdike 
> wrote:
>
>> "If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's
>> not a mainframe, nor is the 1401."
>>
>> I'll pick nits. Altos was not S100 bus.Cromemco was. Next?
>>
>> I was in short pants when 1401 was a mainframe. Long pants with Z80. So
>> my memory is hazy. Just remember older peers talking about 1401 autocoder.
>>
>> On Sat, Dec 29, 2018 at 7:10 AM Seymour J Metz  wrote:
>>
>>> If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's
>>> not a mainframe, nor is the 1401.
>>>
>>>
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>>
>>> 
>>> From: IBM Mainframe Discussion List  on
>>> behalf of Wayne Bickerdike 
>>> Sent: Thursday, December 27, 2018 10:20 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: How about a little Christmas fudge? | Computerworld Shark
>>> tank
>>>
>>> Z80 was a processor. How could it possibly crop up in a discussion about
>>> what constitutes a mainframe?
>>>
>>> The Altos 8000 was Z80 based as was the North Star Horizon and the
>>> Cromemco
>>> System 3. I worked with these in the 70's to *escape* from the mainframe,
>>> the demise of which was imminent. LOL.
>>>
>>> Anything you can carry to the boot (trunk) of your car cannot be a
>>> mainframe:)
>>>
>>> On Fri, Dec 28, 2018 at 6:35 AM Seymour J Metz  wrote:
>>>
>>> > > Well, ...  the IBM 1401 was built in a substantial frame;
>>> >
>>> > Substantial? Look at Figure 1 in
>>> >
>>> http://secure-web.cisco.com/1zGfHVf_OSYTQR-iZeSwUT8hxfRxttRuC64KrmAu3AhbMnt6LyyW-Hp7yUNcU7paWuZbaHN-dbxbJnuJHOx9LIqoVZWk7vzR-Zf_OX4a-ClGtjfSbOPIVMFxIYkYFtcTq3wcZWdiCj-mXgIPGWhxl28vAMZ1aONn5mbNieTKHYzw1k0c2PV0LwDte-VgAq97Jx2hDglzP552wj1RSpk5G_qZ_RDsEi7dChi57va08L87z1kDPeqAKuNsBN2Q7B6n_eifj13cYJcD8Yt0Kvnqcp-EOUAILLbudkLUwdnk4-_f08qEDAsB2PwtlvypFOcQPHqfJ0Xr4VAHmbroBTURny__aAFNQh_eMyKMzSVkqdPg3lYYZ6mCOVtUUmQe7i0Z4HxuWC0BQn26sEcrnl20BORwkDAq-Yvee0rnuF4AyYxT2sKH_bL1pTZCR5VLHMUzp/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F1401%2FA24-1401-1_1401_System_Summary_Sep64.pdf
>>> > .
>>> >
>>> > >  it appears to have the only
>>> >
>>> > If a Z-80 had been the only computer mentioned, would you have called
>>> it a
>>> > mainframe?
>>> >
>>> > > Other members of the same general family like IBM 1410 were certainly
>>> > regarded as a mainframe.
>>> >
>>> >
>>> > The 7010 was certainly called a mainframe, and possibly the 1410, but
>>> > never the 1440 or 1460.
>>> >
>>> > > With a recent MS in Comp Sci, I found myself in the U.S. Army
>>> 1969-1971
>>> > > (started in Infantry but ended up as head Company Clerk at HHC of
>>> "The
>>> > > Old Guard" at Ft Myer VA).  I remember reading some memo that came
>>> down
>>> > > from above the Battalion suggesting the possibility of using a
>>> > > punched-card-based system for maintaining and producing our Company
>>> > > Roster.  That might have involved an IBM 1401,
>>> >
>>> > More likely a UNIVAC 1005.
>>> >
>>> > --
>>> > Shmuel (Seymour J.) Metz
>>> > http://mason.gmu.edu/~smetz3
>>> >
>>> > 
>>> > From: IBM Mainframe Discussion List  on
>>> behalf
>>> > of Joel C. Ewing 
>>> > Sent: Wednesday, December 26, 2018 11:56 PM
>>> > To: IBM-MAIN@LISTSERV.UA.EDU
>>> > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
>>> tank
>>> >
>>> > Well, ...  the IBM 1401 was built in a substantial frame; and in the
>>> > context cited it appears to have the only (hence surely the "main")
>>> > computer present.  Other members of the same general family like IBM
>>> > 1410 were certainly regarded as a mainframe.  I'm pretty sure any
>>> > computer large enough to require one or more dedicated frames  was
>>> > called a "mainframe" in those days.  When mini-computers first came
>>> out,
>>> > they weren't considered mainframes because they were typically only the
>>> > size of a single rack and could even be carried.
>>> >
>>> >  With a recent MS in Comp Sci, I found myself in the U.S. Army
>>> 1969-1971
>>> > (started in Infantry but ended up as head Company Clerk at HHC of "The
>>> > Old Guard" at Ft Myer VA).  I remember reading some memo that came down
>>> > from above the Battalion suggesting the possibility of using a
>>> > punched-card-based system for maintaining and producing our Company
>>> > Roster.  That might have involved an IBM 1401, but my impression at the
>>> > time was that the functions they were describing could easily have been
>>> > done with just unit-record equipment.  Nothing ever came of it while I
>>> > was there.   It would have saved us the periodic tedium of one or more
>>> > man-hours of manually typing up a new roster 

Re: How about a little Christmas fudge? | Computerworld Shark tank

[Wayne Bickerdike]

Even IBM are confusing:

IBM 1401: The Mainframe

https://www.ibm.com/ibm/history/ibm100/us/en/icons/mainframe/



On Sat, Dec 29, 2018 at 7:41 AM Wayne Bickerdike  wrote:

> "If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's
> not a mainframe, nor is the 1401."
>
> I'll pick nits. Altos was not S100 bus.Cromemco was. Next?
>
> I was in short pants when 1401 was a mainframe. Long pants with Z80. So my
> memory is hazy. Just remember older peers talking about 1401 autocoder.
>
> On Sat, Dec 29, 2018 at 7:10 AM Seymour J Metz  wrote:
>
>> If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's
>> not a mainframe, nor is the 1401.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf
>> of Wayne Bickerdike 
>> Sent: Thursday, December 27, 2018 10:20 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: How about a little Christmas fudge? | Computerworld Shark
>> tank
>>
>> Z80 was a processor. How could it possibly crop up in a discussion about
>> what constitutes a mainframe?
>>
>> The Altos 8000 was Z80 based as was the North Star Horizon and the
>> Cromemco
>> System 3. I worked with these in the 70's to *escape* from the mainframe,
>> the demise of which was imminent. LOL.
>>
>> Anything you can carry to the boot (trunk) of your car cannot be a
>> mainframe:)
>>
>> On Fri, Dec 28, 2018 at 6:35 AM Seymour J Metz  wrote:
>>
>> > > Well, ...  the IBM 1401 was built in a substantial frame;
>> >
>> > Substantial? Look at Figure 1 in
>> >
>> http://secure-web.cisco.com/1zGfHVf_OSYTQR-iZeSwUT8hxfRxttRuC64KrmAu3AhbMnt6LyyW-Hp7yUNcU7paWuZbaHN-dbxbJnuJHOx9LIqoVZWk7vzR-Zf_OX4a-ClGtjfSbOPIVMFxIYkYFtcTq3wcZWdiCj-mXgIPGWhxl28vAMZ1aONn5mbNieTKHYzw1k0c2PV0LwDte-VgAq97Jx2hDglzP552wj1RSpk5G_qZ_RDsEi7dChi57va08L87z1kDPeqAKuNsBN2Q7B6n_eifj13cYJcD8Yt0Kvnqcp-EOUAILLbudkLUwdnk4-_f08qEDAsB2PwtlvypFOcQPHqfJ0Xr4VAHmbroBTURny__aAFNQh_eMyKMzSVkqdPg3lYYZ6mCOVtUUmQe7i0Z4HxuWC0BQn26sEcrnl20BORwkDAq-Yvee0rnuF4AyYxT2sKH_bL1pTZCR5VLHMUzp/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F1401%2FA24-1401-1_1401_System_Summary_Sep64.pdf
>> > .
>> >
>> > >  it appears to have the only
>> >
>> > If a Z-80 had been the only computer mentioned, would you have called
>> it a
>> > mainframe?
>> >
>> > > Other members of the same general family like IBM 1410 were certainly
>> > regarded as a mainframe.
>> >
>> >
>> > The 7010 was certainly called a mainframe, and possibly the 1410, but
>> > never the 1440 or 1460.
>> >
>> > > With a recent MS in Comp Sci, I found myself in the U.S. Army
>> 1969-1971
>> > > (started in Infantry but ended up as head Company Clerk at HHC of "The
>> > > Old Guard" at Ft Myer VA).  I remember reading some memo that came
>> down
>> > > from above the Battalion suggesting the possibility of using a
>> > > punched-card-based system for maintaining and producing our Company
>> > > Roster.  That might have involved an IBM 1401,
>> >
>> > More likely a UNIVAC 1005.
>> >
>> > --
>> > Shmuel (Seymour J.) Metz
>> > http://mason.gmu.edu/~smetz3
>> >
>> > 
>> > From: IBM Mainframe Discussion List  on
>> behalf
>> > of Joel C. Ewing 
>> > Sent: Wednesday, December 26, 2018 11:56 PM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
>> tank
>> >
>> > Well, ...  the IBM 1401 was built in a substantial frame; and in the
>> > context cited it appears to have the only (hence surely the "main")
>> > computer present.  Other members of the same general family like IBM
>> > 1410 were certainly regarded as a mainframe.  I'm pretty sure any
>> > computer large enough to require one or more dedicated frames  was
>> > called a "mainframe" in those days.  When mini-computers first came out,
>> > they weren't considered mainframes because they were typically only the
>> > size of a single rack and could even be carried.
>> >
>> >  With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
>> > (started in Infantry but ended up as head Company Clerk at HHC of "The
>> > Old Guard" at Ft Myer VA).  I remember reading some memo that came down
>> > from above the Battalion suggesting the possibility of using a
>> > punched-card-based system for maintaining and producing our Company
>> > Roster.  That might have involved an IBM 1401, but my impression at the
>> > time was that the functions they were describing could easily have been
>> > done with just unit-record equipment.  Nothing ever came of it while I
>> > was there.   It would have saved us the periodic tedium of one or more
>> > man-hours of manually typing up a new roster in which few names changed,
>> > but given that our time was cheap and available, there would have been
>> > no way to cost-justify using a process that would save our time but slow
>> > down the overall process by requiring outside resources.   Clearly, at
>> > that time, 

Re: How about a little Christmas fudge? | Computerworld Shark tank

[Wayne Bickerdike]

"If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's not
a mainframe, nor is the 1401."

I'll pick nits. Altos was not S100 bus.Cromemco was. Next?

I was in short pants when 1401 was a mainframe. Long pants with Z80. So my
memory is hazy. Just remember older peers talking about 1401 autocoder.

On Sat, Dec 29, 2018 at 7:10 AM Seymour J Metz  wrote:

> If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's not
> a mainframe, nor is the 1401.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Wayne Bickerdike 
> Sent: Thursday, December 27, 2018 10:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How about a little Christmas fudge? | Computerworld Shark tank
>
> Z80 was a processor. How could it possibly crop up in a discussion about
> what constitutes a mainframe?
>
> The Altos 8000 was Z80 based as was the North Star Horizon and the Cromemco
> System 3. I worked with these in the 70's to *escape* from the mainframe,
> the demise of which was imminent. LOL.
>
> Anything you can carry to the boot (trunk) of your car cannot be a
> mainframe:)
>
> On Fri, Dec 28, 2018 at 6:35 AM Seymour J Metz  wrote:
>
> > > Well, ...  the IBM 1401 was built in a substantial frame;
> >
> > Substantial? Look at Figure 1 in
> >
> http://secure-web.cisco.com/1zGfHVf_OSYTQR-iZeSwUT8hxfRxttRuC64KrmAu3AhbMnt6LyyW-Hp7yUNcU7paWuZbaHN-dbxbJnuJHOx9LIqoVZWk7vzR-Zf_OX4a-ClGtjfSbOPIVMFxIYkYFtcTq3wcZWdiCj-mXgIPGWhxl28vAMZ1aONn5mbNieTKHYzw1k0c2PV0LwDte-VgAq97Jx2hDglzP552wj1RSpk5G_qZ_RDsEi7dChi57va08L87z1kDPeqAKuNsBN2Q7B6n_eifj13cYJcD8Yt0Kvnqcp-EOUAILLbudkLUwdnk4-_f08qEDAsB2PwtlvypFOcQPHqfJ0Xr4VAHmbroBTURny__aAFNQh_eMyKMzSVkqdPg3lYYZ6mCOVtUUmQe7i0Z4HxuWC0BQn26sEcrnl20BORwkDAq-Yvee0rnuF4AyYxT2sKH_bL1pTZCR5VLHMUzp/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F1401%2FA24-1401-1_1401_System_Summary_Sep64.pdf
> > .
> >
> > >  it appears to have the only
> >
> > If a Z-80 had been the only computer mentioned, would you have called it
> a
> > mainframe?
> >
> > > Other members of the same general family like IBM 1410 were certainly
> > regarded as a mainframe.
> >
> >
> > The 7010 was certainly called a mainframe, and possibly the 1410, but
> > never the 1440 or 1460.
> >
> > > With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
> > > (started in Infantry but ended up as head Company Clerk at HHC of "The
> > > Old Guard" at Ft Myer VA).  I remember reading some memo that came down
> > > from above the Battalion suggesting the possibility of using a
> > > punched-card-based system for maintaining and producing our Company
> > > Roster.  That might have involved an IBM 1401,
> >
> > More likely a UNIVAC 1005.
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Joel C. Ewing 
> > Sent: Wednesday, December 26, 2018 11:56 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
> tank
> >
> > Well, ...  the IBM 1401 was built in a substantial frame; and in the
> > context cited it appears to have the only (hence surely the "main")
> > computer present.  Other members of the same general family like IBM
> > 1410 were certainly regarded as a mainframe.  I'm pretty sure any
> > computer large enough to require one or more dedicated frames  was
> > called a "mainframe" in those days.  When mini-computers first came out,
> > they weren't considered mainframes because they were typically only the
> > size of a single rack and could even be carried.
> >
> >  With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
> > (started in Infantry but ended up as head Company Clerk at HHC of "The
> > Old Guard" at Ft Myer VA).  I remember reading some memo that came down
> > from above the Battalion suggesting the possibility of using a
> > punched-card-based system for maintaining and producing our Company
> > Roster.  That might have involved an IBM 1401, but my impression at the
> > time was that the functions they were describing could easily have been
> > done with just unit-record equipment.  Nothing ever came of it while I
> > was there.   It would have saved us the periodic tedium of one or more
> > man-hours of manually typing up a new roster in which few names changed,
> > but given that our time was cheap and available, there would have been
> > no way to cost-justify using a process that would save our time but slow
> > down the overall process by requiring outside resources.   Clearly, at
> > that time, punched card decks were one of the databases used for
> > tracking military personnel.
> > Joel C. Ewing
> >
> > On 12/26/18 2:42 PM, Seymour J Metz wrote:
> > > What is he smoking? Since when was the 1401 a mainframe?
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > 

Re: How about a little Christmas fudge? | Computerworld Shark tank

[Seymour J Metz]

If you want to pick nits, read "Z-80" as "S-100 PC using a Z-80"; it's not a 
mainframe, nor is the 1401.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Wayne Bickerdike 
Sent: Thursday, December 27, 2018 10:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How about a little Christmas fudge? | Computerworld Shark tank

Z80 was a processor. How could it possibly crop up in a discussion about
what constitutes a mainframe?

The Altos 8000 was Z80 based as was the North Star Horizon and the Cromemco
System 3. I worked with these in the 70's to *escape* from the mainframe,
the demise of which was imminent. LOL.

Anything you can carry to the boot (trunk) of your car cannot be a
mainframe:)

On Fri, Dec 28, 2018 at 6:35 AM Seymour J Metz  wrote:

> > Well, ...  the IBM 1401 was built in a substantial frame;
>
> Substantial? Look at Figure 1 in
> http://secure-web.cisco.com/1zGfHVf_OSYTQR-iZeSwUT8hxfRxttRuC64KrmAu3AhbMnt6LyyW-Hp7yUNcU7paWuZbaHN-dbxbJnuJHOx9LIqoVZWk7vzR-Zf_OX4a-ClGtjfSbOPIVMFxIYkYFtcTq3wcZWdiCj-mXgIPGWhxl28vAMZ1aONn5mbNieTKHYzw1k0c2PV0LwDte-VgAq97Jx2hDglzP552wj1RSpk5G_qZ_RDsEi7dChi57va08L87z1kDPeqAKuNsBN2Q7B6n_eifj13cYJcD8Yt0Kvnqcp-EOUAILLbudkLUwdnk4-_f08qEDAsB2PwtlvypFOcQPHqfJ0Xr4VAHmbroBTURny__aAFNQh_eMyKMzSVkqdPg3lYYZ6mCOVtUUmQe7i0Z4HxuWC0BQn26sEcrnl20BORwkDAq-Yvee0rnuF4AyYxT2sKH_bL1pTZCR5VLHMUzp/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F1401%2FA24-1401-1_1401_System_Summary_Sep64.pdf
> .
>
> >  it appears to have the only
>
> If a Z-80 had been the only computer mentioned, would you have called it a
> mainframe?
>
> > Other members of the same general family like IBM 1410 were certainly
> regarded as a mainframe.
>
>
> The 7010 was certainly called a mainframe, and possibly the 1410, but
> never the 1440 or 1460.
>
> > With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
> > (started in Infantry but ended up as head Company Clerk at HHC of "The
> > Old Guard" at Ft Myer VA).  I remember reading some memo that came down
> > from above the Battalion suggesting the possibility of using a
> > punched-card-based system for maintaining and producing our Company
> > Roster.  That might have involved an IBM 1401,
>
> More likely a UNIVAC 1005.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Joel C. Ewing 
> Sent: Wednesday, December 26, 2018 11:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How about a little Christmas fudge? | Computerworld Shark tank
>
> Well, ...  the IBM 1401 was built in a substantial frame; and in the
> context cited it appears to have the only (hence surely the "main")
> computer present.  Other members of the same general family like IBM
> 1410 were certainly regarded as a mainframe.  I'm pretty sure any
> computer large enough to require one or more dedicated frames  was
> called a "mainframe" in those days.  When mini-computers first came out,
> they weren't considered mainframes because they were typically only the
> size of a single rack and could even be carried.
>
>  With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
> (started in Infantry but ended up as head Company Clerk at HHC of "The
> Old Guard" at Ft Myer VA).  I remember reading some memo that came down
> from above the Battalion suggesting the possibility of using a
> punched-card-based system for maintaining and producing our Company
> Roster.  That might have involved an IBM 1401, but my impression at the
> time was that the functions they were describing could easily have been
> done with just unit-record equipment.  Nothing ever came of it while I
> was there.   It would have saved us the periodic tedium of one or more
> man-hours of manually typing up a new roster in which few names changed,
> but given that our time was cheap and available, there would have been
> no way to cost-justify using a process that would save our time but slow
> down the overall process by requiring outside resources.   Clearly, at
> that time, punched card decks were one of the databases used for
> tracking military personnel.
> Joel C. Ewing
>
> On 12/26/18 2:42 PM, Seymour J Metz wrote:
> > What is he smoking? Since when was the 1401 a mainframe?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of Mark Regan 
> > Sent: Wednesday, December 26, 2018 8:28 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: How about a little Christmas fudge? | Computerworld Shark tank
> >
> >
> 

Re: TOD clock values, leap seconds and BLSUXTOD conversion service

[Mike Schwab]

One major consideration should be who sets the time zone.  Many
mainframes support users in multiple time zones.  So ideally the
mainframe should be set to UTC then the macro should convert to the
local time of the individual application / user.

On Fri, Dec 28, 2018 at 1:47 PM Peter Relson  wrote:
>
> I shouldn't have included "TIME" among the services I mentioned because
> that's "current", not "historic" (so only has to deal with "current" leap
> seconds) and because it does not let you choose STCK as the "zone" -- you
> must choose between local and UTC, both of which are defined with respect
> to leap seconds.
> Thus it must handle leap seconds, but also is not in the position of
> needing update for a "new" leap second.
>
> And, in case you're wondering, at the "instant" of bringing in a new leap
> second, there are various approaches in play that customers choose to
> adopt and I doubt that it is deterministic on which side of the fence you
> would necessarily fall if you used some service such as TIME (or if you
> did it yourself) -- perhaps the STCK was done "just before" but reference
> to CVTLSO was "just after". Something similar could happen with respect to
> time zone offset changes.
>
> 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



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: TOD clock values, leap seconds and BLSUXTOD conversion service

[Seymour J Metz]

I agree with the comments on what should have been done, and I agree that the 
documentation needs to be corrected. However, I also agree with IBM that they 
should not introduce an incompatibility and that any enhancement to TOD 
conversion requires a business case. A starting point might be to research the 
acceptability of z/OS Unix System Service (*NOT* USS!) to the *ix community and 
the effect of that on z sales.

With regard to whether z/OS is UNIX, I must reluctantly agree that it is, 
albeit without many of the facilities that the community expects.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Friday, December 28, 2018 12:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service

Peter,

I really must speak up here in defense of Paul/Gil's long time position on the 
failings of the STCKCONV/CONVTOD services.

Firstly, you are not correct that "no one agrees with" Paul/Gil's position on 
the values produced by STCKCONV.  There are at least some of us out here who 
agree with his position wholeheartedly.  Our failing is not to have spoken up 
in his defense previously to now.

Contrary to your opinion, Paul/Gil's use of "correct" is factually correct.  
People (including programmers) may reasonably expect that a request to convert 
a machine-based time value to "the local time" should produce an accurate 
representation of that local time.  Similarly, if a programmer asks for a 
conversion of a machine-based time value to GMT/UTC/TAI or other time standard 
then they should get what was requested.

Whatever architectural basis is used for the epoch at the machine level, the 
result of requesting a conversion of that hardware time measurement into 
human-intelligible format must produce "the correct time" according to the 
locale-ly correct standard, including "daylight savings" or "summer time" 
variations and also leap seconds.  STCKCONV and CONVTOD perform neither of 
these functions, and should long since have been clearly documented as not 
performing them.

In this sense, Paul/Gil's assertion that these services only produce accurate 
values prior to 1972 is factually accurate in one sense, since before 1972 we 
had no leap seconds.  Paul/Gil is of course not totally accurate either, in 
that since the values produced by these services never did take locale-specific 
DST variations into consideration, by the rule of "locale-ly correct" even 
values prior to 1972 are not accurately converted.

Paul/Gil's oft-expressed desire for IBM to fully support the Olson time 
database (I think I have that name correct, but please correct me if I do not), 
the "tz" timezone database that is regularly updated and supported across (most 
of) the rest of the computing world is something that I agree should have been 
done by IBM a very long time ago, especially since "z/OS is Unix" is an 
oft-repeated claim.  If you do not support the Unix time database standard then 
you are not (entirely) Unix.

And I frankly care not a whig whether it is POSIXly correct to say that or not. 
 It does not conform to the commonly understood Unix time standard among 
programmers around the world.  Period.

Simply documenting the obvious failure of the STCKCONV/CONVTOD services to 
support leap seconds and locale-specific DST rules in any form is the very 
least that IBM should do.

I can agree with your (I think  unstated, or perhaps only stated infrequently) 
opinion that the STCKCONV/CONVTOD services themselves should not change to 
support time conversion features that they do not currently support.  Too many 
compatibility and support issues to count.

That there should be a new pair of services with enhanced capabilities 
available as alternatives to STCKCONV and CONVTOD, which new services actively 
use the "tz" database and correctly adjust any conversion for leap seconds as 
well as locale-dependent DST issues would be an obvious (to me) solution, along 
with carefully documenting STCKCONV's/CONVTOD's limitations in these areas.

As for current LE provided time/date services, a brief RTFM reveals that many 
of them seem to use a different epoch than the (E)TOD clock, specifically 
00:00:00 14 October 1582 according to the current LE Programming Reference.  
And only one of those services (CEEGMTO) purports to know the difference 
between local time and GMT time.  Most confusing.

All opinions expressed here are purely my own, and not my employer's.

With utmost respect and admiration for your continued activity in this forum 
and for your gentlemanly responses here,

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Thursday, December 27, 2018 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion 

Re: TOD clock values, leap seconds and BLSUXTOD conversion service

[Peter Relson]

I shouldn't have included "TIME" among the services I mentioned because 
that's "current", not "historic" (so only has to deal with "current" leap 
seconds) and because it does not let you choose STCK as the "zone" -- you 
must choose between local and UTC, both of which are defined with respect 
to leap seconds.
Thus it must handle leap seconds, but also is not in the position of 
needing update for a "new" leap second.

And, in case you're wondering, at the "instant" of bringing in a new leap 
second, there are various approaches in play that customers choose to 
adopt and I doubt that it is deterministic on which side of the fence you 
would necessarily fall if you used some service such as TIME (or if you 
did it yourself) -- perhaps the STCK was done "just before" but reference 
to CVTLSO was "just after". Something similar could happen with respect to 
time zone offset changes.

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

Re: Was Adding 90 seconds to 8 byte TOD FIELD

[Seymour J Metz]

Redbooks are useful, but they are not formal documentation.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
George Kozakos 
Sent: Friday, December 28, 2018 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Was Adding 90 seconds to 8 byte TOD FIELD

> Is there any additional documentation on this function ?
The function was documented in the z/OS Version 1 Release 11
Implementation redbook - 13.5 Cross-memory TCB and SRB WAIT

Regards,
George Kozakos
z/OS Software Service, Level 2 Supervisor


--
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: Was Adding 90 seconds to 8 byte TOD FIELD

[George Kozakos]

> Is there any additional documentation on this function ?
The function was documented in the z/OS Version 1 Release 11
Implementation redbook - 13.5 Cross-memory TCB and SRB WAIT

Regards,
George Kozakos
z/OS Software Service, Level 2 Supervisor


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

Re: TOD clock values, leap seconds and BLSUXTOD conversion service

[Peter Relson]

There is an architectural definition of what a tick in bit 51 of the 
64-bit TOD clock.
Thus a given clock value (bits 0-51) represents the number of microseconds 
since the start of the epoch being used.
It seems true that STCKCONV assumes the standard epoch. As I said, if that 
is not mentioned in the doc, I'd be in favor of doing so.

A STCK value came from the clock and is not to be considered UTC time. Why 
then should STCKCONV which is converting an input STCK value (not an input 
UTC value) provide a UTC date/time? If you want to provide a UTC clock 
value, then you could presumably do so.

Should the service(s) factor in leap seconds? It no longer matters. They 
could not be changed to do so, since it would be incompatible. They could 
be enhanced to do so with a new non-default option but there would have to 
be a business case for that, and at this point no one has come close to 
making one. Therefore the thing to do is to document the current behavior, 
for which I've already said that I'm OK with indicating that this does not 
factor in leap seconds. I think Gil indicated he had submitted, or would 
submit, an RCF.

As far as I know, none of the BCP-provided time services (TIME, STCKCONV, 
CONVTOD, BLSUXTOD, etc) pay attention to leap seconds. Nor are they likely 
ever to do so, if only because no one wants to have to update them 
whenever a leap second "shows up". 

If you want a service that does something with a historical time stamp and 
leap seconds, make the case. It hasn't been made in all the years since 
the first leap second. Maybe that's because humans don't truly need to 
know that level of precision for "old dates". 

Is this discussion similar to the question about "local time"?  I don't 
see many people trying to factor into a display of time/date from a 
historical time stamp just when day light savings kicked in or out. I 
think local time is considered to be for humans and that it is thought 
that humans can "deal with it". 

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

Re: Explanation of IEAMSCHD parameter SYNCHCOMPADDR

[Joseph Reichman]

Thanks 

I am going to run it under TESTAUTH 
( obviously I cannt run the SRB under TEST )
But I can display the values of X.SRBCCOMCODE before IEAMSCHED and after 


> On Dec 28, 2018, at 1:20 PM, Peter Relson  wrote:
> 
> When I wrote that you ought to invest in a debugger, perhaps what I meant 
> was that you need to use a debugger for debugging.
> Capture data so that you can see what is going on and what is going wrong. 
> Share that data if you are going to ask for help.
> 
> You showed some of the code, but you did not show your data definitions. 
> What is "X.SRBCCOMCODE"? 
> 
> 
> Don't understand addr fields ? shouldn't the value SYNCHCOMPADDR contain 
> the
> return code from the SRB or FRR meaningX.SRBCCOMCODE
> 
> 
> Do you think that we used "ADDR" in the keyword name for the heck of it?
> No, we used it so that you would be more likely to get it right even if 
> you did not read the documentation.
> You should think, in using that keyword, that what you are providing is a 
> field that contains the address of something.
> 
> If you chose to look at the book, there is the wording
> 
> To code: Specify the name (RS-type) of an optional 4-byte input area that 
> contains the address of the fullword that is to hold the data to be 
> returned. 
> 
> If you chose to look at the macro, there is the wording
> 
>is the name (RS-type) of an optional 4 byte input
>that contains the address of the fullword that is
>to contain ... 
> 
> 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: Explanation of IEAMSCHD parameter SYNCHCOMPADDR

[Peter Relson]

When I wrote that you ought to invest in a debugger, perhaps what I meant 
was that you need to use a debugger for debugging.
Capture data so that you can see what is going on and what is going wrong. 
Share that data if you are going to ask for help.

You showed some of the code, but you did not show your data definitions. 
What is "X.SRBCCOMCODE"? 


Don't understand addr fields ? shouldn't the value SYNCHCOMPADDR contain 
the
return code from the SRB or FRR meaningX.SRBCCOMCODE


Do you think that we used "ADDR" in the keyword name for the heck of it?
No, we used it so that you would be more likely to get it right even if 
you did not read the documentation.
You should think, in using that keyword, that what you are providing is a 
field that contains the address of something.

If you chose to look at the book, there is the wording

To code: Specify the name (RS-type) of an optional 4-byte input area that 
contains the address of the fullword that is to hold the data to be 
returned. 

If you chose to look at the macro, there is the wording
 
is the name (RS-type) of an optional 4 byte input
that contains the address of the fullword that is
to contain ... 

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

Re: How about a little Christmas fudge? | Computerworld Shark tank

[Vernooij, Kees (ITOP NM) - KLM]

I only waiting for a reply from Statler and Waldorf... (grump, grump).

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Friday, December 28, 2018 18:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How about a little Christmas fudge? | Computerworld Shark tank

I helped convert from a System 3 to a 4361

On Thu, Dec 27, 2018 at 10:21 PM Wayne Bickerdike  wrote:

> Z80 was a processor. How could it possibly crop up in a discussion 
> about what constitutes a mainframe?
>
> The Altos 8000 was Z80 based as was the North Star Horizon and the 
> Cromemco System 3. I worked with these in the 70's to *escape* from 
> the mainframe, the demise of which was imminent. LOL.
>
> Anything you can carry to the boot (trunk) of your car cannot be a
> mainframe:)
>
> On Fri, Dec 28, 2018 at 6:35 AM Seymour J Metz  wrote:
>
> > > Well, ...  the IBM 1401 was built in a substantial frame;
> >
> > Substantial? Look at Figure 1 in
> >
> http://bitsavers.org/pdf/ibm/1401/A24-1401-1_1401_System_Summary_Sep64
> .pdf
> > .
> >
> > >  it appears to have the only
> >
> > If a Z-80 had been the only computer mentioned, would you have 
> > called it
> a
> > mainframe?
> >
> > > Other members of the same general family like IBM 1410 were 
> > > certainly
> > regarded as a mainframe.
> >
> >
> > The 7010 was certainly called a mainframe, and possibly the 1410, 
> > but never the 1440 or 1460.
> >
> > > With a recent MS in Comp Sci, I found myself in the U.S. Army 
> > > 1969-1971 (started in Infantry but ended up as head Company Clerk 
> > > at HHC of "The Old Guard" at Ft Myer VA).  I remember reading some 
> > > memo that came down from above the Battalion suggesting the 
> > > possibility of using a punched-card-based system for maintaining 
> > > and producing our Company Roster.  That might have involved an IBM 
> > > 1401,
> >
> > More likely a UNIVAC 1005.
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on 
> > behalf of Joel C. Ewing 
> > Sent: Wednesday, December 26, 2018 11:56 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: How about a little Christmas fudge? | Computerworld 
> > Shark
> tank
> >
> > Well, ...  the IBM 1401 was built in a substantial frame; and in the 
> > context cited it appears to have the only (hence surely the "main") 
> > computer present.  Other members of the same general family like IBM
> > 1410 were certainly regarded as a mainframe.  I'm pretty sure any 
> > computer large enough to require one or more dedicated frames  was 
> > called a "mainframe" in those days.  When mini-computers first came 
> > out, they weren't considered mainframes because they were typically 
> > only the size of a single rack and could even be carried.
> >
> >  With a recent MS in Comp Sci, I found myself in the U.S. Army 
> > 1969-1971 (started in Infantry but ended up as head Company Clerk at 
> > HHC of "The Old Guard" at Ft Myer VA).  I remember reading some memo 
> > that came down from above the Battalion suggesting the possibility 
> > of using a punched-card-based system for maintaining and producing 
> > our Company Roster.  That might have involved an IBM 1401, but my 
> > impression at the time was that the functions they were describing 
> > could easily have been done with just unit-record equipment.  Nothing ever 
> > came of it while I
> > was there.   It would have saved us the periodic tedium of one or more
> > man-hours of manually typing up a new roster in which few names 
> > changed, but given that our time was cheap and available, there 
> > would have been no way to cost-justify using a process that would save our 
> > time but slow
> > down the overall process by requiring outside resources.   Clearly, at
> > that time, punched card decks were one of the databases used for 
> > tracking military personnel.
> > Joel C. Ewing
> >
> > On 12/26/18 2:42 PM, Seymour J Metz wrote:
> > > What is he smoking? Since when was the 1401 a mainframe?
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> > behalf of Mark Regan 
> > > Sent: Wednesday, December 26, 2018 8:28 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: How about a little Christmas fudge? | Computerworld Shark 
> > > tank
> > >
> > >
> >
> https://secure-web.cisco.com/1iMlW_GZ2Scqioa5F4rqymcywO0OTBLBFOtYPuQZZ
> F6F73Kv0x_B9nU3SOTiheXf32DsESHEBSvbzXuJ78Z2XaRKtXr7A2GITbjxnEDGjBqcDiO
> zF9WOIQCYJIH89nABmY7xso9DckpD3Q10YPvrxhvPVeFvR6IYMhBl0Po4k4-03fXnkJSam
> mKYm3lrjMJyX4f-lcp9YlEt59dyzYTF_at6wT-i9VPdyfHx5DVlOyFFEzAQxZe-ifUcS7u
> OAE70lUB6w6ZfwDLRp9vhqQVEaCVSjXFSY0F4a2YhM92FII0XRqIAu4y7yW4Iop4TXQVM-
> iMQuqleDME3jgueepL3jXWQ797SaO4hRpNph47Gl9FOTKIqwIXeAe2DNqPGTQMlRexhctM
> 

Re: Was Adding 90 seconds to 8 byte TOD FIELD

[Peter Relson]

AM I to understand that this routine can be called from an SRB Routine or
a Cross Memory PC Service routine to place the SRB  routine in a 
wait-suspend for x-amount of time ?

yes


Is there any additional documentation on this function?

no. What additional documentation would you think you would need? 


Is this a restricted function meaning it should not be used because it is
undocumented ?

No. Use it if it meets your needs. It is not "undocumented"; it is just 
not documented "nicely". It is documented by the comments you see for this 
field within the data areas book for the ECVT. ECVTXTSW is identified as 
being a programming interface.


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

Re: How about a little Christmas fudge? | Computerworld Shark tank

[scott Ford]

I helped convert from a System 3 to a 4361

On Thu, Dec 27, 2018 at 10:21 PM Wayne Bickerdike  wrote:

> Z80 was a processor. How could it possibly crop up in a discussion about
> what constitutes a mainframe?
>
> The Altos 8000 was Z80 based as was the North Star Horizon and the Cromemco
> System 3. I worked with these in the 70's to *escape* from the mainframe,
> the demise of which was imminent. LOL.
>
> Anything you can carry to the boot (trunk) of your car cannot be a
> mainframe:)
>
> On Fri, Dec 28, 2018 at 6:35 AM Seymour J Metz  wrote:
>
> > > Well, ...  the IBM 1401 was built in a substantial frame;
> >
> > Substantial? Look at Figure 1 in
> >
> http://bitsavers.org/pdf/ibm/1401/A24-1401-1_1401_System_Summary_Sep64.pdf
> > .
> >
> > >  it appears to have the only
> >
> > If a Z-80 had been the only computer mentioned, would you have called it
> a
> > mainframe?
> >
> > > Other members of the same general family like IBM 1410 were certainly
> > regarded as a mainframe.
> >
> >
> > The 7010 was certainly called a mainframe, and possibly the 1410, but
> > never the 1440 or 1460.
> >
> > > With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
> > > (started in Infantry but ended up as head Company Clerk at HHC of "The
> > > Old Guard" at Ft Myer VA).  I remember reading some memo that came down
> > > from above the Battalion suggesting the possibility of using a
> > > punched-card-based system for maintaining and producing our Company
> > > Roster.  That might have involved an IBM 1401,
> >
> > More likely a UNIVAC 1005.
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Joel C. Ewing 
> > Sent: Wednesday, December 26, 2018 11:56 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: How about a little Christmas fudge? | Computerworld Shark
> tank
> >
> > Well, ...  the IBM 1401 was built in a substantial frame; and in the
> > context cited it appears to have the only (hence surely the "main")
> > computer present.  Other members of the same general family like IBM
> > 1410 were certainly regarded as a mainframe.  I'm pretty sure any
> > computer large enough to require one or more dedicated frames  was
> > called a "mainframe" in those days.  When mini-computers first came out,
> > they weren't considered mainframes because they were typically only the
> > size of a single rack and could even be carried.
> >
> >  With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
> > (started in Infantry but ended up as head Company Clerk at HHC of "The
> > Old Guard" at Ft Myer VA).  I remember reading some memo that came down
> > from above the Battalion suggesting the possibility of using a
> > punched-card-based system for maintaining and producing our Company
> > Roster.  That might have involved an IBM 1401, but my impression at the
> > time was that the functions they were describing could easily have been
> > done with just unit-record equipment.  Nothing ever came of it while I
> > was there.   It would have saved us the periodic tedium of one or more
> > man-hours of manually typing up a new roster in which few names changed,
> > but given that our time was cheap and available, there would have been
> > no way to cost-justify using a process that would save our time but slow
> > down the overall process by requiring outside resources.   Clearly, at
> > that time, punched card decks were one of the databases used for
> > tracking military personnel.
> > Joel C. Ewing
> >
> > On 12/26/18 2:42 PM, Seymour J Metz wrote:
> > > What is he smoking? Since when was the 1401 a mainframe?
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> > behalf of Mark Regan 
> > > Sent: Wednesday, December 26, 2018 8:28 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: How about a little Christmas fudge? | Computerworld Shark tank
> > >
> > >
> >
> https://secure-web.cisco.com/1iMlW_GZ2Scqioa5F4rqymcywO0OTBLBFOtYPuQZZF6F73Kv0x_B9nU3SOTiheXf32DsESHEBSvbzXuJ78Z2XaRKtXr7A2GITbjxnEDGjBqcDiOzF9WOIQCYJIH89nABmY7xso9DckpD3Q10YPvrxhvPVeFvR6IYMhBl0Po4k4-03fXnkJSammKYm3lrjMJyX4f-lcp9YlEt59dyzYTF_at6wT-i9VPdyfHx5DVlOyFFEzAQxZe-ifUcS7uOAE70lUB6w6ZfwDLRp9vhqQVEaCVSjXFSY0F4a2YhM92FII0XRqIAu4y7yW4Iop4TXQVM-iMQuqleDME3jgueepL3jXWQ797SaO4hRpNph47Gl9FOTKIqwIXeAe2DNqPGTQMlRexhctM6zHXZYT2EbywHPaw/https%3A%2F%2Fwww.computerworld.com%2Farticle%2F3330396%2Fapplication-development%2Fsituation-normal-all-fudged-up.html
> > >
> > > ...
> > >
> >
> > --
> > Joel C. Ewing
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > 

Re: How annoying: SSAFF OBTAIN requires PASN=SASN=HOME ?????

[Peter Relson]

It is, to me, quite surprising that anyone still uses SSAFF OBTAIN.
It is an inefficient way of accessing a small amount of data. To a good 
degree, I think that name/token has superseded the usefulness of SSAFF.
SSAFF will likely never be enhanced in any way.

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

System Symbols

[scott Ford]

All,

Has anyone created their own system symbol and then referenced it in HLASM ?
If so I need some points on how to do it. I saw in the manual how to define
it, what I am not clear on is how to have HLASM code read the system symbol
table and compare for the desired symbol..What i want to do is if we find a
specific symbol set, have a exit perform conditional logic.

Regards,

Scott

-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: determining step completion code/status

[Dan D]

You're looking in the right spot Paul.

SCTABEND indicates the step abended and if the step completed 
(SCTSTSRT+SCTSTPND) then SCTSEXEC should contain the completion code for this 
step (not the abend code).
SCTSTNRN will be on if the step was bypassed.

Where's your code running?  An SMF exit?

Dan

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

Re: TOD clock values, leap seconds and BLSUXTOD conversion service

[Steve Smith]

For a contrary opinion, I believe IBM's documentation and function of the
TOD clock to be quite adequate.  The provided macros do the fairly involved
arithmetic to convert a TOD number as-is, which is the most useful option.
Adjusting for leap seconds, DST, and time zone can easily be done before
conversion to a date/timestamp.  If all those were built-in, you'd need
several additional parameters to the macros to account for whether those
operations were needed or not.  That would complicate things for no
particular benefit.

Regardless, if that's the function you want, then bid for it, or write it
and sell it.  IBM evidently doesn't see the business proposition, so prove
them wrong.  For me, I'd just as soon code the 2-3 extra instructions
myself and know that I understand exactly what's happening.

sas

On Fri, Dec 28, 2018 at 12:46 AM Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> Peter,
>
> I really must speak up here in defense of Paul/Gil's long time position on
> the failings of the STCKCONV/CONVTOD services.
>

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