Re: Poll

2019-09-17 Thread Richard Kuebbing
Was the 2321 the noodle reader?  Ours never worked - I think we traded it in 
for several extra 2301s.  The only problem w/2301 was it was twice as fast as 
LCS and it therefore could not perform i/o w/LCS.

SQA on 2301 was almost as good as LSQA.

When the 360/91 arrived, that package that later became the cause for Rannie's 
boat paddle had a form of LSQA in it to realize the speed of the 91.

And I know how old I am and how much I have forgotten that I can't remember 
Rannie's first name.  Was the software package LSPS - large scale programming 
system?

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Seymour J Metz
Sent: Tuesday, September 17, 2019 12:33 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Poll

Shirley you mean the 2321, a machine that only a mother could love. Or the 
early iterations of CROS.


--
Shmuel (Seymour J.) Metz
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3&d=DwIFAw&c=Z4P52L0foFKAY1wcP-GmiQ&r=gPyXKYfguTF6KSwWL0MXilwlmRSg_lRVheZFw_2X3Uw&m=rVKTFHqhguoI60YAs1FNBFJ7Bukaml-lT-ITq8LLdnU&s=2f076YSeLoIPgkU11RrJFw6HS-rM7zlDnjhrNa3bHU4&e=



From: IBM Mainframe Assembler List  on behalf 
of Richard Kuebbing 
Sent: Tuesday, September 17, 2019 12:31 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Poll

As a short-timer ( I will retire soon w/58 yrs in IT and 53 yrs on 360) I have 
been quiet on the lists.  But as a certified curmudgeon ...

Poo or poop, because both sound like doing #2

Over the yrs I have seen/heard/... so much #2 passed off as work product ... 
(e.g. the original design of floating point processing on the 360/75 - it 
should be embarrassing having to do a re-pop)

Peace be with y'all

richard

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of M. Ray Mullins
Sent: Tuesday, September 17, 2019 12:20 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Poll

psIII missed a chance when setting the options for this poll.

On 2019-09-16 15:45, Tony Thigpen wrote:
> Pop, never Poo or poop, as both sound like doing #2.
>
> Tony Thigpen
>
> Phil Smith III wrote on 9/16/19 3:50 PM:
>> Principles of Operation-how do you refer to it? (NOT including
>> case-let's not make this any more complicated than it is already!)
>>
>> 1) PofOp
>>
>> 2) POP
>>
>> 3) POO
>>
>> 4) Pops
>>
>> 5) other?
>>
>>
>> Just curious-there are no wrong answers, of course! (Well, I suppose
>> "IntelR 64 and IA-32 Architectures Software Developer Manuals" is
>> wrong.)
>>
>>
>> .phsiii
>>
>>
>>


--
M. Ray Mullins
Roseville, CA, USA

NOTICE: This communication is intended only for the person or entity to whom it 
is addressed and may contain confidential, proprietary, and/or privileged 
material. Unless you are the intended addressee, any review, reliance, 
dissemination, distribution, copying or use whatsoever of this communication is 
strictly prohibited. If you received this in error, please reply immediately 
and delete the material from all computers. Email sent through the Internet is 
not secure. Do not use email to send us confidential information such as credit 
card numbers, PIN numbers, passwords, Social Security Numbers, Account numbers, 
or other important and confidential information.


Re: Poll

2019-09-17 Thread Richard Kuebbing
As a short-timer ( I will retire soon w/58 yrs in IT and 53 yrs on 360) I have 
been quiet on the lists.  But as a certified curmudgeon ...

Poo or poop, because both sound like doing #2

Over the yrs I have seen/heard/... so much #2 passed off as work product ... 
(e.g. the original design of floating point processing on the 360/75 - it 
should be embarrassing having to do a re-pop)

Peace be with y'all

richard

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of M. Ray Mullins
Sent: Tuesday, September 17, 2019 12:20 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Poll

psIII missed a chance when setting the options for this poll.

On 2019-09-16 15:45, Tony Thigpen wrote:
> Pop, never Poo or poop, as both sound like doing #2.
>
> Tony Thigpen
>
> Phil Smith III wrote on 9/16/19 3:50 PM:
>> Principles of Operation-how do you refer to it? (NOT including
>> case-let's not make this any more complicated than it is already!)
>>
>> 1) PofOp
>>
>> 2) POP
>>
>> 3) POO
>>
>> 4) Pops
>>
>> 5) other?
>>
>>
>> Just curious-there are no wrong answers, of course! (Well, I suppose
>> "IntelR 64 and IA-32 Architectures Software Developer Manuals" is
>> wrong.)
>>
>>
>> .phsiii
>>
>>
>>


--
M. Ray Mullins
Roseville, CA, USA
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.catherdersoftware.com_&d=DwID-g&c=Z4P52L0foFKAY1wcP-GmiQ&r=gPyXKYfguTF6KSwWL0MXilwlmRSg_lRVheZFw_2X3Uw&m=RkBCgAlIeEOwGP2FrkWMqbgA8qRTZlyU7z4G5jjrQVk&s=iG6wAhXREfJ8GgY4Mbm81CqTbSXtJTKVUwONpGvQmSg&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.z390.org_&d=DwID-g&c=Z4P52L0foFKAY1wcP-GmiQ&r=gPyXKYfguTF6KSwWL0MXilwlmRSg_lRVheZFw_2X3Uw&m=RkBCgAlIeEOwGP2FrkWMqbgA8qRTZlyU7z4G5jjrQVk&s=PVyu0iCAg4WQPoEN-4kMLMu2z2fTlN9mXGbk1WqtvA4&e=

German is essentially a form of assembly language consisting entirely of far 
calls heavily accented with throaty guttural sounds.-ilvi French is essentially 
German with messed-up pronunciation and spelling.-Robert B Wilson English is 
essentially French converted to 7-bit ASCII.-Christophe Pierret [for Alain 
LaBonté]

NOTICE: This communication is intended only for the person or entity to whom it 
is addressed and may contain confidential, proprietary, and/or privileged 
material. Unless you are the intended addressee, any review, reliance, 
dissemination, distribution, copying or use whatsoever of this communication is 
strictly prohibited. If you received this in error, please reply immediately 
and delete the material from all computers. Email sent through the Internet is 
not secure. Do not use email to send us confidential information such as credit 
card numbers, PIN numbers, passwords, Social Security Numbers, Account numbers, 
or other important and confidential information.


Re: old code failing

2019-07-24 Thread Richard Kuebbing
I read DEVTYPE doc looking for rc meaning "not found" and did not see it.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Mike Shaw
Sent: Wednesday, July 24, 2019 11:49 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: old code failing

The DEVTYPE macro is a much safer and simpler way to check for the presence of 
a DD. The old TIOT scan method may work and it may not work.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.


On Wed, Jul 24, 2019 at 11:24 AM Richard Kuebbing  wrote:

> A subroutine written long ago appears to be failing.  It looks for a
> DDname in the TIOT.  Did the format of the TIOT change at some point?
> If yes, at what release?
>
> Does it matter if AMODE is 24 or 31?
>
> It might have something to do with the fact that the DD is a proc
> override instead of straight JCL or in a proc.
>
> Richard Kuebbing
>
> NOTICE: This communication is intended only for the person or entity
> to whom it is addressed and may contain confidential, proprietary,
> and/or privileged material. Unless you are the intended addressee, any
> review, reliance, dissemination, distribution, copying or use
> whatsoever of this communication is strictly prohibited. If you
> received this in error, please reply immediately and delete the
> material from all computers. Email sent through the Internet is not
> secure. Do not use email to send us confidential information such as
> credit card numbers, PIN numbers, passwords, Social Security Numbers,
> Account numbers, or other important and confidential information.
>

NOTICE: This communication is intended only for the person or entity to whom it 
is addressed and may contain confidential, proprietary, and/or privileged 
material. Unless you are the intended addressee, any review, reliance, 
dissemination, distribution, copying or use whatsoever of this communication is 
strictly prohibited. If you received this in error, please reply immediately 
and delete the material from all computers. Email sent through the Internet is 
not secure. Do not use email to send us confidential information such as credit 
card numbers, PIN numbers, passwords, Social Security Numbers, Account numbers, 
or other important and confidential information.


Re: old code failing

2019-07-24 Thread Richard Kuebbing
Routine only uses the TIOT entry to see if DD is present.  It does that to 
avoid OPEN message of missing DD.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Seymour J Metz
Sent: Wednesday, July 24, 2019 1:15 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: old code failing

There are hangs to the TIOT in support of SWA above the line, and later changes 
in support of XTIOT. Do GETDSAB and RDJFCB with an ARL give you all the data 
you need, or do you actually need the TIOT entry itself?

You should not use the TIOT to load the JFCB address into a register; use 
system services. Even if your SWA is still below the line, you don't want your 
code to break when you move it above.


--
Shmuel (Seymour J.) Metz
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3&d=DwIFAw&c=Z4P52L0foFKAY1wcP-GmiQ&r=gPyXKYfguTF6KSwWL0MXilwlmRSg_lRVheZFw_2X3Uw&m=jqVGzuz4Q3wbyPPOsgs3PMcHhqiB5cgIMie4AVXVuPU&s=E-q0y2ZFAQxFgXU8s1fx-AdO7qnsqYOSdCZRO9Gsk8E&e=


From: IBM Mainframe Assembler List  on behalf 
of Richard Kuebbing 
Sent: Wednesday, July 24, 2019 11:23 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: old code failing

A subroutine written long ago appears to be failing.  It looks for a DDname in 
the TIOT.  Did the format of the TIOT change at some point?  If yes, at what 
release?

Does it matter if AMODE is 24 or 31?

It might have something to do with the fact that the DD is a proc override 
instead of straight JCL or in a proc.

Richard Kuebbing

NOTICE: This communication is intended only for the person or entity to whom it 
is addressed and may contain confidential, proprietary, and/or privileged 
material. Unless you are the intended addressee, any review, reliance, 
dissemination, distribution, copying or use whatsoever of this communication is 
strictly prohibited. If you received this in error, please reply immediately 
and delete the material from all computers. Email sent through the Internet is 
not secure. Do not use email to send us confidential information such as credit 
card numbers, PIN numbers, passwords, Social Security Numbers, Account numbers, 
or other important and confidential information.

NOTICE: This communication is intended only for the person or entity to whom it 
is addressed and may contain confidential, proprietary, and/or privileged 
material. Unless you are the intended addressee, any review, reliance, 
dissemination, distribution, copying or use whatsoever of this communication is 
strictly prohibited. If you received this in error, please reply immediately 
and delete the material from all computers. Email sent through the Internet is 
not secure. Do not use email to send us confidential information such as credit 
card numbers, PIN numbers, passwords, Social Security Numbers, Account numbers, 
or other important and confidential information.


Re: old code failing

2019-07-24 Thread Richard Kuebbing
Thanks for the comments.  I have only a few months before I retire after more 
than 50 yrs doing ASM.

I found part of the problem.  I was testing out of a library that caused a test 
version (from 2011) of my subroutine to be used.  It works.  The production 
version (from 2005) does not.

The difference revolves around an AMODE ANY statement.

So it looks like I have to tiptoe around a code change I don't own.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Christopher Y. Blaicher
Sent: Wednesday, July 24, 2019 11:45 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: old code failing

Maybe the system put the TIOT entry in the extended TIOT.  Look up EXTRACT and 
GETDSAB macros.

Chris Blaicher
Technical Architect
Syncsort, Inc.


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of retired mainframer
Sent: Wednesday, July 24, 2019 11:42 AM
To: MVS List Server 2 
Subject: Re: old code failing

Can you show us the code that does the looking?

> -Original Message-
> From: IBM Mainframe Assembler List 
> On Behalf Of Richard Kuebbing
> Sent: Wednesday, July 24, 2019 8:24 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: old code failing
>
> A subroutine written long ago appears to be failing.  It looks for a
> DDname in the TIOT.  Did the format of the TIOT change at some point?  If 
> yes, at what release?
>
> Does it matter if AMODE is 24 or 31?
>
> It might have something to do with the fact that the DD is a proc
> override instead of straight JCL or in a proc.

NOTICE: This communication is intended only for the person or entity to whom it 
is addressed and may contain confidential, proprietary, and/or privileged 
material. Unless you are the intended addressee, any review, reliance, 
dissemination, distribution, copying or use whatsoever of this communication is 
strictly prohibited. If you received this in error, please reply immediately 
and delete the material from all computers. Email sent through the Internet is 
not secure. Do not use email to send us confidential information such as credit 
card numbers, PIN numbers, passwords, Social Security Numbers, Account numbers, 
or other important and confidential information.


old code failing

2019-07-24 Thread Richard Kuebbing
A subroutine written long ago appears to be failing.  It looks for a DDname in 
the TIOT.  Did the format of the TIOT change at some point?  If yes, at what 
release?

Does it matter if AMODE is 24 or 31?

It might have something to do with the fact that the DD is a proc override 
instead of straight JCL or in a proc.

Richard Kuebbing

NOTICE: This communication is intended only for the person or entity to whom it 
is addressed and may contain confidential, proprietary, and/or privileged 
material. Unless you are the intended addressee, any review, reliance, 
dissemination, distribution, copying or use whatsoever of this communication is 
strictly prohibited. If you received this in error, please reply immediately 
and delete the material from all computers. Email sent through the Internet is 
not secure. Do not use email to send us confidential information such as credit 
card numbers, PIN numbers, passwords, Social Security Numbers, Account numbers, 
or other important and confidential information.


Re: Loading a VCON with as an immediate value

2019-06-19 Thread Richard Kuebbing
macro

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Wednesday, June 19, 2019 1:31 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Loading a VCON with as an immediate value

To me, it seems silly to do the following, if I am only loading a VCON in a 
single place.

L R15,=V(ENTRY)

When I can do:

 LLILF R15,0
 ORG *-4
 DC V(ENTRY)

I am hoping that someone out there can tell me how I can improve the previous 3 
instructions to be something like:

  LLILH R15,ENTRY

HLASM complains the ENTRY is either relocatable or unresolved. Yes, it is 
relocatable, but at run time it will be a constant. Is there some "magic"
to get HLASM to know this?


--
Money is the root of all evil.
Evil is the root of all money.
With that in mind, money is made by the government ...


Maranatha! <><
John McKown

NOTICE: This communication is intended only for the person or entity to whom it 
is addressed and may contain confidential, proprietary, and/or privileged 
material. Unless you are the intended addressee, any review, reliance, 
dissemination, distribution, copying or use whatsoever of this communication is 
strictly prohibited. If you received this in error, please reply immediately 
and delete the material from all computers. Email sent through the Internet is 
not secure. Do not use email to send us confidential information such as credit 
card numbers, PIN numbers, passwords, Social Security Numbers, Account numbers, 
or other important and confidential information.


Re: You know you've been writing assembler too long when...

2019-05-28 Thread Richard Kuebbing
Roflmao for 52 yrs

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Phil Smith III
Sent: Tuesday, May 28, 2019 12:40 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: You know you've been writing assembler too long when...

.you're reading some British crime fiction that includes a  Detective Sergeant 
named O'Halloran, and every time there's a reference to

DS O'Halloran

you find yourself looking for the quote to close the literal!

 

 

NOTICE: This communication is intended only for the person or entity to whom it 
is addressed and may contain confidential, proprietary, and/or privileged 
material. Unless you are the intended addressee, any review, reliance, 
dissemination, distribution, copying or use whatsoever of this communication is 
strictly prohibited. If you received this in error, please reply immediately 
and delete the material from all computers. Email sent through the Internet is 
not secure. Do not use email to send us confidential information such as credit 
card numbers, PIN numbers, passwords, Social Security Numbers, Account numbers, 
or other important and confidential information.


Re: Getting the Last Condition code

2018-12-06 Thread Richard Kuebbing
In what environment?

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of esst...@juno.com
Sent: Thursday, December 06, 2018 5:15 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Getting the Last Condition code

Hi,I seeem to recall am instruction that returned the last/current condition 
code. Does any one Know the name of this instruction or its OP code ?
.
.
Paul D'Angelo
.
.


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: S0C1

2018-08-06 Thread Richard Kuebbing
In some very old code (1975-1985) where storage was severely constrained, the 
inline halfword was a value from 0-255 for error#s 0-255.

richard

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Seymour J Metz
Sent: Monday, August 06, 2018 4:02 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: S0C1

>It might be that some SPIE routines handle the interrupt, maybe print a 
>message, and then allow it through to the OS.

I vaguely recall someone using DC H'0' followed by a message in a special 
format to get a tailored error message via a SPIE exit.

>I do still remember S0C0 from the 360/91 days,

Multiple imprecise interrupt, as I recall.

>I wouldn't have thought of that one.  Pretty neat.

Not as neat as I thought at the time; see the footnote.

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


From: IBM Mainframe Assembler List  on behalf 
of glen herrmannsfeldt 
Sent: Monday, August 6, 2018 3:55 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: S0C1

Shmuel (Seymour J.) Metz wrote:

> No; it is guarantied to generate a program 001 interrupt.
> You only get an ABEND S0C1 if there is no SPIE/ESPIE exit.

I suspect that some use S0C1 as shorthand, and as you note incorrect, 
description for program interrupt 1.j

It might be that some SPIE routines handle the interrupt, maybe print a 
message, and then allow it through to the OS.

I do still remember S0C0 from the 360/91 days, which doesn't mean program 
interrupt 0, though the low bits will be .
Dreaded by anyone debugging from a hex dump.

> I've written code that distinguished[1] between a S/360 and a S/370 
> with a SPIE[2] for codes 1 and 2; the exit assumed that it was a S/370 
> if the code was 2.

I wouldn't have thought of that one.  Pretty neat.



- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: EQU * considered harmful

2018-08-01 Thread Richard Kuebbing
It's been a long time but once upon a time DS 0H was used for labels in code 
for two reasons.  TSO TEST liked it better than EQU *, and when a person mixed 
data and code, EQU * could possibly refer to an odd address.

And yes EQU * is a good way to mark a location in a record/control block that 
is either variable length or liable to change in length.

richard

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Gary Weinhold
Sent: Wednesday, August 01, 2018 2:40 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EQU * considered harmful

To avoid the problem Dan illustrates but retain the advantages Charles cites of 
not labeling specific instructions, we use

label  DS  0H  instead of   label EQU   *

But i think some of the point of the original post was lost, since the question 
was whether

label   EQU    *

was ever beneficial, where the "*" indicates current location rather than 
meaning generically any value.


On 2018-08-01 2:23 PM, Dan Greiner wrote:
> I too disagree (rather strongly).
>
> As an example, consider where EQU is used to give names to bits of a field in 
> memory.
>
> FLAGSDSX
> F_OPEN   EQU X'80'
> F_CLOSE  EQU   X'40'
> F_FUBAR  EQU   X'20'
> ...
>  TMFLAGS,F_FUBAR
>   JOTOTALLY_HOSED
>
> Furthermore, you can assign a "length" to each bit, and use that as an offset 
> in the field, e.g:
>
> FLAGSDSXL4
> F_OPEN   EQU   X'80',0
> F_CLOSE   EQU   X'40',0
> F_FUBAR  EQU   X'02',3
> ...
>   TMFLAGS+L'F_FUBAR,F_FUBAR
>
> (apologies if the syntax is not precise ... I'm doing this from memory at 
> home).
>
> As to Charles' comment about using EQU as a branch target, I'm a little bit 
> less comfortable.  If — by chance or accident — there happens to be code 
> before the EQU that knocks the location off a halfword boundary, this could 
> spell trouble.  E.g:
>
>   LA 7,ITS_ON
>   TMBYTE,BIT
>   BCR   X'01',7
>   ...
>   other instructions
> HI_MOM DCC'Hello'
> ITS_ON  EQU   *
>
> Since the constant "Hello" is 5 bytes long, this knocks the label ITS_ON onto 
> an odd boundary. If the branch had been directly to the location (as opposed 
> to BCR), HLASM would have flagged an error. But in this case, the error may 
> go undetected until execution — at which point the hardware will slap you 
> with a PIC-0006 (PIC-0006).



Gary Weinhold 
Senior Application Architect 

DATAKINETICS | Data Performance & Optimization 

Phone   +1.613.523.5500 x216
Email:  weinh...@dkl.com

Visit us online at www.DKL.com 

E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system. 



- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


wrong list but I am in a panic

2018-07-06 Thread Richard Kuebbing
ISPF edit recovery just failed.

"Nonexistent record referenced in recovery file or chain"

Do I have any options?  I appear to have lost at least one days work.

richard


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Two string instruction questions

2018-03-14 Thread Richard Kuebbing
It appears if r0 also equals length of second operand, you should get desired 
result.

Richard

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Seymour J Metz
Sent: Wednesday, March 14, 2018 12:22 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Two string instruction questions

If your search string is less than 256 bytes then CUSE should work, if I am 
reading th PoOps correctly. Set R0 to the length of the search string.


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


From: IBM Mainframe Assembler List  on behalf 
of Charles Mills 
Sent: Wednesday, March 14, 2018 11:51 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Two string instruction questions

1.   Is there a machine instruction that will find one string within
another? That given "Now is the time" and "is" would find the "is" and return a 
pointer to it? A machine instruction analog of Rexx POS?

2.   Searching the PoOp for such an instruction led me to CUSE. It does
not seem that CUSE could be used for this - is that correct? If I am reading 
CUSE correctly, then given "Now is the time", "All is well" and 2 or 3 would 
return the position of "is". Is my reading correct? What would that be good 
for? What would be a reasonable real-world use?



Thanks,



Charles


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Dr. John Ehrman

2018-02-21 Thread Richard Kuebbing
Might I suggest the life of John Ehrman rises to a level that calls for a page 
on Wikipedia.

Since Wikipedia wants to be only a secondary source, these messages could be 
considered the primary source.

I would build the page but I am not a writer of anything but code.

richard

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Don Higgins
Sent: Wednesday, February 21, 2018 3:47 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Dr. John Ehrman

All

I was so sorry to hear about the passing of John Ehrman.

Back on 11/20/17 I received this private email from John, 

“Hi, Don…. I retired from IBM in June 2016; at the same time, we discovered two 
types of cancer, so with treating that plus a couple of back surgeries has 
slowed me down a bit.   I hope all is well with you and yours, and that the 
recent hurricanes didn't do any lasting damage.  Regards ... John”

I replied but never heard back from him again.

I consider John Ehrman a friend, a true gentleman, and a technical hero.  He 
was leader of the IBM High Level Assembler Group and leader of the Assembler 
Group at SHARE.  I met John at SHARE many times and he introduced me several 
times when I made presentations at SHARE about the z390 Portable Mainframe 
Assembler and Emulator.  

Don Higgins
d...@higgins.net


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Looking for a way for a batch job to know if CICS is all the way up?

2018-02-20 Thread Richard Kuebbing
This borders on silly but has been used in other contexts:  Use status file 
which is set as the last thing in startup procedure.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Tony Thigpen
Sent: Tuesday, February 20, 2018 12:37 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Looking for a way for a batch job to know if CICS is all the way up?

I am looking for a way for a batch job to know if CICS is all the way up, i.e., 
has issued the "DFHSI1517 CICSTMS Control is being given to CICS." message.

I can look at the ASCB to know if a CICS is executing, but I don't see a way to 
know that it is really operational.

--
Tony Thigpen


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Solution OOP in HLASM - try#3

2018-02-15 Thread Richard Kuebbing
I'm a newbie - I didn't start in IT until 1961 and not using computers until 
1964, but I have worked on an application (a session manager) which was OOP.

1) it was multi-tasking and worked by passing messages between tasks.  When an 
RU was received from VTAM, a copy was made and the address of the copy was sent 
via queues to the task to process it.  Very OO.  All time dependant code was 
implemented using a timing task and message(s).  Send a message telling the 
time manager when you want something done and send one or more messages to be 
sent at that time.

2) all files were objects.  Tasks could not read files.  They had to request a 
record.  Each field of each record and each field of any interesting opsys 
field had a method.  If you want a value, call a method.  I wrote the methods - 
about 1k of them.  During a following upgrade, I added about another 1k of them.

3) all screen were defines as ISPF like specifications, with imbedded method 
names.

4) there were stacks one for each user pluse one for each user for each 
internal app opened.  The zero level had the global methods and any global 
data.  When you read a record, you push the record onto the stack with a simple 
small id.  If you are doing an update, you might want to push a second copy 
onto the stack.  If the record was e.g. a user record, you would push the 
matching profile record onto the stack. etc.

5) screen display consisted of passing the current local stack pointer for the 
current thread to the display object.  When control was returned, R15= 0(enter) 
4(pf3) 8(return) 12(cancel) 16(the world is about to end).  If rc=4, you sent 
the appropriate record to the file object for update.  If rc=0 you redisplay.  
If rc=12, free updated record.

6) each internal app had its own stack built on the global stack.  Each user of 
each internal app had its own stack built on the app stack.

7) as for code reuseability and inheritance, I took the code and made slight 
modification and made it decide at startup whether it was a VTAM pgm or a batch 
pgm.  It then executed according to what startup built.

It had a c/s feature where it could have a "conversation" with an "intelligent 
terminal emulator".  At the time CA bought us, there was a proposal on the 
table to use the connection from real terminal and our code to do things today 
being done w/XML and other markup languages.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Seymour J Metz
Sent: Thursday, February 15, 2018 1:43 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Solution OOP in HLASM

Well, I've been programming since 1960, have used everything from Assembler (D) 
to HLASM, write macros at the drop of a hat and have consistently defended the 
use of assemblers, but I have3 to disagree with you. 

While there is a good deal of theology in the OO camp about the one true 
definition of object oriented programming, I believe that none of them would 
accept the facilities you cite as encapsulation, methods, objects or 
polymorphism and I'm certain that none of them would accept MVS as an OO OS; in 
fact, I doubt that you could find an MVS developer who would accept the claim.


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



- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Man or boy test

2018-02-09 Thread Richard Kuebbing
I read this wiki entry https://en.wikipedia.org/wiki/Evaluation_strategy and it 
is clear as mud.  I think I have led a sheltered life.

As an aside, I followed the OOP discussion.  The session manager (TPX) I worked 
on had a kind of OOP.  It had a stack for each thread, the htreads were 
interruptible (conversational), you pushed objects onto the stack, methods used 
the stack to evaluate a host of variables (originaly about 1000, later over 
2000), the opsys storage was the zero level of the stack, each task was a 
server sending and receiving messages from everyone, including VTAM via exits, 
there was a timer task used for scheduling  And it was easier programming 
that in assembler than CICS using Cobol.

It had a client server piece in the form of an emulator.  It had the potential 
of being a pipeline between the host and the client.  But noone had to 
foresight to allow it.  And then we were bought by CA.

Intense nostalgia.


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Charles Mills
Sent: Friday, February 09, 2018 4:23 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Man or boy test

As I understand it, call-by-name means the following:

Suppose for example if you coded a subroutine that expected some sort of 
parameter, and called it with a random number function, the random number 
function would (in most languages) get evaluated once before your subroutine 
was called, and your subroutine would see it as a constant. If you printed it 
three times in a loop it would be the same all three times.

With call-by-name, 'RAND()' (or whatever) would not get evaluated by the caller 
but rather passed to your subroutine "as-is." It would get evaluated whenever 
your subroutine referenced it. If you printed it three times in a loop you 
would get three different values.

It's not really "call by name" but rather "call with function" as opposed to 
"call with value of function."

Charles


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Any real need for sequence numbers in 73-80 any more?

2017-12-11 Thread Richard Kuebbing
We use Endevor and have for decades.  It has a feature called PDM (Parallel 
Development Manager) which allows a base program to be compared to two 
versions.  The resulting "report" is editable.  The edited report can be used 
to create a new version.  Beautiful program.

richard

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Jonathan Scott
Sent: Monday, December 11, 2017 10:29 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Any real need for sequence numbers in 73-80 any more?

Ref:  Your note of Mon, 11 Dec 2017 07:25:43 -0800

> In VM-land, they're canon, because of use of CMS UPDATE for maintenance.
> z/OS is poorer for lack of an equivalent: I know there's IEBUPDTE, but 
> with no good way to create updates, it doesn't seem to be used much. 
> XEDIT in UPDATE mode makes source maintenance SO much easier! A shame 
> that functionality never got added to ISPF.
>
> ...phsiii

The SUPERC utility (ISRSUPC from ISPF, or ASMFSUPC from the HLASM
Toolkit) has an UPDMVS8 option which compares two levels of a file and produces 
an IEBUPDTE-type update file. It also has a similar UPDCMS8 option to produce a 
CMS UPDATE file.

That method is in many ways safer and more flexible than using the editor to 
create update files, as it is not confused by lines which have been touched 
without actually having been changed, and it does not even need the new version 
of the file to have sequence numbers. So for example, one can update a source 
file on a workstation, upload it to VM and create a "delta" for the 
corresponding support copy maintained using sequence numbers in IBM's SPA 
repository.

Jonathan Scott
HLASM, IBM Hursley, UK


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: The Pointlessness of handwriting "efficient" code (was One Byte MVC Versus IC/STC)

2017-10-16 Thread Richard Kuebbing
Efficiency is doing things right. Effectiveness is doing the right things. - 
Peter Drucker 

There is nothing so useless as doing efficiently that which should not be done 
at all. - Peter Drucker

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Steve Smith
Sent: Monday, October 16, 2017 3:02 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: The Pointlessness of handwriting "efficient" code (was One Byte 
MVC Versus IC/STC)

And if Dave Cole isn't a high enough authority (but he is :-)),

"Programmers waste enormous amounts of time thinking about, or worrying about, 
the speed of noncritical parts of their programs, and these attempts at 
efficiency actually have a strong negative impact when debugging and 
maintenance are considered. We should forget about small efficiencies, say 
about 97% of the time: premature optimization is the root of all evil."

Donald Knuth, "Structured Programming with Goto Statements". Computing Surveys 
6:4 (December 1974), pp. 261–301, §1.


sas


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: The Pointlessness of handwriting "efficient" code (was One Byte MVC Versus IC/STC)

2017-10-16 Thread Richard Kuebbing
Thanks for the story.  I started writing assembler in 1967 on early serial of 
360/75 (machine 3 or 4) by reading fortran generated code.

I also focused on efficiency.  My typesetting program ran 10 times faster then 
its competition.  A programmer at Dept of Commerce complained my output module 
for Termtext was a ripoff because it ran at the same speed as a file copy.

One point about the future.  If assembler is to be relevant to the future, it 
must be by using macros.  Whenever I have to do a repetive task, I write either 
a macro or a subroutine, or both.

richard

peace be with you

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of David Cole
Sent: Monday, October 16, 2017 12:24 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: The Pointlessness of handwriting "efficient" code (was One Byte MVC 
Versus IC/STC)

First, let me start by saying I am NOT talking about the kernel of sorting 
routines intended to sort records by the millions. Nor am I talking about any 
similar place where saving a few nano-seconds here and there might actually 
matter. If that's your concern, then this post is not for you.

I am talking about typical logic whose execution frequency ranges from a 
handful per week all the way up to maybe a million times per hour. (Just 
guessing here, but it sounds good.)

I'm also talking about hand coded Assembler. If you want to write efficient 
code, use a compiled language. Use C. Use Cobol. Use whatever. But don't use 
Assembler. Assembler is probably the worse language to choose.

Why? Well, read on.



I started writing assembler back in the late 1960s. I've been writing assembler 
for nearly 50 years. I've written a LOT of assembler, and I still love writing 
it!

Back when I started, one of my coding ethics was "efficiency", both in space 
and time. I wanted my programs to accomplish as much as they could with the 
fewest instructions taking up the least number of bytes as possible. (That, of 
course led to some gawdawful code being written!)

Well, back in that day, when a large machine had maybe a half a meg of storage, 
and megabyte storage frames literally had to be wheeled in on trucks, program 
size actually did matter. And with storage access speeds measured in micro 
seconds (and even milliseconds for the LCS storage), speed mattered too. But 
those days are long gone, and I have long since grown out of my childish ways.

Yes, speed does matter, and IBM has invested an immense amount of expertise and 
creativity to come up with ways to leverage parallelism and pipelining and only 
god knows what all else to squeeze out every unneeded nanosecond of processing 
time it can. It is statistics based and it is mind-numbingly complex. Any given 
combination of workflow will never behave the identically same way one run to 
the next. (Even though statistically speaking, efficiencies will be repeatable.)

But all these techniques for efficiency that IBM has created are not human 
compatible. They are too complex, they are too messy[!] and they are not even 
the same techniques from one machine to the next. In fact, sometimes code 
written to be efficient on one machine will be actually inefficient on another!

In other words, if you are using hand-coded Assembler, and you want to write 
the most efficient code possible, you will end up writing something...
   - That is messy,
   - That is ugly,
   - That will be difficult to read, follow and understand,
   - That will probably fail to be the most efficient possible,
   - And that you will probably have to rewrite when IBM comes out with its 
next machine.

So if there is anything that needs to be "Laughed out of code review", it's 
feeble concerns with such questions as MVC-onebyte vs. IC/STC. As a prior 
gentleman commented, "rubbish!"

The point is, with code written in any language (especially for production 
program development), one of the most important ethics is clarity, because 
without that, the code will not be maintainable over time. 
(www.colesoft.com/files/presentations/commercialqualityprogramming.pdf)

Obscure code is what should be laughed out of code review, and serious attempts 
to write so called "efficient" code (a) will fail to produce perceptible 
results and (b) will only end up obfuscating the code.

So if all these wonderful efficiency techniques that IBM has come up with are 
too complex/obscure/ugly to use, then what's the point? COMPILERS! That's the 
point.

Let the compilers be concerned about efficiency. 
That's their job. That's what they do far far better than humans.

When IBM develops new pipelining techniques and new methods to achieve better 
parallelisms, they don't do it in a vacuum. They get their compiler writers 
involved! There is a back-and-forth between the two teams: Between the hardware 
developers and the compiler writers. Together, they hammer out what will work 
and what won't. In the end, the compilers are fitted to

Re: Flag "OMEN" BS for Deletion and AS Dobrin Removal of from ListServ

2017-09-28 Thread Richard Kuebbing
What does this mean?

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Moderator
Sent: Thursday, September 28, 2017 6:37 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Flag "OMEN" BS for Deletion and AS Dobrin Removal of from ListServ

https://listserv.uga.edu/cgi-bin/wa?A2=ASSEMBLER-LIST;e8b7630f.1709


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: z14 PoO Available

2017-09-25 Thread Richard Kuebbing
The word in Houston when the name was chosen was that the consultants who came 
up with the name using history and the algorithm you describe below got really 
big bucks.  btw one of the previous names was ESSO, which when spoken can be 
followed by a word beginning with B.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Monday, September 25, 2017 3:24 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z14 PoO Available

On Mon, Sep 25, 2017 at 1:53 PM, Abe Kornelis  wrote:


​I was told that "Exxon" exists simply because it is not a word or reminiscent 
of a word in any major language. The previous name of Enco, as I was told, 
means "broken car" in Japan. Not a good name for a gasoline.


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: interesting, to me, new z14 instruction: BIC

2017-09-15 Thread Richard Kuebbing
I find this intereesting:

The second operand is fetched using the current
DAT and address-space controls in the PSW.
However, the branch address that is fetched from
the second-operand location is treated as an
instruction address and is treated as a real
address in the real mode, as a primary virtual
address in the primary-space mode, secondaryspace
mode, or access-register mode, and as a
home virtual address in the home-space mode.

Not just an adcon but a "real address"!

Richard

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Friday, September 15, 2017 12:47 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: interesting, to me, new z14 instruction: BIC

On Fri, Sep 15, 2017 at 11:20 AM, Tony Harminc  wrote:

> On 15 September 2017 at 11:46, Martin Truebner 
> wrote:
> > Did they forget BIRC (same as BIC, but the address of the storage is 
> > relative to branch instruction).
> >
> > Yes, a table with routine-addresses will most of the time exist in 
> > storage addressable with a base-register (or an Index-register)- but 
> > what about the cases where this is not true?
>
> I don't think they forgot it; I think it's not useful for the scenario 
> in question. That is, where the branch address is passed in storage 
> (typically on a stack) from a calling routine. There are far fewer 
> cases where the address of the branch address would be known at 
> compile time and be instruction relative. Maybe you can suggest a 
> realistic use case for this.


> What I found interesting is that there is only a 64-bit instruction 
> (though it has no G in it); there is no 31-bit version.
>

​Well, I guess that IBM figured that saving 4 bytes in the "adcon" wasn't worth 
the extra decoding. The current addressing mode determines whether the branched 
to address is a 24, 31, or 64 bit address.​ As best as I can tell, the excess 
bits are simply ignored. Like doing a fullword load into a register in 24 bit 
mode to use as a branch address. The contents of the high order byte are 
irrelevant and ignored.



>
> Tony H.
>



--
UNIX was not designed to stop you from doing stupid things, because that would 
also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: interesting, to me, new z14 instruction: BIC

2017-09-15 Thread Richard Kuebbing
Last time I saw indirect addressing was on the 7094.  That machine was storage 
constrained and had no "general registers".

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Friday, September 15, 2017 10:12 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: interesting, to me, new z14 instruction: BIC

Branch Indirect on Condition. Instead of branching to the address pointed to by 
the second operand, it uses the second operand as the address of an 8 byte area 
which contains the address to which to branch. I guess this is sort of like an 
LG combined with a regular BCR. A nice way to implement branching via a branch 
table.

--
UNIX was not designed to stop you from doing stupid things, because that would 
also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Source address significance for clearing MVCL

2017-08-17 Thread Richard Kuebbing
So I looked at the doc.

OI works because the length will have been cleared or set to a value less that 
X'00FF'.

It appears the correct opcode is OILH.

New corrected entry is

OILH  Rx,X'4000' inserts X'40' into high order byte for pad character

Obviously this wiki entry has never been used.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Steve Smith
Sent: Thursday, August 17, 2017 12:15 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Source address significance for clearing MVCL

Your wiki note is incorrect.  MVCL doesn't use the high-word for its length 
registers.  And 'O' instructions do not insert, they OR (duh).
OILH is useful when a length has already been loaded, and you know the high 
byte is zero.  OILF is overkill, but some say you can never have too much 
overkill.

sas

On Thu, Aug 17, 2017 at 12:08 PM, Richard Kuebbing  wrote:
> I have a note in my wiki that says this is possible
>
> OIHF  Rx,X'4000' inserts X'40' into high order byte for pad 
> character
>
> -Original Message-
> From: IBM Mainframe Assembler List 
> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith
> Sent: Thursday, August 17, 2017 12:04 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Source address significance for clearing MVCL
>
> HLASM doesn't do "obviously I meant" (aka DWIM).
>
> The source address register is ignored, doesn't have to be cleared, and will 
> not be changed, when the source length is 0.  btw, the cool modern way to set 
> that with one instruction is LLILH Rx,x'4000'
> (e.g.).  Fair warning, this clears the high-word, if that matters to your 
> program or environment.
>
> sas
>
> On Thu, Aug 17, 2017 at 11:27 AM, Robin Vowels  wrote:
>> From: "Charles Mills" 
>> Sent: Friday, August 18, 2017 1:04 AM
>>
>>
>>> I'd need a whole lot more than two SR R2,0's.
>>
>>
>> Obviously I meant SR R2,R2.
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>
>
>
> --
> sas
>
>
> - The information contained in 
> this communication (including any attachments hereto) is confidential 
> and is intended solely for the personal and confidential use of the 
> individual or entity to whom it is addressed. The information may also 
> constitute a legally privileged confidential communication. If the reader of 
> this message is not the intended recipient or an agent responsible for 
> delivering it to the intended recipient, you are hereby notified that you 
> have received this communication in error and that any review, dissemination, 
> copying, or unauthorized use of this information, or the taking of any action 
> in reliance on the contents of this information is strictly prohibited. If 
> you have received this communication in error, please notify us immediately 
> by e-mail, and delete the original message. Thank you



--
sas


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Source address significance for clearing MVCL

2017-08-17 Thread Richard Kuebbing
I have a note in my wiki that says this is possible

OIHF  Rx,X'4000' inserts X'40' into high order byte for pad character

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Steve Smith
Sent: Thursday, August 17, 2017 12:04 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Source address significance for clearing MVCL

HLASM doesn't do "obviously I meant" (aka DWIM).

The source address register is ignored, doesn't have to be cleared, and will 
not be changed, when the source length is 0.  btw, the cool modern way to set 
that with one instruction is LLILH Rx,x'4000'
(e.g.).  Fair warning, this clears the high-word, if that matters to your 
program or environment.

sas

On Thu, Aug 17, 2017 at 11:27 AM, Robin Vowels  wrote:
> From: "Charles Mills" 
> Sent: Friday, August 18, 2017 1:04 AM
>
>
>> I'd need a whole lot more than two SR R2,0's.
>
>
> Obviously I meant SR R2,R2.
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus



--
sas


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Question about CPUs

2017-07-31 Thread Richard Kuebbing
On the first multiple processors (360/40 and [360/65 later called? - fuzzy old 
memory] 360/67)  in a multitasking program, TS was the only ATOMIC instruction. 
 You obtained lock to a block of storage using whatever lock was setup for that 
block of storage by either the operating system or by the appl system, and then 
it was safe to update.  You released the lock asap.  You ignore the lock at 
your peril.

Using CS and CDS, you pulled a block off a stack.  You designed so that at that 
point, noone had the address of that block of storage, or "knew" not to use it. 
 It was a VTAM application.  Each user block had the address of the dedicated 
task for that user for syncing.

Or you used enques of type SYSTEMS to lock the "key" (whatever that was) of a 
block of storage. as is done today by some application/system systems.

For example in the code I worked on, you wanted to update a VSAM record.  You 
got the record and locked the VSAM key using enque on a certain queue.  When 
you were done, you released the enqueue asap.  For storage, you, the 
programmer, locked a userid in order to maintain any piece of storage chained 
off the root user block.  The user themselves could change any of their control 
blocks that was alowed using same protocol.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Robin Vowels
Sent: Monday, July 31, 2017 11:50 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Question about CPUs

From: "Charles Mills" 
Sent: Monday, July 31, 2017 2:57 PM


> Nay. Many, many instructions are not atomic. On a single CPU, yes. For 
> multiple CPUs, not atomic. Until the z13 (?), for example, NI, OI and 
> XI were interruptible within a reference to a single byte. NI is 
> actually fetch, AND, store. It could be interrupted between the fetch and the 
> store.

What about the decimal instructions? such as AP, SP, MP, DP, and others such as 
NC, OC  ?

> So two processors doing NI or OI on the same byte could get "logically 
> impossible" results.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Question about CPUs

2017-07-31 Thread Richard Kuebbing
I agree TS was first "atomic".  Second afaicr was CS and CDS for queue 
maintenance.  Used extensively in session manager for sending and receiving 
messages in an object oriented multi-task environment.

I remember that the explanation given previously on one of these lists was that 
TS was done for the first IBM multiprocessor.  All they needed was a "lock" 
flag.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Gary Weinhold

I think (TS) Test and Set was/is atomic and AFAIK was the earliest implemented 
atomic instruction.  I think it addressed the requirement to allow 
interruptible code to fetch, test,  and modify a single byte on a single CPU 
machine with integrity.  An external or I/O interrupt could undermine the 
integrity  of a TM, Bx, OI/NI instruction sequence in that environment.


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Table Searchig with a Mask

2017-06-18 Thread Richard Kuebbing
Is a binary search ever appropriate on machines like the Z where the penalty 
for not being in the cache is so high?

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of esst...@juno.com
Sent: Saturday, June 17, 2017 11:55 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Table Searchig with a Mask

Hi everyone

I would like some help in reducing the number of instructions required to 
search a table.
The table is in no particular order, so a Binary Search may not be appropriate 
here.
.
.
I will try to explain this.
.
I have a structure with X number of fields For this example lets assume:
STRUCTUREEQU *
USERID   DS CL8 
COMPANY_CODE DS CL4
JOB_NAME DS CL8
FILE DS CL8

I also have an Array (table) of Acceptable Values with the same elements   
as my structure.
I can search the table using a single compare for a length of 28.
.
.
However some of the table entries contain an asterisk "*" in the first position 
of the respective field. The asterisk means to accept any value from the 
structure.
For Example:
ARRAY EQU  *
TUSERID   DC CL8'JOSEPH  '
TCOMPANY_CODE DC CL4'*   '
TJOB_NAME DC CL8'REPORT  '
TFILE DC CL8'*   '
.
In order to search the table using a single compare instruction, I would need 
to overlay the respective elements in the structure with the Asterisk from the 
corresponding element in the Array Table Entry. 
.
This would mean I would need to compare each element in the ARRAY entry for the 
Asterisk, and if present move the corresponding field to the structure.
   CLI TCOMPANY_CODE,=C'*'
   JNE NEXT_ELEMENT
   MVC COMPANY_CODE,TCOMPANY_CODE .
I prefer not to test each element in the ARRAY for an Asterisk and Move them 
individually to the structure, prior to comparing the structure with the Array 
Entry. 
.
I'm not aware of any instruction that will move selectively all fields with an 
Asterisk "*". Which Is what I am looking for, then I can use a single move or 
four Moves and continue to use a single compare instruction.
.
Again I'm looking for the fewest amount of instructions to accomplish this. 
.
What Alternatives are there ?  
A long time ago I did see someone do something similar with a Translate and 
Test.
But again this is several iterations of TRT and a Move for each Array element.
.

Thank You
Paul D'Angelo
 


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: random quest

2017-05-18 Thread Richard Kuebbing
At least the posts are mostly intelligible to one who does not have any degrees 
in mathematics.  I find the article (link below) to be mostly opaque because of 
math jargon: https://en.wikipedia.org/wiki/Randomness_tests

But then the few articles I published when I was a physicist are loaded 
w/physics jargon.

The only thing remotely interesting about the two special elections we just had 
/ are having in GA/USA is seeing the manipulation of language in sending 
messages.  It makes me nostalgic for SNA.  Each byte (aka token) having one 
meaning.

DrK

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Gary Weinhold

It could easily be mistaken for a board game forum until you read the actual 
posts (or maybe even after).



- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: random quest

2017-05-17 Thread Richard Kuebbing
I should have known that email would screwup the table.  Table fixed below for 
what it is worth.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Richard Kuebbing
Sent: Wednesday, May 17, 2017 6:15 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: random quest

So I have coded my "final" solution and am testing it.  I used SORT to "count" 
duplicates.  I haven't decided how my personal "goodness" will be done.  The 
less technical a person on the project is the less likely they care.  DIGIT 
means how many zeroes are in the # of elements.  For cpu 2964-N63, running 2.2, 
Cobol 6.2 (OPT(0) program ran last case in 2.19 cpu seconds w/srb= 0.01 sec.  
Wall was 3.9 min.  We have become spoiled.


SEED=12345
DIGIT   elementsunique
1   10  7
2   100 60
3   1000634
4   10,000  6,280
5   100,000 63,252
6   1,000,000   632,271
7   10,000,000  6,329,187


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: random quest

2017-05-17 Thread Richard Kuebbing
So I have coded my "final" solution and am testing it.  I used SORT to "count" 
duplicates.  I haven't decided how my personal "goodness" will be done.  The 
less technical a person on the project is the less likely they care.  DIGIT 
means how many zeroes are in the # of elements.  For cpu 2964-N63, running 2.2, 
Cobol 6.2 (OPT(0) program ran last case in 2.19 cpu seconds w/srb= 0.01 sec.  
Wall was 3.9 min.  We have become spoiled.


SEED=12345
DIGIT

elements

unique

.

1

10

7

.

2

100

60

.

3

1000

634

.

4

10,000

6,280

.

5

100,000

63,252

.

6

1,000,000

632,271

.

7

10,000,000

6,329,187

.






-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Paul Gilmartin


On 2017-05-17, at 12:59, Martin Ward wrote:



> On 16/05/17 23:46, Richard Kuebbing wrote:

>> Fantastic.  This looks to be the level of brilliance I was looking

>> for - simplicity plus 100% solution.

>

> To generate a random permutation of the numbers from 1 to 99,999 the

> usual method is the Fisher-Yates shuffle, dating from 1938:

>

> https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle

>

Damn!  So Melvyn and I won't be able to publish our re-discovery.



> This takes O(n) time, as opposed to O(n log n) for Peter's "generate

> and sort" method. With only 99,999 numbers the extra CPU time may not

> be significant, depending on how often you need to generate a

> sequence.

>

Presuming that the table fits in main memory.  On the first mainframes I used, 
99,999 wouldn't have fit.



> There are various statistical tests for randomness, if you don't

> entirely trust your random number generator:

>

> https://en.wikipedia.org/wiki/Randomness_tests

>

And, even worse:


https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#Pseudorandom_generators



... a shuffle driven by such a generator cannot possibly produce more

distinct permutations than the generator has distinct possible states.

..., to minimize bias, the number of states of the PRNG should exceed

the number of permutations by at least several orders of magnitude.



I doubt that any PRNG available nowadays has 9 ! internal states.

(Probably no one will notice.)



Is DFSORT the Swiss Army Knife of z/OS?



-- gil


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: random quest

2017-05-16 Thread Richard Kuebbing
Fantastic.  This looks to be the level of brilliance I was looking for - 
simplicity plus 100% solution.

So follow-up question.  I have a lot of advanced math in grad school, all 
inapplicable to this.  Is there any kind of measure of how "random" a set of 
numbers is?  Someone internal is bound to ask.  I am thinking of graphing the 
difference [=n(i+1)-n(i)] and looking at distribution.  The client(s) are 
business persons and are unlikely to ask.

Question 2:  I have a passion for documenting things.  Do you wish to have your 
name attached to this idea?

Tomorrow when I have time I will peruse all the answers.

Profound thanks

Peace be w/y'all

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Farley, Peter x23353
Sent: Tuesday, May 16, 2017 4:51 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: random quest

1.  Use either CEERAN0 or FUNCTION RANDOM to generate a column of 99,999 
random numbers.  It's OK if there are duplicates.
2.  Add a second column using SORT with sequential numbers from 1 to 9 
(use the SEQNUM option). 
3.  SORT by the first column only and DO NOT specify the EQUALS option.
4.  Use the numbers in column 2 after sorting as your 99,999 randomly 
ordered numbers

You can combine steps 2, 3, and 4 in one SORT execution.  INREC to add the 
SEQNUM's as a second column, SORT by first column, OUTREC to select only the 
second column for output.

HTH

Peter

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Richard Kuebbing
Sent: Tuesday, May 16, 2017 4:28 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: random quest

So I need a set of 99,999 random numbers which are 5 digits and unique, i.e. no 
duplicates.  CEERAN0 and Cobol FUNCTION RANDOM both give sets w/30+% duplicates.

I have seen website random.org.

Anyone have to ever done this thing?

Anyone have suggestions?

--

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.


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: random quest

2017-05-16 Thread Richard Kuebbing
Correct - the order of the numbers must be random.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Mark Boonie
Sent: Tuesday, May 16, 2017 4:35 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: random quest

Perhaps there's something about the question I don't understand, but if you 
want 99,999 unique 5-digit numbers then you'll end up with the numbers
0 to 9.  Or do you just want the *order* of the numbers to be random?

- mb


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


random quest

2017-05-16 Thread Richard Kuebbing
So I need a set of 99,999 random numbers which are 5 digits and unique, i.e. no 
duplicates.  CEERAN0 and Cobol FUNCTION RANDOM both give sets w/30+% duplicates.

I have seen website random.org.

Anyone have to ever done this thing?

Anyone have suggestions?

Richard Kuebbing

Efforts and courage are not enough without purpose and direction. - John F. 
Kennedy
Fasten your seat belts, it's going to be a bumpy ride. - Bette Davis (as 
character Margo Channing) _All About Eve_1950
Furious activity is no substitute for understanding. - H. H. Williams
Our greatest danger in life is in permitting the urgent things to crowd out the 
important. - Charles E. Hummel
Quidquid latine dictum sit, altum videtur.



- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)

2017-05-11 Thread Richard Kuebbing
The only issue I ever had with this is that S0C1's are common "real" abends.  
On the other hand this almost never occurs:

EX 0,*
EXRL 0,*

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Charles Mills
Sent: Thursday, May 11, 2017 1:44 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Quick error termination of an assembler routine (Was: Performance of 
Decimal Floating Point Instruction)

What is *wrong* with DC H'0'? It has the advantage of being incredibly 
straightforward. I had to spend a minute thinking about J *+2; I pretty much 
guarantee you anyone with six months of HLASM experience would "get" DC H'0'.

I don't write much assembler anymore but if I did I think I might define a 
bunch of error situation equates in the 0 < value < 256 range:

Blowup_no_input EQU 1
Blowup_invalid_parm EQU 2
Etc.

Then one could code 

  DC  Y(Blowup_no_input) 

And it would (a.) be somewhat self-documenting in the source code and (b.) 
would more or less diagnose itself in a dump.

And if 255 were not enough codes, one could go to 16 million+ with DC 
FL4(Blowup_whatever).

Frankly, I use DC H'0 very infrequently, usually only temporarily ("I can't 
possibly be going through this code, could I?"). If is a "real" error then it 
should have a "real" termination with messages, a return code, a user ABEND, 
whatever is appropriate to the context, but something better than a 
S0C1/S0C3/S0C7. Three years from now if our support crew gets a call reporting 
a S0C1/S0C3/S0C7 are they going to have a clue? But if we staked out a user 
ABEND number that we always used then they could go "aha!" and look up the 
reason code.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: Thursday, May 11, 2017 10:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction

On Thu, May 11, 2017 at 12:12 PM, Paul Gilmartin < 
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On 2017-05-11, at 06:34, Charles Mills wrote:
>
> >> If you need a way to ABEND, use the proper LE service, or an 
> >> assembler
> > routine. Anything else will bite you sooner or later.
> >
> > AMEN!
> >
> No more "DC H'0'"
>

​My current favorite is : J *+2 which results in a S0C1, since it is now 
guaranteed that x'00' will _never_ be used as a valid opcode. It replaces my 
previous favorite of: EX * which is an S0C3.


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: converting character to packed

2016-10-18 Thread Richard Kuebbing
That would be interesting code to see

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of robi...@dodo.com.au
Sent: Tuesday, October 18, 2016 2:34 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: converting character to packed

Using TR in a different way omits the commas and decimal point, sign, and any 
other funny characters. 
To do this, you swap the roles of the translate table and the string being 
translated.

- Original Message -
From: "IBM Mainframe Assembler List" 
To:
Cc:
Sent:Mon, 17 Oct 2016 16:24:18 -0400
Subject:Re: converting character to packed

 The TR command would leave all the non-numeric characters in the data, 
translated as you specified, so you'd have to have a technique to pass through 
the result to remove them. A TRT instruction would help you find the 
non-numeric characters, but in this case it would be considerably slower in 
execution than the character by character loop approaches suggested.

 If the original manually-entered data is not edited as it's entered, there 
could be many other characters besides "$",",","." and EBCDIC numeric 
characters in it. That's something TRT could check for.

 Gary Weinhold
 Senior Application Architect

 __

 On 2016-10-17 15:11, robi...@dodo.com.au wrote:

 Won't a TR followed by a PACK do this?
Email sent using Dodo Webmail


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: Test of List

2016-10-06 Thread Richard Kuebbing
moribund perhaps

I was thinking of posting yesterday when I was trying to tackle how to handle 
the simple problem of using the length attribute to update a arithmetic macro 
variable.  I am still unhappy with the sloppy nature of the code.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Steve Thompson
Sent: Thursday, October 06, 2016 8:40 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Test of List

The last email I've gotten from the list was 10JUN2010.

Is this list still working?

Regards,
Steve Thompson


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: COBOL CALLing ALC ...

2016-07-12 Thread Richard Kuebbing
We are a very large mainframe shop and use Cobol extensively.  We have both 
main program assembler and Asm subroutines.

We find that if you call a AMODE 24 subroutine dynamically, Cobol complains.

I recommend that before STM 14,12 in subroutine, use the following so that you 
always return to the caller in the mode they called you

BSM   R14,0   *Save mode bit to use when exit

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Steve Thompson
Sent: Monday, July 11, 2016 4:10 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: COBOL CALLing ALC ...

I am trying to determine how I am supposed to know if a COBOL program is 
AMODE=31/ANY when they call an ALC subroutine.

The routine getting control has just been through an upgrade from
1979 style of NOREUS and data mixed in with instructions.

Also, this routine is not LE conforming. It has never been.

I'm used to doing a BSM to return as a subroutine to have addressing modes 
match. I had assumed that the caller did BSSM not just BASR or BALR

So when the program ends and returns to the caller via BSM R14, wow, you would 
not believe all the ESTAEs that get driven (including this programs ESTAEX). LE 
throws a fit and thankfully, having set up SYSMDUMP with DISP=MOD, I get the 
dump I need and IPCS ignores the second dump. ;-)

So, R14 does not have the hi-order bit on when I am called.

COBOL being used is Enterprise COBOL 4.2 (which is currently supported).

The environment, just so we are all on the same page is JES2, z/OS 2.2, z13EC.

Regards,
Steve Thompson

PS. I have been scanning various manuals (including the LE one) and nothing is 
said about this. And I don't have any MVS/XA or MVS/ESA manuals around anymore.



- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you


Re: ASM0A43E Previously Defined Symbol

2016-04-14 Thread Richard Kuebbing
the traditional way of dealing with this is to use field prefixes.  If you have 
copybooks, instead use macros to generate the copybook and do the refixing.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of michealbutz
Sent: Thursday, April 14, 2016 3:00 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: ASM0A43E Previously Defined Symbol

Hi

If I have to two dsects with the same label and I qaulify the usage of the 
dsect with a label on the using shouldn't that do away with above error message

TIME1   DSECT
HOURS DS   XL2

AA USING TIME1,R7
 
TIME2 DSECT
HOURS DS XL2

BB  USING TIME2,R8

  MVC   AA.HOURS,HH
  MVC  BB.HOURS,HH


- The information contained in this 
communication (including any attachments hereto) is confidential and is 
intended solely for the personal and confidential use of the individual or 
entity to whom it is addressed. The information may also constitute a legally 
privileged confidential communication. If the reader of this message is not the 
intended recipient or an agent responsible for delivering it to the intended 
recipient, you are hereby notified that you have received this communication in 
error and that any review, dissemination, copying, or unauthorized use of this 
information, or the taking of any action in reliance on the contents of this 
information is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail, and delete the original message. 
Thank you