Verifying a PDS

[Jake Anderson]

Hi Group

Is there a utility or a program to verify if PDS is corrupted or not. To
provide me a statistical output whether if any of its control block is
corrupted or not .


Jake.

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

Re: Verifying a PDS

[Vernooij, Kees (ITOP NM) - KLM]

CA-PDSMAN can o.a. analyze a PDS and produce statistics.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: 16 July, 2019 9:32
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Verifying a PDS
> 
> Hi Group
> 
> Is there a utility or a program to verify if PDS is corrupted or not. To
> provide me a statistical output whether if any of its control block is
> corrupted or not .
> 
> 
> Jake.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: Verifying a PDS

[Lionel B Dyck]

Get the PDS command from cbttape.org file 182.  Free and it works great. The 
latest can be found at http://cbttape.org/ftp/updates/CBT182.zip

PDS pds-dsname VER :

If you are trying to verify a PDSE then use the IEBPDSE - a free ISPF dialog to 
drive it can be found here http://lbdsoftware.com./iebpdse.zip


Lionel B. Dyck <
Website: http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Tuesday, July 16, 2019 2:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Verifying a PDS

Hi Group

Is there a utility or a program to verify if PDS is corrupted or not. To 
provide me a statistical output whether if any of its control block is 
corrupted or not .


Jake.

--
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: Verifying a PDS

[Lizette Koehler]

What is your definition of corrupted?  Are you getting IO errors?  Or some 
other issue?

Sometimes a member will have PACK turned on and then functions outside of ISPF 
cannot read it.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Jake Anderson
> Sent: Tuesday, July 16, 2019 12:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Verifying a PDS
> 
> Hi Group
> 
> Is there a utility or a program to verify if PDS is corrupted or not. To
> provide me a statistical output whether if any of its control block is
> corrupted or not .
> 
> 
> Jake.
> 
> --
> 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

Tn3270 + MFA

[Pew, Curtis G]

Our security folks want us to implement some form of two-factor authentication 
for tn3270 access. (Currently, we just require users to be on campus or use our 
VPN; the VPN uses DUO to provide two-factor authentication. But now they want 
two-factor for on campus too.) Has anyone implemented anything like this? Any 
pointers or suggestions?

Thanks.

 
-- 
Pew, Curtis G
curtis@austin.utexas.edu

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

Re: Tn3270 + MFA

[Mark Jacobs]

The two main products that I'm aware of for MFA are IBM's MFA for RACF, and 
Vanguard MFA. At $previoushjob I implemented the Vanguard product using RSA 
SecurID as the MFA factor. Go on their websites and checkout which MFAs they 
support.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, July 16, 2019 10:23 AM, Pew, Curtis G 
 wrote:

> Our security folks want us to implement some form of two-factor 
> authentication for tn3270 access. (Currently, we just require users to be on 
> campus or use our VPN; the VPN uses DUO to provide two-factor authentication. 
> But now they want two-factor for on campus too.) Has anyone implemented 
> anything like this? Any pointers or suggestions?
>
> Thanks.
>
>
> --
>
> Pew, Curtis G
> curtis@austin.utexas.edu
>
> ---
>
> 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: Tn3270 + MFA

[Mike Wawiorko]

Curtis,



Do you mean MFA:

1.   as the TCP connection is made from a client to the tn3270 server (I 
assume you are not talking about OSA-ICC as that would have different issues)

2.   or as an SNA sessions are created to (selected) 3270 applications such 
as TSO, CICS, IMS etc



Mike Wawiorko



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pew, Curtis G
Sent: 16 July 2019 15:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Tn3270 + MFA





This mail originated from outside our organisation - 
curtis@austin.utexas.edu



Our security folks want us to implement some form of two-factor authentication 
for tn3270 access. (Currently, we just require users to be on campus or use our 
VPN; the VPN uses DUO to provide two-factor authentication. But now they want 
two-factor for on campus too.) Has anyone implemented anything like this? Any 
pointers or suggestions?



Thanks.



--

Pew, Curtis G

curtis@austin.utexas.edu



--

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: Tn3270 + MFA

[Pew, Curtis G]

On Jul 16, 2019, at 9:40 AM, Mike Wawiorko 
<014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote:
> 
> 1.   as the TCP connection is made from a client to the tn3270 server (I 
> assume you are not talking about OSA-ICC as that would have different issues)
> 
> 2.   or as an SNA sessions are created to (selected) 3270 applications 
> such as TSO, CICS, IMS etc
> 

I believe either would be acceptable; they just want something beyond simple 
password protection.


-- 
Pew, Curtis G
curtis@austin.utexas.edu

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

Re: Tn3270 + MFA

[Hervey Martinez]

I work for a Bank and MFA was implemented several months ago. It was very 
smooth for the most part.

One of the issues we ran into was our DR exercise, the MFA software did not 
work on the DR recovered system since we usually do some SMS work in the first 
IPL; we had to keep our "old" password active.

Also, we use something called 'out of band'(it is a 'single use'; code) which 
we use when we FTP from plex to another; there is some other code that is used 
for the CICS community but not sure what that is called.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pew, Curtis G
Sent: Tuesday, July 16, 2019 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Tn3270 + MFA

Our security folks want us to implement some form of two-factor authentication 
for tn3270 access. (Currently, we just require users to be on campus or use our 
VPN; the VPN uses DUO to provide two-factor authentication. But now they want 
two-factor for on campus too.) Has anyone implemented anything like this? Any 
pointers or suggestions?

Thanks.

 
--
Pew, Curtis G
curtis@austin.utexas.edu

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

Tool Debug Question

[Joseph Reichman]

Hi

 

I am running a clist which invokes TEST initially testing out an Assembler
program which calls a C program the C program has a call to __ceetest()

 

Seems nothing happens when the call is executed

 

First off I am wondering if the output of debug tool can have the same
destination i.e. SYSTSPRT which is my TSO terminal

 

The Call to the C program doesn't seem to invoke Debug Tool

 

Don't know if the output of debug tool can only go to terminal manager

   

 

thanks

 


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

SMS for tape

[Jesse 1 Robinson]

For the first time ever, we are considering turning on SMS for tape. We've had 
decades of business practice where SMS and tape never intersect. My main 
concern is this: without SMS, a tape data set can be created and used without 
involving any ICF catalog. One 'benefit' of this practice is that multiple 
like-named tape data sets can coexist in the tape library as long a user is 
careful to provide correct volser information. The tape management system must 
support this option. We used CA-1 for years, and now RMM for years. As long as 
the user is careful, uncataloged tape data sets can be handled just fine.

SMS, however, introduces a whole new variable. In general, an SMS data 
set-certainly for DASD-must be cataloged. This precludes duplicate names. I 
don't want to argue the merits of this restriction. The point is that we may 
have countless cases of duplicate names. If they're not a problem within SMS, 
then we're cool. If we have to change business practices to accommodate SMS, we 
have a long and winding road to hoe.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


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

Re: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Seymour J Metz]

One of the things that I liked about Algol was that "=" was always a comparison 
operator; assignment was ":=". But even in PL/I that particular error is 
impossible: the "=" in "IF foo=bar" can never be interpreted as assignment.


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


From: IBM Mainframe Discussion List  on behalf of Tom 
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Monday, July 15, 2019 4:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND 
Parameter)

On Mon, 15 Jul 2019 13:30:51 -0700, Charles Mills wrote:

>Some C programmers are fond of if (7 == foo) rather than the more conventional 
>if (foo == 7) because if one gets in the habit of doing so and then 
>accidentally codes if (7 = foo) one gets a compile error rather than 
>unexpected behavior.
>
>For those not familiar with C, foo == 7 is a relational expression, foo = 7 is 
>an assignment, and if (foo = 7) ... compiles as though one had coded
>
>foo = 7; if (foo != 0) /* which will be true of course */ ...
>
>which is not at all what was presumably intended.
>
>7 = foo is always a compile-time error; you can't assign a variable to a 
>constant.

It's one of the things that I don't like about C.
While you can code if 7 = foo and the compiler will catch your error, there is 
nothing
you can do to protect yourself against the mistake of if foo = bar.

--
Tom Marchant

--
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: JCL COND Parameter

[Seymour J Metz]

I generally code the variable on the left, but then I don't generally use 
unsafe languages like C.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, July 15, 2019 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL COND Parameter

On Mon, 15 Jul 2019 16:51:43 +0100, CM Poncelet wrote:

>If '//STEP000 EXEC PGM=IEFBR14' is commented out, then 'STEPA030' will
>execute with CC=00 instead of NXEQ'd.*
>*
Of course you're right.  I was misled by a strong habit I have.  When coding
tests, I try to put the notional variable on the left; the notional constant on
the right.  I'd code in most other languages:
IF ( CC < 7 )
never:
IF ( 7 > CC )
... but JCL wouldn't allow my habitual:
//STEPA040 EXEC PGM=IEFBR14,COND=(STEP010,LT,7))
or, especially:
//STEPA030 EXEC PGM=IEFBR14,COND=(LT,7)

So I misunderstood:
//STEPA030 EXEC PGM=IEFBR14,COND=(7,GT)
//STEPA040 EXEC PGM=IEFBR14,COND=(7,GT,STEP010)

Where languages allow it, do other programmers generally code
the variable on the left or the right?  I find it jarring to see:
IF ( 7 > CC )
(... but my habits were not formed by the syntax of JCL COND or CLI.)

-- 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: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Bernd Oppolzer]

This double meaning of =, together with the absence of reserved words
makes PL/1 parsing extremely hard. Consider for example

IF (1) = (2);

now what does that mean?

Given a declaration

DCL IF (25) BIN FIXED (31);

that is, if IF is an array of integers, the "IF" statement above is a 
valid assignment
of 2 to the array element 1. The PL/1 compiler does not know that the 
statement
above is no IF statement before it encounters the semicolon; before that 
it has
to consider both possibilities ... this is completely different from 
most other

languages (only Fortran has similar issues).

I always thought that nobody would be as silly as to name his or her 
identifiers IF,

but then I observed a program containing the following:

DCL IA BIN FIXED (15)  /* index for TABA */
DCL IB BIN FIXED (15)  /* index for TABB */
DCL IC BIN FIXED (15)  /* index for TABC */
DCL ID BIN FIXED (15)  /* index for TABD */
DCL IE BIN FIXED (15)  /* index for TABE */
DCL IF BIN FIXED (15)  /* index for TABF */

the coder probably didn't even notice the use of IF as variable name :-))

Long live PL/1 :-)))

Kind regards

Bernd


Am 16.07.2019 um 20:04 schrieb Seymour J Metz:

One of the things that I liked about Algol was that "=" was always a comparison operator; assignment was 
":=". But even in PL/I that particular error is impossible: the "=" in "IF foo=bar" can 
never be interpreted as assignment.


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



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

Re: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Bernd Oppolzer]

and Pascal :-)
Pascal makes the same difference between := (assignment) and = (comparison)
So does C.

BTW: a free Pascal compiler for mainframe targets:
http://bernd-oppolzer.de/job9.htm
https://www.facebook.com/StanfordPascal
https://github.com/StanfordPascal/Pascal
unfortunately only AMODE 24 at the moment.
Feel free to send comments offline :-)

Kind regards

Bernd


Am 16.07.2019 um 20:04 schrieb Seymour J Metz:

One of the things that I liked about Algol was that "=" was always a comparison operator; assignment was 
":=". But even in PL/I that particular error is impossible: the "=" in "IF foo=bar" can 
never be interpreted as assignment.


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


From: IBM Mainframe Discussion List  on behalf of Tom 
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Monday, July 15, 2019 4:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND 
Parameter)

On Mon, 15 Jul 2019 13:30:51 -0700, Charles Mills wrote:


Some C programmers are fond of if (7 == foo) rather than the more conventional 
if (foo == 7) because if one gets in the habit of doing so and then 
accidentally codes if (7 = foo) one gets a compile error rather than unexpected 
behavior.

For those not familiar with C, foo == 7 is a relational expression, foo = 7 is 
an assignment, and if (foo = 7) ... compiles as though one had coded

foo = 7; if (foo != 0) /* which will be true of course */ ...

which is not at all what was presumably intended.

7 = foo is always a compile-time error; you can't assign a variable to a 
constant.

It's one of the things that I don't like about C.
While you can code if 7 = foo and the compiler will catch your error, there is 
nothing
you can do to protect yourself against the mistake of if foo = bar.

--
Tom Marchant

--
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: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Seymour J Metz]

AFAIK a space is not permitted in PL/I between an identifier and the left 
parenthesis for the subscripts. If that is correct then

IF (1) = (2);

can easily be recognized as an IF statement.

Id do, however, agree that it is very bad form to knowingly use a keyword as an 
identifier.


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


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Tuesday, July 16, 2019 2:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND 
Parameter)

This double meaning of =, together with the absence of reserved words
makes PL/1 parsing extremely hard. Consider for example

IF (1) = (2);

now what does that mean?

Given a declaration

DCL IF (25) BIN FIXED (31);

that is, if IF is an array of integers, the "IF" statement above is a
valid assignment
of 2 to the array element 1. The PL/1 compiler does not know that the
statement
above is no IF statement before it encounters the semicolon; before that
it has
to consider both possibilities ... this is completely different from
most other
languages (only Fortran has similar issues).

I always thought that nobody would be as silly as to name his or her
identifiers IF,
but then I observed a program containing the following:

DCL IA BIN FIXED (15)  /* index for TABA */
DCL IB BIN FIXED (15)  /* index for TABB */
DCL IC BIN FIXED (15)  /* index for TABC */
DCL ID BIN FIXED (15)  /* index for TABD */
DCL IE BIN FIXED (15)  /* index for TABE */
DCL IF BIN FIXED (15)  /* index for TABF */

the coder probably didn't even notice the use of IF as variable name :-))

Long live PL/1 :-)))

Kind regards

Bernd


Am 16.07.2019 um 20:04 schrieb Seymour J Metz:
> One of the things that I liked about Algol was that "=" was always a 
> comparison operator; assignment was ":=". But even in PL/I that particular 
> error is impossible: the "=" in "IF foo=bar" can never be interpreted as 
> assignment.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>

--
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: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Seymour J Metz]

> Pascal makes the same difference between := (assignment) and = (comparison)

Pascal is a castrated version of Algol 60,

> So does C.

You're missing  Charles Mills's point; in C it is easy to type "=" where you 
meant "=="; typing ":=" when you meant "=" is much less likely. 

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


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Tuesday, July 16, 2019 2:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND 
Parameter)

and Pascal :-)
Pascal makes the same difference between := (assignment) and = (comparison)
So does C.

BTW: a free Pascal compiler for mainframe targets:
http://secure-web.cisco.com/1d8g6NdaGnJSXOoPGlsW_cuVr7ZvTMNJ5ogRpamvCfkPhwhx9zcEEOPIpkyJVujXTdvtZkWWshMq8mXK79ppXOiSSvBNhUKGV72cmsukk1EySOc-rMN4_N5Ec0hjbOwDth-9lzTMfMO5roFPpPA-jcIoQbH2YwovmfQdaFeeHYhs5NoVlNsET0QMBIt7BynNelS9LDo0NlURN4zCrj4YNgosaQk6qFOlRTBGGClki-jSTcDFbXfwTbkxsPQVwNT5wwyTIcBKCqWsfQShkcZ4lOkDDEzAheIu57CR6AtCNeJLgeN0SyzjibeBWobne-wrta1udZRWF_a0Aw2nd3jw9Lp0DBOgL4Mf9pIauDWcO9XnM0lSuo-Cdjo6k2BGT6lbNmghn_R4tTk6DoEYkcndptrXSpeOQ-aL9h1CXhiVd9Gq82Z61XLLt8lvfZPETWA1f/http%3A%2F%2Fbernd-oppolzer.de%2Fjob9.htm
https://secure-web.cisco.com/1bQnEidc5Dqd3wuG5_Vm65bxLQ3PfeJOp6_TL2osPgyPBaZ5qP_otTJlCsEFuiCpA1so086uAX9SqPMVqqU6_QRH07ar9Ga9PCpBsaMkTk3ujKgRmfljYTWcHo08q_4mA8smsTxpVaHN4qdPKU2HatdrJi1gOfkkn1D_w2036Sy2SQC9bIeXXsDDFvN9HXOVBP_715bN8Qq7EU6dzCow-YheDQURYbjBDdVoqf8g8-yZwxZH0IJqmDawtaRAuuOfx1dSm2FCTRgbfGCDjv_RmpklU5fQKqpbqyq-GbmzcsxToLD4I_0zpH4AVeERO5AXQoyKpNQfETya_lNokM-VA-dT_uzNgYxOL1Vo5Z5Qsev_-j06ahMBJ84YoQx9yYtONUbZNq-6pCJcyS48fPcziZ8CwobnGiUGlwr3C8hF65CvKLe4Xl0jt2hL0zvsy7Vn0/https%3A%2F%2Fwww.facebook.com%2FStanfordPascal
https://secure-web.cisco.com/1H-srYcgPyNO8FskL4JjcZXVkCuKFITGP0xjdhqdYc7TMRGjiJcLuyxUxoewgz6vBi-Hg1Qa43hOB5qRchMLlfqrBgSFU05PBn3hIO1fCVcP__3_1en5VH9i2hiwF7nTSALZcZtsrk8aTPKON-TOG_ODRAyUjfOjSgXB8yHVkXqgvv0sZU9bX7z_Hjflo5wMdJZc75L3BKZyXpLBeE5AaziVtI60jzoVZA1zQJ8ioWMPrEO2-DYGUGznrxwVe6j0M8KVEbl-6sqp8t3o1_59fFLq5m6orzXCBQdQTngav2tKm6aZ28JalAwPLfrRU3xpfIL_fw_nh3EhWxqOrHQoUhPSJtNKY1nPQmNGe1U60U75mcLsBfWc3IeZMLVHRhDHZkT437LAu8pq7OYG89avC-NlnJHAAF2RZt6QSPXKwF7C-2DbWjpNbN6Ms7obl8dDG/https%3A%2F%2Fgithub.com%2FStanfordPascal%2FPascal
unfortunately only AMODE 24 at the moment.
Feel free to send comments offline :-)

Kind regards

Bernd


Am 16.07.2019 um 20:04 schrieb Seymour J Metz:
> One of the things that I liked about Algol was that "=" was always a 
> comparison operator; assignment was ":=". But even in PL/I that particular 
> error is impossible: the "=" in "IF foo=bar" can never be interpreted as 
> assignment.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
> Sent: Monday, July 15, 2019 4:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND 
> Parameter)
>
> On Mon, 15 Jul 2019 13:30:51 -0700, Charles Mills wrote:
>
>> Some C programmers are fond of if (7 == foo) rather than the more 
>> conventional if (foo == 7) because if one gets in the habit of doing so and 
>> then accidentally codes if (7 = foo) one gets a compile error rather than 
>> unexpected behavior.
>>
>> For those not familiar with C, foo == 7 is a relational expression, foo = 7 
>> is an assignment, and if (foo = 7) ... compiles as though one had coded
>>
>> foo = 7; if (foo != 0) /* which will be true of course */ ...
>>
>> which is not at all what was presumably intended.
>>
>> 7 = foo is always a compile-time error; you can't assign a variable to a 
>> constant.
> It's one of the things that I don't like about C.
> While you can code if 7 = foo and the compiler will catch your error, there 
> is nothing
> you can do to protect yourself against the mistake of if foo = bar.
>
> --
> Tom Marchant
>
> --
> 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: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Bernd Oppolzer]

Am 16.07.2019 um 20:40 schrieb Seymour J Metz:

Pascal makes the same difference between := (assignment) and = (comparison)

Pascal is a castrated version of Algol 60,


Hmmm ... the only feature that Pascal lacks IMO is call-by-name,
but this is something not easy to understand (and explain) to today's 
developers

and the value of this concept is questionable.

Pascal has a very rich type concept and is easy to learn and to understand,
and you can write significant programs using it (although it needs some
extensions to the standard to be really useful).


So does C.

You're missing  Charles Mills's point; in C it is easy to type "=" where you meant "=="; typing 
":=" when you meant "=" is much less likely.


Ok, this is indeed dangerous and needs much care, when coding C;

if (x = 5)

changes x to 5 and is always true;

you will only get a warning, if you are compiling with sensible warning 
options.


Kind regards

Bernd

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

Re: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Seymour J Metz]

> Hmmm ... the only feature that Pascal lacks IMO is call-by-name,

Labels in Pascal are more like Fortran than Algol; strictly numeric. Prior to 
the ISO standard, you didn't have conformant array parameters, which made Pasal 
almost useless for handling arrays.

As to call by name, it's extremely useful for, e.g., integration subroutines. 
Of course, it's not needed in languages with procedure parameters.


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


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Tuesday, July 16, 2019 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND 
Parameter)

Am 16.07.2019 um 20:40 schrieb Seymour J Metz:
>> Pascal makes the same difference between := (assignment) and = (comparison)
> Pascal is a castrated version of Algol 60,

Hmmm ... the only feature that Pascal lacks IMO is call-by-name,
but this is something not easy to understand (and explain) to today's
developers
and the value of this concept is questionable.

Pascal has a very rich type concept and is easy to learn and to understand,
and you can write significant programs using it (although it needs some
extensions to the standard to be really useful).

>> So does C.
> You're missing  Charles Mills's point; in C it is easy to type "=" where you 
> meant "=="; typing ":=" when you meant "=" is much less likely.

Ok, this is indeed dangerous and needs much care, when coding C;

if (x = 5)

changes x to 5 and is always true;

you will only get a warning, if you are compiling with sensible warning
options.

Kind regards

Bernd

--
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: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Bernd Oppolzer]

Space is permitted almost everywhere in PL/1,
not in the middle of identifiers (in contrast to FORTRAN).
It is permitted before the left paranthesis of subscripts,
so there is no chance for the compiler to decide before
the semicolon or THEN in this case:

IF (possible index expr1) = (complicated and long expr2); /* valid 
assignment */
IF (possible index expr1) = (complicated and long expr2) THEN ... /* IF 
statement */


This decision has to be done by the Parser, before if knows,
if there is a definition for a IF array. The problem for this
ambiguity is a problem of the PL/1 grammar. Pascal and other
languages avoid this by defining different symbols for
comparison and assignment.

Furthermore: the more modern languages like Pascal, C and Java etc.
forbid the use of reserved symbols as variable names. This may be
restrictive, but makes the compilers much much simpler.

Kind regards

Bernd


Am 16.07.2019 um 20:37 schrieb Seymour J Metz:

AFAIK a space is not permitted in PL/I between an identifier and the left 
parenthesis for the subscripts. If that is correct then

 IF (1) = (2);

can easily be recognized as an IF statement.

Id do, however, agree that it is very bad form to knowingly use a keyword as an 
identifier.


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


From: IBM Mainframe Discussion List  on behalf of Bernd 
Oppolzer 
Sent: Tuesday, July 16, 2019 2:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND 
Parameter)

This double meaning of =, together with the absence of reserved words
makes PL/1 parsing extremely hard. Consider for example

IF (1) = (2);

now what does that mean?

Given a declaration

DCL IF (25) BIN FIXED (31);

that is, if IF is an array of integers, the "IF" statement above is a
valid assignment
of 2 to the array element 1. The PL/1 compiler does not know that the
statement
above is no IF statement before it encounters the semicolon; before that
it has
to consider both possibilities ... this is completely different from
most other
languages (only Fortran has similar issues).

I always thought that nobody would be as silly as to name his or her
identifiers IF,
but then I observed a program containing the following:

DCL IA BIN FIXED (15)  /* index for TABA */
DCL IB BIN FIXED (15)  /* index for TABB */
DCL IC BIN FIXED (15)  /* index for TABC */
DCL ID BIN FIXED (15)  /* index for TABD */
DCL IE BIN FIXED (15)  /* index for TABE */
DCL IF BIN FIXED (15)  /* index for TABF */

the coder probably didn't even notice the use of IF as variable name :-))

Long live PL/1 :-)))

Kind regards

Bernd


Am 16.07.2019 um 20:04 schrieb Seymour J Metz:

One of the things that I liked about Algol was that "=" was always a comparison operator; assignment was 
":=". But even in PL/I that particular error is impossible: the "=" in "IF foo=bar" can 
never be interpreted as assignment.


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


--
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: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Seymour J Metz]

> Furthermore: the more modern languages like Pascal, C and Java etc.
> forbid the use of reserved symbols as variable names. This may be
> restrictive, but makes the compilers much much simpler.

The cardinal sin in language design is to make the compiler simpler at the 
expense of the user. An enhancement to a language with reserved word can render 
a previously valid program invalid. Contrast this with PL/I, where several 
times keywords have been added without affecting existing code.


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


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Tuesday, July 16, 2019 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND 
Parameter)

Space is permitted almost everywhere in PL/1,
not in the middle of identifiers (in contrast to FORTRAN).
It is permitted before the left paranthesis of subscripts,
so there is no chance for the compiler to decide before
the semicolon or THEN in this case:

 IF (possible index expr1) = (complicated and long expr2); /* valid 
assignment */
 IF (possible index expr1) = (complicated and long expr2) THEN ... /* IF 
statement */


This decision has to be done by the Parser, before if knows,
if there is a definition for a IF array. The problem for this
ambiguity is a problem of the PL/1 grammar. Pascal and other
languages avoid this by defining different symbols for
comparison and assignment.

Furthermore: the more modern languages like Pascal, C and Java etc.
forbid the use of reserved symbols as variable names. This may be
restrictive, but makes the compilers much much simpler.

Kind regards

Bernd


Am 16.07.2019 um 20:37 schrieb Seymour J Metz:
> AFAIK a space is not permitted in PL/I between an identifier and the left 
> parenthesis for the subscripts. If that is correct then
>
>  IF (1) = (2);
>
> can easily be recognized as an IF statement.
>
> Id do, however, agree that it is very bad form to knowingly use a keyword as 
> an identifier.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Bernd Oppolzer 
> Sent: Tuesday, July 16, 2019 2:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Where put the notional constant in a condition (Was RE: JCL COND 
> Parameter)
>
> This double meaning of =, together with the absence of reserved words
> makes PL/1 parsing extremely hard. Consider for example
>
> IF (1) = (2);
>
> now what does that mean?
>
> Given a declaration
>
> DCL IF (25) BIN FIXED (31);
>
> that is, if IF is an array of integers, the "IF" statement above is a
> valid assignment
> of 2 to the array element 1. The PL/1 compiler does not know that the
> statement
> above is no IF statement before it encounters the semicolon; before that
> it has
> to consider both possibilities ... this is completely different from
> most other
> languages (only Fortran has similar issues).
>
> I always thought that nobody would be as silly as to name his or her
> identifiers IF,
> but then I observed a program containing the following:
>
> DCL IA BIN FIXED (15)  /* index for TABA */
> DCL IB BIN FIXED (15)  /* index for TABB */
> DCL IC BIN FIXED (15)  /* index for TABC */
> DCL ID BIN FIXED (15)  /* index for TABD */
> DCL IE BIN FIXED (15)  /* index for TABE */
> DCL IF BIN FIXED (15)  /* index for TABF */
>
> the coder probably didn't even notice the use of IF as variable name :-))
>
> Long live PL/1 :-)))
>
> Kind regards
>
> Bernd
>
>
> Am 16.07.2019 um 20:04 schrieb Seymour J Metz:
>> One of the things that I liked about Algol was that "=" was always a 
>> comparison operator; assignment was ":=". But even in PL/I that particular 
>> error is impossible: the "=" in "IF foo=bar" can never be interpreted as 
>> assignment.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
> --
> 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: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Bernd Oppolzer]

Am 16.07.2019 um 21:22 schrieb Seymour J Metz:

Furthermore: the more modern languages like Pascal, C and Java etc.
forbid the use of reserved symbols as variable names. This may be
restrictive, but makes the compilers much much simpler.

The cardinal sin in language design is to make the compiler simpler at the 
expense of the user. An enhancement to a language with reserved word can render 
a previously valid program invalid. Contrast this with PL/I, where several 
times keywords have been added without affecting existing code.


Yes, I agree somehow to that statement ...

since I am working on my version of Stanford Pascal,
I sometimes felt the need for adding new keywords. I always had bad 
feelings

when doing this.

The compiler already had OTHERWISE (but no abbreviation to his, obviously),
EXTERNAL and FORTRAN.

I added BREAK, CONTINUE, RETURN, MODULE, LOCAL and STATIC;
this was in the years from 2011 to 2016. No more need since.

Don't confuse this with adding new builtin function, which is much less 
critical,
because you always can redefine builtin functions (which are considered 
predefined
functions at level 0) with own functions with the same name doing 
different things

and having different prototypes at lower levels.

IMO, new keywords are only OK, if they have a sort of well-known meaning,
inherited from other languages.

A big problem with C, IMO, is that it uses "static" for different 
purposes where

an additional keyword "local" (as I did it) would have been much better.

Kind regards

Bernd



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




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

Re: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Paul Gilmartin]

On Tue, 16 Jul 2019 21:37:38 +0200, Bernd Oppolzer wrote:

>Am 16.07.2019 um 21:22 schrieb Seymour J Metz:
>>> Furthermore: the more modern languages like Pascal, C and Java etc.
>>> forbid the use of reserved symbols as variable names. This may be
>>> restrictive, but makes the compilers much much simpler.
>> The cardinal sin in language design is to make the compiler simpler at the 
>> expense of the user. An enhancement to a language with reserved word can 
>> render a previously valid program invalid. Contrast this with PL/I, where 
>> several times keywords have been added without affecting existing code.
>>
>Yes, I agree somehow to that statement ...
> 
A somewhat complementary sin is to enrich the facilities of the language
to the benefit of the sophisticated user but to the detriment of the naive
user.

I'll add near-ambiguities such as assignment vs. comparison and tricky
semantics of semicolon.  A co-worker once tried removing ";" from the
definition of Pascal and running a meta-parser on the BNF.  The only
further change he needed to make the syntax valid at the same Chomsky
level was to remove the null statement from the language definition.

>since I am working on my version of Stanford Pascal,
>I sometimes felt the need for adding new keywords. I always had bad feelings
>when doing this.
>
>The compiler already had OTHERWISE (but no abbreviation to his, obviously),
>EXTERNAL and FORTRAN.
>
>I added BREAK, CONTINUE, RETURN, MODULE, LOCAL and STATIC;
>this was in the years from 2011 to 2016. No more need since.
> 
I've done many of these as predefined quasi-identifiers, similar to Pascal's
predefined standard types.  A programmer could choose to declare CONTINUE
as an identifier, overriding its predefined meaning within the block containing
the declaration.

I've heard partisans rail that the standard types can be overridden by
local declarations.  If it bothers them, they shouldn't do it.  But I've seen:
TYPE -32768 .. 32767 INTEGER;
to force 16-bit behavior on machines with other word sizes.  I'm
uncomfortable with that.

-- gil

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

Re: Verifying a PDS

[Binyamin Dissen]

On Tue, 16 Jul 2019 11:31:30 +0400 Jake Anderson 
wrote:

:>Is there a utility or a program to verify if PDS is corrupted or not. To
:>provide me a statistical output whether if any of its control block is
:>corrupted or not .

IEBPTPCH PRINT TYPORG=PO

But you have to define your terms.

What are its "control blocks"?

Why do you think that it may be corrupted?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Bernd Oppolzer]

Am 16.07.2019 um 22:16 schrieb Paul Gilmartin:

On Tue, 16 Jul 2019 21:37:38 +0200, Bernd Oppolzer wrote:


Am 16.07.2019 um 21:22 schrieb Seymour J Metz:

Furthermore: the more modern languages like Pascal, C and Java etc.
forbid the use of reserved symbols as variable names. This may be
restrictive, but makes the compilers much much simpler.

The cardinal sin in language design is to make the compiler simpler at the 
expense of the user. An enhancement to a language with reserved word can render 
a previously valid program invalid. Contrast this with PL/I, where several 
times keywords have been added without affecting existing code.


Yes, I agree somehow to that statement ...


A somewhat complementary sin is to enrich the facilities of the language
to the benefit of the sophisticated user but to the detriment of the naive
user.



I have tried to never do this and have all (even the simplest)
Pascal programs stay valid during my extensions.



I'll add near-ambiguities such as assignment vs. comparison and tricky
semantics of semicolon.  A co-worker once tried removing ";" from the
definition of Pascal and running a meta-parser on the BNF.  The only
further change he needed to make the syntax valid at the same Chomsky
level was to remove the null statement from the language definition.



I don't really understand this, but at the same time I'm not sure
if I need to ...



since I am working on my version of Stanford Pascal,
I sometimes felt the need for adding new keywords. I always had bad feelings
when doing this.

The compiler already had OTHERWISE (but no abbreviation to his, obviously),
EXTERNAL and FORTRAN.

I added BREAK, CONTINUE, RETURN, MODULE, LOCAL and STATIC;
this was in the years from 2011 to 2016. No more need since.


I've done many of these as predefined quasi-identifiers, similar to Pascal's
predefined standard types.  A programmer could choose to declare CONTINUE
as an identifier, overriding its predefined meaning within the block containing
the declaration.



would not work with CONTINUE, because CONTINUE in my compiler
is a real reserved word meant for loop control (same as in C, ITERATE in 
PL/1),

and it cannot be overridden by a variable or type definition.

If you have a program that uses CONTINUE as identifier for other things,
you need to do a global change, if you want to use my compiler.

Sorry for that ...




I've heard partisans rail that the standard types can be overridden by
local declarations.  If it bothers them, they shouldn't do it.  But I've seen:
 TYPE -32768 .. 32767 INTEGER;
to force 16-bit behavior on machines with other word sizes.  I'm
uncomfortable with that.



INTEGER in Pascal is no reserved word;
the type INTEGER is a predefined standard type (sort of BUILTIN);
the compiler enters these predefined types, variables and procedures in
a very early stage of processing into the compiler's internal lists.
It is possible to override these standard types (at level 0) by own types
with the same name and different semantics, although sort of dangerous,
because every naive reader of the program would assume the original
standard type (if he or she only sees the variable definition and not the
"special" type definition).

The correct syntax, BTW, would be

type integer = -32768 .. 32767;

some real world examples from my compiler:

type LEVRANGE = 0 .. MAXLEVEL ;
 ADDRRANGE = 0 .. MAXADDR ;
 ALNRNG = 1 .. 8 ;
 LABELRNG = 0 .. 1000 ;
 BKT_RNG = 0 .. MAX_BKT ;
 OPRANGE = 0 .. OPMAX ;

the identifiers on the right side of .. are constants defined elsewhere.

The compiler checks (if desired) if variables of these types have values
inside these ranges and throws exceptions, if not (this has some 
performance

drawbacks, of course, but it makes the programs much more secure).
Same goes for index range checks (bounds checks) etc.

Kind regards

Bernd




-- 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: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Paul Gilmartin]

On Tue, 16 Jul 2019 22:36:43 +0200, Bernd Oppolzer wrote:
>>>
>>> I added BREAK, CONTINUE, RETURN, MODULE, LOCAL and STATIC;
>>> this was in the years from 2011 to 2016. No more need since.
>>>
>> I've done many of these as predefined quasi-identifiers, similar to Pascal's
>> predefined standard types.  A programmer could choose to declare CONTINUE
>> as an identifier, overriding its predefined meaning within the block 
>> containing
>> the declaration.
>
>would not work with CONTINUE, because CONTINUE in my compiler
>is a real reserved word meant for loop control (same as in C, ITERATE in PL/1),
>and it cannot be overridden by a variable or type definition.
>
>If you have a program that uses CONTINUE as identifier for other things,
>you need to do a global change, if you want to use my compiler.
> 
Ah, but that's in your compiler.  In "my" (actually my employer's) compiler,
we started from another (almost) free compiler having almost no extensions
beyond the IEEE standard.  I made CONTINUE an identifier with the peculiar
semantic in order not to break standard programs.

>The correct syntax, BTW, would be
>type integer = -32768 .. 32767;
>
Thanks.  It's been a long time.

-- gil

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

Re: Where put the notional constant in a condition (Was RE: JCL COND Parameter)

[Edward Finnell]

https://en.wikipedia.org/wiki/Pascal_MicroEngine

In a message dated 7/16/2019 6:02:25 PM Central Standard Time, 
bernd.oppol...@t-online.de writes:
and Pascal :-)
Pascal makes the same difference between := (assignment) and = (comparison)
So does C.

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

Re: Tn3270 + MFA

[Mike Hochee]

I have not personally used it, only read about it, but the RACF PWFALLBACK 
option in a user's MFA segment is feature that might be quite helpful during 
implementation/testing.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hervey Martinez
Sent: Tuesday, July 16, 2019 11:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Tn3270 + MFA

I work for a Bank and MFA was implemented several months ago. It was very 
smooth for the most part.

One of the issues we ran into was our DR exercise, the MFA software did not 
work on the DR recovered system since we usually do some SMS work in the first 
IPL; we had to keep our "old" password active.

Also, we use something called 'out of band'(it is a 'single use'; code) which 
we use when we FTP from plex to another; there is some other code that is used 
for the CICS community but not sure what that is called.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pew, Curtis G
Sent: Tuesday, July 16, 2019 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Tn3270 + MFA

Our security folks want us to implement some form of two-factor authentication 
for tn3270 access. (Currently, we just require users to be on campus or use our 
VPN; the VPN uses DUO to provide two-factor authentication. But now they want 
two-factor for on campus too.) Has anyone implemented anything like this? Any 
pointers or suggestions?

Thanks.

 
--
Pew, Curtis G
curtis@austin.utexas.edu

--
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: SMS for tape

[Vernooij, Kees (ITOP NM) - KLM]

AFAIK, SMS managing tapes is much simpler than dasd. 
The only thing SMS really does is to assign a DC, SC, MC and SG to a tape in 
the ACS routines and these constructs are passed to the tape library, which 
does its thing with them. 
We don't have uncatalogued tapes, but I am quite sure they can be.

What is the reason that you must go to SMS managed tape?

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: 16 July, 2019 18:28
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMS for tape
> 
> For the first time ever, we are considering turning on SMS for tape. We've
> had decades of business practice where SMS and tape never intersect. My
> main concern is this: without SMS, a tape data set can be created and used
> without involving any ICF catalog. One 'benefit' of this practice is that
> multiple like-named tape data sets can coexist in the tape library as long
> a user is careful to provide correct volser information. The tape
> management system must support this option. We used CA-1 for years, and
> now RMM for years. As long as the user is careful, uncataloged tape data
> sets can be handled just fine.
> 
> SMS, however, introduces a whole new variable. In general, an SMS data
> set-certainly for DASD-must be cataloged. This precludes duplicate names.
> I don't want to argue the merits of this restriction. The point is that we
> may have countless cases of duplicate names. If they're not a problem
> within SMS, then we're cool. If we have to change business practices to
> accommodate SMS, we have a long and winding road to hoe.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office <= NEW
> robin...@sce.com
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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