Re: VTS and volume categories (Friday questions)

[Alain Benvéniste]

I don’t know if it answers part of your question, but i have clients who used 
to use categories for production and catégories for DR to be able to write in 
their vts on specific tape ranges. And depending on the licences your vts has, 
you have to consider tape allocation : imagine you want to save your system 
with 256 drives using 25go tapes. The vts needs to allocate all the space in 
parallel. It may accept it or not depending on the number of licences, can’t 
remember which one, you but.

Resiliency Services on Z Mainframe
alain.benveni...@kyndryl.com 

> Le 23 mai 2023 à 04:20, Brian Fraser  a écrit :
> 
> Sorry, I misunderstood the question.
> 
> In IBM's TS7700, you can only select MEDIA1 or MEDIA2 as they only emulate
> 3490 and 3490E. 18-track and 36-track.
> I only use MEDIA2, with dataclas assigning either 6GB or 25GB volume sizes.
> 
> I don't know about other virtual tape systems, which may be able to emulate
> EFMTx formats.
> 
> 
> 
>> On Tue, 23 May 2023 at 05:03, Radoslaw Skorupka <
>> 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> That's good answer to the question not asked.
>> Yes, different categories are good for multi-tenancy, even if it is set
>> of RMM, each having own db.
>> However I'm asking for the reason for having multiple categories
>> logically assigned to single system.
>> I excluded various (virtual) tape capacities since the capacity is now
>> set up by dataclass. So, why should one have more than one scratch
>> category, still assuming there is one z/OS image?
>> 
>> 
>> 
>> --
>> Radoslaw Skorupka
>> Lodz, Poland
>> 
>> 
>> 
>> W dniu 20.05.2023 o 05:20, Brian Fraser pisze:
>>> If different LPARs using the tape library have different TMCs, then they
>>> must also have different category codes assigned so the correct tapes are
>>> used for scratch mounts.
>>> 
>>> 
>>> On Sat, 20 May 2023 at 02:43, Radoslaw Skorupka <
>>> 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
 Volume categories (0001, 0002, and so on) are useful for library
 partitioning. Each SMS-plex can use it's own set of categories (00x1,
 00x2...).
 Categorie are good to request big tape of small tape (JA, JK) or newer
 or older (JB, JC...).
 However the last sentence was good for real tapes.
 In VTS world we have virtual tapes and the max. volume size is
 determined in DATA CLASS construct - so one can have several sizes
 within category.
 
 So, the question arises: what is a purpose to have multiple categories
 for one SMS-plex? Of course, there is no obligation to more than one
 scratch category, however what goal can be achieved by using more than
>> one?
 I see the only one: different scratch Expiration settings.
 
 BTW: all the volumes and drives are emulated, but... are there any
 architectural limits (i.e. volume size) resulting from choice o CAT 00x1
 aka MEDIA1 vs 00x2, etc. ?
 
 Rather obvious, but I want to ask: is there any reason to define more
 categories, that means for MEDIA3 and above?
 In real tape world 3490E drive was completely incompatible with MEDIA3,
 4, etc.
 And the VTS allows to insert only CST (MEDIA1) and ECCST (MEDIA2)
 virtual volumes.
 
 --
 Radoslaw Skorupka
 Lodz, Poland
 
>> 
>> --
>> 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: VTS and volume categories (Friday questions)

[Brian Fraser]

Sorry, I misunderstood the question.

In IBM's TS7700, you can only select MEDIA1 or MEDIA2 as they only emulate
3490 and 3490E. 18-track and 36-track.
I only use MEDIA2, with dataclas assigning either 6GB or 25GB volume sizes.

I don't know about other virtual tape systems, which may be able to emulate
EFMTx formats.



On Tue, 23 May 2023 at 05:03, Radoslaw Skorupka <
0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:

> That's good answer to the question not asked.
> Yes, different categories are good for multi-tenancy, even if it is set
> of RMM, each having own db.
> However I'm asking for the reason for having multiple categories
> logically assigned to single system.
> I excluded various (virtual) tape capacities since the capacity is now
> set up by dataclass. So, why should one have more than one scratch
> category, still assuming there is one z/OS image?
>
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
> W dniu 20.05.2023 o 05:20, Brian Fraser pisze:
> > If different LPARs using the tape library have different TMCs, then they
> > must also have different category codes assigned so the correct tapes are
> > used for scratch mounts.
> >
> >
> > On Sat, 20 May 2023 at 02:43, Radoslaw Skorupka <
> > 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Volume categories (0001, 0002, and so on) are useful for library
> >> partitioning. Each SMS-plex can use it's own set of categories (00x1,
> >> 00x2...).
> >> Categorie are good to request big tape of small tape (JA, JK) or newer
> >> or older (JB, JC...).
> >> However the last sentence was good for real tapes.
> >> In VTS world we have virtual tapes and the max. volume size is
> >> determined in DATA CLASS construct - so one can have several sizes
> >> within category.
> >>
> >> So, the question arises: what is a purpose to have multiple categories
> >> for one SMS-plex? Of course, there is no obligation to more than one
> >> scratch category, however what goal can be achieved by using more than
> one?
> >> I see the only one: different scratch Expiration settings.
> >>
> >> BTW: all the volumes and drives are emulated, but... are there any
> >> architectural limits (i.e. volume size) resulting from choice o CAT 00x1
> >> aka MEDIA1 vs 00x2, etc. ?
> >>
> >> Rather obvious, but I want to ask: is there any reason to define more
> >> categories, that means for MEDIA3 and above?
> >> In real tape world 3490E drive was completely incompatible with MEDIA3,
> >> 4, etc.
> >> And the VTS allows to insert only CST (MEDIA1) and ECCST (MEDIA2)
> >> virtual volumes.
> >>
> >> --
> >> Radoslaw Skorupka
> >> Lodz, Poland
> >>
>
> --
> 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: VTS and volume categories (Friday questions)

[Radoslaw Skorupka]

That's good answer to the question not asked.
Yes, different categories are good for multi-tenancy, even if it is set 
of RMM, each having own db.
However I'm asking for the reason for having multiple categories 
logically assigned to single system.
I excluded various (virtual) tape capacities since the capacity is now  
set up by dataclass. So, why should one have more than one scratch 
category, still assuming there is one z/OS image?




--
Radoslaw Skorupka
Lodz, Poland



W dniu 20.05.2023 o 05:20, Brian Fraser pisze:

If different LPARs using the tape library have different TMCs, then they
must also have different category codes assigned so the correct tapes are
used for scratch mounts.


On Sat, 20 May 2023 at 02:43, Radoslaw Skorupka <
0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:


Volume categories (0001, 0002, and so on) are useful for library
partitioning. Each SMS-plex can use it's own set of categories (00x1,
00x2...).
Categorie are good to request big tape of small tape (JA, JK) or newer
or older (JB, JC...).
However the last sentence was good for real tapes.
In VTS world we have virtual tapes and the max. volume size is
determined in DATA CLASS construct - so one can have several sizes
within category.

So, the question arises: what is a purpose to have multiple categories
for one SMS-plex? Of course, there is no obligation to more than one
scratch category, however what goal can be achieved by using more than one?
I see the only one: different scratch Expiration settings.

BTW: all the volumes and drives are emulated, but... are there any
architectural limits (i.e. volume size) resulting from choice o CAT 00x1
aka MEDIA1 vs 00x2, etc. ?

Rather obvious, but I want to ask: is there any reason to define more
categories, that means for MEDIA3 and above?
In real tape world 3490E drive was completely incompatible with MEDIA3,
4, etc.
And the VTS allows to insert only CST (MEDIA1) and ECCST (MEDIA2)
virtual volumes.

--
Radoslaw Skorupka
Lodz, Poland



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

Re: VTS and volume categories (Friday questions)

[Brian Fraser]

If different LPARs using the tape library have different TMCs, then they
must also have different category codes assigned so the correct tapes are
used for scratch mounts.


On Sat, 20 May 2023 at 02:43, Radoslaw Skorupka <
0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:

> Volume categories (0001, 0002, and so on) are useful for library
> partitioning. Each SMS-plex can use it's own set of categories (00x1,
> 00x2...).
> Categorie are good to request big tape of small tape (JA, JK) or newer
> or older (JB, JC...).
> However the last sentence was good for real tapes.
> In VTS world we have virtual tapes and the max. volume size is
> determined in DATA CLASS construct - so one can have several sizes
> within category.
>
> So, the question arises: what is a purpose to have multiple categories
> for one SMS-plex? Of course, there is no obligation to more than one
> scratch category, however what goal can be achieved by using more than one?
> I see the only one: different scratch Expiration settings.
>
> BTW: all the volumes and drives are emulated, but... are there any
> architectural limits (i.e. volume size) resulting from choice o CAT 00x1
> aka MEDIA1 vs 00x2, etc. ?
>
> Rather obvious, but I want to ask: is there any reason to define more
> categories, that means for MEDIA3 and above?
> In real tape world 3490E drive was completely incompatible with MEDIA3,
> 4, etc.
> And the VTS allows to insert only CST (MEDIA1) and ECCST (MEDIA2)
> virtual volumes.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> 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

VTS and volume categories (Friday questions)

[Radoslaw Skorupka]

Volume categories (0001, 0002, and so on) are useful for library 
partitioning. Each SMS-plex can use it's own set of categories (00x1, 
00x2...).
Categorie are good to request big tape of small tape (JA, JK) or newer 
or older (JB, JC...).

However the last sentence was good for real tapes.
In VTS world we have virtual tapes and the max. volume size is 
determined in DATA CLASS construct - so one can have several sizes 
within category.


So, the question arises: what is a purpose to have multiple categories 
for one SMS-plex? Of course, there is no obligation to more than one 
scratch category, however what goal can be achieved by using more than one?

I see the only one: different scratch Expiration settings.

BTW: all the volumes and drives are emulated, but... are there any 
architectural limits (i.e. volume size) resulting from choice o CAT 00x1 
aka MEDIA1 vs 00x2, etc. ?


Rather obvious, but I want to ask: is there any reason to define more 
categories, that means for MEDIA3 and above?
In real tape world 3490E drive was completely incompatible with MEDIA3, 
4, etc.
And the VTS allows to insert only CST (MEDIA1) and ECCST (MEDIA2) 
virtual volumes.


--
Radoslaw Skorupka
Lodz, Poland

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

Re: One for Gil on Friday...

[Gord Tomlin]

On 2023-04-14 13:56 PM, Paul Gilmartin wrote:

enhances "-" character


It's amazing that they have found a way to enhance a character. ;)

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: One for Gil on Friday...

[Paul Gilmartin]

On Fri, 14 Apr 2023 11:59:28 -0400, Tony Harminc wrote:

>I got a notification that New Function APAR /OA64061 has closed.
>https://www.ibm.com/support/pages/apar/OA64061
>
Thanks.   OS Release?  Availability date?  Documentation?

>The date command enhances -d option to displays the operating
>system's concept of the specified date and time.
>
???

>The find command enhances -print0 option to displays displays
>the current file name, followed by a null character.
>
"to displays displays?"?

This not an "enhancement".  Something that didn't exist previously can't be 
enhanced.

English not they first language?

"It's about time!™"  This is precious on Linux, Solaris, MacOS, ...
However, ir's of little use without "xargs -0", and can be synthesized
(at considerable performance cost) as "find ... -exec printf '%s\n' {} \;".
There's no such alternative for "xargs -0".

What about "find ... [-iname|-ls]"

>The cat command enhances a clear error message when accessing
>a RACF protected MVS data set.
>
>The ps command enhances "-" character to handle the
>address column collapsing issue.
>
>What a hodgepodge of ad-hoc little changes ("fixes"? "new function"?).

Some administrators would prefer four independent PTFs.

-- 
gil

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

One for Gil on Friday...

[Tony Harminc]

I got a notification that New Function APAR /OA64061 has closed.
https://www.ibm.com/support/pages/apar/OA64061

The description:

* USERS AFFECTED: z/OS users of the date, find, cat, ps*
* command. *

* PROBLEM DESCRIPTION: Provides enhancement of the date, find, *
*  cat, ps command *
*  to record logs. *

The date command enhances -d option to displays the operating
system's concept of the specified date and time.

The find command enhances -print0 option to displays displays
the current file name, followed by a null character.

The cat command enhances a clear error message when accessing
a RACF protected MVS data set.

The ps command enhances "-" character to handle the
address column collapsing issue.

What a hodgepodge of ad-hoc little changes ("fixes"? "new function"?).

Tony H.

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

Re: And it's not even Friday

[Phil Smith III]

Robert Prins wrote:

>https://ibmmainframes.com/viewtopic.php?t=68675

 

That's pretty good. I'm'a try it on a few of my younger colleagues, see if
they get it-betting they don't.


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

And it's not even Friday

[Robert Prins]

https://ibmmainframes.com/viewtopic.php?t=68675

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Seymour J Metz]

I would describe that as a failure of the panel; ALLOCATE is correctly 
processing the input it receives. How about an RFE for all panels that 
uppercase their command line to include an annotation that they do so or to 
display the translated input.

As for concatenating classical datasets with Unix paths, that is but one 
example of many where the corpse of orthogonality lies bleeding on the ground. 
Nor is IBM the only poster child for that.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, May 24, 2020 11:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

On Sun, 24 May 2020 18:26:13 -0700, Charles Mills wrote:
>...
>+1 (What the H*** is gained by uppercasing a CART where the underlying
>service supports any 64-bit value? Don't over validate! This is the problem
>with various utilities that could handle UNIX files except that the utility
>"validates" the filename and rejects slashes or lowercase letters.)
>
Most conspicuous to me is the failure of "TSO ALLOCATE PATH('/dev/null')"
on various ISPF panel command lines.

And semantic more than semantic, the failure of SYSEXEC or
AMATERSE UNPACK SYSUT1 when allocated to UNIX directories
or files.  It seems to be a gratuitous check on DSORG which can
be circumvented by pre-concatenating an empty Classic DSN.

-- gil

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

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Paul Gilmartin]

On Sun, 24 May 2020 18:26:13 -0700, Charles Mills wrote:
>...
>+1 (What the H*** is gained by uppercasing a CART where the underlying
>service supports any 64-bit value? Don't over validate! This is the problem
>with various utilities that could handle UNIX files except that the utility
>"validates" the filename and rejects slashes or lowercase letters.)
> 
Most conspicuous to me is the failure of "TSO ALLOCATE PATH('/dev/null')"
on various ISPF panel command lines.

And semantic more than semantic, the failure of SYSEXEC or
AMATERSE UNPACK SYSUT1 when allocated to UNIX directories
or files.  It seems to be a gratuitous check on DSORG which can
be circumvented by pre-concatenating an empty Classic DSN.

-- gil

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Seymour J Metz]

> +1 (What the H*** is gained by uppercasing a CART where the underlying
> service supports any 64-bit value?

Inertia? Blind adherence to poorly understood specifications. There are lots of 
pathlogies in large organizations that could explain it. Report it, and if it 
comes back BAD then submit an RFE. There is nothing in TSO that either requires 
the misbehavior or that requires the documentation of the misbehavior to be 
camouflaged.

I've already submitted an RFC, but IMHO it's the code that should be changed.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Sunday, May 24, 2020 9:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

+1 (SUBMIT)
+1 (Doc)
+1 (What the H*** is gained by uppercasing a CART where the underlying
service supports any 64-bit value? Don't over validate! This is the problem
with various utilities that could handle UNIX files except that the utility
"validates" the filename and rejects slashes or lowercase letters.)

I've done my part on various RCF's but not so far on this one.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Sunday, May 24, 2020 5:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Never mind case; when will SUBMIT recognize that 80 is not the only integer?

Also, when TSO (sub)commands upper case their input, the documentation
should say so in an obvious location as part of the (sub)command
description.

Finally, when a TSO (sub)command provides the facilities of a documented
subroutine or assembler macro, it should not impose additional syntactic
constraints or transformations beyond those documented for the underlying
services.

OTOH, people should RTFM and submit an RCF if they find TFM to be deficient.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, May 24, 2020 7:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

On Sun, 24 May 2020 14:26:51 -0700, Charles Mills wrote:
>
>'MyCart01' (as written, in camel-case) was my intended CART and it is a
valid CART: a CART may have any 64-bit value. The problem was that the
CONSOLE command uppercased it to MYCART01. Yes, had I written my Rexx in
such a way as to uppercase it the problem would have disappeared, but two
wrongs don't make a right.
>
It's far overdue that interfaces quit forcing the limitations of the
029 keypunch on users.  Decades ago, I learned that if I need
upper case I press the SHIFT key; otherwise I should get what
I type.

It's fine for functions to be case insensitive, case sensitive, or
monocase.  It's wrong for upstream processes to second-guess
-- they're too often wrong.

And it was a design error for Binder to provide a CASE UPPER
option.  CASE MIXED, compatible with Linkage Editor, should
always be in force.

-- gil

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

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

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

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Charles Mills]

Right! Let the service fail and then report its error. Don't introduce some new 
error to document and be learned.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, May 24, 2020 6:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

On Mon, 25 May 2020 00:53:04 +, Seymour J Metz wrote:

>Never mind case; when will SUBMIT recognize that 80 is not the only integer?
>
>Also, when TSO (sub)commands upper case their input, the documentation should 
>say so in an obvious location as part of the (sub)command description.
>
>Finally, when a TSO (sub)command provides the facilities of a documented 
>subroutine or assembler macro, it should not impose additional syntactic 
>constraints or transformations beyond those documented for the underlying 
>services.
>
Further, when a user violates the documented restrictions of
a subroutine or assembler macro (possibly by directly issuing
an SVC), that service should fail and report the error.  I think
of such as trying to STOW "Fred.txt".

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Charles Mills]

+1 (SUBMIT)
+1 (Doc)
+1 (What the H*** is gained by uppercasing a CART where the underlying
service supports any 64-bit value? Don't over validate! This is the problem
with various utilities that could handle UNIX files except that the utility
"validates" the filename and rejects slashes or lowercase letters.)

I've done my part on various RCF's but not so far on this one.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Sunday, May 24, 2020 5:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Never mind case; when will SUBMIT recognize that 80 is not the only integer?

Also, when TSO (sub)commands upper case their input, the documentation
should say so in an obvious location as part of the (sub)command
description.

Finally, when a TSO (sub)command provides the facilities of a documented
subroutine or assembler macro, it should not impose additional syntactic
constraints or transformations beyond those documented for the underlying
services.

OTOH, people should RTFM and submit an RCF if they find TFM to be deficient.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, May 24, 2020 7:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

On Sun, 24 May 2020 14:26:51 -0700, Charles Mills wrote:
>
>'MyCart01' (as written, in camel-case) was my intended CART and it is a
valid CART: a CART may have any 64-bit value. The problem was that the
CONSOLE command uppercased it to MYCART01. Yes, had I written my Rexx in
such a way as to uppercase it the problem would have disappeared, but two
wrongs don't make a right.
>
It's far overdue that interfaces quit forcing the limitations of the
029 keypunch on users.  Decades ago, I learned that if I need
upper case I press the SHIFT key; otherwise I should get what
I type.

It's fine for functions to be case insensitive, case sensitive, or
monocase.  It's wrong for upstream processes to second-guess
-- they're too often wrong.

And it was a design error for Binder to provide a CASE UPPER
option.  CASE MIXED, compatible with Linkage Editor, should
always be in force.

-- gil

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

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

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Paul Gilmartin]

On Mon, 25 May 2020 00:53:04 +, Seymour J Metz wrote:

>Never mind case; when will SUBMIT recognize that 80 is not the only integer?
>
>Also, when TSO (sub)commands upper case their input, the documentation should 
>say so in an obvious location as part of the (sub)command description.
>
>Finally, when a TSO (sub)command provides the facilities of a documented 
>subroutine or assembler macro, it should not impose additional syntactic 
>constraints or transformations beyond those documented for the underlying 
>services.
>
Further, when a user violates the documented restrictions of
a subroutine or assembler macro (possibly by directly issuing
an SVC), that service should fail and report the error.  I think
of such as trying to STOW "Fred.txt".

>OTOH, people should RTFM and submit an RCF if they find TFM to be deficient.

-- gil

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Seymour J Metz]

Never mind case; when will SUBMIT recognize that 80 is not the only integer?

Also, when TSO (sub)commands upper case their input, the documentation should 
say so in an obvious location as part of the (sub)command description.

Finally, when a TSO (sub)command provides the facilities of a documented 
subroutine or assembler macro, it should not impose additional syntactic 
constraints or transformations beyond those documented for the underlying 
services.

OTOH, people should RTFM and submit an RCF if they find TFM to be deficient.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, May 24, 2020 7:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

On Sun, 24 May 2020 14:26:51 -0700, Charles Mills wrote:
>
>'MyCart01' (as written, in camel-case) was my intended CART and it is a valid 
>CART: a CART may have any 64-bit value. The problem was that the CONSOLE 
>command uppercased it to MYCART01. Yes, had I written my Rexx in such a way as 
>to uppercase it the problem would have disappeared, but two wrongs don't make 
>a right.
>
It's far overdue that interfaces quit forcing the limitations of the
029 keypunch on users.  Decades ago, I learned that if I need
upper case I press the SHIFT key; otherwise I should get what
I type.

It's fine for functions to be case insensitive, case sensitive, or
monocase.  It's wrong for upstream processes to second-guess
-- they're too often wrong.

And it was a design error for Binder to provide a CASE UPPER
option.  CASE MIXED, compatible with Linkage Editor, should
always be in force.

-- gil

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

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Paul Gilmartin]

On Sun, 24 May 2020 14:26:51 -0700, Charles Mills wrote:
>
>'MyCart01' (as written, in camel-case) was my intended CART and it is a valid 
>CART: a CART may have any 64-bit value. The problem was that the CONSOLE 
>command uppercased it to MYCART01. Yes, had I written my Rexx in such a way as 
>to uppercase it the problem would have disappeared, but two wrongs don't make 
>a right.
> 
It's far overdue that interfaces quit forcing the limitations of the
029 keypunch on users.  Decades ago, I learned that if I need
upper case I press the SHIFT key; otherwise I should get what
I type.

It's fine for functions to be case insensitive, case sensitive, or
monocase.  It's wrong for upstream processes to second-guess
-- they're too often wrong.

And it was a design error for Binder to provide a CASE UPPER
option.  CASE MIXED, compatible with Linkage Editor, should
always be in force.

-- gil

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Seymour J Metz]

No, the problem is you didn't adhere to the interface, possibly because the 
relevant statement is not (RCF submitted*) in the obvious location. CONSOLE is 
not the only case where you need to know the case behavior of the command. I 
never said that you should uppercase everything, only that you should use the 
*correct* case for the task at hand, and that I've seen a lot of errors 
stemming from the failure to do so.

You are incorrect in your fantasy that you are a telepath. You are imputing to 
me beliefs and impressions that I have never held and claims that I have never 
made. Please rebut claims that people actually made, not claims you invented on 
the spot.

As for the subject line, it's wrongheaded. It's not some abstract TSO in the 
sky that uppercased the CART, it's, e.g., the CONSOLE command, the CART 
subcommand. I've been using TSO commands with mixed case operands since before 
you could spell TSO, and they worked just fine.

* You could try to submit a problem report, but I suspect that it will be 
closed as BAD.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Sunday, May 24, 2020 5:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

The problem was NOT that Rexx (or my coding style) failed to uppercase an 
operand; the problem was that TSO did. Note my subject line: a rant about TSO.

'MyCart01' (as written, in camel-case) was my intended CART and it is a valid 
CART: a CART may have any 64-bit value. The problem was that the CONSOLE 
command uppercased it to MYCART01. Yes, had I written my Rexx in such a way as 
to uppercase it the problem would have disappeared, but two wrongs don't make a 
right.

Had Rexx or my coding style inadvertently uppercased my intended CART it would 
simply have created a false impression of what constitutes a valid CART. Note 
what the first almost correct answerer posted: "Your problem is caused by using 
lower case characters in your CART parameter value, the value of variable 
MyCart. If you used all upper case, or all numerics, it would work fine. That's 
not documented anywhere that I've thus far been able to find."

He is incorrect in his impression of what constitutes a valid CART, and his 
wrong impression of CART validity would be reinforced if Rexx or my coding 
style "corrected" my camel-case CART.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Saturday, May 23, 2020 11:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

> You seem stuck on this capitalization thing.

You seem to forget that this thread started on a capitalization issue. You also 
seem to assume that my alleged fixation affects the way others code. You might 
note that of the three error issues I listed, capitalization was last - why did 
you single it out?

> I’ve never had such a problem,

K3wl. What about code written by others.

--
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: Friday Follies/Why won't this work?/TSO Rant #387

[Charles Mills]

The problem was NOT that Rexx (or my coding style) failed to uppercase an 
operand; the problem was that TSO did. Note my subject line: a rant about TSO.

'MyCart01' (as written, in camel-case) was my intended CART and it is a valid 
CART: a CART may have any 64-bit value. The problem was that the CONSOLE 
command uppercased it to MYCART01. Yes, had I written my Rexx in such a way as 
to uppercase it the problem would have disappeared, but two wrongs don't make a 
right.

Had Rexx or my coding style inadvertently uppercased my intended CART it would 
simply have created a false impression of what constitutes a valid CART. Note 
what the first almost correct answerer posted: "Your problem is caused by using 
lower case characters in your CART parameter value, the value of variable 
MyCart. If you used all upper case, or all numerics, it would work fine. That's 
not documented anywhere that I've thus far been able to find."

He is incorrect in his impression of what constitutes a valid CART, and his 
wrong impression of CART validity would be reinforced if Rexx or my coding 
style "corrected" my camel-case CART.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Saturday, May 23, 2020 11:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

> You seem stuck on this capitalization thing.

You seem to forget that this thread started on a capitalization issue. You also 
seem to assume that my alleged fixation affects the way others code. You might 
note that of the three error issues I listed, capitalization was last - why did 
you single it out?

> I’ve never had such a problem,

K3wl. What about code written by others.

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Seymour J Metz]

> You seem stuck on this capitalization thing.

You seem to forget that this thread started on a capitalization issue. You also 
seem to assume that my alleged fixation affects the way others code. You might 
note that of the three error issues I listed, capitalization was last - why did 
you single it out?

> I’ve never had such a problem,

K3wl. What about code written by others.



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Sunday, May 24, 2020 1:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Metz wrote:

>Well, I've only been using REXX for 35 years. The problems that I have seen 
>from not quoting words have been few and far between, not nearly as many as, 
>e.g., problems related to continuation, omitting a period in a stem, incorrect 
>capitalization in a string literal.



You seem stuck on this capitalization thing. I’ve never had such a problem, 
perhaps because I capitalize literals as needed. I’d never assume that mixed 
case in a literal is OK unless it’s deliberate, no matter the environment. Part 
of my Rexx Programming Style presentation, given at SHARE many times! 😊



I have seen nasty bugs from not quoting literals, not to mention the 
performance hit.


--
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: Friday Follies/Why won't this work?/TSO Rant #387

[Phil Smith III]

Metz wrote:

>Well, I've only been using REXX for 35 years. The problems that I have seen 
>from not quoting words have been few and far between, not nearly as many as, 
>e.g., problems related to continuation, omitting a period in a stem, incorrect 
>capitalization in a string literal.

 

You seem stuck on this capitalization thing. I’ve never had such a problem, 
perhaps because I capitalize literals as needed. I’d never assume that mixed 
case in a literal is OK unless it’s deliberate, no matter the environment. Part 
of my Rexx Programming Style presentation, given at SHARE many times! 😊

 

I have seen nasty bugs from not quoting literals, not to mention the 
performance hit.


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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Seymour J Metz]

Well, I've only been using REXX for 35 years. The problems that I have seen 
from not quoting words have been few and far between, not nearly as many as, 
e.g., problems related to continuation, omitting a period in a stem, incorrect 
capitalization in a string literal.

BTDT,GTS


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Friday, May 22, 2020 8:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Metz wrote:

> Running with signal on novalue and quoting everything leads to hard-to-debug 
> surprises errors when you get the case wrong (present
example is typical.) ;-)



After almost 40 years of writing Rexx, I've never had that problem. Quoting 
literals avoids far more problems than it causes, as
does SIGNAL ON NOVALUE. You want hard-to-debug surprises, try not quoting a 
literal and then having someone define a variable that
happens to match your literal token.



...phsiii


--
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: Friday Follies/Why won't this work?/TSO Rant #387

[scott Ford]

This is great David, thank you kind sir

On Sat, May 23, 2020 at 3:54 AM David Crayford  wrote:

> On 2020-05-23 3:20 AM, scott Ford wrote:
> > I got bit on case and end of line characters using GIT. I was using
> > Notepad++ and had the EOL set incorrectly, duh !
>
>
> Create a .gitattributes file to control line endings
> https://www.edwardthomson.com/blog/git_for_windows_line_endings.html
>
>
> > Scott
> >
> > On Fri, May 22, 2020 at 3:10 PM Seymour J Metz  wrote:
> >
> >> While I started with upper case only languages and progressed to case
> >> independent languages, there is a case for case dependent languages. It
> >> helps if you have a good IDE.
> >>
> >>
> >> --
> >> Shmuel (Seymour J.) Metz
> >> http://mason.gmu.edu/~smetz3
> >>
> >> ____
> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf
> >> of Steve Smith [sasd...@gmail.com]
> >> Sent: Friday, May 22, 2020 3:00 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387
> >>
> >> Case sensitivity is the root of all evil.
> >>
> >> sas
> >>
> >> Disclaimer: The above may contain excessive generalization, hyperbole,
> and
> >> offend your sensibilities.  I'd say I'm sorry, but that would just add
> >> flat-out lying to the mix.
> >>
> >> --
> >> 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
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[David Crayford]

On 2020-05-23 3:20 AM, scott Ford wrote:

I got bit on case and end of line characters using GIT. I was using
Notepad++ and had the EOL set incorrectly, duh !



Create a .gitattributes file to control line endings 
https://www.edwardthomson.com/blog/git_for_windows_line_endings.html




Scott

On Fri, May 22, 2020 at 3:10 PM Seymour J Metz  wrote:


While I started with upper case only languages and progressed to case
independent languages, there is a case for case dependent languages. It
helps if you have a good IDE.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
of Steve Smith [sasd...@gmail.com]
Sent: Friday, May 22, 2020 3:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Case sensitivity is the root of all evil.

sas

Disclaimer: The above may contain excessive generalization, hyperbole, and
offend your sensibilities.  I'd say I'm sorry, but that would just add
flat-out lying to the mix.

--
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: Friday Follies/Why won't this work?/TSO Rant #387

[Wayne Bickerdike]

Slight diversion. A colleague wanted some REXX code so I sent it as an XMIT
file. He was working remotely and said, the RECEIVE fails.

When I next saw him, I went to his desk and watched the RECEIVE command.
Boom, "UNABLE TO ALLOCATE LOG.MISC".

He had TSO PROFILE(NOPREFIX) and didn't have RACF ALTER against LOG prefix.

For years he was wrapping quotes around his dataset names. I mean
everywhere!

On Sat, May 23, 2020 at 10:48 AM Phil Smith III  wrote:

> Metz wrote:
>
> > Running with signal on novalue and quoting everything leads to
> hard-to-debug surprises errors when you get the case wrong (present
> example is typical.) ;-)
>
>
>
> After almost 40 years of writing Rexx, I've never had that problem.
> Quoting literals avoids far more problems than it causes, as
> does SIGNAL ON NOVALUE. You want hard-to-debug surprises, try not quoting
> a literal and then having someone define a variable that
> happens to match your literal token.
>
>
>
> ...phsiii
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Charles Mills]

Have to say that I agree 100% with @Phil (other than that I have only been
coding Rexx for about 25 years).

The other problem with omitting SIGNAL ON NOVALUE is that you can code IF
ARG(1) = FOOO ... and never realize that ARG(1) will never equal FOOO
because the variable is really named FOO, and FOOO will always have a value
of, well, 'FOOO'. The problem is compounded by the fact that Rexx is not
compiled and so references to undefined variables only show up if you
actually execute the code in question, which may not happen in testing. (I
know, everyone on this list tests every code path, but some of our
associates might forget once in a while.)

If you have access to a Rexx compiler I recommend compiling any significant
"production" Rexx code. You don't have to actually run the compiled Rexx --
it's just that the compiler will pick up problems like omitted or misspelled
labels that the interpreter may miss.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Friday, May 22, 2020 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Metz wrote:

> Running with signal on novalue and quoting everything leads to
hard-to-debug surprises errors when you get the case wrong (present
example is typical.) ;-)



After almost 40 years of writing Rexx, I've never had that problem. Quoting
literals avoids far more problems than it causes, as
does SIGNAL ON NOVALUE. You want hard-to-debug surprises, try not quoting a
literal and then having someone define a variable that
happens to match your literal token.

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Phil Smith III]

Metz wrote:

> Running with signal on novalue and quoting everything leads to hard-to-debug 
> surprises errors when you get the case wrong (present
example is typical.) ;-)



After almost 40 years of writing Rexx, I've never had that problem. Quoting 
literals avoids far more problems than it causes, as
does SIGNAL ON NOVALUE. You want hard-to-debug surprises, try not quoting a 
literal and then having someone define a variable that
happens to match your literal token.

 

...phsiii 


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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Seymour J Metz]

Running with signal on novalue and quoting everything leads to hard-to-debug 
surprises errors when you get the case wrong (present example is typical.) ;-)


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Friday, May 22, 2020 4:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

True enough, but in my (actual) Rexx programs I always code Signal On
Novalue. To do otherwise is to invite hard-to-debug surprises (present
example notwithstanding).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Friday, May 22, 2020 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Hence my quote: had he not quoted the value then it would have been a symbol
and REXX would have translated it to upper case.

--
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: Friday Follies/Why won't this work?/TSO Rant #387

[Charles Mills]

True enough, but in my (actual) Rexx programs I always code Signal On
Novalue. To do otherwise is to invite hard-to-debug surprises (present
example notwithstanding).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Friday, May 22, 2020 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Hence my quote: had he not quoted the value then it would have been a symbol
and REXX would have translated it to upper case.

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Seymour J Metz]

Hence my quote: had he not quoted the value then it would have been a symbol 
and REXX would have translated it to upper case.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Garrett [rob...@garrettfamily.us]
Sent: Friday, May 22, 2020 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Your problem is caused by using lower case characters in your CART parameter 
value, the value of variable MyCart.   If you used all upper case, or all 
numerics, it would work fine.
That's not documented anywhere that I've thus far been able to find.

Cheers,
Robert

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, May 22, 2020 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387


 I called my congressman and he said quote
 I'd like to help you son, but you're too young to vote.



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Friday, May 22, 2020 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Friday Follies/Why won't this work?/TSO Rant #387

What is wrong with this Rexx? (I spent about two hours debugging before I 
solved it.) The problem is right here on this page: the answer is NOT something 
in RACF or JES2. It's not something missing: it's a sin of commission, not a 
sin of omission. The below will never work. That is, the output will always be 
RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?

/* Rexx to test command/response */
MyCart = "MyCart01"
"CONSPROF SOLDISP(NO) SOLNUM(400)"
"CONSOLE ACTIVATE"
Address Console
"CART" MyCart
"$DQ"
RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1 "CONSOLE DEACTIVATE"

Charles

--
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: Friday Follies/Why won't this work?/TSO Rant #387

[scott Ford]

I got bit on case and end of line characters using GIT. I was using
Notepad++ and had the EOL set incorrectly, duh !

Scott

On Fri, May 22, 2020 at 3:10 PM Seymour J Metz  wrote:

> While I started with upper case only languages and progressed to case
> independent languages, there is a case for case dependent languages. It
> helps if you have a good IDE.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Steve Smith [sasd...@gmail.com]
> Sent: Friday, May 22, 2020 3:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387
>
> Case sensitivity is the root of all evil.
>
> sas
>
> Disclaimer: The above may contain excessive generalization, hyperbole, and
> offend your sensibilities.  I'd say I'm sorry, but that would just add
> flat-out lying to the mix.
>
> --
> 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
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Seymour J Metz]

While I started with upper case only languages and progressed to case 
independent languages, there is a case for case dependent languages. It helps 
if you have a good IDE.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Smith [sasd...@gmail.com]
Sent: Friday, May 22, 2020 3:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Case sensitivity is the root of all evil.

sas

Disclaimer: The above may contain excessive generalization, hyperbole, and
offend your sensibilities.  I'd say I'm sorry, but that would just add
flat-out lying to the mix.

--
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: Friday Follies/Why won't this work?/TSO Rant #387

[Seymour J Metz]

Not quite. Every TSO command parses its own operands, normally by calling 
IKJPARSE. If the operand description specifies ASIS the PARSE does not 
translate the operand to upper case. Ideally the command description would 
specify whether the operand is case dependent, but we don't live in an ideal 
world.

As I hinted in my  quote, this will work and will have the bonus of 
irritating Gil:

 MyCart = MyCart01

if you leave MyCart01 unquoted in the GETMSG().

The general rule is that the REXX variable pool can have lower case names but 
you have to use the value() function to access them; REXX normally translates 
names to upper case.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Friday, May 22, 2020 1:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

We have a winner! You've got it about 90%.

The clue is in the subject line -- this is actually a TSO rant.

TSO uppercases commands so "CART" MyCart becomes effectively "CART
MYCART01".

GETMSG is an ordinary Rexx function so parameters are passed "as-is," and RC
= GETMSG('MYMSGS.','SOL',MyCart,,1) becomes effectively
RC = GETMSG('MYMSGS.','SOL','MyCart01',,1).

The two CARTs do not match, and no messages are retrieved.

I think it is *possible* that you could solve the problem by quoting the
CART but I have not tested. Something like "CART" "'"||MyCart||"'" .

Charles


-----Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Robert Garrett
Sent: Friday, May 22, 2020 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Your problem is caused by using lower case characters in your CART parameter
value, the value of variable MyCart.   If you used all upper case, or all
numerics, it would work fine.
That's not documented anywhere that I've thus far been able to find.

Cheers,
Robert

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Friday, May 22, 2020 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387


 I called my congressman and he said quote
 I'd like to help you son, but you're too young to vote.



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Friday, May 22, 2020 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Friday Follies/Why won't this work?/TSO Rant #387

What is wrong with this Rexx? (I spent about two hours debugging before I
solved it.) The problem is right here on this page: the answer is NOT
something in RACF or JES2. It's not something missing: it's a sin of
commission, not a sin of omission. The below will never work. That is, the
output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?

/* Rexx to test command/response */
MyCart = "MyCart01"
"CONSPROF SOLDISP(NO) SOLNUM(400)"
"CONSOLE ACTIVATE"
Address Console
"CART" MyCart
"$DQ"
RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1 "CONSOLE DEACTIVATE"

Charles

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

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

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

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

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Steve Smith]

Case sensitivity is the root of all evil.

sas

Disclaimer: The above may contain excessive generalization, hyperbole, and
offend your sensibilities.  I'd say I'm sorry, but that would just add
flat-out lying to the mix.

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[scott Ford]

Charles,

Just a document rc=4 from Getmsg ,  the getmsg could not match your
criteria , filter ...


Scott

On Fri, May 22, 2020 at 1:58 PM Richards, Robert B. <
01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:

> Snippet:
>
> Cart_V = 'CONS1'random(100,)  /* build CART value
>*/
> pass_arg. = "CONSOLE SYSCMD("con_input") CART("Cart_V")"
> "TSOEXEC CONSPROF SOLDISP(NO) SOLNUM(400)"
>  /*
> activate Console services*/
> "TSOEXEC CONSOLE ACTIVATE NAME("con_name") CART("Cart_V")"
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Charles Mills
> Sent: Friday, May 22, 2020 1:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387
>
> We have a winner! You've got it about 90%.
>
> The clue is in the subject line -- this is actually a TSO rant.
>
> TSO uppercases commands so "CART" MyCart becomes effectively "CART
> MYCART01".
>
> GETMSG is an ordinary Rexx function so parameters are passed "as-is," and
> RC = GETMSG('MYMSGS.','SOL',MyCart,,1) becomes effectively RC =
> GETMSG('MYMSGS.','SOL','MyCart01',,1).
>
> The two CARTs do not match, and no messages are retrieved.
>
> I think it is *possible* that you could solve the problem by quoting the
> CART but I have not tested. Something like "CART" "'"||MyCart||"'" .
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Robert Garrett
> Sent: Friday, May 22, 2020 10:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387
>
> Your problem is caused by using lower case characters in your CART
> parameter
> value, the value of variable MyCart.   If you used all upper case, or all
> numerics, it would work fine.
> That's not documented anywhere that I've thus far been able to find.
>
> Cheers,
> Robert
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Seymour J Metz
> Sent: Friday, May 22, 2020 11:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387
>
> 
>  I called my congressman and he said quote
>  I'd like to help you son, but you're too young to vote.
> 
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Charles Mills [charl...@mcn.org]
> Sent: Friday, May 22, 2020 10:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Friday Follies/Why won't this work?/TSO Rant #387
>
> What is wrong with this Rexx? (I spent about two hours debugging before I
> solved it.) The problem is right here on this page: the answer is NOT
> something in RACF or JES2. It's not something missing: it's a sin of
> commission, not a sin of omission. The below will never work. That is, the
> output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?
>
> /* Rexx to test command/response */
> MyCart = "MyCart01"
> "CONSPROF SOLDISP(NO) SOLNUM(400)"
> "CONSOLE ACTIVATE"
> Address Console
> "CART" MyCart
> "$DQ"
> RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
> Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1 "CONSOLE DEACTIVATE"
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Richards, Robert B.]

Snippet:

Cart_V = 'CONS1'random(100,)  /* build CART value 
*/  
pass_arg. = "CONSOLE SYSCMD("con_input") CART("Cart_V")" 
"TSOEXEC CONSPROF SOLDISP(NO) SOLNUM(400)"   
 /* 
activate Console services*/  
"TSOEXEC CONSOLE ACTIVATE NAME("con_name") CART("Cart_V")"   

-Original Message-----
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, May 22, 2020 1:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

We have a winner! You've got it about 90%.

The clue is in the subject line -- this is actually a TSO rant.

TSO uppercases commands so "CART" MyCart becomes effectively "CART MYCART01".

GETMSG is an ordinary Rexx function so parameters are passed "as-is," and RC = 
GETMSG('MYMSGS.','SOL',MyCart,,1) becomes effectively RC = 
GETMSG('MYMSGS.','SOL','MyCart01',,1).

The two CARTs do not match, and no messages are retrieved.

I think it is *possible* that you could solve the problem by quoting the CART 
but I have not tested. Something like "CART" "'"||MyCart||"'" .

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert Garrett
Sent: Friday, May 22, 2020 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Your problem is caused by using lower case characters in your CART parameter
value, the value of variable MyCart.   If you used all upper case, or all
numerics, it would work fine. 
That's not documented anywhere that I've thus far been able to find.

Cheers,
Robert

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, May 22, 2020 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387


 I called my congressman and he said quote
 I'd like to help you son, but you're too young to vote.



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Friday, May 22, 2020 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Friday Follies/Why won't this work?/TSO Rant #387

What is wrong with this Rexx? (I spent about two hours debugging before I 
solved it.) The problem is right here on this page: the answer is NOT something 
in RACF or JES2. It's not something missing: it's a sin of commission, not a 
sin of omission. The below will never work. That is, the output will always be 
RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?

/* Rexx to test command/response */
MyCart = "MyCart01"
"CONSPROF SOLDISP(NO) SOLNUM(400)"
"CONSOLE ACTIVATE"
Address Console
"CART" MyCart
"$DQ"   
RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1 "CONSOLE DEACTIVATE"

Charles

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

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

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

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

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Charles Mills]

We have a winner! You've got it about 90%.

The clue is in the subject line -- this is actually a TSO rant.

TSO uppercases commands so "CART" MyCart becomes effectively "CART
MYCART01".

GETMSG is an ordinary Rexx function so parameters are passed "as-is," and RC
= GETMSG('MYMSGS.','SOL',MyCart,,1) becomes effectively 
RC = GETMSG('MYMSGS.','SOL','MyCart01',,1).

The two CARTs do not match, and no messages are retrieved.

I think it is *possible* that you could solve the problem by quoting the
CART but I have not tested. Something like "CART" "'"||MyCart||"'" .

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Robert Garrett
Sent: Friday, May 22, 2020 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Your problem is caused by using lower case characters in your CART parameter
value, the value of variable MyCart.   If you used all upper case, or all
numerics, it would work fine. 
That's not documented anywhere that I've thus far been able to find.

Cheers,
Robert

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Friday, May 22, 2020 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387


 I called my congressman and he said quote
 I'd like to help you son, but you're too young to vote.



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

____
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Friday, May 22, 2020 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Friday Follies/Why won't this work?/TSO Rant #387

What is wrong with this Rexx? (I spent about two hours debugging before I
solved it.) The problem is right here on this page: the answer is NOT
something in RACF or JES2. It's not something missing: it's a sin of
commission, not a sin of omission. The below will never work. That is, the
output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?

/* Rexx to test command/response */
MyCart = "MyCart01"
"CONSPROF SOLDISP(NO) SOLNUM(400)"
"CONSOLE ACTIVATE"
Address Console
"CART" MyCart
"$DQ"   
RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1 "CONSOLE DEACTIVATE"

Charles

--
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: Friday Follies/Why won't this work?/TSO Rant #387

[Robert Garrett]

Your problem is caused by using lower case characters in your CART parameter 
value, the value of variable MyCart.   If you used all upper case, or all 
numerics, it would work fine. 
That's not documented anywhere that I've thus far been able to find.

Cheers,
Robert

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, May 22, 2020 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387


 I called my congressman and he said quote
 I'd like to help you son, but you're too young to vote.



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Friday, May 22, 2020 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Friday Follies/Why won't this work?/TSO Rant #387

What is wrong with this Rexx? (I spent about two hours debugging before I 
solved it.) The problem is right here on this page: the answer is NOT something 
in RACF or JES2. It's not something missing: it's a sin of commission, not a 
sin of omission. The below will never work. That is, the output will always be 
RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?

/* Rexx to test command/response */
MyCart = "MyCart01"
"CONSPROF SOLDISP(NO) SOLNUM(400)"
"CONSOLE ACTIVATE"
Address Console
"CART" MyCart
"$DQ"
RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1 "CONSOLE DEACTIVATE"

Charles

--
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: Friday Follies/Why won't this work?/TSO Rant #387

[Charles Mills]

SYSCMD() is a valid alternative to Address Console but either one is good, and 
the Address Console in my Rexx is not the problem.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Friday, May 22, 2020 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Charles ,

I was incorrect here:

READY

CONSPROF SOLDISP(NO) SOLNUM(400)
CONSOLE ACTIVATE
CONSOLE SYSCMD($S PRT1) CART('PRT10001')
CONSOLE SYSCMD($S PRT2) CART('PRT20002')
EXEC MY.EXEC(CHKPRT) 'PRT10001' EXEC
EXEC MY.EXEC(CHKPRT) 'PRT20002' EXEC

The exec you invoke (CHKPRT) checks whether the printers were started
successfully. The exec uses the arguments you pass on the invocation (CART
values) as the CART on the GETMSG function. Figure 1
<https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikja300/ikja300179.htm?view=kc#ikja300-gen179__chkprt>
shows
the example exec.
Figure 1. Example exec (CHKPRT) to check start of printers

/* REXX exec to check start of printers */
ARG CARTVAL
GETCODE = GETMSG('PRTMSG.','SOL',CARTVAL,,60)
IF GETCODE = 0 THEN
  DO
IF POS('$HASP000',PRTMSG.1) ¬= 0 THEN
  SAY "Printer started successfully."
ELSE
  DO INDXNUM = 1 TO PRTMSG.0
SAY PRTMSG.INDXNUM
  END
  END
ELSE
  SAY "GETMSG error retrieving message.  Return code is" GETCODE
EXIT


On Fri, May 22, 2020 at 12:40 PM scott Ford  wrote:

> Charles:
>
> I think that should be 'address mvs' ...scott
>
> On Fri, May 22, 2020 at 12:35 PM Charles Mills  wrote:
>
>> Message handling is fine, other than one very specific problem that is
>> inherent in the Rexx code posted.
>>
>> Note this is a Friday Folly, not a "real question." I know the answer
>> (after 2+ hours of debug struggle!).
>>
>> Charles
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Joe Monk
>> Sent: Friday, May 22, 2020 9:07 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387
>>
>> Check your message handling ...
>>
>> Joe
>>
>> On Fri, May 22, 2020 at 11:00 AM Seymour J Metz  wrote:
>>
>> > 
>> >  I called my congressman and he said quote
>> >  I'd like to help you son, but you're too young to vote.
>> > 
>> >
>> >
>> > --
>> > Shmuel (Seymour J.) Metz
>> > http://mason.gmu.edu/~smetz3
>> >
>> > 
>> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
>> behalf
>> > of Charles Mills [charl...@mcn.org]
>> > Sent: Friday, May 22, 2020 10:02 AM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Friday Follies/Why won't this work?/TSO Rant #387
>> >
>> > What is wrong with this Rexx? (I spent about two hours debugging before
>> I
>> > solved it.) The problem is right here on this page: the answer is NOT
>> > something in RACF or JES2. It's not something missing: it's a sin of
>> > commission, not a sin of omission. The below will never work. That is,
>> the
>> > output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?
>> >
>> > /* Rexx to test command/response */
>> > MyCart = "MyCart01"
>> > "CONSPROF SOLDISP(NO) SOLNUM(400)"
>> > "CONSOLE ACTIVATE"
>> > Address Console
>> > "CART" MyCart
>> > "$DQ"
>> > RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
>> > Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1
>> > "CONSOLE DEACTIVATE"
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
> www.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: www.idmworks.com/blog
>
>
>
>
>
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of th

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Charles Mills]

Nope.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Friday, May 22, 2020 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

If I turn on HILITE, will the answer become apparent? 😊

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, May 22, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Message handling is fine, other than one very specific problem that is inherent 
in the Rexx code posted.

Note this is a Friday Folly, not a "real question." I know the answer (after 2+ 
hours of debug struggle!).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe Monk
Sent: Friday, May 22, 2020 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Check your message handling ...

Joe

On Fri, May 22, 2020 at 11:00 AM Seymour J Metz  wrote:

> 
>  I called my congressman and he said quote
>  I'd like to help you son, but you're too young to vote.
> 
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Charles Mills [charl...@mcn.org]
> Sent: Friday, May 22, 2020 10:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Friday Follies/Why won't this work?/TSO Rant #387
>
> What is wrong with this Rexx? (I spent about two hours debugging 
> before I solved it.) The problem is right here on this page: the 
> answer is NOT something in RACF or JES2. It's not something missing: 
> it's a sin of commission, not a sin of omission. The below will never 
> work. That is, the output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = 
> MYMSGS.1. Why?
>
> /* Rexx to test command/response */
> MyCart = "MyCart01"
> "CONSPROF SOLDISP(NO) SOLNUM(400)"
> "CONSOLE ACTIVATE"
> Address Console
> "CART" MyCart
> "$DQ"
> RC = GETMSG('MYMSGS.','SOL',MyCart,,1) Say "RC =" RC ", Msgs =" 
> MYMSGS.0 ", Msg.1 =" MYMSGS.1 "CONSOLE DEACTIVATE"

--
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: Friday Follies/Why won't this work?/TSO Rant #387

[scott Ford]

Charles ,

I was incorrect here:

READY

CONSPROF SOLDISP(NO) SOLNUM(400)
CONSOLE ACTIVATE
CONSOLE SYSCMD($S PRT1) CART('PRT10001')
CONSOLE SYSCMD($S PRT2) CART('PRT20002')
EXEC MY.EXEC(CHKPRT) 'PRT10001' EXEC
EXEC MY.EXEC(CHKPRT) 'PRT20002' EXEC

The exec you invoke (CHKPRT) checks whether the printers were started
successfully. The exec uses the arguments you pass on the invocation (CART
values) as the CART on the GETMSG function. Figure 1
<https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikja300/ikja300179.htm?view=kc#ikja300-gen179__chkprt>
shows
the example exec.
Figure 1. Example exec (CHKPRT) to check start of printers

/* REXX exec to check start of printers */
ARG CARTVAL
GETCODE = GETMSG('PRTMSG.','SOL',CARTVAL,,60)
IF GETCODE = 0 THEN
  DO
IF POS('$HASP000',PRTMSG.1) ¬= 0 THEN
  SAY "Printer started successfully."
ELSE
  DO INDXNUM = 1 TO PRTMSG.0
SAY PRTMSG.INDXNUM
  END
  END
ELSE
  SAY "GETMSG error retrieving message.  Return code is" GETCODE
EXIT


On Fri, May 22, 2020 at 12:40 PM scott Ford  wrote:

> Charles:
>
> I think that should be 'address mvs' ...scott
>
> On Fri, May 22, 2020 at 12:35 PM Charles Mills  wrote:
>
>> Message handling is fine, other than one very specific problem that is
>> inherent in the Rexx code posted.
>>
>> Note this is a Friday Folly, not a "real question." I know the answer
>> (after 2+ hours of debug struggle!).
>>
>> Charles
>>
>>
>> -Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Joe Monk
>> Sent: Friday, May 22, 2020 9:07 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387
>>
>> Check your message handling ...
>>
>> Joe
>>
>> On Fri, May 22, 2020 at 11:00 AM Seymour J Metz  wrote:
>>
>> > 
>> >  I called my congressman and he said quote
>> >  I'd like to help you son, but you're too young to vote.
>> > 
>> >
>> >
>> > --
>> > Shmuel (Seymour J.) Metz
>> > http://mason.gmu.edu/~smetz3
>> >
>> > 
>> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
>> behalf
>> > of Charles Mills [charl...@mcn.org]
>> > Sent: Friday, May 22, 2020 10:02 AM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Friday Follies/Why won't this work?/TSO Rant #387
>> >
>> > What is wrong with this Rexx? (I spent about two hours debugging before
>> I
>> > solved it.) The problem is right here on this page: the answer is NOT
>> > something in RACF or JES2. It's not something missing: it's a sin of
>> > commission, not a sin of omission. The below will never work. That is,
>> the
>> > output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?
>> >
>> > /* Rexx to test command/response */
>> > MyCart = "MyCart01"
>> > "CONSPROF SOLDISP(NO) SOLNUM(400)"
>> > "CONSOLE ACTIVATE"
>> > Address Console
>> > "CART" MyCart
>> > "$DQ"
>> > RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
>> > Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1
>> > "CONSOLE DEACTIVATE"
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
> www.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: www.idmworks.com/blog
>
>
>
>
>
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
>


-- 



*IDMWO

Re: Friday Follies/Why won't this work?/TSO Rant #387

[scott Ford]

Charles:

I think that should be 'address mvs' ...scott

On Fri, May 22, 2020 at 12:35 PM Charles Mills  wrote:

> Message handling is fine, other than one very specific problem that is
> inherent in the Rexx code posted.
>
> Note this is a Friday Folly, not a "real question." I know the answer
> (after 2+ hours of debug struggle!).
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joe Monk
> Sent: Friday, May 22, 2020 9:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387
>
> Check your message handling ...
>
> Joe
>
> On Fri, May 22, 2020 at 11:00 AM Seymour J Metz  wrote:
>
> > 
> >  I called my congressman and he said quote
> >  I'd like to help you son, but you're too young to vote.
> > 
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > ____
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Charles Mills [charl...@mcn.org]
> > Sent: Friday, May 22, 2020 10:02 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Friday Follies/Why won't this work?/TSO Rant #387
> >
> > What is wrong with this Rexx? (I spent about two hours debugging before I
> > solved it.) The problem is right here on this page: the answer is NOT
> > something in RACF or JES2. It's not something missing: it's a sin of
> > commission, not a sin of omission. The below will never work. That is,
> the
> > output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?
> >
> > /* Rexx to test command/response */
> > MyCart = "MyCart01"
> > "CONSPROF SOLDISP(NO) SOLNUM(400)"
> > "CONSOLE ACTIVATE"
> > Address Console
> > "CART" MyCart
> > "$DQ"
> > RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
> > Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1
> > "CONSOLE DEACTIVATE"
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




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



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





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

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Richards, Robert B.]

If I turn on HILITE, will the answer become apparent? 😊

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, May 22, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Message handling is fine, other than one very specific problem that is inherent 
in the Rexx code posted.

Note this is a Friday Folly, not a "real question." I know the answer (after 2+ 
hours of debug struggle!).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe Monk
Sent: Friday, May 22, 2020 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Check your message handling ...

Joe

On Fri, May 22, 2020 at 11:00 AM Seymour J Metz  wrote:

> 
>  I called my congressman and he said quote
>  I'd like to help you son, but you're too young to vote.
> 
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Charles Mills [charl...@mcn.org]
> Sent: Friday, May 22, 2020 10:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Friday Follies/Why won't this work?/TSO Rant #387
>
> What is wrong with this Rexx? (I spent about two hours debugging 
> before I solved it.) The problem is right here on this page: the 
> answer is NOT something in RACF or JES2. It's not something missing: 
> it's a sin of commission, not a sin of omission. The below will never 
> work. That is, the output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = 
> MYMSGS.1. Why?
>
> /* Rexx to test command/response */
> MyCart = "MyCart01"
> "CONSPROF SOLDISP(NO) SOLNUM(400)"
> "CONSOLE ACTIVATE"
> Address Console
> "CART" MyCart
> "$DQ"
> RC = GETMSG('MYMSGS.','SOL',MyCart,,1) Say "RC =" RC ", Msgs =" 
> MYMSGS.0 ", Msg.1 =" MYMSGS.1 "CONSOLE DEACTIVATE"

--
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: Friday Follies/Why won't this work?/TSO Rant #387

[Charles Mills]

Message handling is fine, other than one very specific problem that is inherent 
in the Rexx code posted.

Note this is a Friday Folly, not a "real question." I know the answer (after 2+ 
hours of debug struggle!).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe Monk
Sent: Friday, May 22, 2020 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Check your message handling ...

Joe

On Fri, May 22, 2020 at 11:00 AM Seymour J Metz  wrote:

> 
>  I called my congressman and he said quote
>  I'd like to help you son, but you're too young to vote.
> 
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Charles Mills [charl...@mcn.org]
> Sent: Friday, May 22, 2020 10:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Friday Follies/Why won't this work?/TSO Rant #387
>
> What is wrong with this Rexx? (I spent about two hours debugging before I
> solved it.) The problem is right here on this page: the answer is NOT
> something in RACF or JES2. It's not something missing: it's a sin of
> commission, not a sin of omission. The below will never work. That is, the
> output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?
>
> /* Rexx to test command/response */
> MyCart = "MyCart01"
> "CONSPROF SOLDISP(NO) SOLNUM(400)"
> "CONSOLE ACTIVATE"
> Address Console
> "CART" MyCart
> "$DQ"
> RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
> Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1
> "CONSOLE DEACTIVATE"

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

Re: Friday Follies/Why won't this work?/TSO Rant #387

[Charles Mills]

Nope, it is fine.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Richards, Robert B.
Sent: Friday, May 22, 2020 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday Follies/Why won't this work?/TSO Rant #387

Address Console in wrong location?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Charles Mills
Sent: Friday, May 22, 2020 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Friday Follies/Why won't this work?/TSO Rant #387

What is wrong with this Rexx? (I spent about two hours debugging before I
solved it.) The problem is right here on this page: the answer is NOT
something in RACF or JES2. It's not something missing: it's a sin of
commission, not a sin of omission. The below will never work. That is, the
output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?

/* Rexx to test command/response */ 
MyCart = "MyCart01" 
"CONSPROF SOLDISP(NO) SOLNUM(400)"  
"CONSOLE ACTIVATE"  
Address Console 
"CART" MyCart  
"$DQ"   
RC = GETMSG('MYMSGS.','SOL',MyCart,,1)  
Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1 
"CONSOLE DEACTIVATE"

Charles 

--
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: Friday Follies/Why won't this work?/TSO Rant #387

[Joe Monk]

Check your message handling ...

Joe

On Fri, May 22, 2020 at 11:00 AM Seymour J Metz  wrote:

> 
>  I called my congressman and he said quote
>  I'd like to help you son, but you're too young to vote.
> 
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Charles Mills [charl...@mcn.org]
> Sent: Friday, May 22, 2020 10:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Friday Follies/Why won't this work?/TSO Rant #387
>
> What is wrong with this Rexx? (I spent about two hours debugging before I
> solved it.) The problem is right here on this page: the answer is NOT
> something in RACF or JES2. It's not something missing: it's a sin of
> commission, not a sin of omission. The below will never work. That is, the
> output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?
>
> /* Rexx to test command/response */
> MyCart = "MyCart01"
> "CONSPROF SOLDISP(NO) SOLNUM(400)"
> "CONSOLE ACTIVATE"
> Address Console
> "CART" MyCart
> "$DQ"
> RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
> Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1
> "CONSOLE DEACTIVATE"
>
> Charles
>
> --
> 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: Friday Follies/Why won't this work?/TSO Rant #387

[Seymour J Metz]

 I called my congressman and he said quote
 I'd like to help you son, but you're too young to vote.



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Friday, May 22, 2020 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Friday Follies/Why won't this work?/TSO Rant #387

What is wrong with this Rexx? (I spent about two hours debugging before I
solved it.) The problem is right here on this page: the answer is NOT
something in RACF or JES2. It's not something missing: it's a sin of
commission, not a sin of omission. The below will never work. That is, the
output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?

/* Rexx to test command/response */
MyCart = "MyCart01"
"CONSPROF SOLDISP(NO) SOLNUM(400)"
"CONSOLE ACTIVATE"
Address Console
"CART" MyCart
"$DQ"
RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1
"CONSOLE DEACTIVATE"

Charles

--
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: Friday Follies/Why won't this work?/TSO Rant #387

[Richards, Robert B.]

Address Console in wrong location?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, May 22, 2020 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Friday Follies/Why won't this work?/TSO Rant #387

What is wrong with this Rexx? (I spent about two hours debugging before I 
solved it.) The problem is right here on this page: the answer is NOT something 
in RACF or JES2. It's not something missing: it's a sin of commission, not a 
sin of omission. The below will never work. That is, the output will always be 
RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?

/* Rexx to test command/response */ 
MyCart = "MyCart01" 
"CONSPROF SOLDISP(NO) SOLNUM(400)"  
"CONSOLE ACTIVATE"  
Address Console 
"CART" MyCart  
"$DQ"   
RC = GETMSG('MYMSGS.','SOL',MyCart,,1)  
Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1 
"CONSOLE DEACTIVATE"

Charles 

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

Friday Follies/Why won't this work?/TSO Rant #387

[Charles Mills]

What is wrong with this Rexx? (I spent about two hours debugging before I
solved it.) The problem is right here on this page: the answer is NOT
something in RACF or JES2. It's not something missing: it's a sin of
commission, not a sin of omission. The below will never work. That is, the
output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?

/* Rexx to test command/response */ 
MyCart = "MyCart01" 
"CONSPROF SOLDISP(NO) SOLNUM(400)"  
"CONSOLE ACTIVATE"  
Address Console 
"CART" MyCart  
"$DQ"   
RC = GETMSG('MYMSGS.','SOL',MyCart,,1)  
Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1 
"CONSOLE DEACTIVATE"

Charles 

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

Re: Friday OT, cheerful program for gloomy times

[CM Poncelet]

conditional macro assembler as in (readable form):
 
.EXTRM   ANOP  TERMINAL EXCLUDES DEFINITION 
.*  
&A1  SETA  1
&C1  SETC  '&EXCNT' 
&@SYSSETC  'EXCL&SYSNDX' 
&@SYSDCH'&C1'  EXCLUDES COUNT
.*   
.EXLOOP  AIF   (&FLHEX).@EXHEX
&A2  SETA  &@EXCLUD(&A1)   CONVERT EXCLUDES TO HEXADECIMAL
&A3  SETA  &A2/16<-- modulo 16 part 1   
  
&C1  SETC  '&HEXVAL(&A3+1)'   
&A3  SETA  &A2-(&A3*16)  <-- modulo 16 part 2   
  
&C2  SETC  '&HEXVAL(&A3+1)'   
&@EXCLUD(&A1) SETC  '&C1&C2'  
.@EXHEX  DCXL1'&@EXCLUD(&A1)'  EXCLUDED   
&A1  SETA  &A1+1  
 AIF   (&A1 LE &EXCNT).EXLOOP 
&@SYSSETC  'EXMK&SYSNDX'  
&@SYSDCXL2''   END OF EXCLUDES MARKER 
.*
 MNOTE *,' COUNT OF TERMINALS EXCLUDED = &EXCNT'  
&@NZ SETC  'EXTRMOK'  
 AGO   .EXCNTL END OF TERMINAL EXCLUDES   
.*
.**   
.*
.EXCLEND ANOP  END OF TERMINAL EXCLUDES BLOCK 
&@NZ SETC  'EXCLOK'  
.EXDONE  AGO   .EXCNTL
.* 
 

 
Cheers. 



On 29/04/2020 03:05, Paul Gilmartin wrote:
> On Wed, 29 Apr 2020 02:57:23 +0100, CM Poncelet wrote:
>
>> ... but that's the only way to do it in conditional macro assembler; so
>> what me worry about 3GL's? :)
>>
> What hardware?  Doesn't Divide leave the quotient in one register and the
> remainder in an adjacent one?
>
>> On 28/04/2020 10:46, David Crayford wrote:
>>> No worries. FWIW,  I think using the // modulo operator would make
>>> your code less verbose and complex ;)
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

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

Re: Friday OT, cheerful program for gloomy times

[CM Poncelet]

conditional macro assembler as in:
 
.EXTRM   ANOP  TERMINAL EXCLUDES DEFINITION
00075800
.* 
00075900
&A1  SETA  1   
00076000
&C1  SETC  '&EXCNT'
00076100
&@SYS    SETC  'EXCL&SYSNDX'   
00076200
&@SYS    DC    H'&C1'  EXCLUDES COUNT  
00076336
.* 
00076400
.EXLOOP  AIF   (&FLHEX).@EXHEX 
00076500
&A2  SETA  &@EXCLUD(&A1)   CONVERT EXCLUDES TO HEXADECIMAL 
00076600
&A3  SETA  &A2/16  
00076700 <--
&C1  SETC  '&HEXVAL(&A3+1)'
00076800
&A3  SETA  &A2-(&A3*16)
00076900 <--
&C2  SETC  '&HEXVAL(&A3+1)'
00077000
&@EXCLUD(&A1) SETC  '&C1&C2'   
00077100
.@EXHEX  DC    XL1'&@EXCLUD(&A1)'  EXCLUDED
00077200
&A1  SETA  &A1+1   
00077300
 AIF   (&A1 LE &EXCNT).EXLOOP  
00077400
&@SYS    SETC  'EXMK&SYSNDX'   
00077500
&@SYS    DC    XL2''   END OF EXCLUDES MARKER  
00077600
.* 
00077700
 MNOTE *,' COUNT OF TERMINALS EXCLUDED = &EXCNT'   
00077800
&@NZ SETC  'EXTRMOK'   
00077900
 AGO   .EXCNTL END OF TERMINAL EXCLUDES
00078000
.* 
00078100
 

 
Cheers.
 


On 29/04/2020 03:05, Paul Gilmartin wrote:
> On Wed, 29 Apr 2020 02:57:23 +0100, CM Poncelet wrote:
>
>> ... but that's the only way to do it in conditional macro assembler; so
>> what me worry about 3GL's? :)
>>
> What hardware?  Doesn't Divide leave the quotient in one register and the
> remainder in an adjacent one?
>
>> On 28/04/2020 10:46, David Crayford wrote:
>>> No worries. FWIW,  I think using the // modulo operator would make
>>> your code less verbose and complex ;)
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

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

Re: Friday OT, cheerful program for gloomy times

[Paul Gilmartin]

On Wed, 29 Apr 2020 02:57:23 +0100, CM Poncelet wrote:

>... but that's the only way to do it in conditional macro assembler; so
>what me worry about 3GL's? :)
>
What hardware?  Doesn't Divide leave the quotient in one register and the
remainder in an adjacent one?

>On 28/04/2020 10:46, David Crayford wrote:
>> No worries. FWIW,  I think using the // modulo operator would make
>> your code less verbose and complex ;)

-- gil

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

Re: Friday OT, cheerful program for gloomy times

[CM Poncelet]

... but that's the only way to do it in conditional macro assembler; so
what me worry about 3GL's? :)

On 28/04/2020 10:46, David Crayford wrote:
> No worries. FWIW,  I think using the // modulo operator would make
> your code less verbose and complex ;)
>
> On 2020-04-28 11:14 AM, CM Poncelet wrote:
>> Yes, you are absolutely right. I thought it was the other way round,
>> divisble by 100 being leap years and by 400 not leap years.
>>   It should have been
>>    LEAP  = (YEAR-YEAR%4*4=0 & YEAR-YEAR%100*100¬=0 |
>> YEAR-YEAR%400*400=0)
>>   This does not affect the calculations themselves, but it does report
>> incorrectly e.g. that 2000.0229 is not valid.
>>   Thanks a lot for pointing this out.
>>   Cheers, Chris Poncelet
>>    
>> On 27/04/2020 10:01, David Crayford wrote:
>>> FYI, you have a bug with your leap year calculation. You need to check
>>> if the year is evenly dividable by 100 (which are not leap years
>>> unless evenly divisible by 400).
>>>
>>> isleap: procedure
>>>    arg year .
>>>    return (year // 4 = 0 & year // 100 /= 0 ) | year // 400 = 0
>>>
>>> On 2020-04-24 2:01 PM, CM Poncelet wrote:
 I attach a Rexx program to calculate and display the biorhythm values
 for a given date of birth and current or whatever other date.
    If 'management' complains that home workers are not putting enough
 effort into their working-from-home time, they can run this thing and
 send its output to 'management' just to prove that they are in perfect
 working condition and that any slow-down in productivity must be
 due to
 external factors which are wholly beyond their control .
    Cheers, Chris Poncelet (retired sysprog)

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

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

Re: Friday OT, cheerful program for gloomy times

[Seymour J Metz]

That's an example of why I bought Tritus SPF (TSPF) instead of CTC.

ISREDIT is the environment for ISPF/PDF EDIT, and any EDIT macro needs services 
in that environment. address ISPEXEC ISREDIT foo is a slower way of doing 
address ISREDIT foo.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM 
Poncelet [ponce...@bcs.org.uk]
Sent: Monday, April 27, 2020 11:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

Thanks, but I get the following errors:

ecalc(182): Error #39, Evaluation stack overflow
do until tmp = tail

PRESS ANY KEY TO CONTINUE.

and

Error 10: Illegal ISPEXEC Service 'isredit macro (parm) NOPROCESS'.

PRESS ANY KEY TO CONTINUE.

I have CTC Rexx running under DOS - perhaps not the right environment
for this 

Cheers, Chris



On 27/04/2020 15:29, Robert Prins wrote:
> On 2020-04-24 06:01, CM Poncelet wrote:
>> I attach a Rexx program to calculate and display the biorhythm values
>> for a given date of birth and current or whatever other date.
>
> And if you want to see some niche graphs, try "ecalc
> biog(dd.mm.)", where ecalc can be found (for now) @
> <https://secure-web.cisco.com/1IEjFWf_WpIzXSZGtslQ5NgyLlgelQ0Isk6VdTTMOJNR6rNFOdFyWDUc2sHnbOFOoOET604fO0-Op5_pJZRlp--kSbYjvq0VamP5TX_CsM4kMJqBUkIX25jYILwaV7R6uE8yeV9H1lkubTRGsplg5etFaV1CrnyNERMmSzBHdkq4J_L0rESTs5d_qYIu5QavSNv6Joy93XMvhVve06js4K6aJV_CCz996lWYOSgtg9--_y2VaxtFyXBhoqPGU5TRZn5_-W0qJQ1F8GhlOrj-7AAbNTS9HckC_nU_NXYVkAPLm999qxnwMOin6cCgpfEvcv2w1fqMkEpYQthRTdj6CVJAlcEiT0mi0f8LAOPNU0UtuuPOV0uiA-7-1YEjJxbGCDS7GSQS1b7b37uLu0rkeain9IJBvdw9En-2bncOZ2NBxI0V-sSWKX6cTQuu1itzj/https%3A%2F%2Fprino.neocities.org%2Ftemp%2Fecalc.rexx.txt>
>
> Also contains a few other more-or-lesser useful conversions, "ecalc ?"
> will display some help.
>
> Robert

--
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: Friday OT, cheerful program for gloomy times

[CM Poncelet]

Thanks - I have figured out how to use it.
 
It's an edit macro and it must therefore be saved with an ".spf"
extension instead of the ".isp" one used for CTC Rexx execs. Also, it
needs to be invoked while editing a file and not issued as a TSO
command. When all that is done, it works OK.
 
Thanks again.
 
Cheers, Chris


On 28/04/2020 13:56, Robert Prins wrote:
> On 2020-04-28 03:47, CM Poncelet wrote:
>> Thanks, but I get the following errors:
>>   ecalc(182): Error #39, Evaluation stack overflow
>>  do until tmp = tail
>>
>> PRESS ANY KEY TO CONTINUE.
>>   and
>>   Error 10: Illegal ISPEXEC Service 'isredit macro (parm) NOPROCESS'.
>>
>> PRESS ANY KEY TO CONTINUE.
>>   I have CTC Rexx running under DOS - perhaps not the right environment
>> for this 
>
> It probably isn't, and as I do not have access to CTC Rexx, it's
> highly unlikely that I'll ever update it for that environment.
> However, it probably should get a bit of TLC, given that the last
> update was nearly 11 years ago!
>
> I can only suggest you try a "trace ?r" to see why the error occurs.
>
> FWIW, if cross-over points are critical, I can concur, yesterday my
> P-cycle went through zero, and I managed to put my finger on a still
> running band-sander. Result wasn't pretty.
>
> And for what it's worth, if you use ecalc as a TSO command, you'll
> have to move the resulting long-message window to correctly see the
> biorhythm graph, on my 160x62 screen moving the left edge to column
> 91/2/3/4 will give you a correct display.
>
> Robert

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

Re: Friday OT, cheerful program for gloomy times

[Robert Prins]

On 2020-04-28 03:47, CM Poncelet wrote:

Thanks, but I get the following errors:
  
ecalc(182): Error #39, Evaluation stack overflow

     do until tmp = tail

PRESS ANY KEY TO CONTINUE.
  
and
  
Error 10: Illegal ISPEXEC Service 'isredit macro (parm) NOPROCESS'.


PRESS ANY KEY TO CONTINUE.
  
I have CTC Rexx running under DOS - perhaps not the right environment

for this 


It probably isn't, and as I do not have access to CTC Rexx, it's highly unlikely 
that I'll ever update it for that environment. However, it probably should get a 
bit of TLC, given that the last update was nearly 11 years ago!


I can only suggest you try a "trace ?r" to see why the error occurs.

FWIW, if cross-over points are critical, I can concur, yesterday my P-cycle went 
through zero, and I managed to put my finger on a still running band-sander. 
Result wasn't pretty.


And for what it's worth, if you use ecalc as a TSO command, you'll have to move 
the resulting long-message window to correctly see the biorhythm graph, on my 
160x62 screen moving the left edge to column 91/2/3/4 will give you a correct 
display.


Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html


On 27/04/2020 15:29, Robert Prins wrote:

On 2020-04-24 06:01, CM Poncelet wrote:

I attach a Rexx program to calculate and display the biorhythm values
for a given date of birth and current or whatever other date.


And if you want to see some niche graphs, try "ecalc
biog(dd.mm.)", where ecalc can be found (for now) @


Also contains a few other more-or-lesser useful conversions, "ecalc ?"
will display some help.

Robert


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




--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: Friday OT, cheerful program for gloomy times

[David Crayford]

No worries. FWIW,  I think using the // modulo operator would make your 
code less verbose and complex ;)


On 2020-04-28 11:14 AM, CM Poncelet wrote:

Yes, you are absolutely right. I thought it was the other way round,
divisble by 100 being leap years and by 400 not leap years.
  
It should have been

   LEAP  = (YEAR-YEAR%4*4=0 & YEAR-YEAR%100*100¬=0 | YEAR-YEAR%400*400=0)
  
This does not affect the calculations themselves, but it does report

incorrectly e.g. that 2000.0229 is not valid.
  
Thanks a lot for pointing this out.
  
Cheers, Chris Poncelet
  
  


On 27/04/2020 10:01, David Crayford wrote:

FYI, you have a bug with your leap year calculation. You need to check
if the year is evenly dividable by 100 (which are not leap years
unless evenly divisible by 400).

isleap: procedure
   arg year .
   return (year // 4 = 0 & year // 100 /= 0 ) | year // 400 = 0

On 2020-04-24 2:01 PM, CM Poncelet wrote:

I attach a Rexx program to calculate and display the biorhythm values
for a given date of birth and current or whatever other date.
   If 'management' complains that home workers are not putting enough
effort into their working-from-home time, they can run this thing and
send its output to 'management' just to prove that they are in perfect
working condition and that any slow-down in productivity must be due to
external factors which are wholly beyond their control .
   Cheers, Chris Poncelet (retired sysprog)

--
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: Friday OT, cheerful program for gloomy times

[CM Poncelet]

Thanks, but I get the following errors:
 
ecalc(182): Error #39, Evaluation stack overflow
    do until tmp = tail

PRESS ANY KEY TO CONTINUE.
 
and
 
Error 10: Illegal ISPEXEC Service 'isredit macro (parm) NOPROCESS'.

PRESS ANY KEY TO CONTINUE.
 
I have CTC Rexx running under DOS - perhaps not the right environment
for this 
 
Cheers, Chris
 


On 27/04/2020 15:29, Robert Prins wrote:
> On 2020-04-24 06:01, CM Poncelet wrote:
>> I attach a Rexx program to calculate and display the biorhythm values
>> for a given date of birth and current or whatever other date.
>
> And if you want to see some niche graphs, try "ecalc
> biog(dd.mm.)", where ecalc can be found (for now) @
> 
>
> Also contains a few other more-or-lesser useful conversions, "ecalc ?"
> will display some help.
>
> Robert

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

Re: Friday OT, cheerful program for gloomy times

[CM Poncelet]

Yes, you are absolutely right. I thought it was the other way round,
divisble by 100 being leap years and by 400 not leap years.
 
It should have been
  LEAP  = (YEAR-YEAR%4*4=0 & YEAR-YEAR%100*100¬=0 | YEAR-YEAR%400*400=0)
 
This does not affect the calculations themselves, but it does report
incorrectly e.g. that 2000.0229 is not valid.
 
Thanks a lot for pointing this out.
 
Cheers, Chris Poncelet
 
 

On 27/04/2020 10:01, David Crayford wrote:
> FYI, you have a bug with your leap year calculation. You need to check
> if the year is evenly dividable by 100 (which are not leap years
> unless evenly divisible by 400).
>
> isleap: procedure
>   arg year .
>   return (year // 4 = 0 & year // 100 /= 0 ) | year // 400 = 0
>
> On 2020-04-24 2:01 PM, CM Poncelet wrote:
>> I attach a Rexx program to calculate and display the biorhythm values
>> for a given date of birth and current or whatever other date.
>>   If 'management' complains that home workers are not putting enough
>> effort into their working-from-home time, they can run this thing and
>> send its output to 'management' just to prove that they are in perfect
>> working condition and that any slow-down in productivity must be due to
>> external factors which are wholly beyond their control .
>>   Cheers, Chris Poncelet (retired sysprog)
>>
>> --
>> 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: Friday OT, cheerful program for gloomy times

[Seymour J Metz]

> What I have against (E)TOD is that IEBCOPY got leap seconds wrong
> until they resolved my APAR by converting to TIME.

That's an IEBCOPY issue. If TIME STCKE doesn't do adjustments, then *that* is 
the issue, not ETOD itself. I certainly hope that if IBM starts using ETOD for 
timestamps that they will do so through a documented system interface, not RYO. 
What would be really nice would be if they included both UT* and the zone in 
the new timestamp format.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Monday, April 27, 2020 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

On Mon, 27 Apr 2020 17:10:54 +, Seymour J Metz wrote:

>> I hope not.
>
>What do you have against ETOD?
>
>> TIME macro
> TIME  STCKE,foo
>
>Or doesn't that do the adjustments?
>
I believe it does not.  I believe TIME LOCAL and TIME GMT do.
I believe STCKCONV and CONVTOD do not.  I am confident
that before TOD rolls over TIME will be using ETOD.

What I have against (E)TOD is that IEBCOPY got leap seconds wrong
until they resolved my APAR by converting to TIME.

And back to David's report on the OP's BIO.TXT.  That uses two
different leap year formulae.  Neither reports an error for 1900.0229.
Rexx DATE() reports an error (though not very lucidly).  The moral
is, "Trust the experts; don't RYO (as IEBCOPY once did)."

-- gil

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

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

Re: Friday OT, cheerful program for gloomy times

[Paul Gilmartin]

On Mon, 27 Apr 2020 17:10:54 +, Seymour J Metz wrote:

>> I hope not.
>
>What do you have against ETOD?
>
>> TIME macro
> TIME  STCKE,foo
>
>Or doesn't that do the adjustments?
> 
I believe it does not.  I believe TIME LOCAL and TIME GMT do.
I believe STCKCONV and CONVTOD do not.  I am confident
that before TOD rolls over TIME will be using ETOD.

What I have against (E)TOD is that IEBCOPY got leap seconds wrong
until they resolved my APAR by converting to TIME.

And back to David's report on the OP's BIO.TXT.  That uses two
different leap year formulae.  Neither reports an error for 1900.0229.
Rexx DATE() reports an error (though not very lucidly).  The moral
is, "Trust the experts; don't RYO (as IEBCOPY once did)."

-- gil

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

Re: Friday OT, cheerful program for gloomy times

[Seymour J Metz]

> I hope not.

What do you have against ETOD?

> TIME macro

 TIME  STCKE,foo

Or doesn't that do the adjustments?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Monday, April 27, 2020 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

On 2020-04-27, at 04:57:13, Seymour J Metz wrote:
>
> Is there a statement of direction for using ETOD for all timestamping?
>
I hope not.

I once went to SR because the timestamps in IEBCOPY SYSPRINT were
about 20 seconds ahead of those in job log.  Suggested I suspected
a leap second problem.

Level 1> Whatsa Leap Second?

gil> [lotsa URLs; GIYF]

Level 1> Wow! Thanks!

They fixed it; closure text said they switched to TIME macro --
much better idea than RYO from ETOD, CVTLSO, CVTLDTO, ...


> On 2020-04-27, at 03:41:14, ITschak Mugzach wrote:
>
> צ
>
> בתאריך יום ב׳, 27 באפר׳ 2020, 12:38, מאת David Crayford ...
>
Year 5800/Y6K problem?

-- gil

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

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

Re: Friday OT, cheerful program for gloomy times

[Paul Gilmartin]

On Mon, 27 Apr 2020 17:01:08 +0800, David Crayford wrote:

>FYI, you have a bug with your leap year calculation. You need to check
>if the year is evenly dividable by 100 (which are not leap years unless
>evenly divisible by 400).
>
>isleap: procedure
>   arg year .
>   return (year // 4 = 0 & year // 100 /= 0 ) | year // 400 = 0
> 
I believe that's taken care of in the OP's code by:
... TRUNC((TRUNC(YY/100)+1)*3/4)

-- gil

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

Re: Friday OT, cheerful program for gloomy times

[Paul Gilmartin]

On 2020-04-27, at 04:57:13, Seymour J Metz wrote:
> 
> Is there a statement of direction for using ETOD for all timestamping?
>  
I hope not.

I once went to SR because the timestamps in IEBCOPY SYSPRINT were
about 20 seconds ahead of those in job log.  Suggested I suspected
a leap second problem.

Level 1> Whatsa Leap Second?

gil> [lotsa URLs; GIYF]

Level 1> Wow! Thanks!

They fixed it; closure text said they switched to TIME macro --
much better idea than RYO from ETOD, CVTLSO, CVTLDTO, ...


> On 2020-04-27, at 03:41:14, ITschak Mugzach wrote:
> 
> צ
> 
> בתאריך יום ב׳, 27 באפר׳ 2020, 12:38, מאת David Crayford ...
>   
Year 5800/Y6K problem?

-- gil

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

Re: Friday OT, cheerful program for gloomy times

[Robert Prins]

On 2020-04-24 06:01, CM Poncelet wrote:

I attach a Rexx program to calculate and display the biorhythm values
for a given date of birth and current or whatever other date.


And if you want to see some niche graphs, try "ecalc biog(dd.mm.)", where 
ecalc can be found (for now) @ 


Also contains a few other more-or-lesser useful conversions, "ecalc ?" will 
display some help.


Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: Friday OT, cheerful program for gloomy times

[Seymour J Metz]

Is there a statement of direction for using ETOD for all timestamping?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Monday, April 27, 2020 5:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

On 2020-04-27 5:18 PM, Ray Pearce wrote:
> Will there be a Y2.1K bug?

I don't know but we've got much bigger problems to solve before then
when the TOD clocks start wrapping :).

Hopefully, I will be retired by then.

--
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: Friday OT, cheerful program for gloomy times

[David Crayford]

I'll be 71 so I may come out of retirement to earn a few extra quid to 
bump up my pension!


On 2020-04-27 6:07 PM, Ray Pearce wrote:

I'm fairly certain I will retire at some point in the next 22 years.
Can't see me still working at age 87 ;)


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: 27 April 2020 10:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

On 2020-04-27 5:18 PM, Ray Pearce wrote:

Will there be a Y2.1K bug?

I don't know but we've got much bigger problems to solve before then
when the TOD clocks start wrapping :).

Hopefully, I will be retired by then.

--
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: Friday OT, cheerful program for gloomy times

[Ray Pearce]

I'm fairly certain I will retire at some point in the next 22 years.
Can't see me still working at age 87 ;)


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: 27 April 2020 10:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

On 2020-04-27 5:18 PM, Ray Pearce wrote:
> Will there be a Y2.1K bug?

I don't know but we've got much bigger problems to solve before then 
when the TOD clocks start wrapping :).

Hopefully, I will be retired by then.

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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: Friday OT, cheerful program for gloomy times

[ITschak Mugzach]

צ

בתאריך יום ב׳, 27 באפר׳ 2020, 12:38, מאת David Crayford ‏<
dcrayf...@gmail.com>:

> On 2020-04-27 5:18 PM, Ray Pearce wrote:
> > Will there be a Y2.1K bug?
>
> I don't know but we've got much bigger problems to solve before then
> when the TOD clocks start wrapping :).
>
> Hopefully, I will be retired by then.
>
> --
> 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: Friday OT, cheerful program for gloomy times

[David Crayford]

On 2020-04-27 5:18 PM, Ray Pearce wrote:

Will there be a Y2.1K bug?


I don't know but we've got much bigger problems to solve before then 
when the TOD clocks start wrapping :).


Hopefully, I will be retired by then.

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

Re: Friday OT, cheerful program for gloomy times

[Ray Pearce]

I guess the code is assuming that the user isn't over 120 years old.

Will there be a Y2.1K bug?

Ray

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: 27 April 2020 10:01
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

FYI, you have a bug with your leap year calculation. You need to check 
if the year is evenly dividable by 100 (which are not leap years unless 
evenly divisible by 400).

isleap: procedure
   arg year .
   return (year // 4 = 0 & year // 100 /= 0 ) | year // 400 = 0


-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: Friday OT, cheerful program for gloomy times

[David Crayford]

FYI, you have a bug with your leap year calculation. You need to check 
if the year is evenly dividable by 100 (which are not leap years unless 
evenly divisible by 400).


isleap: procedure
  arg year .
  return (year // 4 = 0 & year // 100 /= 0 ) | year // 400 = 0

On 2020-04-24 2:01 PM, CM Poncelet wrote:

I attach a Rexx program to calculate and display the biorhythm values
for a given date of birth and current or whatever other date.
  
If 'management' complains that home workers are not putting enough

effort into their working-from-home time, they can run this thing and
send its output to 'management' just to prove that they are in perfect
working condition and that any slow-down in productivity must be due to
external factors which are wholly beyond their control .
  
Cheers, Chris Poncelet (retired sysprog)


--
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: Friday OT, cheerful program for gloomy times

[Seymour J Metz]

> Mike Cowlishaw created the Rexx language 

Yes, and if you look at the article you linked to, you will see "He has 
contributed to and/or edited various computing standards, including ISO (SGML, 
COBOL, C, C++), BSI (SGML, C), ANSI (REXX), IETF (HTTP 1.0/RFC 1945), W3C (XML 
Schema), ECMA (JavaScript/ECMAScript, C#, CLI), and IEEE (754 decimal 
floating-point). " 

I doubt that he would claim that the standard he worked on was the standard.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM 
Poncelet [ponce...@bcs.org.uk]
Sent: Sunday, April 26, 2020 3:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

Mike Cowlishaw created the Rexx language 

https://secure-web.cisco.com/1wHB0OokqTuD1qCScSXs4vR7WnmA1aaX4xY-RDe3iultGsGFW_EievpsqsLeqREtY7OMbYCI4fR2vRtHuiJBMAB54rDjknPMMRWKLZDzBB-eUsT5ekPkHDrGpMlAkrnPtHb4VklYeecMBEtsNkV-OBz9Tw5z4tWrAvfP1NnTUbx-unParojR5d0_Xfxp0NaFNp0x760nqXgkUkxzXDDR89eqE4ZdtPnAjD4z0oBAx3sPct9_KvjZEz6kFgU6kbGRXldrUl7ZbMG9Vm0CTdsT9_wMAIt3MO-9efLINUKHCRrn_yp1mQ_KHYBgZzr8pwNsrhpyasbuWzJQ_SI2SIM2xLf87UvB8ks78AYRd-gSbp14-Q-YdaPhLW0iF7Wz-FGyudvxjxyBinuLwPVfO-haEjGKSVJ9Ya0qI-VeF1UKsvbZT_AvDY4XzIUiOBxz9VvJ3/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMike_Cowlishaw


On 26/04/2020 15:48, Paul Gilmartin wrote:
> On Sun, 26 Apr 2020 07:39:27 +, Seymour J Metz wrote:
>
>> They say that the memory is the second thing to go; I don't remember the 
>> first thing.
>>
>> Given that Mike Cowlishaw was involved in developing ANSI  X3.274-1996, I'm 
>> pretty sure that he would claim that to be the standard Rexx language, just 
>> as I'm pretty sure that John Backus would consider X3.9-1966,  X3.9-1978, 
>> etc., to be standard Fortran, not what ran on the 704.
>>
> I find this akin to expecting all software to follow the antiquated
> MSDOS 8.3 filename format convention.
>
>> 
>> From: CM Poncelet
>> Sent: Saturday, April 25, 2020 11:40 PM
>>
>> "ON NO VALUE" from memory.
>>
> At one time, IBM's Rexx compiler considered SIGNAL ON NOVALUE (sic) a
> syntax error if the label was not supplied.  I think it got better shortly.
>
>> "supports the standard Rexx language" as per Mike Cowlishaw's definition
>> (COW).
>>
>>   Comparison of Built-In Functions
>>
>>  The following table provides a comparison of Built-In Functions
>>  for VM/SP CMS REXX (CMS), M.F. Cowlishaw's definition (COW),
>>  Systems Application Architecture Procedures Language (SAA), and
>>  CTC REXX.
>>
>>  Table 3. Comparison of Built-in Functions
>>
>>
>> Availability of Built-in Functions
>>
>>  FunctionSAA   COW   CMS   CTC
>>...
>> CHARINx x - x
>> CHAROUT   x x - x
>> CHARS x x - x
>> ...
>> DATE  x x x x
>> ...
> But no discussion of supported operand formats.
>
>> LINEINx x - x
>> LINEOUT   x x - x
>>...
>> STREAMx - - x
>>...
> CMS Rexx has supported the *standard* stream I/O for many releases.
>
> Where does one find SAA nowadays.  Mostly, I remember its incursion
> was disruptive by scrambling ISPF's familiar PF key assignments.
>
>>>> See below for the SPF/PC standard Rexx one.
>>>>
> I don't believe SPF/PC governs the standard for either Rexx or Java.
>
>>> DATE('B',foo,'S') is valid in standard Rexx. I don't believe that the first 
>>> and third
>>> parameters are allowed to be longer than 1 character.
>>>
> They're truncated.  Characters beyond the initial are irrelevant.
>
>  
>>> From: CM Poncelet
>>> Sent: Saturday, April 25, 2020 7:10 PM
>>>
>>> Have you checked that your version works, other than on a mainframe?
>>>
> Regina, yes.
>
>>> SPF/PC Rexx supports the standard Rexx language, but not the full IBM
>>> REXX (which includes EXECIO etc.) and it does not recognise your format
>>> of DATE parms. ...
>>>
> SPF/PC, perhaps; standard, no.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

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

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

Re: Friday OT, cheerful program for gloomy times

[CM Poncelet]

Mike Cowlishaw created the Rexx language 
 
https://en.wikipedia.org/wiki/Mike_Cowlishaw


On 26/04/2020 15:48, Paul Gilmartin wrote:
> On Sun, 26 Apr 2020 07:39:27 +, Seymour J Metz wrote:
>
>> They say that the memory is the second thing to go; I don't remember the 
>> first thing.
>>
>> Given that Mike Cowlishaw was involved in developing ANSI  X3.274-1996, I'm 
>> pretty sure that he would claim that to be the standard Rexx language, just 
>> as I'm pretty sure that John Backus would consider X3.9-1966,  X3.9-1978, 
>> etc., to be standard Fortran, not what ran on the 704.
>>
> I find this akin to expecting all software to follow the antiquated
> MSDOS 8.3 filename format convention.
>
>> 
>> From: CM Poncelet
>> Sent: Saturday, April 25, 2020 11:40 PM
>>
>> "ON NO VALUE" from memory.
>>
> At one time, IBM's Rexx compiler considered SIGNAL ON NOVALUE (sic) a
> syntax error if the label was not supplied.  I think it got better shortly.
>
>> "supports the standard Rexx language" as per Mike Cowlishaw's definition
>> (COW).
>>
>>   Comparison of Built-In Functions
>>
>>  The following table provides a comparison of Built-In Functions
>>  for VM/SP CMS REXX (CMS), M.F. Cowlishaw's definition (COW),
>>  Systems Application Architecture Procedures Language (SAA), and
>>  CTC REXX.
>>
>>  Table 3. Comparison of Built-in Functions
>>
>>
>> Availability of Built-in Functions
>>
>>  FunctionSAA   COW   CMS   CTC
>>...
>> CHARINx x - x
>> CHAROUT   x x - x
>> CHARS x x - x
>> ...
>> DATE  x x x x
>> ...
> But no discussion of supported operand formats.
>
>> LINEINx x - x
>> LINEOUT   x x - x
>>...   
>> STREAMx - - x
>>...
> CMS Rexx has supported the *standard* stream I/O for many releases.
>
> Where does one find SAA nowadays.  Mostly, I remember its incursion
> was disruptive by scrambling ISPF's familiar PF key assignments.
>
 See below for the SPF/PC standard Rexx one.

> I don't believe SPF/PC governs the standard for either Rexx or Java.
>
>>> DATE('B',foo,'S') is valid in standard Rexx. I don't believe that the first 
>>> and third 
>>> parameters are allowed to be longer than 1 character.
>>>
> They're truncated.  Characters beyond the initial are irrelevant.
>
>  
>>> From: CM Poncelet
>>> Sent: Saturday, April 25, 2020 7:10 PM
>>>
>>> Have you checked that your version works, other than on a mainframe?
>>>
> Regina, yes.
>
>>> SPF/PC Rexx supports the standard Rexx language, but not the full IBM
>>> REXX (which includes EXECIO etc.) and it does not recognise your format
>>> of DATE parms. ...
>>>
> SPF/PC, perhaps; standard, no.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

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

Re: Friday OT, cheerful program for gloomy times

[Paul Gilmartin]

On Sun, 26 Apr 2020 07:39:27 +, Seymour J Metz wrote:

>They say that the memory is the second thing to go; I don't remember the first 
>thing.
>
>Given that Mike Cowlishaw was involved in developing ANSI  X3.274-1996, I'm 
>pretty sure that he would claim that to be the standard Rexx language, just as 
>I'm pretty sure that John Backus would consider X3.9-1966,  X3.9-1978, etc., 
>to be standard Fortran, not what ran on the 704.
> 
I find this akin to expecting all software to follow the antiquated
MSDOS 8.3 filename format convention.

>
>From: CM Poncelet
>Sent: Saturday, April 25, 2020 11:40 PM
>
>"ON NO VALUE" from memory.
> 
At one time, IBM's Rexx compiler considered SIGNAL ON NOVALUE (sic) a
syntax error if the label was not supplied.  I think it got better shortly.

>"supports the standard Rexx language" as per Mike Cowlishaw's definition
>(COW).
>
>   Comparison of Built-In Functions
>
>  The following table provides a comparison of Built-In Functions
>  for VM/SP CMS REXX (CMS), M.F. Cowlishaw's definition (COW),
>  Systems Application Architecture Procedures Language (SAA), and
>  CTC REXX.
>
>  Table 3. Comparison of Built-in Functions
>
>
> Availability of Built-in Functions
>
>  FunctionSAA   COW   CMS   CTC
>...
> CHARINx x - x
> CHAROUT   x x - x
> CHARS x x - x
> ...
> DATE  x x x x
> ...
But no discussion of supported operand formats.

> LINEINx x - x
> LINEOUT   x x - x
>...   
> STREAMx - - x
>...
CMS Rexx has supported the *standard* stream I/O for many releases.

Where does one find SAA nowadays.  Mostly, I remember its incursion
was disruptive by scrambling ISPF's familiar PF key assignments.

>>> See below for the SPF/PC standard Rexx one.
>>>
I don't believe SPF/PC governs the standard for either Rexx or Java.

>> DATE('B',foo,'S') is valid in standard Rexx. I don't believe that the first 
>> and third 
>>parameters are allowed to be longer than 1 character.
>>
They're truncated.  Characters beyond the initial are irrelevant.

 
>> From: CM Poncelet
>> Sent: Saturday, April 25, 2020 7:10 PM
>>
>> Have you checked that your version works, other than on a mainframe?
>> 
Regina, yes.

>> SPF/PC Rexx supports the standard Rexx language, but not the full IBM
>> REXX (which includes EXECIO etc.) and it does not recognise your format
>> of DATE parms. ...
>>
SPF/PC, perhaps; standard, no.

-- gil

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

Re: Friday OT, cheerful program for gloomy times

[Seymour J Metz]

OREXX in OS/2:

Sun  4-26-20 10:16:16Sun  4-26-20 10:16:16{1}[h:\] H:\$REXX\trynot.cmd
Trying \ 5C
\ recognized
Trying ¬ AA
¬ recognized
Trying ¼ AC
 6 *-* compare = a ¼
 6 *-*   interpret 'compare = a' Not'= b'
REX0013E: Error 13 running H:\$REXX\TRYNOT.CMD line 6:  Invalid character in 
program
REX0219E: Error 13.1:  Incorrect character in program "¼" ('AC'X)

Code pages 437 and 850 have ¬ at AA and ¼ at AC.



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Joel C. Ewing [jcew...@acm.org]
Sent: Sunday, April 26, 2020 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

On 4/25/20 3:51 PM, Paul Gilmartin wrote:
> I did not copy-and-paste; I downloaded the attachment,
> which appears to be UTF-8.
>
> For Regina, Regina.pdf says: 3.1.1.1 Negators
> ... Regina supports the following characters as negators:
> ...
> ¬ Logical Not
> Copy-and-paste from the pdf gives me:
> 931 $ printf ¬ | od -tx1
> 000c2  ac
> ... the UTF-8 "¬".  But when I paste it into an EXEC, Regina says:
>  say 2+2 ¬= 4
> Error 13 running "/Users/paulgilm/bin/rxx", line 2: Invalid character in 
> program
> Error 13.1: Invalid character in program "('c2'X)"
>
> I much prefer when the examples in the Ref. actually work.  Does
> ooRexx accept UTF-8 "¬"?
>
> I went on and did something fancy.  Attached.

On  Linux oorexx accepts UTF-8 "¬" , but can't speak for oorexx in M$
environment; and also seems to work for all in Seymour's nots list (Nots
= '\' 'aa'x 'ac'x), but am at a loss to remember context for using
'aa'x as a logical not -- displays as "feminine ordinal indicator" "ª"
in gedit on Linux.

Joel C. Ewing

--
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: Friday OT, cheerful program for gloomy times

[Joel C. Ewing]

On 4/25/20 3:51 PM, Paul Gilmartin wrote:
> I did not copy-and-paste; I downloaded the attachment,
> which appears to be UTF-8.
>
> For Regina, Regina.pdf says: 3.1.1.1 Negators
> ... Regina supports the following characters as negators:
> ...
> ¬ Logical Not
> Copy-and-paste from the pdf gives me:
> 931 $ printf ¬ | od -tx1
> 000c2  ac
> ... the UTF-8 "¬".  But when I paste it into an EXEC, Regina says:
>  say 2+2 ¬= 4
> Error 13 running "/Users/paulgilm/bin/rxx", line 2: Invalid character in 
> program
> Error 13.1: Invalid character in program "('c2'X)"
>
> I much prefer when the examples in the Ref. actually work.  Does
> ooRexx accept UTF-8 "¬"?
>
> I went on and did something fancy.  Attached.

On  Linux oorexx accepts UTF-8 "¬" , but can't speak for oorexx in M$
environment; and also seems to work for all in Seymour's nots list (Nots
= '\' 'aa'x 'ac'x), but am at a loss to remember context for using 
'aa'x as a logical not -- displays as "feminine ordinal indicator" "ª"
in gedit on Linux.

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: Friday OT, cheerful program for gloomy times

[Seymour J Metz]

They say that the memory is the second thing to go; I don't remember the first 
thing.

Given that Mike Cowlishaw was involved in developing ANSI  X3.274-1996, I'm 
pretty sure that he would claim that to be the standard Rexx language, just as 
I'm pretty sure that John Backus would consider X3.9-1966,  X3.9-1978, etc., to 
be standard Fortran, not what ran on the 704.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM 
Poncelet [ponce...@bcs.org.uk]
Sent: Saturday, April 25, 2020 11:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

"ON NO VALUE" from memory.

"supports the standard Rexx language" as per Mike Cowlishaw's definition
(COW).

   Comparison of Built-In Functions

  The following table provides a comparison of Built-In Functions
  for VM/SP CMS REXX (CMS), M.F. Cowlishaw's definition (COW),
  Systems Application Architecture Procedures Language (SAA), and
  CTC REXX.

  Table 3. Comparison of Built-in Functions


 Availability of Built-in Functions

  FunctionSAA   COW   CMS   CTC

 ABBREVx x x x
 ABS   x x x x
 ADDRESS   x x x x
 ARG   x x x x
 BITANDx x x x
 BITOR x x x x
 BITXORx x x x
 B2X   x - - x
 CENTERx x x x
 CHARINx x - x
 CHAROUT   x x - x
 CHARS x x - x
 COMPARE   x x x x
 CONDITION x - - x
 COPIESx x x x
 C2D   x x x x
 C2X   x x x x
 DATATYPE  x x x x
 DATE  x x x x
 DELSTRx x x x
 DELWORD   x x x x
 DIGITSx x x x
 D2C   x x x x
 D2X   x x x x
 ERRORTEXT x x x x
 FORM  x x x x
 FORMATx x x x
 FUZZ  x x x x
 INSERTx x x x
 LASTPOS   x x x x
 LEFT  x x x x
 LENGTHx x x x
 LINEINx x - x
 LINEOUT   x x - x
 LINES x x - x
 MAX   x x x x
 MIN   x x x x
 OVERLAY   x x x x
 POS   x x x x
 QUEUEDx x x x
 RANDOMx x x x
 REVERSE   x x x x
 RIGHT x x x x
 SIGN  x x x x
 SOURCELINEx x x x
 SPACE x x x x
 STREAMx - - x
 STRIP x x x x
 SUBSTRx x x x
 SUBWORD   x x x x
 SYMBOLx x x x
 TIME  x x x x
 TRACE x x x x
 TRANSLATE x x x x
 TRUNC x x x x
 VALUE x x x x
 VERIFYx x x x
 WORD  x x x x
 WORDINDEX x x x x
 WORDLENGTHx x x x
 WORDPOS   x x x x
 WORDS x x x x
 XRANGEx x x x
 X2B   x - - x
 X2C   x x x x
 X2D   x x x x


On 26/04/2020 02:35, Seymour J Metz wrote:
>> After c

Re: Friday OT, cheerful program for gloomy times

[CM Poncelet]

"ON NO VALUE" from memory.
 
"supports the standard Rexx language" as per Mike Cowlishaw's definition
(COW).
 
   Comparison of Built-In Functions

  The following table provides a comparison of Built-In Functions
  for VM/SP CMS REXX (CMS), M.F. Cowlishaw's definition (COW),
  Systems Application Architecture Procedures Language (SAA), and
  CTC REXX.

  Table 3. Comparison of Built-in Functions


 Availability of Built-in Functions

  Function    SAA   COW   CMS   CTC

 ABBREV    x x x x
 ABS   x x x x
 ADDRESS   x x x x
 ARG   x x x x
 BITAND    x x x x
 BITOR x x x x
 BITXOR    x x x x
 B2X   x - - x
 CENTER    x x x x
 CHARIN    x x - x
 CHAROUT   x x - x
 CHARS x x - x
 COMPARE   x x x x
 CONDITION x - - x
 COPIES    x x x x
 C2D   x x x x
 C2X   x x x x
 DATATYPE  x x x x
 DATE  x x x x
 DELSTR    x x x x
 DELWORD   x x x x
 DIGITS    x x x x
 D2C   x x x x
 D2X   x x x x
 ERRORTEXT x x x x
 FORM  x x x x
 FORMAT    x x x x
 FUZZ  x x x x
 INSERT    x x x x
 LASTPOS   x x x x
 LEFT  x x x x
 LENGTH    x x x x
 LINEIN    x x - x
 LINEOUT   x x - x
 LINES x x - x
 MAX   x x x x
 MIN   x x x x
 OVERLAY   x x x x
 POS   x x x x
 QUEUED    x x x x
 RANDOM    x x x x
 REVERSE   x x x x
 RIGHT x x x x
 SIGN  x x x x
 SOURCELINE    x x x x
 SPACE x x x x
 STREAM    x - - x
 STRIP x x x x
 SUBSTR    x x x x
 SUBWORD   x x x x
 SYMBOL    x x x x
 TIME  x x x x
 TRACE x x x x
 TRANSLATE x x x x
 TRUNC x x x x
 VALUE x x x x
 VERIFY    x x x x
 WORD  x x x x
 WORDINDEX x x x x
 WORDLENGTH    x x x x
 WORDPOS   x x x x
 WORDS x x x x
 XRANGE    x x x x
 X2B   x - - x
 X2C   x x x x
 X2D   x x x x


On 26/04/2020 02:35, Seymour J Metz wrote:
>> After commenting out the "SIGNAL ON NO VALUE" 
> "SIGNAL ON NOVALUE" , Shirley.
>
>> SPF/PC Rexx supports the standard Rexx language, 
> Original, but certainly not standard.
>
>> See below for the SPF/PC standard Rexx one.
> DATE('B',foo,'S') is valid in standard Rexx. I don't believe that the first 
> and third parameters are allowed to be longer than 1 character.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> CM Poncelet [ponce...@bcs.org.uk]
> Sent: Saturday, April 25, 2020 7:

Re: Friday OT, cheerful program for gloomy times

[Seymour J Metz]

If you run the code below on oorexx and regina, you will see that they are not 
playing on the same (code) page.

 /* Test whether REXX recognizes all of the logical not characters */
 Nots = '\' 'aa'x 'ac'x
 do 3
parse var Nots Not Nots
say 'Trying' Not c2x(Not)
interpret 'compare = a' Not'= b'
say Not 'recognized'
end



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Joel C. Ewing [jcew...@acm.org]
Sent: Saturday, April 25, 2020 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

Always curious about compatibility issues, copied program and pasted
into gedit on Fedora Linux, put a leading
"#!/usr/bin/rexx"  and tried to run with oorexx on linux. Only code
issues found:
(1)Not really a code issue, but had to to run through dos2unix to
convert Windows CR LF end-of-line to unix LF end of line or don't even
get past the unix shebang 1st line -- can't find program "rexx" with CR
appended to name.
(2)Only special characters allowed in variable names in oorexx are !, ?,
and _, so "#DAYS" is not a valid variable name and produced an error
message about unexpected "#".  Find-replace-all "#DAYS" to "NR_DAYS"

That's all it took to get it to run.

Would be nice if non-standard date format of .mmdd were documented
in leading comments, but if you try enough possibilities it does
eventually tell the expected format.  First assuming mm/dd/, I got
that my birthdate was greater than current date, which implies year must
come first.  After assuming ISO -mm-dd, it did get far enough to
tell the date format expected.

Sobering to find I'm over 27,000 days old.
JC Ewing

On 4/24/20 1:01 AM, CM Poncelet wrote:
> I attach a Rexx program to calculate and display the biorhythm values
> for a given date of birth and current or whatever other date.
>
> If 'management' complains that home workers are not putting enough
> effort into their working-from-home time, they can run this thing and
> send its output to 'management' just to prove that they are in perfect
> working condition and that any slow-down in productivity must be due to
> external factors which are wholly beyond their control .
>
> Cheers, Chris Poncelet (retired sysprog)
>
> ...


--
Joel C. Ewing

--
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: Friday OT, cheerful program for gloomy times

[Seymour J Metz]

> After commenting out the "SIGNAL ON NO VALUE" 

"SIGNAL ON NOVALUE" , Shirley.

> SPF/PC Rexx supports the standard Rexx language, 

Original, but certainly not standard.

> See below for the SPF/PC standard Rexx one.

DATE('B',foo,'S') is valid in standard Rexx. I don't believe that the first and 
third parameters are allowed to be longer than 1 character.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM 
Poncelet [ponce...@bcs.org.uk]
Sent: Saturday, April 25, 2020 7:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday OT, cheerful program for gloomy times

Have you checked that your version works, other than on a mainframe?

After commenting out the "SIGNAL ON NO VALUE" because it produces a
"LABEL NOT FOUND", I ran it and got:

bio2(50): Error #40, Incorrect call to routine
FACTOR1 = DATE( 'Base', YEAR || MONTH || DAY, 'Standard' )

PRESS ANY KEY TO CONTINUE.

SPF/PC Rexx supports the standard Rexx language, but not the full IBM
REXX (which includes EXECIO etc.) and it does not recognise your format
of DATE parms. See below for the SPF/PC standard Rexx one.

  DATE({option})

   Parameter

  option The format to use to return the date.  The options are:

 B  (Basedate) Returns the number of complete days (not
including the current day) since and including the base
date, January 1, 0001, in the format:  dd (no
leading zeros).  The expression "DATE(B)//7" returns a
number in the range 0-6, where 0 is Monday and 6 is
Sunday.

You can use this option to determine the day of the
week independent of the national language in which you
are working.

Note: The origin of January 1, 0001 is based on the
Gregorian calendar.  Though this calendar did not exist
prior to 1582, Basedate is calculated as if it did:
365 days per year, an extra day every four years except
century years, and leap centuries if the century is
divisible by 400.  It does not take into account any
errors in the calendar system that created the Grego-
rian calendar originally.

 C  (Century) Returns the number of days, including the
current day, so far in this century in the format
'd' (no leading zeros or blanks).

 D  (Days) Returns the number of days, including the
current day, so far in this year in the format 'ddd'
(no leading zeros or blanks).

 E  (European) Returns the date in the format 'dd/mm/yy'.

 J  (Julian) Returns the date in the format 'yyddd', where
'ddd' is the number of days so far in the year.

 L  (Language) Returns the date in the format
'dd month yyy'.

 M  (Month) Returns the full name of the current month, in
mixed case.

 N  (Normal) Explicitly returns the date in the default
format 'dd mmm ', as described above.

 O  (Ordered) Returns the date in the format 'yy/mm/dd'
(suitable for sorting).

 S  (Standard) Returns date in the format 'mmdd' (suit-
able for sorting).  This is one of the three forms
recommended in the International Standards Organization
Recommendation ISO/R 2014-1971 (E).  The other two
forms that document recommends can be derived from this
form by separating the month from the year and day
using either blanks or hyphens, for example:'1989 08
27' or '1989-08-27'.

 U  (USA) Returns the date in the format 'mm/dd/yy'.

 W  (Weekday) Returns the day of the week, in mixed case.

Cheers.


On 25/04/2020 22:27, CM Poncelet wrote:
> Nice one. (BTW My version was not "optimised": it worked and that was
> enough.)
>
> Your NUMERIC DIGITS 8 *might* not be sufficient for your "finite
> difference equation to generate table of sines". I used the much slower
> Taylor series for calculating sines, for which NUMERIC DIGITS 100 worked
> "OK" - but without checking whether this could be reduced to 10 or 8.
>
> Cheers.
>
>
> On 25/04/2020 21:51, Paul Gilmartin wrote:
>> On 2020-04-25, at 08:38:08, Joel C. Ewing wrote:
>>> Always curious about compatibility issues, copied program and pasted
>>> into gedit on F

Re: Friday OT, cheerful program for gloomy times

[CM Poncelet]

Have you checked that your version works, other than on a mainframe?
 
After commenting out the "SIGNAL ON NO VALUE" because it produces a
"LABEL NOT FOUND", I ran it and got:
 
bio2(50): Error #40, Incorrect call to routine
FACTOR1 = DATE( 'Base', YEAR || MONTH || DAY, 'Standard' )

PRESS ANY KEY TO CONTINUE.
 
SPF/PC Rexx supports the standard Rexx language, but not the full IBM
REXX (which includes EXECIO etc.) and it does not recognise your format
of DATE parms. See below for the SPF/PC standard Rexx one.
 
  DATE({option})

   Parameter

  option The format to use to return the date.  The options are:

 B  (Basedate) Returns the number of complete days (not
    including the current day) since and including the base
    date, January 1, 0001, in the format:  dd (no
    leading zeros).  The expression "DATE(B)//7" returns a
    number in the range 0-6, where 0 is Monday and 6 is
    Sunday.

    You can use this option to determine the day of the
    week independent of the national language in which you
    are working.

    Note: The origin of January 1, 0001 is based on the
    Gregorian calendar.  Though this calendar did not exist
    prior to 1582, Basedate is calculated as if it did:
    365 days per year, an extra day every four years except
    century years, and leap centuries if the century is
    divisible by 400.  It does not take into account any
    errors in the calendar system that created the Grego-
    rian calendar originally.

 C  (Century) Returns the number of days, including the
    current day, so far in this century in the format
    'd' (no leading zeros or blanks).

 D  (Days) Returns the number of days, including the
    current day, so far in this year in the format 'ddd'
    (no leading zeros or blanks).

 E  (European) Returns the date in the format 'dd/mm/yy'.

 J  (Julian) Returns the date in the format 'yyddd', where
    'ddd' is the number of days so far in the year.

 L  (Language) Returns the date in the format
    'dd month yyy'.

 M  (Month) Returns the full name of the current month, in
    mixed case.

 N  (Normal) Explicitly returns the date in the default
    format 'dd mmm ', as described above.

 O  (Ordered) Returns the date in the format 'yy/mm/dd'
    (suitable for sorting).

 S  (Standard) Returns date in the format 'mmdd' (suit-
    able for sorting).  This is one of the three forms
    recommended in the International Standards Organization
    Recommendation ISO/R 2014-1971 (E).  The other two
    forms that document recommends can be derived from this
    form by separating the month from the year and day
    using either blanks or hyphens, for example:'1989 08
    27' or '1989-08-27'.

 U  (USA) Returns the date in the format 'mm/dd/yy'.

 W  (Weekday) Returns the day of the week, in mixed case.
 
Cheers.


On 25/04/2020 22:27, CM Poncelet wrote:
> Nice one. (BTW My version was not "optimised": it worked and that was
> enough.)
>  
> Your NUMERIC DIGITS 8 *might* not be sufficient for your "finite
> difference equation to generate table of sines". I used the much slower
> Taylor series for calculating sines, for which NUMERIC DIGITS 100 worked
> "OK" - but without checking whether this could be reduced to 10 or 8.
>  
> Cheers.
>  
>
> On 25/04/2020 21:51, Paul Gilmartin wrote:
>> On 2020-04-25, at 08:38:08, Joel C. Ewing wrote:
>>> Always curious about compatibility issues, copied program and pasted
>>> into gedit on Fedora Linux, put a leading
>>> "#!/usr/bin/rexx"  and tried to run with oorexx on linux. Only code
>>> issues found:
>>> (1)Not really a code issue, but had to to run through dos2unix to
>>> convert Windows CR LF end-of-line to unix LF end of line or don't even
>>> get past the unix shebang 1st line -- can't find program "rexx" with CR
>>> appended to name.
>>> (2)Only special characters allowed in variable names in oorexx are !, ?,
>>> and _, so "#DAYS" is not a valid variable name and produced an error
>>> message about unexpected "#".  Find-replace-all "#DAYS" to "NR_DAYS"
>>>
>>> That's all it took to get it to run.
>>>  
>> I did not copy-and-paste; I downloaded the attachment,
>> which appears to be UTF-8.
>>
>> For Regina, Regina.pdf says: 3.1.1.1 Negators
>>     ... Regina supports the following characters as negators:
>>     ...
>>     ¬ Logical Not
>> Copy-and-paste from the pdf gives me:
>>     931 $ printf ¬ | od -tx1
>>     000    c2  ac   
>> ... the UTF-8 "¬".  But when

Re: Friday OT, cheerful program for gloomy times

[CM Poncelet]

Nice one. (BTW My version was not "optimised": it worked and that was
enough.)
 
Your NUMERIC DIGITS 8 *might* not be sufficient for your "finite
difference equation to generate table of sines". I used the much slower
Taylor series for calculating sines, for which NUMERIC DIGITS 100 worked
"OK" - but without checking whether this could be reduced to 10 or 8.
 
Cheers.
 

On 25/04/2020 21:51, Paul Gilmartin wrote:
> On 2020-04-25, at 08:38:08, Joel C. Ewing wrote:
> >
> > Always curious about compatibility issues, copied program and pasted
> > into gedit on Fedora Linux, put a leading
> > "#!/usr/bin/rexx"  and tried to run with oorexx on linux. Only code
> > issues found:
> > (1)Not really a code issue, but had to to run through dos2unix to
> > convert Windows CR LF end-of-line to unix LF end of line or don't even
> > get past the unix shebang 1st line -- can't find program "rexx" with CR
> > appended to name.
> > (2)Only special characters allowed in variable names in oorexx are !, ?,
> > and _, so "#DAYS" is not a valid variable name and produced an error
> > message about unexpected "#".  Find-replace-all "#DAYS" to "NR_DAYS"
> >
> > That's all it took to get it to run.
> > 
> I did not copy-and-paste; I downloaded the attachment,
> which appears to be UTF-8.
>
> For Regina, Regina.pdf says: 3.1.1.1 Negators
>     ... Regina supports the following characters as negators:
>     ...
>     ¬ Logical Not
> Copy-and-paste from the pdf gives me:
>     931 $ printf ¬ | od -tx1
>     000    c2  ac   
> ... the UTF-8 "¬".  But when I paste it into an EXEC, Regina says:
>  say 2+2 ¬= 4
> Error 13 running "/Users/paulgilm/bin/rxx", line 2: Invalid character
> in program
> Error 13.1: Invalid character in program "('c2'X)"
>
> I much prefer when the examples in the Ref. actually work.  Does
> ooRexx accept UTF-8 "¬"?
>
> I went on and did something fancy.  Attached.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> -- gil
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: Friday OT, cheerful program for gloomy times

[Paul Gilmartin]

On 2020-04-25, at 08:38:08, Joel C. Ewing wrote:
> 
> Always curious about compatibility issues, copied program and pasted
> into gedit on Fedora Linux, put a leading
> "#!/usr/bin/rexx"  and tried to run with oorexx on linux. Only code
> issues found:
> (1)Not really a code issue, but had to to run through dos2unix to
> convert Windows CR LF end-of-line to unix LF end of line or don't even
> get past the unix shebang 1st line -- can't find program "rexx" with CR
> appended to name.
> (2)Only special characters allowed in variable names in oorexx are !, ?,
> and _, so "#DAYS" is not a valid variable name and produced an error
> message about unexpected "#".  Find-replace-all "#DAYS" to "NR_DAYS"
> 
> That's all it took to get it to run.
>  
I did not copy-and-paste; I downloaded the attachment,
which appears to be UTF-8.

For Regina, Regina.pdf says: 3.1.1.1 Negators
... Regina supports the following characters as negators:
...
¬ Logical Not
Copy-and-paste from the pdf gives me:
931 $ printf ¬ | od -tx1
000c2  ac
... the UTF-8 "¬".  But when I paste it into an EXEC, Regina says:
 say 2+2 ¬= 4
Error 13 running "/Users/paulgilm/bin/rxx", line 2: Invalid character in program
Error 13.1: Invalid character in program "('c2'X)"

I much prefer when the examples in the Ref. actually work.  Does
ooRexx accept UTF-8 "¬"?

I went on and did something fancy.  Attached.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
/*/
/* Calculate Biorhythm Program   */
/*   */
/* Based on theory that physical, emotional and intellectual cycles  */
/* vary from 1.00 to -1.00 every 23, 28 and 33 days from the date of */
/* birth onwards - where positive scores are "up days" and negative  */
/* scores indicate "down days"   */
/*   */
/* Cycles:   */
/* - Physical : 23 days  */
/* - Emotional: 28 days  */
/* - Intellectual : 33 days  */
/*   */
/* Paramters:*/
/* - DATE1  : date of birth  */
/* - DATE2  : current date   */
/* - DEBUG  : to debug this thing, if required   */
/*   */
/*   */
/* 2020/04/04 Chris Poncelet */
/* 2020/04/25 Paul Gilmartin */
/* - Use ASCII operators */
/* - Use Rexx DATE function  */
/* - Streamline modulo arithmetic*/
/* - Use specialized discrete sin() calculation. */
/*/
SIGNAL ON NOVALUE
ARG DATE1 DATE2 DEBUG

IF ABBREV(DEBUG,'D') = 1 THEN ,
  TRACE I

NUMERIC DIGITS 8  /* mmdd  */

/* CHECK THAT START DATE1 IS EARLIER THAN END DATE DATE2 */
IF DATE2 < DATE1 THEN ,
  DO
  SAY 'Start date 'DATE1' must be no later than end date 'DATE2'.'
  SAY ' '
  SAY 'Please try again.'
  SAY ' '
  CALL EXIT
  END /* IF */

/* CHECK THAT DATE1 DATA IS VALID AND WHETHER LEAP YEAR ETC. */
Q = DATE1
CALL CHECK_DATE

/* CONVERT DATE1 YEARS, MONTHS, DAYS TO FACTOR */
FACTOR1 = DATE( 'Base', YEAR || MONTH || DAY, 'Standard' )

/* CALCULATE DAY OF THE WEEK FOR DATE1 */
DAYS = '(Monday) (Tuesday) (Wednesday) (Thursday) (Friday) (Saturday) (Sunday)'
DW1 = WORD( DAYS, FACTOR1 // 7 + 1 )
SAY 'We have year = 'YEAR', month = 'MONTH', day = 'DAY' 'DW1
SAY ' '

/* CHECK THAT DATE2 DATA IS VALID AND WHETHER LEAP YEAR ETC. */
Q = DATE2
CALL CHECK_DATE

/* CONVERT DATE2 YEARS, MONTHS, DAYS TO FACTOR */
FACTOR2 = DATE( 'Base', YEAR || MONTH || DAY, 'Standard' )

/* CALCULATE DAY OF THE WEEK FOR DATE2 */
DW2 = WORD( DAYS, FACTOR2 // 7 + 1 )
SAY 'We have year = 'YEAR', month = 'MONTH',

Re: Friday OT, cheerful program for gloomy times

[CM Poncelet]

The attachment was in Windoze's "text document" ANSI format. Not sure
what code page that is other than it's the "UK" one (not pure ASCII.)
When I copied the original BIO.ISP to BIO.txt, all the "¬" (ASCII x'AA')
were changed to "ª" in Windoze. So I replaced all the "¬" with "@" in
SPF/PC then, in Windoze, changed all the "@" back to "¬", which then
stayed shown as "¬"; so I attached that.

On 25/04/2020 07:29, Paul Gilmartin wrote:
> On Sat, 25 Apr 2020 03:15:12 +0100, CM Poncelet wrote:
>
>> "¬" (NOT)
>>
> I inferred as much.  What code page was your attachment?
>
>>> On Fri, 24 Apr 2020 07:01:52 +0100, CM Poncelet wrote:
  ...
 CHECK_DATE:
 /* CHECK THAT DATE IS NUMERIC AND IN THE CORRECT FORMAT */
 IF DATATYPE(Q,N) �= 1 ,
 |  DATATYPE(SUBSTR(Q,1,4),W) �= 1 ,
 |  DATATYPE(SUBSTR(Q,6,4),W) �= 1 ,
 |  LENGTH(Q) �= 9 ,
 |  SUBSTR(Q,5,1) �= '.' THEN ,
...
>>> What charset/CCSID is that supposed to be?
>>>
>>> -- gil
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> .
>>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

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

Re: Friday OT, cheerful program for gloomy times

[Paul Gilmartin]

On Sat, 25 Apr 2020 18:10:25 +1000, Wayne Bickerdike wrote:

>Paul asked:
>
> *What code page was your attachment?*
>
>It's US Code page 37.
>
Is that an EBCDIC code page?  The attachment looks more
like ASCII, or UTF-8.

Blame the editor.  TextEdit fails to show the "¬";  BBEdit fails to show the 
"¬";
vi gets it right.  Go figger.  MIME header in the message shows UTF-8,
but doesn't appear in the attachment.
835 $ locale
...
LC_CTYPE="en_US.UTF-8"

>On Sat, Apr 25, 2020 at 4:30 PM Paul Gilmartin wrote:
>
>> On Sat, 25 Apr 2020 03:15:12 +0100, CM Poncelet wrote:
>>
>> >"¬" (NOT)
>> >
>> I inferred as much.  What code page was your attachment?
>>
>> >> On Fri, 24 Apr 2020 07:01:52 +0100, CM Poncelet wrote:
>> >>>  ...
>> >>> CHECK_DATE:
>> >>> /* CHECK THAT DATE IS NUMERIC AND IN THE CORRECT FORMAT */
>> >>> IF DATATYPE(Q,N) �= 1 ,
>> >>> |  DATATYPE(SUBSTR(Q,1,4),W) �= 1 ,
>> >>> |  DATATYPE(SUBSTR(Q,6,4),W) �= 1 ,
>> >>> |  LENGTH(Q) �= 9 ,
>> >>> |  SUBSTR(Q,5,1) �= '.' THEN ,
>> >>>...
>> >> What charset/CCSID is that supposed to be?

-- gil

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

Re: Friday OT, cheerful program for gloomy times

[Joel C. Ewing]

Always curious about compatibility issues, copied program and pasted
into gedit on Fedora Linux, put a leading
"#!/usr/bin/rexx"  and tried to run with oorexx on linux. Only code
issues found:
(1)Not really a code issue, but had to to run through dos2unix to
convert Windows CR LF end-of-line to unix LF end of line or don't even
get past the unix shebang 1st line -- can't find program "rexx" with CR
appended to name.
(2)Only special characters allowed in variable names in oorexx are !, ?,
and _, so "#DAYS" is not a valid variable name and produced an error
message about unexpected "#".  Find-replace-all "#DAYS" to "NR_DAYS"

That's all it took to get it to run.

Would be nice if non-standard date format of .mmdd were documented
in leading comments, but if you try enough possibilities it does
eventually tell the expected format.  First assuming mm/dd/, I got
that my birthdate was greater than current date, which implies year must
come first.  After assuming ISO -mm-dd, it did get far enough to
tell the date format expected. 

Sobering to find I'm over 27,000 days old.
    JC Ewing

On 4/24/20 1:01 AM, CM Poncelet wrote:
> I attach a Rexx program to calculate and display the biorhythm values
> for a given date of birth and current or whatever other date.
>  
> If 'management' complains that home workers are not putting enough
> effort into their working-from-home time, they can run this thing and
> send its output to 'management' just to prove that they are in perfect
> working condition and that any slow-down in productivity must be due to
> external factors which are wholly beyond their control .
>  
> Cheers, Chris Poncelet (retired sysprog)
>
> ...


-- 
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: Friday OT, cheerful program for gloomy times

[Wayne Bickerdike]

Paul asked:

 *What code page was your attachment?*

It's US Code page 37.

On Sat, Apr 25, 2020 at 4:30 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 25 Apr 2020 03:15:12 +0100, CM Poncelet wrote:
>
> >"¬" (NOT)
> >
> I inferred as much.  What code page was your attachment?
>
> >> On Fri, 24 Apr 2020 07:01:52 +0100, CM Poncelet wrote:
> >>>  ...
> >>> CHECK_DATE:
> >>> /* CHECK THAT DATE IS NUMERIC AND IN THE CORRECT FORMAT */
> >>> IF DATATYPE(Q,N) �= 1 ,
> >>> |  DATATYPE(SUBSTR(Q,1,4),W) �= 1 ,
> >>> |  DATATYPE(SUBSTR(Q,6,4),W) �= 1 ,
> >>> |  LENGTH(Q) �= 9 ,
> >>> |  SUBSTR(Q,5,1) �= '.' THEN ,
> >>>...
> >> What charset/CCSID is that supposed to be?
> >>
> >> -- gil
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >> .
> >>
> >
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: Friday OT, cheerful program for gloomy times

[Paul Gilmartin]

On Sat, 25 Apr 2020 03:15:12 +0100, CM Poncelet wrote:

>"¬" (NOT)
> 
I inferred as much.  What code page was your attachment?

>> On Fri, 24 Apr 2020 07:01:52 +0100, CM Poncelet wrote:
>>>  ...
>>> CHECK_DATE:
>>> /* CHECK THAT DATE IS NUMERIC AND IN THE CORRECT FORMAT */
>>> IF DATATYPE(Q,N) �= 1 ,
>>> |  DATATYPE(SUBSTR(Q,1,4),W) �= 1 ,
>>> |  DATATYPE(SUBSTR(Q,6,4),W) �= 1 ,
>>> |  LENGTH(Q) �= 9 ,
>>> |  SUBSTR(Q,5,1) �= '.' THEN ,
>>>...
>> What charset/CCSID is that supposed to be?
>>
>> -- gil
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> .
>>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Friday OT, cheerful program for gloomy times

[Wayne Bickerdike]

My wife's BIO had a better intellectual quotient than mine today, however,
she dragged me to the shops today at 8:30 to beat the lockdown rush. They
don't open until 13:00 because it's ANZAC day here. I knew I should have
stayed in bed.

On Sat, Apr 25, 2020 at 2:26 PM Wayne Bickerdike  wrote:

> Never thought about it,  downloaded to Windoze and it looks like this :
>
> IF DATE2 ¬> DATE1 THEN
>
> CCSID, bah!
>
> On Sat, Apr 25, 2020 at 12:18 PM CM Poncelet  wrote:
>
>> Technical support suggests that you try changing your date of birth, to
>> see whether that fixes the problem.
>>
>> On 25/04/2020 00:16, Wayne Bickerdike wrote:
>> > All negatives for me today. Plus I'm thousands of days old :(
>> >
>> > On Sat, Apr 25, 2020 at 6:21 AM scott Ford  wrote:
>> >
>> >> Nice Chris, at least you have a job, I got furloughed ...
>> >>
>> >>
>> >>
>> >>
>> >> On Fri, Apr 24, 2020 at 2:01 AM CM Poncelet 
>> wrote:
>> >>
>> >>> I attach a Rexx program to calculate and display the biorhythm values
>> >>> for a given date of birth and current or whatever other date.
>> >>>
>> >>> If 'management' complains that home workers are not putting enough
>> >>> effort into their working-from-home time, they can run this thing and
>> >>> send its output to 'management' just to prove that they are in perfect
>> >>> working condition and that any slow-down in productivity must be due
>> to
>> >>> external factors which are wholly beyond their control .
>> >>>
>> >>> Cheers, Chris Poncelet (retired sysprog)
>> >>>
>> >>> --
>> >>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> >>> send email to lists...@listserv.ua.edu with the message: INFO
>> IBM-MAIN
>> >>>
>> >> --
>> >> Scott Ford
>> >> IDMWORKS
>> >> z/OS Development
>> >>
>> >> --
>> >> 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
>>
>
>
> --
> Wayne V. Bickerdike
>
>

-- 
Wayne V. Bickerdike

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

Re: Friday OT, cheerful program for gloomy times

[Wayne Bickerdike]

Never thought about it,  downloaded to Windoze and it looks like this :

IF DATE2 ¬> DATE1 THEN

CCSID, bah!

On Sat, Apr 25, 2020 at 12:18 PM CM Poncelet  wrote:

> Technical support suggests that you try changing your date of birth, to
> see whether that fixes the problem.
>
> On 25/04/2020 00:16, Wayne Bickerdike wrote:
> > All negatives for me today. Plus I'm thousands of days old :(
> >
> > On Sat, Apr 25, 2020 at 6:21 AM scott Ford  wrote:
> >
> >> Nice Chris, at least you have a job, I got furloughed ...
> >>
> >>
> >>
> >>
> >> On Fri, Apr 24, 2020 at 2:01 AM CM Poncelet 
> wrote:
> >>
> >>> I attach a Rexx program to calculate and display the biorhythm values
> >>> for a given date of birth and current or whatever other date.
> >>>
> >>> If 'management' complains that home workers are not putting enough
> >>> effort into their working-from-home time, they can run this thing and
> >>> send its output to 'management' just to prove that they are in perfect
> >>> working condition and that any slow-down in productivity must be due to
> >>> external factors which are wholly beyond their control .
> >>>
> >>> Cheers, Chris Poncelet (retired sysprog)
> >>>
> >>> --
> >>> For IBM-MAIN subscribe / signoff / archive access instructions,
> >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>>
> >> --
> >> Scott Ford
> >> IDMWORKS
> >> z/OS Development
> >>
> >> --
> >> 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
>


-- 
Wayne V. Bickerdike

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

Re: Friday OT, cheerful program for gloomy times

[CM Poncelet]

Technical support suggests that you try changing your date of birth, to
see whether that fixes the problem.

On 25/04/2020 00:16, Wayne Bickerdike wrote:
> All negatives for me today. Plus I'm thousands of days old :(
>
> On Sat, Apr 25, 2020 at 6:21 AM scott Ford  wrote:
>
>> Nice Chris, at least you have a job, I got furloughed ...
>>
>>
>>
>>
>> On Fri, Apr 24, 2020 at 2:01 AM CM Poncelet  wrote:
>>
>>> I attach a Rexx program to calculate and display the biorhythm values
>>> for a given date of birth and current or whatever other date.
>>>
>>> If 'management' complains that home workers are not putting enough
>>> effort into their working-from-home time, they can run this thing and
>>> send its output to 'management' just to prove that they are in perfect
>>> working condition and that any slow-down in productivity must be due to
>>> external factors which are wholly beyond their control .
>>>
>>> Cheers, Chris Poncelet (retired sysprog)
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>> --
>> Scott Ford
>> IDMWORKS
>> z/OS Development
>>
>> --
>> 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: Friday OT, cheerful program for gloomy times

[CM Poncelet]

"¬" (NOT)

On 25/04/2020 02:18, Paul Gilmartin wrote:
> On Fri, 24 Apr 2020 07:01:52 +0100, CM Poncelet wrote:
>
>> I attach a Rexx program to calculate and display the biorhythm values
>> for a given date of birth and current or whatever other date.
>>  
>> If 'management' complains that home workers are not putting enough
>> effort into their working-from-home time, they can run this thing and
>> send its output to 'management' just to prove that they are in perfect
>> working condition and that any slow-down in productivity must be due to
>> external factors which are wholly beyond their control .
>>  ...
>> CHECK_DATE:
>> /* CHECK THAT DATE IS NUMERIC AND IN THE CORRECT FORMAT */
>> IF DATATYPE(Q,N) �= 1 ,
>> |  DATATYPE(SUBSTR(Q,1,4),W) �= 1 ,
>> |  DATATYPE(SUBSTR(Q,6,4),W) �= 1 ,
>> |  LENGTH(Q) �= 9 ,
>> |  SUBSTR(Q,5,1) �= '.' THEN ,
>>...
> What charset/CCSID is that supposed to be?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>


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

Re: Friday OT, cheerful program for gloomy times

[Paul Gilmartin]

On Fri, 24 Apr 2020 07:01:52 +0100, CM Poncelet wrote:

>I attach a Rexx program to calculate and display the biorhythm values
>for a given date of birth and current or whatever other date.
> 
>If 'management' complains that home workers are not putting enough
>effort into their working-from-home time, they can run this thing and
>send its output to 'management' just to prove that they are in perfect
>working condition and that any slow-down in productivity must be due to
>external factors which are wholly beyond their control .
> ...
>CHECK_DATE:
>/* CHECK THAT DATE IS NUMERIC AND IN THE CORRECT FORMAT */
>IF DATATYPE(Q,N) �= 1 ,
>|  DATATYPE(SUBSTR(Q,1,4),W) �= 1 ,
>|  DATATYPE(SUBSTR(Q,6,4),W) �= 1 ,
>|  LENGTH(Q) �= 9 ,
>|  SUBSTR(Q,5,1) �= '.' THEN ,
>...
What charset/CCSID is that supposed to be?

-- gil

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

Re: Friday OT, cheerful program for gloomy times

[Wayne Bickerdike]

Anything with date algorithms floats my boat. Another lot to add to my
list. Thanks!

On Sat, Apr 25, 2020 at 9:16 AM Wayne Bickerdike  wrote:

> All negatives for me today. Plus I'm thousands of days old :(
>
> On Sat, Apr 25, 2020 at 6:21 AM scott Ford  wrote:
>
>> Nice Chris, at least you have a job, I got furloughed ...
>>
>>
>>
>>
>> On Fri, Apr 24, 2020 at 2:01 AM CM Poncelet  wrote:
>>
>> > I attach a Rexx program to calculate and display the biorhythm values
>> > for a given date of birth and current or whatever other date.
>> >
>> > If 'management' complains that home workers are not putting enough
>> > effort into their working-from-home time, they can run this thing and
>> > send its output to 'management' just to prove that they are in perfect
>> > working condition and that any slow-down in productivity must be due to
>> > external factors which are wholly beyond their control .
>> >
>> > Cheers, Chris Poncelet (retired sysprog)
>> >
>> > --
>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> >
>> --
>> Scott Ford
>> IDMWORKS
>> z/OS Development
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
> Wayne V. Bickerdike
>
>

-- 
Wayne V. Bickerdike

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

Re: Friday OT, cheerful program for gloomy times

[Wayne Bickerdike]

All negatives for me today. Plus I'm thousands of days old :(

On Sat, Apr 25, 2020 at 6:21 AM scott Ford  wrote:

> Nice Chris, at least you have a job, I got furloughed ...
>
>
>
>
> On Fri, Apr 24, 2020 at 2:01 AM CM Poncelet  wrote:
>
> > I attach a Rexx program to calculate and display the biorhythm values
> > for a given date of birth and current or whatever other date.
> >
> > If 'management' complains that home workers are not putting enough
> > effort into their working-from-home time, they can run this thing and
> > send its output to 'management' just to prove that they are in perfect
> > working condition and that any slow-down in productivity must be due to
> > external factors which are wholly beyond their control .
> >
> > Cheers, Chris Poncelet (retired sysprog)
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: Friday OT, cheerful program for gloomy times

[scott Ford]

Nice Chris, at least you have a job, I got furloughed ...




On Fri, Apr 24, 2020 at 2:01 AM CM Poncelet  wrote:

> I attach a Rexx program to calculate and display the biorhythm values
> for a given date of birth and current or whatever other date.
>
> If 'management' complains that home workers are not putting enough
> effort into their working-from-home time, they can run this thing and
> send its output to 'management' just to prove that they are in perfect
> working condition and that any slow-down in productivity must be due to
> external factors which are wholly beyond their control .
>
> Cheers, Chris Poncelet (retired sysprog)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Friday OT, cheerful program for gloomy times

[CM Poncelet]

I attach a Rexx program to calculate and display the biorhythm values
for a given date of birth and current or whatever other date.
 
If 'management' complains that home workers are not putting enough
effort into their working-from-home time, they can run this thing and
send its output to 'management' just to prove that they are in perfect
working condition and that any slow-down in productivity must be due to
external factors which are wholly beyond their control .
 
Cheers, Chris Poncelet (retired sysprog)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
/*/
/* Calculate Biorhythm Program   */
/*   */
/* Based on theory that physical, emotional and intellectual cycles  */
/* vary from 1.00 to -1.00 every 23, 28 and 33 days from the date of */
/* birth onwards - where positive scores are "up days" and negative  */
/* scores indicate "down days"   */
/*   */
/* Cycles:   */
/* - Physical : 23 days  */
/* - Emotional: 28 days  */
/* - Intellectual : 33 days  */
/*   */
/* Paramters:*/
/* - DATE1  : date of birth  */
/* - DATE2  : current date   */
/* - DEBUG  : to debug this thing, if required   */
/*   */
/*   */
/* 2020/04/04 Chris Poncelet */
/*/
ARG DATE1 DATE2 DEBUG

IF ABBREV(DEBUG,'D') = 1 THEN ,
  TRACE I

NUMERIC DIGITS 100

/* CHECK THAT START DATE1 IS EARLIER THAN END DATE DATE2 */
IF DATE2 ¬> DATE1 THEN ,
  DO
  SAY 'START DATE 'DATE1' MUST BE EARLIER THAN END DATE 'DATE2'.'
  SAY ' '
  SAY 'PLEASE TRY AGAIN.'
  SAY ' '
  CALL EXIT
  END /* IF */

/* CHECK THAT DATE1 DATA IS VALID AND WHETHER LEAP YEAR ETC. */
Q = DATE1
CALL CHECK_DATE

/* CONVERT DATE1 YEARS, MONTHS, DAYS TO FACTOR */
CALL GET_FACTOR
FACTOR1 = FACTOR

/* CALCULATE DAY OF THE WEEK FOR DATE1 */
DW1 = FACTOR + TRUNC(-FACTOR/7)*7
SELECT
  WHEN DW1 = 0 THEN DW1 = '(SATURDAY)'
  WHEN DW1 = 1 THEN DW1 = '(SUNDAY)'
  WHEN DW1 = 2 THEN DW1 = '(MONDAY)'
  WHEN DW1 = 3 THEN DW1 = '(TUESDAY)'
  WHEN DW1 = 4 THEN DW1 = '(WEDNESDAY)'
  WHEN DW1 = 5 THEN DW1 = '(THURSDAY)'
  WHEN DW1 = 6 THEN DW1 = '(FRIDAY)'
  OTHERWISE NOP
  END /* SELECT */
SAY 'WE HAVE YEAR = 'YEAR', MONTH = 'MONTH', DAY = 'DAY' 'DW1
SAY ' '

/* CHECK THAT DATE2 DATA IS VALID AND WHETHER LEAP YEAR ETC. */
Q = DATE2
CALL CHECK_DATE

/* CONVERT DATE2 YEARS, MONTHS, DAYS TO FACTOR */
CALL GET_FACTOR
FACTOR2 = FACTOR

/* CALCULATE DAY OF THE WEEK FOR DATE2 */
DW2 = FACTOR + TRUNC(-FACTOR/7)*7
SELECT
  WHEN DW2 = 0 THEN DW2 = '(SATURDAY)'
  WHEN DW2 = 1 THEN DW2 = '(SUNDAY)'
  WHEN DW2 = 2 THEN DW2 = '(MONDAY)'
  WHEN DW2 = 3 THEN DW2 = '(TUESDAY)'
  WHEN DW2 = 4 THEN DW2 = '(WEDNESDAY)'
  WHEN DW2 = 5 THEN DW2 = '(THURSDAY)'
  WHEN DW2 = 6 THEN DW2 = '(FRIDAY)'
  OTHERWISE NOP
  END /* SELECT */
SAY 'WE HAVE YEAR = 'YEAR', MONTH = 'MONTH', DAY = 'DAY' 'DW2
SAY ' '


#DAYS = FACTOR2 - FACTOR1
SAY 'ELAPSED NUMBER OF DAYS IS '#DAYS
SAY ' '

/* NOW GET PHYSICAL, EMOTIONAL AND INTELLECTUAL CYCLE SCORES */
Q = #DAYS/23
CALL GET_SINE
P = QS
IF P < 0 THEN ,
  SAY 'PHYSICAL  : 'FORMAT(QS,,2)
ELSE,
  SAY 'PHYSICAL  :  'FORMAT(QS,,2)
SAY ' '

Q = #DAYS/28
CALL GET_SINE
E = QS
IF E < 0 THEN ,
  SAY 'EMOTIONAL : 'FORMAT(QS,,2)
ELSE ,
  SAY 'EMOTIONAL :  'FORMAT(QS,,2)
SAY ' '

Q = #DAYS/33
CALL GET_SINE
I = QS
IF I < 0 THEN ,
  SAY 'INTELLECTUAL  : 'FORMAT(QS,,2)
ELSE ,
  SAY 'INTELLECTUAL  :  'FORMAT(QS,,2)
SAY ' '

AV = (P+E+I)/3
IF AV < 0 THEN ,
  SAY 'AVERAGE   : 'FORMAT(AV,,2)
ELSE ,
  SAY 'AVERAGE   :  'FORMAT(AV,,2)
SAY '

Re: Friday!

[Carmen Vitullo]

:) yup toggle switches, and you had to read the display (lights), interpret, to 
make sure the system was ready to read your card program. 


My senior project was to re write the attendance program in RPG, to print the 
class name from the card input (each class's student had a 5081 card) with the 
student name and class code, I was to list each student that was absent in each 
class, tally the total from each class and the percentage of students absent, 
then a total for the school, Initially I kept a internal table class code to 
class name, that changed quickly when I blew core in the assembly, we had an 
outstanding 8k of storage to work with :) 
the other part of the project was to replicate this program on the 405 
accounting machine's wiring board, for DR purposes ! 
ah school ! 





Carmen Vitullo 

- Original Message -

From: "zMan"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, July 24, 2019 4:58:11 PM 
Subject: Re: Friday! 

You had switches? We had to hard-wire the cores... 

On Mon, Jul 22, 2019 at 11:01 AM Carmen Vitullo  wrote: 

> same here, but on a Univac processor we had in school, all done by 
> switches. 
> 
> 
> Carmen Vitullo 
> 
> - Original Message - 
> 
> From: "Gary Weinhold"  
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Sent: Monday, July 22, 2019 9:49:38 AM 
> Subject: Re: Friday! 
> 
> I almost remember how to do it on an IBM 1620 and had to do it on an 
> Amdahl 470 V6 (in two steps). But it was a machine language routine, 
> but you seem to be referring to perhaps a buit-in function of the 
> hardware. 
> 
> Gary 
> 
> BobL wrote: 
> 
> > Hi All, 
> > 
> > Who remembers how to "ripple core" on a 360/75J? Back in the day, I was 
> taught that it "wrote un-digit zeros" to all storage locations (main + LCS) 
> on the box. If course, an IPL was required after this was done. 
> > 
> > Not sure how widely it was used. A simple yes or no is OK if you cannot 
> provide details. 😊 
> > 
> > Thanks! 
> > BobL 
> 
> 
> 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. 
> 
> 
> 
> -- 
> 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 
> 


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it" 

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