Re: EBCDIC-ASCII converter and other tools

[Frank Swarbrick]

I don't make much use of PowerShell either, and love Windows Subsystem for 
Linux.  But PS, verbose or not, does seem quite powerful.


From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Tuesday, December 29, 2020 11:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: EBCDIC-ASCII converter and other tools

I'm using PowerShell 7.2. I don't use PowerShell all that often but when
I do I'm blown away by it's power and turned off by it's verbosity. I
tend to stick to bash CLI scripts
and Python these days and my beloved Lua for embedded scripting. Ever
since Windows got a Linux subsystem I spend all my time in a bash shell :)

On 30/12/2020 2:09 am, Frank Swarbrick wrote:
> It doesn't look like Windows 10 included PowerShell supports EBCDIC, but the 
> open source version, PowerShell 7.1 does.
>
> PS C:\Users\fswar> Format-Hex 1047.txt
>
> Label: C:\Users\fswar\1047.txt
>
>Offset Bytes   Ascii
>   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
>-- --- -
>  F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 40ðñòóôõö÷øù@
>
> PS C:\Users\fswar> Get-Content 1047.txt -encoding 1047 | Out-File out.txt 
> -encoding ascii -nonewline
> PS C:\Users\fswar> Format-Hex out.txt
>
> Label: C:\Users\fswar\out.txt
>
>Offset Bytes   Ascii
>   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
>-- --- -
>  30 31 32 33 34 35 36 37 38 39 200123456789
>
>
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Crayford 
> Sent: Tuesday, December 29, 2020 10:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: EBCDIC-ASCII converter and other tools
>
> On 30/12/2020 1:12 am, R.S. wrote:
>> This is even simpler tool, maybe it address rare need - just to
>> truncate first nnn bytes from beginning of file
>> Possible usage:
>> truncfile -header -12384 ifile ofile
>> truncates/deletes header, which is 12384 bytes long, the output is
>> written to ofile. Ofile is shorter than ifile, the difference is 12384
>> bytes. No CR/LF issues, just byte after byte.
>
> On Windows install you can WSL and use Linux tools. Or use Powershell
> and do something similar. I don't use Powershell that often and have to
> study to find a bash analog but it's simple using Linux.
>
> tail -c +12385 ifile | iconv -f ibm-1047 -t utf-8 >> ofile
>
> --
> 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: EBCDIC-ASCII converter and other tools

[Frank Swarbrick]

It doesn't look like Windows 10 included PowerShell supports EBCDIC, but the 
open source version, PowerShell 7.1 does.

PS C:\Users\fswar> Format-Hex 1047.txt

   Label: C:\Users\fswar\1047.txt

  Offset Bytes   Ascii
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
  -- --- -
 F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 40ðñòóôõö÷øù@

PS C:\Users\fswar> Get-Content 1047.txt -encoding 1047 | Out-File out.txt 
-encoding ascii -nonewline
PS C:\Users\fswar> Format-Hex out.txt

   Label: C:\Users\fswar\out.txt

  Offset Bytes   Ascii
 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
  -- --- -
 30 31 32 33 34 35 36 37 38 39 200123456789




From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Tuesday, December 29, 2020 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: EBCDIC-ASCII converter and other tools

On 30/12/2020 1:12 am, R.S. wrote:
> This is even simpler tool, maybe it address rare need - just to
> truncate first nnn bytes from beginning of file
> Possible usage:
> truncfile -header -12384 ifile ofile
> truncates/deletes header, which is 12384 bytes long, the output is
> written to ofile. Ofile is shorter than ifile, the difference is 12384
> bytes. No CR/LF issues, just byte after byte.


On Windows install you can WSL and use Linux tools. Or use Powershell
and do something similar. I don't use Powershell that often and have to
study to find a bash analog but it's simple using Linux.

tail -c +12385 ifile | iconv -f ibm-1047 -t utf-8 >> ofile

--
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: COBOL LIB

[Frank Swarbrick]

If you don't have COBOL developers in house it seems unlikely you would have 
purchased the COBOL compiler.
Can't the vendor supply you with binary executables that they have compiled?


From: IBM Mainframe Discussion List  on behalf of 
CarlosM Martinez 
Sent: Thursday, December 17, 2020 5:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL LIB

Just looking for the BATCH compiler for the VENDOR... If we have it.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, December 17, 2020 6:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL LIB

What you could do is use

ISRDDN
Once you get the new panel, enter LINKLIST
Then on the command line enter IGY*

If you have authority to the Linklist datasets, you should see where those 
modules exist

If you have a vendor providing you with the modules for your CICS system.  What 
issue are you trying to solve?


Lizette


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Thursday, December 17, 2020 4:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL LIB

IBM has an easytrieve replacement that does that.

On Thu, Dec 17, 2020 at 4:27 PM CarlosM Martinez  wrote:
>
> Well I am a newbie in Z/OS my expertise is in VSE. But... everything here is 
> hold on to your hat... EASYTRIEVE. I have not look at a complete Easytrieve 
> compile but doesn't it produce cobol code?
> We get our CICS online System compiled and shipped from a vendor and just 
> load it to a loadlib. I looked on 3.4 of TSO for IGY and found NONE.
>
> Thank you all.
>
> Carlos Martinez
> SUNY Downstate.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Steve Beaver
> Sent: Thursday, December 17, 2020 5:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL LIB
>
> Do you even have any compiler procs?
>
> Sent from my iPhone
>
> > On Dec 17, 2020, at 16:02, Jousma, David 
> > <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > COBOL compiler doesn't come with z/os.  It is separately purchased and 
> > licensed,  so since you are asking, you may not have it.
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of CarlosM Martinez 
> > Sent: Thursday, December 17, 2020 4:12:28 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: COBOL LIB
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > Hello all,
> > Does anyone know what library the COBOL compiler is in Z/OS 1.0 ?
> > SYS1.???
> >
> > Thank you
> > Carlos Martinez
> > SUNY Downstate Med. Center
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO
> > IBM-MAIN **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> >
> > ${If.App.WXP}Classification: Internal Use${If.End} This e-mail
> > transmission contains information that is confidential and may be 
> > privileged.
> > It is intended only for the addressee(s) named above. If you receive
> > this e-mail in error, please do not read, copy or disseminate it in
> > any manner.  If you are not the intended recipient, any disclosure,
> > copying, distribution or use of the contents of
> --
> 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



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

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

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

Security and z/OS open source tools

[Frank Swarbrick]

I have downloaded and installed in my personal z/OS Unix directory curl and a 
few other z/OpenSource tools from Rocket Software.  I have asked my z/OS 
security guy if we can go ahead and have our systems group (outsourced to IBM 
zCloud) "officially" install them.  He came back with the following:  "My 
question is how do we approve, track and secure the open source code we are 
putting on z/OS?"

Does anyone have suggestions on answering this concern?

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

Re: [MVS-OE] Other user trying to run my shell script gets "FSUM7351 not found" error

[Frank Swarbrick]

Hmm...  I can't recreate any case where I can run another user's program 
without the full path having both r and x (didn't try it without r), regardless 
of it being executed with just the full path or from a script with the full 
path.  I must have done something that I don't recall.  Oh well.  It makes 
sense that it wouldn't work one way but not the other.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, November 18, 2020 1:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: [MVS-OE] Other user trying to run my shell script gets "FSUM7351 
not found" error

On 2020-11-18, at 10:16:41, Frank Swarbrick wrote:
>
> Can you explain the difference between executing a script that executes the 
> program, which requires this, while running the program directly (with a 
> fully qualified path) does not?
>
I can hardly imagine a case where a program with a non-searchable
directory in its path can be "[run] directly (with a fully qualified
path)" but not from "a script that executes the program."  Does the
script also use a fully qualified path?

I'm skeptical without seeing a detailed example such as:

myscript:
#! /bin/sh -x
/u/dvfjs/rocket/bin/curl

chmod a-x /u/dvfjs/rocket/bin
ls -lid /u/dvfjs/rocket/bin/curl # should get permission denied.

cat myscript
chmod a+rx myscript
ls -lid myscript
./myscript# should get permission denied.

# while:
/u/dvfjs/rocket/bin/curl # should likewise get permission denied.

# If it succeeds it's because the z/OS kernel breaks
# (more precisely fails to enforce) the rules.
# That should be subject to APAR.

> 
> From: Kirk Wolf
> Sent: Wednesday, November 18, 2020 10:13 AM
>
> You need directory search (x) permission for every directory in the path in
> order to access a file or subdirectory with a known name.
>
> So in your example, the user must have search (x) permission on all of
> these:
>
> /u
> /u/dvfjs
> /u/dvfjs/rocket
> /u/dvfjs/rocket/bin

-- 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: [MVS-OE] [External] Re: [MVS-OE] Other user trying to run my shell script gets "FSUM7351 not found" error

[Frank Swarbrick]

Yep. Thanks.

Can you explain the difference between executing a script that executes the 
program, which requires this, while running the program directly (with a fully 
qualified path) does not?


From: IBM Mainframe Discussion List  on behalf of 
Kirk Wolf 
Sent: Wednesday, November 18, 2020 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: [MVS-OE] [External] Re: [MVS-OE] Other user trying to run my shell 
script gets "FSUM7351 not found" error

You need directory search (x) permission for every directory in the path in
order to access a file or subdirectory with a known name.

So in your example, the user must have search (x) permission on all of
these:

/u
/u/dvfjs
/u/dvfjs/rocket
/u/dvfjs/rocket/bin

Kirk Wolf

On Tue, Nov 17, 2020 at 3:25 PM Frank Swarbrick 
wrote:

> OK, issue resolved.  I not only had to set the read and execute bits on
> the program itself (curl), but also on the entire directory path.  Not sure
> what the difference is in regard to executing the program directly vs
> inside a script, but hey.
>
> 
> From: MVS OpenEdition  on behalf of Pommier, Rex <
> rpomm...@sfgmembers.com>
> Sent: Tuesday, November 17, 2020 12:47 PM
> To: mvs...@vm.marist.edu 
> Subject: Re: [MVS-OE] [External] Re: [MVS-OE] Other user trying to run my
> shell script gets "FSUM7351 not found" error
>
> Except Frank said the other user could run curl directly, just not if he
> was using Frank's script.
>
> -Original Message-
> From: MVS OpenEdition  On Behalf Of Kirk Wolf
> Sent: Tuesday, November 17, 2020 1:10 PM
> To: mvs...@vm.marist.edu
> Subject: [External] Re: [MVS-OE] Other user trying to run my shell script
> gets "FSUM7351 not found" error
>
> Perhaps the user doesn't have read/search/execute permissions to the full
> directory path of /u/dvfjs/rocket/bin/curl  ?
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
>
> On Mon, Nov 16, 2020 at 12:51 PM Frank Swarbrick <
> frank.swarbr...@outlook.com> wrote:
>
> > Any thoughts on this?  I can execute this job and have no issue.  I'm
> > trying to let another developer run it.  He's able to run
> > /u/dvfjs/rocket/bin/curl directly (in STDPARM, following "SH ".)  But
> > if he executes my shell script (/u/dvfjs/jira_test) he gets
> > "/u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4: FSUM7351 not found".
> >
> > I've set the read and execution bits for user, group and other for
> > both curl and the jira_test shell script.  Since the "echo" commands
> > are working for him, he's obviously able to execute my shell script
> > itself.  What else might I be missing?  The other developer has an
> > OMVS segment, but he doesn't have an initial working directory or
> default shell configured yet.
> > Could that be the issue?  If so, what specifically is causing this
> > particular issue?
> >
> > JCL:
> > //DVRJZTST JOB ,'Test',CLASS=C,REGION=0M,NOTIFY=
> > //*
> > //UNIX EXEC PGM=BPXBATCH
> > //STDOUT   DD SYSOUT=*
> > //STDERR   DD SYSOUT=*
> > //STDPARM  DD *
> > SH /u/dvfjs/jira_test
> > /*
> >
> > /u/dvfjs/jira_test:
> > #!/bin/sh -x
> >
> > echo **before**
> > /u/dvfjs/rocket/bin/curl --help
> > echo **after**
> >
> > File attributes:
> > -sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/jira_test
> > - untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971  77 Nov 16
> > 12:24 /u/dvfjs/jira_test
> > -sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/rocket/bin/curl
> > - untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971 21266432 Nov
> > 1  2019 /u/dvfjs/rocket/bin/curl
> >
> > STDERR:
> > FSUM1012 The initial working directory was not specified.
> > FSUM1006 A shell was not specified. Processing continues using the
> > default shell name.
> > + echo **before**
> > + /u/dvfjs/rocket/bin/curl --help
> > /u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4:
> > + echo **after**
> >
> > STDOUT:
> > **before**
> > **after**
> >
> >
> >
> > --
> > For MVS-OE subscribe / signoff / archive access instructions, send
> > email to lists...@vm.marist.edu with the message: INFO MVS-OE
> >
>
> --
> For MVS-OE subscribe / signoff / archive access instructions, send email
> to lists...@vm.marist.edu with the message: INFO MVS-OE
>
>
> The information contained in this message is confidential, protected from
> disclo

Re: [MVS-OE] [External] Re: [MVS-OE] Other user trying to run my shell script gets "FSUM7351 not found" error

[Frank Swarbrick]

Unknown, since I tested it only with both bits set.


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Wednesday, November 18, 2020 6:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: [MVS-OE] [External] Re: [MVS-OE] Other user trying to run my shell 
script gets "FSUM7351 not found" error

Did you need the read bit on the entire path, or only the execute bit?


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



From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Tuesday, November 17, 2020 4:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] [External] Re: [MVS-OE] Other user trying to run my shell 
script gets "FSUM7351 not found" error

OK, issue resolved.  I not only had to set the read and execute bits on the 
program itself (curl), but also on the entire directory path.  Not sure what 
the difference is in regard to executing the program directly vs inside a 
script, but hey.


From: MVS OpenEdition  on behalf of Pommier, Rex 

Sent: Tuesday, November 17, 2020 12:47 PM
To: mvs...@vm.marist.edu 
Subject: Re: [MVS-OE] [External] Re: [MVS-OE] Other user trying to run my shell 
script gets "FSUM7351 not found" error

Except Frank said the other user could run curl directly, just not if he was 
using Frank's script.

-Original Message-
From: MVS OpenEdition  On Behalf Of Kirk Wolf
Sent: Tuesday, November 17, 2020 1:10 PM
To: mvs...@vm.marist.edu
Subject: [External] Re: [MVS-OE] Other user trying to run my shell script gets 
"FSUM7351 not found" error

Perhaps the user doesn't have read/search/execute permissions to the full 
directory path of /u/dvfjs/rocket/bin/curl  ?

Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/1lyBFXiveOds6XamK3ZgQmj8A7-ybpz8sz21wX2PPg7b0fQfZiVzOAq2aIdMQt2YtbZW3F9lFUYCwahSfc9lZA4FEjMRfIaLAZIyh3zjGSyeG5OMziI3LEmko0rELjoIMRGE-MnAy7zdVyShSCjTbphBNHy7qaHA3zDOloSe-CPHx3jiiMkbRWkTy3cxRxsBHN8oK2CUOeLKuBq_3IxW3umtjD7E16Vz35v3Hhhl2w68ihmgf6F_6F2FExu4nsrr46vy0S1bW3aygSIy85l1rTEy5U3YbJMsLPAOpReHzePb64_uuTeEuOmbitquoOOvi3n-7p7dpkQLeRhgiiVU9PldzauUpBNexw4c6eIRBAylqA7UGeebw5bo9yjVopq4u0rojPakPp1WGt7IJah0e-PhbnEZ1FOMY4oBKeLQxrJGt5tFfsoWJlRed6rHFV87K/http%3A%2F%2Fdovetail.com


On Mon, Nov 16, 2020 at 12:51 PM Frank Swarbrick < frank.swarbr...@outlook.com> 
wrote:

> Any thoughts on this?  I can execute this job and have no issue.  I'm
> trying to let another developer run it.  He's able to run
> /u/dvfjs/rocket/bin/curl directly (in STDPARM, following "SH ".)  But
> if he executes my shell script (/u/dvfjs/jira_test) he gets
> "/u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4: FSUM7351 not found".
>
> I've set the read and execution bits for user, group and other for
> both curl and the jira_test shell script.  Since the "echo" commands
> are working for him, he's obviously able to execute my shell script
> itself.  What else might I be missing?  The other developer has an
> OMVS segment, but he doesn't have an initial working directory or default 
> shell configured yet.
> Could that be the issue?  If so, what specifically is causing this
> particular issue?
>
> JCL:
> //DVRJZTST JOB ,'Test',CLASS=C,REGION=0M,NOTIFY=
> //*
> //UNIX EXEC PGM=BPXBATCH
> //STDOUT   DD SYSOUT=*
> //STDERR   DD SYSOUT=*
> //STDPARM  DD *
> SH /u/dvfjs/jira_test
> /*
>
> /u/dvfjs/jira_test:
> #!/bin/sh -x
>
> echo **before**
> /u/dvfjs/rocket/bin/curl --help
> echo **after**
>
> File attributes:
> -sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/jira_test
> - untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971  77 Nov 16
> 12:24 /u/dvfjs/jira_test
> -sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/rocket/bin/curl
> - untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971 21266432 Nov
> 1  2019 /u/dvfjs/rocket/bin/curl
>
> STDERR:
> FSUM1012 The initial working directory was not specified.
> FSUM1006 A shell was not specified. Processing continues using the
> default shell name.
> + echo **before**
> + /u/dvfjs/rocket/bin/curl --help
> /u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4:
> + echo **after**
>
> STDOUT:
> **before**
> **after**
>
>
>
> --
> For MVS-OE subscribe / signoff / archive access instructions, send
> email to lists...@vm.marist.edu with the message: INFO MVS-OE
>

--
For MVS-OE subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO MVS-OE


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reade

Re: [MVS-OE] [External] Re: [MVS-OE] Other user trying to run my shell script gets "FSUM7351 not found" error

[Frank Swarbrick]

OK, issue resolved.  I not only had to set the read and execute bits on the 
program itself (curl), but also on the entire directory path.  Not sure what 
the difference is in regard to executing the program directly vs inside a 
script, but hey.


From: MVS OpenEdition  on behalf of Pommier, Rex 

Sent: Tuesday, November 17, 2020 12:47 PM
To: mvs...@vm.marist.edu 
Subject: Re: [MVS-OE] [External] Re: [MVS-OE] Other user trying to run my shell 
script gets "FSUM7351 not found" error

Except Frank said the other user could run curl directly, just not if he was 
using Frank's script.

-Original Message-
From: MVS OpenEdition  On Behalf Of Kirk Wolf
Sent: Tuesday, November 17, 2020 1:10 PM
To: mvs...@vm.marist.edu
Subject: [External] Re: [MVS-OE] Other user trying to run my shell script gets 
"FSUM7351 not found" error

Perhaps the user doesn't have read/search/execute permissions to the full 
directory path of /u/dvfjs/rocket/bin/curl  ?

Kirk Wolf
Dovetailed Technologies
http://dovetail.com


On Mon, Nov 16, 2020 at 12:51 PM Frank Swarbrick < frank.swarbr...@outlook.com> 
wrote:

> Any thoughts on this?  I can execute this job and have no issue.  I'm
> trying to let another developer run it.  He's able to run
> /u/dvfjs/rocket/bin/curl directly (in STDPARM, following "SH ".)  But
> if he executes my shell script (/u/dvfjs/jira_test) he gets
> "/u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4: FSUM7351 not found".
>
> I've set the read and execution bits for user, group and other for
> both curl and the jira_test shell script.  Since the "echo" commands
> are working for him, he's obviously able to execute my shell script
> itself.  What else might I be missing?  The other developer has an
> OMVS segment, but he doesn't have an initial working directory or default 
> shell configured yet.
> Could that be the issue?  If so, what specifically is causing this
> particular issue?
>
> JCL:
> //DVRJZTST JOB ,'Test',CLASS=C,REGION=0M,NOTIFY=
> //*
> //UNIX EXEC PGM=BPXBATCH
> //STDOUT   DD SYSOUT=*
> //STDERR   DD SYSOUT=*
> //STDPARM  DD *
> SH /u/dvfjs/jira_test
> /*
>
> /u/dvfjs/jira_test:
> #!/bin/sh -x
>
> echo **before**
> /u/dvfjs/rocket/bin/curl --help
> echo **after**
>
> File attributes:
> -sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/jira_test
> - untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971  77 Nov 16
> 12:24 /u/dvfjs/jira_test
> -sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/rocket/bin/curl
> - untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971 21266432 Nov
> 1  2019 /u/dvfjs/rocket/bin/curl
>
> STDERR:
> FSUM1012 The initial working directory was not specified.
> FSUM1006 A shell was not specified. Processing continues using the
> default shell name.
> + echo **before**
> + /u/dvfjs/rocket/bin/curl --help
> /u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4:
> + echo **after**
>
> STDOUT:
> **before**
> **after**
>
>
>
> --
> For MVS-OE subscribe / signoff / archive access instructions, send
> email to lists...@vm.marist.edu with the message: INFO MVS-OE
>

--
For MVS-OE subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO MVS-OE


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For MVS-OE subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO MVS-OE

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

Re: Other user trying to run my shell script gets "FSUM7351 not found" error

[Frank Swarbrick]

Why would PATH have any effect here, since I have the fully qualified path 
specified?


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Tuesday, November 17, 2020 6:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Other user trying to run my shell script gets "FSUM7351 not found" 
error

That sounds like PATH is different in the two cases.


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



From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Monday, November 16, 2020 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Other user trying to run my shell script gets "FSUM7351 not found" 
error

Any thoughts on this?  I can execute this job and have no issue.  I'm trying to 
let another developer run it.  He's able to run /u/dvfjs/rocket/bin/curl 
directly (in STDPARM, following "SH ".)  But if he executes my shell script 
(/u/dvfjs/jira_test) he gets "/u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4: 
FSUM7351 not found".

I've set the read and execution bits for user, group and other for both curl 
and the jira_test shell script.  Since the "echo" commands are working for him, 
he's obviously able to execute my shell script itself.  What else might I be 
missing?  The other developer has an OMVS segment, but he doesn't have an 
initial working directory or default shell configured yet.  Could that be the 
issue?  If so, what specifically is causing this particular issue?

JCL:
//DVRJZTST JOB ,'Test',CLASS=C,REGION=0M,NOTIFY=
//*
//UNIX EXEC PGM=BPXBATCH
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*
//STDPARM  DD *
SH /u/dvfjs/jira_test
/*

/u/dvfjs/jira_test:
#!/bin/sh -x

echo **before**
/u/dvfjs/rocket/bin/curl --help
echo **after**

File attributes:
-sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/jira_test
- untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971  77 Nov 16 12:24 
/u/dvfjs/jira_test
-sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/rocket/bin/curl
- untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971 21266432 Nov  1  
2019 /u/dvfjs/rocket/bin/curl

STDERR:
FSUM1012 The initial working directory was not specified.
FSUM1006 A shell was not specified. Processing continues using the default 
shell name.
+ echo **before**
+ /u/dvfjs/rocket/bin/curl --help
/u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4:
+ echo **after**

STDOUT:
**before**
**after**



--
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: FTP converting between UTF-8 and EBCDIC

[Frank Swarbrick]

Originally (current production mode) there is no SBDATACONN/MBDATACONN 
specified, so z/OS is not treating the file as UTF-8.  It works fine when we 
specify "site mbdataconn=(ibm-1140,utf-8) encoding=mbcs".


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Monday, November 16, 2020 2:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP converting between UTF-8 and EBCDIC

If you tell FTP that the non-EBCDIC file is UTF-8 then FTP *should* convert
accented characters and such to EBCDIC SUB (X'3F') rather than to two bytes.
Should. YMMV.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Monday, November 16, 2020 10:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP converting between UTF-8 and EBCDIC

The record is made up of multiple fixed-length fields.  I guess the field in
question technically didn't overflow.  But rather it "expanded" the field by
one byte, pushing every other field one byte to the right.  Likely the
program that creates the file is treating the "field length" as the number
of characters, rather than the number of bytes.  I've actually asked them to
create the file as ISO-8859-1 instead of UTF-8, and if they're willing/able
to do that then this entire discussion is moot.  But I wanted to have this
as a backup solution.


From: IBM Mainframe Discussion List  on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, November 16, 2020 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP converting between UTF-8 and EBCDIC

On Mon, 16 Nov 2020 17:26:12 +, Frank Swarbrick wrote:

>Yes, it "overflowed" a fixed-length field.  x'C3A1' in the source file was
treated as two separate "ASCII" characters, x'C3' and x'A1'.  Since those
don't exist in the EBCDIC code page I am using they just get converted to
two "nonsense" characters.
>
How wide is that field?  You must have been on the bitter edge of the limit.
What happens if a client enters an actual surname exceeding the limit?

>I agree that ideally the input source would restrict the input.  But since
that's on another team, and this workaround is likely "good enough", that's
probably unlikely to happen.
>
What was the workaround you chose, converting to which EBCDIC CCSID?
Is there no possibility of a client's entering a character not in that
CCSID?
What happens if someone does?  Can you fuzz test or would that intrude
"on another team"?

I'd expect you need to do some filtering, perhaps to preclude SQL injection
downstream.  But that might be achieved by encoding.

(I guessed wrong: "á", not  "â".  Spellcheck flags both.)

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

Other user trying to run my shell script gets "FSUM7351 not found" error

[Frank Swarbrick]

Any thoughts on this?  I can execute this job and have no issue.  I'm trying to 
let another developer run it.  He's able to run /u/dvfjs/rocket/bin/curl 
directly (in STDPARM, following "SH ".)  But if he executes my shell script 
(/u/dvfjs/jira_test) he gets "/u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4: 
FSUM7351 not found".

I've set the read and execution bits for user, group and other for both curl 
and the jira_test shell script.  Since the "echo" commands are working for him, 
he's obviously able to execute my shell script itself.  What else might I be 
missing?  The other developer has an OMVS segment, but he doesn't have an 
initial working directory or default shell configured yet.  Could that be the 
issue?  If so, what specifically is causing this particular issue?

JCL:
//DVRJZTST JOB ,'Test',CLASS=C,REGION=0M,NOTIFY=
//*
//UNIX EXEC PGM=BPXBATCH
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*
//STDPARM  DD *
SH /u/dvfjs/jira_test
/*

/u/dvfjs/jira_test:
#!/bin/sh -x

echo **before**
/u/dvfjs/rocket/bin/curl --help
echo **after**

File attributes:
-sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/jira_test
- untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971  77 Nov 16 12:24 
/u/dvfjs/jira_test
-sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/rocket/bin/curl
- untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971 21266432 Nov  1  
2019 /u/dvfjs/rocket/bin/curl

STDERR:
FSUM1012 The initial working directory was not specified.
FSUM1006 A shell was not specified. Processing continues using the default 
shell name.
+ echo **before**
+ /u/dvfjs/rocket/bin/curl --help
/u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4:
+ echo **after**

STDOUT:
**before**
**after**



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

Re: FTP converting between UTF-8 and EBCDIC

[Frank Swarbrick]

The record is made up of multiple fixed-length fields.  I guess the field in 
question technically didn't overflow.  But rather it "expanded" the field by 
one byte, pushing every other field one byte to the right.  Likely the program 
that creates the file is treating the "field length" as the number of 
characters, rather than the number of bytes.  I've actually asked them to 
create the file as ISO-8859-1 instead of UTF-8, and if they're willing/able to 
do that then this entire discussion is moot.  But I wanted to have this as a 
backup solution.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, November 16, 2020 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP converting between UTF-8 and EBCDIC

On Mon, 16 Nov 2020 17:26:12 +, Frank Swarbrick wrote:

>Yes, it "overflowed" a fixed-length field.  x'C3A1' in the source file was 
>treated as two separate "ASCII" characters, x'C3' and x'A1'.  Since those 
>don't exist in the EBCDIC code page I am using they just get converted to two 
>"nonsense" characters.
>
How wide is that field?  You must have been on the bitter edge of the limit.
What happens if a client enters an actual surname exceeding the limit?

>I agree that ideally the input source would restrict the input.  But since 
>that's on another team, and this workaround is likely "good enough", that's 
>probably unlikely to happen.
>
What was the workaround you chose, converting to which EBCDIC CCSID?
Is there no possibility of a client's entering a character not in that CCSID?
What happens if someone does?  Can you fuzz test or would that intrude
"on another team"?

I'd expect you need to do some filtering, perhaps to preclude SQL injection
downstream.  But that might be achieved by encoding.

(I guessed wrong: "á", not  "â".  Spellcheck flags both.)

-- 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: FTP converting between UTF-8 and EBCDIC

[Frank Swarbrick]

Yes, it "overflowed" a fixed-length field.  x'C3A1' in the source file was 
treated as two separate "ASCII" characters, x'C3' and x'A1'.  Since those don't 
exist in the EBCDIC code page I am using they just get converted to two 
"nonsense" characters.

I agree that ideally the input source would restrict the input.  But since 
that's on another team, and this workaround is likely "good enough", that's 
probably unlikely to happen.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, November 15, 2020 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP converting between UTF-8 and EBCDIC

On Mon, 16 Nov 2020 02:28:06 +, Frank Swarbrick wrote:

>We don't use Unix for any of our production business applications.  If we were 
>"starting from scratch" I imagine we might choose to use Unix files for many 
>things, but I can't see us going this direction now.
>
>This is an existing process with an existing MVS data set, and up until a 
>couple of days ago it was treated (on the remote side) as just a standard 
>"ASCII" file.   A couple of days ago a user entered as last name with a 
>lower-case 'a' with an accent, causing a two-byte character to be used where 
>it had always been a single byte before.  
>
Did that (â?) cause the last name to overflow a field?  If not, what's the 
problem?

No single SBCS code page can accommodate all characters you're likely to 
encounter.

You might filter on input to acceptable, SBCS-translatable characters.
Expect accusations of ethnic bias if you do that.

-- 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: FTP converting between UTF-8 and EBCDIC

[Frank Swarbrick]

We don't use Unix for any of our production business applications.  If we were 
"starting from scratch" I imagine we might choose to use Unix files for many 
things, but I can't see us going this direction now.

This is an existing process with an existing MVS data set, and up until a 
couple of days ago it was treated (on the remote side) as just a standard 
"ASCII" file.   A couple of days ago a user entered as last name with a 
lower-case 'a' with an accent, causing a two-byte character to be used where it 
had always been a single byte before.  


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, November 15, 2020 4:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP converting between UTF-8 and EBCDIC

On Sun, 15 Nov 2020 22:44:05 +, Frank Swarbrick wrote:

>I couldn't find this actually stated anywhere, but it looks like if you want 
>to use z/OS FTP to transmit a UTF-8 encoded file to (and I assume from) an 
>EBCDIC codepage you have to use multi-byte encoding instead of single byte 
>encoding.  The z/OS file also has to be variable length, not fixed length.
>
Why bother?  Just transfer in binary to a z/OS UNIX file.  ISPF Edit,
for example, handles that format splendidly, subject to the display
capability of the attached terminal; even automatically if the file is
tagged as CCSID 1208.

>Here is an example using curl.  Note that this works even on standard Windows 
>10, as curl.exe is now provided with Windows 10.  If you are using PowerShell 
>instead of CMD.exe you need to specify "curl.exe" instead of just "curl".  
>Search the internet for why, if you care.
>
>curl --user DVFJS --ftp-ssl --insecure --use-ascii --quote "site 
>mbdataconn=(ibm-1140,utf-8) encoding=mbcs" --upload-file 
>20201106180101ICMUpload.txt ftp://ZOSD:8443/'DEV.RXMTIN.ICM.ICMM2M.VB'
>
>"--insecure" is necessary for me because we have a self-signed FTP server 
>certificate.  It may not be necessary for you.
>
>Note that this is only required if the source file actually has one or more 
>multi-byte UTF-8 codepoints.  A UTF-8 file that only has single-byte 
>codepoints is identical to a standard 7-bit ASCII file and can be transmitted 
>using a default sbcs encoding.
>
>I honestly was surprised this work, as the documentation (as I read it, 
>anyway) didn't seem to indicate that conversion between a multi-byte codeset 
>(UTF-8) and a single-byte EBCDIC codeset (IBM-1140, in this case) is possible. 
> But apparently it is.  Note that I didn't test anything where the EBCDIC 
>codepage does not have a corresponding codepoint for a particular character.  
>The character in question in this example is "�", which is code-sequence 
>x'C3A1' in UTF-8 and x'45' in ECBDIC-1140.

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

FTP converting between UTF-8 and EBCDIC

[Frank Swarbrick]

I couldn't find this actually stated anywhere, but it looks like if you want to 
use z/OS FTP to transmit a UTF-8 encoded file to (and I assume from) an EBCDIC 
codepage you have to use multi-byte encoding instead of single byte encoding.  
The z/OS file also has to be variable length, not fixed length.

Here is an example using curl.  Note that this works even on standard Windows 
10, as curl.exe is now provided with Windows 10.  If you are using PowerShell 
instead of CMD.exe you need to specify "curl.exe" instead of just "curl".  
Search the internet for why, if you care.

curl --user DVFJS --ftp-ssl --insecure --use-ascii --quote "site 
mbdataconn=(ibm-1140,utf-8) encoding=mbcs" --upload-file 
20201106180101ICMUpload.txt ftp://ZOSD:8443/'DEV.RXMTIN.ICM.ICMM2M.VB'

"--insecure" is necessary for me because we have a self-signed FTP server 
certificate.  It may not be necessary for you.

Note that this is only required if the source file actually has one or more 
multi-byte UTF-8 codepoints.  A UTF-8 file that only has single-byte codepoints 
is identical to a standard 7-bit ASCII file and can be transmitted using a 
default sbcs encoding.

I honestly was surprised this work, as the documentation (as I read it, anyway) 
didn't seem to indicate that conversion between a multi-byte codeset (UTF-8) 
and a single-byte EBCDIC codeset (IBM-1140, in this case) is possible.  But 
apparently it is.  Note that I didn't test anything where the EBCDIC codepage 
does not have a corresponding codepoint for a particular character.  The 
character in question in this example is "á", which is code-sequence x'C3A1' in 
UTF-8 and x'45' in ECBDIC-1140.

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

Re: Learning shell scripting

[Frank Swarbrick]

I just found this:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa400/shs.htm
Writing z/OS shell 
scripts<https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa400/shs.htm>
To simplify such jobs, the shell lets you run a sequence of commands that have 
been stored in a text file. For example, the programmer could store all the 
appropriate compiling and linking commands in a file.
www.ibm.com




From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Monday, November 9, 2020 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Learning shell scripting

No particular goal in mind.  Just learning.
I already know REXX fairly well.
Thanks.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, November 9, 2020 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Learning shell scripting

On Mon, 9 Nov 2020 20:48:23 +, Frank Swarbrick wrote:

>While I've used Unix/Linux systems on and off for over 30 years, I've never 
>really taken the time to learn shell scripting.  For a z/OS environment are 
>there any highly recommended tutorials and/or references?
>
Largely, I glanced at examples and read man pages.  I never went
down a path such as "Shell for dummies".  I think I became competent.

I also recommend z/OS Using REXX and z/OS UNIX System Services
SA23-2283-40

Not shell, but enormously useful.  Much of the power of the standard
"C" library with the ease of coding Rexx.

What's your goal; what would be your first practical/demo shell
(or Rexx) program?

In my earliest encounter with UNIX (Solaris) I was impressed by the
significance of the "Uni" prefix; the ability to use a single language
for terminal commands, scripting, and batch; as opposed to TSO,
CLIST, Rexx, JCL, ...

And the *uni*formity of shell's lexical analysis.  Granted there are
some commands you'd like to be peculiar; I find this outweighed
by "everything works the same."  Except for outliers such as
"dd" (needlessly -- I suspect it was invented by an OS/360
partisan) and "find" (with better reason -- it's command line is
somewhat like you'd expect of a DFSORT control flle).

What's your goal?

-- 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: Learning shell scripting

[Frank Swarbrick]

No particular goal in mind.  Just learning.
I already know REXX fairly well.
Thanks.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, November 9, 2020 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Learning shell scripting

On Mon, 9 Nov 2020 20:48:23 +, Frank Swarbrick wrote:

>While I've used Unix/Linux systems on and off for over 30 years, I've never 
>really taken the time to learn shell scripting.  For a z/OS environment are 
>there any highly recommended tutorials and/or references?
>
Largely, I glanced at examples and read man pages.  I never went
down a path such as "Shell for dummies".  I think I became competent.

I also recommend z/OS Using REXX and z/OS UNIX System Services
SA23-2283-40

Not shell, but enormously useful.  Much of the power of the standard
"C" library with the ease of coding Rexx.

What's your goal; what would be your first practical/demo shell
(or Rexx) program?

In my earliest encounter with UNIX (Solaris) I was impressed by the
significance of the "Uni" prefix; the ability to use a single language
for terminal commands, scripting, and batch; as opposed to TSO,
CLIST, Rexx, JCL, ...

And the *uni*formity of shell's lexical analysis.  Granted there are
some commands you'd like to be peculiar; I find this outweighed
by "everything works the same."  Except for outliers such as
"dd" (needlessly -- I suspect it was invented by an OS/360
partisan) and "find" (with better reason -- it's command line is
somewhat like you'd expect of a DFSORT control flle).

What's your goal?

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

Learning shell scripting

[Frank Swarbrick]

While I've used Unix/Linux systems on and off for over 30 years, I've never 
really taken the time to learn shell scripting.  For a z/OS environment are 
there any highly recommended tutorials and/or references?

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

Re: Can a non-admin restrict others from viewing one of their own MVS data sets?

[Frank Swarbrick]

Haha, I've gotten enough security violations myself to know that this won't be 
a problem.


From: IBM Mainframe Discussion List  on behalf of 
Arthur 
Sent: Friday, November 6, 2020 6:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Can a non-admin restrict others from viewing one of their own MVS 
data sets?

Frank Swarbrick said:
>I was successfully able to use the Security System (RACF)
>panels to add a dataset profile for a dataset with my HLQ,
>with UACC(NONE).  I had another developer who would
>normally have access try to view it and he was blocked.

You might want to tell your security people that this was a
test, and do it *before* they notice that failed access.
Even the truth is suspicious when stated after the
investigations start; and you don't want to get that other
developer in trouble.

--
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: Can a non-admin restrict others from viewing one of their own MVS data sets?

[Frank Swarbrick]

Thanks!  I was successfully able to use the Security System (RACF) panels to 
add a dataset profile for a dataset with my HLQ, with UACC(NONE).  I had 
another developer who would normally have access try to view it and he was 
blocked.  Didn't really expect for this to work, but glad it did.


From: IBM Mainframe Discussion List  on behalf of 
Lizette Koehler 
Sent: Friday, November 6, 2020 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Can a non-admin restrict others from viewing one of their own MVS 
data sets?

If you own the dataset and RACF Admins permit it,

You should be able to alter your Datasets in MVS using the RACF Commands or
Panels.

Will not work if you are not the owner of the file.

For Example I own all datasets that begin with my TSO ID.  I do not own SYS1
datasets.

SO it just depends

Lizette


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Frank Swarbrick
Sent: Friday, November 6, 2020 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Can a non-admin restrict others from viewing one of their own MVS
data sets?

In the Unix world one can use chmod (change mode) on their own files to make
it so non-superusers cannot view a particular file.  Is there anything
similar for MVS data sets?

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

Can a non-admin restrict others from viewing one of their own MVS data sets?

[Frank Swarbrick]

In the Unix world one can use chmod (change mode) on their own files to make it 
so non-superusers cannot view a particular file.  Is there anything similar for 
MVS data sets?

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

Re: Modify UNIX File Format

[Frank Swarbrick]

That worked.  I never in a million years would have found it.  How did you know?
Your URL pointed to the binder instruction, though, not the UNIX command, which 
is 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/xattr.htm

DVFJS:/u/dvfjs:>touch attrtest
DVFJS:/u/dvfjs:>chtag -t -c 819 attrtest
DVFJS:/u/dvfjs:>extattr -F CRLF attrtest
DVFJS:/u/dvfjs:>ls -FalTHp attrtest
t ISO8859-1   T=on  -rw---  crlf   1 DVFJSDEPT9971   0 Oct 29 14:13 
attrtest

Thanks!

From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, October 29, 2020 1:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Modify UNIX File Format

On Thu, 29 Oct 2020 18:31:03 +0000, Frank Swarbrick wrote:

>Using the z/OS UNIX Directory List Utility (ISPF 3.17) command MF (Modify 
>Format) you are able to change the file format.  It prompts you with a panel 
>looking something like this:
>...
>Is there a corresponding UNIX command to perform this action?  For example, 
>chtag can be used to change the CCSID.  But I can't find a command to change 
>the file format value.
>
I believe "extattr":

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab100/exta.htm

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

Modify UNIX File Format

[Frank Swarbrick]

Using the z/OS UNIX Directory List Utility (ISPF 3.17) command MF (Modify 
Format) you are able to change the file format.  It prompts you with a panel 
looking something like this:

   Modify z/OS UNIX File Format
Command ===>

Pathname . : /u/dvfjs/cics_headers.txt
Type . . . : File

Format . . . 6  1. NA   3. NL 5. LF 7. LFCR 9. Record
2. Binary   4. CR 6. CRLF   8. CRNL

CCSID  . . . 819

Enter "/" to select option
/  Automatic Conversion


Is there a corresponding UNIX command to perform this action?  For example, 
chtag can be used to change the CCSID.  But I can't find a command to change 
the file format value.

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

Re: Generic name for PDS/PDSE

[Frank Swarbrick]

Load module or program object should be easy: executable, or binary executable.


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Wednesday, October 28, 2020 8:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Generic name for PDS/PDSE

I use "PDS(E)", but what's the generic for "load module or program object"?

I spell auto-correct as "auto-defect"; we hates it, precious. Of course, some 
of the "corrections" are hilarious.

I would interpret "MVS library" as DSNTYPE=LIBRARY, but I wouldn't bet on that 
being correct.


--
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: Tuesday, October 27, 2020 5:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Generic name for PDS/PDSE

Grrr. As a frequent writer of documentation I struggle with that one.

I would say either "PDS(E)" (which my PC keeps trying to auto-correct to PDS€) 
or a preamble something like

"In this document, the term PDS means either a Partitioned Dataset (PDS) or a 
Partitioned Dataset Extended (PDSE) unless the context clearly demands 
otherwise."

I personally at least would have to think "what the heck does he mean?" every 
time I encountered "MVS library."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Tuesday, October 27, 2020 2:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Generic name for PDS/PDSE

Is there a standard "generic" name for PDS/PDSE?  Is it "PDS(E)"?  Or maybe 
something like "MVS library" or "MVS dataset library"?

Just wondering.

--
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: Syncsort to DFSORT - my time has come.

[Frank Swarbrick]

Not my dog...  I'm just a developer.


From: IBM Mainframe Discussion List  on behalf of 
Martin Packer 
Sent: Wednesday, October 28, 2020 2:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Syncsort to DFSORT - my time has come.


FWIW I would go with SMF=FULL - unless you have an exceptionally large
number of sorts - or tight SMF space restrictions.

There’s gold in them there records. :-)

Cheers, Martin

Sent from my iPad

> On 27 Oct 2020, at 21:13, Frank Swarbrick 
wrote:
>
> Here is our ICEPRM00, if you are interested.
>
> JCL
>   DYNALOC=(SYSDA,12)
>   DYNAUTO=YES
>   MSGDDN=SYSOUT
>   PARMDDN=DFSPARM
>   SMF=NO
> INV
>   DYNALOC=(SYSDA,12)
>   DYNAUTO=IGNWKDD
>   ERET=ABEND
>   MSGDDN=SORTMSG
>   PARMDDN=SORTPARM
>   SMF=SHORT
> TSO
>   SMF=SHORT
> TSOINV
>   SMF=SHORT
> TD1
>   SMF=SHORT
> TD2
>   SMF=SHORT
> TD3
>   SMF=SHORT
> TD4
>   SMF=SHORT
>
> 
> From: IBM Mainframe Discussion List  on behalf
of R.S. 
> Sent: Tuesday, October 27, 2020 11:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Syncsort to DFSORT - my time has come.
>
> W dniu 27.10.2020 o 18:16, Gibney, Dave pisze:
>>A fairly quick question. Are there sample ICEPRMxx members provided
by IBM for tailoring DFSORT? I don't find any in SICESAMP.
>> Yesterday, in my sandbox, I IPL'd with SICELPA, SORTLPA, SICELINK,
SORTLIB ahead of the SYNCSORT libraries and not ICEPRMxx. SHOWZOS shows
DFSORT as resident sort program. All seems well. I don't keep this
concatenation, it was just easier for fall back considerations.
>
> If you want some sample I can send it.
> However there is no black magic there.
> IMHO it is fundamental to define your needs, because the member is for
> defaults which can be easily overtyped by parameters in the job.
>
> Here you are:
>
> ***
> ** History of changes:
> ** 05-10-2019 R.SKORUPKA first customization
> ** dd-mm- user description...
> **
> 
> *
> * JCL (ICEAM1)
> JCL
> DYNALOC=(3390,10)
> *
> * INV (ICEAM2)
> INV
> DYNALOC=(3390,10)
>
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
(kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st.
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS
025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości)
według stanu na 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you
have printed out or saved).
> This message may contain legally protected information, which may be used
exclusively by the addressee.Please be reminded that anyone who
disseminates (copies, distributes) this message or takes any similar
action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18,
00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for
the Capital City of Warsaw, 12th Commercial Division of the National Court
Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Generic name for PDS/PDSE

[Frank Swarbrick]

Is there a standard "generic" name for PDS/PDSE?  Is it "PDS(E)"?  Or maybe 
something like "MVS library" or "MVS dataset library"?

Just wondering.

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

Re: Syncsort to DFSORT - my time has come.

[Frank Swarbrick]

Here is our ICEPRM00, if you are interested.

JCL
   DYNALOC=(SYSDA,12)
   DYNAUTO=YES
   MSGDDN=SYSOUT
   PARMDDN=DFSPARM
   SMF=NO
INV
   DYNALOC=(SYSDA,12)
   DYNAUTO=IGNWKDD
   ERET=ABEND
   MSGDDN=SORTMSG
   PARMDDN=SORTPARM
   SMF=SHORT
TSO
   SMF=SHORT
TSOINV
   SMF=SHORT
TD1
   SMF=SHORT
TD2
   SMF=SHORT
TD3
   SMF=SHORT
TD4
   SMF=SHORT


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Tuesday, October 27, 2020 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Syncsort to DFSORT - my time has come.

W dniu 27.10.2020 o 18:16, Gibney, Dave pisze:
> A fairly quick question. Are there sample ICEPRMxx members provided by 
> IBM for tailoring DFSORT? I don't find any in SICESAMP.
> Yesterday, in my sandbox, I IPL'd with SICELPA, SORTLPA, SICELINK, SORTLIB 
> ahead of the SYNCSORT libraries and not ICEPRMxx. SHOWZOS shows DFSORT as 
> resident sort program. All seems well. I don't keep this concatenation, it 
> was just easier for fall back considerations.

If you want some sample I can send it.
However there is no black magic there.
IMHO it is fundamental to define your needs, because the member is for
defaults which can be easily overtyped by parameters in the job.

Here you are:

***
** History of changes:
** 05-10-2019 R.SKORUPKA first customization
** dd-mm- user description...
**

*
* JCL (ICEAM1)
JCL
DYNALOC=(3390,10)
*
* INV (ICEAM2)
INV
DYNALOC=(3390,10)



--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

--
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: SMF to capture user login history

[Frank Swarbrick]

Right.  Was hoping to be able to do it with a single user ID.  Oh well!


From: IBM Mainframe Discussion List  on behalf of 
Allan Staller 
Sent: Monday, October 26, 2020 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SMF to capture user login history

Classification: Internal

That would require an additional longon ID with a different default 
group/grouplist.
This is a fairly common practice. One ID for everyday use and another with 
elevated privileges when needed.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Monday, October 26, 2020 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF to capture user login history

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Thanks.
Looks like there is not a way to do what I was hoping for, which would allow 
for a set of default groups for a user, along with one or more groups that 
require a user to explicitly log in to use them.  For example, I am a member of 
3 groups right now, and we must use GRPLIST because I don't have to specify a 
particular group to have my rights for all three.  I would like to have an 
additional group available to me, but only if I explicitly specify it.  In that 
case I would want to have the rights for all four groups.  I would also want to 
be able to "log" any time I (or any user) log in to this "special access" 
fourth group.

Sounds like I am out of luck here, but someone correct me if I'm wrong.


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Monday, October 26, 2020 11:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SMF to capture user login history

Yes, obviously!
But ...no.

To explain: there is an option in RACF, called GRPLIST. Vast majority of 
installations use GRPLIST, but few use NOGRPLIST.

1. YES
For NOGRPLIST you may belong to meny group, but only one connection at the time 
is "active"  - that means you logon as Frank, FRANK1 (that's the password) and 
NETADM - that's the group.
And you have all the authorities given to user FRANK and to group NETADM.
However you are member of SMSADM as well - but this group gives you no 
authorities, because only one group is taken.
Is it stupid? Some people say it is good. Let's leave it.


2. NO
In typical GRPLIST world you logon as FRANK/FRANK1 and (usually) it doesn't 
matter what group you provide, if any.
And you have all the authorities given to FRANK, NETADM, SMSADM and all other 
groups you are connected to.
So, it in this case privileges are not different.

Exception: there are very few, very rare cases when "current connect group" is 
important even in GRPLIST. See ARCCATGP (DFSMShsm manual).
However AFAIR it is enough to provide this groupname during logon.

Remark: no group provided = default group. Every RACF user has default group 
assigned. And of course the user is connected to this group.

HTH

--
Radoslaw Skorupka
Lodz, Poland






W dniu 26.10.2020 o 17:30, Frank Swarbrick pisze:
> Curious question.  Is it possible to have a single user ID with different 
> privileges depending on what group you specify when logging in (to TSO, for 
> example)?
>
> 
> From: IBM Mainframe Discussion List  on
> behalf of Seymour J Metz 
> Sent: Sunday, October 25, 2020 8:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: SMF to capture user login history
>
>> two sets of IDs
> Multiple ids can be very usefull. If you have a lot of privileges and write 
> code that is supposed to work without those privileges, it's useful to have a 
> bare bones userid. If you have work that requires privileges that you 
> consider too dangerous for normal work, it's nice to have a more privileged 
> userid and proxy permission. BTDT, GTTS.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g
> mu.edu%2F~smetz3data=04%7C01%7Callan.staller%40HCL.COM%7C0eaac4d6
> fb9245e9d75c08d879df9a98%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C
> 637393349175371164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=ew8aS0sA5X7qu
> EdwJZayOILNENkQsBhqgCYRSDOqkeQ%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Steve Horein [steve.hor...@gmail.com]
> Sent: Sunday, October 25, 2020 9:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF to capture user login history
>
> On Sun, Oct 25, 2020 at 1:11 AM kekronbekron <
> 02dee3fcae33-dmarc

Re: SMF to capture user login history

[Frank Swarbrick]

Thanks.
Looks like there is not a way to do what I was hoping for, which would allow 
for a set of default groups for a user, along with one or more groups that 
require a user to explicitly log in to use them.  For example, I am a member of 
3 groups right now, and we must use GRPLIST because I don't have to specify a 
particular group to have my rights for all three.  I would like to have an 
additional group available to me, but only if I explicitly specify it.  In that 
case I would want to have the rights for all four groups.  I would also want to 
be able to "log" any time I (or any user) log in to this "special access" 
fourth group.

Sounds like I am out of luck here, but someone correct me if I'm wrong.


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Monday, October 26, 2020 11:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SMF to capture user login history

Yes, obviously!
But ...no.

To explain: there is an option in RACF, called GRPLIST. Vast majority of
installations use GRPLIST, but few use NOGRPLIST.

1. YES
For NOGRPLIST you may belong to meny group, but only one connection at
the time is "active"  - that means you logon as Frank, FRANK1 (that's
the password) and NETADM - that's the group.
And you have all the authorities given to user FRANK and to group NETADM.
However you are member of SMSADM as well - but this group gives you no
authorities, because only one group is taken.
Is it stupid? Some people say it is good. Let's leave it.


2. NO
In typical GRPLIST world you logon as FRANK/FRANK1 and (usually) it
doesn't matter what group you provide, if any.
And you have all the authorities given to FRANK, NETADM, SMSADM and all
other groups you are connected to.
So, it in this case privileges are not different.

Exception: there are very few, very rare cases when "current connect
group" is important even in GRPLIST. See ARCCATGP (DFSMShsm manual).
However AFAIR it is enough to provide this groupname during logon.

Remark: no group provided = default group. Every RACF user has default
group assigned. And of course the user is connected to this group.

HTH

--
Radoslaw Skorupka
Lodz, Poland






W dniu 26.10.2020 o 17:30, Frank Swarbrick pisze:
> Curious question.  Is it possible to have a single user ID with different 
> privileges depending on what group you specify when logging in (to TSO, for 
> example)?
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Seymour J Metz 
> Sent: Sunday, October 25, 2020 8:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: SMF to capture user login history
>
>> two sets of IDs
> Multiple ids can be very usefull. If you have a lot of privileges and write 
> code that is supposed to work without those privileges, it's useful to have a 
> bare bones userid. If you have work that requires privileges that you 
> consider too dangerous for normal work, it's nice to have a more privileged 
> userid and proxy permission. BTDT, GTTS.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Steve Horein [steve.hor...@gmail.com]
> Sent: Sunday, October 25, 2020 9:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF to capture user login history
>
> On Sun, Oct 25, 2020 at 1:11 AM kekronbekron <
> 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
>
>> I hope no one encourages this kind of snooping on the list.
>> Stinks of an attempt to police working hours.
>>
>> - KB
>>



==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, di

Re: SMF to capture user login history

[Frank Swarbrick]

Curious question.  Is it possible to have a single user ID with different 
privileges depending on what group you specify when logging in (to TSO, for 
example)?


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Sunday, October 25, 2020 8:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SMF to capture user login history

> two sets of IDs

Multiple ids can be very usefull. If you have a lot of privileges and write 
code that is supposed to work without those privileges, it's useful to have a 
bare bones userid. If you have work that requires privileges that you consider 
too dangerous for normal work, it's nice to have a more privileged userid and 
proxy permission. BTDT, GTTS.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Horein [steve.hor...@gmail.com]
Sent: Sunday, October 25, 2020 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF to capture user login history

On Sun, Oct 25, 2020 at 1:11 AM kekronbekron <
02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:

> I hope no one encourages this kind of snooping on the list.
> Stinks of an attempt to police working hours.
>
> - KB
>

Meh.
The first shop I worked in implemented something like that to track the use
of privileged IDs that had elevated permissions to update production
resources. At the time, the scope had been TSO, so I wrote some automation
that would send an email to the "security operations center" if RACF IDs
matching specific patterns generated an IEF125I, IEF126I, or an IEF45*
message. The time frames from logon to logoff/abend needed to be justified
with a change request or incident, otherwise it would be considered
suspicious activity. Yes, it meant having to maintain two sets of IDs - a
BAU ID for day to day work, and the privileged ID for changes or recovery
support, but it satisfied someone's requirement.

--
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: Bill Klein, COBOL standards person has died

[Frank Swarbrick]

Sad news.  Thanks for letting us know, Clark.


From: IBM Mainframe Discussion List  on behalf of 
Clark F Morris 
Sent: Thursday, September 24, 2020 1:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Bill Klein, COBOL standards person has died

The following is from comp.lang.cobol

Bill Klein was involved with COBOL requirements and other things at
SHARE.  He is being missed.

Clark Morris
On Thu, 17 Sep 2020 02:07:39 -0600, in comp.lang.cobol Louis Krupp
 wrote:

>On 9/16/2020 9:42 PM, Arnold Trembley wrote:
>>
>> Brian Tiffin reports than Bill Klein has died:
>>
>> "I'm saddened to inform everyone about the recent passing of William
>> Klein. Bill passed away September 5th 2020.
>>
>> "For those that may not know; Bill has been the COBOL Standard guy for
>> years now. Until he started losing his sight, he was also the Keeper
>> of the COBOL FAQ."
>>
>> Here's a link to Brian's post:
>>
>> https://sourceforge.net/p/gnucobol/discussion/lounge/thread/070e0bf6aa/
>>
>> William Klein was a fairly frequent poster in comp.lang.cobol,
>> although he had not been as active in recent years.
>>
>>
>>
>
>A couple of obituaries (I believe these are for the right Bill Klein --
>I trust that someone will correct me if they're not):
>
>https://www.donnellanfuneral.com/obituaries/William-Michael--Klein?obId=18353180
>
>http://www.iagsdchistory.org/historywiki/index.php/Bill_Klein
>
>Louis

--
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: Passing STDENV DD to FTP via SYSIN

[Frank Swarbrick]

You can also use the CEEOPTS DD.  Something like this:

//CEEOPTS DD *
ENVAR("GSK_PROTOCOL_TLSV1_2=1")
[...any other LE options you wish to use...]
/*

We also use this method of specifying TLS 1.2, but I seem to recall the 
"official" method is to use AT-TLS instead.  At the time we wanted to start 
using TLS 1.2 we didn't have PAGENT (and thus AT-TLS) set up, so we went this 
way.  So offhand I don't know how it should be configured using PAGENT/AT-TLS.


From: IBM Mainframe Discussion List  on behalf of 
Wendell Lovewell <01e9c0ee0673-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, September 10, 2020 10:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Passing STDENV DD to FTP via SYSIN

Hey Charles, I took you seriously the first time.  I appreciate your interest 
in helping.

Bottom line, I'd like to come up with a job any z/OS customer could run, 
without requiring changes to any of their system files (like FTPCDATA or AT-TLS 
or RACF) that would allow them to transmit files to/from an FTP site using FTPS.

I've pretty much given up on that--I can't find a way to do it without 
installing certificates used by the FTP server into their RACF/ACF2/Top Secret 
databases.  And even with the certificates in RACF, the only way I've gotten it 
to work is force FTP to use TLS 1.2 by setting the "GSK_PROTOCOL_TLSV1_2" 
environment variable to "ON" per this URL:

https://www.ibm.com/support/pages/zos-communications-server-tls-needed-implement-tls-v12

That page does say for FTP the STDENV dataset should be RECFM=VB.  (I did try 
various combinations of DD *,DCB=(...), including DCB=(RECFM=VB), but JES 
didn't seem to allow that.)  Gil might be on to something with the temporary 
datasets not being available to spawned processes, but I've cataloged the 
IEBGENER'd file and the job still fails like it doesn't find the 
"GSK_PROTOCOL_TLSV1_2=ON" variable.

---

I'm not sure how to close this out, but as I've been typing this, I did figure 
out how to get around the STDENV problem.  I'm going to go ahead and leave what 
I've said so far in case someone else comes across this in the future, but 
here's a work-around:

What I was trying to do was:
//FTPXFER  EXEC PGM=FTP,REGION=4292K,
//PARM=('POSIX(ON) ALL31(ON)',
//   'ENVAR("_CEE_ENVFILE=DD:STDENV")/(EXIT')
//STDENV   DD *
GSK_PROTOCOL_TLSV1_2=ON
//*

Where the 'ENVAR("_CEE_ENVFILE=DD:STDENV") is telling LE to look for 
environment variables in the STDENV DD.  The STDENV file wasn't being found, 
but all it has is one variable name and value.  So it occurred to me that I 
could just put the variable and value in the PARM:

//FTPXFER  EXEC PGM=FTP,REGION=4292K,
//PARM=('POSIX(ON) ALL31(ON)',
//   'ENVAR("GSK_PROTOCOL_TLSV1_2=ON")/(EXIT')

Turns out, it works!

Thanks for all your help.
Wendell

--
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: Multiple FTP Servers

[Frank Swarbrick]

A couple of things...

  *   According to https://en.wikipedia.org/wiki/FTPS, port 990 has been 
"reserved" as the official listener port for the FTPS data connection.
  *   This doesn't mean you must use this port.  Our FTPS server uses 8443.  
Apparently some brainiac thought that FTPS and HTTPS were the same thing...
  *   I imagine you could continue to use port 21 if you want to allow both 
encrypted and unencrypted FTP.  Just guessing here.


From: IBM Mainframe Discussion List  on behalf of 
Roberto Halais 
Sent: Friday, September 4, 2020 9:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Multiple FTP Servers

Listers:

We are converting all our file transfer jobs from FTP to FTPS.
Our security people insist we do not use port 21 for our FTPS.
I see no way of adding another port to our current ftp server it listens on
port 21.
Question:
Do I have to create another FTPD server listening on port 9921 (for
example)?
Can I have more than one ftp server per tcp/ip stack one listening on port
21 and the other on port 9921?

I haven't encountered this before and Google hasn't helped.

Any ideas are welcome.

Roberto

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

Accessing github (and other public internet sites) (was Re: A little magic from Doug Nadel)

[Frank Swarbrick]

Question for you all.  Are you allowed to have your z/OS machines access 
internet sites such as github, directly?  If not, what processes do you follow 
to get said data on to your z/OS systems?


From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Friday, September 4, 2020 1:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: A little magic from Doug Nadel

On 2020-09-03 11:34 PM, Tom Conley wrote:
> On 9/3/2020 11:25 AM, David Crayford wrote:
>> I don’t want to bother with XMIT files. Git has been ported to z/OS
>> and works great.
>>
>
> David,
>
> Others have requested GIT, so stay tuned.

Thank you Tom! You can use Lionel's Zigi if you would rather not use the
shell https://github.com/wizardofzos/zigi


>
> Regards,
> Tom Conley
>
> --
> 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: PL/I RFE to vote for (or not)

[Frank Swarbrick]

There is one advantage to COBOL's rather archaic arithmetic statements:

DIVIDE dividend  BY  divisor  GIVING quotient  REMAINDER remain
DIVIDE divisor INTO dividend  GIVING quotient  REMAINDER remain



From: IBM Mainframe Discussion List  on behalf of 
Robert Prins 
Sent: Wednesday, September 2, 2020 1:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: PL/I RFE to vote for (or not)

quotient = QUOTREM(dividend, divisor, remainder),

With quotient and remainder generated in one go by the execution of a DP
instruction (and probably/possibly/maybe/likely  also by the various other
divide instructions)

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=145001
--
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

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

Re: Dovetail/Kirk Wolf?

[Frank Swarbrick]

If one does not use Twitter does one truly exist?


From: IBM Mainframe Discussion List  on behalf of 
Kirk Wolf 
Sent: Monday, August 31, 2020 3:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Dovetail/Kirk Wolf?

I'm fine (and utterly amused that my status might be inferred from my
cancelled Twitter account :-)

We wanted to look into your Tomcat request from Thursday before responding.
We do offer a z/OS distribution of Tomcat free without support, so
sometimes other things take precedence.
To confirm: Tomcat 8.5.6 is the last z/OS integration build that we
currently offer.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Mon, Aug 31, 2020 at 12:12 PM Dave Jousma <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Has anyone heard from Kirk Wolf recently?   I don’t see much action on his
> community forum over at dovetail.com either.
>
> I ask because we have been running Dovetail’s port of TOMCAT on Z that has
> the SAF interfaces added to it to house our internal team documentation.
>  We are admittedly behind, but I only see TOMCAT 8.5.6 on Dovetails site,
> and our security folks have identified a security vulnerability(WebSocket
> DoS CVE-2020-13935) in all releases older than 9.0.37.
>
> --
> 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: z/OS use of "legacy" programming languages

[Frank Swarbrick]

Thanks Tim.

I can't imagine being comfortable writing new code, at least, for a compiler 
that has not been updated in 35 years, but maybe that's just me.  

Now that we know what languages are still supported, I am still curious if 
anyone out there is actually still using them, and if so, why.


From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Wednesday, July 1, 2020 12:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: z/OS use of "legacy" programming languages

Frank Swarbrick asked:
>Is Pascal also still supported/used?

IBM VS Pascal (5668-767) is still IBM marketed and supported:

https://www.ibm.com/support/lifecycle/#/details?q45=M618799U16404L24

The New Stanford Pascal Compiler is also available:

https://github.com/StanfordPascal/Pascal
http://bernd-oppolzer.de/job9.htm

Here are some more classic programming language compilers that are
currently IBM marketed and supported, in no particular order:

APL2 (5688-228)
https://www.ibm.com/support/lifecycle/#/details?q45=D543769I30278S34

BASIC (5665-948)
https://www.ibm.com/support/lifecycle/#/details?q45=G568183M36263P96

RPG II
This one is a little extra obscure, but yes, it's still IBM marketed and
supported. The IBM Program Number is 5740-RG1. The z/VSE variant
(5746-RG1) is listed more visibly here:
https://www.ibm.com/us-en/marketplace/dosvs-rpg-ii
There's a little bit of confusion about RPG in large part because there
was a relatively briefly marketed RPG compiler introduced years later
called "IBM SAA RPG/370." This specific, very different compiler
(5688-127) was withdrawn from marketing and is no longer IBM supported,
but the previously introduced RPG II compiler is still an active IBM
product.

IBM's Prolog, Lisp, Ada, Algol, Smalltalk, and COMTRAN compilers are
withdrawn and past their End of Service dates, but it's likely there are
some of these compiled programs still running, even with some periodic
code changes. In some cases there may be available and supported
programming language offerings from other parties. Some may target Java
Virtual Machine (JVM) and/or z/OS Container Extensions (zCX) runtimes.

There's a supported JOVIAL compiler available for z/OS and z/VM:
http://www.seadeo.com/IBM_Compilers.htm

If there's some other programming language's status you'd like me to
research, please ask. And obviously IBM markets and supports C, C++, REXX,
COBOL, PL/I, Java, EGL, HLASM, and several other programming languages
(JavaScript, Swift, Python, IBM Migration Utility)

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

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

z/OS use of "legacy" programming languages

[Frank Swarbrick]

Some time ago I noticed that z/OS Language Environment has support for both 
"FORTRAN IV" and "VS FORTRAN" (FORTRAN 77 standard), even though the latest 
Fortran compiler hasn't been enhanced since 1993 (??).  I've been learning 
modern Fortran (standards Fortran 90, 95, 03 and 08) using GNU Fortran and 
actually quite like it, but I can't imagine using anything prior to the 1990 
standard.  Anyway, I am curious if anyone uses Fortran on z/OS in their shop, 
and if so, why?

Is Pascal also still supported/used?  I don't see any mention of it in LE 
documentation.  Are there any other "legacy" MVS languages still in use (i.e., 
ones that haven't been updated in the last 30 years...)?  I've seen mention of 
APL2 on MVS, and maybe even Smalltalk?

Just wondering!

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

Re: Good FTP client for MVS data set access

[Frank Swarbrick]

Looks like my confusion is I don't seem to actually have z/OS Explorer, but 
rather the "z/OS view" of IBM Problem Determination Tools Studio.  I guess they 
are not the same thing.

Is z/OS Explorer, including the server/host side of the product truly no-cost?  
If so I guess I could ask for it to be installed.


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Thursday, June 18, 2020 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

okay, understand, FEK is the HLQ for zexplorer, but yes a sysprog would need to 
install it if not installed, configure and setup the security or have the 
secadmin do the security.





Carmen Vitullo

- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, June 18, 2020 1:20:14 PM
Subject: Re: Good FTP client for MVS data set access

I'm not a sysprog so I can't configure anything myself. I don't that we have an 
SFEK* set of libraries on the system currently.  The documentation I've just 
now looked at seems to indicate this is part of IBM Developer/Rational 
Developer for z/OS.



From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Thursday, June 18, 2020 12:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

From what I recall, I don't have any doc at home, the configuration is done 
using the FEF.SFEKSAMP library for the RSED address space.
the Unix part located in /usr/lpp/IBM/zexpl contains some environmental and 
configuration files
it was not hard to setup and once the client is installed you get one view of 
your workstation MVS and USS files, TSO command window and a USS window to run 
scripts



File 755 2020-02-20 11:49 CPV8281 1387 ISPF.conf
File 755 2020-02-20 11:50 CPV8281 2916 process_audit.rex
File 755 2020-02-20 11:50 CPV8281 2187 process_logon.sh
File 755 2020-02-20 11:50 CPV8281 324 pushtoclient.properties
File 755 2020-02-20 11:49 CPV8281 7844 rse.env
File 755 2020-02-20 11:49 CPV8281 308 rsecomm.properties
File 755 2020-02-20 11:50 CPV8281 294 ssl.properties


Carmen Vitullo

- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, June 18, 2020 12:52:18 PM
Subject: Re: Good FTP client for MVS data set access

Looks like some of this might be part of the "Remote System Explorer" 
perspective, which I don't see to have configured. Does this require z/OS 
configuration?


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Thursday, June 18, 2020 6:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

the FMID is (HALG320) the GUI client is Aqua explorer for zos, IIRC
I currently do not have the GUI client on the loaner laptop I'm using at home 
so I cannot be 100% sure


Carmen Vitullo

----- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 17, 2020 5:29:58 PM
Subject: Re: Good FTP client for MVS data set access

Hey Carmen,
Is that z/OS Explorer (free) or is that IBM Developer (formerly Rational 
Developer -- expensive) for Z that you are referring to? I know that z/OS 
Explorer uses FTP under the covers, but I've not seen it having a normal drag 
and drop style FTP GUI, or have I seen an ability to run shell scripts or TSO 
commands. Perhaps I'm overlooking some things.


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, June 17, 2020 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

I've always liked the reflections FTP client, I've not been able to use any 
other client, but I am not starting to use IBM's Z/explorer , that GUI along 
with an MVS address space will get you MVS dataset, USS filesystem, local 
fileystems access plus the ability to run shell scripts, and tso command from 
the GUI
moving or coping datasets can be done using a drag and drop.


Carmen Vitullo

----- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 17, 2020 1:09:55 PM
Subject: Good FTP client for MVS data set access

What FTP client do you use to access MVS data sets? Do you like it?

I personally use the FTP Client that is part of Micro Focus (formerly 
Attachmate) Reflection Desktop for IBM (Reflection Workspace). Being an 
application suite dedicated to mainframe access (the application is primarily a 
TN3270 client), the FTP Client that goes along with it seems to truly 
understand the idiosyncrasies of MVS and works quite well with it.

On the other hand, only a limited number of users in our shop are "authorized" 
to use Reflection, so they cannot use its FTP client. They are stuck 
(currently) with an MVS hostile (IMO) 

Re: Good FTP client for MVS data set access

[Frank Swarbrick]

I'm not a sysprog so I can't configure anything myself.  I don't that we have 
an SFEK* set of libraries on the system currently.    The documentation I've 
just now looked at seems to indicate this is part of IBM Developer/Rational 
Developer for z/OS.



From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Thursday, June 18, 2020 12:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

From what I recall, I don't have any doc at home, the configuration is done 
using the FEF.SFEKSAMP library for the RSED address space.
the Unix part located in /usr/lpp/IBM/zexpl contains some environmental and 
configuration files
it was not hard to setup and once the client is installed you get one view of 
your workstation MVS and USS files, TSO command window and a USS window to run 
scripts



File 755 2020-02-20 11:49 CPV8281 1387 ISPF.conf
File 755 2020-02-20 11:50 CPV8281 2916 process_audit.rex
File 755 2020-02-20 11:50 CPV8281 2187 process_logon.sh
File 755 2020-02-20 11:50 CPV8281 324 pushtoclient.properties
File 755 2020-02-20 11:49 CPV8281 7844 rse.env
File 755 2020-02-20 11:49 CPV8281 308 rsecomm.properties
File 755 2020-02-20 11:50 CPV8281 294 ssl.properties


Carmen Vitullo

- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, June 18, 2020 12:52:18 PM
Subject: Re: Good FTP client for MVS data set access

Looks like some of this might be part of the "Remote System Explorer" 
perspective, which I don't see to have configured. Does this require z/OS 
configuration?


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Thursday, June 18, 2020 6:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

the FMID is (HALG320) the GUI client is Aqua explorer for zos, IIRC
I currently do not have the GUI client on the loaner laptop I'm using at home 
so I cannot be 100% sure


Carmen Vitullo

- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 17, 2020 5:29:58 PM
Subject: Re: Good FTP client for MVS data set access

Hey Carmen,
Is that z/OS Explorer (free) or is that IBM Developer (formerly Rational 
Developer -- expensive) for Z that you are referring to? I know that z/OS 
Explorer uses FTP under the covers, but I've not seen it having a normal drag 
and drop style FTP GUI, or have I seen an ability to run shell scripts or TSO 
commands. Perhaps I'm overlooking some things.


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, June 17, 2020 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

I've always liked the reflections FTP client, I've not been able to use any 
other client, but I am not starting to use IBM's Z/explorer , that GUI along 
with an MVS address space will get you MVS dataset, USS filesystem, local 
fileystems access plus the ability to run shell scripts, and tso command from 
the GUI
moving or coping datasets can be done using a drag and drop.


Carmen Vitullo

- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 17, 2020 1:09:55 PM
Subject: Good FTP client for MVS data set access

What FTP client do you use to access MVS data sets? Do you like it?

I personally use the FTP Client that is part of Micro Focus (formerly 
Attachmate) Reflection Desktop for IBM (Reflection Workspace). Being an 
application suite dedicated to mainframe access (the application is primarily a 
TN3270 client), the FTP Client that goes along with it seems to truly 
understand the idiosyncrasies of MVS and works quite well with it.

On the other hand, only a limited number of users in our shop are "authorized" 
to use Reflection, so they cannot use its FTP client. They are stuck 
(currently) with an MVS hostile (IMO) application called CuteFTP.

Are there any good "freestanding" FTP GUI applications that are "MVS friendly"?


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

Re: Good FTP client for MVS data set access

[Frank Swarbrick]

Looks like some of this might be part of the "Remote System Explorer" 
perspective, which I don't see to have configured.  Does this require z/OS 
configuration?


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Thursday, June 18, 2020 6:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

the FMID is (HALG320) the GUI client is Aqua explorer for zos, IIRC
I currently do not have the GUI client on the loaner laptop I'm using at home 
so I cannot be 100% sure


Carmen Vitullo

- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 17, 2020 5:29:58 PM
Subject: Re: Good FTP client for MVS data set access

Hey Carmen,
Is that z/OS Explorer (free) or is that IBM Developer (formerly Rational 
Developer -- expensive) for Z that you are referring to? I know that z/OS 
Explorer uses FTP under the covers, but I've not seen it having a normal drag 
and drop style FTP GUI, or have I seen an ability to run shell scripts or TSO 
commands. Perhaps I'm overlooking some things.


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, June 17, 2020 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

I've always liked the reflections FTP client, I've not been able to use any 
other client, but I am not starting to use IBM's Z/explorer , that GUI along 
with an MVS address space will get you MVS dataset, USS filesystem, local 
fileystems access plus the ability to run shell scripts, and tso command from 
the GUI
moving or coping datasets can be done using a drag and drop.


Carmen Vitullo

- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 17, 2020 1:09:55 PM
Subject: Good FTP client for MVS data set access

What FTP client do you use to access MVS data sets? Do you like it?

I personally use the FTP Client that is part of Micro Focus (formerly 
Attachmate) Reflection Desktop for IBM (Reflection Workspace). Being an 
application suite dedicated to mainframe access (the application is primarily a 
TN3270 client), the FTP Client that goes along with it seems to truly 
understand the idiosyncrasies of MVS and works quite well with it.

On the other hand, only a limited number of users in our shop are "authorized" 
to use Reflection, so they cannot use its FTP client. They are stuck 
(currently) with an MVS hostile (IMO) application called CuteFTP.

Are there any good "freestanding" FTP GUI applications that are "MVS friendly"?


--
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: Good FTP client for MVS data set access

[Frank Swarbrick]

I'll have to look more at this.  Thanks.


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Thursday, June 18, 2020 5:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

Morning Frank, this is the Free Z/explorer I have installed




Carmen Vitullo

- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 17, 2020 5:29:58 PM
Subject: Re: Good FTP client for MVS data set access

Hey Carmen,
Is that z/OS Explorer (free) or is that IBM Developer (formerly Rational 
Developer -- expensive) for Z that you are referring to? I know that z/OS 
Explorer uses FTP under the covers, but I've not seen it having a normal drag 
and drop style FTP GUI, or have I seen an ability to run shell scripts or TSO 
commands. Perhaps I'm overlooking some things.


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, June 17, 2020 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

I've always liked the reflections FTP client, I've not been able to use any 
other client, but I am not starting to use IBM's Z/explorer , that GUI along 
with an MVS address space will get you MVS dataset, USS filesystem, local 
fileystems access plus the ability to run shell scripts, and tso command from 
the GUI
moving or coping datasets can be done using a drag and drop.


Carmen Vitullo

- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 17, 2020 1:09:55 PM
Subject: Good FTP client for MVS data set access

What FTP client do you use to access MVS data sets? Do you like it?

I personally use the FTP Client that is part of Micro Focus (formerly 
Attachmate) Reflection Desktop for IBM (Reflection Workspace). Being an 
application suite dedicated to mainframe access (the application is primarily a 
TN3270 client), the FTP Client that goes along with it seems to truly 
understand the idiosyncrasies of MVS and works quite well with it.

On the other hand, only a limited number of users in our shop are "authorized" 
to use Reflection, so they cannot use its FTP client. They are stuck 
(currently) with an MVS hostile (IMO) application called CuteFTP.

Are there any good "freestanding" FTP GUI applications that are "MVS friendly"?


--
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: Improve OMVS cp performance?

[Frank Swarbrick]

I'll see if I can carve out some time to put this together.  If I do I'll 
probably post it here before making an official request, as people here are 
much smarter than me and will probably provide good feedback.  Any initial 
thoughts from anyone here are also welcome!


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Wednesday, June 17, 2020 6:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Improve OMVS cp performance?

I think that it is worth an RFE if you can put together a compelling business 
case. Be sure to cover any functionality that's important to you, e.g.,

 Program Objects?
 PDS(E) directory data
 Performance for multiple members in the same PDS(E)
 Record formats
 Character set issues
 Line ending conventions, e.g., CRLF, LF, NEL, NL


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Wednesday, June 17, 2020 6:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

Do you think its worth an RFE?



From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Wednesday, June 17, 2020 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Improve OMVS cp performance?

I think that technically it would be a piece of cake, although it would take 
some careful design to make it efficient and  transparent.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Wednesday, June 17, 2020 6:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

I mean technical effort on IBM's part to implement it.

It seems to me that, along with some mapping/naming rules and sensible 
defaults, in addition to Lionel's use case it could also be useful for FTP 
clients, so non-z/OS users can have "understandable" access to MVS data sets 
w/o having to even know that's what they are doing.


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Wednesday, June 17, 2020 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Improve OMVS cp performance?

Technical effort or administrative effort. I suspect that it will be a lot more 
involved to get it approved than to actually implement it.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Wednesday, June 17, 2020 1:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

I wonder what kind of effort it might be for z/OS to support Unix path names as 
aliases/links to MVS legacy data sets.  Probably a lot of work, but it seems 
like it would be quite useful for situations such as this where the Unix 
application only supports Unix paths.

Just a wild thought.  Not opening an RFE for it or anything, unless someone can 
say it sounds at all reasonable.

By the way, z/OS Unix is z/OS, as some like to say.  I prefer to use the terms 
"legacy data sets" or "MVS data sets" saying "the z/OS side".  It's all z/OS!  


From: IBM Mainframe Discussion List  on behalf of 
Lionel B Dyck 
Sent: Wednesday, June 17, 2020 6:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Improve OMVS cp performance?

Kirk - thank you for the ideas.

What I'm doing is in the ZIGI (see 
https://secure-web.cisco.com/16y9woZ-KKNGioIsmrX3l0VloGx62ZmJbaIDUMxNEu3X4_DmZ6nR-qUkWT-lIJna_FSvyQDSqjJHfEE6JVKyGupXrO9tZC1YO3pkDcHdunPFAORyGUqh2yJwHFSDhnEN1TtNm5g8EvDfoNzNsauNWFq4Y_5InaggC3Djt9nYuC7fv4BlPnY08D6jHmqOOticix9GjXAoL9A2DFzRItsD7RyJt7tNFtjfWZFZu3E-ycsOQlpWifUJvx4QAe6GSVyJinMUnvQ0cG7veolIcRj9KdGLoHSjf0diK1UVO0q3LRSzwcLSv9K5aNecTApJaWO0YizryqgYg3UqT4cDPbHG-sLS4b_8_CV6WTBJFipgSWaH1SnA6EsjjHognkaFW_J9WuXnPRq9b-odk_z1k3sQt4Li6oWKIpRIBAyK2b2RvwvBW2Vq0v_9ybXpgNqjKaNAI/https%3A%2F%2Fzigi.rocks)
 where I need to copy PDS members to/from USS so that Git can manage them. With 
small projects this isn't an issue but with larger projects it could take 
enough time for you to go to lunch ☹

Btw. I voted your RFE.


Lionel B. Dyck <
Website: 
https://secure-web.cisco.com/1M2R-g6A5gGoKDKQxyFiYYV7WXr9OdUyu6Ixa3zjpJ6CJbQmAW8FtYkxjXgLOeIDnvjGXI0lOmtzYcfyzGiCcRXXoTJiT7jNfLgtZaozhB1snDKIsuSqxrUFNz5eHiU9FuFPR_nAf45mLn3swUsAfJB77d53cb7b4d1kHMZxbp69FYPo4AbO7fSOmun_rPhg-ArrddqzghsnvKXAWOl88mKZ5TLED7NhEjdb1G3D2OauWeZmmrYS7YNoaApm9ci2dFr9POiD9mLXAhZEOO5HJImkuCdd3O0jGChFv7l7yIQnE1_ZXQ--KqkeAjWI7XPrhKZnpDex2AYCsAZ0f-4tNYyL1XagaW7uBJxH8OFBFFApall8WssfmP94dlBt_13DdsDtCrFzObRE8x5b5008xoJkZ08eOE8Hsk

Re: Improve OMVS cp performance?

[Frank Swarbrick]

Do you think its worth an RFE?



From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Wednesday, June 17, 2020 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Improve OMVS cp performance?

I think that technically it would be a piece of cake, although it would take 
some careful design to make it efficient and  transparent.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Wednesday, June 17, 2020 6:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

I mean technical effort on IBM's part to implement it.

It seems to me that, along with some mapping/naming rules and sensible 
defaults, in addition to Lionel's use case it could also be useful for FTP 
clients, so non-z/OS users can have "understandable" access to MVS data sets 
w/o having to even know that's what they are doing.


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Wednesday, June 17, 2020 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Improve OMVS cp performance?

Technical effort or administrative effort. I suspect that it will be a lot more 
involved to get it approved than to actually implement it.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Wednesday, June 17, 2020 1:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

I wonder what kind of effort it might be for z/OS to support Unix path names as 
aliases/links to MVS legacy data sets.  Probably a lot of work, but it seems 
like it would be quite useful for situations such as this where the Unix 
application only supports Unix paths.

Just a wild thought.  Not opening an RFE for it or anything, unless someone can 
say it sounds at all reasonable.

By the way, z/OS Unix is z/OS, as some like to say.  I prefer to use the terms 
"legacy data sets" or "MVS data sets" saying "the z/OS side".  It's all z/OS!  


From: IBM Mainframe Discussion List  on behalf of 
Lionel B Dyck 
Sent: Wednesday, June 17, 2020 6:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Improve OMVS cp performance?

Kirk - thank you for the ideas.

What I'm doing is in the ZIGI (see 
https://secure-web.cisco.com/16y9woZ-KKNGioIsmrX3l0VloGx62ZmJbaIDUMxNEu3X4_DmZ6nR-qUkWT-lIJna_FSvyQDSqjJHfEE6JVKyGupXrO9tZC1YO3pkDcHdunPFAORyGUqh2yJwHFSDhnEN1TtNm5g8EvDfoNzNsauNWFq4Y_5InaggC3Djt9nYuC7fv4BlPnY08D6jHmqOOticix9GjXAoL9A2DFzRItsD7RyJt7tNFtjfWZFZu3E-ycsOQlpWifUJvx4QAe6GSVyJinMUnvQ0cG7veolIcRj9KdGLoHSjf0diK1UVO0q3LRSzwcLSv9K5aNecTApJaWO0YizryqgYg3UqT4cDPbHG-sLS4b_8_CV6WTBJFipgSWaH1SnA6EsjjHognkaFW_J9WuXnPRq9b-odk_z1k3sQt4Li6oWKIpRIBAyK2b2RvwvBW2Vq0v_9ybXpgNqjKaNAI/https%3A%2F%2Fzigi.rocks)
 where I need to copy PDS members to/from USS so that Git can manage them. With 
small projects this isn't an issue but with larger projects it could take 
enough time for you to go to lunch ☹

Btw. I voted your RFE.


Lionel B. Dyck <
Website: 
https://secure-web.cisco.com/1M2R-g6A5gGoKDKQxyFiYYV7WXr9OdUyu6Ixa3zjpJ6CJbQmAW8FtYkxjXgLOeIDnvjGXI0lOmtzYcfyzGiCcRXXoTJiT7jNfLgtZaozhB1snDKIsuSqxrUFNz5eHiU9FuFPR_nAf45mLn3swUsAfJB77d53cb7b4d1kHMZxbp69FYPo4AbO7fSOmun_rPhg-ArrddqzghsnvKXAWOl88mKZ5TLED7NhEjdb1G3D2OauWeZmmrYS7YNoaApm9ci2dFr9POiD9mLXAhZEOO5HJImkuCdd3O0jGChFv7l7yIQnE1_ZXQ--KqkeAjWI7XPrhKZnpDex2AYCsAZ0f-4tNYyL1XagaW7uBJxH8OFBFFApall8WssfmP94dlBt_13DdsDtCrFzObRE8x5b5008xoJkZ08eOE8HskcXulsVEDlDkwgBNRyy-qwYCMUyXsKHV/https%3A%2F%2Fwww.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 
Kirk Wolf
Sent: Wednesday, June 17, 2020 7:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

Hi Lionel,

Can you provide any more detail on how you are invoking "cp" ?

- With cp, there won't be any way to avoid opening the PDSE for each member, 
but you might get some improvement by allocating a DD to the PDSE and then 
passing  //DD(member) to cp, so as to avoid allocation each time.
 If you do this, then you will also know for sure if you are using local spawn 
(_BPX_SHAREAS=YES), since otherwise the DD won't be visible if a new AS was 
forked.

- The other issue would be the cost of spawning a Unix process for each
member, even if local spawned.   I haven't tested this, but you might write
a shell script that is passed the DD as arg and member names as lines to
stdin.   Then the script could do the cp for each member.   The hope is
th

Re: Good FTP client for MVS data set access

[Frank Swarbrick]

Our whitelisting software blocks every execution of a BAT or CMD file as being 
possibly dangerous.  Yikes!  At least they allow us to use manual command line 
commands.


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Wednesday, June 17, 2020 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

+1 for CLI!

-1 for corporate nannies who want to log every time you use a command prompt 
window because that is so dangerous for the masses . . . or maybe especially 
for programmers who *think* they know what they are doing . . .

I use FileZilla, it has a few quirks but mostly it works for my limited and 
occasional needs.  I fall back to the CLI version when all else fails.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jackson, Rob
Sent: Wednesday, June 17, 2020 2:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Good FTP client for MVS data set access

My opinion, which is absolutely worthless:  FileZilla sucks as a mainframe FTP 
client.  BZ is far superior.  If you don't need SSL/TLS (which, of course, you 
do), the "DOS" client is better than both.  Who doesn't love a good ol' CLI?

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Wednesday, June 17, 2020 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Good FTP client for MVS data set access

[External Email. Exercise caution when clicking links or opening attachments.]

I use Filezilla (Open Source) and Bluezone (now from Rocket) Both have their 
pluses and minuses.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Frank Swarbrick
> Sent: Wednesday, June 17, 2020 11:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Good FTP client for MVS data set access
>
> What FTP client do you use to access MVS data sets?  Do you like it?
>
> I personally use the FTP Client that is part of Micro Focus (formerly
> Attachmate) Reflection Desktop for IBM (Reflection Workspace).  Being
> an application suite dedicated to mainframe access (the application is
> primarily a
> TN3270 client), the FTP Client that goes along with it seems to truly
> understand the idiosyncrasies of MVS and works quite well with it.
>
> On the other hand, only a limited number of users in our shop are
> "authorized" to use Reflection, so they cannot use its FTP client.
> They are stuck (currently) with an MVS hostile (IMO) application called 
> CuteFTP.
>
> Are there any good "freestanding" FTP GUI applications that are "MVS
> friendly"?
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

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

Re: Good FTP client for MVS data set access

[Frank Swarbrick]

I just tried using WinSCP today and I couldn't get it to recognize MVS data 
sets.  Is there some option I am missing?  This might be ideal in that it, 
unlike the others already mentioned, is currently used in our environment so 
wouldn't require a lot of bureaucracy to just perform a POC.


From: IBM Mainframe Discussion List  on behalf of 
Jackson, Rob 
Sent: Wednesday, June 17, 2020 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

WinSCP is decent; there are countless class libraries as well.  I just enjoy 
the DOS CLI.  Man, I wish they'd add encryption to it.

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, June 17, 2020 2:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Good FTP client for MVS data set access

[External Email. Exercise caution when clicking links or opening attachments.]

The devil is in the details. I want tools that work together. That includes the 
ability to mix and match CLI and GUI. I should be able to script the GUI in a 
decent language.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jackson, Rob [rwjack...@firsthorizon.com]
Sent: Wednesday, June 17, 2020 2:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Good FTP client for MVS data set access

My opinion, which is absolutely worthless:  FileZilla sucks as a mainframe FTP 
client.  BZ is far superior.  If you don't need SSL/TLS (which, of course, you 
do), the "DOS" client is better than both.  Who doesn't love a good ol' CLI?

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Wednesday, June 17, 2020 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Good FTP client for MVS data set access

[External Email. Exercise caution when clicking links or opening attachments.]

I use Filezilla (Open Source) and Bluezone (now from Rocket) Both have their 
pluses and minuses.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Frank Swarbrick
> Sent: Wednesday, June 17, 2020 11:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Good FTP client for MVS data set access
>
> What FTP client do you use to access MVS data sets?  Do you like it?
>
> I personally use the FTP Client that is part of Micro Focus (formerly
> Attachmate) Reflection Desktop for IBM (Reflection Workspace).  Being
> an application suite dedicated to mainframe access (the application is
> primarily a
> TN3270 client), the FTP Client that goes along with it seems to truly
> understand the idiosyncrasies of MVS and works quite well with it.
>
> On the other hand, only a limited number of users in our shop are
> "authorized" to use Reflection, so they cannot use its FTP client.
> They are stuck (currently) with an MVS hostile (IMO) application called 
> CuteFTP.
>
> Are there any good "freestanding" FTP GUI applications that are "MVS
> friendly"?
>
>
> --
> 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 Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
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: Good FTP client for MVS data set access

[Frank Swarbrick]

My goodness, I absolutely agree that a command line interface is ideal.  Which, 
because of no SSL/TLS support, as you say eliminates the Windows provided 
client.  In the past the only good (and free) command line client I've found 
for Windows is MoveIt Freely.  I used to use it extensively until my company 
implemented whitelisting (can I still say that?) software and I never bothered 
to get it approved.  Ugh, I hate "security".  If I find a good GUI FTP client 
that my coworkers would actually use I could go through the bother of getting 
it approved.  Not sure if the company would be up for buying something because 
we already have something that kinda/sorta works.

Back to command line, if we could have WSL activated on our workstations we 
could have all of the goodness of Linux command line tools.  Including, I 
believe, SSL/TLS capable FTP client.  I've never asked for it, but think about 
it often...  


From: IBM Mainframe Discussion List  on behalf of 
Jackson, Rob 
Sent: Wednesday, June 17, 2020 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

My opinion, which is absolutely worthless:  FileZilla sucks as a mainframe FTP 
client.  BZ is far superior.  If you don't need SSL/TLS (which, of course, you 
do), the "DOS" client is better than both.  Who doesn't love a good ol' CLI?

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Wednesday, June 17, 2020 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Good FTP client for MVS data set access

[External Email. Exercise caution when clicking links or opening attachments.]

I use Filezilla (Open Source) and Bluezone (now from Rocket) Both have their 
pluses and minuses.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Frank Swarbrick
> Sent: Wednesday, June 17, 2020 11:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Good FTP client for MVS data set access
>
> What FTP client do you use to access MVS data sets?  Do you like it?
>
> I personally use the FTP Client that is part of Micro Focus (formerly
> Attachmate) Reflection Desktop for IBM (Reflection Workspace).  Being
> an application suite dedicated to mainframe access (the application is
> primarily a
> TN3270 client), the FTP Client that goes along with it seems to truly
> understand the idiosyncrasies of MVS and works quite well with it.
>
> On the other hand, only a limited number of users in our shop are
> "authorized" to use Reflection, so they cannot use its FTP client.
> They are stuck (currently) with an MVS hostile (IMO) application called 
> CuteFTP.
>
> Are there any good "freestanding" FTP GUI applications that are "MVS
> friendly"?
>
>
> --
> 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
Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
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: Improve OMVS cp performance?

[Frank Swarbrick]

I mean technical effort on IBM's part to implement it.

It seems to me that, along with some mapping/naming rules and sensible 
defaults, in addition to Lionel's use case it could also be useful for FTP 
clients, so non-z/OS users can have "understandable" access to MVS data sets 
w/o having to even know that's what they are doing.


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Wednesday, June 17, 2020 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Improve OMVS cp performance?

Technical effort or administrative effort. I suspect that it will be a lot more 
involved to get it approved than to actually implement it.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Wednesday, June 17, 2020 1:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

I wonder what kind of effort it might be for z/OS to support Unix path names as 
aliases/links to MVS legacy data sets.  Probably a lot of work, but it seems 
like it would be quite useful for situations such as this where the Unix 
application only supports Unix paths.

Just a wild thought.  Not opening an RFE for it or anything, unless someone can 
say it sounds at all reasonable.

By the way, z/OS Unix is z/OS, as some like to say.  I prefer to use the terms 
"legacy data sets" or "MVS data sets" saying "the z/OS side".  It's all z/OS!  


From: IBM Mainframe Discussion List  on behalf of 
Lionel B Dyck 
Sent: Wednesday, June 17, 2020 6:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Improve OMVS cp performance?

Kirk - thank you for the ideas.

What I'm doing is in the ZIGI (see 
https://secure-web.cisco.com/16y9woZ-KKNGioIsmrX3l0VloGx62ZmJbaIDUMxNEu3X4_DmZ6nR-qUkWT-lIJna_FSvyQDSqjJHfEE6JVKyGupXrO9tZC1YO3pkDcHdunPFAORyGUqh2yJwHFSDhnEN1TtNm5g8EvDfoNzNsauNWFq4Y_5InaggC3Djt9nYuC7fv4BlPnY08D6jHmqOOticix9GjXAoL9A2DFzRItsD7RyJt7tNFtjfWZFZu3E-ycsOQlpWifUJvx4QAe6GSVyJinMUnvQ0cG7veolIcRj9KdGLoHSjf0diK1UVO0q3LRSzwcLSv9K5aNecTApJaWO0YizryqgYg3UqT4cDPbHG-sLS4b_8_CV6WTBJFipgSWaH1SnA6EsjjHognkaFW_J9WuXnPRq9b-odk_z1k3sQt4Li6oWKIpRIBAyK2b2RvwvBW2Vq0v_9ybXpgNqjKaNAI/https%3A%2F%2Fzigi.rocks)
 where I need to copy PDS members to/from USS so that Git can manage them. With 
small projects this isn't an issue but with larger projects it could take 
enough time for you to go to lunch ☹

Btw. I voted your RFE.


Lionel B. Dyck <
Website: 
https://secure-web.cisco.com/1M2R-g6A5gGoKDKQxyFiYYV7WXr9OdUyu6Ixa3zjpJ6CJbQmAW8FtYkxjXgLOeIDnvjGXI0lOmtzYcfyzGiCcRXXoTJiT7jNfLgtZaozhB1snDKIsuSqxrUFNz5eHiU9FuFPR_nAf45mLn3swUsAfJB77d53cb7b4d1kHMZxbp69FYPo4AbO7fSOmun_rPhg-ArrddqzghsnvKXAWOl88mKZ5TLED7NhEjdb1G3D2OauWeZmmrYS7YNoaApm9ci2dFr9POiD9mLXAhZEOO5HJImkuCdd3O0jGChFv7l7yIQnE1_ZXQ--KqkeAjWI7XPrhKZnpDex2AYCsAZ0f-4tNYyL1XagaW7uBJxH8OFBFFApall8WssfmP94dlBt_13DdsDtCrFzObRE8x5b5008xoJkZ08eOE8HskcXulsVEDlDkwgBNRyy-qwYCMUyXsKHV/https%3A%2F%2Fwww.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 
Kirk Wolf
Sent: Wednesday, June 17, 2020 7:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

Hi Lionel,

Can you provide any more detail on how you are invoking "cp" ?

- With cp, there won't be any way to avoid opening the PDSE for each member, 
but you might get some improvement by allocating a DD to the PDSE and then 
passing  //DD(member) to cp, so as to avoid allocation each time.
 If you do this, then you will also know for sure if you are using local spawn 
(_BPX_SHAREAS=YES), since otherwise the DD won't be visible if a new AS was 
forked.

- The other issue would be the cost of spawning a Unix process for each
member, even if local spawned.   I haven't tested this, but you might write
a shell script that is passed the DD as arg and member names as lines to
stdin.   Then the script could do the cp for each member.   The hope is
that since cp is also a shell "built-in" you might avoid spawning processes for 
each one.

- the "best" performance possible would be writing your own BPAM code that
also does the Unix fileio.   Assembler is fine, but I would use C/++ for
everything except the low level BPAM I/O routines, since I would probably use 
buffered filestreams for the Unix files.

FWIW: It's a pity that the IBM C library doesn't have any support for 
BLDL/NOTE/POINT processing of PDS/Es -- see my old RFE and vote if you
agree:
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=80811



On Wed, Jun 17, 2020 at 5:30 AM Lionel B Dyck  wrote:

> " What's on the non-OMVS side?  a  PDS(E)?

Re: Good FTP client for MVS data set access

[Frank Swarbrick]

Hey Carmen,
Is that z/OS Explorer (free) or is that IBM Developer (formerly Rational 
Developer -- expensive) for Z that you are referring to?  I know that z/OS 
Explorer uses FTP under the covers, but I've not seen it having a normal drag 
and drop style FTP GUI, or have I seen an ability to run shell scripts or TSO 
commands.  Perhaps I'm overlooking some things.


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, June 17, 2020 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Good FTP client for MVS data set access

I've always liked the reflections FTP client, I've not been able to use any 
other client, but I am not starting to use IBM's Z/explorer , that GUI along 
with an MVS address space will get you MVS dataset, USS filesystem, local 
fileystems access plus the ability to run shell scripts, and tso command from 
the GUI
moving or coping datasets can be done using a drag and drop.


Carmen Vitullo

- Original Message -

From: "Frank Swarbrick" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, June 17, 2020 1:09:55 PM
Subject: Good FTP client for MVS data set access

What FTP client do you use to access MVS data sets? Do you like it?

I personally use the FTP Client that is part of Micro Focus (formerly 
Attachmate) Reflection Desktop for IBM (Reflection Workspace). Being an 
application suite dedicated to mainframe access (the application is primarily a 
TN3270 client), the FTP Client that goes along with it seems to truly 
understand the idiosyncrasies of MVS and works quite well with it.

On the other hand, only a limited number of users in our shop are "authorized" 
to use Reflection, so they cannot use its FTP client. They are stuck 
(currently) with an MVS hostile (IMO) application called CuteFTP.

Are there any good "freestanding" FTP GUI applications that are "MVS friendly"?


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

Good FTP client for MVS data set access

[Frank Swarbrick]

What FTP client do you use to access MVS data sets?  Do you like it?

I personally use the FTP Client that is part of Micro Focus (formerly 
Attachmate) Reflection Desktop for IBM (Reflection Workspace).  Being an 
application suite dedicated to mainframe access (the application is primarily a 
TN3270 client), the FTP Client that goes along with it seems to truly 
understand the idiosyncrasies of MVS and works quite well with it.

On the other hand, only a limited number of users in our shop are "authorized" 
to use Reflection, so they cannot use its FTP client.  They are stuck 
(currently) with an MVS hostile (IMO) application called CuteFTP.

Are there any good "freestanding" FTP GUI applications that are "MVS friendly"?


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

Re: Improve OMVS cp performance?

[Frank Swarbrick]

I wonder what kind of effort it might be for z/OS to support Unix path names as 
aliases/links to MVS legacy data sets.  Probably a lot of work, but it seems 
like it would be quite useful for situations such as this where the Unix 
application only supports Unix paths.

Just a wild thought.  Not opening an RFE for it or anything, unless someone can 
say it sounds at all reasonable.

By the way, z/OS Unix is z/OS, as some like to say.  I prefer to use the terms 
"legacy data sets" or "MVS data sets" saying "the z/OS side".  It's all z/OS!  


From: IBM Mainframe Discussion List  on behalf of 
Lionel B Dyck 
Sent: Wednesday, June 17, 2020 6:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Improve OMVS cp performance?

Kirk - thank you for the ideas.

What I'm doing is in the ZIGI (see https://zigi.rocks) where I need to copy PDS 
members to/from USS so that Git can manage them. With small projects this isn't 
an issue but with larger projects it could take enough time for you to go to 
lunch ☹

Btw. I voted your RFE.


Lionel B. Dyck <
Website: https://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 
Kirk Wolf
Sent: Wednesday, June 17, 2020 7:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

Hi Lionel,

Can you provide any more detail on how you are invoking "cp" ?

- With cp, there won't be any way to avoid opening the PDSE for each member, 
but you might get some improvement by allocating a DD to the PDSE and then 
passing  //DD(member) to cp, so as to avoid allocation each time.
 If you do this, then you will also know for sure if you are using local spawn 
(_BPX_SHAREAS=YES), since otherwise the DD won't be visible if a new AS was 
forked.

- The other issue would be the cost of spawning a Unix process for each
member, even if local spawned.   I haven't tested this, but you might write
a shell script that is passed the DD as arg and member names as lines to
stdin.   Then the script could do the cp for each member.   The hope is
that since cp is also a shell "built-in" you might avoid spawning processes for 
each one.

- the "best" performance possible would be writing your own BPAM code that
also does the Unix fileio.   Assembler is fine, but I would use C/++ for
everything except the low level BPAM I/O routines, since I would probably use 
buffered filestreams for the Unix files.

FWIW: It's a pity that the IBM C library doesn't have any support for 
BLDL/NOTE/POINT processing of PDS/Es -- see my old RFE and vote if you
agree:
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=80811



On Wed, Jun 17, 2020 at 5:30 AM Lionel B Dyck  wrote:

> " What's on the non-OMVS side?  a  PDS(E)?  Multiple PS data sets?"
>
> On the z/OS side is a PDS(E).
>
> Thanks
>
>
> Lionel B. Dyck <
> Website: https://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 Paul Gilmartin
> Sent: Tuesday, June 16, 2020 9:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Improve OMVS cp performance?
>
> On Tue, 16 Jun 2020 20:34:59 -0500, Lionel B Dyck wrote:
>
> >Any suggestions on how to speed up cp copying multiple file to and
> >from
> z/OS?
> >
> >I gave SHAREAS=YES. Anything else?  Can I control buffers or ?
> >
> What's on the non-OMVS side?  a  PDS(E)?  Multiple PS data sets?
>
> I might suggest as an extreme measure Rexx under ISPF using ADDRESS
> SYSCALL I/O for OMVS and LM services for Classic.
> SYSCALL READFILE/WRITEFILE are available for text files only.
>
> -- 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

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

Re: "Everyone wants to retire mainframes"

[Frank Swarbrick]

Apparently that world is not this world.


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Thursday, June 11, 2020 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: "Everyone wants to retire mainframes"

> DBD  or PSB library.

In a kinder, more gentle world, the message would tell you which.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Thursday, June 11, 2020 1:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "Everyone wants to retire mainframes"

Here are all of the possibly relevant parts from the JESMSGLG for a similar 
occurrence that I just caused.

+*DFS0929I BLDL FAILED FOR MEMBER --ABCDEFG
IEA995I SYMPTOM DUMP OUTPUT  830
  USER COMPLETION CODE=0929
 TIME=10.52.44  SEQ=18497  CPU=  ASID=0038
 PSW AT TIME OF ERROR  078D1000   9012762C  ILC 2  INTC 0D
   ACTIVE MODULE   ADDRESS=_1011A000  OFFSET=D62C
   NAME=DFSDLBL0
   DATA AT PSW  10127626 - D234181F  0A0DD71C  D200D200
   GR 0:    1: 83A1
  2: 7660   3: 84B0
  4: 0005D060   5: 7658
  6: 10126358   7: 0005D060
  8: 00019928   9: 00019F68
  A:    B: 0001
  C: 1011C048   D: 101260B0
  E: 90127E9E   F: 83A1
 END OF SYMPTOM DUMP
DFS627I IMS RTM CLEANUP ( EOT ) COMPLETE FOR JS DDADMP  .PROC01  .STEP01  ,RC=00
IEF450I DDADMP STEP01 PROC01 - ABEND=S000 U0929 REASON=  832

There are no additional DDs beyond this and the standard JESJCL and JESYSMSG 
which have no additional relevant data.

Of course if you look up the error in the manual it does provide slightly more 
useful information.

DFS0929I

 BLDL FAILED FOR MEMBER -- member name

 Explanation
 ~~~
 A BLDL was issued for the named member. The member was not found in the DBD
 or PSB library.

 System action
 ~
 Abend 0929 is issued if batch DL/I was running. ACBGEN processing continues
 if the ACBGEN utility was being run.

 Programmer response
 ~~~
 Correct the error in the appropriate library, and rerun the program.




From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Wednesday, June 10, 2020 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: "Everyone wants to retire mainframes"

The problem with that message is not that it mentions BLDL, but that it fails 
to mention other relevant data. At a minimum, what was the ddname and what was 
the return code. Ideally I'd like secondary messages listing the libraries in 
the concatenation.

A user ABEND without a message is hard to justify. Are you sure that it wasn't 
in the joblog?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Wednesday, June 10, 2020 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "Everyone wants to retire mainframes"

Here's a quote from a message I posted to this list in 2009:

"I have a very basic one to complain about:

DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ

This really means that the specified PSB DDMPPSZ is not in the specified IMS 
library.  Why can't it just say that?  As an application programmer do I really 
need to know that BLDL means, well, whatever it means?

Of course IMS has some that are even worse.  Sometimes I just get something 
like:
USER COMPLETION CODE=
without any message at all.  The first time I ran in to it it took me a heck of 
a time to figure out I need to look in the IMS manual to find out what the 
error was.  For all I could tell it was a user application error, but I 
couldn't see what.  Now all of the other developers on our VSE to z/OS 
conversion team just ask me what the errors are, because trying to find them in 
the manuals is too often too painful.  Hopefully I'll get them trained some day!

I've got to say, coming from VSE their error messages are, in general, much 
better.  Of course as a developer I hate dealing with creating error messages 
for my own apps, so I can understand why IBM has such issues...  :-)"

Things have not improved much, if it all, in this regard in the last ten years. 
 

From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab 
Sent: Tuesday, June 9, 2020 8:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: "Everyone wants to retire mainframes"

Yep.  We used to get a lot of errors for out of volumes in a storage
groups, and the users would want us to add more volumes.  For several
calls I would point out that the data set had a very small primary and
secondary space value.  I would go through all the extents on one
volume, then proceed through the

Re: Goto Statements AND COBOL OPTIMIZATION

[Frank Swarbrick]

Those were added w/ COBOL 2002, not 2014.  Don't give yourself too much credit!



From: IBM Mainframe Discussion List  on behalf of Tom 
Ross 
Sent: Wednesday, June 10, 2020 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Goto Statements AND COBOL OPTIMIZATION

>The addition of EXIT PARAGRAPH
>and EXIT SECTION have eliminated most of the reasons for use of GO TO
>in COBOL.  I would be interested in any corrections to my
>understanding by those responsible for the COBOL compiler. =20

I partially agree, Clark, but what really made it easy to get rid of GOTOs
in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM CYCLE!
These were added to the Standard with COBOL 2014 and implemented by IBM in 
Enterprise
COBOL for z/OS V5.2

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
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: "Everyone wants to retire mainframes"

[Frank Swarbrick]

Here are all of the possibly relevant parts from the JESMSGLG for a similar 
occurrence that I just caused.

+*DFS0929I BLDL FAILED FOR MEMBER --ABCDEFG
IEA995I SYMPTOM DUMP OUTPUT  830
  USER COMPLETION CODE=0929
 TIME=10.52.44  SEQ=18497  CPU=  ASID=0038
 PSW AT TIME OF ERROR  078D1000   9012762C  ILC 2  INTC 0D
   ACTIVE MODULE   ADDRESS=_1011A000  OFFSET=D62C
   NAME=DFSDLBL0
   DATA AT PSW  10127626 - D234181F  0A0DD71C  D200D200
   GR 0:    1: 83A1
  2: 7660   3: 84B0
  4: 0005D060   5: 7658
  6: 10126358   7: 0005D060
  8: 00019928   9: 00019F68
  A:    B: 0001
  C: 1011C048   D: 101260B0
  E: 90127E9E   F: 83A1
 END OF SYMPTOM DUMP
DFS627I IMS RTM CLEANUP ( EOT ) COMPLETE FOR JS DDADMP  .PROC01  .STEP01  ,RC=00
IEF450I DDADMP STEP01 PROC01 - ABEND=S000 U0929 REASON=  832

There are no additional DDs beyond this and the standard JESJCL and JESYSMSG 
which have no additional relevant data.

Of course if you look up the error in the manual it does provide slightly more 
useful information.

DFS0929I

 BLDL FAILED FOR MEMBER -- member name

 Explanation
 ~~~
 A BLDL was issued for the named member. The member was not found in the DBD
 or PSB library.

 System action
 ~
 Abend 0929 is issued if batch DL/I was running. ACBGEN processing continues
 if the ACBGEN utility was being run.

 Programmer response
 ~~~
 Correct the error in the appropriate library, and rerun the program.




From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Wednesday, June 10, 2020 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: "Everyone wants to retire mainframes"

The problem with that message is not that it mentions BLDL, but that it fails 
to mention other relevant data. At a minimum, what was the ddname and what was 
the return code. Ideally I'd like secondary messages listing the libraries in 
the concatenation.

A user ABEND without a message is hard to justify. Are you sure that it wasn't 
in the joblog?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Wednesday, June 10, 2020 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "Everyone wants to retire mainframes"

Here's a quote from a message I posted to this list in 2009:

"I have a very basic one to complain about:

DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ

This really means that the specified PSB DDMPPSZ is not in the specified IMS 
library.  Why can't it just say that?  As an application programmer do I really 
need to know that BLDL means, well, whatever it means?

Of course IMS has some that are even worse.  Sometimes I just get something 
like:
USER COMPLETION CODE=
without any message at all.  The first time I ran in to it it took me a heck of 
a time to figure out I need to look in the IMS manual to find out what the 
error was.  For all I could tell it was a user application error, but I 
couldn't see what.  Now all of the other developers on our VSE to z/OS 
conversion team just ask me what the errors are, because trying to find them in 
the manuals is too often too painful.  Hopefully I'll get them trained some day!

I've got to say, coming from VSE their error messages are, in general, much 
better.  Of course as a developer I hate dealing with creating error messages 
for my own apps, so I can understand why IBM has such issues...  :-)"

Things have not improved much, if it all, in this regard in the last ten years. 
 

From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab 
Sent: Tuesday, June 9, 2020 8:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: "Everyone wants to retire mainframes"

Yep.  We used to get a lot of errors for out of volumes in a storage
groups, and the users would want us to add more volumes.  For several
calls I would point out that the data set had a very small primary and
secondary space value.  I would go through all the extents on one
volume, then proceed through the rest, and run out volumes despite
lots of space in the storage group.  They didn't want to reallocate,
so I suggested they migrate and recall the dataset.  Then the existing
space would be in 1 extent on 1 volume and plenty of extents and
volumes to extend onto.  The problem started going away after that.

Would the new 1st extent on the first volume from the recall become
the default 1st allocation on subsequent volumes?

On Wed, Jun 10, 2020 at 12:48 AM Seymour J Metz  wrote:
>
> My pet peeve is the default for SPACE; "Absolute track not available" is not 
> a user friendly error message for forgetting to specify SPACE.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://maso

Re: "Everyone wants to retire mainframes"

[Frank Swarbrick]

Here's a quote from a message I posted to this list in 2009:

"I have a very basic one to complain about:

DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ

This really means that the specified PSB DDMPPSZ is not in the specified IMS 
library.  Why can't it just say that?  As an application programmer do I really 
need to know that BLDL means, well, whatever it means?

Of course IMS has some that are even worse.  Sometimes I just get something 
like:
USER COMPLETION CODE=
without any message at all.  The first time I ran in to it it took me a heck of 
a time to figure out I need to look in the IMS manual to find out what the 
error was.  For all I could tell it was a user application error, but I 
couldn't see what.  Now all of the other developers on our VSE to z/OS 
conversion team just ask me what the errors are, because trying to find them in 
the manuals is too often too painful.  Hopefully I'll get them trained some day!

I've got to say, coming from VSE their error messages are, in general, much 
better.  Of course as a developer I hate dealing with creating error messages 
for my own apps, so I can understand why IBM has such issues...  :-)"

Things have not improved much, if it all, in this regard in the last ten years. 
 

From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab 
Sent: Tuesday, June 9, 2020 8:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: "Everyone wants to retire mainframes"

Yep.  We used to get a lot of errors for out of volumes in a storage
groups, and the users would want us to add more volumes.  For several
calls I would point out that the data set had a very small primary and
secondary space value.  I would go through all the extents on one
volume, then proceed through the rest, and run out volumes despite
lots of space in the storage group.  They didn't want to reallocate,
so I suggested they migrate and recall the dataset.  Then the existing
space would be in 1 extent on 1 volume and plenty of extents and
volumes to extend onto.  The problem started going away after that.

Would the new 1st extent on the first volume from the recall become
the default 1st allocation on subsequent volumes?

On Wed, Jun 10, 2020 at 12:48 AM Seymour J Metz  wrote:
>
> My pet peeve is the default for SPACE; "Absolute track not available" is not 
> a user friendly error message for forgetting to specify SPACE.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Bob Bridges [robhbrid...@gmail.com]
> Sent: Tuesday, June 9, 2020 8:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "Everyone wants to retire mainframes"
>
> JCL: I used to complain about JCL's arcane and in some cases backward syntax. 
>  I mean, "COND=(0,LT,step.procstep)" - who made that up?  But somehow over 
> the years I've made my peace with JCL.  It is what it is.  And I would have 
> done no better, back then.
>
> EBCDIC: A couple of years ago, when I was employed by a small mainframe 
> security consulting company, a client came to them asking for help with a 
> project to create a security product that would reside on a distributed 
> platform but handle security on the mainframe.  They were going to develop it 
> for a client that was using Top Secret, but it could have been any of the 
> three.  These folks didn't know mainframes, which is why they hired my 
> employers, who assigned me to the project.
>
> I said they "didn't know mainframes"; let's start with the fact that they 
> didn't know about EBCDIC.  But that's no problem, right?  There are lots of 
> things one can do to translate between EBCDIC and ASCII.  In the process of 
> working on this project I wrote, my very own self, a socket server that would 
> handle both ASCII and EBCDIC clients.  (I mention this because I'd never done 
> any such thing before, and I was inordinately pleased with the fact that I 
> could do anything so cool.  Those of you who've done hundreds of those and 
> take it for granted, please don't burst my bubble.)
>
> Then they discovered the whole issue of 3270 emulation.  And I probably 
> wasn't helping by trying to explain the complexities of mainframe security at 
> about the same time.  The client went away to think about the communications 
> issue, and somehow they never came back; the project never went anywhere 
> after that.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Always look a gift horse in the mouth.  It may have hoof-and-mouth 
> disease.  -Bob Bridges, 1977 */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Tuesday, June 9, 2020 19:18
> >
> Yes, but JCL.  JCL is to programming as Roman numerals are to arithmetic.
>
> And EBCDIC.  "Doesn't play well with others."
>
> 

Re: COBOL Question

[Frank Swarbrick]

I don't know what any of those terms even mean, so I'll not attempt to answer.
My interest in learning Fortran is more for it syntax than for its scientific 
and mathematical capabilities.


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Tuesday, June 9, 2020 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

Partially. Does Fortran now have reduction operators, e.g., inner product, 
trace?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Tuesday, June 9, 2020 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question

Do you mean like this?

integer, dimension(10) :: a, b, c
a = [1,2,3,4,5,6,7,8,9,10]
b = [2,3,4,5,6,7,8,9,10,11]
c = a + b
print *, "a = ", a
print *, "b = ", b
print *, "c = ", c

a =1   2   3   4   5   6
   7   8   9  10
b =2   3   4   5   6   7
   8   9  10  11
c =3   5   7   9  11  13
  15  17  19  21

Apparently added as part of the Fortran 90 standard.


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Tuesday, June 9, 2020 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

Have they added array operations to Fortran?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Tuesday, June 9, 2020 12:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question

I haven't written anything in FORTRAN since some time in the late '70s.  But
even much more recently I heard it's regarded by number crunchers, engineers
say, as the best language for sheer speed.  Not so great for report writing
and formatting.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* If a problem has a single neck, it has a simple solution. */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Monday, June 8, 2020 21:22

I've been teaching myself (modern) Fortran the last few weeks.  Just
because.  It has an interesting behavior that I kind of like.

Normal IF statement:

if (something) then
   
   
end if

But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):

if (something) 

 must be on the same line as the if and the condition
(unless you specify the "line continuation character"), and of course only
one statement is allowed.  Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement.  Here is one way I've used it in practice.

call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")

Using "if/then" instead of just "if" I'd have had this:

call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if

Given by absolute druthers I would have the then clause part of the single
line if instead of the if/end if, but its still pretty nice regardless, as
it doesn't cause as much "clutter" as error handling often does.

On a side note, I think Fortran has done a much better job than COBOL of
adding "modern" features (starting with Fortran 90 in 1990).  If only the
COBOL "designers" had followed in their footsteps.

And in my mind Fortran had even more to "make up" for in regards to it's
less than ideal beginnings.  Which Fortran can even be forgiven for then,
being I believe about five years older than COBOL (Cobol?).


From: IBM Mainframe Discussion List  on behalf of
Bob Bridges 
Sent: Sunday, June 7, 2020 12:35 PM

The only language I can think of off-hand that doesn't require some sort of
END to close a DO (I'm sure there are others) is ISPF.  But, in REXX at
least, I never use singl

Re: COBOL Question

[Frank Swarbrick]

I couldn't tell you.  But it's what I have been running on Windows recently.  I 
imagine it might (probably?) run on Linux for Z.


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Tuesday, June 9, 2020 8:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

What about gcc Fortran? Does that run on OMVS? Linux on Z?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Tuesday, June 9, 2020 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question

Here's the question I have about Fortran support.  Why does IBM support modern 
Fortran on platforms like Linux and AIX, but mainframe Fortran (IBM VS FORTRAN) 
is still at FORTRAN 77 level and seems to have had no enhancements other than 
Language Environment support since...1993?  I know if I were a Fortran 
developer this would piss me off greatly.


From: IBM Mainframe Discussion List  on behalf of 
Evans-Young, Darren 
Sent: Monday, June 8, 2020 8:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

FORTRAN 90 was a significant upgrade over previous standards. Mainly, free-form 
input source statements.
Also, increase the length of identifiers from 6 characters to 31 characters, 
and upper/lowecase keywords/identifiers.

The latest standard is Fortran 2018.

I still teach Fortran to my Honor students. It's easy to learn for a first 
programming language, very forgiving, and
you can do a lot with it. I still get flack from uninformed individuals, you 
know, the ones that say no one uses mainframes
anymore, no one uses Fortran anymore, no on uses COBOL anymore. Every year, a 
couple of my students email me back
to say how having Fortran experience on their resume helped them land a job or 
internship; companies like NASA, NOAA,
Lockheed-Martin, etc. They are usually the only applicants out of hundreds that 
list Fortran experience.

Darren


From: IBM Mainframe Discussion List  on behalf of 
lenru...@gmail.com 
Sent: Monday, June 8, 2020 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

On, long ago and on some DOS/VS Cobol compiler, after a compiler upgrade, there 
was a problem with a statement something like this:
READ some-fileAT END do somethingMOVE A TO B.
See the problem?  The period after the AT END was omitted.  The old compiler 
only allowed one statement after AT END (maybe a bug) but after it honored the 
period.
It was a bear to find.  It worked before and for a long time after the compiler 
change, until it was complied again.
On Monday, June 8, 2020, 08:22:18 PM CDT, Frank Swarbrick 
 wrote:

 I've been teaching myself (modern) Fortran the last few weeks.  Just because.  
It has an interesting behavior that I kind of like.

Normal IF statement:

if (something) then
  
  
end if

But it also has a "one line IF" (not sure offhand of the Fortran "name" for 
this):

if (something) 

 must be on the same line as the if and the condition (unless 
you specify the "line continuation character"), and of course only one 
statement is allowed.  Kind of like the C/Java if statement with out a 
statement block, but less dangerous because of the "on the same line" 
requirement.  Here is one way I've used it in practice.

call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal 
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to 
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive 
numeric (0-32767).")

Using "if/then" instead of just "if" I'd have had this:

call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to 
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if

Given by absolute druthers I would have the then clause part of the single line 
if instead of the if/end if, but its still pretty nice regardless, as it 
doesn't cause as much "clutter" as error handling often does.

On a side note, I think Fortran has done a much better job than COBOL of adding 
"modern" features (starting with Fortran 90 in 1990).  If only the COBOL 
"designers" had followed in their footsteps.

And in my mind Fortran had even more to "make up" for in regards to it's less 
than ideal beginnings.  Which Fortran can even be forgiven for then, being I 
believe a

Re: COBOL Question

[Frank Swarbrick]

Do you mean like this?

integer, dimension(10) :: a, b, c
a = [1,2,3,4,5,6,7,8,9,10]
b = [2,3,4,5,6,7,8,9,10,11]
c = a + b
print *, "a = ", a
print *, "b = ", b
print *, "c = ", c

a =1   2   3   4   5   6
   7   8   9  10
b =2   3   4   5   6   7
   8   9  10  11
c =3   5   7   9  11  13
  15  17  19  21

Apparently added as part of the Fortran 90 standard.


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Tuesday, June 9, 2020 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

Have they added array operations to Fortran?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Tuesday, June 9, 2020 12:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Question

I haven't written anything in FORTRAN since some time in the late '70s.  But
even much more recently I heard it's regarded by number crunchers, engineers
say, as the best language for sheer speed.  Not so great for report writing
and formatting.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* If a problem has a single neck, it has a simple solution. */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Monday, June 8, 2020 21:22

I've been teaching myself (modern) Fortran the last few weeks.  Just
because.  It has an interesting behavior that I kind of like.

Normal IF statement:

if (something) then
   
   
end if

But it also has a "one line IF" (not sure offhand of the Fortran "name" for
this):

if (something) 

 must be on the same line as the if and the condition
(unless you specify the "line continuation character"), and of course only
one statement is allowed.  Kind of like the C/Java if statement with out a
statement block, but less dangerous because of the "on the same line"
requirement.  Here is one way I've used it in practice.

call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive
numeric (0-32767).")

Using "if/then" instead of just "if" I'd have had this:

call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if

Given by absolute druthers I would have the then clause part of the single
line if instead of the if/end if, but its still pretty nice regardless, as
it doesn't cause as much "clutter" as error handling often does.

On a side note, I think Fortran has done a much better job than COBOL of
adding "modern" features (starting with Fortran 90 in 1990).  If only the
COBOL "designers" had followed in their footsteps.

And in my mind Fortran had even more to "make up" for in regards to it's
less than ideal beginnings.  Which Fortran can even be forgiven for then,
being I believe about five years older than COBOL (Cobol?).


From: IBM Mainframe Discussion List  on behalf of
Bob Bridges 
Sent: Sunday, June 7, 2020 12:35 PM

The only language I can think of off-hand that doesn't require some sort of
END to close a DO (I'm sure there are others) is ISPF.  But, in REXX at
least, I never use single-statement DOs.  I see them all the time, and I
don't get it.  Like this:

  if x=0 then do
x=x+1
  end

Or, more painfully:

  select
when idx="T" then
  do
countt=countt+1
  end
when idx="U" then
  do
countu=countu+1
  end
when idx="V" then
  do
countv=countv+1
  end
when idx="W" then
  do
countw=countw+1
  end
otherwise
  do
countx=countx+1
  end
  end

Why?  If it were easier to read, I might sympathize.  But it's harder, not
easier.

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

Re: COBOL Question

[Frank Swarbrick]

Here's the question I have about Fortran support.  Why does IBM support modern 
Fortran on platforms like Linux and AIX, but mainframe Fortran (IBM VS FORTRAN) 
is still at FORTRAN 77 level and seems to have had no enhancements other than 
Language Environment support since...1993?  I know if I were a Fortran 
developer this would piss me off greatly.


From: IBM Mainframe Discussion List  on behalf of 
Evans-Young, Darren 
Sent: Monday, June 8, 2020 8:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

FORTRAN 90 was a significant upgrade over previous standards. Mainly, free-form 
input source statements.
Also, increase the length of identifiers from 6 characters to 31 characters, 
and upper/lowecase keywords/identifiers.

The latest standard is Fortran 2018.

I still teach Fortran to my Honor students. It's easy to learn for a first 
programming language, very forgiving, and
you can do a lot with it. I still get flack from uninformed individuals, you 
know, the ones that say no one uses mainframes
anymore, no one uses Fortran anymore, no on uses COBOL anymore. Every year, a 
couple of my students email me back
to say how having Fortran experience on their resume helped them land a job or 
internship; companies like NASA, NOAA,
Lockheed-Martin, etc. They are usually the only applicants out of hundreds that 
list Fortran experience.

Darren


From: IBM Mainframe Discussion List  on behalf of 
lenru...@gmail.com 
Sent: Monday, June 8, 2020 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

On, long ago and on some DOS/VS Cobol compiler, after a compiler upgrade, there 
was a problem with a statement something like this:
READ some-fileAT END do somethingMOVE A TO B.
See the problem?  The period after the AT END was omitted.  The old compiler 
only allowed one statement after AT END (maybe a bug) but after it honored the 
period.
It was a bear to find.  It worked before and for a long time after the compiler 
change, until it was complied again.
On Monday, June 8, 2020, 08:22:18 PM CDT, Frank Swarbrick 
 wrote:

 I've been teaching myself (modern) Fortran the last few weeks.  Just because.  
It has an interesting behavior that I kind of like.

Normal IF statement:

if (something) then
  
  
end if

But it also has a "one line IF" (not sure offhand of the Fortran "name" for 
this):

if (something) 

 must be on the same line as the if and the condition (unless 
you specify the "line continuation character"), and of course only one 
statement is allowed.  Kind of like the C/Java if statement with out a 
statement block, but less dangerous because of the "on the same line" 
requirement.  Here is one way I've used it in practice.

call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal 
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to 
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive 
numeric (0-32767).")

Using "if/then" instead of just "if" I'd have had this:

call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to 
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if

Given by absolute druthers I would have the then clause part of the single line 
if instead of the if/end if, but its still pretty nice regardless, as it 
doesn't cause as much "clutter" as error handling often does.

On a side note, I think Fortran has done a much better job than COBOL of adding 
"modern" features (starting with Fortran 90 in 1990).  If only the COBOL 
"designers" had followed in their footsteps.

And in my mind Fortran had even more to "make up" for in regards to it's less 
than ideal beginnings.  Which Fortran can even be forgiven for then, being I 
believe about five years older than COBOL (Cobol?).



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Sunday, June 7, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

The only language I can think of off-hand that doesn't require some sort of END 
to close a DO (I'm sure there are others) is ISPF.  But, in REXX at least, I 
never use single-statement DOs.  I see them all the time, and I don't get it.  
Like this:

  if x=0 then do
x=x+1
  end

Or, more painfully:

  select
when idx="T" then
  do
countt=countt+1
  end
when idx="U" then
  do
countu=countu+1
  

Re: COBOL Question

[Frank Swarbrick]

I've been teaching myself (modern) Fortran the last few weeks.  Just because.  
It has an interesting behavior that I kind of like.

Normal IF statement:

if (something) then
   
   
end if

But it also has a "one line IF" (not sure offhand of the Fortran "name" for 
this):

if (something) 

 must be on the same line as the if and the condition (unless 
you specify the "line continuation character"), and of course only one 
statement is allowed.  Kind of like the C/Java if statement with out a 
statement block, but less dangerous because of the "on the same line" 
requirement.  Here is one way I've used it in practice.

call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) call error_stop("Host must be in dotted decimal 
format.")
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to 
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) call error_stop("Port must be positive 
numeric (0-32767).")

Using "if/then" instead of just "if" I'd have had this:

call get_command_argument(1, host)
if (inet_addr(host) .lt. 0) then
call error_stop("Host must be in dotted decimal format.")
end if
call get_command_argument(2, port_str)
read (port_str, '(i5)', iostat = iostat) port ! convert string 'port_str' to 
integer 'port'
if (iostat .ne. 0 .or. port .le. 0) then
call error_stop("Port must be positive numeric (0-32767).")
end if

Given by absolute druthers I would have the then clause part of the single line 
if instead of the if/end if, but its still pretty nice regardless, as it 
doesn't cause as much "clutter" as error handling often does.

On a side note, I think Fortran has done a much better job than COBOL of adding 
"modern" features (starting with Fortran 90 in 1990).  If only the COBOL 
"designers" had followed in their footsteps.

And in my mind Fortran had even more to "make up" for in regards to it's less 
than ideal beginnings.  Which Fortran can even be forgiven for then, being I 
believe about five years older than COBOL (Cobol?).



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Sunday, June 7, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

The only language I can think of off-hand that doesn't require some sort of END 
to close a DO (I'm sure there are others) is ISPF.  But, in REXX at least, I 
never use single-statement DOs.  I see them all the time, and I don't get it.  
Like this:

  if x=0 then do
x=x+1
  end

Or, more painfully:

  select
when idx="T" then
  do
countt=countt+1
  end
when idx="U" then
  do
countu=countu+1
  end
when idx="V" then
  do
countv=countv+1
  end
when idx="W" then
  do
countw=countw+1
  end
otherwise
  do
countx=countx+1
  end
  end

Why?  If it were easier to read, I might sympathize.  But it's harder, not 
easier.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* It's a good thing Lincoln wrote the Gettysburg Address the year that he did, 
or else that "fourscore and seven years" part would have just been plain wrong. 
 -Paul Paternoster */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, June 6, 2020 14:40

But in Rexx similarly, END is required even for a single-statement DO.
Good for Rexx.  I like strong closure.

>--- On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote:
>>Oh, you need an END-IF even for a single-statement IF?  I forgot; I've been 
>>thinking in REXX too long.  In that case you're close; I guess I really meant

--
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: COBOL Question

[Frank Swarbrick]

Were there really three releases of VS COBOL II that didn't implement COBOL 
1985?  I thought there was only one.  But I didn't live through it.  I 
generally think of COBOL II and COBOL 1985 as being "the same", since that was 
(essentially) the case by the time I became a COBOL developer (in 1996).

I also curse those who still insist on using periods to terminate sentences 
when it is allowed.  The major offender at my shop left a few years ago, so 
I've mostly (?) gotten over it.


From: IBM Mainframe Discussion List  on behalf of 
Clark Morris 
Sent: Saturday, June 6, 2020 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

[Default] On 6 Jun 2020 10:53:44 -0700, in bit.listserv.ibm-main
robhbrid...@gmail.com (Bob Bridges) wrote:

>Oh, you need an END-IF even for a single-statement IF?  I forgot; I've been 
>thinking in REXX too long.  In that case you're close; I guess I really meant
In your example the END-IF is not needed.  However beginning with VS
COBOL IIV4 (1985 standard) it became better practice to eliminate all
but the last period in a paragraph and terminate all conditional with
end statements such as END-IF.  With Enterprise COBOL 5.2 and later
(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO
TOs replaced with EXIT PARAGRAPH.  This allow simpler code generation
for the PERFORM and the PERFORMed paragraph be moved inline to in
effect replace the PERFORM statement.  Also look up inline PERFORMs.
In general, because of code optimization starting with VS COBOL II
release 4 (1985 standard) GO TO became a bad idea.

Clark Morris
>
>   PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X > 999 GOTO 1050-EXIT END-IF.
> IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF.
> IF TYPE <> 195 GOTO 1050-EXIT END-IF.
> IF NOT SO-ON GOTO 1050-EXIT END-IF.
> IF NOT SO-FORTH GOTO 1050-EXIT END-IF.
> [do such and such]
>   1050-EXIT.
>
>I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ 
>circumstances.  In my old shop I argued for GOTOs in three very strictly 
>limited circumstances, the other two being end-of-section and end-of-program.  
>Some languages allow for this by including some flavor of "leave" statement; 
>all I want to do with a GOTO is to simulate that part of structured 
>programming.  But at the particular shop I have in mind, none of that could be 
>contemplated, because all GOTOs are evil.
>
>---
>Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>/* Law #21 of combat operations: The important things are always simple; the 
>simple things are always hard. */
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Joe Monk
>Sent: Saturday, June 6, 2020 04:49
>
>I think what you mean is this:
>
>PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99
>END-PERFORM
>
>  1050-LOOP.
>IF FIRST-NAME NOT = "ROBERT"
>GO TO 1059-EXIT
>END-IF
>IF TYPE NOT = 195
>GO TO 1059-EXIT
>END-IF
>IF NOT SO-ON
>GO TO 1059-EXIT
>END-IF
>IF NOT SO-FORTH
>GO TO 1059-EXIT
>END-IF
>PERFORM 1050-SUCH-AND-SUCH END-PERFORM
>
>  1059-EXIT.
>  EXIT.
>
>In structured programming, it is perfectly acceptable to use GO TO within a
>paragraph. It is NOT acceptable to use GO TO outside of a paragraph.
>
>--- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges  wrote:
>> I realize this is a bit of a change in subject (and it's not as if we need
>> yet another one), but I avoid this construction.  My phobia is based on an
>> extreme example:  In their zeal never to use GOTOs, I've frequently seen
>> programmers write paragraphs like this:
>>
>>   PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99
>>
>>   1050-LOOP.
>> IF X < 1000
>>   IF FIRST-NAME NOT = "ROBERT"
>> IF TYPE = 195
>>   IF SO-ON
>> IF SO-FORTH
>>   EXECUTE 1050-SUCH-AND-SUCH
>>   END-IF
>> END-IF
>>   END-IF
>> END-IF
>>   END-IF
>>
>> Gives me a headache to try to evaluate that.  Much better, in my opinion,
>> to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this:
>>
>>   PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99
>>
>>   1050-LOOP.
>> IF X > 999 GOTO 1059-LOOP.
>> IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP.
>> IF TYPE <> 195 GOTO 1059-LOOP.
>> IF NOT SO-ON GOTO 1059-LOOP.
>> IF NOT SO-FORTH GOTO 1059-LOOP.
>> EXECUTE 1050-SUCH-AND-SUCH
>>   1059-LOOP.
>>
>> Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the
>> syntax, I probably got part of it wrong nonetheless, and I'll bet there are
>> easier ways to do it nowadays.  In REXX, for example, they have the ITERATE
>> statement:
>>
>>   do jc=1 to 99
>> if x>99 then iterate
>> if firstname='ROBERT' then iterate
>> if type<>195 then iterate
>> if \soon then iterate

Re: COBOL Question

[Frank Swarbrick]

Apologies again if this has already been answered.  I'm a few days behind.

You can use a full stop (period) to terminate an IF statement.  The "problem" 
is (and one of the any reasons I elide all periods that are not absolutely 
required) it terminates an entire COBOL "sentence" (not just a COBOL 
statement).  Since you used a perform of a separate procedure you could end 
each IF with a period and its fine.  The same would not be true for an "inline" 
perform, as I showed in my previous reply.  If I had used a period instead of 
an END-IF the period would not only terminate the first IF, but also the 
PERFORM.  Meaning the remainder of the IF statements would end up being 
"outside of the loop", while the END-PERFORM would have no PERFORM to match to, 
since the PERFORM was already terminated by the period.  Bad news!  But at 
least it wouldn't compile.  If I had dropped the END-PERFORM it WOULD compile 
(with periods replacing END-IFs), but it wouldn't do what you want.

Here's, if you are interested, valid COBOL that also likely does not do what 
one would want it to do.

IF SOMETHING
NEXT SENTENCE
ELSE
PERFORM SOMETHING-ELSE
END-IF
PERFORM MORE
PERFORM MORE-AND-MORE
EXIT.

The "NEXT SENTENCE" phrase of an IF statement is an implicit GO TO *beyond* the 
next period (i.e., "to the next sentence".  In this case if SOMETHING is true 
not only would SOMETHING-ELSE be bypassed, but so would MORE and MORE-AND-MORE. 
 Two possible fixes are: 1) add three periods (example below), or keep as-is 
except replace the NEXT SENTENCE phrase (clause?) with a CONTINUE statement.  
CONTINUE is a true no-op, rather then a GO TO in disguise.

Option 1)
IF SOMETHING
NEXT SENTENCE
ELSE
PERFORM SOMETHING-ELSE
END-IF.
PERFORM MORE.
PERFORM MORE-AND-MORE.
EXIT.


Option 2)
IF SOMETHING
CONTINUE
ELSE
PERFORM SOMETHING-ELSE
END-IF
PERFORM MORE
PERFORM MORE-AND-MORE
EXIT.


All of this nonsense is, of course, a result of END- clauses not being part of 
COBOL before the 1985 standard.  You HAD to use a period to terminate an IF.  
And of course all of that is a result of someone thinking that an "English 
like" programming language could be unambiguous, or at least a somewhat good 
idea in practice...  A good idea in theory, but not so much in practice.



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Saturday, June 6, 2020 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

Oh, you need an END-IF even for a single-statement IF?  I forgot; I've been 
thinking in REXX too long.  In that case you're close; I guess I really meant

   PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99

   1050-LOOP.
 IF X > 999 GOTO 1050-EXIT END-IF.
 IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF.
 IF TYPE <> 195 GOTO 1050-EXIT END-IF.
 IF NOT SO-ON GOTO 1050-EXIT END-IF.
 IF NOT SO-FORTH GOTO 1050-EXIT END-IF.
 [do such and such]
   1050-EXIT.

I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ 
circumstances.  In my old shop I argued for GOTOs in three very strictly 
limited circumstances, the other two being end-of-section and end-of-program.  
Some languages allow for this by including some flavor of "leave" statement; 
all I want to do with a GOTO is to simulate that part of structured 
programming.  But at the particular shop I have in mind, none of that could be 
contemplated, because all GOTOs are evil.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Law #21 of combat operations: The important things are always simple; the 
simple things are always hard. */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe Monk
Sent: Saturday, June 6, 2020 04:49

I think what you mean is this:

PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99
END-PERFORM

  1050-LOOP.
IF FIRST-NAME NOT = "ROBERT"
GO TO 1059-EXIT
END-IF
IF TYPE NOT = 195
GO TO 1059-EXIT
END-IF
IF NOT SO-ON
GO TO 1059-EXIT
END-IF
IF NOT SO-FORTH
GO TO 1059-EXIT
END-IF
PERFORM 1050-SUCH-AND-SUCH END-PERFORM

  1059-EXIT.
  EXIT.

In structured programming, it is perfectly acceptable to use GO TO within a
paragraph. It is NOT acceptable to use GO TO outside of a paragraph.

--- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges  wrote:
> I realize this is a bit of a change in subject (and it's not as if we need
> yet another one), but I avoid this construction.  My phobia is based on an
> extreme example:  In their zeal never to use GOTOs, I've frequently seen
> programmers write paragraphs like this:
>
>   PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X < 1000
>   IF FIRST-NAME NOT = "ROBERT"
> IF TYPE = 195
>   IF SO-ON
> IF SO-FORTH
>   EXECUTE 1050-SUCH-AND-SUCH
>   END-IF
> 

Re: COBOL Question

[Frank Swarbrick]

GO TO to an "exit" procedure (that is, a procedure that terminates 
unconditionally terminates the program) is, in my mind, acceptable as well.  In 
fact, if you try to "perform" a "terminal" exit procedure the compiler will 
give you a warning that your "calling" procedure will never reach its exit.


From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Saturday, June 6, 2020 2:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

I think what you mean is this:

PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99
END-PERFORM

  1050-LOOP.
IF FIRST-NAME NOT = "ROBERT"
GO TO 1059-EXIT
END-IF
IF TYPE NOT = 195
GO TO 1059-EXIT
END-IF
IF NOT SO-ON
GO TO 1059-EXIT
END-IF
IF NOT SO-FORTH
GO TO 1059-EXIT
END-IF
PERFORM 1050-SUCH-AND-SUCH END-PERFORM

  1059-EXIT.
  EXIT.

In structured programming, it is perfectly acceptable to use GO TO within a
paragraph. It is NOT acceptable to use GO TO outside of a paragraph.

Joe

On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges  wrote:

> I realize this is a bit of a change in subject (and it's not as if we need
> yet another one), but I avoid this construction.  My phobia is based on an
> extreme example:  In their zeal never to use GOTOs, I've frequently seen
> programmers write paragraphs like this:
>
>   PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X < 1000
>   IF FIRST-NAME NOT = "ROBERT"
> IF TYPE = 195
>   IF SO-ON
> IF SO-FORTH
>   EXECUTE 1050-SUCH-AND-SUCH
>   END-IF
> END-IF
>   END-IF
> END-IF
>   END-IF
>
> Gives me a headache to try to evaluate that.  Much better, in my opinion,
> to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this:
>
>   PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X > 999 GOTO 1059-LOOP.
> IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP.
> IF TYPE <> 195 GOTO 1059-LOOP.
> IF NOT SO-ON GOTO 1059-LOOP.
> IF NOT SO-FORTH GOTO 1059-LOOP.
> EXECUTE 1050-SUCH-AND-SUCH
>   1059-LOOP.
>
> Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the
> syntax, I probably got part of it wrong nonetheless, and I'll bet there are
> easier ways to do it nowadays.  In REXX, for example, they have the ITERATE
> statement:
>
>   do jc=1 to 99
> if x>99 then iterate
> if firstname='ROBERT' then iterate
> if type<>195 then iterate
> if \soon then iterate
> if \soforth then iterate
> call suchandsuch
> end
>
> However you do it, I vastly prefer skip-to-next-item over nested Ifs.  But
> I confess that one single nested IF is not going to give me a headache; I
> just react when I see one.  Not your fault :).
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* In an emergency, a drawstring from a parka hood can be used to strangle
> a snoring tent mate.  -"Camping Tips" */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gibney, Dave
> Sent: Friday, June 5, 2020 16:17
>
> Using OP
>  IF TVOLL (IND1) NOT = HIGH-VALUE
>  AND SMOD (IND1) = 'B' OR 'R'
>
> I would do
>  IF TVOLL (IND1) NOT = HIGH-VALUE
>   IF SMOD (IND1) = 'B' OR 'R'
>   Do the stuff
>
> --
> 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: COBOL Question

[Frank Swarbrick]

With Enterprise COBOL V5 and up you could do the following:

PERFORM VARYING JC FROM 1 BY 1 UNTIL JC > 99
IF X > 999 EXIT PERFORM CYCLE END-IF
IF FIRST-NAME = "ROBERT" EXIT PERFORM CYCLE END-IF
IF TYPE <> 195 EXIT PERFORM CYCLE END-IF
IF NOT SO-ON EXIT PERFORM CYCLE END-IF
IF NOT SO-FORTH EXIT PERFORM CYCLE END-IF
PERFORM 1050-SUCH-AND-SUCH
END-PERFORM

EXIT PERFORM CYCLE is COBOL's version of REXX "iterate", C/C++/Java "continue", 
etc.  EXIT PERFORM (w/o CYCLE) is like "leave/break".  Only works with an 
inline perform, but that's true for those other languages as well.

Inline performs have been available since COBOL 1985 standard, e.g. IBM VS 
COBOL II, but EXIT PERFORM [CYCLE] were added only in the COBOL 2002 standard.



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Friday, June 5, 2020 11:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Question

I realize this is a bit of a change in subject (and it's not as if we need yet 
another one), but I avoid this construction.  My phobia is based on an extreme 
example:  In their zeal never to use GOTOs, I've frequently seen programmers 
write paragraphs like this:

  PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99

  1050-LOOP.
IF X < 1000
  IF FIRST-NAME NOT = "ROBERT"
IF TYPE = 195
  IF SO-ON
IF SO-FORTH
  EXECUTE 1050-SUCH-AND-SUCH
  END-IF
END-IF
  END-IF
END-IF
  END-IF

Gives me a headache to try to evaluate that.  Much better, in my opinion, to 
introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this:

  PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99

  1050-LOOP.
IF X > 999 GOTO 1059-LOOP.
IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP.
IF TYPE <> 195 GOTO 1059-LOOP.
IF NOT SO-ON GOTO 1059-LOOP.
IF NOT SO-FORTH GOTO 1059-LOOP.
EXECUTE 1050-SUCH-AND-SUCH
  1059-LOOP.

Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the 
syntax, I probably got part of it wrong nonetheless, and I'll bet there are 
easier ways to do it nowadays.  In REXX, for example, they have the ITERATE 
statement:

  do jc=1 to 99
if x>99 then iterate
if firstname='ROBERT' then iterate
if type<>195 then iterate
if \soon then iterate
if \soforth then iterate
call suchandsuch
end

However you do it, I vastly prefer skip-to-next-item over nested Ifs.  But I 
confess that one single nested IF is not going to give me a headache; I just 
react when I see one.  Not your fault :).

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* In an emergency, a drawstring from a parka hood can be used to strangle a 
snoring tent mate.  -"Camping Tips" */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Friday, June 5, 2020 16:17

Using OP
 IF TVOLL (IND1) NOT = HIGH-VALUE
 AND SMOD (IND1) = 'B' OR 'R'

I would do
 IF TVOLL (IND1) NOT = HIGH-VALUE
  IF SMOD (IND1) = 'B' OR 'R'
  Do the stuff

--
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: Gratuitous EXECIO Documentation

[Frank Swarbrick]

I can't seem to find any way to give a "thumbs up" to a listserv post.  So 
consider this to be a virtual thumbs up.  

(Yes, I am kidding about not being able to find how to do it.  I realize that 
listserv far pre-dates Twitter, Facebook and the like.)


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Friday, June 5, 2020 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Gratuitous EXECIO Documentation

The documentation is written to aid human beings. It is not a hard-core 
exercise in logic.

In writing doc I am often struck by a contrast to coding. In coding, if you had 
to do the same three-line sequence at ten places in your code the right thing 
would be to factor it out into a subroutine and invoke it ten times. In writing 
doc OTOH the reader might be better served by your repeating the same three 
sentences ten times rather than ten times saying "See the note at the top of 
page 17" (which is roughly the documentation analog of a subroutine call).

It's a judgment call as to what will best help the reader. Sometimes following 
logic rigorously is what best serves the reader. Probably better to use a link 
to the JCL reference rather than doing a halfway job of explaining DD 
statements in a COBOL manual. But as @Tony says, EXECIO is a particular 
landmine for inexperienced Rexx coders. It is not wrong to make their lives 
easier.

And no, "therefore every technically similar feature should get the same note" 
is not a valid corollary.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, June 5, 2020 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Gratuitous EXECIO Documentation

On Fri, 5 Jun 2020 12:01:18 -0400, Tony Thigpen wrote:

>In my experience, over 30 years of using REXX on first VM, then VSE and
>now z/OS, I can't tell you how many times I have had to help people with
>the EXECIO syntax as it relates to "what is a keyword" and "what is a
>variable". I would put it at the top of the "common programming errors
>in REXX" list.
>
>I have seen the following error S many times:
>... "STEM" line.
>Which should be:
>... "STEM LINE."
>
>I would not consider this "gratuitous" documentation.
>
I'm outvoted.  I  shall submit one RCF for each command description
that does not contain such a caution asking that one be added.

(I haven't checked.  Perhaps they already exist.)

-- 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: What crashing COBOL systems reveal about applications maintenance -- GCN

[Frank Swarbrick]

We use OPT(1).  Probably for no good reason.  (And it was my decision, meaning 
its easy enough to change!)


From: IBM Mainframe Discussion List  on behalf of Tom 
Ross 
Sent: Wednesday, May 20, 2020 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: What crashing COBOL systems reveal about applications maintenance 
-- GCN

>Suppose that they took a group of programmers and got the production online=
> programs to all compile with COBOL 6.2 and OPT(1). Would they see a signif=
>icant reduction in MSUs?  Assuming they are running on z14s minimally?

I sure hope no one is using OPT(1) with 3rd generation COBOL!  IBM expects all 
users
to compile with OPT(2) for production performance.  I am honestly not sure why 
we
shipped OPT(1).  Users should use OPT(0) if they want more straight-forward 
debugging
(no optimizations) and then after unit test compile with OPT(2) for 
performance, and
and never use OPT(1).  Alternatively, they could compile with OPT(2) for 
debugging and
get used to odd things like statements getting moved or deleted while debugging.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
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: Oil futures and computer "help"

[Frank Swarbrick]

Never trust a computer application that you yourself didn't write.  And even 
then don't trust it.

Only slightly kidding.


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Wednesday, May 13, 2020 5:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Oil futures and computer "help"

This fascinating article isn't really on the topic of mainframes, but we've 
been talking about similar things recently and I thought some would be 
interested:

https://www.bloomberg.com/news/articles/2020-05-08/oil-crash-busted-a-broker-s-computers-and-inflicted-huge-losses

The main player is a futures speculator who watched the price of oil futures 
drop fantastically low and bought like crazy - never realizing that the price 
~could~ go negative.  The brokerage house's trading application didn't know it 
either:  "Crude was actually around negative $3.70 a barrel when Shah’s screen 
had it at 1 centCompounding the problem, and a big reason why Shah lost an 
unbelievable amount in a few hours, is that the negative numbers also blew up 
the model Interactive Brokers used to calculate the amount of margin -- aka 
collateral -- that customers needed to secure their accounts."

"At midnight, Shah got the devastating news: he owed Interactive Brokers $9 
million. He’d started the day with $77,000 in his account."

Another player "bought contracts for his friends on Interactive Brokers that 
day at $11 and between $4 and $5. Just after 2 p.m. New York time, his trading 
screen froze. 'The price feed went black, there were no bids or offers 
anymore,' he said in an interview. Yet as far as he knew at this point, 
according to his Interactive Brokers account, he didn’t have anything to worry 
about as trading closed for the day."

"Besides locking up because of negative prices, a second issue concerned the 
amount of money Interactive Brokers required its customers to have on hand in 
order to trade. Known as margin, it’s a vital risk measure to ensure traders 
don’t lose more than they can afford. For the 212 oil contracts Shah bought for 
1 cent each, the broker only required his account to have $30 of margin per 
contract. It was as if Interactive Brokers thought the potential loss of buying 
at one cent was one cent, rather than the almost unlimited downside that 
negative prices imply, he said."

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The Constitution is supposed to define the powers of the federal government 
-- authorizing some powers, which are enumerated, while reserving all other 
powers to the states and the people. This means that the first question we 
should ask when a new law is proposed is: "Does the Constitution allow the 
federal government to do this?"  -Joseph Sobran, 2001-01-06 */

--
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: Developers say Google's Go is 'most sought after' programming language of 2020

[Frank Swarbrick]

https://developer.ibm.com/mainframe/2020/04/24/ibm-intends-to-enable-go-on-z-os/
IBM intends to enable Go on z/OS - Mainframe 
DEV
IBM intends to enable a full native Go (or Golang) compiler on z/OS. IBM 
intends to enable a native Go (or Golang) compiler on z/OS, further 
strengthening its portfolio of compiler technologies and partnership with the 
open source community.
developer.ibm.com



From: IBM Mainframe Discussion List  on behalf of 
Mark Regan 
Sent: Friday, May 8, 2020 10:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Fwd: Developers say Google's Go is 'most sought after' programming 
language of 2020

https://www.zdnet.com/article/developers-say-googles-go-is-most-sought-after-programming-language-of-2020

or

*https://tinyurl.com/yaduy3gn* 

Regards,

Mark Regan, K8MTR

*CTO1 USNR-Retired, 1969-1991*
*Nationwide Insurance, Retired, 1986-2017*
Facebook: https://www.facebook.com/mark.t.regan
LinkedIn:   https://www.linkedin.com/in/mark-t-regan
Maranatha! <><

--
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: TSO/E SUBMIT exit

[Frank Swarbrick]

Are you still wanting to limit "non OPER" users to only those jobs beginning 
with their user ID?  If so, for gods sake why?  Sounds very 1960s...


From: IBM Mainframe Discussion List  on behalf of 
Robert Hahne 
Sent: Wednesday, May 6, 2020 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: TSO/E SUBMIT exit

Hello listers ,

 I understand this is a RACF question . But thought someone can help me here . 
We have a requirement where TSO submit exit IKJEFF10 needs to be eliminated . 
Currently it is written to ensure only those users with TSOAUTH(OPER) are 
allowed to submit jobs with any name . Rest of the users are only allowed to 
submit jobs that begins with their USERID .

Also , the users are not allowed to issue JES commands in batch unless they 
have TSOAUTH(OPER) . Can we get both of these requirements done using RACF 
profiles ?

Any pointers are highly appreciated

Regards,
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: Mainframe user ID length

[Frank Swarbrick]

I know on my MQ instance I have installed on my home Windows machine, MQ 
truncates my Windows user ID "Frank Swarbrick" to "Frank Swarbr".


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Monday, May 4, 2020 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Mainframe user ID length

The maximum length on Linux is 32; whether MQ will work with a name longer than 
12 is a separate issue. There are also Linux commands that will display the UID 
instead of a username longer than 8. LDAP can map long names to short. I don't 
know about non-IBM LDAP.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Monday, May 4, 2020 2:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe user ID length

Wow! That's a lot to digest.
A couple of things.  First, I see the following documented:

“On z/OS® and UNIX and Linux, the maximum length of a user ID is 12 
characters.”  From 
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q010300_.htm

I wonder how this works if RACF user IDs are only allowed up to 8 characters.  
Would an alternate SAF product be required?  I can't see anything documented to 
explain how this might work.


On a separate line, are you saying is it possible for z/OS to use a non-z/OS 
LDAP server for authentication (and authorization?), including user IDs and 
passwords?  But this would that still require TSO and CICS (and IMS? and 
others?) signon processes to be able to handle those user IDs?  It sounds like 
both of these things are true, but I want to make sure I am not 
misunderstanding you.


From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Saturday, May 2, 2020 12:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Mainframe user ID length

Frank Swarbrick wrote:
>"more than 8"?  What's the limit, if any?

The z/OS LDAP Server's CN limit is 256 characters, so it's at least that
large.

>Which system components/products permit/prohibit this?
>(Start your list with JCL.)

You can specify pretty much anything you want in JCL. Do you mean JES2? If
so, that'll use maximum 8 character user IDs.

Whatever list I come up with is necessarily going to be partial, but as
we've already seen (I linked to the documentation) MQ for z/OS can
authenticate users with the IBM Directory Server for z/OS at least in
certain contexts. CICS Transaction Server for z/OS also can in certain
contexts. See for example this documentation:

https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html

Other z/OS components and products that come to mind include the z/OS
Container Extensions, WebSphere Application Server for z/OS, and the IBM
HTTP Server for z/OS. See for example here:

https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html

There are quite a large number of intersections, so many that we've now
reached the stage when one of them fell overboard. z/OS HCD had some LDAP
affinities (would you believe), but they were removed in z/OS 2.3.
Evidently that one was too "crazy." :-)

Bob Bridges wrote:
>I'm about to expose my ignorance here: IDS and LDAP, aren't they just
>IBM's attempt to let z/OS talk to non-z/OS systems?

No, not according to IBM. Right at the very beginning of the IBM (Tivoli)
Directory Server for z/OS redbook, Section 1.1, it says that this
component is for both z/OS and non-z/OS workloads. So take the hint: if
maximum 8 character user IDs are constraining, then start using the IBM
Directory Server for z/OS to authenticate users if you aren't already,
as/where it makes sense for you. Or use a certain something else to
authenticate (see below).

>Or put it this way: If you say I can be authenticated via LPAR using a
>longer ID, and then perform tasks on the mainframe using that ID, how
does
>RACF-or-whatever determine permissions?

First of all, you didn't include "RACF" in the text I reacted to. RACF is
a popular but optional z/OS component. z/OS is not equivalent to RACF.
Second, if you are talking about RACF specifically, yes, it does use
maximum 8 character user IDs But you're not required to authenticate
with them. I (somewhat facetiously) pointed out that you don't have to
authenticate at all, although (as I also pointed out) I'll urge you to at
least perform authorizations. More seriously, z/OS RACF has supported
client certificate authentication since the 1990s. (This feature was
initially introduced way back in the OS/390 days. The OS/390 TN3270E
Server picked up support for it with OS/390 2.9, backported to 2.8. IBM
Personal Communications picked up support for this feature in the late
1990s, too.) See here f

Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)

[Frank Swarbrick]

Well, in our case at least the workstation refers to a company provided and 
managed workstation.  We can't log on to z/OS from our personal devices.  And 
we use SSO for many applications.  I don't know how it works; only that it does 
work.


From: IBM Mainframe Discussion List  on behalf of Tom 
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Monday, May 4, 2020 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)

On Mon, 4 May 2020 19:14:31 +, Frank Swarbrick wrote:

>What I would love to see is some sort of "single signon" option, where a user 
>would only need
>to sign on to their personal workstation and not need to explicitly sign on to 
>z/OS at all.

IMO, this is a bad idea unless you can count on everyone's workstation being at 
least as secure
as z/OS is. All you need is one user who gets their PC hacked and the hacker 
has access to z/OS,
with whatever authority that user has.

--
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: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)

[Frank Swarbrick]

It's simple enough to write your own CICS signon screen to allow for longer 
user IDs (and passwords/phrases), but I think CICS would have to add support 
for the EXEC CICS SIGNON command to allow for a longer user ID.  Currently:
"
USERID(data-value)
Specifies the 8-byte sign-on user ID.

The user ID supplied is converted to uppercase.

"
They did, of course, already add support for a "PASSPHRASE" of up to 100 
characters.



From: IBM Mainframe Discussion List  on behalf of 
Wayne Bickerdike 
Sent: Monday, May 4, 2020 2:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)

There are more CICS users than TSO users. Is there a howto for the CICS
signon screen to accept long IDs and Passphrases?

On Mon, May 4, 2020 at 6:03 PM Timothy Sipples  wrote:

> Bob Bridges wrote:
> >So maybe - maybe, I don't know either - if I sign on to z/OS with a
> >certificate, or LDAP, or anything other than the usual, the sign-on
> routine
> >MAKES UP an 8-byte ID and stores it in the ACEE. If so, after that
> >everything works fine, I guess.
>
> I don't think RACF itself works that way, or at least the z/OS 2.4
> documentation doesn't suggest so. Take a look at this information, for
> example:
>
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Certificate_mapping.htm
>
> Let's suppose the user is authenticating with RACF (not with the IBM
> Directory Server for z/OS, a.k.a. "LDAP"), and the user transmits an X.509
> client digital certificate for that purpose. RACF has to know ahead of
> time whether or not to authenticate that particular user (digital
> certificate). So the digital certificate has to be known to RACF ahead of
> time. Since the digital certificate has to be known, it's not unreasonable
> to associate an up to 8 character "short" user ID with that certificate.
> And that's how it works, as I understand it. The user doesn't present the
> short user ID -- well, not really, I'll get to this in a moment -- but
> RACF can check the certificate and create an ACEE with a mapped short user
> ID.
>
> There are three basic choices here as I understand it:
>
> 1. A one-to-one mapping (one certificate to short ID ABCD1234). The
> documentation does a little bit of handwaving here along the lines of
> "this might be difficult to administer," but I'd argue that's somewhat
> dated advice now that so many organizations use identity management tools.
>
> 2. A many-to-one mapping (multiple certificates to ABCD1234).
>
> 3. Either mapping, but with the certificate itself holding an embedded
> short name ("hostIdMapping"). Certificate issuers don't typically support
> this extension, or at least they hide it well, but the z/OS PKI Services
> do. (Is this technique "cheating"? Not really)
>
> In all these cases the user need not be aware there's a short name that
> RACF uses "under the covers." The user just supplies a valid, unexpired
> client certificate -- from a PIN-protected smart card perhaps. From RACF's
> perspective the X.509 digital certificate is really just another alias, a
> verbose one.
>
> z/OS LDAP also supports broadly similar RACF ID mapping (supply a long CN,
> which the directory maps to a short name), but it's optional. You can
> certainly authenticate with LDAP as a standalone matter if you wish.
>
> It's an interesting idea to have a fourth option for digital certificate
> authentication with RACF, which would be like choice #1 but without
> telling RACF what the short user ID is ahead of time -- to let RACF create
> one "on the fly," probably with caching and templating. For example, allow
> me to register a bunch of digital certificates in RACF as valid users, but
> I'm not going to tell you (RACF) what their short user IDs are ahead of
> time. The first time you encounter a particular certificate, just create a
> short user ID of C$-- (where the dashes are RACF's randomized or
> sequential choice, of any length -- randomized as default, but sequential
> as an option), store it, and use that on-the-fly short ID to build the
> ACEE. For example. I'd have to ponder that one a bit more, but if you
> think you've got a good use case, ask (RFE).
>
> Of course it'd be "nice" to have more than a maximum 8 character ID (with
> the current maximum of 39 different characters per position) internally in
> RACF, but I imagine that'd be a big plumbing problem and potentially break
> a lot of important stuff if not done carefully. Fortunately, you're not
> required to limit users' experiences to maximum 8 character user IDs: use
> LDAP CNs, use digital certificates, or use something else.
>
> By the way, if someone is looking for an interesting project, I'd be
> pretty neat to have a sample TSO/E signon screen that accepts a LDAP CN
> and passphrase that's then checked against the IBM Directory Server for
> z/OS for authentication (and thus also with the SAF security provider,
> 

Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)

[Frank Swarbrick]

Interesting stuff.  I certainly won't claim to understand it all.
What I would love to see is some sort of "single signon" option, where a user 
would only need to sign on to their personal workstation and not need to 
explicitly sign on to z/OS at all.  It seems like (to me, anyway!) a user could 
use a TN3270 application to connect to the z/OS Communication Server and 
somehow a credential authentication could be done between the TN3270 client and 
the TN3270 server.  I think then CICS/TSO/etc. would need to query the "TN3270 
session" and bypass the associated signon screen(s) if the session has already 
been authenticated.  Or something like that.  Does this sound remotely in the 
realm of possibility?


From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Monday, May 4, 2020 2:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)

Bob Bridges wrote:
>So maybe - maybe, I don't know either - if I sign on to z/OS with a
>certificate, or LDAP, or anything other than the usual, the sign-on
routine
>MAKES UP an 8-byte ID and stores it in the ACEE. If so, after that
>everything works fine, I guess.

I don't think RACF itself works that way, or at least the z/OS 2.4
documentation doesn't suggest so. Take a look at this information, for
example:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Certificate_mapping.htm

Let's suppose the user is authenticating with RACF (not with the IBM
Directory Server for z/OS, a.k.a. "LDAP"), and the user transmits an X.509
client digital certificate for that purpose. RACF has to know ahead of
time whether or not to authenticate that particular user (digital
certificate). So the digital certificate has to be known to RACF ahead of
time. Since the digital certificate has to be known, it's not unreasonable
to associate an up to 8 character "short" user ID with that certificate.
And that's how it works, as I understand it. The user doesn't present the
short user ID -- well, not really, I'll get to this in a moment -- but
RACF can check the certificate and create an ACEE with a mapped short user
ID.

There are three basic choices here as I understand it:

1. A one-to-one mapping (one certificate to short ID ABCD1234). The
documentation does a little bit of handwaving here along the lines of
"this might be difficult to administer," but I'd argue that's somewhat
dated advice now that so many organizations use identity management tools.

2. A many-to-one mapping (multiple certificates to ABCD1234).

3. Either mapping, but with the certificate itself holding an embedded
short name ("hostIdMapping"). Certificate issuers don't typically support
this extension, or at least they hide it well, but the z/OS PKI Services
do. (Is this technique "cheating"? Not really)

In all these cases the user need not be aware there's a short name that
RACF uses "under the covers." The user just supplies a valid, unexpired
client certificate -- from a PIN-protected smart card perhaps. From RACF's
perspective the X.509 digital certificate is really just another alias, a
verbose one.

z/OS LDAP also supports broadly similar RACF ID mapping (supply a long CN,
which the directory maps to a short name), but it's optional. You can
certainly authenticate with LDAP as a standalone matter if you wish.

It's an interesting idea to have a fourth option for digital certificate
authentication with RACF, which would be like choice #1 but without
telling RACF what the short user ID is ahead of time -- to let RACF create
one "on the fly," probably with caching and templating. For example, allow
me to register a bunch of digital certificates in RACF as valid users, but
I'm not going to tell you (RACF) what their short user IDs are ahead of
time. The first time you encounter a particular certificate, just create a
short user ID of C$-- (where the dashes are RACF's randomized or
sequential choice, of any length -- randomized as default, but sequential
as an option), store it, and use that on-the-fly short ID to build the
ACEE. For example. I'd have to ponder that one a bit more, but if you
think you've got a good use case, ask (RFE).

Of course it'd be "nice" to have more than a maximum 8 character ID (with
the current maximum of 39 different characters per position) internally in
RACF, but I imagine that'd be a big plumbing problem and potentially break
a lot of important stuff if not done carefully. Fortunately, you're not
required to limit users' experiences to maximum 8 character user IDs: use
LDAP CNs, use digital certificates, or use something else.

By the way, if someone is looking for an interesting project, I'd be
pretty neat to have a sample TSO/E signon screen that accepts a LDAP CN
and passphrase that's then checked against the IBM Directory Server for
z/OS for authentication (and thus also with the SAF security provider,
indirectly). This part of the z/OS 

Re: Mainframe user ID length

[Frank Swarbrick]

MQ does, in fact, support that, and I've used it.  It's the "Channel 
Authentication" user mapping feature.
I was just wondering if it was "directly supported" without a mapping, if the 
presented user ID was more than 8 characters.
Thanks.


From: IBM Mainframe Discussion List  on behalf of 
Walt Farrell 
Sent: Sunday, May 3, 2020 7:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Mainframe user ID length

On Thu, 30 Apr 2020 19:46:04 +0000, Frank Swarbrick 
 wrote:

>Is z/OS still limited in all cases to 8 upper case characters?  I am curious 
>if a user that only has access to MQ might be able to have a longer and
>ideally mixed case user ID.  They wouldn't have access to TSO or CICS or IMS.

It is in theory possible for an application (such as MQ) to use z/OS security 
services to map an alternative identity (which might have different 
characteristics from a z/OS user ID) into a standard z/OS user ID.

That can be done, for example, when applications support authentication via 
digital certificates, or via Kerberos (e.g., Windows Active Directory), or via 
LDAP. And there are additional mechanisms besides those three that z/OS 
supports.

I have no idea whether MQ supports any of those alternative mechanisms, nor 
which ones, nor whether they're applicable in your environment.

--
Walt

--
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: Mainframe user ID length

[Frank Swarbrick]

Wow! That's a lot to digest.
A couple of things.  First, I see the following documented:

“On z/OS® and UNIX and Linux, the maximum length of a user ID is 12 
characters.”  From 
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q010300_.htm

I wonder how this works if RACF user IDs are only allowed up to 8 characters.  
Would an alternate SAF product be required?  I can't see anything documented to 
explain how this might work.


On a separate line, are you saying is it possible for z/OS to use a non-z/OS 
LDAP server for authentication (and authorization?), including user IDs and 
passwords?  But this would that still require TSO and CICS (and IMS? and 
others?) signon processes to be able to handle those user IDs?  It sounds like 
both of these things are true, but I want to make sure I am not 
misunderstanding you.


From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Saturday, May 2, 2020 12:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Mainframe user ID length

Frank Swarbrick wrote:
>"more than 8"?  What's the limit, if any?

The z/OS LDAP Server's CN limit is 256 characters, so it's at least that
large.

>Which system components/products permit/prohibit this?
>(Start your list with JCL.)

You can specify pretty much anything you want in JCL. Do you mean JES2? If
so, that'll use maximum 8 character user IDs.

Whatever list I come up with is necessarily going to be partial, but as
we've already seen (I linked to the documentation) MQ for z/OS can
authenticate users with the IBM Directory Server for z/OS at least in
certain contexts. CICS Transaction Server for z/OS also can in certain
contexts. See for example this documentation:

https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html

Other z/OS components and products that come to mind include the z/OS
Container Extensions, WebSphere Application Server for z/OS, and the IBM
HTTP Server for z/OS. See for example here:

https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html

There are quite a large number of intersections, so many that we've now
reached the stage when one of them fell overboard. z/OS HCD had some LDAP
affinities (would you believe), but they were removed in z/OS 2.3.
Evidently that one was too "crazy." :-)

Bob Bridges wrote:
>I'm about to expose my ignorance here: IDS and LDAP, aren't they just
>IBM's attempt to let z/OS talk to non-z/OS systems?

No, not according to IBM. Right at the very beginning of the IBM (Tivoli)
Directory Server for z/OS redbook, Section 1.1, it says that this
component is for both z/OS and non-z/OS workloads. So take the hint: if
maximum 8 character user IDs are constraining, then start using the IBM
Directory Server for z/OS to authenticate users if you aren't already,
as/where it makes sense for you. Or use a certain something else to
authenticate (see below).

>Or put it this way: If you say I can be authenticated via LPAR using a
>longer ID, and then perform tasks on the mainframe using that ID, how
does
>RACF-or-whatever determine permissions?

First of all, you didn't include "RACF" in the text I reacted to. RACF is
a popular but optional z/OS component. z/OS is not equivalent to RACF.
Second, if you are talking about RACF specifically, yes, it does use
maximum 8 character user IDs But you're not required to authenticate
with them. I (somewhat facetiously) pointed out that you don't have to
authenticate at all, although (as I also pointed out) I'll urge you to at
least perform authorizations. More seriously, z/OS RACF has supported
client certificate authentication since the 1990s. (This feature was
initially introduced way back in the OS/390 days. The OS/390 TN3270E
Server picked up support for it with OS/390 2.9, backported to 2.8. IBM
Personal Communications picked up support for this feature in the late
1990s, too.) See here for an introductory reference:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Enabling_client_login_using_certificates.htm

In this case users don't present maximum 8 character user IDs at all, or
not really. They present digital certificates, and those may be coming
from PIN-protected smart cards for example. Please do check this out! It's
a really nifty solution, and the world seems to be (re)discovering it
lately.

Another approach you can take is to authenticate with the IBM Directory
Server for z/OS (or other LDAP server, but that one is a terrific one) and
leverage a mapping to a "short name." This is the approach z/VSE takes
when you turn on its included LDAP authentication support, and it's both
simple and clever. You're certainly free to submit RFEs for IBM's
consideration if you'd like more such features, such as a TSO/E sign on
screen comparable to z/VSE's LDAP friendly sign on scree

Re: Mainframe user ID length

[Frank Swarbrick]

Thanks.


From: IBM Mainframe Discussion List  on behalf of 
Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, April 30, 2020 1:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Mainframe user ID length

Looks like it. I tried to add a userid with 9 characters, it wouldn't accept 
it. i didn't try lower case in a batch job, but I'd assume it would be 
converted to uppercase.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐
On Thursday, April 30, 2020 3:46 PM, Frank Swarbrick 
 wrote:

> Is z/OS still limited in all cases to 8 upper case characters? I am curious 
> if a user that only has access to MQ might be able to have a longer and 
> ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS.
>
> -
>
> 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: Mainframe user ID length

[Frank Swarbrick]

I'm asking about the user ID, not the password/pass phrase.  But thanks.


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Thursday, April 30, 2020 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Mainframe user ID length

RACF can now handle 'password phrase' of considerable length and/or upper/lower 
case passwords. If you allow lower case, you can end up with a mess. With 
traditional upper-only system option, a password typed e.g. via TSO gets 
automatically translated to upper case with no user notification. With the 
system option set to lower case allowed, that translation does not occur. This 
means that every password entry *must* also be lower case. Some logon 
environments may not allow lower case. Worse, if there is a severe problem that 
requires fallback to upper only, a user with a lower case password may not be 
able to logon at all.

This is an all or nothing option. Allowing or disallowing lower case affects 
all environments at the same time.

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Thursday, April 30, 2020 12:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Mainframe user ID length

CAUTION EXTERNAL EMAIL

Is z/OS still limited in all cases to 8 upper case characters?  I am curious if 
a user that only has access to MQ might be able to have a longer and ideally 
mixed case user ID.  They wouldn't have access to TSO or CICS or IMS.


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

Mainframe user ID length

[Frank Swarbrick]

Is z/OS still limited in all cases to 8 upper case characters?  I am curious if 
a user that only has access to MQ might be able to have a longer and ideally 
mixed case user ID.  They wouldn't have access to TSO or CICS or IMS.

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

Re: Latest COBOL standard is 2014 was Re: Cobol

[Frank Swarbrick]

And believe it or not, there is an ISO group working on a 202X standard for 
COBOL.


From: IBM Mainframe Discussion List  on behalf of 
Clark Morris 
Sent: Monday, April 27, 2020 7:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Latest COBOL standard is 2014 was Re: Cobol

[Default] On 27 Apr 2020 00:29:21 -0700, in bit.listserv.ibm-main
dcrayf...@gmail.com (David Crayford) wrote:

>Define modern? A language is only as modern as its last standard (or
>version). For example, Python is considered a modern language although
>it's 30 years old. It's constantly
>being updated. Python 3.6 supports static type checking! JavaScript is
>the same. C++20 is being ratified, C2x is being worked on. Java 13 is
>going to GA on z/OS this year!
>
>It's my understanding that COBOL-85 is the current standard in use on
>z/OS? That's probably indicative of COBOL programmers not requiring new
>language features as they don't
>need them to maintain the code bases that they work on. COBOL
>modernization on z/OS has mostly been back-end optimizer work which is
>probably a lot more valuable to z/OS
>IT managers then new language features that won't be used. If companies
>want to modernize a COBOL application they integrate with Java like CICS
>and IMS.

The latest COBOL standard is 2014 with 2002 and 1989 extensions being
predecessors.  The 2014 standard supports IEEE binary floating point
plus IEEE decimal floating point with all of the rounding options
including round to nearest even.  There also are true binary usages
including binary character and USAGE BIT along with boolean
operations.  There is everything needed to fully work with SMf 30
records without weird coding.  It would allow a relatively straight
forward conversion of Assembler DSECTS to COBOL.  Because it has
language to support all of the IEEE fixed and floating point binary
usages, IEEE and hex floating point could co-exist in the same
program.  I wanted USAGE BIT 50 years ago because I was dealing with
bit switches on customer, product and open account files.

Clark Morris
>
>REXX hasn't changed in almost 30 years. There's been a few updates to
>TSO REXX such as EXECIO VBS support but that's about all.
>
>On 2020-04-25 7:03 AM, Wayne Bickerdike wrote:
>> One of our guys was talking about modern languages such as C. I said what?
>>
>> On Sat, Apr 25, 2020 at 7:01 AM Seymour J Metz  wrote:
>>
>>> Well what do you know? The emperor has no clothes. We shot an innocent
>>> language.
>>>
>>>
>>> --
>>> 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: Friday, April 24, 2020 3:58 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Cobol
>>>
>>> On Fri, 24 Apr 2020 18:26:49 +, Seymour J Metz wrote:
>>>
 There are blurbs for dozens of articles; which one is relevant? I tried
>>> searxhing for COBOL, but got 0 hits.
>>> I suspect that was OP's desperate and futile attempt to circumvent
>>> secureweb,
>>> as you often do.  But, I hope (posting from web interface):
>>>
>>> https://secure-web.cisco.com/18wMr2wQiot_mC2NJkJL7buWujrBfP9suLfEWZL4dG8gjB_Zjaj31ZgILnrnn--CfD_RooCYfsFjxvxArhRiN2V2tCmTfs8NayUQCV2ProhQ0KfRlDMDZdg2alKOSjuWwTXeK_Lci9elkht49bjva6Fj7o1W1SIr2REv9PF2NO_PK0BStoe0irBBLJRM9a_tKg3QNHj3DghbIM6_s_J2QBa8K1XWudsYnadGx1bdpDNNTapriOq_jLHjoC742AxmqQVAJ4Szwl0aLrINIHWnzPzP_p0N_kYOi4keUEoOLuWRccU_ZVES-3NC05VlKLovPbiDfx9BUbsi3Kn4nGo1sHGipsJJfPFN4ClnEGuuMjWs6LU9f2293Fm0jTt3GhayZHNNDR8prcppx857Qz_vQpR6HOUIxm-p1DAvFYE8aFU_B3Da9y60snIIWQxr9qfkI67XWmwAvbGdgFfA9cP_uBHV85oupnnYfOSco5uQPIVE/https%3A%2F%2Fwww.wired.com%2Fstory%2Fcant-file-unemployment-dont-blame-cobol%2F
>>>
>>> 
>>> From: scott Ford
>>> Sent: Friday, April 24, 2020 2:08 PM
>>>
>>> See this url ...
>>>
>>>
>>> http://secure-web.cisco.com/1DYCAeckpzqV94PQWw8dHuuJalhW0eVroAe-0-S4pJl_FnqGfZxS4EcWK7cCAl1oA09gJJKNMcHC1Be4KK3D-KcMIEVRVBeNOw5sf7565Z6e9CTYIm43a-oit3GGWnum7LgBTpYCxV6CAhgR9TuXipYHaUjUUPtd7BICMs1zfFGQQ8NhAeXHdXvHPrGdxzaQmTRfNi8vGWGKk4fg_G75au8H3Ja9AbLwRb2m8-upI9jYdmy1ZYdzYlRF2kzlwN155wAFEug02LCkZ5Bpk3IvSuxwzwd1UUyk_5NUmIqwMFmcDxZ8SpSnwFspncJTV1bLmByZAIVczBfj-JctXDA5Ta99YBqxx1tBpdl0qN5MWPGsz1CGAQ_Is1sLoRxy9Dl_fCLgMhLDvO5L8-EsVff2IiswF1xKvwUDiAEPcV0mOxz5c915mExQuVbCTDL0KTJQEtCF5dYTiss8HJIK_dzSG8g/http%3A%2F%2Fwww.wired.com.
>>>Can't File for Unemployment - Don?t Blame Cobol
>>>
>>> -- 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: 

Re: C

[Frank Swarbrick]

The "1974" COBOL compiler (OS/VS COBOL) required the printer control character 
to be explicitly defined.  This "bug" can be "emulated" with VS COBOL II and 
subsequent compilers by specifying the "NOADV" compiler option.  Not 
recommended for new programs, but useful when migrating from OS/VS COBOL.


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Monday, April 27, 2020 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: C

That's a bug; the carriage control character is supposed to be transparent to 
the COBOL programmer.


--
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 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C

On Mon, 27 Apr 2020 15:06:03 +1000, Wayne Bickerdike wrote:
>
>I had neither mainframe COBOL nor SPPS skills but I'd written a whole bunch
>of Microfocus COBOL on CP/M micros.
>
>I convinced them that I could do mainframe COBOL, which wasn't that
>difficult. When I looked at the SPPS code, it was macro Assembler, so that
>was the start of a short time with same.
>
My one foray into COBOL occurred when I worked for a small consulting
firm.  Warm body with no COBOL skill.  I developed a small COBOL
program timesharing to DECSystem-10.

My co-worker carried it to client's IBM 360.

Failed.

Using AFTER ADVANCING construct in IBM COBOL clobbers the first
character of my data record.  Who woulda thunk it?

DEC COBOL, more wisely IMO, prefixes the intact record with LF, FF,
whatever carriage motion command(s).  Better design; standard be
damned!

-- 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: IGYSC2025-W cobol message

[Frank Swarbrick]

Is SAS-BLOCK or B-C-BILL ever referred to later in the program?  If so, post 
the code.  If not then just delete both fields from the linkage section.


From: IBM Mainframe Discussion List  on behalf of 
Mahesh KN 
Sent: Friday, April 24, 2020 5:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: IGYSC2025-W cobol message

thanks Max,
i have more interesting code that looks like below.
 15   *
 16   *   L I N K A G E   S E C T I O N   *
 17   *
 18LINKAGE SECTION.
 1901 DFHCOMMAREA.
 20   05 A-C-BILL PIC S9(8) COMP.
 2201 SAS-BLOCK.
 23   05 B-C-BILL PIC S9(8) COMP.
 24   *
 25   *P R O C E D U R E   D I V I S I O N*
 26   *
 27PROCEDURE DIVISION.
 28MOVE A-C-BILL to B-C-BILL.

in the above case, i think both 9(8) comp fields are some addresses(which 
doesnt matter much anyway) . But i still get IGYSC2025 warning on line 22 
SAS-BLOCK field definition.


From: IBM Mainframe Discussion List  on behalf of 
Massimo Biancucci 
Sent: Friday, April 24, 2020 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: IGYSC2025-W cobol message

Hi,

any area having not an address can be a potential problem.

A sample of the code would have been better.
Anyway look at this:

 15   *

 16   *   L I N K A G E   S E C T I O N   *

 17   *

 18LINKAGE SECTION.

 1901 PARM.

 20   05 PARM-PTR USAGE IS POINTER.

 21

 2201 QQ PIC X(2).

 2301 QQ2 PIC X(2).

 24   *

 25   *P R O C E D U R E   D I V I S I O N*

 26   *

 27PROCEDURE DIVISION USING PARM.

 28

 29DISPLAY 'ZPLINKUS - INIZIO'

 30DISPLAY QQ

 31

 32SET ADDRESS OF QQ2 TO PARM-PTR

 33DISPLAY QQ2

 34

 35DISPLAY 'ZPLINKUS - FINE'

 36

 37GOBACK.

..


22  IGYSC2025-W   "QQ" or one of its subordinates was referenced, but
"QQ" w
  addressability.  This reference will not be resolved
succe
MessagesTotalInformationalWarningErrorSevere
 Terminating

As you can see compiler warns on QQ and not on QQ2.

QQ will have not a valid address and this will lead to abend (if you're
lucky) or to result error (difficult to diagnose).
So you should be sure the variable address had been set before using it.
Maybe compiler didn't understand a SET even though I think it's not so.

I've lots of examples where "bad programs ran properly" on V4 and prior and
abended on V5 or later because of bad addressed areas or misleaded
parm-area length.

Regards.
Max



Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno ven 24 apr 2020 alle ore 09:51 Mahesh KN  ha
scritto:

> We are upgrading the Cobol to Cobol v 6.2.0. We have a program that was
> compile on Cobol v4.* and probably the code was running fine. But our shop
> has setup to take IGYSC2025 warnings seriously and not proceed with
> compilation under Cobol V6.
> So i am wondering how adsressability works if a linkage section variable
> is used in the program without having "USING" clause in the procedure
> section.
> There seems to be a misuse of linkage section to declare large copybooks
> to 'save' space while compiling. I am into application programming and
> didnt understand the full implication of IGYSC2025 warnings.
> thanks
> Mahesh.
>
> [
> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif
> ]<
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> Virus-free. www.avast.com<
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
>
> 

Re: Why rip out COBOL when you can modernize key applications? - Weirdware

[Frank Swarbrick]

Yes, very verbose.
And yes, recursion is possible, but you must specify "IS RECURSIVE" on the 
PROGRAM-ID.  Not sure what having nested programs has to do with that, though.


From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Tuesday, April 7, 2020 7:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Why rip out COBOL when you can modernize key applications? - 
Weirdware

Wow, and some people criticize Java for being verbose!

So using nested programs one can implement recursion in COBOL which you
couldn't do before without using a table stack.

On 2020-04-08 5:14 AM, Frank Swarbrick wrote:
> Nested subroutines.
>
> Small example:
>
>   ID DIVISION.
>   PROGRAM-NAME. MAINPROG.
>   [...]
>   PROCEDURE DIVISION.
>   CALL 'NESTED-PROGRAM-1'
>   GOBACK.
>
>   ID DIVISION.
>   PROGRAM-ID. NESTED-PROGRAM-1.
>   DATA DIVISION.
>   WORKING-STORAGE SECTION.
>   01  LOCAL-VAR-1 PIC X.
>   [...]
>   PROCEDURE DIVISION.
>   DISPLAY 'IN NESTED-PROGRAM-1'
>   GOBACK.
>
>   END PROGRAM NESTED-PROGRAM-1.
>
>   END PROGRAM MAINPROG.
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Spiegel 
> Sent: Tuesday, April 7, 2020 2:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Why rip out COBOL when you can modernize key applications? - 
> Weirdware
>
> Hi Frank,
> Thank you for that information.
> (All the COBOL I support(ed) didn't contain these and neither did my
> university courses in the '70s.)
>
> If I wanted to look them up, which keyword(s) would I use?
>
> Thanks and regards,
> David
>
> On 2020-04-07 15:49, Frank Swarbrick wrote:
>> Internal subroutines and local variables have been supported since COBOL 
>> 1985 (VS COBOL II era).
>> They're not ideal, but they do exist.
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> David Spiegel 
>> Sent: Tuesday, April 7, 2020 12:58 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU 
>> Subject: Re: Why rip out COBOL when you can modernize key applications? - 
>> Weirdware
>>
>> How about no internal subroutines with local variables?
>>
>> On 2020-04-07 14:47, Bob Bridges wrote:
>>> I used to bad-mouth COBOL, and I still prefer languages that are less 
>>> wordy.  But I came somewhat reluctantly to see that it has its strengths.  
>>> The one I think most important is that it encourages even novice 
>>> programmers to organize their logic in what we used to call a "top-down" 
>>> manner:  This paragraph accomplish a certain task by executing paragraphs 
>>> one through three, then two more, and this subparagraph executes 
>>> subsubparagraphs, and so on.  Forms good habits, I think.
>>>
>>> ---
>>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>>>
>>> /* My life is in the hands of any fool who can make me lose my temper.  
>>> -driving motto */
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>>> Behalf Of scott Ford
>>> Sent: Tuesday, April 7, 2020 12:55
>>>
>>> I learned Assembler first and then Cobol and then some PL/1.  I always felt 
>>> each language had its strengths and weaknesses and all were like tools in a 
>>> toolbox.
>>>
>>> --
>>> 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

--
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: Why rip out COBOL when you can modernize key applications? - Weirdware

[Frank Swarbrick]

Sorry, I guess technically they are "nested programs".


From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Tuesday, April 7, 2020 3:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Why rip out COBOL when you can modernize key applications? - 
Weirdware

Nested subroutines.

Small example:

 ID DIVISION.
 PROGRAM-NAME. MAINPROG.
 [...]
 PROCEDURE DIVISION.
 CALL 'NESTED-PROGRAM-1'
 GOBACK.

 ID DIVISION.
 PROGRAM-ID. NESTED-PROGRAM-1.
 DATA DIVISION.
 WORKING-STORAGE SECTION.
 01  LOCAL-VAR-1 PIC X.
 [...]
 PROCEDURE DIVISION.
 DISPLAY 'IN NESTED-PROGRAM-1'
 GOBACK.

 END PROGRAM NESTED-PROGRAM-1.

 END PROGRAM MAINPROG.


From: IBM Mainframe Discussion List  on behalf of 
David Spiegel 
Sent: Tuesday, April 7, 2020 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Why rip out COBOL when you can modernize key applications? - 
Weirdware

Hi Frank,
Thank you for that information.
(All the COBOL I support(ed) didn't contain these and neither did my
university courses in the '70s.)

If I wanted to look them up, which keyword(s) would I use?

Thanks and regards,
David

On 2020-04-07 15:49, Frank Swarbrick wrote:
> Internal subroutines and local variables have been supported since COBOL 1985 
> (VS COBOL II era).
> They're not ideal, but they do exist.
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Spiegel 
> Sent: Tuesday, April 7, 2020 12:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Why rip out COBOL when you can modernize key applications? - 
> Weirdware
>
> How about no internal subroutines with local variables?
>
> On 2020-04-07 14:47, Bob Bridges wrote:
>> I used to bad-mouth COBOL, and I still prefer languages that are less wordy. 
>>  But I came somewhat reluctantly to see that it has its strengths.  The one 
>> I think most important is that it encourages even novice programmers to 
>> organize their logic in what we used to call a "top-down" manner:  This 
>> paragraph accomplish a certain task by executing paragraphs one through 
>> three, then two more, and this subparagraph executes subsubparagraphs, and 
>> so on.  Forms good habits, I think.
>>
>> ---
>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>>
>> /* My life is in the hands of any fool who can make me lose my temper.  
>> -driving motto */
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of scott Ford
>> Sent: Tuesday, April 7, 2020 12:55
>>
>> I learned Assembler first and then Cobol and then some PL/1.  I always felt 
>> each language had its strengths and weaknesses and all were like tools in a 
>> toolbox.
>>
>> --
>> 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

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

Re: Why rip out COBOL when you can modernize key applications? - Weirdware

[Frank Swarbrick]

Nested subroutines.

Small example:

 ID DIVISION.
 PROGRAM-NAME. MAINPROG.
 [...]
 PROCEDURE DIVISION.
 CALL 'NESTED-PROGRAM-1'
 GOBACK.

 ID DIVISION.
 PROGRAM-ID. NESTED-PROGRAM-1.
 DATA DIVISION.
 WORKING-STORAGE SECTION.
 01  LOCAL-VAR-1 PIC X.
 [...]
 PROCEDURE DIVISION.
 DISPLAY 'IN NESTED-PROGRAM-1'
 GOBACK.

 END PROGRAM NESTED-PROGRAM-1.

 END PROGRAM MAINPROG.


From: IBM Mainframe Discussion List  on behalf of 
David Spiegel 
Sent: Tuesday, April 7, 2020 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Why rip out COBOL when you can modernize key applications? - 
Weirdware

Hi Frank,
Thank you for that information.
(All the COBOL I support(ed) didn't contain these and neither did my
university courses in the '70s.)

If I wanted to look them up, which keyword(s) would I use?

Thanks and regards,
David

On 2020-04-07 15:49, Frank Swarbrick wrote:
> Internal subroutines and local variables have been supported since COBOL 1985 
> (VS COBOL II era).
> They're not ideal, but they do exist.
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Spiegel 
> Sent: Tuesday, April 7, 2020 12:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Why rip out COBOL when you can modernize key applications? - 
> Weirdware
>
> How about no internal subroutines with local variables?
>
> On 2020-04-07 14:47, Bob Bridges wrote:
>> I used to bad-mouth COBOL, and I still prefer languages that are less wordy. 
>>  But I came somewhat reluctantly to see that it has its strengths.  The one 
>> I think most important is that it encourages even novice programmers to 
>> organize their logic in what we used to call a "top-down" manner:  This 
>> paragraph accomplish a certain task by executing paragraphs one through 
>> three, then two more, and this subparagraph executes subsubparagraphs, and 
>> so on.  Forms good habits, I think.
>>
>> ---
>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>>
>> /* My life is in the hands of any fool who can make me lose my temper.  
>> -driving motto */
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of scott Ford
>> Sent: Tuesday, April 7, 2020 12:55
>>
>> I learned Assembler first and then Cobol and then some PL/1.  I always felt 
>> each language had its strengths and weaknesses and all were like tools in a 
>> toolbox.
>>
>> --
>> 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: Why rip out COBOL when you can modernize key applications? - Weirdware

[Frank Swarbrick]

Internal subroutines and local variables have been supported since COBOL 1985 
(VS COBOL II era).
They're not ideal, but they do exist.


From: IBM Mainframe Discussion List  on behalf of 
David Spiegel 
Sent: Tuesday, April 7, 2020 12:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Why rip out COBOL when you can modernize key applications? - 
Weirdware

How about no internal subroutines with local variables?

On 2020-04-07 14:47, Bob Bridges wrote:
> I used to bad-mouth COBOL, and I still prefer languages that are less wordy.  
> But I came somewhat reluctantly to see that it has its strengths.  The one I 
> think most important is that it encourages even novice programmers to 
> organize their logic in what we used to call a "top-down" manner:  This 
> paragraph accomplish a certain task by executing paragraphs one through 
> three, then two more, and this subparagraph executes subsubparagraphs, and so 
> on.  Forms good habits, I think.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* My life is in the hands of any fool who can make me lose my temper.  
> -driving motto */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of scott Ford
> Sent: Tuesday, April 7, 2020 12:55
>
> I learned Assembler first and then Cobol and then some PL/1.  I always felt 
> each language had its strengths and weaknesses and all were like tools in a 
> toolbox.
>
> --
> 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: GOTOs (was CLIST)

[Frank Swarbrick]

A bit off topic perhaps, but COBOL now supports the following:

EXIT PERFORM (like LEAVE)
EXIT PERFORM CYCLE (like ITERATE)
EXIT PARAGRAPH (like LEAVE but exists the current COBOL paragraph)
EXIT SECTION (like LEAVE but exists the current COBOL section)


You can even exit from a simple block, which you mentioned REXX does not 
support:

PERFORM
DISPLAY 'SOMETHING'
IF A = 1
EXIT PERFORM
END-IF
DISPLAY 'SOMETHING ELSE'
END-PERFORM

One thing missing is an "infinite loop" (do forever).  I have requested support 
of "PERFORM UNTIL EXIT" to allow for this.  Feel free to vote for my RFE!  
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=133631


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Tuesday, March 24, 2020 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: GOTOs (was CLIST)

There is such a thing as overdoing GOTOs, but I agree that a blanket 
never-do-it rule is counter-productive.  I don't often use SIGNAL in REXX, 
because I find that its structured features are adequate.  But in other 
languages I have argued for limited GOTO use.

In COBOL, for example, it seems to me that there's a place for GOTO 
TOP-OF-PARAGRAPH (to simulate ITERATE in REXX), GOTO EXIT-PARAGRAPH (to 
simulate LEAVE) and GOTO END-OF-PROGRAM (for controlled abend conditions).  
These don't violate structured-programming principles, they implement them.  In 
VBA I freely use Goto IterateSomething (putting the label just before the Next 
statement).  I don't think PL/1 ever needs it, but I'm glad it's there just in 
case.

Even in REXX there's one missing structured ingredient: some way to leave a 
~simple~ block.  A SELECT comes close, but it's not perfect.  Say you're 
looping through a list of candidates and have to perform a number of candidates:

  do jr=1 to stem.0
v0=stem.jr
if v0='' then iterate
v1=function1(v0)
if v1<5 then iterate
v2=functionv2(v1 + othervalue)
if v2=previous then iterate
say 'TRK:' v0 v1 v2
end

That's great in a controled DO loop.  But it's harder in simple block of code.  
A SELECT won't do the job, because of the calculations you have to do between 
the various tests.  I handle it this way:

  do 1
if v0='' then leave
v1=function1(v0)
if v1<5 then leave
v2=functionv2(v1+othervalue)
if v2=previous then leave
say 'TRK:' v0 v1 v2
end

I always suspect I'd get complaints from structured enthusiasts if they ever 
saw me cheating like that.  In VBA I can't "Do 1", but I can do this:

  Do 'one time
If v0 = '' Then Exit Do
v1 = function1(v0)
If v1 < 5 Then Exit Do
v2 = functionv2(v1 + othervalue)
If v2 = previous Then Exit Do
MsgBox "TRK: " & v0 & " " & v1 & " " &  v2
Loop Until True

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Being famous has its benefits, but fame isn't one of them.  -Larry Wall */


-Original Message-
From: David Crayford
Sent: Tuesday, March 24, 2020 09:03

If you eschew goto how do you deal with error handling and cleanup using
a language which doesn't support exceptions, finalization or RAII? I find
these kind of blanket rules to lead to bad code with deep nesting and useless
status variables.

--- On 2020-03-21 11:45 PM, Paul Gilmartin wrote:
> o Symbols EXPOSEd from external scopes can't be used as targets
> of ITERATE and LEAVE.  (I eschew GOTO; SIGNAL is worse,)

--
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: Glossary (was: ZOA ... Ansible)

[Frank Swarbrick]

Why not just "UNIX file" or "z/OS UNIX" file?


From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Friday, February 21, 2020 6:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Glossary (was: ZOA ... Ansible)

What's wrong with USS again?  Confusion with VTAM's USS is unlikely, and
neither would the Navy commissioning a new ship named USS Directory.  The
contexts are different.

Replacing a TLA with a half-line phrase isn't viable.

One term that is inherently ambiguous is "zFS file".  That naturally means
a VSAM LDS that holds a USS file system; not USS files, which per se, do
not care what type of file system they are contained in.

My opinions, but I have no objections to others having different ones.

sas


On Fri, Feb 21, 2020 at 12:59 AM Timothy Sipples  wrote:

> Paul Gilmartin wrote:
> >Yes, but zFS is too specific, and at risk of change.
>
> Change cuts both/all ways. There's now at least one base z/OS component
> that uses zFS nontrivially (and requires it) that isn't z/OS UNIX System
> Services.
>
> How about something like this: "...a zFS or other z/OS UNIX compatible
> directory/file/path..."? That'd allow for z/OS NFS, HFS (for now, in z/OS
> releases that provide it), etc. if those are acceptable alternatives.
> "z/OS UNIX" seems to be an acceptable short form of "z/OS UNIX System
> Services," so I think that works. If for some reason the requirement is
> specific to zFS, then it'd just collapse to "a zFS directory/file/path."
> Here's another form, in between those two poles:
>
> "...a z/OS UNIX compatible directory/file/path (zFS recommended)..."
>
> Technical writing with clarity is hard, but I think these constructions
> would be an improvement.
>
> - - - - - - - - - -
> Timothy Sipples
> I.T. Architect Executive
> Digital Asset & Other Industry Solutions
> IBM Z & LinuxONE
> - - - - - - - - - -
> E-Mail: sipp...@sg.ibm.com
>

--
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: Manuals for CA-VOLLIE?

[Frank Swarbrick]

I don't have a Broadcom logon, but did you try this page?
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-miscellaneous/legacy_bookshelves_and_pdfs/bookshelves_and_pdfs/bookshelves/ca-vollie-for-z-vse.html


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Monday, February 3, 2020 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Manuals for CA-VOLLIE?

In my new project assignment, I have to use a tool called VOLLIE (from
CA), which is used to modify (edit)
VSE libraries and prepare compile and test jobs for VSE and COBOL-CICS
programs etc.

No VM in this installation. VOLLIE seems to be a CICS transaction.

Is there a manual for CA-VOLLIE, which can be shared, for example PDF
format?
No match when using the well-known search engines.

Thanks and 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: Manuals for CA-VOLLIE?

[Frank Swarbrick]

You might ask on bit.listserv.vse-l.


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Monday, February 3, 2020 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Manuals for CA-VOLLIE?

In my new project assignment, I have to use a tool called VOLLIE (from
CA), which is used to modify (edit)
VSE libraries and prepare compile and test jobs for VSE and COBOL-CICS
programs etc.

No VM in this installation. VOLLIE seems to be a CICS transaction.

Is there a manual for CA-VOLLIE, which can be shared, for example PDF
format?
No match when using the well-known search engines.

Thanks and 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: Starting an application in ISPF

[Frank Swarbrick]

Apparently I knew how to do this once upon a time, but how do you close a user 
command table in order to allow editing of it?


From: IBM Mainframe Discussion List  on behalf of 
ITschak Mugzach 
Sent: Thursday, January 16, 2020 11:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Starting an application in ISPF

And even simpler, add it's and select cmd options to your ispf command
table. This way you can type a short name to invoke it.

ITschak

בתאריך יום ו׳, 17 בינו׳ 2020, 2:44, מאת Frank Swarbrick ‏<
frank.swarbr...@outlook.com>:

> This works.  Thanks much.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Steve Smith 
> Sent: Thursday, January 16, 2020 5:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Starting an application in ISPF
>
> Just write and invoke a simple exec (or clist if that's your thing):
>
>  /* REXX */
>  ADDRESS ISPEXEC
>  'SELECT PGM(DGTFMD01) NEWAPPL(DGT) SCRNAME(ISMF)'
>  EXIT
>
> You could also invoke it from option 7.1 (Dialog Test), but that adds some
> overhead.
>
> sas
>
>
> On Thu, Jan 16, 2020 at 6:47 PM Frank Swarbrick <
> frank.swarbr...@outlook.com>
> wrote:
>
> > Doesn't work for me.  Must not be in my "profile" or something.
>
> --
> 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: Starting an application in ISPF

[Frank Swarbrick]

"Luckily", whoever set up our system apparently included all of the allocations 
in our standard logon, so I was able to follow Steve Smith's recommendation.  
But your reply is certainly good reference.  Thanks!


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson <02b46c9bbdf0-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, January 16, 2020 5:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Starting an application in ISPF

An ISPF application needs to have all related data sets allocated before the 
application itself starts running. For the 'PDF' application, folks will have 
all necessary ISPxLIBs allocated by logon proc or by some front-end REXX. In 
our shop, applications like ISMF are considered specialized utilities that only 
a handful of folks are expected to run, so it doesn't make sense for every user 
to allocate libraries that will never be used. The problem with just "ISPSTART 
PGM(DGTFMD01) NEWAPPL(DGT)" is that the typical user--in this case YOU--will 
not have the right ISPxLIB environment. Same here, so what we do is provide 
this lines on a menu that the appropriate folks have allocated:

%   ISMF +ISMF%-+Invoke Space Management Functions
...
ISMF,'cmd(%ismfinit ) newappl(dgt) nocheck'
...

This menu can be in your own (pre-allocated) panel library.

REXX ISFMINIT contains this:

/* REXX */
TRACE N
PARSE ARG nextopt .
ADDRESS ISPEXEC
"LIBDEF ISPMLIB DATASET STACK ID('SYS1.DGTMLIB' 'SYS1.DFQMLIB')"
"LIBDEF ISPPLIB DATASET STACK ID('SYS1.DGTPLIB' 'SYS1.DFQPLIB')"
"LIBDEF ISPSLIB DATASET STACK ID('SYS1.DGTSLIB')"
"LIBDEF ISPTLIB DATASET STACK ID('SYS1.DGTTLIB')"
ADDRESS TSO "ALTLIB ACT APPL(CLIST) DATASET('SYS1.DGTCLIB')"
"SELECT PGM(DGTFMD01) PARM("nextopt")"
"LIBDEF ISPMLIB DATASET"
"LIBDEF ISPPLIB DATASET"
"LIBDEF ISPSLIB DATASET"
"LIBDEF ISPTLIB DATASET"
ADDRESS TSO "ALTLIB RESET"

You will need SAF READ access to the ISMF libraries, whatever they're called in 
your shop.


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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Smith
Sent: Thursday, January 16, 2020 4:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Starting an application in ISPF

Just write and invoke a simple exec (or clist if that's your thing):

 /* REXX */
 ADDRESS ISPEXEC
 'SELECT PGM(DGTFMD01) NEWAPPL(DGT) SCRNAME(ISMF)'
 EXIT

You could also invoke it from option 7.1 (Dialog Test), but that adds some 
overhead.

sas


On Thu, Jan 16, 2020 at 6:47 PM Frank Swarbrick 
wrote:

> Doesn't work for me.  Must not be in my "profile" or something.


--
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: Starting an application in ISPF

[Frank Swarbrick]

This works.  Thanks much.


From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Thursday, January 16, 2020 5:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Starting an application in ISPF

Just write and invoke a simple exec (or clist if that's your thing):

 /* REXX */
 ADDRESS ISPEXEC
 'SELECT PGM(DGTFMD01) NEWAPPL(DGT) SCRNAME(ISMF)'
 EXIT

You could also invoke it from option 7.1 (Dialog Test), but that adds some
overhead.

sas


On Thu, Jan 16, 2020 at 6:47 PM Frank Swarbrick 
wrote:

> Doesn't work for me.  Must not be in my "profile" or something.

--
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: Starting an application in ISPF

[Frank Swarbrick]

Doesn't work for me.  Must not be in my "profile" or something.


From: IBM Mainframe Discussion List  on behalf of 
Roger Sawtell 
Sent: Thursday, January 16, 2020 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Starting an application in ISPF

I just type  START ISMF on any ISPF command line
Launches in a new window

YMMV
rgds

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Friday, 17 January 2020 12:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Starting an application in ISPF

I am a developer who wants to start up the ISMF application.  Being a developer 
I don't have it as an option on any ISPF menu.  Documentation states I can use 
"ISPSTART PGM(DGTFMD01) NEWAPPL(DGT)" from TSO.  This works, but then I have 
only that application running, and not my other ISPF "stuff".  Is there a 
similar command I can use to start it from within ISPF?

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Good planets are hard to find - please think of the environment before you 
print this email.

CAUTION - This message may contain privileged and confidential
information intended only for the use of the addressee named above.
If you are not the intended recipient of this message you are hereby
notified that any use, dissemination, distribution or reproduction
of this message is prohibited. If you have received this message in
error please notify Air New Zealand immediately. Any views expressed
in this message are those of the individual sender and may not
necessarily reflect the views of Air New Zealand.
_
For more information on the Air New Zealand Group, visit us online
at http://www.airnewzealand.com
_

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

Starting an application in ISPF

[Frank Swarbrick]

I am a developer who wants to start up the ISMF application.  Being a developer 
I don't have it as an option on any ISPF menu.  Documentation states I can use 
"ISPSTART PGM(DGTFMD01) NEWAPPL(DGT)" from TSO.  This works, but then I have 
only that application running, and not my other ISPF "stuff".  Is there a 
similar command I can use to start it from within ISPF?

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

Re: Migrating to new compiler release

[Frank Swarbrick]

Yeah.  We do have regressions tests, but it's not built in to change control 
itself.  Perhaps something we should look in to enhancing.  Thanks.


From: IBM Mainframe Discussion List  on behalf of 
Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, January 15, 2020 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Migrating to new compiler release

We migrate source *and* executable into a controlled stage environment where 
the app folks are supposed to do one last round of tests.   From there, its 
straight copy to all PROD locations.

_
Dave Jousma
AVP | Manager, Systems Engineering

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Babcock
Sent: Wednesday, January 15, 2020 1:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

You’ve got me there!   I would think that chance is relatively small and
wouldn’t worry about it.

On Wed, Jan 15, 2020 at 12:08 PM Frank Swarbrick < frank.swarbr...@outlook.com> 
wrote:

> Intentional differences, yes.  Bug; probably not!  
>
> 
> From: IBM Mainframe Discussion List  on
> behalf of Michael Babcock 
> Sent: Wednesday, January 15, 2020 11:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Migrating to new compiler release
>
> Any difference should be documented in the migration guides I would think.
>
> On Tue, Jan 14, 2020 at 1:38 PM Frank Swarbrick <
> frank.swarbr...@outlook.com>
> wrote:
>
> > I understand that the runtime is part of LE, and is generally shared
> > between versions (at least V5 and V6 seem to share the same runtime
> > for many/most functions).  Conceivably it's still possible that the
> > code generated by a certain version of a compiler may have defects.
> > Probably less likely if the code is in a pre-existing feature.
> >
> > My question has to do with the (probably slight) possibility that
> > the
> code
> > generated by one compiler would be different, for the same
> > statement, for another.
> >
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Charles Mills 
> > Sent: Monday, January 13, 2020 4:54 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Re: Migrating to new compiler release
> >
> > Caution and backups and fallback strategies are always good, but I
> > don't think there is much relationship between *running* a COBOL
> > version X program and having the *compiler* version Y installed. I
> > believe all of the
> runtime
> > is part of LE, not the compiler, and compatibility from VS COBOL II
> > (if I recall correctly) to current C++, PL/I and COBOL is what LE
> > does for a living. Not always perfectly, but that is what APARs and PTFs 
> > are for.
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
> > Sent: Monday, January 13, 2020 3:33 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Migrating to new compiler release
> >
> > I was wondering what "methodologies" shops have for migrating to a
> > new "release" within the same "version" of a compiler.
> > Specifically, we currently have Enterprise COBOL 6.2 (V6 R2) and 6.3 is now 
> > available.
> Our
> > systems group asked if we just wanted to "replace" 6.2 with 6.3.
> > I'm a
> bit
> > wary especially of a program having been compiled with V6.2 but then
> > implemented with V6.3.  Am I over thinking this, perhaps because of
> > the large difference in the compiler from V4 to V5?  What is the
> > likelihood
> of
> > a
> > compiler bug being introduced in V6.3 for code that worked in V6.2?
> > Perhaps
> > very, very little.  But I'd still like to hear thoughts and opinions.
> >
> > For what its worth, along with 6.2 we still have 4.2 and 5.2 installed.
> > But
> > we really should only be using 6.2 at this point any time a program
> > is recompiled.  Anyway, up to this point we've always made sure that
> > the production compile is done with the same version/release as all
> > of the testing.
> >
>

Re: Migrating to new compiler release

[Frank Swarbrick]

Intentional differences, yes.  Bug; probably not!  


From: IBM Mainframe Discussion List  on behalf of 
Michael Babcock 
Sent: Wednesday, January 15, 2020 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Migrating to new compiler release

Any difference should be documented in the migration guides I would think.

On Tue, Jan 14, 2020 at 1:38 PM Frank Swarbrick 
wrote:

> I understand that the runtime is part of LE, and is generally shared
> between versions (at least V5 and V6 seem to share the same runtime for
> many/most functions).  Conceivably it's still possible that the code
> generated by a certain version of a compiler may have defects.  Probably
> less likely if the code is in a pre-existing feature.
>
> My question has to do with the (probably slight) possibility that the code
> generated by one compiler would be different, for the same statement, for
> another.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Charles Mills 
> Sent: Monday, January 13, 2020 4:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Migrating to new compiler release
>
> Caution and backups and fallback strategies are always good, but I don't
> think there is much relationship between *running* a COBOL version X
> program
> and having the *compiler* version Y installed. I believe all of the runtime
> is part of LE, not the compiler, and compatibility from VS COBOL II (if I
> recall correctly) to current C++, PL/I and COBOL is what LE does for a
> living. Not always perfectly, but that is what APARs and PTFs are for.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Frank Swarbrick
> Sent: Monday, January 13, 2020 3:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Migrating to new compiler release
>
> I was wondering what "methodologies" shops have for migrating to a new
> "release" within the same "version" of a compiler.  Specifically, we
> currently have Enterprise COBOL 6.2 (V6 R2) and 6.3 is now available.  Our
> systems group asked if we just wanted to "replace" 6.2 with 6.3.  I'm a bit
> wary especially of a program having been compiled with V6.2 but then
> implemented with V6.3.  Am I over thinking this, perhaps because of the
> large difference in the compiler from V4 to V5?  What is the likelihood of
> a
> compiler bug being introduced in V6.3 for code that worked in V6.2?
> Perhaps
> very, very little.  But I'd still like to hear thoughts and opinions.
>
> For what its worth, along with 6.2 we still have 4.2 and 5.2 installed.
> But
> we really should only be using 6.2 at this point any time a program is
> recompiled.  Anyway, up to this point we've always made sure that the
> production compile is done with the same version/release as all of the
> testing.
>
> Thanks,
> Frank
>
> --
> 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
>
--
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

--
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: Migrating to new compiler release

[Frank Swarbrick]

That doesn't fit in to our current processes.  We migrate source code, not 
executables.  I guess we could consider changing that, but this is small enough 
an issue.


From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Wednesday, January 15, 2020 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Migrating to new compiler release

Seems to me your problem is recompiling after testing.  If you want to
avoid problems that re-compiling could introduce, then don't.

sas

On Wed, Jan 15, 2020 at 11:59 AM Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> I was just stating what a theoretical new version of a theoretical
> compiler might provide.  In the specific case of E.C. 6.3 you are certainly
> correct.  Of course there is no requirement to change ARCH level upon
> implementation of a new version, even if you're at that necessary hardware
> level.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Clark Morris 
> Sent: Tuesday, January 14, 2020 4:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Migrating to new compiler release
>
> [Default] On 14 Jan 2020 13:58:34 -0800, in bit.listserv.ibm-main
> frank.swarbr...@outlook.com (Frank Swarbrick) wrote:
>
> >I disagree with that.  A new version may simply be new features, none
> affecting any features the old version supported.
>
> The 6.3 compiler supports a new ARCH level for the z15 and uses SIMD
> instructions rather that the selected conversion to floating point
> decimal for some calculations.  Both code sequences are an enhancement
> over using standard packed decimal instructions.
>
> Clark Morris
>

--
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: Migrating to new compiler release

[Frank Swarbrick]

I was just stating what a theoretical new version of a theoretical compiler 
might provide.  In the specific case of E.C. 6.3 you are certainly correct.  Of 
course there is no requirement to change ARCH level upon implementation of a 
new version, even if you're at that necessary hardware level.


From: IBM Mainframe Discussion List  on behalf of 
Clark Morris 
Sent: Tuesday, January 14, 2020 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Migrating to new compiler release

[Default] On 14 Jan 2020 13:58:34 -0800, in bit.listserv.ibm-main
frank.swarbr...@outlook.com (Frank Swarbrick) wrote:

>I disagree with that.  A new version may simply be new features, none 
>affecting any features the old version supported.

The 6.3 compiler supports a new ARCH level for the z15 and uses SIMD
instructions rather that the selected conversion to floating point
decimal for some calculations.  Both code sequences are an enhancement
over using standard packed decimal instructions.

Clark Morris
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Charles Mills 
>Sent: Tuesday, January 14, 2020 2:09 PM
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Subject: Re: Migrating to new compiler release
>
>> My question has to do with the (probably slight) possibility that the code
>generated by one compiler would be different, for the same statement, for
>another.
>
>It certainly would. If the code generated for every statement was the same
>for both compilers, then there would be no difference between the two.
>
>Charles
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of Frank Swarbrick
>Sent: Tuesday, January 14, 2020 11:37 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Migrating to new compiler release
>
>I understand that the runtime is part of LE, and is generally shared between
>versions (at least V5 and V6 seem to share the same runtime for many/most
>functions).  Conceivably it's still possible that the code generated by a
>certain version of a compiler may have defects.  Probably less likely if the
>code is in a pre-existing feature.
>
>My question has to do with the (probably slight) possibility that the code
>generated by one compiler would be different, for the same statement, for
>another.
>
>--
>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: Migrating to new compiler release

[Frank Swarbrick]

You are misunderstanding.  My concern, and I admit its a small one, is about 
those programs that were tested prior to the version upgrade but implemented 
after the version upgrade.  Meaning they were tested having been compiled with 
V6.2, but compiled for implementation using V6.3.  It's a short window where 
that would happen, so probably not worth fretting about.


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Tuesday, January 14, 2020 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Migrating to new compiler release

I think we are getting into "how many compiler developers can dance on the
head of a pin?" territory here. I stand by my original answer:

- Yes, be prudent. There are old sysprogs and there are bold sysprogs but
there are no old, bold sysprogs.
- I would be surprised if there were any reasons why having 6.3 installed
would affect how 6.2-compiled programs would run. I would be really
surprised if such reasons existed and they could not be quickly fixed by
APAR and PTF.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Tuesday, January 14, 2020 1:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release

I disagree with that.  A new version may simply be new features, none
affecting any features the old version supported.


From: IBM Mainframe Discussion List  on behalf of
Charles Mills 
Sent: Tuesday, January 14, 2020 2:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Migrating to new compiler release

> My question has to do with the (probably slight) possibility that the code
generated by one compiler would be different, for the same statement, for
another.

It certainly would. If the code generated for every statement was the same
for both compilers, then there would be no difference between the two.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Tuesday, January 14, 2020 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release

I understand that the runtime is part of LE, and is generally shared between
versions (at least V5 and V6 seem to share the same runtime for many/most
functions).  Conceivably it's still possible that the code generated by a
certain version of a compiler may have defects.  Probably less likely if the
code is in a pre-existing feature.

My question has to do with the (probably slight) possibility that the code
generated by one compiler would be different, for the same statement, for
another.

--
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: Migrating to new compiler release

[Frank Swarbrick]

I disagree with that.  A new version may simply be new features, none affecting 
any features the old version supported.


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Tuesday, January 14, 2020 2:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Migrating to new compiler release

> My question has to do with the (probably slight) possibility that the code
generated by one compiler would be different, for the same statement, for
another.

It certainly would. If the code generated for every statement was the same
for both compilers, then there would be no difference between the two.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Tuesday, January 14, 2020 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating to new compiler release

I understand that the runtime is part of LE, and is generally shared between
versions (at least V5 and V6 seem to share the same runtime for many/most
functions).  Conceivably it's still possible that the code generated by a
certain version of a compiler may have defects.  Probably less likely if the
code is in a pre-existing feature.

My question has to do with the (probably slight) possibility that the code
generated by one compiler would be different, for the same statement, for
another.

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