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

[Joel C. Ewing]

Well, ...  the IBM 1401 was built in a substantial frame; and in the
context cited it appears to have the only (hence surely the "main")
computer present.  Other members of the same general family like IBM
1410 were certainly regarded as a mainframe.  I'm pretty sure any
computer large enough to require one or more dedicated frames  was
called a "mainframe" in those days.  When mini-computers first came out,
they weren't considered mainframes because they were typically only the
size of a single rack and could even be carried.

 With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
(started in Infantry but ended up as head Company Clerk at HHC of "The
Old Guard" at Ft Myer VA).  I remember reading some memo that came down
from above the Battalion suggesting the possibility of using a
punched-card-based system for maintaining and producing our Company
Roster.  That might have involved an IBM 1401, but my impression at the
time was that the functions they were describing could easily have been
done with just unit-record equipment.  Nothing ever came of it while I
was there.   It would have saved us the periodic tedium of one or more
man-hours of manually typing up a new roster in which few names changed,
but given that our time was cheap and available, there would have been
no way to cost-justify using a process that would save our time but slow
down the overall process by requiring outside resources.   Clearly, at
that time, punched card decks were one of the databases used for
tracking military personnel.
    Joel C. Ewing

On 12/26/18 2:42 PM, Seymour J Metz wrote:
> What is he smoking? Since when was the 1401 a mainframe?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Mark Regan 
> Sent: Wednesday, December 26, 2018 8:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How about a little Christmas fudge? | Computerworld Shark tank
>
> https://secure-web.cisco.com/1iMlW_GZ2Scqioa5F4rqymcywO0OTBLBFOtYPuQZZF6F73Kv0x_B9nU3SOTiheXf32DsESHEBSvbzXuJ78Z2XaRKtXr7A2GITbjxnEDGjBqcDiOzF9WOIQCYJIH89nABmY7xso9DckpD3Q10YPvrxhvPVeFvR6IYMhBl0Po4k4-03fXnkJSammKYm3lrjMJyX4f-lcp9YlEt59dyzYTF_at6wT-i9VPdyfHx5DVlOyFFEzAQxZe-ifUcS7uOAE70lUB6w6ZfwDLRp9vhqQVEaCVSjXFSY0F4a2YhM92FII0XRqIAu4y7yW4Iop4TXQVM-iMQuqleDME3jgueepL3jXWQ797SaO4hRpNph47Gl9FOTKIqwIXeAe2DNqPGTQMlRexhctM6zHXZYT2EbywHPaw/https%3A%2F%2Fwww.computerworld.com%2Farticle%2F3330396%2Fapplication-development%2Fsituation-normal-all-fudged-up.html
>
> ...
>

-- 
Joel C. Ewing

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

Re: Programs in the PPT on z/OS 2.2

[Tom Conley]

On 12/26/2018 3:39 PM, Peter Ten Eyck wrote:

How does a program get added to the PPT?

For example in SYS1.PARMLIB(SCHED**) has numerous programs are added to the PPT 
at say IPL time, but the console command D PPT display many more? Is there a 
default table of PPT programs? Other than looking at a SCHED** member, how 
would I determine which programs are in the PPT via a SCHED** member and which 
are in the PPT through some other means?

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



The D PPT command tells all.

Regards,
Tom Conley

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

Re: Assigning a Data Class to HSM BACKUP files

[Brian Fraser]

I use different DATACLAS for HSM tapes from other tapes to assign a
smaller virtual volume size.
HSM Mig & Backup tapes use a DATACLAS that gives tapes a maximum size
of 1,000 MB, other tapes get 6,000 MB


On Thu, 27 Dec 2018 at 03:07, Dan D  wrote:
>
> I agree, the SMS routines could easily be used, but why?
> Other than the volume count I don't know what you would want to change.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Programs in the PPT on z/OS 2.2

[Roger Lowe]

On Wed, 26 Dec 2018 14:39:32 -0600, Peter Ten Eyck 
 wrote:

>How does a program get added to the PPT?
>
>For example in SYS1.PARMLIB(SCHED**) has numerous programs are added to the 
>PPT at say IPL time, but the console command D PPT display many more? Is there 
>a default table of PPT programs? Other than looking at a SCHED** member, how 
>would I determine which programs are in the PPT via a SCHED** member and which 
>are in the PPT through some other means?
>
This is for z/OS 2.3 - 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieae200/ieae200541.htm

Roger

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

ibm-main@listserv.ua.edu

[Rob Schramm]

My understanding is that you can request copies by contacting author
directly or thru IBM Sales reps.. although I have had no luck requesting
them thru Sales Reps.  I always wanted the issues related to system Z CPUs
etc.. always found them interesting.

Rob Schramm

On Thu, Dec 20, 2018 at 10:34 AM Jerry Callen  wrote:

> From another thread:
>
> > Many of these techniques have been documented in the IBM Journal of
> Research and Development.
> > Unfortunately, a few years ago IBM decided to hide that behind a paywall.
>
> This has always seemed to me like a colossal marketing failure. There is
> just no better showcase for IBM's technical chops than this publication.
>
> -- Jerry
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

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

[Seymour J Metz]

What is he smoking? Since when was the 1401 a mainframe?


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


From: IBM Mainframe Discussion List  on behalf of 
Mark Regan 
Sent: Wednesday, December 26, 2018 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How about a little Christmas fudge? | Computerworld Shark tank

https://secure-web.cisco.com/1iMlW_GZ2Scqioa5F4rqymcywO0OTBLBFOtYPuQZZF6F73Kv0x_B9nU3SOTiheXf32DsESHEBSvbzXuJ78Z2XaRKtXr7A2GITbjxnEDGjBqcDiOzF9WOIQCYJIH89nABmY7xso9DckpD3Q10YPvrxhvPVeFvR6IYMhBl0Po4k4-03fXnkJSammKYm3lrjMJyX4f-lcp9YlEt59dyzYTF_at6wT-i9VPdyfHx5DVlOyFFEzAQxZe-ifUcS7uOAE70lUB6w6ZfwDLRp9vhqQVEaCVSjXFSY0F4a2YhM92FII0XRqIAu4y7yW4Iop4TXQVM-iMQuqleDME3jgueepL3jXWQ797SaO4hRpNph47Gl9FOTKIqwIXeAe2DNqPGTQMlRexhctM6zHXZYT2EbywHPaw/https%3A%2F%2Fwww.computerworld.com%2Farticle%2F3330396%2Fapplication-development%2Fsituation-normal-all-fudged-up.html

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

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

Programs in the PPT on z/OS 2.2

[Peter Ten Eyck]

How does a program get added to the PPT?

For example in SYS1.PARMLIB(SCHED**) has numerous programs are added to the PPT 
at say IPL time, but the console command D PPT display many more? Is there a 
default table of PPT programs? Other than looking at a SCHED** member, how 
would I determine which programs are in the PPT via a SCHED** member and which 
are in the PPT through some other means?

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

Re: Adding 90 seconds to 8 byte TOD FIELD

[Dan D]

&SecsIn1Day SETA 24*60*60
&SecsIn1Hr  SETA 60*60
&SecsIn1Min SETA 1*60
ONEDAY  DC   FDS12'&SecsIn1Day.E6'
ONEHOUR DC   FDS12'&SecsIn1Hr.E6'
ONEMINUTE   DC   FDS12'&SecsIn1Min.E6'

or just simply:

NINTYSECS   DC   FDS12'90E6'

...

Thanks Ed.

I've just never seen that before.  Very useful.

Dan

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

Re: Enforcing CLASS in instream proc

[Dan D]

Yes, ThruPut Manager (owned by Compuware Corp.) is available.

In JAL you can identify the PROCs being executed and where they came from.  You 
can also identify the input class and then direct the job to execute on 
whatever LPAR you choose.

That's one of the very many things that can be done with TM...check it out at 
the Compuware site.

Dan

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

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

[Paul Gilmartin]

On Wed, 26 Dec 2018 09:00:47 -0500, Peter Relson wrote:
>
>>I believe a programmer might reasonably expect that STCKCONV usefully return
>>whatever TIME would have returned at the instant of the STCK.
>
>A programmer would expect next to nothing due to the name of a service 
>since it is not possible to define much in the way of expectations with only 8 
>bytes of name.
>A programmer would read the description to understand what a service does.
> 
From: IBM MVS Programming: Assembler Services Reference, Volume 2 (IAR-XCT)
Version 2 Release 3  SA23-1370-30
Chapter 107. TIME — Obtain time and date:
...
You can use the STCKCONV and CONVTOD macros to convert between
TOD-clock format and various time of day and date formats. The STCKCONV
macro converts a TOD-clock value to a time of day and date value and the
CONVTOD macro converts a time of day and date value to a TOD clock value.
...
OK.  You're correct in your pedantry; it does not assert that the time output by
these services corresponds to the input values -- it guarantees only the format.
I still feel that statements such as this entice a programmer to that misbelief.

Would you be willing to see added to this description a caution such as:
Note: if the (E)TOD clock is set according to IBM's recommendation,
the times output by STCKCONV and CONVTOD do not match the input
values, but may differ according to the content of various common
control blocks.
?

What was the objective of providing these two services?  Did they address
a User Requirement?  Did they meet that requirement?  They give correct
results only for dates before 1972, and I see little value in that.

>A programmer would wonder when they might want to use TIME and when they 
>might want to use STCKCONV, and base their decision on the service 
>definitions.
>The difference is between "what date/time is it" and "what is the 
>date/time that a STCK value architecturally is" (which, ignoring bits 
>52-63, is the number of microseconds since the start of the standard 
>epoch). 
>
An alternative statement might be:
If the (E)TOD clock is set according to IBM's recommendation, and the
input to STCKCONV is the result of STCK, the output of STCKCONV will
be TAI minus 10 seconds.  Conversely, if the input to TODCONV is
a TAI value minus 10 seconds, the output will be the corresponding
(E)TOD value.

OK.  You're right that the programmer is free to choose any epoch/origin.
Yet it would be a courtesy to state, if only as an example, what the
programmer can expect when choosing the origin recommended by IBM.

-- gil

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

Re: Adding 90 seconds to 8 byte TOD FIELD

[Ed Jaffe]

On 12/26/2018 9:47 AM, Dan D wrote:

I don't recall which IBM manual I found these values in but they certainly make 
this type of calculation easier.

*TOD Values
  CNOP  0,8
ONEDAY   DCX'000141DD7600'
ONEHOUR  DCX'0D693A40'
ONEMINUTE DC   X'00393870'
ONESECOND DC   X'F424'
ONEMILISEC DC  X'003E8000'
ONEMICROSEC DC X'1000'

With the above, take ONESECOND and multiply by 90 and add to TOD.
LG/ALG make 8 byte calculations so much easier ;-)


I still don't understand why anyone would opt for hard-coded values from 
a book and/or perform calculations at run time to determine constant 
values when the assembler will do it all for you. Example:


&SecsIn1Day SETA 24*60*60
&SecsIn1Hr  SETA 60*60
&SecsIn1Min SETA 1*60
ONEDAY  DC   FDS12'&SecsIn1Day.E6'
ONEHOUR DC   FDS12'&SecsIn1Hr.E6'
ONEMINUTE   DC   FDS12'&SecsIn1Min.E6'

or just simply:

NINTYSECS   DC   FDS12'90E6'

etc...

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



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

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

Re: Assigning a Data Class to HSM BACKUP files

[Dan D]

I agree, the SMS routines could easily be used, but why? 
Other than the volume count I don't know what you would want to change.

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

Re: Adding 90 seconds to 8 byte TOD FIELD

[Joseph Reichman]

Hi

Just ran the code under TESTAUTH 

I made a breakpoint at the BASR and did a L 1R??  L (8) XC it pointed to
00895440 which 90 * f424 WHAT Dan Dalby posted to be a second

After the BASR I got a  IKJ56640I SYSTEM ABEND CODE D23   REASON CODE
FF050064 looking into it

Thanks

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
retired mainframer
Sent: Wednesday, December 26, 2018 10:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding 90 seconds to 8 byte TOD FIELD

Look at the assembled contents of your address literal.  The * does not
refer to the location of the LA instruction but the address of the literal
itself.

Are you sure that your DC did not skip some bytes to force doubleword
alignment?  If it did, your B instruction points to the wrong place.   If it
didn't skip for this run, are you sure it won't the next time you make a
change.

What is your aversion to using labels?

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Joseph Reichman
> Sent: Wednesday, December 26, 2018 5:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding 90 seconds to 8 byte TOD FIELD
> 
> Thanks
> 
> I changed that however doesn't seem like I am getting out of the wait 
> as I put a WTO after the code and IT didn't execute
> 
> Thanks
> 
> WAIT  ANOP
> L R15,CVTPTR
> USING CVT,R15 GET CVT ADDRESS
> L R15,CVTECVT
> DROP  R15
> USING ECVT,R15   GET ECVT ADDRESS
> L R15,ECVTXTSW X'384'(R15)  GET
> ECVTXTSW ADDRESS
> LAR1,=A(*+10)  PARAMTER LIST
> BASR  R14,R15  GO THERE
> B *+12
> DCFDS12'90E6'  90 SECOND WAIT
> LM15,2,SAVER
> 
> 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Peter Relson
> Sent: Wednesday, December 26, 2018 8:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding 90 seconds to 8 byte TOD FIELD
> 
> >LR15,16  GET CVT ADDRESS
> >LR15,X'8C'(R15)  GET ECVT ADDRESS
> >LR15,X'384'(R15)  GET ECVTXTSW ADDRESS
> >LAR1,=A(*+10)  PARAMTER LIST
> 
> Macros such as IHAPSA, CVT, and IHAECVT are provided for a reason -- 
> so
that
> you don't need to hard-code offsets and in so doing make your code 
> less readable and less maintainable.
> 
> Why do you avoid them?  z/OS macros themselves might hard-code offsets 
> because we don't necessarily want to impose a requirement on the 
> invoker that they include other macros. But if you're writing your own 
> code, you should insist on imposing that requirement on yourself.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu   
> with the
> message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: 64-bit C code fetching IGGCSI00

[Dan D]

Why not just a general LINK31 routine to be called for any program …

 ACONTROL OPTABLE(ZS3)  
 SPLEVEL  SET=6Specify OS/390 R2 MACRO Format   
 SYSSTATE ARCHLVL=2Program Requires Z/Architecture  
 SYSSTATE OSREL=ZOSV1R13   Program Requires Z/OS 1.13 & Higher  

LINK31   CSECT ,
LINK31   AMODE 31   
LINK31   RMODE ANY  
 BAKR  R14,0
 LRR4,R0   Copy Parameter List Address  
 LRR5,R1   Copy Program Name Address
 LARL  R12,LINK31  Set Base Address 
 USING LINK31,R12   
 SAM31 ,
 STORAGE OBTAIN,LENGTH=WRKLEN,LOC=ANY   
 LRR13,R1   
 USING WRKAREA,R13  

 LRR1,R4   Restore Parameter Address
 LINK  EPLOC=(R5)  Call Requested Program   
 LRR4,R0   Copy Reason Code 
 LRR5,R15  Copy Return Code 

 STORAGE RELEASE,LENGTH=WRKLEN,ADDR=(R13)   

 LRR0,R4   Restore Reason Code  
 LRR15,R5  Restore Return Code  
 PR,   Return To Caller 

 LTORG ,

WRKAREA  DSECT ,
 DS18F  

WRKLEN   EQU   *-WRKAREA

 YREGS ,
 END   ,

Then pass parms in R0 and the program name in R1.
Could be used for IGGCSI00 or any other program when in 64 bit mode.

Dan

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

Re: Adding 90 seconds to 8 byte TOD FIELD

[Dan D]

I don't recall which IBM manual I found these values in but they certainly make 
this type of calculation easier.

*TOD Values 
 CNOP  0,8  
ONEDAY   DCX'000141DD7600'
ONEHOUR  DCX'0D693A40'
ONEMINUTE DC   X'00393870'
ONESECOND DC   X'F424'
ONEMILISEC DC  X'003E8000'
ONEMICROSEC DC X'1000'

With the above, take ONESECOND and multiply by 90 and add to TOD.
LG/ALG make 8 byte calculations so much easier ;-)

LG  R1,ONESECOND
MSGF R1,=F'90'
ALGR1,STCKTIME

Dan
 

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

Re: Adding 90 seconds to 8 byte TOD FIELD

[Joseph Reichman]

=A(*+10) refers to the  address of the 8 byte field loading  that address
(address of adcon ltorg) is what I think I should be doing

  R1 -> A(of timer field)

Here is the doc

2-14 will be preserved. - On
entry R1 should contain the
address of a standard parameter
list. The parameter list
consists of a fullword that is
the "address"  of an 8-byte area
that contains the wait time in
TOD clock format. -
  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
retired mainframer
Sent: Wednesday, December 26, 2018 10:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding 90 seconds to 8 byte TOD FIELD

Look at the assembled contents of your address literal.  The * does not
refer to the location of the LA instruction but the address of the literal
itself.

Are you sure that your DC did not skip some bytes to force doubleword
alignment?  If it did, your B instruction points to the wrong place.   If it
didn't skip for this run, are you sure it won't the next time you make a
change.

What is your aversion to using labels?

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Joseph Reichman
> Sent: Wednesday, December 26, 2018 5:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding 90 seconds to 8 byte TOD FIELD
> 
> Thanks
> 
> I changed that however doesn't seem like I am getting out of the wait 
> as I put a WTO after the code and IT didn't execute
> 
> Thanks
> 
> WAIT  ANOP
> L R15,CVTPTR
> USING CVT,R15 GET CVT ADDRESS
> L R15,CVTECVT
> DROP  R15
> USING ECVT,R15   GET ECVT ADDRESS
> L R15,ECVTXTSW X'384'(R15)  GET
> ECVTXTSW ADDRESS
> LAR1,=A(*+10)  PARAMTER LIST
> BASR  R14,R15  GO THERE
> B *+12
> DCFDS12'90E6'  90 SECOND WAIT
> LM15,2,SAVER
> 
> 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Peter Relson
> Sent: Wednesday, December 26, 2018 8:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding 90 seconds to 8 byte TOD FIELD
> 
> >LR15,16  GET CVT ADDRESS
> >LR15,X'8C'(R15)  GET ECVT ADDRESS
> >LR15,X'384'(R15)  GET ECVTXTSW ADDRESS
> >LAR1,=A(*+10)  PARAMTER LIST
> 
> Macros such as IHAPSA, CVT, and IHAECVT are provided for a reason -- 
> so
that
> you don't need to hard-code offsets and in so doing make your code 
> less readable and less maintainable.
> 
> Why do you avoid them?  z/OS macros themselves might hard-code offsets 
> because we don't necessarily want to impose a requirement on the 
> invoker that they include other macros. But if you're writing your own 
> code, you should insist on imposing that requirement on yourself.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu   
> with the
> message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Adding 90 seconds to 8 byte TOD FIELD

[retired mainframer]

Look at the assembled contents of your address literal.  The * does not
refer to the location of the LA instruction but the address of the literal
itself.

Are you sure that your DC did not skip some bytes to force doubleword
alignment?  If it did, your B instruction points to the wrong place.   If it
didn't skip for this run, are you sure it won't the next time you make a
change.

What is your aversion to using labels?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Joseph Reichman
> Sent: Wednesday, December 26, 2018 5:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding 90 seconds to 8 byte TOD FIELD
> 
> Thanks
> 
> I changed that however doesn't seem like I am getting out of the wait as I
> put a WTO after the code and IT didn't execute
> 
> Thanks
> 
> WAIT  ANOP
> L R15,CVTPTR
> USING CVT,R15 GET CVT ADDRESS
> L R15,CVTECVT
> DROP  R15
> USING ECVT,R15   GET ECVT ADDRESS
> L R15,ECVTXTSW X'384'(R15)  GET
> ECVTXTSW ADDRESS
> LAR1,=A(*+10)  PARAMTER LIST
> BASR  R14,R15  GO THERE
> B *+12
> DCFDS12'90E6'  90 SECOND WAIT
> LM15,2,SAVER
> 
> 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of
> Peter Relson
> Sent: Wednesday, December 26, 2018 8:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Adding 90 seconds to 8 byte TOD FIELD
> 
> >LR15,16  GET CVT ADDRESS
> >LR15,X'8C'(R15)  GET ECVT ADDRESS
> >LR15,X'384'(R15)  GET ECVTXTSW ADDRESS
> >LAR1,=A(*+10)  PARAMTER LIST
> 
> Macros such as IHAPSA, CVT, and IHAECVT are provided for a reason -- so
that
> you don't need to hard-code offsets and in so doing make your code less
> readable and less maintainable.
> 
> Why do you avoid them?  z/OS macros themselves might hard-code offsets
> because we don't necessarily want to impose a requirement on the invoker
> that they include other macros. But if you're writing your own code, you
> should insist on imposing that requirement on yourself.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu   with the
> message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: IRXANCHR REXX environment value recommendation

[Richards, Robert B.]

Steve,

Your setting is the highest from the responses that I have received. I am 
probably split the difference and set it to 2000.

Bob 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Horein
Sent: Friday, December 21, 2018 5:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRXANCHR REXX environment value recommendation

Late to the party -
I haven't looked at, or thought about it for some time, but I've considered
creating a NetView specific LMOD thrown into NetView's STEPLIB to not
impose a NetView requirement on the rest of the environment.
2816 was set some years ago when moving to NetView 6.x.

On Fri, Nov 30, 2018 at 1:08 PM Cieri, Anthony  wrote:

> Since I did not notice any responses, I thought I would offer my 2
> cents.
>
> We are NOT running z/OS 2.3 yet, but I did have the need to
> increase this value a few years ago. The need was predicated on the
> installation of Tivoli System Automation (TSA). TSA is based upon Netview,
> which make great use of Rexx. I believe that the limit of anchor CBs is at
> the address space level and we only ever noticed a problem in TSA.
>
>  Our current value is 800 (post TSA) and we generally run at about
> 400 control black in use.
>
> Hth
> Tony
> .
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Richards, Robert B.
> Sent: Tuesday, November 20, 2018 1:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IRXANCHR REXX environment value recommendation
>
> Anyone have a good recommendation for the value of IRXANCHR on a z/OS 2.3
> system?
>
> Current value is 1000, but there may be the need for more REXX
> environments as this value has not been increased in awhile.
>
> What's the new "happy value" everyone is using?  :)
>
> There is no bad answer here.
>
> Bob
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

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

[Peter Relson]

>What date and time in 1900, and what time scale?  GMT? UTC? UT1? 
Ephemeris tme?
>Terrestrial dynamic time? ...?

Surely you know that the principles of operation documents that a clock 
value of 0 is January 1, 1900 12:00 AM UTC (although I believe UTC did not 
exist as a term when this was defined; it was presumably GMT at that 
time), or the start of any subsequent epoch.


>I believe a programmer might reasonably expect that STCKCONV usefully 
return
>whatever TIME would have returned at the instant of the STCK.

A programmer would expect next to nothing due to the name of a service 
since it is not possible to define much in the way of expectations with 
only 8 bytes of name.
A programmer would read the description to understand what a service does.

A programmer would wonder when they might want to use TIME and when they 
might want to use STCKCONV, and base their decision on the service 
definitions.
The difference is between "what date/time is it" and "what is the 
date/time that a STCK value architecturally is" (which, ignoring bits 
52-63, is the number of microseconds since the start of the standard 
epoch). 

Peter Relson
z/OS Core Technology Design


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

Re: Adding 90 seconds to 8 byte TOD FIELD

[Joseph Reichman]

Thanks

I changed that however doesn't seem like I am getting out of the wait as I
put a WTO after the code and IT didn't execute

Thanks

WAIT  ANOP
L R15,CVTPTR
USING CVT,R15 GET CVT ADDRESS
L R15,CVTECVT
DROP  R15
USING ECVT,R15   GET ECVT ADDRESS
L R15,ECVTXTSW X'384'(R15)  GET
ECVTXTSW ADDRESS
LAR1,=A(*+10)  PARAMTER LIST
BASR  R14,R15  GO THERE
B *+12
DCFDS12'90E6'  90 SECOND WAIT
LM15,2,SAVER





-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Peter Relson
Sent: Wednesday, December 26, 2018 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding 90 seconds to 8 byte TOD FIELD

>LR15,16  GET CVT ADDRESS
>LR15,X'8C'(R15)  GET ECVT ADDRESS
>LR15,X'384'(R15)  GET ECVTXTSW ADDRESS
>LAR1,=A(*+10)  PARAMTER LIST

Macros such as IHAPSA, CVT, and IHAECVT are provided for a reason -- so that
you don't need to hard-code offsets and in so doing make your code less
readable and less maintainable.

Why do you avoid them?  z/OS macros themselves might hard-code offsets
because we don't necessarily want to impose a requirement on the invoker
that they include other macros. But if you're writing your own code, you
should insist on imposing that requirement on yourself.

Peter Relson
z/OS Core Technology Design


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

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

How about a little Christmas fudge? | Computerworld Shark tank

[Mark Regan]

https://www.computerworld.com/article/3330396/application-development/situation-normal-all-fudged-up.html

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

Re: Adding 90 seconds to 8 byte TOD FIELD

[Peter Relson]

>LR15,16  GET CVT ADDRESS
>LR15,X'8C'(R15)  GET ECVT ADDRESS
>LR15,X'384'(R15)  GET ECVTXTSW ADDRESS
>LAR1,=A(*+10)  PARAMTER LIST

Macros such as IHAPSA, CVT, and IHAECVT are provided for a reason -- so 
that you don't need to hard-code offsets and in so doing make your code 
less readable and less maintainable.

Why do you avoid them?  z/OS macros themselves might hard-code offsets 
because we don't necessarily want to impose a requirement on the invoker 
that they include other macros. But if you're writing your own code, you 
should insist on imposing that requirement on yourself.

Peter Relson
z/OS Core Technology Design


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